In December 2020, Johannes Schartau, Christiaan Verwijs, and I published the Zombie Scrum Survival Guide. We wrote it to help readers understand why Scrum so often descends into Zombie Scrum and to offer practical and down-to-earth help. Zombie Scrum isn’t something you fix with one simple experiment. The deeper it’s ingrained in your organization, the more effort it takes to resolve. So, about 6 months after the book was released, we wanted to check what progress our community is making with putting the experiments we describe in our book, into practice. What are the success stories they’ve experienced with fighting Zombie Scrum? What happened? What did Zombie Scrum look like and how did they manage to improve the situation?
To find an answer to these questions we organized a public meetup in The Liberators Network. Together with 40 participants, we used the Liberating Structure “Drawing Together” to visualize everyone’s individual Scrum journey, and “Appreciative Interviews” to identify and share success stories. In this blog post, we share the 10 success factors that stood out the most. Factors that helped our community to use Scrum more effectively within their team and organization. Although these ideas aren’t mind-blowing and earth-shattering, it’s what helped *real* Scrum practitioners resolve Zombie Scrum. Use it as a source of inspiration to improve Scrum in your organization!
Below you’ll find 10 success factors that emerged from our community meetup. These aren’t the 10 ultimate factors to fight Zombie Scrum, because every team and organization is different and needs a tailor-made approach. Yet these factors proved to be clear patterns in the stories the 40 participants shared, so there must be some truth in it :)
1. Make the Scrum events goal-oriented
The Product- and Sprint Goal are two of the most powerful parts of the Scrum framework. Together, they give meaning to the work of the Scrum team and provide a single goal to collaborate around and focus on. If a team struggles with using a Product- or Sprint Goal, it’s often a symptom of a deeper problem. For example, they work on too many different products, are not really cross-functional, or don’t have a Product Owner who provides a clear direction.
Many of our community members moved in the direction of more effective Scrum to put a laser-sharp focus on setting goals. Especially during the Scrum events. During the Sprint Planning, they defined the Sprint Goal. In the beginning, this was tough and they ended up with multiple goals, but slowly they could change it into one goal for the entire team. By having a Sprint Goal, the Daily Scrum became way more focused as well. Instead of sharing all the work everyone has done, they only shared the progress they’ve made to achieve the goal. During the Sprint Review, everyone inspected the improved increment, discussed the progress towards the Product Goal, and already shared ideas on the next Sprint Goal. For many, this wasn’t an easy journey, but goal-oriented Scrum events proved to be key in moving away from Zombie Scrum.
2. Try to increase psychological safety
Psychological safety is one of the most important contributors to successful teams. Amy Edmondson defines psychological safety as “a shared belief about the consequences of interpersonal risk-taking”. It’s not at odds with having tough conversations, it is what allows teams to have tough conversations. Psychological safety is not about always agreeing with each other, or about giving compliments all the time. It is much more about encouraging people to speak up when they have worries, uncertainties, or doubts.
During the meetup, someone shared a story of how they used the Liberating Structure “Heard, Seen, Respected” to increase psychological safety. This Liberating Structure is all about building empathy and compassion. It does so by inviting the participants to share a story of a time when they felt not heard, seen, or respected. But also by inviting everyone to actively listen to the story of another person. People who participate in ‘Heard, Seen, Respected’ often reflect on the power of silence while also acknowledging how difficult it is to only listen. Teams that create an environment where everyone is heard, seen, and respected, also often lack fertile ground for Zombie Scrum to take root.
Use the Liberating Structure “Heard, Seen, Respected” to increase psychological safety.
3. Leave Scrum for Kanban, or use Scrum with Kanban
Scrum is a framework for developing and sustaining complex products. It helps teams to manage risk and deliver value to their stakeholders sooner. The framework offers five repeating events to work on three artifacts, three accountabilities to support this plus several principles & rules to glue this together into a cohesive whole. Because it’s a framework, you can use it as a “frame” to “work” on a wide variety of complex problems, projects, and products.
But still, not every team likes the rhythm of Sprints. For some teams, it makes more sense to focus on “flow” and as such use Kanban instead. The Kanban Guide describes Kanban as “a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system.” Other teams discovered that using Scrum according to the Scrum Guide and complete it with Kanban practices works best for them. Whatever you choose, if you’re stuck with Zombie Scrum, this might also be because Scrum isn’t suitable for you. Start experimenting, and see what framework, methodology, or process helps you manage risk and deliver value.
4. Create more engaging Scrum events
When explaining the Scrum events, I always emphasize the ‘event’-part. The Scrum framework doesn’t contain 4 boring meetings (with the Sprint as the fifth container event), it offers you 4 lively events. The team should use them as moments to get actual work done, together! Events that help to create a plan for the upcoming Sprint (Sprint Planning), to inspect the progress towards the Sprint Goal (Daily Scrum), to identify improvements (Sprint Retrospective), and to gather feedback from stakeholders (Sprint Review).
For many members of our community, the Scrum events turned into meetings in which everyone turned into a zombie going through the motions in a mechanical, lifeless manner. Meetings people tried to skip or cancel because it was a waste of time. To create more engaging Scrum events, the 33 Liberating Structures proved to be a valuable source of inspiration. They helped to spice up the events and to involve & engage everyone again. It goes beyond the scope of this blog post to share all examples. Check this series of articles on how to combine Scrum with Liberating Structures.
5. Make Scrum a choice of the teams themselves
As a team, there are basically two ways to get started with Scrum. One: someone from outside the team encouraged (or enforced) them to try Scrum. Two: the team itself decided to give Scrum a try. Both approaches can work. Although I don’t believe in enforcing a way of working on a team, it does have advantages if e.g. management encourages the team to try Scrum. One of the key advantages is that lack of management support probably isn’t an issue. If it’s their suggestion to use Scrum, chances are they’ll also more actively help to resolve impediments for the team.
Great Scrum Teams use Scrum as a mirror for self-reflection.
Yet a pattern that emerged from the stories by our community members, is that the most successful teams had the freedom to choose the framework they preferred. Or to tweak it in such a way it suits them best. However, the urge to change how to use the Scrum framework can also have its roots in organizational dysfunctions. The best teams challenged each other and their environment and used Scrum as a mirror. The need to make adaptations to the framework was used as a critical moment for self-reflection. But whatever they decided, because the team took ownership of their way of working, they also had the freedom to make any adjustments.
6. Create a safe space for experimentation
Scrum thrives in environments with a high degree of complexity. The more complex a problem is the organization faces, the more important it is to use an empirical approach. Due to the nature of complexity, the outcome is something you can’t predict. For example, when developing a software product, it’s impossible to predict upfront what features will be most valued and how much time it takes to create them.
As a Scrum team, you’ll do many other assumptions as well. Assumptions about the product features, planning, budget, time, collaboration, risks, dependencies, skills, team dynamics, etc. The only way to validate all these assumptions is to conduct small experiments. In organizations with a high degree of Zombie Scrum, experiments are not encouraged. We’ve heard stories where organizations didn’t want too much experimentation because it gave the impression the outcome was unknown… Other organizations acknowledged the unknown factors and used Scrum as leverage to discover the answers together. They created an environment where doing small experiments was encouraged. They understood it actually helped them manage risk!
7. Back to the Scrum Guide
The Scrum framework is purposefully incomplete. As described in the Scrum Guide, teams can employ various processes, techniques, and methods within the framework. We always encourage teams to try experiments on this level as well. However, it’s tricky to experiment with changing essential elements of the Scrum framework. For example, only do the Daily Scrum twice per week, skip the Sprint Retrospective, or not use a Sprint Goal. Although I even encourage teams to give it a try, I do always emphasize that it’s not Scrum anymore. Scrum only exists in its entirety.
Some teams have experimented so much that as a consequence the Scrum framework is hardly recognizable anymore. Maybe it resulted in a perfect way of working. Chances are it didn’t. At those moments it always good to check the Scrum Guide again. Not to blindly implement Scrum according to the guide again, but mostly to start a conversation about why the team made changes to the framework. What was helpful? What wasn’t such a good idea? What changes should we consider making? If you facilitate this conversation with the Scrum team, make sure not to become a Scrum Preacher!
8. Have the courage to face persistent impediments
A clear pattern that showed up in our community, is that many teams that struggle with Zombie Scrum, also don’t get any value out of the Sprint Retrospective. These teams are mostly focused on making the Sprint Retrospective fun, lighthearted, and energizing, leveraging many games and facilitation techniques. It’s what we call “Happy-Clappy-Scrum”. It might be fun for a while, but it quickly starts to frustrate teams because the real problems are ignored.
Using Scrum effectively isn’t easy. Teams need to overcome many tough, challenging, and persistent impediments that oftentimes seem to be beyond their span of influence. If resolving impediments proves to be tough, it’s tempting to only focus on the easy improvements. Teams that moved away from Zombie Scrum had the courage to face their impediments. They actively worked together with stakeholders, other Scrum teams, and management to find a solution. They created awareness in the wider organization and explained how the impediments impacted other areas as well. Often, support emerged from unexpected people, and solutions were found to problems that seemed impossible to solve.
9. Create a team contract or team manifesto
Another practical success factor to prevent Zombie Scrum is to create a team contract or team manifesto at the start of a new team. Or, if you’re already stuck in Zombie Scrum, during a team reboot session. A team contract or manifesto brings clarity around the personal values, work agreements, or how collaboration should take place. How are we going to work as a team? Who is responsible for what? When are the Scrum events? It can also contain agreements on how to deal with conflict. What if we have a completely different opinion on how a feature should be built? What if we disagree about the Sprint Goal? What if we have a heated debate that becomes too personal?
If everything runs smoothly, the importance of a team contract or team manifesto probably isn’t clear. It might even feel like a waste of time. Especially, because it already helps you to prevent many problems. Problems you’re obviously not aware of. Its value becomes clear once you’ll get into a rough situation with your team. If you have an intense debate within your team, it’s very useful to steer the conversation towards to team contract and remind everyone of what they agreed upon. As such, the contract or manifesto serves as a solid foundation for team dynamics, collaboration, and growth. In the articles “How To Kickstart A Great Team”, and “The Team Manifesto” we describe this concept in more detail.
10. Focus on a done Increment
The 10th success factor our community identified to prevent or fix Zombie Scrum is probably the most important one. A Scrum Team should have a laser focus on creating a done Increment every Sprint that delivers value to their stakeholders. The purpose of an Increment is to validate assumptions about the work that has been done to date. People that have a stake in the product can inspect it and determine if it meets their needs if they understand how it works and if it satisfies their expectations. The Increment is also a driver of new ideas, as having something tangible to interact with is a great way for people to see new possibilities.
This laser focus on creating a done Increment most likely also brings impediments to the surface. The team might not have the technical capabilities to release early and often, the Product Owner doesn’t have the mandate, or everyone works on too many different products that prevent them to create anything meaningful for their stakeholders. Other teams don’t even know who their stakeholders are… This brings us back to many of the success factors we shared earlier. Teams that have resolved Zombie Scrum worked in an environment with a high degree of psychological safety, they conducted many experiments to find solutions, and they had the courage to face persistent impediments.
Closing
In this blog post, we shared 10 success factors that emerged from a community meetup we hosted for The Liberators Network. Factors that helped Scrum practitioners prevent or fix Zombie Scrum in their team and organization. We hope this article serves as a source of inspiration to improve Scrum in your organization! As always, we’re eager to learn from your experiences as well. What are the success factors you recognize? What else have you tried to use Scrum more effectively? Feel free to share your findings. let’s learn and grow, together!