This post is an excerpt from the book that we’re writing, the ‘Zombie Scrum Survival Guide’. It’s our way of delivering small increments and involving our stakeholders: you, the reader. So we’d love to hear your feedback, encouragements and wild ideas.
The Scrum Framework urges teams to involve stakeholders. But many Scrum Teams struggle to do so. For some, involving one or two internal stakeholders seems plenty. For others, stakeholders can only be involved when the entire product is done.
In a previous article, we described one of the symptoms that let you know that your stakeholders are not adequately involved. This article explores the main cause behind this zombified interaction.
The Curious Case of Stakeholder Distance
Let’s review for a second: Scrum works best when there’s a tight interaction between the Scrum Team and its stakeholders. Organizations infected with the Zombie Scrum virus show little to no actual stakeholder activity. Make no mistake, some people may be involved and they might even be called “stakeholders” or “customers” by the team. However, they are usually only proxies for real stakeholders according to our understanding outlined in “Actual stakeholders? Or just your audience?”
When you trace the Product Backlog Items the team is working on back to the source — someone whose needs are being met or goal achieved — you will find that there is a considerable distance between Zombie Scrum Teams and their stakeholders. This distance manifests in several “hops” (in the form of people) and/or considerable time that expires while that person or group is waiting for the solution to their problem.
This throws a big fat wrench into the gears of Scrum’s cycle of Transparency, Inspection, and Adaptation. It’s next to impossible to learn and adapt if you can’t see first-hand what kind of effect your actions (in the form of done increments) have. No wonder Zombie Scrum Teams appear so lifeless! Instead of lively interaction with the environment, we usually find a one-way street of churned out “user stories”. Whether these make any impact in the real world at all becomes irrelevant.
“This throws a big fat wrench into the gears of Scrum’s cycle of Transparency, Inspection, and Adaptation.”
But… Why?
At this point, you might ask yourself where this distance to the stakeholders comes from and why we find it so often.
Most organizations structure their flow of value creation guided by the inherent belief that problems can be analyzed in their entirety and solutions devised in isolation. They believe that experts working on an issue individually one after another is the most efficient way to solve this problem. And this chain does have some advantages. It clearly defines who is responsible for certain kinds of risks. It is also rather predictable and standardized in how, when and by whom communication takes place.
The long chain of handoffs aka “Game of Phones” — Created by Thea Schukken
But there are many downsides, especially when dealing with work where the problem isn’t clear and there is no out-of-the-box solution available. These are called complex adaptive problems. Scrum is designed precisely for them. Zombie Scrum organizations generally haven’t realized that they’re dealing with a fundamentally different type of challenge that not only requires a different problem-solving approach but a different organizational structure as well.
Instead of individual experts working on a part of the solution we need cross-functional teams that are optimized for effectiveness and learning. We need a close relationship with our stakeholders. We need to create transparency, inspect what is happening and adapt to reality quickly and continuously.
Game of Phones
Zombie Scrum organizations cling to traditional ways of organizing their work, either because they are unaware that a change is needed or they don’t know how to change. Most of the time their agile transformation is just a renaming of old structures and roles.
And so the long chain of hand-offs, the Game of Phones, lives on. All in the belief that experts analyzing and contributing a part of the solution before handing it off to someone else is the most efficient way of solving a problem. Talking to the people who have the problem and showing them early results to get valuable feedback gets neglected.
“Zombie Scrum organizations cling to traditional ways of organizing their work, either because they are unaware that a change is needed or they don’t know how to change.”
Other Causes
There are other causes of lack of stakeholder involvement in Zombie Scrum organizations. In our upcoming book, we describe these in much more detail. Here’s an outline of the other causes we’ve identified:
- Separation of Business and IT. In most Zombie Scrum organizations, there is a clear delineation between what people feel is “the business” and “the IT”. Instead of working together these two different parts of the company spend most of their time negotiating contracts.
- Focus on output over value. Despite their lifelessness, most Zombie Scrum organizations are very busy. However, there is no real effect that is being achieved.
- Communication by documentation. Members of Zombie Scrum teams often don’t spend time actually talking to each other and working collaboratively on issues. They create documents for other people to read.
- Developers to focus on writing software only. In a healthy Scrum Team, the developer role expands from software developer to product developer. Writing software is one part of that. Zombie Scrum organizations believe developers shouldn’t take responsibility for the entire product and broaden their horizons a bit.
- Developers are considered incapable of talking to stakeholders. Zombie Scrum developers are usually kept isolated and away from the outside world. This is often due to the old stereotype that developers lack social skills.
- Assumptions are made about what stakeholders need. Instead of involving stakeholders, gathering feedback and testing assumptions a lot of Product Owners, project managers and analysts believe they know much better what the stakeholders need than they know themselves. This leads them to develop solutions in isolation for a long time.
- Stakeholders Don’t want to be involved. Sometimes teams do their best to involve their stakeholder but they simply can’t be bothered. They want to see “the finished thing”, not any intermediary steps.
Diagnose Your Scrum Team
Do you recognize this cause of Zombie Scrum or are you curious to learn if other symptoms are present in your organization and team? Why don’t you give the Zombie Scrum Symptoms Checker a try? It’s completely free and anonymous and offers your team a profile that helps you identify the areas for improvement.
Order your book directly from us for some nice extras.