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 experiments that didn’t make it to the book but are still very helpful. This post was written collaborative by Christiaan Verwijs, Barry Overeem, and Johannes Schartau. Download the paper “10 Powerful Experiments to Overcome Zombie Scrum” to get more inspiration on how to fight Zombie Scrum.
It is hard for a Scrum Team to ship fast when it has to wait on other departments, teams, or suppliers to do something they depend on. For example, when deployments are performed by an external team that is swamped with other work. Or when another department has to perform specialized testing before approval is given. Whatever their dependencies, they are generally outside of the control of a team. That makes the delays unpredictable. Even when a Scrum Team considers something “Done”, weeks or months may pass before their work actually reaches stakeholders. This greatly impedes a team’s ability to work empirically and reduce the risk associated with complex work.
This experiment is about creating transparency around dependencies and the effect they have on your team’s ability to ship fast. This experiment was inspired by the Dependency Spiders in Jimmy Janlen’s “96 Visualization Examples” (which contains many other useful visualizations).
Required Skill
Mapping dependencies and calculating wait time are easy.
Impact on Survival
Removing or reducing dependencies is a great way to ship faster.
Dependency Spiders help visualize where teams depend on others, and what happens because of that.
Steps
To implement this experiment, do the following:
- Draw your Scrum Team in the middle of a big piece of paper. Together, create a list of the teams, people, and departments you frequently need something from in order to create a Done Increment or release it. Whose approval do you need? Who needs to perform an activity in order for your team to continue? Draw the sources that you depend on around your team, like the legs of a spider.
- Whenever your team needs something from someone outside the team, capture the request and the date it was issued on a sticky note and put it next to the source on the canvas. When the request is fulfilled, write the number of days you had to wait on the sticky. At the end of the Sprint, calculate the average wait time in days for all the requests that have been fulfilled, and move them to an archive.
- Use the Dependency Spider and the average wait time as input for your Sprint Reviews and Sprint Retrospectives. What actions can you take to reduce the impact of dependencies on your ability to ship? How can you include and collaborate with them to remove or reduce dependencies? How can you leverage support from your Product Owner and stakeholders to change the environment of your Scrum Team so that you can ship value to them faster?
Our Findings
- Dependency Spiders are a wonderful tool to visualize what is preventing the system from becoming more effective. You may find that the people you depend on also have dependencies of their own. Although it can be simpler to limit your analysis to the dependencies of your team, you will get a more complete picture of the overall dependencies by inviting other teams, people, and departments to participate.
- Consider using Liberating Structures like Conversation Cafe, Impromptu Networking, or 1–2–4-ALL to start a conversation about the dependencies the team is facing. For resolving the dependencies, give Wise Crowds, Discovery and Action Dialogue, or 15% Solutions a try.
Conversation Cafe in a workshop with Swisscom and KPN iTV.
Experience from the Field
“We used Dependency Spiders to understand a huge dependency that was impeding our ability to ship a large infrastructure product. Releasing new Increments was outsourced to a service provider. Because they used a different schedule and worked for many other customers, our requests would end up somewhere down a lengthy backlog. Not only did we have to wait an unpredictable number of weeks for something to happen, when they finally got around to it they’d bombard us with questions and issues that disrupted our focus from the current Sprint. After creating awareness around the wait time, and the impact it was having on our focus and ability to get feedback from stakeholders, the Product Owner worked with management and the service provider to assign a part-time release engineer to each of the five Scrum Teams. Although there was no requirement to be physically present, we noticed that most of the release engineers made an effort to be with the teams in person.”
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.