3. A Primer on Zombie Scrum

Zombies can’t believe the energy we waste on nonfood pursuits.

—Patton Oswalt, Zombie Spaceship Wasteland

In This Chapter

• Understand the symptoms and causes of Zombie Scrum.

• Diagnose your team with our Zombie Scrum Checker.

• Sigh with relief to discover it’s possible to recover from Zombie Scrum.

“All right, recruit: We trust you have gotten yourself into a more or less safe environment with the help of the First Aid Kit. Take a deep breath. The chances of you getting mauled by these zombies is now a bit less than 100%! That is some serious progress. We understand that you’re itching to get back out there and find a cure. For now we need you to sit tight though! We need to make sure you will be able to spot Zombie Scrum infections within seconds. This knowledge can save lives. And kittens!”

An Experience from the Field

A couple of years ago we did work for a large financial institution. They had the seemingly perfect transformation plan to roll out fifty-plus Scrum Teams in one year. Every week, a couple of new Scrum Teams were launched. Everyone buzzed with excitement. “Scrum of Scrums” started. Big Room Planning sessions were organized. Release Trains were planned. At the end of the year, the transformation plan was completed, and it was time for a big party. The agile transformation was a success!

However, the only metrics they used to track “success” were how busy people were, such as the number of Story Points completed per Sprint and whether all the items from the Sprint Backlog were finished. Teams were actively compared on these metrics and encouraged to get more work done. Instead of going after larger organizational impediments, teams were asked to focus on what they could improve within their team. People felt misled, manipulated, and controlled. Although their metrics showed that they were very busy, everyone felt something was off. . . .

Two years after the agile transformation had kicked off, they started to explore different kinds of metrics in an effort to identify what was wrong. Instead of focusing on how much work was being done, they started tracking metrics that more directly measured agility. From tracking and comparing Story Points, they shifted to measuring the time that elapsed between the start of working on an item from the Product Backlog to its delivery (cycle time), how happy customers were with what was being delivered (customer satisfaction), how happy teams were (team morale), how much money was being returned from what was being invested in development, the quality of what was being delivered (e.g., total defects), and how much time teams spent on innovation (innovation rate).

When the first results came in, everyone was shocked. Their cycle time had increased, customer satisfaction had gone down, teams were unhappy, the return on investment was very low, the number of defects seemed to go through the roof, and as a result, there wasn’t any time for innovation anymore.

What was going on? They had implemented everything they thought was part of the Scrum Framework. All the artifacts, roles, and events were in place. They had even added some extra practices like Scrum of Scrums, Story Points and Big Room Planning. Why wasn’t Scrum delivering on its promise?

The State of Scrum

There is no doubt about it: Scrum is wildly popular. It has been adopted by many organizations from all over the world. The two official organizations that spread the Scrum Framework far and wide together— Scrum.org and Scrum Alliance—have hundreds of trainers worldwide. More than a million people have been certified. Countless books and comic books and articles on Scrum have been written and every country has one or more user groups. You can even find songs about Scrum on YouTube!

Following the promise of agility, Scrum has become the agile framework of choice for many organizations. The fact that many organizations and teams are trying Scrum is certainly a reason for celebration. On the other hand, although many think they’re doing Scrum, they’re still only touching the surface of what is possible. Like the organization described the case, most are stuck in painful mediocrity, struggling to find their way out.

Organizations and teams often think they’re doing Scrum when everyone is certified, when the roles, events, and artifacts are in place, and when an army of well-paid (external) coaches and trainers is available to support the implementation (see Figure 3.1). Who can blame them for this kind of “Checklist Scrum” when so little time is spent on actually understanding the purpose of Scrum and its underlying principles and values?

Figure 3.1 The agile transformation process

The changes that the Scrum Framework brings remain superficial when there is no useful and valuable increment at the end of every Sprint—that is, when there is no new version of the product ready to release to stakeholders. Unfortunately, and for reasons we’ll explore in this book, work is often organized in such a way that it is very difficult for Scrum Teams to release at the end of every Sprint. So instead of solving these deeper problems, Scrum Teams give up and concede that “it doesn’t work here.” Or worse, the Scrum Framework is blamed for exposing just how little focus organizations have on stakeholder value and being (more) responsive.

Just as trying to eat healthier by adding a salad to your existing diet of burgers and beer isn’t much help, adding a good idea on top of an otherwise broken system isn’t going to result in magical improvements. Instead, discipline, courage, and determination are necessary to start changing the system that is getting in the way. And that doesn’t happen nearly as often as it should.

This kind of superficial Scrum easily devolves into what we’ve come to call Zombie Scrum. There’s a lot of it out there (see “How Bad Is It, Really?” in Chapter 1).

Zombie Scrum

The thumbnail description of Zombie Scrum is that it looks like Scrum, but without the beating heart. It is a bit like a zombie shuffling towards you on a foggy night. All seems well from a distance: Two legs, check! Two arms, check! A head, check! But on closer inspection, it’s obvious you need to run for your life. Something has clearly gone wrong!

The same goes for Zombie Scrum. From a distance, all seems well as Scrum Teams go through the motions of the Scrum Framework. Sprint Planning takes place at the start of the Sprint, the Daily Scrum once every twenty-four hours, a Sprint Review and Sprint Retrospective at the end of the Sprint. And there’s even a Definition of Done! With the Scrum Guide as a checklist, you’d say that the team is doing “Scrum by the book.” But instead of supporting how people do their work, Scrum feels like a chore. There’s no beating heart and not much of a working brain either.

Through years of research inside and outside our lab, we’ve found that Zombie Scrum manifests in four key areas:

Symptom 1: Zombie Scrum Teams Don’t Know the Needs of Their Stakeholders

Different from movie zombies who attack human beings to devour their flesh, teams affected by Zombie Scrum prefer to hide away from people and keep to their familiar surroundings (see Figure 3.2). They care neither what’s upstream nor what’s downstream in the value chain. It’s safer to just hide behind screens and be busy with design, analysis, or writing code. Zombie Scrum Teams see themselves as a cog in the wheel, unable or unwilling to change anything to have a real impact. Sadly, this metaphor is usually quite accurate.

Figure 3.2 Zombie Scrum Teams are shy like that.

Their work, as well as the system it takes place in, is often designed to keep them far away from the people that actually use or pay for the product. In traditional organizations, developers only write code, just as managers manage, designers design, and analysts analyze. When they are done, they hand off the work to someone else and work on the next item without knowing what happened to the previous one. This old-fashioned silo-thinking goes against the idea of cross-functional teams that have the necessary skills and behaviors to create valuable products with stakeholders.

The result is that teams churn out a stream of product features with questionable value. The features may not be what the stakeholders actually needed. Or they’re nice to have but don’t really help the users be much more effective. This creates what is probably the biggest waste in product development: mediocre products that don’t offer much value.

Symptom 2: Zombie Scrum Teams Don’t Ship Fast

Teams that suffer from Zombie Scrum struggle to deliver anything of value at the end of a Sprint. Often, there isn’t even a working increment. If there is, it takes months before it can be released to stakeholders. Even though Scrum Teams go through the motions of Scrum, there is little to inspect and adapt (see Figure 3.3).

Figure 3.3 Sorry, no working product. But a presentation with make-believe will do.

This is most apparent during the Sprint Review. Stakeholders don’t have the opportunity to take the keyboard and mouse to use the product and validate what was created. Instead, the team turns on the projector for a fancy presentation, shows screenshots, or simply talks about what was on the Sprint Backlog. If the product is inspected at all, it is either very technical or annotated with comments like “We have to finish this next Sprint” or “Whoops, that isn’t working yet.” A more subtle indicator is the lack of interaction during the Sprint Review. There are no opinions expressed, suggestions raised, or new ideas discussed. Stakeholders are rarely present. And the Product Owner seems to be OK with everything. Instead of inspecting a new version of the product, the Sprint Review is mostly ticking off boxes from the specifications. It’s all boring, brainless, and without much of a heart. And nobody seems to mind.

These crucial conversations to determine the value of the product and the direction in which development is headed are only possible when people can inspect and talk about something tangible. A potentially releasable version of a product that stakeholders can actually interact with is an incredible conversation piece and answers many more questions than precise documentation. The right questions and comments arise only when people get the chance to try the product directly, without having to rely on their imagination and assumptions about what should be.

This symptom also manifests in how teams define when something is “done.” For teams that suffer from Zombie Scrum, something is already done when it works on their machines, when the code compiles, and when it doesn’t break when you look at it. All the other work that is needed to deliver something of quality—such as testing, security checks, performance scans, and deployments—happens elsewhere anyways. Or it doesn’t happen at all.

Scrum is pointless when teams are unable to deliver a useful and valuable increment of their product at the end of a Sprint. It’s like pretending to be in a real car when instead you’re in one of those spring-mounted playground cars. You can make loud and impressive engine noises and flash your expensive race glasses all you want, but it won’t get you anywhere.

Symptom 3: Zombie Scrum Teams Don’t Improve (Continuously)

Like a zombie that doesn’t complain when an arm falls off, Zombie Scrum Teams show no response to a failed Sprint, or even a successful one. When other teams curse or rejoice, they simply keep their empty stare of numb resignation. Team morale is low. Items from the Sprint Backlog are carried over to the next Sprint without question. Because why not? There’s always a next Sprint, and the iterations are artificial anyway! Figure 3.4 tells that story.

Figure 3.4 “If it ain’t broke, don’t fix it.” Even when the wheels are coming off, the engine is sputtering, and you can’t hear each other over the noise.

Because items on the Sprint Backlog are not tied to any specific Sprint Goal, they can be completed whenever the team feels like it, as team members continue their aimless trudge through a barren wasteland of product development. No signposts, no direction, no alignment, and some tumbleweeds blowing over the road. Walking at a snail’s pace into the sunset without showing any emotions or any drive to improve.

And can you blame the team? The Product Owner is hardly present during the Sprint Review or Sprint Planning. The only thing that matters is how much work they get done, not how useful and valuable that work actually is to stakeholders. There is no time to reflect on what is lost because of this situation. Teams are highly unstable, as members are continuously moved around to where their specialized skills are needed the most. And there’s no actual Scrum Master present to help the team grow. Some of the bottlenecks may be real, while others may be imagined. The bottom line is that nothing improves. If there is any desire to improve in the first place, it is quickly squashed by the harsh reality of life in a Zombie Scrum system. And so the team struggles on, losing a limb here and there, and groaning like there’s no tomorrow.

Symptom 4: Zombie Scrum Teams Don’t Self-Organize to Overcome Impediments

Scrum Teams that operate in environments with Zombie Scrum can’t flexibly work with the people they need for creating an amazing product (see Figure 3.5). They can’t choose their own tools. They can’t even make crucial decisions about their own product. They have to ask for permission for nearly everything, and their requests are often denied. This lack of autonomy results in a very understandable lack of ownership. Why would you care about the success of a product when you’re not actually involved in shaping it?

Figure 3.5 Like cogs in the machine. A very rigid machine.

But every now and again the occasional Zombie Scrum Team gets lucky. Their manager reads something about “agile” and decides to give them more space. She declares the team autonomous overnight. The problem is that self-organization doesn’t happen just because a team is given permission to forge their own path. They have to develop the skills to navigate this autonomy, to align their work with the broader organization and be supported in doing so. Without that support, failure is inevitable. And the manager will likely take control again, even more rigidly than before, since she now has further proof that this “agile thing” doesn’t work!

It’s All Connected

As we mentioned earlier, the four symptoms are closely connected. When Sprints rarely result in working versions of the product, the team can’t benefit from the short feedback loop the Scrum Framework offers. This lack of feedback from stakeholders means that vital opportunities for validating critical assumptions about the product and its use are lost. Without the beating heart of this short feedback loop, it is no wonder that Sprints feel like artificial timeboxes. In these environments, there is no urge to make the best of each Sprint. Nor will teams feel bummed out when the Sprint doesn’t achieve its goal. And even though the team may be aware that this isn’t how things are supposed to be in Scrum, nothing is done to change it, because people feel like they’re stuck in a system without any power to change it.

Isn’t This Just Cargo Cult Scrum or Dark Scrum?

A simple search on the web yields many other metaphors to describe bad Scrum, such as “Cargo Cult Scrum,” “Mechanical Scrum,” and “Dark Scrum.” Aside from the fact that we just love zombies and use any excuse to work them into our writing, we also feel that “Zombie Scrum” emphasizes the lack of motivation, the missing drive to improve, and the slow pace that characterizes this unnatural type of Scrum. Plus, a funny, over-the-top metaphor gives plenty of opportunities for serious fun. After an initial laugh, a more critical closer inspection may offer insights into ways to improve.

Is There Hope for Zombie Scrum?

Once Zombie Scrum, always Zombie Scrum? Luckily the answer is a resounding “No.” First of all, most teams that start with Scrum will face some or all of the symptoms initially. Provided that they learn from their mistakes and find ways to overcome them, there is nothing wrong with making mistakes. Working empirically, using a framework like Scrum, is often at odds with how organizations are used to operating. It’s impossible to change everything at once, so you’ll have to learn how to apply Scrum successfully in the same incremental way that you deliver your product. This may take a long time and a lot of learning.

Second, we know from experience that you can recover from Zombie Scrum even when your team has been stuck in it for a long time. Sure, recovering will be painful, challenging, and time-consuming, but it’s definitely possible to fully recover. Why else would we have invested time in writing a book that’s packed with experiments to prevent and fix Zombie Scrum?

Nonetheless, we have to face the painful truth: Zombie Scrum has spread on a global scale and threatens the existence of many large and small organizations. The number of new teams that are suffering from Zombie Scrum is rapidly increasing. Entire departments are becoming zombified on a weekly basis. Many organizations panic once they’ve recognized the seriousness of this infection. Often, after the first panic settles in, the phase of denial starts. You’ll hear statements such as these:

• “That’s just the way things work here.”

• “This is a one-of-a-kind organization. We’re too unique to do Scrum by the book.”

• “We don’t have time for all these Scrum ceremonies.”

• “Our developers just want to code. Doing ‘real’ Scrum will only make them less productive.”

• “If we increase the maturity of our employees to level 5, Scrum will work just fine.”

The purpose of this book is to offer tangible experiments that help you fight Zombie Scrum. This approach does require you to be brave, bold, and ferocious. And we are fully convinced that you and your team can do this! Remember, you’re not in this alone. You’re part of a global movement that fights Zombie Scrum together!

Experiment: Diagnose Your Team Together

Throughout this book, you’ll find many experiments and interventions that you can do with your team. They are all designed to help create transparency around what is happening, to allow inspection and encourage adaptation. Every experiment follows a similar pattern. We start with the purpose. Then we explain the steps and give direction on what to watch out for.

This first experiment is all about creating transparency and starting a conversation around Zombie Scrum (see Figure 3.6). This is a critical first step towards recovery and to confront the truth that work is needed. This experiment helps you progress on the first three steps of the First Aid Kit (Chapter 2): take responsibility, assess the situation, and create awareness.

Figure 3.6 Team diagnoses in progress

This experiment is based on the Liberating Structure “What, So What, Now What?”¹ It is a good way to build confidence, celebrate small successes, and build the muscle to get through the hard stuff.

¹ Lipmanowicz, H., and K. McCandless. 2014. The Surprising Power of Liberating Structures: Simple Rules to Unleash a Culture of Innovation. Liberating Structures Press. ASN: 978-0615975306.

Skill/Impact Ratio

Steps

The following steps help you do this experiment:

1. Go to survey.zombiescrum.org and fill out the extensive free survey for your Scrum Team. Invite others from your team to join your “sample” as instructed. To protect others’ privacy and avoid abuse of the survey, scores from individual members are only shown to each survey taker.

2. When you’ve completed the survey, you’ll receive a detailed report (see Figure 3.7). The report will be updated every time someone joins the sample. In the report, you’ll find results for the four symptoms of Zombie Scrum, as well as a more detailed breakdown. The report also gives feedback and recommendations based on the results.

Figure 3.7 Part of the report you’ll receive after completing the Zombie Scrum Survey

3. When everyone has participated, schedule a one-hour workshop to inspect the results together. We recommend doing this with only the Scrum Team: the Product Owner, the Scrum Master, and the Development Team.

4. Prepare for the workshop. You can print the report and hand out copies, put prints on the walls, or simply put up the profile on a screen.

5. Start the workshop by reiterating the purpose clearly and emphasizing what will happen with the outcomes (and what won’t). Make sure to emphasize that improvement is always a gradual, incremental, and often messy process and that this workshop is a step in that process.

6. Invite everyone to inspect the results silently and note down observations. Ask: “What do you notice in the results?” Encourage people to stick to the facts, and avoid jumping to conclusions, for the first round. After a few minutes, ask people to share their observations in pairs for another couple of minutes and notice similarities and differences. If you have eight or more people, ask pairs to join another pair and take a few minutes to share observations and notice patterns. Ask the small groups to share their most important insights with the whole group, and capture them in a way that remains visible to everyone present.

7. Following the pattern outlined in the previous step, repeat twice more with different questions. For round two, ask people “So, what does this mean for our work as a team?” For round three, ask people “Where do we have the freedom and autonomy to improve as a team? What are small, first steps we can commit to?” Make sure to keep capturing the most salient outcomes.

8. Put the most important actionable improvement on the Sprint Backlog for the next Sprint. Involve others as needed to keep making progress.

Our Findings

• It can be tempting to identify dozens of potential improvements and end up doing nothing at all. Instead, keep a strong focus on improving one thing first before moving onto something else. If that improvement is too big to commit to doing it in a single Sprint, make it smaller.

• When you ask people to participate in this survey, you’re asking them to trust you with their honest answers. Be deeply respectful of that. Don’t spread reports to people outside of the team or forward them to management unless you have clear and unambiguous approval from everyone involved.

• Don’t use the report to compare teams. Doing so will erode trust much faster than you can rebuild it.

Now What?

In this chapter, we explored how Zombie Scrum is something that looks like Scrum from a distance. It has all the mechanical parts: the roles, events, and artifacts. But there is no beating heart. There are no frequent releases. Stakeholders are hardly involved. People don’t feel like they own what they are doing. And there’s generally no drive to do something about the situation. Unfortunately, this state of affairs is remarkably common, according to the data we’ve collected.

Thankfully there’s a way out. Even though recovering from Zombie Scrum may feel like having to pull yourself up by your bootstraps, we’ve seen many teams and organizations do so. The remainder of this book is here to help you better understand what causes Zombie Scrum and to start improving with your team.