BT

Facilitating the spread of knowledge and innovation in professional software development

Contribute

Topics

Choose your language

InfoQ Homepage Articles Surviving Zombie Scrum

Surviving Zombie Scrum

Bookmarks

Key Takeaways

  •  Zombie Scrum Teams see themselves as a cog in the wheel, unable or unwilling to change anything to have a real impact.
  • In many organizations, shipping fast is perceived as a “nice to have”, instead of a necessary activity to manage risk and deliver value sooner. Without shipping fast, Scrum’s loop of Empirical Process Control collapses.
  • In Zombie Scrum, organizations don’t create safety to fail. Teams can’t improve when they experience no room for uncertainty, doubt, or criticism. 
  • The purpose of Scrum Masters is to create transparency around the ability of teams to deliver valuable outcomes to their stakeholders, and the impediments that get in the way.
  • Not all cases of Zombie Scrum can be cured. In some organizations, work is structured and managed so rigidly, that it will never become responsive and flexible.

The book Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem aims to support teams that are stuck in Zombie Scrum. It helps them to understand why things are the way they are and provide them with experiments to get out of this state of Zombie Scrum by enabling collaboration with stakeholders, working increments, autonomy for teams, and continuous improvement.

InfoQ readers can visit the Zombie Scrum Blog to use experiments from the book Zombie Scrum Survival Guide.

InfoQ interviewed Christiaan Verwijs, Johannes Schartau, and Barry Overeem about Zombie Srum. 

InfoQ: What made you decide to write this book?

Christiaan Verwijs: I’ve been working with Scrum Teams for over 15 years now, and I really wanted to crystallize some of that experience in a book so it may benefit others. The opportunity to write it with Barry and Johannes, who share a similar experience, made it even better. I also enjoyed the more longform approach of a book, where you have more time and space to expand on ideas.

Johannes Schartau: When I started using Scrum there were many things that I heard from other Scrum Masters and Agile Coaches that didn’t work for me. I started wondering whether that was my fault or if something else was going on. After a while I discovered that pretty much everyone I talked to was struggling. Christiaan, Barry and I made it our mission to help these people. The impact was noticeable so a book was the logical next step to reach even more people.

Barry Overeem: I was forced to write it. Just kidding. It felt like a logical next step. For the past decade I’ve gained lots of experience as a Scrum practitioner. This experience is something I’ve always shared by writing blog posts, participating in public events, and providing training. To capture everything in a book felt like the missing piece of the puzzle. 

InfoQ: For whom is this book intended?

Verwijs: There are already many excellent Scrum books out there that explain Scrum and/or give you helpful tips. While incredibly useful in their own right, they are not always able to help Scrum Teams who are truly and utterly stuck in Zombie Scrum. For them, the gap between what is in a book and what they can actually accomplish is simply too large. So we wrote a book that both helps them understand why things are the way they are and is filled to the brim with powerful and practical experiments to make progress - even in the most rigid and hierarchical of organizations. 

Scrum Masters are a very natural audience for this book. At the same time, we hope that product owners, developers and those around the team will use our book to recognize their role in preventing Zombie Scrum. 

InfoQ: What is Zombie Scrum? How can we recognize it?

Schartau: Zombie Scrum is something that looks like Scrum from a distance, but lacks the beating heart. While you see the roles, the events and even the artifacts of the Scrum Framework, there is no collaboration with stakeholders, no working increments, no autonomy for teams and nobody seems bothered to improve anything at all.

InfoQ: What can cause Zombie Scrum?

Overeem: There’s not one specific cause of Zombie Scrum, but in relation to the symptoms we described earlier, we can share some common causes. Generally speaking, Zombie Scrum systems occur in organizations that optimize for something else than actual agility. This creates problems that the teams can usually not solve on their own.

For example, Scrum Teams that operate in environments with Zombie Scrum rarely have a clear answer as to what makes their product valuable. Much like zombies that stumble around without a sense of direction, many Zombie Scrum Teams work hard on getting nowhere in particular. While they still produce something the question remains whether they are actually effective.

Verwijs: Another cause is the struggle many organizations face with shipping fast. Often heard excuses are that the product is too complex, technology doesn’t support it, or customers aren’t asking for it. Shipping fast is perceived as a “nice to have”, instead of a necessary activity to manage risk and deliver value sooner. Without shipping fast, Scrum’s loop of Empirical Process Control collapses.

In Zombie Scrum, organizations don’t create safety to fail. Teams can’t improve when they experience no room for uncertainty, doubt, or criticism. They often develop all kinds of defensive strategies to prevent uncertainty. This results in a lack of psychological safety, making it difficult to learn and improve. In such an environment, it’s also difficult or unsafe to create transparency about the challenges that impede Scrum Teams. As a result, inspection becomes ineffective, and necessary adaptations won’t be made either. A vicious cycle of Zombie Scrum is the result.

InfoQ: How can teams diagnose their way of working?

Overeem: Scrum Masters play an important role in the area. Their purpose is to create transparency around the ability of teams to deliver valuable outcomes to their stakeholders, and the impediments that get in the way. One way to do this is by helping teams gather data to assess how they are doing. By shining a light on where it hurts the most, Scrum Masters create the opportunity to jointly inspect the state of Scrum and support the team in making adjustments accordingly. 

To support Scrum Teams with the diagnosis, we created the Scrum Team Survey. It’s free and anonymous, provides detailed feedback, offers helpful experiments, and a foundation for meaningful conversations. 

InfoQ: The Scrum guide describes that Scrum is a framework for addressing complex adaptive problems. How do such problems look, and what does Scrum provide for solving them?

Schartau: Complex problems cannot be solved by analyzing them and coming up with a solution upfront. They need to be engaged with. We need to stay in contact, learn continuously and adapt our behavior. Scrum is based on the three pillars of Transparency, Inspection and Adaptation (TIA). That’s exactly the way to approach complex problems successfully. Instead of making a detailed plan, we go through the TIA process cyclically. This creates a rhythm that lets us learn, validate or invalidate assumptions and adapt our behavior.

InfoQ: What can be done to involve stakeholders and improve our understanding of their needs?

Verwijs: A good first step would be to find the “real” stakeholder. There’s a big difference between a stakeholder and someone with an opinion about the product. We see many examples where the vagueness of stakeholders is leveraged into making teams believe that only talking to internal stakeholders is what Scrum is all about. For them, it’s not necessary to talk to the people using the product or paying for it. And that’s a huge issue, because including the real stakeholders is the best way to reduce the risk of building the wrong product. 

Overeem: We like to make the distinction between “stakeholders” and “audience”. A stakeholder is someone who helps you decide what is valuable to work on next because it’s important to them to get a return on their investment of time and/or money. Everyone else is your “audience”. So, don’t ignore your audience, but focus mostly on your actual stakeholders!

InfoQ: Preferably teams should ship fast to get feedback as soon as possible. What kind of impediments cause delays or block shipping?

Schartau: We often see organizations create elaborate long-term project plans and yearly release schedules wrapped around the Sprints of their Scrum Teams. This is what we call plan-driven governance and it impedes Scrum Teams in their ability to ship fast. Their success is often measured against meeting artificial deadlines that have nothing to do with creating value for stakeholders. 

Overeem: Another common impediment that prevents Scrum Teams from shipping fast are large Product Backlog items that can’t be completed in a single Sprint. As a result, the remaining work has to be carried over into the next Sprint, where the team now has even less time to work on new items. This triggers a cascading effect which makes Sprints only artificial timeboxes in which nothing really gets done, let alone shipped.

InfoQ: What are your suggestions for dealing with such impediments? What can teams experiment with?

Verwijs: A strong recommendation we have for Scrum Teams is to make a business case for Continuous Delivery. This is the practice of automating your release pipeline from code commit to release. Without it, shipping fast is difficult and time consuming. So a good question to focus on is “How much money and time can actually be saved by automating your deployment pipeline?” By answering this question you make the promise of Continuous Delivery quantifiable, and might make it easier to convince the organization to make the necessary investments. 

For teams that struggle with slicing their Product Backlog items, some powerful questions they can explore are:

  • If we had to implement this item in only one day, what would we focus on? What could be done later?
  • What is the smallest and simplest possible way to implement this item? 
  • Which groups of users will be using this item? Which group is the most important? What can we let go of if we focus on that group?

Slicing Product Backlog items is one of the most important skills for Scrum Teams to master. Smaller items increase the flow of work, improve predictability, and give more flexibility to where to add or drop items in order to achieve the Sprint Goal. 

InfoQ: What are your thoughts on considering agile to be a transformation?

Schartau: Honestly, we don’t believe it is possible to “transform” to Agile. Usually, such transformations merely take the shape of a few different names for departments, new job titles and some extra certificates. Everything else remains the same, and thus nothing truly changes.

In our book, we clearly distinguish between “agile transformation” and continuous improvement. While it may sound slower than “transformation”, it is also a more deliberate and purposeful way to continuously inspect and adapt. We offer many practical strategies to spur on this continuous improvement, even in environments where you have little control. 

InfoQ: How does asking powerful questions in retrospectives work, and what benefits can it bring?

Overeem: One of the sad characteristics of Zombie Scrum Teams is their hopelessness. They feel stuck, and in a way they often are. Asking powerful questions can help people let go of rigid beliefs and adopt a fresh perspective. 

Generally speaking, you listen to statements of what isn’t possible within this team or organization. You then ask “What do you believe to be true that makes you say that?” You can help the individual create a sentence that starts with “I believe that…” So for example, when someone says, “We can’t deliver a new Increment every Sprint,” the possible underlying belief may be something like, “I believe that our product is too complex.”

Once you have identified this belief, there are other questions you can ask to gently challenge it. One example is the question, “What would need to happen for you to let go of this belief?”

InfoQ: How can we increase the autonomy of teams and foster self-organization?

Schartau: There is an entire chapter dedicated to this question in our book. Sadly, most Scrum Teams in Zombie Scrum organizations suffer from lack of autonomy which is crucial for successful Scrum. While a larger organizational change is often necessary to provide this autonomy, most teams don’t have the power to elicit this change. That’s why we provide small experiments to slowly widen the sphere of autonomy from the team outwards. 

Verwijs: One example is the use of permission tokens. Every time the team has to ask for permission to do something during a Sprint, the team members put a token into a special jar. There can be different tokens for different kinds of permission from different people or teams. At the end of the Sprint, for example during the Sprint Review, the tokens are counted and we ask the question “How does this affect our ability to quickly adapt in the moment and do what is the most valuable?” Explore this question and its consequences together with your stakeholders. Use the Sprint Retrospective to look closely at potential improvements.

InfoQ: What's your advice if it looks like the organization isn't able or willing to recover from Zombie Scrum?

Overeem: We are optimistic about the ability of most teams to get out of Zombie Scrum. It is also true that not all cases of Zombie Scrum can be cured. In some organizations, work is structured and managed so rigidly, that it will never become responsive and flexible. If you find yourself in such an environment, and you really don’t see any potential for improvement, perhaps it is better to find an organization that more clearly acknowledges you and how you want to help them. There is absolutely no shame in that. 

About the Book Authors

Christiaan Verwijs is one of the two founders of The Liberators. He has over twenty years of experience as a developer, organizational psychologist, Scrum Master and trainer and steward for Scrum.org, both in small and large organizations. He has seen his share of severe Zombie Scrum, as well as how many of those teams recovered.

Johannes Schartau is a consultant, trainer and coach for agile product development and organizational improvement. His mission is to bring life and meaning back to the workplace by spreading healthy Agile and Liberating Structures around the world.

Barry Overeem is the other founder of The Liberators. In line with the mission of The Liberators, Overeem liberates organizations from outdated modes of working & learning, using Scrum and Liberating Structures as sources of inspiration. 

We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.