It sounds obvious that you should include your stakeholders. But who are they? Are we talking about users? Customers? Internal or external customers? Product Managers? While some organizations work exclusively for external customers, many also have people inside the organization that should be included in deciding what is valuable. And in other organizations, the term ‘customer’ is not something that people are used to, like in NGOs and governmental agencies.
For this reason, the Scrum Guide purposefully talks about ‘stakeholders’ to mean everyone who has a stake in the product. Particularly in Zombie Scrum, we see many examples where the vagueness of ‘stakeholders’ is leveraged into making teams believe that only talking to internal stakeholders, domain experts, or intermediaries is exactly what Scrum intends. The people paying for the product or are using it are not involved.
And that is a huge issue. In product development, we want to balance the perspectives of users and customers with a business perspective. Only focusing on one of them is going to lead to trouble. Yet in virtually all the Zombie Scrum teams we have worked with, the side of the customers and the users was woefully underrepresented. This easily leads to many of the symptoms we see in this book.
So this experiment is about including the right people at the right time. These are the people that have something to gain when the product delivers and something to lose if it doesn’t. Including them is the best way to reduce the risk of building the wrong product.
“While it is easy to include many people in product development and simply call them ‘stakeholders’, it is far more difficult to find the people that have an actual stake in your product.”
While it is easy to include many people in product development and simply call them ‘stakeholders’, it is far more difficult to find the people that have an actual stake in your product. We find the following questions helpful to discover who they are:
- Is this person using, or going to use, the product on a regular basis?
- Is this person investing significantly in the development of the product?
- Is this person deeply invested in solving a challenge that your product addresses?
You will notice that these questions are about value. 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 or money. Everyone else is your ‘audience’. This likely includes domain experts, intermediaries, and other people that are interested in your product but have no personal stake in it. You can happily invite them for the ride, but you want to focus on your stakeholders. Naturally, this perspective emphasizes the involvement of the people using your product (users) and the people paying for it (customers). These groups often overlap.
Recovering from Zombie Scrum starts with finding the right stakeholders and continuously refining who is part of that group and who isn’t. This experiment helps Zombie Scrum teams identify the people that care about their product by clarifying the product’s purpose. This is the first step towards interacting with them.
Required skill
Going on a journey to find the real stakeholders takes time.
Impact on survival
When teams start learning who their stakeholders are, it becomes progressively easier to deliver value to them (and recover!)
Steps
Gather your team and ask the following questions to understand the purpose of your product:
- “What is the product we are building? Why does it need to exist?”
- “What would be missing if we stopped building this product?”
- “How do we justify using our precious time, money, and mental energy?”
There are a number of ways to engage participants in this conversation. For this particular experiment, and for many others in this book, we recommend using one or more Liberating Structures. For example, you can use “1–2–4-All” and ask the participants to silently reflect on the question for one minute. Then ask them to form pairs and discuss the question for two minutes before they join another pair and discuss for another four minutes. When the time is up ask the quartets to share their results with the large groups. Other Liberating Structures like “Conversation Cafe” or “User Experience Fishbowl” can also be used.
Now that you have clarity on the purpose of your product, ask these questions to hunt for your stakeholders:
- “Who actually uses our product?”
- “Who benefits from our product?”
- “Whose problem are we solving?”
- “How are we engaging these people?”
It’s easy for some teams to answer these questions. Other teams don’t have a clue. In this case, we recommend making your way up the chain. Ask the team:
- “Who tells us what to work on?”
- “Who tells them what to work on?”
- “What happens before that?”
Once you have identified your stakeholders successfully you can try other experiments to start interacting with them. For example, the ones we describe in our book: “Give the Stakeholder a Desk Close to the Scrum Team” and “Invite Stakeholders to a ‘Feedback Party’”. Or check the do-it-yourself workshops we created about stakeholder engagement.
Our findings
- Zombie Scrum teams often know very little about where their requirements are coming from. It’s entirely possible that asking the previous questions will earn you a lot of shrugs and confused looks. Start with the Product Owner and see how far you get. If you can’t go any further, ask around within your organization.
- Some stakeholders will receive you with open arms once you start interacting with them. Others will be just as skeptical as Zombie Scrum teams and won’t see the benefits. Find a way of showing how closer contact with the Scrum team can help them!
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.