5. Symptoms and Causes
With sunglasses, a hat, and half a pack of Band-Aids, Roger could pass as a human.
—Nadia Higgins, Zombie Camp
In This Chapter
• Explore the common symptoms of Zombie Scrum related to not building what the stakeholders need.
• Explore the causes and reasons for not involving stakeholders, with the purpose of understanding why this is happening.
• Understand what the involvement of stakeholders should look like in healthy Scrum Teams, and why close collaboration with stakeholders is a prerequisite for success.
An Experience from the Field
Janet works as a software developer for an insurance company. Her team adopted Scrum about six months ago. During Sprint Planning, the Product Owner explains what the Development Team needs to do next. It is very important that the team finishes the work in the two-week Sprint timebox. Failing to do so would derail the plan, as the Product Owner has planned all the Sprints well into the next year.
Every Sprint, Janet works on the items that she is being assigned during Sprint Planning. She fights through the boredom of each Daily Scrum. During the Sprint Review, the Development Team shows the Product Owner what they have achieved. The Product Owner ticks boxes. Then the next Sprint starts. The team feels good that they deliver everything the Product Owner asks of them. Yet Janet can’t help but think, “Maybe there is more out there we’re overlooking.”
So during a team meeting last fall, she remarked that the user interface of the product looked outdated and complicated. Janet would frankly hate to use it herself if she had to. She wondered out loud if the users were okay with it and suggested to maybe involve them more in development. The Product Owner reprimanded her for making assumptions. As a Product Owner, he was responsible for relaying the many feature requests from sales, support, and management to the Development Team. There was really no need to talk with users. Plus, support never relayed any complaints about the interface. He reminded her that they were working for a professional insurance company and not a hip start-up. That was the moment when Janet stopped asking questions about users and simply did what was asked of her.
This case illustrates a pattern that many Zombie Scrum Teams will be familiar with. Instead of collaborating closely with actual stakeholders—such as users and customers—Development Teams instead deliver what the Product Owner ordered. Product Owners, in turn, simply translate the requirements that were handed to them by sales or marketing. Scrum Teams mostly don’t know what happens with their work after a Sprint ends, let alone how their work impacts the users. In this chapter we explore one of the most significant symptoms of Zombie Scrum: not building what stakeholders need.
How Bad Is It, Really?
We are continuously monitoring the spread of Zombie Scrum around the world with our online Symptoms Checker at survey.zombiescrum.org. Of the Scrum Teams that have participated at the time of writing:1
• 65% have little interaction with other departments during the Sprint (e.g., legal, marketing, sales).
• 65% have a Product Owner who rarely rejects work or says “No.”
• 63% never or rarely remove items from the Product Backlog.
• 62% don’t see frequent interaction between the Development Team and stakeholders during the Sprint.
• 62% have a Product Owner who is the only member of the team who interacts with stakeholders.
• 60% have a Product Owner who doesn’t have the mandate to decide how to spend the budget.
• 59% have Sprint Reviews that are attended only by the Scrum Team (no stakeholders).
• 53% have a Product Owner who doesn’t or rarely involves stakeholders in ordering or updating the Product Backlog.
1 The percentages represent teams that scored a 6 or lower on a 10-point scale. Each topic was measured with 10 to 30 questions. The results represent 1,764 teams that participated in the self-reported survey at survey.zombiescrum.org between June 2019 and May 2020.
Why Bother Involving Stakeholders?
Organizations can continue to exist only if they offer something valuable to their environment. It doesn’t matter if they’re commercial enterprises, nonprofits, or governmental agencies. This sounds obvious, right? But somehow, we forget what this means in our day-to-day work. Why is it that in many organizations—large or small—the people who are actually working on a product (designers, developers, managers, testers, and so on) rarely really talk to actual stakeholders? Hidden behind layers of “organizational fat” (sales, marketing, account managers, project managers), the stakeholder has become an abstraction.
Who Are the Stakeholders, Actually?
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 who should be included in deciding what is valuable. And in other organizations, such as NGOs and governmental agencies, the term “customer” is not familiar to staffers.
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 talking only to internal stakeholders, domain experts, or intermediaries is exactly what Scrum intends. The people paying for or using the product 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. Focusing on only one of them is going to lead to trouble. Yet in virtually all the Zombie Scrum Teams we have worked with, the interests of the customers and the users were woefully underrepresented. This imbalance easily leads to many of the symptoms we see in this book.
This part of the book is about including the right people at the right time. These are the people who 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.
Although it is easy to include many people in product development and simply call them “stakeholders,” it is far more difficult to find the people who 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 who 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.
Validating Assumptions about Value
As we explored in Chapter 4, product development is complex work. Inherent to this work is that teams make many assumptions about the needs of stakeholders and how best to fulfill them, or about what is valuable. Each assumption comes with the risk of being wrong. So instead of validating these assumptions at the very end of development, and risk losing a lot of time and money when they turn out to be wrong, we reduce this risk by validating assumptions early and often. This approach means answering questions such as the following:
• Do people understand how to use this new feature?
• Does the feature actually solve the problem it is intended to solve?
• Does the description for this field make sense?
• Does this change improve the conversion rate?
• When we implement this feature, does it indeed reduce the time it takes to perform a certain task?
The Scrum Framework lays down the bare essentials for a process that promotes collaborative discovery to validate these assumptions. By frequently delivering incremental versions of a product, developers and stakeholders can have important conversations about what is valuable and how to build it. “Does the feature, implemented this way, help you solve the problem?”, “What can we do to make this feature more valuable?” and “What new, valuable ideas pop up when you see this?” are the kind of things you want developers and stakeholders to be talking about.
Inspecting the Increment for your product that comes out of a Sprint is where a feedback loop for your product closes. This is the moment when a Scrum Team examines how the results align with the intentions. Inspecting a working Increment allows all the people present to look at the same thing, understand it in the same way, and speak the same language. Without this step, the conversation is bound to stay theoretical and superficial, and delivering a product the stakeholders actually need becomes much harder.
Why Are We Not Involving Stakeholders?
If it is so important to involve stakeholders, why isn’t it happening as much as it should in organizations that suffer from Zombie Scrum? There are many reasons for this shortcoming, and we’ll explore the ones we see most often next. When you are aware of the causes, it is easier to select the right interventions and experiments. Understanding also builds empathy with Zombie Scrum, and how it often emerges despite everyone’s best intentions.
“Okay, junior! Now we’re finally getting into the meat . . . sorry, the core of Zombie Scrum. Delivering value and involving stakeholders are really the bones . . . sorry, the heart . . . what’s wrong with me today? Well, these are important things. We’ll get you all set up for spotting the symptoms of the missing stakeholder so that you can try out several experiments safely. Break a leg! Or rather good luck and don’t get bitten!”
We Don’t Really Understand the Purpose of Our Product
Scrum Teams that operate in environments with Zombie Scrum rarely have a clear answer as to what makes their product valuable. They don’t know how it helps their stakeholders, nor how to make it more appealing. They also don’t know how the product helps their organization achieve its mission. Without understanding the purpose of a product, how can Scrum Teams separate the important work from all the potential work that comes their way? Instead, they focus on the technical part of what is needed to build the product rather than understand why that work actually matters. Much like zombies that stumble around without a sense of direction, many Zombie Scrum Teams work hard on getting nowhere in particular.
Signs to look for:
• When asked to complete the sentence “This product exists in order to . . . ,” nobody—including the Product Owner—offers a meaningful response.
• When you pick any item from your team’s task board, nobody on the team can clearly explain why that item matters to stakeholders and what need it addresses, other than “they told us to.”
• In the environments where the teams work, no artifacts relate to the vision or purpose of the product. Or the product is never even mentioned.
• The Product Owner rarely or never says “No” to items that are suggested for the Product Backlog. The Product Backlog is very long and continues growing.
• Sprint Goals are either missing entirely or they don’t say anything about why a Sprint is valuable for stakeholders.
• When asked, a Product Owner is unable to tell the story of how the items on the Product Backlog are ordered in terms of “First we deliver value by doing this . . . followed by . . . so that we can do . . . .”
The role of the Product Owner exists to continuously make decisions about the product based on feedback from stakeholders and what is happening in the environment. Many different options—ideas, suggestions, and opportunities—will present themselves. Product Owners should find themselves asking questions like these:
• Does it fit with the product’s purpose or vision?
• Does it fit with the mission of our organization?
• Does it align with the needs of most stakeholders?
• Is it complete enough to work, but not too complicated to clutter up the product?
When a Product Owner tries to balance budget and time against the value generated by each option, many of these questions need to be answered with a resounding “No.” These are hard decisions and can be disappointing for those who suggested the options. How can Product Owners and their Scrum Teams make these difficult decisions without a clear understanding of the purpose of their product?
A product’s purpose or vision doesn’t have to be fancy or incredibly inventive, but it should explain which needs of the stakeholders it primarily aims to address at this moment in time. A product strategy then describes in what order those needs will be addressed and what work is necessary to make that happen. Obviously, both are continuously tuned and refined as new insights emerge while developing the product. But they act as a yardstick to make decisions about what should end up in the product and what doesn’t.
Without a purpose or a strategy, Scrum Teams end up with Gung-ho development, where anything goes. All the work becomes equally (un)important. You end up with a huge—and growing—Product Backlog. And worse, you’ll waste a lot of time and money on a bloated, overcomplicated product that is shunned by stakeholders in favor of more elegant alternatives.
Try these experiments to improve with your team (see Chapter 6):
• Express Desired Outcomes, Not Work to Be Done
• Start a Stakeholder Treasure Hunt
• Limit the Maximum Length of Your Product Backlog
• Map Your Product Backlog on an Ecocycle
• Decorate the Team Room with the Product Purpose
We Make Assumptions about What Stakeholders Need
One of the authors once coached a medium-size company where the CEO proudly boasted that he knew better what the stakeholders needed than they did. For him, involving stakeholders wasn’t important. Which was ironic, considering that the company was losing its market share to competitors that offered more innovative solutions.
We hear this sentiment a lot in organizations with Zombie Scrum. “We know what people want. So we will ship it and they will love it.”
Signs to look for:
• Teams don’t invest 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).
• Whenever stakeholders are involved during the Sprint or Sprint Reviews, it is only to inform them about what was done. They are not invited to actually use the product.
• Despite initial praise and high hopes for a new feature, it fizzles and fails to take off after releasing it.
Statements like these are often made by Product Owners who have zero contact with their stakeholders. Instead, they rely on their own intuitions and assumptions. But this attitude ignores the complexities of product development by making three faulty assumptions:
• That you fully understand what kinds of problems your stakeholder is trying to solve with the product
• That what you once identified as helpful hasn’t changed
• That involving stakeholders can’t help you be even more successful than you already are
The degree to which a product is effective can only be determined by stakeholders. You only know if they’re willing to pay for it when they put money on the table. Or invest the time to use your product. The Scrum Framework is designed to help you validate these assumptions as you go. And not taking advantage of that is fraught with risk.
The Sprint Review is a good example of where this belief manifests. When Product Owners or entire Scrum Teams make themselves believe that they know exactly what their stakeholders want, there is no need to involve them. And when stakeholders do show up, it is only to inform them of what happened, without any actual validation of how useful that work was.
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 practice or makes it difficult.
Try these experiments to improve with your team (see Chapter 6):
• Invite Stakeholders to a “Feedback Party”
• Give the Stakeholder a Desk Close to the Scrum Team
• Guerrilla Testing
• Go on a User Safari
• Start a Stakeholder Treasure Hunt
We Create Distance between Developers and Stakeholders
If we had a penny for every Zombie Scrum Team we worked with that had no contact with actual users, we would have bought the Brain X-Tractor 3000 a long time ago (and not just last week when it was practically too late). For these teams, the stakeholder is usually the person who hands them their requirements. These people are often the former Project Manager, Business Analyst, head of department, or someone in a parent company. When you go further up the chain, however, you often find that the person who was labeled as a stakeholder is four or five steps removed from anyone actually using the product themselves. They don’t own the real problem that is being solved and are just one link in an absurdly long chain of requirements being passed down in a game of telephone (see Figure 5.1).
Figure 5.1 The “Game of Telephone” that breaks down communication in traditional organizations where there are many “hops” between the people using the product and the people developing it
Signs to look for:
• There is a lot of talk of “internal stakeholders” and what they need, but rarely talk of actual product users (“real” stakeholders).
• Sprint Reviews are never attended by people who use the product to address a challenge they face. Instead, Sprint Reviews are attended by people from within the organization who have a stake in the product, such as product managers, people from sales and marketing, or the CEO.
• When you ask someone on the Development Team to name one person who’s really using or going to use the product, all you get is an empty stare.
This chain has its advantages. It makes sense in an organization where work is organized along functional roles, as it clearly defines which functional role is responsible for certain kinds of risks. It is also rather predictable and standardized in how, when, and by whom communication takes place. But there are significant downsides, especially when dealing with work where the problem isn’t clear and there is no out-of-the-box solution available. Here you have to figure both out along the way. And to make that sort of “shared discovery” possible, there needs to be frequent collaboration between the people owning the problem and the ones solving it.
If this chain is enforced by organizations, as is often the case, it actively discourages this kind of collaboration. It’s likely that everyone in the chain has more work to do for other projects and other stakeholders. So continuously relaying feedback, ideas, and messages between stakeholders and developers causes too much overhead. Instead, feedback ends up being grouped into monthly or quarterly meetings. Or it is discouraged altogether. As a result, the functional “silos” that form in these organizations create distance between the people using the products and the people developing them. If any kind of Sprint Review takes place, it ends up attended by people who cannot provide meaningful feedback on how they experience the use of the product. Maybe boxes are ticked and documents are updated. But no insight into the usability of the product is generated and there is no conversation about the way forward. After several Sprints, something of questionable value is delivered. The team feels confident about their performance, however, because the person they call their stakeholder is happy that things are going according to their plan.
Try these experiments to improve with your team (see Chapter 6):
• Give the Stakeholder a Desk Close to the Scrum Team
• Create Transparency with the Stakeholder Distance Metric
• Go on a User Safari
• Guerrilla Testing
We See Business and IT As Separate Things
One important cause for Zombie Scrum lies in the line that many organizations draw between “Business” and “IT.” Usually the “IT people” includes everyone with knowledge of software and hardware, such as testers, developers, support employees, architects, and IT managers. The “Business people,” on the other hand, are the people doing sales, marketing, or management (see Figure 5.2). They generally act as “internal stakeholders” of needs that serve the actual, external stakeholders.
Figure 5.2 Business and IT as two, somehow separate, parts of the same company
Signs to look for:
• People talk about “Business” and “IT” as separate departments or separate perspectives.
• There is a lot of negative gossip. People complain about how “IT never gets anything done” or “Business always wants things done yesterday.”
• The “IT people” work in different departments or even different buildings from the “Business people.”
Following their functional roles and the subset of risks they are responsible for, “Business” and “IT” often “collaborate” by means of contracts and documents. During tough negotiations about costs and requirements, the actual stakeholders are forgotten. Distinct rifts form within the organization and you start hearing things like, “If you want to get anything done, don’t talk to IT” and “Business keeps changing their mind.”
One outcome of this separation of “IT” and “Business” is that it encourages a Scrum Team to focus on the needs of “internal stakeholders” over the customers of an organization and the users of the product, and “Business” comes to believe that they are the customers of the product instead, purchasing it on behalf of the real customers. Another outcome is a deep mutual distrust between “Business” and “IT” that drives even tougher negotiations and more extensive contractual agreements. Because the whole circus takes so long, important business opportunities are not exploited because people stop making the effort.
“Software is eating the world,” said Marc Andreessen in 2011,2 when he observed that more and more organizations, regardless of their sector and industry, depend on software to perform their primary processes and remain competitive. That makes the distinction between “IT” and “Business” just as meaningless as arguing over whether you need your brain or your intelligence to solve puzzles; you need both. Unfortunately, organizations with Zombie Scrum cling to this meaningless distinction and let it actively get in the way of delivering value to their actual stakeholders.
2 Andreessen, M. 2011. “Why Software Is Eating the World.” Wall Street Journal, August 20. Retrieved on May 27, 2020, from https://www.wsj.com/articles/SB10001424053111903480904576512250915629460.
Try these experiments to improve with your team (see Chapter 6):
• Give the Stakeholder a Desk Close to the Scrum Team
• Create Transparency with the Stakeholder Distance Metric
• Go on a User Safari
• Start a Stakeholder Treasure Hunt
We Don’t Allow Product Owners to Actually Own the Product
In organizations with Zombie Scrum, Product Owners simply translate requirements into items for the Product Backlog, without much of a say in what goes on it or in what order. They fulfill their roles as “Order Takers” with no actual ownership or mandate (see Figure 5.3). Whenever a decision needs to be made about the ordering or what goes on the Product Backlog, either they don’t make a decision at all or they have to defer to someone higher up in the organizational hierarchy.
Figure 5.3 When Product Owners act as “Order Takers,” they mindlessly transfer requests from stakeholders to the Development Team.
Signs to look for:
• During the Sprint Review, the Product Owner gathers sticky notes with feedback. But other people decide if these ideas are actually going to happen or not.
• When the Development Team considers the product ready to release, the Product Owner needs to ask the entire chain of command for permission, making it impossible to release multiple times during the Sprint.
• When asked, the Product Owner has no idea how much actual value was generated by the outcome of a Sprint.
This lack of autonomy is curious, because the Scrum Guide states that “the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.”3 When Product Owners don’t take an active role in deciding what goes on the Product Backlog and in what order, it will be nearly impossible for them to maximize value. Instead, the focus shifts to getting as much work done as possible. Unfortunately, much of that work will be of questionable value compared to the money and effort that was poured into doing it.
3 Sutherland, J. K., and K. Schwaber. 2017. The Scrum Guide. Retrieved on May 26, 2020, from https://www.scrumguides.org.
When Product Owners fulfill their role as intended, they become “Order Makers” instead. They have to if they want to filter the many needs and requests of many potential stakeholders into a useful and valuable product. With the inherent limitations on budget and time, Product Owners have to work closely with stakeholders to decide what is important and what isn’t. Without mandate, they won’t be able to make these decisions at all, or it will simply take too long to navigate the organizational hierarchy and internal policies. When they are “Order Makers,” Product Owners truly maximize the work not done.
Try these experiments to improve with your team (see Chapter 6):
• Limit the Maximum Length of Your Product Backlog
• Map Your Product Backlog on an Ecocycle
We Measure Output over Value
Up to this point, one underlying root cause of Zombie Scrum is that it focuses on getting as much work done (output) rather than judging the value of that work to stakeholders (outcome). This symptom also shows in, and is often amplified by, how Scrum Teams report their work.
Signs to look for:
• Scrum Teams report metrics that capture how much work is being done, such as velocity, the number of items completed, or the number of bugs fixed.
• None of the metrics used by Scrum Teams captures the value of that work. For example, how quality or performance improves or how the work is appreciated by stakeholders.
• Scrum Teams are actively compared by others on their output and (implicitly or explicitly) told to work harder.
This focus on measuring output makes sense when you consider the guiding philosophy behind how work is organized. When organizations design work along functional roles, they often want to measure how that work is done by those roles. How many leads are generated by sales? How many projects are delivered on time by project management? And how many support calls are handled by support? For Scrum Teams, this translates into how much work they can get done in a certain amount of time.
The purpose of this reporting is to improve the efficiency of the entire organization by tuning the efficiency of individual components (people, teams, departments). The assumption here is that the efficiency of the entire system improves when individual components become more efficient. And although that might apply to environments where work is predictable and follows recipes, such as assembly lines and manufacturing processes, it doesn’t work for complex environments where the degree of collaboration needed to deliver value is much higher.
In complex environments, focusing on the efficiency of individual units—people or teams—actually reduces the overall output because it tries to keep each unit as busy as possible. And that undermines collaboration within the organization and with stakeholders. In Chapter 9, we share more helpful metrics.
Try these experiments to improve with your team (see Chapter 6):
• Decorate the Team Room with the Product Purpose
• Limit the Length of the Product Backlog
• Express Desired Outcomes, Not Work to Be Done
We Believe That Developers Should Only Write Code
In Zombie Scrum, developers are generally encouraged to focus on writing code while other people work with stakeholders. Or developers promote this belief themselves by stating that they’re “only here to code” and anything else is considered a waste of time (see Figure 5.4).
Figure 5.4 The “I’m only here to code” attitude is a great way to avoid dealing with the frustrations of real stakeholders.
Signs to look for:
• Developers don’t attend Scrum Events or other gatherings because it takes time away from writing code.
• Developers are assumed to lack the social skills needed to talk to stakeholders.
• Job descriptions for developers only mention technical skills and don’t mention anything about creating valuable products together with stakeholders.
This attitude where the work is disconnected from those it serves makes sense in organizations where work is organized along functional roles. Developers are recruited entirely on their ability to write code. Being capable of working with stakeholders is not a job requirement. And yet, that is exactly the kind of collaboration you need when you do something as complex as developing products.
The “I’m only here to code” attitude is a mental enabler of Zombie Scrum. It encourages people to reject ownership of anything outside their immediate functional responsibility. It also paints a stereotype of developers and other roles as being incapable of talking with stakeholders.
Agile software development shifts a developer’s responsibility from being someone who writes code to someone who works with stakeholders to solve complex problems. The same goes for every other specialization, such as UI/UX expert, systems architect, database admin, and so forth. Instead of focusing on individual role responsibilities, the team as a whole becomes responsible for the product.
Try these experiments to improve with your team (see Chapter 6):
• Go on a User Safari
• Invite Stakeholders to a “Feedback Party”
• Give the Stakeholder a Desk Close to the Scrum Team
We Have Stakeholders Who Don’t Want to Be Involved
Scrum Teams sometimes avoid involving stakeholders because they don’t want to bother them. A driving assumption here is that asking questions is seen as unprofessional and inexperienced or is a waste of stakeholders’ valuable time. Stakeholders sometimes use a similar argument: “You are the professionals, go and figure it out.”
Signs to look for:
• Stakeholders consistently don’t make time available to attend Sprint Reviews.
• After the initial briefing of requirements, customers openly question why their involvement is necessary during development.
• When a member of the Development Team asks for clarification or has questions about a feature, the stakeholders point them to the specification documents.
One of the authors once attended a kickoff where a key stakeholder—the customer paying for development—noted that he didn’t need to be involved during the development of his tailor-made product. He felt that he had sufficiently briefed the Product Owner and was expecting great results. The Scrum Team cleverly responded by asking questions like “What makes you certain that your stakeholders will be happy with the product as you’ve described it?”, “How certain are you that the solution we have in mind now is also the best one?” and “Would you exclude new, valuable ideas that emerge during development?” As an experiment, the stakeholder agreed to join the first three Sprint Reviews. Although the initial two Sprint Reviews resulted in no spectacular changes, the third Sprint Review yielded an entirely new feature that was pushed to the top of the Product Backlog. And it convinced the stakeholder that there was huge value in being involved.
What helped this Scrum Team convince the stakeholder was their ability to deliver a done and releasable Increment to production every Sprint. Because value was delivered every Sprint, the stakeholder shifted from being present to oblige the Scrum Team to being present because it helped him get more value out of his investments. Each Sprint Review presented him with an opportunity to add new ideas, make corrections with the team, and stay up to date with what was being released and when. Over the coming Sprints, more and more stakeholders—including many users—started attending the Sprint Reviews for the same reason.
Unfortunately, teams that suffer from Zombie Scrum often don’t have much to show by the end of a Sprint. Even when they have a “Done” Increment, it still takes months for their work to reach production. With such a delay, who can blame stakeholders for not seeing the need to be present? All sense of immediacy is lost as they have to wait a long time for their influence to show in what is released. It’s easy to understand why they’d rather wait with their feedback until a release is imminent, or even afterward.
The complexities of product development lie in the ambiguity of both the problem and the solution. As the example notes, this reality requires that Scrum Teams better explain what is to be gained from a collaborative approach. In turn, this approach only works when Scrum Teams are able to ship (and respond) fast to feedback from stakeholders. If it is very difficult for stakeholders to find the time to join, pragmatic solutions may be called for, such as organizing the Sprint Review at the stakeholders’ location or involving them through teleconferencing.
Try these experiments to improve with your team (see Chapter 6):
• Give the Stakeholder a Desk Close to the Scrum Team
• Express Desired Outcomes, Not Work to Be Done
• Start a Stakeholder Treasure Hunt
• Guerrilla Testing
Healthy Scrum
As we’ve seen in this chapter, Scrum Teams that operate in environments with Zombie Scrum don’t know their stakeholders nor what is valuable to them. This distance is created when organizations design work along functional roles, and when they focus on the efficiency of how work is done by those roles. In contrast, healthy Scrum Teams are more concerned with how effective their work is—that is, how much value it delivers to their stakeholders and the organization they work for. They can’t do this without close and frequent collaboration with actual stakeholders.
Who Should Get to Know the Stakeholders?
In a traditional organizational structure, the stakeholder contacts are probably the product manager or people from sales. When these organizations switch to the Scrum Framework, they often make the Product Owner responsible for connecting with stakeholders. But that is a missed opportunity for collaborative discovery.
Getting to know the stakeholders is something the entire Scrum Team should be involved in. Although a Product Owner will naturally spend more time with groups of stakeholders to determine what is needed in the product, and in what order, the conversations should naturally involve the entire Development Team as well.
We like to explain that the Product Owner is the person who is continuously on a journey to identify what is valuable and important to stakeholders. But instead of translating these value judgments into detailed specifications for the Development Team, the Product Owner creates a Product Backlog that is essentially a list of conversations that should take place somewhere down the road between the Development Team, the Product Owner, and relevant stakeholders. These conversations should take place soon for items near the top of the Product Backlog, and later for others.
Whatever the case, each conversation results in some kind of refinement of the work that is needed. This can result in changes to the Product Backlog or its ordering. Information can also be captured as a workflow drawn out on a whiteboard, a list of notes on a piece of paper, a more detailed description in a tool, or a good recollection from the minds of those present. But the point is that the best products are created when developers and stakeholders work together. Everything that gets in the way of this dynamic should be removed. The purpose is not specification, but conversation.
This approach makes the Product Owner more of a facilitator of the interactions between the Development Team and the stakeholders. No Product Owner, no matter how good or clever they are, can comprehend the playing field on their own. Instead, they can use the intelligence of the entire Scrum Team to clarify what is needed, how to get it done, and in what order.
When to Involve Stakeholders
When should Scrum Teams involve their stakeholders? Healthy Scrum Teams involve them in different ways and at different moments.
Involve Stakeholders during the Creation of the Product Purpose
In this chapter, we explained how a lack of vision and purpose makes it difficult to deliver valuable outcomes to stakeholders. It makes sense to start by clarifying the purpose. And this is an excellent opportunity for Product Owners to bring together the perspectives of stakeholders and the people building the product to create clarity. This effort can take the shape of a workshop, a summit, or an online session. And although “clarifying the purpose” might seem complicated, it essentially boils down to completing the statements “This product exists in order to . . .” and “This product does not exist in order to . . . .”
Considering the complexity of product development, it is only natural that the understanding of a product’s purpose changes over time as work proceeds and new opportunities take shape. So tune the purpose periodically.
Involve Stakeholders during the Product Development Kickoff
Inviting stakeholders to the kickoff of development is a great way to get a strong value focus ingrained from the start. The goal here is to create the foundation for collaboration between the people developing the product and the people using it, paying for it, or relying on it. So instead of starting up a PowerPoint deck of dozens of sheets, focus on facilitating a highly interactive session. Let people get to know each other, using a variety of introductory games. Focus on what people expect from the product and each other.
Involve Stakeholders during the Sprint Review
The most obvious moment to invite stakeholders is during the Sprint Review. It’s up to the Product Owner to decide who, or which groups, can add the most value. If you have a lot of stakeholders, invite a representative sample. The goal here is actively to involve stakeholders. Don’t make them sit and listen to you. Pass them the mouse and keyboard and let them use a new feature. Ask them if it works for them, what they would like to see improved, or what new ideas they have.
The purpose of a Sprint Review is not merely to demo new features and gather feedback. The Scrum Guide clearly explains the purpose in a single sentence: “A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.”4 This means the Sprint Review is an excellent moment to reflect on what has been built by the Development Team, and what that means for future Sprints. It is likely that feedback gathered during a Sprint Review affects what’s on the Product Backlog, or the way it’s ordered. Make good use of this opportunity to inspect not only the new version of the product (the “Increment”) but also the Product Backlog.
4 Sutherland and Schwaber, The Scrum Guide.
Involve Stakeholders during Product Backlog Refinement
The best chefs use a practice called mise en place. It is the practice of putting everything in place before cooking begins. Ingredients are chopped up, meat is sliced, and sauces are mixed. All materials are arranged so that they are easily accessible. Mise en place helps cooks deal with the stress of fast-paced professional kitchens and focus on preparing delicious meals. Refinement in product development is like mise en place for cooking. It helps to prepare for upcoming work and to create focus.
One example of refinement is the activity of breaking down large chunks of work into smaller chunks. If we take on large chunks of work, we’re likely to run into unforeseen problems. We may have forgotten about dependencies, issues in the code may emerge, and things take more time. The larger the amount of work, the higher this risk. For this reason, it is a good idea to break down large chunks into many smaller chunks.
You can do refinement during Sprint Planning. But like a cook who’s trying to cut, chop, and prepare his ingredients while also cooking, you will quickly discover that this approach is stressful and exhausting. It draws energy away from the purpose of Sprint Planning: to determine a goal for the next Sprint and select the work that is necessary for that. Instead, it is better to do your mise en place and let refinement for the upcoming Sprint take place during the current Sprint. With all the ingredients ready, Sprint Planning will be much more fluent and energizing. Some teams do this in the form of timeboxed “refinement workshops,” where the entire team attends; other teams use “Three Amigos sessions,” where three members of the Development Team work together to refine a large feature that will be coming up soon. How you do it is entirely up to you.
Refinement is a great opportunity to involve stakeholders. When refining a certain item, you can invite relevant stakeholders to attend a refinement workshop. Or you can visit stakeholders to interview them about their needs, and then break down the work together.
Now What?
In this chapter, we explored the most common symptoms and causes for not sufficiently involving stakeholders. Without involving stakeholders, the Scrum Framework is pointless, because there is no way to actually know what is valuable.
Are you on a Scrum Team or in an organization where this is happening? Don’t panic. The next chapter is loaded with practical experiments and interventions you can use to start shifting things in the right direction.