Why Zombie Scrum Teams Don’t (Sufficiently) Involve Stakeholders
How frequently validating assumptions with actual stakeholders is the best way to reduce risk
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 this article, we offer one symptom that tells you that stakeholders aren’t sufficiently involved. It’s the symptom ‘No Validation With Stakeholders’. We also introduce the other 5 symptoms, which will be explained in more detail in the book.
In case you’re wondering what is meant by ‘stakeholders’ as used within Scrum, check the article “Actual stakeholders? Or just your audience?”. In short, a stakeholder is someone who helps you decide what is valuable to work on next because it’s important to them to get a return on their investment of time and/or money.
“A stakeholder is someone who helps you decide what is valuable to work on next because it’s important to them to get a return on their investment of time and/or money.”
Signs to watch for
- Teams don’t invest any time in exploring ways, tools, and techniques to validate what they are doing with stakeholders;
- Sprints are never intended to test a hypothesis about what might help stakeholders (or add more value);
- When asked, the team can’t explain who their real stakeholder is. They’ll only mention direct colleagues. None of them really has a ‘stake’ in the product;
- Whenever stakeholders are involved during the Sprint or during Sprint Reviews, it is only to inform them about what was done. They are never invited to take the keyboard (or what makes sense for your product) and try it out;
- Despite initial praise and high hopes for a new feature, it fizzles and fails to take off after releasing it;
If Zombie Scrum Teams actually know the people that are going to use the product, they prefer to hide from them. This is quite different from regular zombies, who have developed an unhealthy, carnivorous interest in other people. Zombie Scrum Teams rarely (or never) have real stakeholders present during the Sprint Review or the Sprint Planning and certainly, don’t validate assumptions with them throughout the Sprint by other means.
Why This Is a Problem
Involving the stakeholders of a product is one way to validate the assumptions that we continuously make while developing products early and often. This means answering questions like:
- “Will people understand how to use this new feature?”
- “Is this button in the right spot for people to find it?”
- “Does the feature actually solve the problem it is intended to solve?”
- “What other ideas emerge from using this feature?”
- “Does the description for this field make sense?”
Not involving stakeholders during Sprints means that no meaningful validation of the assumptions behind these questions takes place. This increases the risk of wasting time and money on building unnecessary things. And there is no foundation for a discussion about what needs to happen next to maximize the value of the product.
“Involving the stakeholders of a product is one way to validate the assumptions that we continuously make while developing products early and often.”
Common Causes
Sometimes the lack of stakeholders in the room is caused by a Product Owner who misunderstands their role. Often they have no contact with people that are using and/or paying for the product themselves. They will then proclaim that they know exactly what the stakeholders need — perhaps even better than they do themselves — and that there’s really no need to talk to them. That’s why they never invite stakeholders to Sprint Reviews. And whenever people make an assumption about what stakeholders need, Product Owners never hit the brake and say “Wait, let me check with them if that’s really what they want”.
In some cases, Development Teams prefer to hide on their own volition. The people that are using the product are scary, so they try to avoid them altogether. Other Zombie Scrum Teams are kept away from the people who are using, or will be using, the product by managers or other teams and departments. Maybe because developers are deemed unable to have meaningful conversations with stakeholders. Maybe because stakeholders only talk to sales managers, who then talk to project managers, who then talk to Product Owners, who then talk to developers.
No matter what organization you work for, or what your context is, there is no excuse for not validating if the time and money you’re spending are actually worth the effort. Do it together and do it often. Remove or change everything that prevents this or makes this difficult.
If you have a flawed understanding of who it actually is you’re building your product for, however, it becomes tricky to do that.
“In many organizations, developers are deemed unable to have meaningful conversations with stakeholders.”
What else?
Aside from a lack understanding how shipping fast helps to reduce risks, there are many other reasons why Zombie Scrum Teams don’t involve stakeholders. Here is a brief overview of some of the other reasons we’ve found. We cover these, and others, in more detail in our book, The Zombie Scrum Survival Guide.
Cause #2: No product ownership
In many organizations, the work of the Product Owner is understood primarily as that of a gateway between the developers and the stakeholders. Product Owners are fulfilling their roles as “Order Takers” with no actual ownership or mandate of the product.
Cause #4: No vision, no strategy, no purpose
In Zombie Scrum Teams, we rarely find a clear and compelling vision for the product. Instead, they focus more on doing the work that is needed to build a product than to understand why that work matters. Much like Zombies that stumble on without a sense of direction, many Zombie Scrum Teams work very hard on getting nowhere in particular.
Cause #6: No transparency of the Scrum Team.
Not only do Zombie Scrum teams hide from stakeholders, but they also hide the work they’re doing or going to do. Take the team that hid their Product Backlog in a digital tool, only accessible to the Scrum Team itself.
Closing Thoughts
Recovering from Zombie Scrum starts with actively involving your stakeholders. So start searching for the real stakeholder, invite them for a cup of coffee, and explore what the most beneficial type of collaboration could be. In upcoming articles, we’ll describe the causes of this symptom and offer experiments to try to prevent and/or resolve it.
We’d love to hear your experiences with this symptom. What are the things you’ve tried? What are other symptoms by which you know that stakeholders aren’t involved? Feel free to share them, we might include your idea in the book!
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.
How To Recover?
In our book, we offer 10 powerful experiments to start involving stakeholders. We explain each experiment step-by-step and help you prepare.
