The Four Symptoms of Zombie Scrum
This post is an excerpt from the book 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 thumbnail description of Zombie Scrum is that it looks like Scrum, but without a beating heart. It is a bit like a zombie shuffling along 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 appear to go through the motions of the Scrum Framework. Sprint Planning takes place at the start of the Sprint, the Daily Scrum once every 24 hours, a Sprint Review, and Sprint Retrospective at the end of the Sprint. And there’s often 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; its heart isn’t beating.
Through years of research in and outside our lab, we’ve found that healthy Scrum boils down to four key areas. If you want to be successful with Scrum, you will need to:
- Build what stakeholders need
- Create inspectable results as quickly as possible
- Improve continuously
- Self-organize around a common goal
Zombie Scrum manifests in four key symptoms, each related to one of the areas. Although not all of them necessarily show up together, they usually do. Below, we’ll focus on one of the symptoms: Symptom #1 ‘No desire for contact with the outside world’ is explained in detail. The other three symptoms are briefly introduced, in the book ‘The Zombie Scrum Survival Guide’ we offer an in-depth description.
Symptom #1: No desire for contact with the outside world
This symptom is related to the area ‘build what stakeholders need’. 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 the picture below). They neither care 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 and unwilling to change anything, and have a real impact. Sadly, this picture is usually very accurate.
“Zombie Scrum teams see themselves as a cog in the wheel, unable and unwilling to change anything and have a real impact.”
Their work, as well as the system it takes place in, is often designed to keep them confined in their little box. In traditional organizations, coders only write code, just like managers manage, designers design, and analysts analyze. When they are done they hand off the work to someone else and work on the next thing without knowing what happened to the previous item. This old-fashioned silo-thinking goes against the idea of cross-functional teams that have all the necessary competencies to get the work done without depending on others.
The result is that teams churn out a stream of product features with questionable value. They may not be what the customer actually asked for. 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 without much value.
Zombie Scrum Teams are shy like that
The Other Three Symptoms
Symptom #2: No working product
Zombie Scrum Teams go through the motions of Scrum, but the product is there only at the end of development or at least many Sprints down the road. Stakeholders rarely have the opportunity to validate what was created by the Development Team. Also, the team uses a very limited definition of what ‘done’ means coupled with a lack of drive to expand it.
Symptom #3: No drive to improve
Zombie Scrum Teams show no response to a failed Sprint or even a successful Sprint. Where 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!
Symptom #4: No autonomy, no ownership
Zombie Scrum teams can’t flexibly work with the people they need for creating an amazing product. 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?
It’s All Connected
The four symptoms are all 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 users and customers means that vital opportunities for testing critical assumptions about the product and its use are lost. Without this 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. Or feel bummed out when the Sprint didn’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.
In this article, we explored the four symptoms of Zombie Scrum, in particular, the symptom ‘No desire for contact with the outside world’. If you recognize these symptoms, don’t panic. 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 book ‘The Zombie Scrum Survival Guide’ will help you better understand what causes Zombie Scrum and — more importantly — find all those levers that you can start pulling to shift how your team and organization work. You can expect 50+ experiments that help you fight Zombie Scrum! Interested? Sign up here to stay informed.
Diagnose Your Scrum Team
Are you curious to learn if your organization and team are infected by Zombie Scrum? 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.
Sign up for the book
We — Johannes Schartau, Christiaan Verwijs, and Barry Overeem — are currently up to our necks in the process of writing a Survival Guide for Zombie Scrum. It’s a hands-on guide filled with results from our on-going research and dozens upon dozens of bold-yet-practical interventions to start your road towards recovery. The book will be published by Scrum.org and Addison-Wesley in Q4 of 2020. Sign up here to stay informed and provide feedback on our writing.