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.”
Common Observations
The symptom ‘No Validation With Stakeholders’ is most likely the reality when you observe the following:
- 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.
Teams have no idea who their stakeholders are and/or they prefer to hide from them
Why This Symptom 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”.
Sometimes the lack of stakeholders in the room is caused by a Product Owner who misunderstands their role. Only being an ‘order taker’, handing over requirements to the Development Team
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.”
The 5 Other Symptoms
In total, we’ve defined six symptoms by which you can recognize that stakeholders aren’t involved. Besides the one described in this article, no validation with stakeholders, our research has shown that other symptoms are…
- 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.
- No clue of what is valuable. When you’re dealing with severe Zombie Scrum, you’ll find people struggling to find any kind of meaningful answer to questions about value. Instead, it boils down to platitudes like “it belongs to feature X and that is what person y asked for”.
- 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.
- No focus on the real stakeholder. For these teams, the stakeholder is usually the person that hands them their requirements. These people are often the former Project Manager, Business Analyst, head of department or someone in a parent company.
- 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
Do you recognize this symptom 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.
Get the book
Order your book directly from us for some nice extras.