The Curious Case of Stakeholder Distance
Why the interaction between stakeholders and Scrum Teams is so often completely zombified
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.
Don’t want to read? You can also listen to us reading this post in this episode of our podcast ‘The Liberators Network’.
The Curious Case of Stakeholder Distance
Let’s review: Scrum works best when there’s a tight interaction between the Scrum Team and its stakeholders. Organizations infected with Zombie Scrum show little to no actual stakeholder activity. Make no mistake, some people may be involved and they might even be called “stakeholders” (or even “customers”) by the team. However, they are usually only proxies for real users and customers as they don’t actually pay for the product or use it themselves.
When you trace the Product Backlog items that a team is working on back to their source —the stakeholder whose need they represent— you will find that there is a considerable distance between them and Zombie Scrum Teams. This distance manifests itself as the number of “hops” — people and departments— you have to go through. It also manifests itself as the long wait time for the person who expressed the need.
And this throws a big fat wrench into the gears of Scrum’s cycle of transparency, inspection, and adaptation. It’s close to impossible to learn and adapt if you can’t see first-hand what effect your work has on real users. No wonder Zombie Scrum Teams appear so lifeless! Instead of lively interaction with their environment, all they do is churn out “user stories”. Whether their work makes an impact on users is completely beyond them.
“This throws a big fat wrench into the gears of Scrum’s cycle of Transparency, Inspection, and Adaptation.”
So where does this distance come from? Most organizations structure work as a sequence of specialists who apply their skill to a problem. For example, the sales department first sells a solution. Analysts then fully clarify the requirements. Architects identify the best way to structure the solution with technology. And a designer then sets about creating a visual design. Developers then implement it, after which a tester verifies the work. And a release engineer deploys it to production.
An underlying belief here is that problems can be fully analyzed and designed before any work is done on actually solving it. And that, consequently, no interaction with stakeholders is necessary in between. They also believe that, in light of this, experts working on an issue one after another is the most efficient way to go about solving problems. And this chain does have some advantages. It clearly defines who is responsible for certain kinds of tasks (and the resulting risks). It is also rather predictable and standardized in how, when and by whom communication takes place.
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. It’s with these types of problems, the strength of Scrum becomes clear. Organizations that suffer from Zombie Scrum generally haven’t realized yet 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 instead of efficiency. Teams need to work closely and frequently with real stakeholders to understand what is needed and to test possible solutions. We need to create transparency, inspect what is happening and adapt to reality quickly and continuously.
Game of Phones
Organizations that suffer from Zombie Scrum 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 lives on. We’ve jokingly come to call this the “Game of Phones”. 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. Bringing the people that are actually building the product and the people who’s need is being addressed simply doesn’t happen.
“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.”
Now, there are more reasons why the involvement of stakeholders is generally low in organizations that are dealing with Zombie Scrum. In our upcoming book, we describe them in 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 distinction between what people consider “the business” and “IT”. Instead of working together, the two different parts of the company spend most of their time fighting each other.
- Focus on output over value. Despite their lifelessness, most Zombie Scrum organizations are very busy. Very little attention is paid to what actually results from all that business.
- Communication by documentation. Members of Zombie Scrum teams don’t spend time talking to each other and working collaboratively on issues. They create documents for other people to read.
- Developers tend to focus on writing code only. In a healthy Scrum Team, the role of developers expands from merely writing code to creating a product. Writing code is one part of that. Organizations that suffer from Zombie Scrum believe that developers should stick to just that.
- Developers are considered incapable of talking to stakeholders. Developers are often kept as far away from customers as possible. This is often due to the old (and incorrect) stereotypes that developers lack social skills. This completely neglects that many developers take great joy in fixing problems for users.
- Assumptions are made about what stakeholders need. Instead of involving stakeholders, some Product Owners believe that validating their great product ideas isn’t necessary. They know exactly what customers need, after all. This can easily lead them down development trajectories of years, without releasing anything.
- Stakeholders don’t want to be involved. Sometimes teams do their best to involve stakeholder but they simply don’t show up. They want to see “the finished thing”, not any intermediary steps.
In this article, we explored the main causes of having a zombified interaction between the Scrum Team and stakeholders. Although Scrum works best when there’s a tight interaction between the Scrum Team and its stakeholders, this often not the case. If you recognize the symptoms and causes, check our other articles to gain inspiration for experiments. It’s not time to remain idle, let’s start fighting Zombie Scrum!
Diagnose Your Scrum Team
Are you curious to learn if your organization and team are infected by Zombie Scrum? 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.
Sign up for the book
We — Johannes Schartau, Christiaan Verwijs, and Barry Overeem — are currently up to our necks in the process of writing a Survival Guide for Zombie Scrum. It’s a hands-on guide filled with results from our on-going research and dozens upon dozens of bold-yet-practical interventions to start your road towards recovery. The book will be published by Scrum.org and Addison-Wesley in Q1 of 2021. Sign up here to stay informed and provide feedback on our writing.