Scrum for Software Development

In my earlier post I explained why we needed this. In this one I’ll describe some principles and practices that should be in it

Use some degree of test-first. At a minimum, anytime a request is made the question “how will I know I’ve done that” should be asked

An understanding that delays in feedback, workflow and between getting and using information causes unplanned work

Continue reading “Scrum for Software Development”

Why we need a Scrum for Software Development Teams

Scrum proponents take pride in the fact that Scrum can work anywhere, in any domain. But keeping it in its generic form leaves big gaps in the practices people should be using.

The result of this is often that people have to reinvent things and don’t have ready access to concepts that would guide their adoption. These challenges are exacerbated when the immutable aspects of Scrum need to be modified a little. What often happens is people try to follow Scrum, often referring to the Scrum Guide and what they learned in their CSM class. They should be using Scrum as an open framework as it’s intended.

Continue reading “Why we need a Scrum for Software Development Teams”