Image for post
Image for post

Update: we wrote an entire book about this; the Zombie Scrum Survival Guide. Get your copy directly from us for some nice extras.

We got out by the skin of our teeth, I tell you! Crawling through vents, hiding behind Scrum Boards and pelleting them with post-its and whiteboard markers. But we got out in time, and we’re here to warn you. Because they are here, and their number is growing rapidly. Mindless, drooling herds of developers, testers, designers and others moaning ‘chaaaange’ and shambling around the building to all sorts of brainless Scrum-activities.

We (Johannes Schartau and Christiaan Verwijs) took it upon ourselves to write down what we have learned. By sharing this with you, we hope you will be able to identify teams that are starting to show symptoms and act accordingly. Let’s hope you don’t have to experience the horrors we did.

Symptoms of Zombie Scrum

The heart of a healthy Scrum Team beats in a sprint-staccato to produce a steady stream of valuable, completed and working software, ready for review with key stakeholders. Healthy Scrum Teams understand that working software is essential, because it is the single best way to test assumptions on time, technology, user expectations and what’s needed. This is different for Zombie Scrum Teams. They 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 most prevalent during the Sprint Review. Members hardly ever take the keyboard and mouse to click through a working application and demo what they’ve made. Instead, they have prepared PowerPoints, go through screenshots and release notes or simply talk about what was on the Sprint Backlog. If functionality is demo-ed, it is either very technical or annotated with comments like ‘We have to finish this (next sprint)’ or ‘Whoops, that isn’t working yet’. A more subtle indicator is the lack of discussion during the review. There are no opinions exchanged, suggestions raised or ideas discussed. Stakeholders are hardly ever present, or never at all. And the Product Owner always seems to be OK with everything. Instead of inspecting working software, the Sprint Review is mostly ‘ticking off boxes’. Boring, brainless and without much of a heart. And nobody seems to mind.

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 the more ‘done’ functionality is — the more it touches real users, real data and real hardware — the more useful the feedback will be for learning what (else) is needed. They 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. Instead of describing when functionality is actually ‘done’, it captures only technical aspects, such as ‘Committed to Version-Control’ or ‘Developer has clicked through it’. And who can blame them? This technical focus is usually a reflection of the functional silos that are still in place in the organisation. Testing is done by a Q&A-team, deployment is done by Operations and user feedback and writing support documentation is handled by Support. By keeping the traditional functional silos intact, there are many steps and hand-offs between what the team delivers (‘functionality that is technically done’) and when it touches real users, real data and real hardware. Therefore, a team will learn very little and very late about the effect of what they have made in the real world. And nobody seems to mind.

The third symptom is directly related to the previous one. Different from movie zombies who attack human beings to devour their flesh, 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! The app is causing memory leaks and makes the user’s computer unresponsive? QA should have caught that before deployment! A stakeholder wants one of those “cool Flash intros” and red marquee text on the landing page? I’m not a designer. Zombie Scrum teams see themselves as a cog in the wheel, unable and unwilling to change anything and have a real impact.

It’s old-fashioned silo-thinking and directly goes against the idea of cross-functional teams that have all the necessary competencies to get the work done without depending on others. Zombie Scrum teams want to depend on others in order to avoid taking responsibility. The idea of being directly involved in the design and validation of features is scary!

Symptom #3: No emotional response to success or failure

Symptom #4: No drive to improve

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, a lot of complaining (moaning). And certainly no desire to improve. The team shambles on, losing a limb here and there, and moaning like there’s no tomorrow.

Causes of Zombie Scrum

Cause #1: A bit too homegrown, or ‘Cargo Cult Scrum’

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). And what about the organisation that decided it was doing Scrum because it had renamed job titles; from ‘product manager’ to ‘product owner’, and from ‘project manager’ to ‘Scrum Master’, but failed to understand that ‘product owners’ should represent users and customers, while ‘scrum masters’ should not manage the team’s work.

This partial adoption of Scrum is often unintentional. Maybe someone heard or read something somewhere about Scrum, and applied only the part that they got. Or maybe an organisation decides to adopt only those parts that don’t require too much change. But by adopting only a part of Scrum, the actual benefits are lost, and the team will likely struggle. It’s like your girlfriend got infected with the zombie virus and has been slowly rotting away in the basement for a year. But then you decide to put her in a nice dress and take her to the ball, hoping nobody will notice what’s really going on. Or it’s like getting ready for bikini season by keeping your old habits but adding one salad a week.

Scrum is a collaborative process focussed on frequently delivering working software, so that we can test important assumptions about users (‘do people want this?’), about our collaboration (‘are we on the same page?’), about time and money (‘how much time will this take?’) and about technology (‘will this work?’). This is hard, and requires real change in the teams and their ecosystem. Superficial changes only result in ‘Cargo Cult Scrum’; we change the names, and use the Scrum-vocabulary, but we don’t really understand why. A sure-fire way to contract Zombie Scrum!

Cause #2: No urgency

Value is not about the CEO voicing his opinion. It’s about transparency regarding what is important and why. How do we know what’s important? How do we spread that information? Do we use abstract measurements like value points or do we use something specific like Cost of Delay? Great Scrum teams know that a little effort can go a long way and smartly prioritized that small effort can lead to huge payoffs. Due to the fogginess regarding value, mediocre Scrum Teams often have a hard time coming up with clear goals. We don’t see any clearly articulated Sprint Goals anywhere, they don’t tie into a goal-oriented Roadmap and there is no relationship to what’s important for the company. 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.

Paradoxically, however, we often find a fake sense of urgency in Zombie Scrum teams. The urgency is not caused by taking advantage of lucrative options but by someone screaming loudly. The team then switches to the headless chicken mode or becomes numb. Like a herd of zombies randomly moving in the direction of sounds that might indicate some yummy humans. A good sense of urgency comes from colleagues depending on each other for something that is clearly important for the company and the customers. A terrible sense of urgency comes from a fear of being yelled at.

The lack of urgency is also prevalent in an unwillingness to change how the organisation operates. Zombie Scrum treats Scrum as ‘a process for software development’, thereby limiting the application to only the ‘IT department’. But Healthy Scrum aims much higher, and tries to pull users and customers deeply into the development process. This necessarily touches many aspects of the organisation, from sales to marketing and from operations to support. Not because that’s what Scrum-hipsters like, but because that’s the best way to make sure that we’re building the right software for our customers.

Cause #3: Competing Values

Belief on Belief in Zombie Scrum Belief in Healthy Scrum Mindset A project mindset. Although every sprint can result in a new version, only the final version delivers real value A product mindset. Every sprint should result in a new version to maximize learning and value. Purpose of Scrum Scrum is a process that must be followed (for its own sake) Scrum allows us to ‘fail fast’ because of a steady stream of working software Working software Working software is a nice-to-have; we’re not going live at the end of a sprint anyways Working software is essential; even if we don’t go live at the end of a sprint, we learn most from it Definition of Done Done is what we can reasonably do at this moment, and have always done Done may be what we can reasonably do at this moment, but we should push onward Urgency There’s always a next sprint. Sprints are artificial timeboxes. A sprint is the longest allowed period between feedback opportunities Scope of change Scrum is a method for software development Scrum touches software development, sales, HR, support, marketing, etc. What is ‘work’? Writing code is work, everything else is a waste of time Writing code is an important part of work, but building good software requires frequent interaction with the team, stakeholders and peers. Distribution of responsibilities Individuals are made responsible (and rewarded) for particular areas Teams are made responsible (and rewarded) for particular areas Responsibilities within the team People feel responsible for their own contribution People feel responsible for what the team delivers Sense of control We have little or no control over what we do, and how. We have control over how we work as a team, or even beyond Customer focus Customers don’t know what they want, so we decide it for them Customer input is essential for building good software Business value Is implicit, and mostly unknown to Scrum Teams Should be explicit, and known by Scrum Teams Span of control Scrum Teams should focus on writing working code Scrum Teams should focus on analyzing requirements, writing working code, testing it, deploying it, and preferably even supporting it (whole cycle).

Treating Zombie Scrum

Treatment #1: Become a Zombie-whisperer

We would like to emphasize strongly that Zombie Scrum is not a team-problem. Zombie Scrum is a manifestation of the disconnect between organisational values and Scrum values. Although talking with Zombie Scrum Teams can work wonders, teams probably won’t be able to climb out of Zombie Scrum on their own. Broader interventions will be necessary. One way is to bring representatives from the teams and management together in frequent meet-ups to find solutions to problems that the teams can’t change on their own (like a group of zombie-fighting superheroes). 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

Treatment #3: Shake things up (don’t continue the stumble)

We’re dealing with a serious virus here, so it is possible you might have to lead for a while and take a step back from a pure coaching stance. Zombie Scrum Teams are often trapped and they need a guide to help them out. Limiting yourself to only raising awareness of issues without making progress doesn’t necessarily help. Potentially, it could even increase the general sense of resignation and numbness. Just keep in mind to relinquish control as fast as possible after the symptoms have improved so you don’t simply create a horde of zombie followers.

Your interventions will most likely have to be aimed at breaking the monotony. Don’t focus on what’s not working, look at what possibilities for improvement there are instead. 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

But this goes both ways. We strongly feel that part of the responsibility for the proliferation of Zombie Scrum lies with the Scrum Community itself. With the recent focus on scaling Scrum and enterprise adoption, combined with the growing number of parties with vested commercial interests in selling Scrum trainings, coaching and certifications, we feel that the purpose (or the beating heart) of Scrum and Agile are increasingly pushed to the background. The key question to ask is not ‘How do we scale Scrum to 20 teams’ or ‘How do we transition this company to Scrum as quickly as possible?’. Instead, the focus should lie on: ‘How can we deliver more working software every sprint’. If the heart does not start beating at the level of individual teams, everything else will just be a lifeless husk. Zombie Scrum in optima forma.

Image for post
Image for post
Order your book directly from us for some nice extras.

Written by

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store