In our book — the Zombie Scrum Survival Guide — we dive deep into what causes Zombie Scrum; something that looks like Scrum from a distance, but lacks a beating heart. We also offer 40+ experiments to recover from Zombie Scrum. In this series, we share some of the experiments from the book and many that didn’t make the final cut (but are still very useful). Download the paper “10 Powerful Experiments to Overcome Zombie Scrum” to get more inspiration on how to fight Zombie Scrum.
Self-organization is more likely to take off when teams have autonomy to come up with their own solutions. Unfortunately, many teams don’t have the freedom to choose their tools, their composition, the way they do their work, or how they collaborate with others. In our book, we explore common reasons why this happens.
One reason is that the autonomy of teams often decreases as their dependencies on external people increases. Some dependencies are explicit, like when a Scrum Team needs someone outside the team to do something for them. Other dependencies are more implicit. Having to ask for permission or approval from someone outside the team in order to proceed is a good example of this.
In this post, we describe one tiny experiment that creates transparency about lack of autonomy, and what happens because of it. It won’t create earth-shattering miracles, but I should start the right conversations.
How fair is it to expect wonders from Scrum Teams when the odds are stacked against them so severely?
Required Skill
It only requires a jar, tokens, and a few minutes during your Sprint Review.
Impact on Survival
Even in the most zombified environments, regaining some sense of control makes people sigh with relief.
Steps
To implement this experiment, do the following:
- Find an empty jar, or another container, and place it in the team room. Somewhere near the Sprint Backlog is the best spot.
- Give everyone in your team a bunch of permission tokens. You can use marbles, LEGO® bricks, magnets, or stickies. Use different colors for the various permission categories. For example, permission to release something, to move an item to another column on your Scrum Board, or to change your tools or environment. We recommend a limit of five categories to keep things simple.
- During the Sprint, put an approval token in the jar every time someone in the Scrum Team has to ask permission from someone outside the team. For example, put a token in the jar when an external architect needs to approve that an item is done. Or when the Product Owner has to vet an item with an external manager. Put a token in the jar when you need permission from office management to purchase stickies. And put a token in the jar when you need a configuration to be changed by an external administrator. Aside from requests for permission, also add a token every time you need someone outside the team to perform a specific action as well.
- During the Sprint Review, and with stakeholders present, share the number of tokens in the jar. Ask: “How does this affect our ability to quickly adapt in the moment and do what is the most valuable? Where can we simplify things?”. Invite people to first consider this for themselves and in silence, then in pairs for two minutes and paired with another pair for four more minutes. Capture the most salient improvements with the whole group. The Sprint Retrospective is a great opportunity for digging into potential improvements.
Our Findings
- For another perspective, you can use different colors for everyone in your team. This allows you to identify who is most often in need of permission.
- If you want to focus on the amount of organizational bureaucracy, don’t add permission tokens for requests from direct stakeholders like customers, users, or people who otherwise invest significant money or time in your product.
- The experiment “Break the Rules!” elsewhere in this chapter is great to test where asking for permission matters, and where it just gets in the way of doing the right thing.
How did it go?
We’d love to hear how it went when you’ve tried this experiment. With your feedback, we can empirically improve experiments, add new ones, and remove what doesn’t work. Let us know in the comments how it went and/or fill in this short feedback form.
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.
Order your book directly from us for some nice extras.