Why Zombie Scrum Teams Don’t Ship Fast

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

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?

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

Reference