As many of you know, the Scrum methodology – and many other agile methodologies – use a practice called “retrospectives.” In other, non-software domains, they might be called debriefs or after-action reviews.
After each sprint the team spends a short amount of time reviewing what went well, what could be improved, and what they should stop doing. The goal is for the team to learn quickly from each sprint.
Regular retrospectives have been shown to improve team performance significantly.
So, let’s say I really wanted my team to start doing retrospectives, and the team is unwilling. I might share this little bit of research with them:
In a meta-analysis of 46 studies on debriefs (also called after action reviews or lessons learned), Scott Tannenbaum and Christopher Cerasoli found that when appropriately conducted, debriefs can lead to a 20-25% average improvement in performance. The authors found performance improvements in the use of debriefs with both teams and individuals. (Thanks to the Center For Evidence Based Management for sharing this study.)
Obviously, based on this data, retrospectives and debriefs should be a no-brainer. They are easy and they make your team 20% more effective. But this data still doesn’t motivate most teams to act.
It’s simply that a 20% improvement isn’t enough to get the team to change its behavior.
This is a general problem for product managers. 20% improvements aren’t interesting to people, whether they’re your customers or your team members.
One of my product management rules of thumb is the “Factor of 10 rule” – people aren’t willing to make a change – to a new product, to a new process – unless they get a 10x benefit on a metric they care about.
Back to my problem. I still think retrospectives are a good idea because I want my team to learn faster.
So I need to figure out how retrospectives will make an order of magnitude difference to something important to the team.
Somehow, I have to make 20% appear to be 1000%.
And that’s what this post is about. (It’s not really about retrospectives.)
Let me tell you one of my favorite stories. At NetIQ we improved the uptime of Windows servers by 20%. That’s nice, but as I said above, it’s not compelling.
But by improving uptime, we also reduced downtime. If you do the math, we reduced it by a factor of nearly 100 – two orders of magnitude! And I can assure you that our customers cared a lot about having less downtime. That’s a story you can tell, and indeed at NetIQ we told that story well.
Can we apply the same kind of thinking to “20% performance improvement?” Somehow turn it into an order of magnitude improvement?
Well, here’s one way. It’s similar to the “downtime/uptime” calculation we did at NetIQ.
How fast will the team learn if they don’t do retrospectives? I assume the team’s performance will increase over time naturally, but kind of slowly. Let’s call it 2%. So, if retrospectives increase that rate to 20% … I get a factor of 10x right there.
With this data I can say, “I recommend the team start doing retrospectives – your performance will improve 10x faster.” Retrospectives accelerate the team’s learning, and they accelerate it by a factor of 10. That’s a much better pitch. And learning faster is a benefit that most teams consider important.
But now let’s make the problem a little harder. I don’t just want the team to do retrospectives, which are free. I want the company to buy the team a tool to support retrospectives. And unfortunately, the execs don’t care that much about team learning, no matter what they say about “the company’s people are our most important asset!”
So I have to go to the next step. I need to show a dollars-and-cents business benefit for retrospectives – for “improving performance 10x faster.”
What happens when you accelerate your learning by a factor of 10? Well, the whole point of having a higher performing team is to release higher quality products faster.
And what happens when you introduce higher quality products to market faster? You get more revenue faster.
What happens when you get more revenue faster, but with the same team and the same level of effort? All the additional revenue goes straight to the bottom line. So your profit grows, and it grows faster than it would have.
Let’s put some numbers around that. Let’s say that improving the team’s performance results in a 10% improvement in time to market, which results in a 10% improvement in being able to close sales. In any period I get 10% more sales than I would have.
Let’s also assume that our profit margin was 5% before. If I had $10 million in revenue in a quarter, our quarterly profit was $500,000.
With my improved team performance, all the costs are the same, except I’m spending a little bit more on a tool – say that’s $3,000 per quarter. Otherwise, all I’m doing differently is having another short meeting every few weeks. I didn’t add anyone to the team. But now my revenue is $11 million in the quarter because I got a better product to market faster. My profit is now $1,497,000.
Improving the team’s performance by 20% tripled my profits!
This is even more impressive if the company is barely profitable. If our profit margin is only 1% before improving the team, then improving the team’s performance using retrospectives can increase my profits by a factor of 10.
To pitch retrospectives in my company, I’m going to use these ideas.
If we implement retrospectives and a good retrospective tool:
I illustrated this powerful idea in terms of retrospectives. But you can use the same approach to justify – and get investment in – many other kinds of improvement.
Have you used this technique of changing the perspective on a metric that’s “not quite good enough” to get a factor of 10 improvement?
I’d love to hear how you pitch improvement techniques, especially when they involve tools, to your management.
Please leave a comment or note below with your approach – or if you have additional questions.
Your host and author, Nils Davis, is a long-time product manager, consultant, trainer, and coach. He is the author of The Secret Product Manager Handbook, many blog posts, a series of video trainings on product management, and the occasional grilled pizza.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.