Few teams start from a position where the Scrum Framework works like a charm from the start. Scrum is radically different from the way that teams have built products and worked with stakeholders in the past.
Signs to watch for
- The Sprint Retrospective doesn’t result in any improvements at all.
- For the actions that come out of a Sprint Retrospective, it is unclear where to start or what success looks like.
- Scrum Teams or Scrum Masters focus their improvements mostly on making the Scrum Events more fun, with more games and more facilitation techniques.
- Scrum Teams don’t inspect metrics during Sprint Retrospectives to identify improvements.
- Team members put the responsibility of performing an action on others, often people outside of the team.
No Tangible Improvements
The Scrum Framework provides a clear criterion for success: delivering a potentially releasable Increment every Sprint. And since that requires addressing many hard challenges, you won’t be able to do that overnight. Improving incrementally, in small steps, is your best strategy to keep change manageable and motivating.
“The Scrum Framework provides a clear criterion for success: delivering a potentially releasable Increment every Sprint.”
One important skill for Scrum Teams to learn is how to be specific about what to improve, and how to break down improvement into small steps. Just as refining large items on the Product Backlog into smaller items makes it easier to complete them, breaking down large improvements into small steps makes it more likely your improvements will succeed. Teams that suffer from Zombie Scrum tend to either get stuck in huge, demotivating improvements like ‘Product Owner should have a greater mandate’ or they get lost in vague improvements that don’t tell them where to start.
“Teams that suffer from Zombie Scrum tend to either get stuck in huge, demotivating improvements or they get lost in vague improvements that don’t tell them where to start.”
Cause: In Zombie Scrum, We Don’t Value Mistakes
Organizations that suffer from Zombie Scrum avoid making mistakes at all costs or don’t recognize what they can learn from them. For example, when Scrum Teams can’t deploy their Increment on their own because there is too much risk. Or releases don’t happen every Sprint because it seems too difficult, and new technologies are avoided because they are too daring.
Cause: Scrum Teams Don’t Recognize The Human Factors of Work
Organizations that suffer from Zombie Scrum spend little time on human factors. They either don’t see the need or they simply assume that employees will behave professionally, and so they implicitly and explicitly signal that spending time on work agreements, talking about tension, getting to know each other, and building a team are not considered “real work”. They fail to appreciate that teams are social systems with important social needs.