Why Zombie Scrum Teams Don’t Self-Organize Around Challenges

Summary : Self-organization is a concept that is central to the Scrum Framework. For all its significance, it is remarkably hard to define. It is often confused with “self-management”, or the idea that teams should make their own decisions.

Self-organization is a concept that is central to the Scrum Framework. For all its significance, it is remarkably hard to define. It is often confused with “self-management”, or the idea that teams should make their own decisions. Instead, self-organization is the process by which order arises spontaneously from something that is initially disorganized (Camazine, 2001). This distinction may seem trivial, but it helps us understand two essential truths about Scrum. The first is how it uses self-organization to act as a lever to make organizations more agile. The second is how Scrum Teams require a high degree of self-management to make that lever work.

Image for post

Unfortunately, we’ve found that many Scrum Teams struggle to self-organize at all. And that easily leads to Zombie Scrum: something that may look like Scrum from a distance but lacks the beating heart. In this post, we address one common reason for this: the (forced) use of off-the-shelf solutions and best practices.

Signs to watch for

People say things like “Let’s not reinvent the wheel”.
External experts are hired to implement their best-practices or “roll-out” change initiatives that were planned without concerted involvement of employees.
Approaches that worked for other organizations are copied onto the entire organization without trying them in one small area first.
You don’t get a clear answer when you ask people what problem they are trying to solve with an external framework or solution (e.g. SAFe, LESS, Spotify-model).

In Zombie Scrum, We Use Off-The-Shelf Solutions

Organizations that suffer from Zombie Scrum like to follow standardized methods, well-defined frameworks, and industry best practices. To them, this feels more efficient than developing their own approaches. They believe that they are learning from the experiences of others, as in the case when organizations implement the “Spotify Model” in the hope of replicating Spotify’s top-notch engineering culture. But there are three big problems with “copying” from others like this:

Copying what works for one organization completely ignores the unique circumstances that enabled the solution to work for that other organization. For example, Spotify has a completely different culture and the environment from the banks and insurance companies that try to copy its “model”; what works for Spotify may be completely wrong for other organizations.
The very nature of complex systems means that there are no “models” or best practices. Organizations like Spotify are in a constant state of flux as double-loop learning and self-organization continuously reshape how people work together. Although you can take a snapshot of what Spotify looks like at a given moment in time and copy its roles, structure, and rules to your own organization, the actual model at work here is not its structure but its focus on learning and self-organization. In fact, Spotify went out of its way to show that its structure always changes and shouldn’t be copied.
Copying best practices from other organizations effectively sidestep the double-loop learning and self-organization that gave rise to those recipes in the first place. By simply copying the (supposed) result, organizations never develop the ability to learn that is essential to solving complex challenges. It actually impedes self-organization and double-loop learning as predefined solutions from elsewhere are rolled-out across the organization.

The example of Spotify is an obvious one, but the same argument applies to other attempts to copy best-practices from elsewhere. It also applies to scaling frameworks that emphasize a particular structural solution for scaling over double-loop learning and self-organization.

You can certainly find inspiration in solutions from other organizations. But instead of jumping straight to replicate their recipes, it’s more helpful to create environments where people can learn and fail. Don’t copy the plant, copy the soil it grew from. To create environments where people are encouraged to explore why a problem exists, where they have autonomy over their work and where they can experiment with different approaches. This is where double-loop learning starts and when all sorts of wildly creative solutions start emerging from self-organization.

What else?

Aside from the use of off-the-shelf solutions, there are many other reasons why Zombie Scrum Teams don’t self-organize around challenges. Here is a brief overview of some of the other reasons we’ve found. We cover these, and others, in more detail in our book, The Zombie Scrum Survival Guide.

Cause #2: Scrum Teams Are Not Self-Managing Enough

It is difficult for Scrum Teams to self-organize around shared challenges if their ability to self-manage their work is limited. In organizations that suffer from Zombie Scrum, most or all of the areas tilt towards “No autonomy at all”. Instead of being able to make decisions about their own work, when and by whom it should be done, others make those decisions for them, approval is needed first, or adherence to existing standards or “the way we do things here” is required.

Cause #5: Scrum Teams Don’t Have Goals Or They Are Imposed

Provided they have sufficient autonomy, teams, and people go in many different directions when there are no clear goals to direct self-organization. This is what often happens in Zombie Scrum, and can be a huge source of frustration to everyone involved.

Cause #7: Scrum Teams Are Impeded By Organization

In environments with high degrees of standardization, Scrum Teams are constrained in their ability to develop local solutions in response to what is happening in their immediate environment. When the standardized solution, tool, structure, or practice doesn’t work well in response to changes in their environment, it impacts the team or even the entire organization. It makes the whole system decidedly more fragile against sudden change.

Closing Thoughts

In this post, we explored how self-organization is often impeded by the introduction of “best practices” and other off-the-shelf solutions that are pulled in by teams and management. Although done with the best intentions, it robs Scrum Teams of their autonomy to come up with their own solutions. We also explored some other reasons why self-organization is often lacking.
We’d love to hear about your experiences with this. What are the things you’ve tried? What are other reasons you have found?