In the article “The Rise of Zombie Scrum” Johannes Schartau and Christiaan Verwijs provide a comprehensive description of the symptoms, causes, and treatment of Zombie Scrum. In this blog post, I’ll share the highlights of the original article and offer my own perspective on the causes and treatment of Zombie Scrum.
What is Zombie Scrum?
At first sight, Zombie Scrum seems to be a normal Scrum. But it lacks a beating heart. The Scrum teams do all the Scrum events but a potentially releasable increment is rarely the result of a Sprint. The team also doesn’t have any intention to improve their situation. Actually, nobody cares about this team. The stakeholders have forgotten the existence of this team a long time ago.
Zombie Scrum is Scrum, but without the beating heart of working software.
The Symptoms of Zombie Scrum
Symptom #1: No beating heart
Zombie Scrum Teams may be going through the Scrum motions, but there is hardly any working software (or none at all). Completed functionality is often treated as a ‘nice-to-have’, and can be finished in any other sprint. The lack of a beating heart is also apparent in a very limited and unambitious definition of what ‘done’ means, and no drive to extend it. In healthy Scrum teams understand that having a continuous stream of ‘done’ software is not a nice-to-have, but an essential goal of Scrum. Zombie Scrum approaches this differently. Who cares about working software, gathering feedback, and generating insights?
Symptom #2: No (desire for) contact with the outside world
Scrum zombies prefer to hide away from people and keep to their familiar surroundings. They neither care what’s upstream nor what’s downstream in the value chain. The product failed to meet customer expectations? I’m only here to code! Zombie Scrum teams see themselves as a cog in the wheel, unable and unwilling to change anything, and have a real impact.
Symptom #3: No emotional response to success or failure
The lack of contact with the outside world often leads to this symptom, but it can also manifest itself independently of the other symptoms. Like a lifeless body, Zombie Scrum teams show no response to a failed or successful Sprint. Where other teams curse or rejoice, they simply keep their empty stare of numb resignation. Team morale is very low. Items from the Sprint Backlog get 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 drive to improve
In Zombie Scrum, there’s no joy, and certainly no drive for improvement. And nobody really seems to care. And can you blame the team? The Product Owner is hardly ever-present during the Sprint Review or the Sprint Planning. Teams are highly unstable, as members continuously get loaned out to other teams in need of their (specialized) skills. 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. But the bottom line here is the lack of control a team experiences over their own success, and this easily translates into boring retrospectives and a lot of complaining (moaning). And certainly no desire to improve.
The Causes of Zombie Scrum
Homegrown Scrum is great. That is; teams and organizations that start working with Scrum without the help of (expensive) external trainers and coaches. Some of the best Scrum Teams started out like this.
But Scrum can be a bit too homegrown. Like when a team decides that they’re doing Scrum because they have a bi-weekly ‘Daily Scrum’, or when a team adjusts the sprint length based on what needs to be done (instead of the other way around). This partial adoption of Scrum is often unintentional. But by adopting only a part of Scrum, the actual benefits are lost, and the team will likely struggle.
Cause #1: A bit too homegrown, or ‘Cargo Cult Scrum’
Homegrown Scrum is great. That is; teams and organizations that start working with Scrum without the help of (expensive) external trainers and coaches. Some of the best Scrum Teams started out like this.
But Scrum can be a bit too homegrown. Like when a team decides that they’re doing Scrum because they have a bi-weekly ‘Daily Scrum’, or when a team adjusts the sprint length based on what needs to be done (instead of the other way around). This partial adoption of Scrum is often unintentional. But by adopting only a part of Scrum, the actual benefits are lost, and the team will likely struggle.
Cause #2: No Urgency
We often witness a lack of urgency in Scrum Teams, usually caused by a lack of urgency in the rest of the organization. One of the potential underlying causes is that there’s no real understanding of value. If working software is the beating heart of Scrum, then the value is its lifeblood. Due to the fogginess regarding the value, mediocre Scrum Teams often have a hard time coming up with clear goals. Without goals, there’s simply no reason for urgency. And that, in turn, causes Zombie Scrum, as shared goals are the glue for any team and provide them with purpose and motivation.
Cause #3: Competing Values
Zombie Scrum is essentially the result of a systemic mismatch with Agile values. We know that the business lingo is strong with this one, but the point we’re trying to make is that Healthy Scrum easily decays into Zombie Scrum when people in the organization hold beliefs about software development that collide with what drives Agile software development. To give you some examples:
- Zombie Scrum considers the purpose of Scrum a process that must be followed (for its own sake). Instead of understanding that Scrum allows us to ‘fail fast’ because of a steady stream of working software;
- Zombie Scrum considers working software a nice-to-have; we’re not going live at the end of a sprint anyways. In healthy Scrum working software is essential; even if we don’t go live at the end of a sprint, we learn most from it;
- Zombie Scrum teams experience no sense of urgency. There’s always the next sprint. Sprints are artificial time-boxes. In healthy Scrum teams, however, a sprint is the longest allowed period between feedback opportunities.
Cause #4: Scrum Cherry Picking
At first sight “Scrum cherry-picking” might seem the same as “cargo cult Scrum”. The difference, however, is that with Scrum cherry-picking the partial adoption of Scrum is done deliberately. Doing Scrum by the book was too difficult. It caused too much pain within the organization. Therefore some changes to the already lightweight Scrum Framework were “necessary”:
- Allowing the tester to fulfill the Scrum Master role 4 hours per week. Sharing the weekly status report with the management shouldn’t take more time;
- Extending the Sprint by a couple of days to ensure a “done” Sprint;
- Ending the Sprint Planning without a shared commitment on the Sprint plan and its goals;
- Canceling the Sprint Review because “there’s is nothing to demonstrate”;
- Canceling the Sprint Retrospective because “we don’t have enough time to improve”;
- Considering Backlog Refinement as a “meeting” that includes only the Product Owner and the “Lead Developer”.
Cause #5: Contracts Implying “We Don’t Trust You!”
The truly value-driven organization also embraces value-driven contracts. These are contracts that have a foundation built on transparency and trust. Such a contract stimulates effective partnerships and invites collaboration. A value-driven contract supports adapting new insights and processing gained knowledge. It encourages acting on necessary changes and lessons learned. A value-driven contract is lightweight and only contains the necessary agreements and constraints. A value-driven contract embraces the Agile mindset.
In reality, however, agreeing upon an Agile, value-driven contract is difficult. When the customer has a great idea, enthusiasm is high and possibilities are endless. We only have to agree upon the contract…
The difficulty with contracts is that it’s all about trust. If there’s enough mutual trust in each other’s capabilities, setting up a contract probably won’t be too difficult. But often the customer and supplier haven’t worked together before, therefore it lacks a proven foundation of trust. The customer wants guarantees around budget, time, quality, and scope. A decent change control process is lacking. After some tough negotiations, the development team starts but doesn’t truly collaborate with the customer and is just mechanically building what’s written in outdated requirements. A sub-optimal product, building an atmosphere of Zombie-Scrum, will be the result and the relationship and trust are damaged deeply.
Cause #6: The Smell of the Place
In organizations, it’s all about the context. This has a huge impact on the behavior of employees and largely determines the risk of Zombie Scrum. In the video “The Smell of the Place” professor Sumantra Ghoshal offers four examples of smells in organizations. The ones on the left describe “downtown Calcutta in mid-summer”, on the right is “Fontainebleau in spring”. In addition, I’ll share some smells that I have interpreted and experienced in organizations.
- Constraint versus Stretch
- Compliance versus Discipline
- Control versus Support
- Contract versus Trust
- Project versus Product
- Planning versus Prognoses
- Commitment versus Forecast
- Resources versus People
If the context of an organization has lots of smells that resemble “downtown Calcutta in mid-summer”; chances are Zombie-Scrum will occur. Therefore focus on the opposite of every smell and create “Fontainebleau in spring” in your organization!
Treating Zombie Scrum
So suppose you’re dealing with an infestation of Zombie Scrum. How do you deal with this? After countless experiments, we have come up with a few potential antidotes that might help:
Treatment #1: Become a Zombie-whisperer
You might not expect much out of a bunch of zombies, but simply talking to them may work wonders. Zombie Scrum Teams are rarely happy with their predicament. So a good start is to talk about their situation and identify potential causes and solutions. It also helps to talk about values and beliefs, and (when necessary) educate on the purposes of Scrum and the underlying values.
We would like to emphasize strongly that Zombie Scrum is not a team problem. Zombie Scrum is a manifestation of the disconnect between organizational values and Scrum values. The role of management cannot be understated here; they have to support and communicate the key values of Healthy Scrum in everything they do.
Treatment #2: Introduce Healthy Scrum into the population
Another way to combat Zombie Scrum is by introducing people into the population that can show and explain how Healthy Scrum works, and communicate the right values. Teams and organizations suffering from Zombie Scrum often feel that things aren’t working as well as they should, but are unaware of what’s causing this. There are many ways to do this. Take teams and management on a Scrum-safari in other companies, and show them how Scrum works there. Or hire employees with Scrum experience that can show how things are done. It can also help to bring in Agile coaches to help teams and management understand Scrum better, as long as their focus remains on helping the organization take care of things themselves as soon as possible.
Treatment #3: Shake things up (don’t continue the stumble)
You can shake things up by changing the way the team interacts within the Scrum framework, for example:
- Zombie Scrum teams often benefit from a shortened Sprint length. Instead of three to four-week iterations decrease the length to two weeks or even just one.
- Focus the Sprint Planning on answering the question of what type of impact the team would like to achieve within the upcoming Sprint.
- Start the Daily Scrum by reviewing the Sprint Goal and asking what achievements the team has made towards reaching that goal.
- Use the roadmap to provide context for the insights from the Review meeting. And for heaven’s sake, invite some real customers or stakeholders!
- Use the Retrospective not to drag out the same old problems but to dream big. A transformational approach might be better suited than an incremental one.
- Whatever you do, keep in mind that you can’t always save everybody. Some people are zombies by choice and the disease has already spread too far.
Treatment #4: Involve the broader Scrum Community
You are not alone in your fight against Zombie Scrum. With the ever-increasing adoption of Scrum, there is also an increasingly large community. Benefit from the community by asking for help from people with more experience. Visit local Scrum Meetups, use forums (like the one at Scrum.org) to ask for help, or invite fellow Scrum Masters to drop by. Or join The Liberators Network. This network is our way to help support you in your professional journey towards mastery and fighting Zombie Scrum. Our meetups focus on peer-to-peer coaching, building networks, and the sharing of experiences, lessons learned, and practices.
Treatment #5: Dare to Embrace Agile Contracting Principles
- Start small. Even when a customer has a huge budget for his project, first agree upon doing only one Sprint. After you’ve created and estimated the product vision and Product Backlog together, only do the first Sprint with the goal of delivering the first ‘done’, valuable, and potentially releasable increment. Perform a Sprint Review and Sprint Retrospective and decide if there’s enough mutual trust to start another Sprint.
- Sell/Buy the Entire Scrum Team. Fixed Scrum Teams that have been working together for a longer period, have experienced ups & downs, and know their velocity is worth gold. A common pitfall is to separate this ‘golden team’ when a new project arrives. Don’t do this. Keep the team together at all costs. The customers get the entire team, including the tester, analyst, designer, Scrum Master, developers, etc.
- Sell/Buy Sprints. When working with fixed teams that know their velocity, it’s also easier to sell sprints for this team. Of course, velocity is something for the team, it will take 3 -5 Sprints to discover and can vary with every product they build. However, a fixed, experienced team knows what they are capable of, can estimate a Product Backlog, and give a range of how many Sprints the realization will probably take, for example between 5–7 Sprints. Because the team is fixed they also know what the costs per sprint are, for example, 40.000,-. This means the necessary budget for this project will be between 200.000,- and 280.000,- During every Sprint Review, the Scrum Team and stakeholders can discuss the desired features that should be developed in the upcoming Sprint. They can discuss how much value they will get taking the cost per Sprint into account. By selling Sprints the advantage for the customer is the possibility of early termination of the contract. When the cost of continuing the project is higher than the additional value received, there is the possibility of just not buying any more Sprints.
Treatment #6: Setup a Smell-o-Meter
Changing people’s behaviour is not about changing people, but changing the context which they are in: the smell of the place. — Professor Sumantra Ghoshal
Make the smell of an organization “transparent” by setting up a smell-o-meter. My former colleague Wouter van der Meer wrote an excellent blog post about this idea.
By offering transparency about the smells everyone experiences in an organization you can act on it. An increase in negative smells might result in Zombie Scrum. Therefore everyone should continuously be aware of bad smalls and act on them immediately. This will ensure an organizational context that can resist Zombie Scrum to occur.
Closing
In this blog post, I’ve shared the highlights of Zombie Scrum as described by Christiaan Verwijs and Johannes Schartau. In addition to their original article, I’ve added some causes and treatments. Hopefully, this decreases the chances of a further Zombie Scrum outbreak! If you’ve got any other ideas on how to deal with Zombie Scrum, please share them!