The Rise Of Zombie Scrum
Symptoms, causes and what you can do about it
Our book, the Zombie Scrum Survival Guide, is out! Order your copy here.
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. So far we’ve received a lot of help, but in particular from Barry Overeem (with this post). 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.
Want to stay informed on our progress? Join the Zombie Scrum Resistance. You can find more articles, posts, and inspiration there.
Symptoms of Zombie Scrum
Symptom #1: No beating heart
The problem with zombies is that they appear to be human in that dark alley until you get a bit closer. That’s when you notice that they are not really alive. Zombie Scrum is similar, in that it appears to be Scrum on the surface. Except there’s no beating heart.
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.
Symptom #2: No (desire for) contact with the outside world
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
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! Since items on the Sprint Backlog are not tied to any specific Sprint goal they can be completed whenever the team feels like it. And thus continues the aimless trudge through a barren wasteland of software development. No signposts, no direction, no alignment. Walking at a snail’s pace into the sunset without showing any emotions.
Symptom #4: No drive to improve
In “The Walking Dead”, zombies are the epitome of brainlessness, moving along because that’s what they always did. This lifeless procession is accompanied by a moody ambiance of moans and clacking teeth. Although a bit less dramatic, Zombie Scrum really isn’t all that different. Like their movie counterparts, teams go through the motions of Scrum. Yes, there are sprints (although the results are limited, see symptoms #1, #2 and #3) and the Scrum events do take place. But there’s no joy, and certainly no drive for improvement (symptom #4). 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 (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
Scrum is big, there’s no doubt about that. But the increasing population of Scrum Teams is also giving rise to an equal increase in the incidence of Zombie Scrum. And although they won’t chomp of your arm, take a bite out of the intern or start gnawing at the Scrum Master any time soon, we want for nothing more than to help these teams experience what Scrum is actually like. But before identifying remedies and antidotes, we need to know more about how Scrum devolves into Zombie Scrum. We’ve identified a few:
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). 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
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 value is its lifeblood.
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
We have already alluded to this in the previous points, but 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. One of the difficulties here is that these beliefs are rarely openly discussed. They are deeply-held, often subconsciously, and shared as part of the organisation’s culture. Considering the fogginess surrounding this topic, and to summarize what we’ve written before, we thought it best to give you some examples:
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. One way to identify causes is by asking the opposite question; ‘How can we make the team even more Zombi-fied?’. It also helps to talk about values and beliefs, and (when necessary) educate on the purposes of Scrum and the underlying values. A game like ‘Circles & Soup’ can help teams regain a sense of control, by focussing on what they can change rather than what they can’t.
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
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 won’t cure Zombie Scrum by playing to the regular rules. Your intervention will most likely depend on a wide variety of tools, similar to the assortment of tools found in an abandoned farmhouse that you can use to fight zombies. Since the causes of Zombie Scrum can be manifold, you might want to try several approaches to see which lead to success.
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 of 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!
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 training, 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.
Closing thoughts
Zombie Scrum is here. And we’re not proud of it. But thankfully we can do something about it, and we hope we inspired you to do the same with this post! We’re looking forward to your ideas, your help, and your thoughts.
Diagnose Your Scrum Team
Are you curious to learn if your organization and team are infected by Zombie Scrum? Why don’t you give the Zombie Scrum Symptoms Checker a try? It’s completely free and anonymous and offers your team a profile that helps you identify the areas for improvement.
