Zombie Scrum: all the motions, none of the life

The events are on the calendar. The board is updated. There is a Product Owner, a Scrum Master and a Definition of Done on the wiki. Everyone attends. Nothing seems wrong, and nothing is happening. After the Sprint there is no working software that anyone uses. The Sprint Review is a presentation to people who say little. The Retrospective produces the same actions as last month. The team is going through the motions of a framework that is meant to produce learning and delivery, and it produces neither.

What the term means

The term Zombie Scrum comes from practitioners who studied hundreds of Scrum teams. They describe it as something that looks like Scrum from a distance, but is anything but on closer inspection. The symptoms they list are four: there is no working software after a Sprint, stakeholders are not involved, teams have little autonomy and nobody is trying to improve. They add that Zombie Scrum often starts when the purpose of Scrum is misunderstood in four key areas: shipping quickly, building what stakeholders need, continuous improvement and team autonomy.

It is related to Scrum-but but different. Scrum-but removes elements on purpose. Zombie Scrum keeps all the elements and lets them die. A team can run every event on time and be a zombie.

The symptoms against the Guide

Each symptom contradicts something the Guide asks.

No working software after a Sprint. The Guide says the moment an item meets the Definition of Done an Increment is born, that an Increment must be usable, and that Sprints are where ideas are turned into value. A Sprint that ends with work in progress and nothing releasable has missed the purpose.

Stakeholders absent. The Guide describes the Sprint Review as a working session where the team presents the results to key stakeholders and they collaborate on what to do next. If stakeholders do not come, or come and do not engage, there is no inspection of the outcome.

Little autonomy. The Guide says the Scrum Team is self-managing, deciding internally who does what, when and how, and is structured and empowered by the organisation to manage its own work. A team whose tasks are assigned from above and whose scope is fixed is managed, not self-managing.

No improvement. The Retrospective exists to plan ways to increase quality and effectiveness, and the Guide expects the most impactful improvements to be addressed as soon as possible. If the same issues return every time, the loop is broken.

The Guide's values give another angle. Where team members are not open about problems, do not use courage to raise tough ones and do not focus on the goal, the empirical pillars of transparency, inspection and adaptation do not come to life. Zombie Scrum is what is left when they don't.

How to recognise it

Signs you can see without surveys:

• The Sprint Goal is not remembered by the end of the Sprint, or does not exist.
• The Sprint Review is attended by the team and one manager.
• The Definition of Done is not met by half of the items accepted.
• Stories are carried over every Sprint.
• Retrospective actions are repeated.
• The Product Owner has not talked to a user for a month.
• The Scrum Master spends the time updating tools.
• Nobody is surprised by anything at the Review.
• People describe the events as "the meetings".
• Releases are separate from the Sprint, done by someone else.

A fast test: ask each team member, separately, "What did we learn this Sprint?" If the answers are blank, the loop is not running.

Why it happens

The purpose was never explained. The team was told to run events and not told what they were for.

Scrum was adopted by instruction. The team did not choose it, and treats it as an imposed process.

The organisation rewards the wrong things. If people are measured on tasks closed or utilisation, they will produce those.

No access to users or stakeholders. Without real feedback, the Review has nothing to inspect.

Fear. If bad news is punished, the team learns not to bring it.

The Scrum Master is a clerk. Tools and reports take the time that coaching should.

A fixed scope and date. The team's job is to deliver a specification, and there is nothing to learn.

Technical obstacles. If the code cannot be released, no Increment can exist.

A worked example

This is an illustrative team of seven. By every visible measure it is doing Scrum. Sprints run on time, the board is current and the Scrum Master produces a velocity chart.

In a Retrospective, a newly arrived Developer asks what the last Sprint Goal was. Nobody can say. She asks when a user last used something the team built. The answer is that releases happen quarterly, handled by another group. She asks who attends the Review. The team and the Product Owner's manager, who comes for ten minutes.

The Scrum Master takes this seriously and proposes small experiments. For the next Sprint, the team will write a Sprint Goal in one sentence and read it at each Daily Scrum. The Product Owner will invite two real users to the Review, and the team will show the working product and not slides. The Definition of Done will add "deployed to a test environment that the users can open".

In the first Review with users, a user says the form cannot be completed on a phone. The team had not tested on a phone. A Developer fixes it in two days. The user comes back to the following Review. The Retrospective produces its first action in months that someone finishes.

Nothing about the framework changed. Three small things brought information in from outside, and the loop began to turn.

Recovery: small experiments

The practitioners who coined the term recommend starting small and where it matters most, and propose experiments instead of solutions. A few that follow from the Guide:

1. Write and display a Sprint Goal. Read it at every Daily Scrum.
2. Get a real user to the next Review. Show the product and let them try it.
3. Release something small, soon. Even a minor change put in front of users makes feedback real.
4. Tighten the Definition of Done by one line that makes the Increment usable.
5. Fix one recurring Retrospective topic. Choose the oldest and finish it.
6. Ask "what did we learn?" at the end of each Sprint, and write the answer.
7. Let the team choose one thing about how it works that managers used to decide.
8. Count how long work waits and show the number.

Choose one or two. Run them for a Sprint and review. The aim is to restore contact with the outside world, since a zombie team is cut off from the things that tell it whether it is working.

What the Scrum Master can do

The Guide gives the Scrum Master the work of coaching the team in self-management, causing the removal of impediments and helping the organisation understand an empirical approach. In a zombie situation that means making the symptoms visible without blaming, proposing experiments and talking to the managers whose habits keep the team passive. See coaching the organisation.

How to practise it

Check your team against the four symptoms and write the evidence for each. Pick the weakest and run one experiment for a Sprint. In the simulator the Sprint Review brings stakeholder reaction to the Increment, and that contact with outsiders is what keeps a team alive.