Why Zombie Scrum Teams Don’t Ship Fast

Organizational Exercising: Do It Often And Become Stronger

Zombie Scrum Resistance
Jul 6 · 5 min read

In environments with Zombie Scrum, people don’t understand why it’s important to ship fast. When you ask them, they respond with a shrug. Or with a dismissive smile, because “that can’t possibly work for a product or organization as complex as ours”. For them, shipping fast is only possible for small and inconsequential products or for huge tech companies like LinkedIn, Facebook, and Etsy. Even if they’d want to, the investment would simply be too large. It’s more convenient to keep batching many updates into large, infrequent releases. Honestly, this is not very different from seeing the appeal in a healthy lifestyle but refusing to do the frequent workouts to get there.

Signs to watch for

  • Regardless of how much work Scrum Teams complete within a Sprint, features are batched into large quarterly or yearly releases.
  • Releases are “all hands”-affairs where people clear their schedule for the evening and the next day(s) to address issues caused by the release.
  • “That doesn’t work here” is a common response from people when you explain that every Sprint should result in a new version of the product that can be released.
  • People don’t have a clear answer when you ask “What risks increase when we don’t ship faster?”.
  • Releases are large operations and include many changes, bug fixes, and improvements. A simple look at the release notes usually tells you enough.

Shipping Fast Reduces Risks

What all these responses have in common, is that they show that people ultimately don’t understand that shipping fast is necessary to reduce the risk inherent to complex work. Ironically, the more complex the product or its environment is, the more important it is to release small increments to reduce the risks that are inherent to that complexity. The reasons that people often give why they can’t ship faster are often exactly the reasons why they should.

Image for post
Image for post
“Lets take shelter before you hit ‘Release’ on the yearly deployment”.

For many teams, deploying a new version of their product hurts. Teams are on edge, worried about making a critical mistake. They prefer to do this during the low-traffic hours (in the middle of the night). Schedules for the days after the release are cleared to address the fallout in terms of bugs, issues, and — potentially — rollbacks. It is no wonder that many teams choose to deploy as infrequently as possible.

But shipping fast is a form of organizational exercise. When Scrum Teams ship fast, they purposefully stress their processes, skills, and technologies. In response, they start to look for ways to optimize their work to deal with those frequent stressors. Scrum Teams are likely to increase their use of automation, create rapid fall-back strategies, introduce techniques like feature toggles, and find other ways to reduce the “blast radius” of a new release. Just as our muscles become stronger as they recover each time that we slightly damage them through exercise, releasing often helps organizations build capabilities where they matter most. Although some pain is unavoidable, and just like sore muscles give rise to increased strength and endurance, each release will be easier, faster, and less risky than the one before.

Obviously, these improvements only happen when it is the Scrum Team itself doing the exercising. When people outside the Scrum Team are responsible for releasing, the Scrum Team has no incentive to improve. They also need to have control over the deployment process and the tools to automate deployments. The best Scrum Teams we’ve worked with treated automation as part of their work on a product. They made this work transparent on their Product Backlog and refined it into smaller items as needed. Rather than treating automation as an afterthought, they used their first Sprints to create the necessary automation to deploy their product increment to production. In subsequent Sprints, they built upon this foundation with additional automation and monitoring. All the time they would’ve wasted on making, and recovering from, large deployments was spent on adding more valuable features to their product.

What else?

Aside from a lack understanding how shipping fast helps to reduce risks, there are many other reasons why Zombie Scrum Teams don’t ship fast(er). 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 #3: In Zombie Scrum, We Don’t Understand The Competitive Advantage Of Shipping Fast

In organizations that don’t ship fast, the churn rate — the percentage of existing stakeholders that stop doing business with you — is high or increases. Instead, they jump to competitors or other solutions because their needs are not addressed in time. Shipping fast is a great way to build a competitive advantage, but this insight is often lost in environment with rampant Zombie Scrum.

Cause #5: In Zombie Scrum, We Don’t Break-down Large Items

Frequently, items on the Sprint Backlog or Product Backlog are so large that a Scrum Team can’t complete them within a single Sprint. Or, Scrum Teams have only a few large items on their Sprint Backlog instead of many smaller ones. And, Scrum Teams don’t spend time refining work for upcoming Sprints. Because nothing can get done in single Sprint, teams are unable to ship faster.

Closing Thoughts

Recovering from Zombie Scrum starts with understanding why we’re using Scrum in the first place. Its all about complex work and reducing the impact of the risks that are inherent to that. In this post, we explored how releasing frequently is essentially a form of organization exercising. If you do it more often, you become stronger.

We’d love to hear your experiences with this. What are the things you’ve tried? What are other reasons you have found?


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.

How To Recover?

In our book, we offer 10 powerful experiments to start improving continuously with your Scrum Team(s). We explain each experiment step-by-step and help you prepare.

Image for post
Image for post

The Liberators

The Liberators: Unleashing Organisational Superpowers

Zombie Scrum Resistance

Written by

This is the combined account of Christiaan Verwijs, Johannes Schartau and Barry Overeem — the authors of the upcoming ‘Zombie Scrum Survival Guide’.

The Liberators

The Liberators: Unleashing Organisational Superpowers

Zombie Scrum Resistance

Written by

This is the combined account of Christiaan Verwijs, Johannes Schartau and Barry Overeem — the authors of the upcoming ‘Zombie Scrum Survival Guide’.

The Liberators

The Liberators: Unleashing Organisational Superpowers

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store