Last week, I had the privilege to facilitate the Zombie Scrum workshop with Christiaan Verwijs. Together with Johannes Schartau, Christiaan created the Zombie Scrum workshop with a goal of calling attention to the alarming condition of Scrum in many organizations. In the article The Rise of Zombie Scrum, Johannes and Christiaan provide a comprehensive description of the symptoms, causes, and treatment of Zombie Scrum. In this 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 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 forgot about 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 are as follows.
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. 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?
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.
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!
4. No Drive to Improve
In Zombie Scrum, there’s no joy, and certainly, no drive for improvement — and nobody really seems to care. 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. 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 here is the lack of control a team experiences over their own success. This easily translates into boring retrospectives, a lot of complaining (moaning), and certainly, no desire to improve.
Given all of the symptoms of Zombie Scrum, what are the actual causes?
1. A Bit Too Homegrown (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.
However, 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.
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 value, mediocre Scrum Teams often have a hard time coming up with clear goals. Without goals, there’s simply no reason for urgency. That causes Zombie Scrum, as shared goals are the glue for any team and provide them with purpose and motivation.
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.
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 on 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,” including:
- Allowing the tester to fulfill the Scrum Master role four 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 to 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.
5. Contracts Implying “We Don’t Trust You!”
True value-driven organizations also embrace value-driven contracts. These are contracts that have a foundation build on transparency and trust. Such a contract stimulates effective partnerships and invites collaboration. A value-driven contract supports adopting 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. However, often, the customer and supplier haven’t worked together before and lack 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 suboptimal product, built in the atmosphere of Zombie Scrum, will be the result and the relationship and trust will be damaged deeply.
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 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,” and 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 with “downtown Calcutta in mid-summer,” chances are that Zombie Scrum will occur. Therefore, focus on the opposite of every smell and create “Fontainebleau in spring” in your organization!
If you’re dealing with an infestation of Zombie Scrum, how do you deal with it? After countless experiments, we have come up with a few potential antidotes that might help.
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.
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 unaware as to 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.
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 whattype 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.
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 help from people with more experience. Visit local Agile or Scrum Meetups. Use forums (like the one at Scrum.org) or Facebook to ask for help or invite fellow Scrum Masters or Agile Coaches to drop by. Or, send an email to bloggers like us; we’re happy to help!
5. Dare to Embrace Agile Contracting Principles
Even when a customer has a huge budget for the 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 and Buy the Entire Scrum Team
Fixed Scrum Teams who have been working together for a longer period, have experienced ups and downs, and who know their velocity are 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 testers, analysts, designers, Scrum Masters, developers, etc.
Sell and Buy Sprints
When working with fixed teams who know their velocity, it’s also easier to sell Sprints for this team. Of course, velocity is something for the team, will take three to five Sprints to discover and can vary with every product they build. However, a fixed, experienced team knows what they are capable of and can estimate a Product Backlog and give a range of how much 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 the upcoming Sprint. They can discuss how much value the 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.
6. Set Up a Smell-o-Meter
Changing people’s behavior is not about changing people, but changing the context which they are in: the smell of the place. — Prof. Goshal
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 of negative smells might result in Zombie Scrum. Therefore, everyone should continuously be aware of bad smells and act on them immediately. This will ensure an organizational context that can resist Zombie Scrum to occur.
In this 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!