Take your retrospective Back to the Future
Got a big and intimidating release coming up? Hop into your DeLorean with your team and ask your future selves how it all played out!
Back to the Future is an agile retrospective format that allows you to recognize risks, engage the team’s imagination and quite possibly have a laugh or two. I came up with the idea when our team was preparing to launch a huge website overhaul we had been working on for the last six months. There was an air of uncertainty and insecurity that I wanted to clear but couldn’t find any existing templates and therefore decided to roll my own. Here’s how we did it.
Step 1: Ask questions
Get a big pile of sticky notes and markers. If you can draw, draw a cool DeLorean DMC-12 to set the mood. If you can’t, draw a lousy one like I did. Brief your team.
“We’ve been able to get access to a DeLorean with working time machine modifications. We’ll send it to the future, a few weeks after launch. This gives us the opportunity to ask our future selves any questions we want — how the the release went, how the new features were received, what problems we had.”
Give the team 10 minutes to come up with at least a couple of questions each. Allow them to quickly present their questions to the rest of the team.
Step 2: Answer the questions in the future
Time to get all those sticky notes aboard your DeLorean and travel to the future! With the miracle of imagination we can do this without even moving. The team needs to get in character and answer the questions as if they have already happened. The questions are all fair game - the person who answers doesn’t need to be the same person who asked the question. Make sure everybody answers at least one question to get everybody involved.
Remember that there should be no uncertainty in any answers! We’re talking about the past now, so accept no “maybe” or “possibly”.
Step 3: Return to the present and address risks
The level of optimism in your answers may vary, but there will most likely be at least a few worrying answers (“Did it handle the load?” “Almost.”). Pick them out yourself or let the team vote the most significant ones. These are potential risks which you should then handle. For this, you can use the ROAM method, meaning each risk should either be:
- Resolved immediately, meaning it is no longer a risk,
- Owned by someone who has responsibility of resolving it,
- Accepted that nothing can really be done about it, or
- Mitigated so that its likelihood and/or impact are minimized.
Depending on how much time you have available, try to Resolve or Mitigate some risks if you can. Then assign action points for any Owned risks and conclude the retrospective. You should now have a clearer view of the upcoming release event, a higher level of confidence and a lower possibility of having something go wrong.
Step 4 (optional): Revisit the answers in a future retro
Eventually, the launch date comes and goes. The release is rolled out and the situation eventually stabilizes. Now you may choose to get back to the questions and answers and see how they matched the actual results. Maybe you dodged a bullet because you recognized and mitigated a risk early on? Perhaps you did much better than expected and can just look at the sticky notes and say, “Huh, I guess we’re a pretty good team after all.”