Organizations create rules for a good reason. Usually, they are intended to protect the company and the people working there from harm by preventing mistakes. But some mistakes are not as bad as the rule that exists to prevent them. Many Scrum teams are unable to self-organize and act in the best interest of the company because rules get in their way. This experiment is about testing which rules really matter. It might sound risky in a big company, but we will help you prepare.
This experiment requires you to be daring and careful at the same time. Going too far can have consequences.
Impact on survival
If you pull this off, it has the potential to set positive examples and trigger a wave of change.
To try this experiment, do the following:
Gather your entire Scrum team. Identify an action that you are prohibited from taking but that has a clear benefit to your organization or your stakeholders or would make your team more effective. For example, fixing a bug in the codebase of another team or approving a change without asking for permission from a designated manager first might enable your team to fix a problem immediately when you encounter it rather than having to hand it off to someone else. The experiment “Make the Cost of Low Autonomy Transparent with Permission Tokens” is a great way to find more rules.
The experiment “Make the Cost of Low Autonomy Transparent with Permission Tokens” is a great way to find more rules.
Discuss what would happen if you broke that rule. What would the consequences be? Does the result justify the means? What would happen to the organization if other teams disregarded this rule as well?
Make a plan for what you can do if you break the rule and get into trouble. How would you justify your actions? Is there a way to soften the blow in advance, like sending a nice email or a box of chocolates?
When you are sure that your actions are in the best interest of the organization and the risk is acceptable, break the rule. Don’t break the rule if you’re not sure.
If you are successful, gather the team and discuss whether and how it would be possible to permanently change the rule. You can use your actions as an example of why the rule is obsolete. Experiments like “Share An Impediment Newsletter Throughout The Organization” and “Use Formal and Informal Networks to Drive Change” can help you get started.
Experiments like “Share An Impediment Newsletter Throughout The Organization” and “Use Formal and Informal Networks to Drive Change” can help you get started.
The goal of this experiment is not to create rebellious teams that disrupt everyone’s work and cause harm but to challenge obsolete rules that impede success. Don’t choose actions that only benefit your team and not the organization.
Don’t cause lasting harm to individuals or the organization; choose a gentler way to question the rule than to simply break it.
Looking for more experiments?
Aside from a deep exploration of what causes Zombie Scrum, our book contains over 40 other experiments (like this one) to try with your Scrum team. Each of them is geared towards a particular area where Zombie Scrum often pops up. If you’re looking for more experiments, or if these posts are helpful to you, please consider buying a copy.