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:
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.
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