Re-thinking ScrumBut and ScrumAnd

What is ScrumBut?

When people have challenges doing Scrum they often abandon or modify a practice. They say “Oh, we do Scrum, but we don’t …” Many of these things that they don’t do include:

  1. have full cross-functional teams
  2. have protection from being interrupted all of the time with needed new functionality
  3. have iterations
  4. always have tests completed by the end of the sprint
  5. do our retrospectives
  6. have a product owner
  7. estimate because it takes too long  and management beats us up anyway when we don’t meet them

Scrum.org defines “ScrumBut” as meaning “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

 

But ironically, Scrum limits the options of how to fix this dysfunction by requiring its immutable roles, rules, artifacts and events be followed. If one fixes the dysfunction by dropping a Scrum practice while adding a non-Scrum practices the team is still doing “Scrumbut” even though they’ve eliminated the dysfunction. But now, by not doing Scrum they are in unfamiliar territory since Scrum does not provide insights on the intention of each of its practices. This tends to have new teams in particular, that don’t understand the intentions the Scrum practices, have to stick to Scrum or go outside of the range of Scrum.

Note that the recent “fix” to this dilemma is something now called “ScrumAnd.” That is, adding additional practices to Scrum. But sometimes the best way to remove a dysfunction is to change a practice that is mandated by Scrum and substituting one that is more applicable to the team.

If people just abandon practices without adopting a new one to fulfill its intent ScrumBut is likely a bad thing. Substituting practices requires understanding the intention of the practice being substituted and a set of alternatives to choose from.

The Scrum guide tells us that its roles, events, artifacts and rules are immutable. This is fine if you want to ensure you are doing Scrum. Scrum is based on the philosophy that following its roles, events, artifacts and rules will facilitate Agile. While this is often true, doing so sometimes either cannot be done economically or at all. Cross-functional teams and being able to plan ahead is not something that can always be accomplished. Just as important, sometimes Scrum’s roles, events, artifacts or rules are not appropriate for a particular situation.

Just changing one of these arbitrarily, however, is not advised. There is a reason (objective) for the roles, events, artifacts and rules. While it may be advisable to change one, the new practice must achieve the original intended objective.

Making a change can be accomplished with this four step process:

  1. Are you having challenges with the practice because it is being done poorly? If Yes, then inspect and adapt and see if you can do it better. If No, continue.
  2. Is there something else in the organization that is causing us this problem? If Yes, then see how to fix that or at least influence the fixing of it. If No, then continue.
  3. Is the ecosystem that the team finds itself in causing the problem? That is, are people not colocated when they need to be or are required skills missing? Can you improve on this? If yes, do so. If No, continue to see if another practice that works within this ecosystem will work better (see next step).
  4. What else can we do that meets the same objective of the practice? If there is something else you can do, then try that. If not stick with the practice until you learn more.

There is no definitive set of alternative practices to Scrum. That is the entire point. But it is worth investigating a few of them to illustrate how Scrum as Example can be used.

How to tell if a change is better

There is a set of underlying principles that can provide an indication if a change will improve things.  This is always in theory to some extent, because even if a change will improve things if made, there are often side effects caused by people not adopting the change that work against it. We therefore must always be diligent and validate any change we make.

The measure to use is the value stream impedance scorecard. In a nutshell, the VSIS indicates how much resistance the system will impose on work being attempted. It is based on what improves total value manifested. Lowering this resistance usually results in more value manifested.

Doing ScrumBut Properly

  1. We do Scrum, but we don’t have fully cross-functional teams.
  2. We do Scrum but we can’t stop management from interrupting us.
  3. We do Scrum but we don’t have hard iterations, we follow more of a flow model.
  4. We do Scrum, but tests are not complete by the end of the sprint.
  5. We don’t do retrospections
  6. We don’t have a product owner
  7. We don’t estimate because it takes too long or management beats us up.