This post is an excerpt from the book that we’re writing, the ‘Zombie Scrum Survival Guide’. It’s our way of delivering small increments and involving our stakeholders: you, the reader. So we’d love to hear your feedback, encouragements, and wild ideas.
The Scrum Framework was developed by Ken Schwaber and Jeff Sutherland in the 1990s and first formalized in 1995 to address the inherent complexity of product and software development. More recently, the Scrum Framework is being applied successfully to complex problems in a wide variety of domains, like marketing, organizational change, and scientific research. The Scrum Framework is built on three pillars that allow empirical control:
- Transparency: you gather data — like metrics, feedback, and other experiences — to find out what is going on;
- Inspection: you inspect the progress with everyone involved and decide what that means for your ambitions;
- Adaptation: you make changes that you hope will bring you closer to your ambitions;
The short cycles of creating transparency, inspecting the outcomes, and adapting what else is needed.
This cycle repeats as frequently as necessary to catch deviations, unexpected discoveries, and potential opportunities that emerge as the work is done. It happens not once a year or when the project is completed, but continuously on a daily, weekly, and/or monthly basis. Rather than basing our decisions on risky assumptions about potential futures that will probably never unfold, we’re instead making decisions based on the data we’ve collected up to this point. This is empiricism. Everything in the Scrum Framework is designed around these three pillars.
“The cycle of transparency, inspection, and adaptation, repeats as frequently as necessary to catch deviations, unexpected discoveries and potential opportunities that emerge as the work is done.”
What is Made Possible by the Scrum Framework
The empirical approach that the Scrum Framework offers becomes tremendously useful when you accept that you don’t know and can’t control everything. Because of that, your understanding of what is necessary will change, you will make mistakes and new and valuable insights will emerge that you never considered initially. Instead of making a precise plan upfront and then sticking to it no matter what, you can treat the ideas you have as assumptions or hypotheses that you validate through working with the Scrum Framework.
The Scrum Framework allows you to learn whether you’re off track and need to make adjustments much sooner than when you’re simply following a plan. Instead of going all-in on one solution, you’re now able to tackle the biggest risk you’re facing first.
This is especially important when you’re operating in an uncertain, changing environment. Assumptions you may have had at the beginning may have been absolutely correct at that time. But while you’re developing your product, the context may shift so much that your whole approach flies out of the window. Instead of catastrophic failure at the end of a long project, an empirical approach reduces that to a minor speed bump that requires you to correct the course a bit.
So if anything, the Scrum Framework reduces the risk of the inherent unpredictability and uncertainty of complex, adaptive problems. It allows you to continuously verify that you’re still doing the right things and moving towards solving the problem you set out to solve. Even better is that you now have a process that actively encourages the discovery of even better ideas and to include them in shaping the next steps. Now, uncertainty becomes an asset because of all the underlying possibilities within it.
“The Scrum Framework reduces the risk of the inherent unpredictability and uncertainty of complex, adaptive problems.”
Zombie Scrum and the Efficiency Mindset
So where does Zombie Scrum connect to all this? One clear theme we’ve found is that people use the Scrum Framework for the wrong reasons. When you ask people in a Zombie Scrum organization what they are hoping to get out of Scrum, you’ll hear things like “more speed”, “more brains”, “more output” and “more efficiency”. That’s very different from the actual meaning of the word “agile”. It’s also very different from what the Scrum Framework is designed for. Where does this contradiction come from?
The traditional ways of managing organizations and product development are designed to achieve the opposite of agility. This mental model is often called the “Efficiency Mindset”. A full history of the efficiency mindset is beyond the scope of this book. Suffice to say that its aim is to reduce uncertainty as much as possible, increase predictability and drive efficiency. This usually manifests in detailed plans for upcoming work, the standardization of work through protocols and procedures, a high degree of task specialization, and measuring efficiency (like units of work per day, errors). This mindset can certainly work in environments where work is fairly repetitive and simple, like assembly lines or certain administrative work, it certainly doesn’t work in environments where people deal with complex, adaptive problems that are inherently unpredictable and uncertain.
“The aim of the Efficiency Mindset is to reduce uncertainty as much as possible, increase predictability and drive efficiency.”
Looking at the wrong things? Zombie Scrum goes hand-in-hand with a strong focus on performance and how much work is done. But are customers happy? Is valuable delivered?
And yet, this mental model is so ingrained that it’s effectively invisible. It has become “the truth” that we obviously don’t need to discuss. This mindset completely shapes the way we design organizations, structure interactions, and build our culture. When you look at the Scrum Framework from this perspective, it makes sense that people try to understand it in terms of how it impacts efficiency, speed, and output. Only to be disappointed when Scrum doesn’t seem to do that.
In a very broad sense, the Scrum Framework is more concerned with being effective than being efficient. Where efficiency is about getting as much work done as possible (the output), effectiveness is about the value and usefulness of that work (the outcome). Although it is entirely possible that efficiency improves with the Scrum Framework, it is neither a promise nor a goal.
In environments rife with Zombie Scrum, the “Efficiency Mindset” is so strong that people only see the structural elements of the Scrum Framework; the roles, events, and artifacts. They don’t see nor appreciate the value of the empirical process underneath. And that is why Zombie Scrum only looks like Scrum, but without the beating heart of empiricism.
“The Scrum Framework is more concerned with being effective (outcome) than being efficient (output).”
Closing
In this article, we explained how the cycle of transparency, inspection, and adaptation, repeats as frequently as necessary to catch deviations, unexpected discoveries, and potential opportunities that emerge as the work is done. Everything in the Scrum Framework is designed around these three pillars. It’s what makes empiricism work. Organizations with Zombie Scrum, often have an efficiency mindset with the goal to reduce uncertainty as much as possible, increase predictability and drive efficiency. This contradicts the empirical process of learning & discovering while doing complex work.
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.
Get the book
Order your book directly from us for some nice extras.