Back to Blog List

How Poor Facilitation Of The Scrum Events Can Cause Zombie Scrum

Barry Overeem
(Netherlands)
May 29, 2023
Subscribe

1

In the past years, Johannes Schartau, Christiaan Verwijs, and I wrote many articles on Zombie Scrum. Heck, we even wrote a complete Zombie Scrum Survival Guide! I’d like to believe that since our book, Zombie Scrum completely disappeared. That it’s something we can now all laugh about and has become this silly way of working we only know from the dark old days.

Unfortunately, we’re not there yet. I definitely see many good things happening within our community, and the teams and organizations we work with. But Zombie Scrum is still present in different shapes and forms. In particular, during the Scrum events. Why? What? So What? Now What? That’s roughly the flow of this blog post. In short, I’ll describe how poor facilitation of the Scrum events can cause Zombie Scrum. Hence the title of this blog post.

Zombie Scrum?

First, let’s start with a short introduction of what we mean by Zombie Scrum. Zombie Scrum looks like Scrum from a distance. It might seem that a team has all the important elements of Scrum in place. They have a Product Owner, a Scrum Master, and a bunch of Developers. They conduct all the Scrum events and use a Product Backlog and even a Sprint Backlog. But closer inspection shows you there’s something wrong… the team seems to be missing the beating heart of Scrum: a working, valuable product!

The team doesn’t even know for whom they should actually build the product, they don’t have a clue who their stakeholders are. Due to dependencies and constraints, the team can’t ship their product increments and validate if what they’re building is really valuable. They lack the support from management to resolve persistent impediments. Everyone can identify the areas that need improvement, but the motivation to change the situation is nowhere to be found. The team focuses mostly on superficial improvements, and this gives everyone the illusion of continuous improvement. In short, Zombie Scrum!

2

What symptoms of Zombie Scrum can you spot?

Use the Scrum events to detect Zombie Scrum

Scrum events are the most obvious place to detect Zombie Scrum. Some symptoms are very tangible and visible. For example, during the Daily Scrum, the team doesn’t use a Sprint Goal. During Sprint Planning, only a few large chunks of work, that can’t result in a Done increment, are added to the Sprint Backlog. And during the Sprint Review, none of the stakeholders shows up. The team doesn’t even know who their stakeholders are anyhow.

Other symptoms of Zombie Scrum are less visible. You’ll notice them in the way people interact, collaborate, make decisions, discuss dependencies, navigate conflict, remove impediments, etc. In order to detect those symptoms, you need to pay attention to what you see happening, hear people say, and notice in general. What’s the dynamic within the team? And what can you say about the relationships between the team and its supporters (managers, leaders, coaches) and its stakeholders?

Let’s dig a bit deeper into what Zombie Scrum during the Scrum events might look like. For each event, and the activity of backlog refinement, we’ll describe its purpose and offer 3 potential symptoms of Zombie Scrum.

Sprint Planning

The Scrum team creates a basic plan for the upcoming Sprint and decides what work needs to be done in order to achieve the Sprint Goal.

  • Sprint Goals are either missing entirely or don’t say anything about why a Sprint is valuable for stakeholders.
  • During Sprint Planning, only the easy but not-so-valuable Product Backlog items are selected. The more valuable, riskier items are ignored.
  • Sprints are never intended to test a hypothesis about what might help stakeholders (or add more value).

Daily Scrum

The Developers inspect the progress of their work towards achieving the Sprint Goal, as made transparent through their Sprint Backlog, and make adjustments accordingly.

  • The Daily Scrum is merely a status update with the Scrum Master as the chairperson.
  • Concerns or doubts are never expressed, even though everyone knows they’re not going to achieve the Sprint Goal.
  • When members of the team are stuck on a task, they don’t ask for help from others. Or it takes several days of muddling through before they do so.

Sprint Review

The Scrum team and its stakeholders inspect the work that has been done to date and decide what next steps make sense based on what was learned from that.

  • During the Sprint Review, there’s no working product to inspect together.
  • The Sprint Review is rarely attended by the stakeholders of your product.
  • Whenever stakeholders are involved during the Sprint Review, it’s only to inform them about what was done. They are not invited to actually use the product.

Sprint Retrospective

The Scrum team inspects how they worked together to achieve the Sprint Goal and identifies concrete steps that can be taken in the next Sprint to increase effectiveness and quality.

  • Sprint Retrospectives tend to be boring and repetitive. Or it’s the opposite, and the only focus is to make the Retrospective fun, yet simultaneously meaningless.
  • During the Sprint Retrospective, the Scrum Master is always the person that gathers sticky notes with improvements. It’s also unclear where to start or what success looks like.
  • The conversations during the Sprint Retrospectives focus on tiny improvements, instead of the important things that are obviously not going as well as they could.

3

The conversations during the Sprint Retrospectives focus on tiny improvements, instead of the important things that are obviously not going as well as they could.

Refinement

As an ongoing activity, the Scrum team clarifies, estimates, breaks down, and re-orders work from the Product Backlog.

  • Scrum teams don’t spend time refining work for upcoming Sprints. Mostly, because it leads to endless debates about how important or how much work certain functionality is. Nobody enjoys these debates, so they rather prevent them from happening.
  • The Product Owner has a limited mandate over “their” product. Either they aren’t allowed to make decisions (for items on the Product Backlog) or they frequently have to ask for permission.
  • Facilitation of backlog refinement (and all the other Scrum events) is always the responsibility of the Scrum Master. If the Scrum Master doesn’t show up, backlog refinement never happens.

So how do facilitation and Zombie Scrum relate?

Now you might wonder what these symptoms of Zombie Scrum have to do with how the Scrum events are facilitated. Well, I’m convinced that some symptoms are a direct result of the Scrum events facilitation and others aren’t made visible sufficiently. Because they’re not made transparent, they aren’t resolved either.

In general, Zombie Scrum teams tend to use 5 conventional structures during the Scrum events for communication, decision-making, and the gathering of ideas. I’m talking about the presentation, status report, managed discussion, themed brainstorming, and open discussion.

The problem with these 5 conventional structures, is that they are either too structured or inhibiting, with one person talking while the rest ‘listens’. Or they are too unstructured and loose, with only a handful of people talking while the rest is struggling to keep up. Furthermore, conventional structures tend to favor people that are more extroverted and can ‘think by talking’, whereas the more introverted people feel left behind because they are still thinking about a previous point.

4

The problem with the 5 conventional structures is that they are either too structured or inhibiting, with one person talking while the rest ‘listens’. Or they are too unstructured and loose, with only a handful of people talking while the rest is struggling to keep up.

Although these 5 structures can show up during all the Scrum events, there is a clear pattern…

  • Sprint Planning tends to become a managed discussion, where the Product Owner tells the team what work needs to be done, and maybe already selected the Sprint Backlog on their behalf.
  • Daily Scrums tend to become a status report, in which every team member mechanically shares all the tasks they’ve done yesterday, will do today, and the potential problems they face.
  • Sprint Reviews tend to become boring presentations where they demonstrate new features via a status slideshow.
  • Sprint Retrospectives tend to become a themed brainstorm where everyone randomly shares many superficial improvements that rarely address the real problem.
  • Backlog refinement tends to become an open discussion, where without any structure or connection with the Product Goal, one or two large chunks of work are debated endlessly.

5

As a consequence, the Scrum events become boring meetings where not everyone is involved, not all voices are included, ideas get lost, and problems are ignored or only partially resolved. The Scrum events have turned into meetings in which everyone acts like a Zombie, going through the motion in a mechanical, lifeless manner. Meetings people try to skip or cancel because it’s a waste of time. In short, the entire flow of Scrum gets stuck. The Scrum events result in limited transparency, and because of that, inspection and adaptation are ineffective.

Use Liberating Structures to de-zombify your Scrum events!

To create more engaging, meaningful, and impactful Scrum events, the 33 Liberating Structures proved to be a valuable source of inspiration. They help to spice up the events and to involve & engage everyone again. Our recommendation is always to not use Liberating Structures randomly but to choose them based on the purpose you have with a session. In the past years, we created 100+ do-it-yourself workshops. Each workshop contains a step-by-step explanation of how to resolve a specific impediment. Most of the workshops are ideally suited to use during the Scrum events. I’ll share 3 examples for each event. Download the workshop template for a more detailed explanation.

Sprint Planning

Daily Scrum

  • Use Daily Scrums to become better at helping each other with ‘Helping Heuristics’.
  • Use Daily Scrums to discover the essential work that needs to be done with ‘Nine Whys’ and ‘Min Specs’. Check this blog post for a full description of how to use it.
  • Use Daily Scrums to try ‘TRIZ’ and ‘15% Solutions’ to first learn what NOT to do and afterward create a more product plan for the day ahead. Check this blog post for a full description of how to use it.

Sprint Review

Sprint Retrospective

Backlog Refinement

Closing

In this blog post, I described how poor facilitation of the Scrum events can cause Zombie Scrum, and how Liberating Structures can prevent and/or fix it. Liberating Structures allow you to create more engaging, meaningful, and impactful Scrum events. They encourage everyone to contribute to resolving persistent impediments and make the Scrum events sessions everyone considers valuable and worth investing time in.

What did you think about this post?

Share with your network