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.
So What If It’s Not Scrum?
Of course, following the procedures may take you out of the arena of what Scrum defines. From Scrum.org:
What is ScrumBut?
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum. Every Scrum role, rule, and timebox is designed to provide the desired benefits and address predictable recurring problems. ScrumButs mean 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.
If you follow the procedures above, you won’t be doing a ScrumBut, but will solve the dysfunction with a method that may or may not be in Scrum.