What is Zombie Scrum?

Zombie Scrum – the soulless application of Scrum without heart

Zombie Scrum is a term used to describe a dysfunctional implementation of Scrum in which the formal structures and processes of Scrum are retained, but the actual purpose and values of Scrum are no longer fulfilled. It looks like Scrum, but it is not Scrum. The heartbeat is missing – like a zombie.

Scrum is based on 5 values:

• commitment
• courage
• openness
• focus
• respect

The team’s commitment to achieving the agreed sprint goal, the commitment to quality, learning and doing your best together is crucial for collaboration and building an agile culture.

Courage is important for the team’s success because it is about trying out new things, admitting mistakes, asking for help when necessary, saying “no” to some requirements and questioning the status quo when necessary.

Openness is the basis for a learning culture, for feedback and new ideas. Openness as a value enables well-founded decisions, increases efficiency and creates trust.

Focus helps the team to concentrate on the important things – e.g. through tools such as timeboxing, definition of ready or definition of done. The Scrum Master tries to keep disruptive influences away from the developers and the Product Owner concentrates on the “why” and “what”, but not on the “how”.

Respect as a value is essential for collaboration between those involved. The ideas, views and achievements of others must be respected. Respect is a central building block for successful and productive development.

In Zombie Scrum, individual values or even all values are not practised. This quickly leads to a number of problems: The flexibility and adaptability of the team decreases, transparency within the team and towards the customer gradually declines, and the culture of continuous improvement suffers. Dissatisfaction within the team increases, product quality decreases and there is a risk of staff turnover.

Some symptoms of Zombie Scrum

The term Zombie Scrum goes back to Christiaan Verwijs, Johannes Schartau and Barry Overeem, who name symptoms and possible solutions in The Zombie Scrum Survival Guide¹. In their view, Scrum is primarily about building what stakeholders need, producing verifiable results as quickly as possible, continuously improving and organising as a team towards a common goal. The symptoms of Zombie Scrum manifest themselves in the following key characteristics:

1. there is no desire for contact with the outside world.

Teams isolate themselves. They only focus on their specific task without considering the overall context or the needs of the stakeholders. They often feel like cogs in a wheel, unable and unwilling to make a difference or have any real influence. In traditional organisations, teams often work in silos, producing products that work but may not meet actual customer needs. This leads to a significant waste of resources and results in mediocre products of questionable value.

2. no working increments exist.

Zombie Scrum teams follow the Scrum rules but only deliver the product at the end of development or after many sprints. Stakeholders rarely have the opportunity to review the product created by the development team. In addition, the team has a very limited definition of “done” and shows little motivation to expand it

3. the team has no motivation to improve the way they work.

Zombie scrum teams do not react to either a failed or a successful sprint. Instead of swearing or rejoicing, they show a numb resignation. Team morale is low. Items from the sprint backlog are simply moved to the next sprint without consultation. And why not? From their point of view, there is always a next sprint and the sprint goals and sprint content are arbitrary anyway.

4. the team is not autonomous and takes no responsibility.

Zombie scrum teams are inflexible in working with those they need to develop a great product. They are not free to choose their tools, nor can they make important decisions about their own product. They have to ask permission for almost everything, and their requests are often turned down. This lack of autonomy leads to a lack of responsibility. Why should they care about the success of a product if they are not really involved in its development?

Differences between Scrumbut, Scrumand and Zombie Scrum

The abandonment of individual elements in Scrum (events, responsibilities or artefacts), and thus the deviation from the standard as described in the Scrum Guide, is referred to as Scrumbut. The term is derived from “We use Scrum, but …”, which means “We use Scrum, but …”. The basic rules and principles of Scrum are understood, but Scrum is not fully implemented due to exceptions or restrictions in the organisation. Example: “We use Scrum, but we don’t have fixed sprints”.

A Scrumand describes a situation in which additional processes or frameworks are added to Scrum that are not necessarily in line with the actual elements. The expression is derived from “We use Scrum and …”, i.e. “We use Scrum and …”, e.g. “We use Scrum and also meet once a week for the Weekly Meeting”.

Zombie Scrum describes a situation in which the formal structures of Scrum are retained, but the values and principles of Scrum are no longer adhered to. In contrast to the other two forms, this is not a case of omitting individual elements or adding extras, but rather a situation in which the participants would prefer to escape reality.

Tips against Zombie Scrum

Tips against Zombie Scrum often include advice such as

• the restoration of agility,
• promoting personal responsibility and self-organisation within the team,
• integrating customer feedback into the development process and
• promoting a culture of continuous improvement.

In practice, however, much of this advice often falls flat, as Zombie Scrum often reflects deeper problems in organisational culture, management practices or team dynamics that cannot simply be fixed by superficial changes.²

Sorry that we cannot present any simple, universally applicable tips here.

Impulse to discuss:

Are there early warning signs that can serve as indicators for the emergence or presence of Zombie Scrum?

Notes:

[1] Zombie Scrum Survival Guide
[2] Heiko Bartlog has a blog series on the topic of Agility? We tried it! Does not work! Anyone interested in stumbling blocks and solutions for agile working, without expecting a universal solution, will have a great time!

Our Scrum Whitepaper explains how Scrum should work.

You are welcome to share or link to the content on this page.

Here you can find additional information from our t2informatik Blog: