I’m going to thank Joe Little for introducing me to the term Scrum-but, although I don’t think it’s his. This is an organization that is doing Scrum – but with some changes to the typical process. I’m not talking about the changes that come from a well-run retrospective, but those that are implemented because the organization doesn’t think standard Scrum will work for them. There can be legitimate reasons for this, but the most common one I’ve seen is that the organization isn’t really an Agile organization, they’re just replacing their old SDLC with Scrum.
There’s value in using Agile practices wherever you can, but you won’t get the full value unless you actually become an Agile organization. Becoming Agile is a whole new way of looking at software development. It’s a paradigm shift, not just a new methodology. What are the characteristic differences?
Well, with apologies to Jeff Foxworthy, I’m going to borrow his famous formulation to give some examples.
If you insist on getting all of your story backlog broken down into tasks before you start your first Sprint, you may be a Scrum-but.
Agile organizations get the stories into the backlog with only sufficient detail to do the estimation and assign the business value. The stories aren’t broken into tasks until the Sprint planning meeting. This helps the team avoid doing work that may not be necessary. Why break down a story if the team never gets to it?
If you assign the tasks to your team members based on their roles, you may be a Scrum-but.
Agile teams are self-organizing. People contribute as they are able, not according to some pre-defined role. People assign tasks to themselves and commit to their completion. This gives them the ownership and a sense of responsibility to the team. Both of these elements provide incentive for the team members to excel without fear of failure.
If your team reports its status to the Scrum Master at the stand-up, you may be a Scrum-but.
Agile teams don’t work for the Scrum Master. The Scrum Master works for the team. The team has a goal of completing all the stories they’ve committed to before the end of the Sprint. Team members who sign up for a task commit to its completion, but they commit to the team, not to management. If they fail, they fail the team, not management. If they fail because they have unresolved blockers, the Scrum Master has failed the team, not the other way around.
If you focus on keeping to the original Release Plan, you may be a Scrum-but.
Scrum teams use the points estimates to create an initial Release Plan, but that plan is only a hypothetical based on the story estimates. Story estimates are high-level estimates that don’t become sufficiently detailed to allow the team to commit until the Sprint planning meeting. Once a Sprint has been defined and the stories committed, the release plan is revisited. As the team develops an empirical velocity, the release plan is revisited. As stories change in priority, or stories are added or removed, the release plan is revisited. The release plan is a guide, not a commitment. The team only commits to one Sprint at a time. The team also commits to work as efficiently as possible, turning out high-quality code along the way. Holding to this approach helps the team avoid the quality short-cuts that creep into projects that are “behind schedule.”
I’ll write about more indicators that you might be a Scrum-but in future blogs. Take a look at Part 2.