In our book — the Zombie Scrum Survival Guide — we dive deep into what causes Zombie Scrum; something that looks like Scrum from a distance, but lacks a beating heart. We also offer 40+ experiments to recover from Zombie Scrum. In this series, we share experiments that didn’t make it to the book but are still very helpful. This post was written collaboratively by Christiaan Verwijs, Barry Overeem, and Johannes Schartau.
Scrum makes so much more sense for Scrum Teams when they understand the purpose of their product. Unfortunately, Scrum Teams that operate in environments with Zombie Scrum often don’t know why their product matters, what their stakeholders need nor what is valuable to them. They end up doing whatever ends up on their Product Backlog without having a sense of it all ties together. Or worse, they don’t know the purpose of their product. Or there isn’t even a product.
In a previous post, and in our book, we explore common reasons why this happens. In this post, we describe one tiny experiment that can create big shifts in how teams experience the Scrum Events and the decisions they make during them.
Provided you have a product purpose, this is an easy one to do
Impact on Survival
A great start for important conversations.
To implement this experiment, do the following:
- Prepare visual aids to communicate the product purpose, like a product vision board or a purpose printed on a banner. You can easily bring these with you into the various Scrum Events. If you don’t have a purpose statement at all, refer to “Our Findings” below for suggestions.
- Begin each Scrum Event by reiterating the purpose of the product you’re working on. It doesn’t have to be literally the first thing you say, but make sure to mention it somewhere in the introduction. It’s even better when you tie it to the purpose of the various Scrum Events.
- For the Sprint Review: “We are developing this product to [purpose]. Let’s use this Sprint Review to gather feedback on how the results from this Sprint have helped us make progress on that”;
- For the Sprint Planning: “We are developing this product to [purpose]. Let’s use this Sprint Planning to decide what we’re going to do this Sprint and how we will be working together to work towards that”;
- For the Sprint Retrospective: “We are developing this product to [purpose]. Let’s use this Sprint Retrospective to figure out how we can collaborate more effectively to work towards that”;
- For the Daily Scrum: “We are developing this product to [purpose]. How can we collaborate most effectively in the next 24 hours to work towards that purpose?”. You don’t have to mention this every time;
- There is a risk of this becoming a mantra that is only mentioned, but not acted on in what happens next. Especially when the product's purpose is abstract and vague. A good way to prevent this is to find different ways or metaphors to express the purpose, let someone else do it each time, or re-invent the product purpose periodically. Keep it fresh.
- If you don’t have a purpose statement for your product, this is an excellent opportunity to create the first version. The Liberating Structure “Nine Whys” can be a huge help here. Don’t worry about finding the perfect sentence to complete “This product exists in order to ….”; it's better to have an incomplete, rough sense of why your product matters than no sense at all.
How did it go?
We’d love to hear how it went when you’ve tried this experiment. With your feedback, we can empirically improve experiments, add new ones, and remove what doesn’t work. Let us know in the comments how it went and/or fill in this short feedback form.
Looking for more experiments?
Aside from a deep exploration of what causes Zombie Scrum, our book contains over 40 other experiments (like this one) to try with your Scrum Team. Each of them is geared towards a particular area where Zombie Scrum often pops up. If you’re looking for more experiments, or if these posts are helpful to you, please consider buying a copy.
Order your book directly from us for some nice extras.