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
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.
“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?
Reference
https://www.zentao.pm/agile-knowledge-share/yhy-zombie-scrum-teams-dont-ship-fast-914.html
Comments
Post a Comment