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. Scrum Teams usually need to improve in many different areas, and overcome many barriers, in order to reach their goals of higher customer satisfaction. Because every team, every challenge, and every context is unique, it doesn’t suffice to simply copy “best practices” from elsewhere and expect them to work. Instead, they need to experiment with different approaches to find what works best for them.
Unfortunately, we’ve found that many Scrum Teams struggle to improve at all. And that easily leads to Zombie Scrum: something that may look like Scrum from a distance but lacks the beating heart. In this post, we address one common reason for this: a lack of tangible improvements.
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.
We run into serious problems, however, when the small steps that people come up with are vague and nonspecific, like “improve communication” and “increase collaboration with stakeholders”. Although these are good goals, they don’t tell you where to begin and what success looks like. Teams with improvements like this should ask themselves “When we communicate better, what will be different?” and “What would it look like if we increased our collaboration with stakeholders?”. Specific improvements, with metrics, help people know what they are committing to; vague improvements are easily agreed on, and harder to judge whether they have missed their goal. They make it very difficult to actually succeed in improving and building confidence.
Another example of this is what we’ve come to call “Happy-Clappy Scrum”. Here, Scrum Teams focus their energy on making the Scrum Events as fun, light-hearted, and energizing as possible, leveraging the many games and facilitation techniques that can be found online. This often happens when teams cannot influence impediments, and their well-intentioned improvements remain superficial. Although there is great value in creating inclusive and engaging environments, this doesn’t help when the team is not actually inspecting their results and adapting their product and their approach based on feedback. Rather than using the Scrum Events as opportunities to remove larger impediments to inspecting and adapting, the Scrum Team focuses on re-energizing people to survive another Sprint amidst a wasteland of Zombie Scrum. But no matter how fun the Sprint Retrospective is, teams won’t feel better when they have no feedback about the impact they’re having on real users. No matter how energizing and fast your Sprint Planning is, it won’t make your stakeholders happier when they still have to wait a year for the work to reach them.
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.
What else?
Aside from a lack of tangible improvements, there are many other reasons why Zombie Scrum Teams don’t improve continuously. 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 #2: 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. When you say that the Scrum Framework is a way to fail fast, people respond with wide-eyed wonder: why would you ever want to fail in the first place? Instead, let’s call it ‘succeed fast’. And let’s not talk about ‘experiments’ or ‘minimum viable products’. Instead of seeing mistakes as an opportunity for learning, they see mistakes as something to avoid.
Cause #5: 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.
Cause #7: Scrum Teams Consider Learning And Work As Different Things
In organizations suffering from Zombie Scrum, people are implicitly taught that learning and work are separate things. Work generates value while learning only costs time and money that could’ve been spent doing more “real” work. For example, management expects people to participate in training in the evenings or on weekends. The implicit message is that people get paid for work, and since learning isn’t real work, they have to do it on their own time.
Closing Thoughts
In this post, we explored how continuous improvement is the lifeblood of Scrum Teams. Unfortunately, many teams struggle to come up with small and tangible improvements, instead of resorting to vague improvements without ownership. We also explored some other reasons why continuous improvement is difficult for teams.
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.
Order your book directly from us for some nice extras.