This 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 the goal to call attention to the alarming condition of Scrum in many organisations. In the article "The Rise of Zombie Scrum" Johannes and Christiaan provide an 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.
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 potential releasable increment is rarely the result of a Sprint. The team also don't have any intention to improve their situation. Actually nobody cares about this team. The stakeholders have forgotten the existence of this team long time ago.
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?
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.
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!
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 (specialised) 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, a lot of complaining (moaning). And certainly no desire to improve.
Homegrown Scrum is great. That is; teams and organisations 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 home-grown. 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.
We often witness a lack of urgency in Scrum Teams, usually caused by a lack of urgency in the rest of the organisation. 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 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. And that in turn causes Zombie Scrum, as shared goals are the glue for any team and provide them with purpose and motivation.
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 organisation hold beliefs about software development that collide with what drives Agile software development. To give you some examples:
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 organisation. Therefore some changes to the already lightweight Scrum Framework were "necessary":
Truly value-driven organisation also embraces 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 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 suboptimal product, build in atmosphere of Zombie-Scrum, will be the result and the relationship and trust is damaged deeply.
In organisations, it's all about the context. This has a huge impact on the behaviour 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 organisations. 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 organisations.
If the context of an organisation has lot's of smells that resemble with "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 organisation!
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:
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 emphasise strongly that Zombie Scrum is not a team-problem. Zombie Scrum is a manifestation of the disconnect between organisational 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.
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 organisations 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 organisation take care of things themselves as soon as possible.
You can shake things up by changing the way the team interacts within the Scrum framework, for example:
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.
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!
Make the smell of an organisation "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 organisation you can act on it. An increase of 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 organisational context that can resist Zombie Scrum to occur.
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!
If you want us to help your organisation prevent or fight Zombie-Scrum: just contact Christiaan, Johannes or myself. We provide coaching, training and workshops to deal with this alarming outbreak of Zombie Scrum. Not all is lost, but we must be brave and act courageous!
Knowing what causes Zombie Scrum might help prevent a further outbreak of this terrible evolution
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 potential releasable increment is rarely the result of a Sprint. The team also don't have any intention to improve their situation. Actually nobody cares about this team. The stakeholders have forgotten the existence of this team 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 (specialised) 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, a lot of complaining (moaning). And certainly no desire to improve.
The Causes of Zombie Scrum
Cause #1: A bit too homegrown, or ‘Cargo Cult Scrum’
Homegrown Scrum is great. That is; teams and organisations 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 home-grown. 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 organisation. 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 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. 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 organisation 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 a 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 on deliberately. Doing Scrum by the book was too difficult. It caused too much pain within the organisation. Therefore some changes to the already lightweight Scrum Framework were "necessary":
- Allowing the tester to fulfil the Scrum Master role 4 hours per week. Sharing the weekly status report with the management shouldn't take more time;
- Extending the Sprint with a couple of days to ensure a “done” Sprint;
- Ending the Sprint Planning without a shared commitment on the Sprint plan and its goals;
- Cancelling the Sprint Review because “there’s is nothing to demonstrate”;
- Cancelling 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!"
Truly value-driven organisation also embraces 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 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 suboptimal product, build in atmosphere of Zombie-Scrum, will be the result and the relationship and trust is damaged deeply.
Cause #6: The Smell of the Place
In organisations, it's all about the context. This has a huge impact on the behaviour 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 organisations. 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 organisations.
- 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 organisation has lot's of smells that resemble with "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 organisation!
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 emphasise strongly that Zombie Scrum is not a team-problem. Zombie Scrum is a manifestation of the disconnect between organisational 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 organisations 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 organisation 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 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 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!
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 up’s & down’s and know there 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 gets the entire team, including tester, analist, 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, 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 much Sprints the realisation 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.
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. - Prof. Goshal
Make the smell of an organisation "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 organisation you can act on it. An increase of 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 organisational 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!
If you want us to help your organisation prevent or fight Zombie-Scrum: just contact Christiaan, Johannes or myself. We provide coaching, training and workshops to deal with this alarming outbreak of Zombie Scrum. Not all is lost, but we must be brave and act courageous!