The power of retrospectives
Teams that do structured retrospectives or debriefs are typically 25% more effective. And that improvement can translate into very big business results, like multiplying your profits by a factor of 10.
What does this mean for you? A retrospective, or debrief, or “after-action reviews” is a way to learn from experience. They are a fundamental part of doing agile “right” and are used throughout medicine, the military, and increasingly in business and work environments.
But why is post-execution performance analysis important? If the objective was met, what is there to learn? We achieved the mission so let’s move on to the next one and continue the streak, right? Wrong.
When done promptly, the cause and effect analysis of a Debrief allows your team to capitalize on meaningful learning that time delays could inhibit or prevent. How long can one mistake be repeated before it’s formally integrated into planning? How does your organization benefit from the experiences of its members if there is no method of aggregating the learning outcomes of these missions?
The above is from the Afterburner blog, on the Pros of Debriefs (because they couldn’t think of any cons).
Unfortunately, it’s pretty easy to forget to do a retrospective. And even if you want to do one, how do you do it? In this episode we talk about retrospectives, their value, and how to do them. And then we finish up with a retrospective of the podcast’s 2016 season.
How do you do it, what are good practices?
The basic structure of a retrospective or debrief is to surface the following in a brief meeting of the whole team:
- What went well (you’ll want to keep doing these things)
- What could be improved (went OK, but could be better)
- What went badly (you want to stop doing these things, if possible, or concentrate on doing them better)
- A focus for the next period/sprint/month/quarter (One or two things to focus on)
In more detail for each of the sections:
- What went well: These are the things that were good/great/amazing. Things we could “continue doing.”
- What could be improved: These are areas that we feel were “okay”, but just didn’t satisfy ourselves. We liked them and think they could be improved.
- What didn’t work: These are the things that just flat out didn’t go right, should not continue, or made us feel bad/sad. Sometimes you stop doing those things, sometimes you double down.
- What will we focus on for the next period? It’s critical to choose only one or two areas of focus. To prioritize you can vote (dot voting) for the above items. There are always more things that we’d like to improve than we can focus on. Focusing on less is key (just like with product goals/initiatives!).
One challenge for many teams is that retros sometimes feel awkward. But you can get past this, to reveal the real nuggets:
- Practice and continuity is very important to get the real benefits – just like other agile practices. Just doing it once is nice, but you don’t get all the value.
- You don’t have to share any of the information that comes up outside the team. This is purely for the team to use to improve itself.
Make sure to share things that went well, and to celebrate the team’s successes. We often don’t share the things that went well, and take credit for them, and give ourselves a pat on the back for them. Recognizing “small wins” can be very effective for team productivity and improvement. Any enterprise can go wrong in any way, and the fact that your enterprise kept three of the four wheels on, so to speak, is worth celebrating, because there are enterprises that lost all four wheels.
Three things you can do today
- Plan your first retrospective with your team, if you are not already doing them. It’s not difficult, doesn’t take much time, and even if you don’t do it perfectly there’s a lot of value.
- What went well (keep doing these things)
- What could be improved (went OK, but could be better)
- What went badly (don’t do these things again)
- Focus for next period/sprint/month/quarter (One or two things to focus on)
- Once you’ve done a retrospective, help guide your team to be sure to actually focus on those things. You probably won’t see too much in the way of results for this first time through the process.
- Do another retrospective in two weeks, or at the end of your next sprint, or what is the right time (but make it soon). Ask the same questions. Help guide the team to focus on the things you decided to focus on. Then do it all again. After three or four retrospectives, done regularly, you will start to see some results: The team will be more open, the feedback will be better, the focus items will start to get focus, and you’ll actually stop doing some of the bad habits.
- Agile Retrospectives on Amazon – recommended book on how to have a successful practice of retrospectives with lots of ideas for how to get them started and keep them going. Focused on software development teams.
- Free online collaboration tool: http://www.ideaboardz.com/
- http://www.afterburner.com/insights/debrief-aint-nobody-got-time-for-that/ – insights from a former fighter pilot, now business consultant
Subscribe, Rate, Review
You can subscribe to the podcast using the buttons below, or the ones over to the right. The great benefit of subscribing is that you’ll get new episodes automatically when I release them.
You can also rate and review the podcast on iTunes, or click the Recommend button in your podcast player of choice. Your recommendations help other product managers and innovators find the podcast. It really helps me out and spreads the word. Of course, you can also share the podcast with your friends and colleagues directly!
I’d Love To Hear From You!
Please leave a comment below or drop me an email at firstname.lastname@example.org.
Support the Podcast
You can support the podcast by donating on my Patreon page. There are several levels of support available – but any amount is amazing.
And you can always buy my book, The Secret Product Manager Handbook, available in Kindle and paperback.