The quickest, easiest, and most effective agile retrospective ever
If you’re familiar with agile delivery you would have come across “The Retrospective”. This key agile ceremony promotes team learning through introspection and enables the team to learn, adapt and improve, in a true agile style.
Unfortunately, these lofty goals often collide – sometimes they can be unfocused, too long, or don’t work well for remote teams. Often they end up not being effective or just not done at all.
What we present here, whilst not original, is a quick and easy format for running retrospectives that has worked well for us at Wunder.
It’s fast, lightweight for the facilitator, and easy to run with remote teams. We are a remote-first organisation, so having simple and effective retrospectives, irrespective of where team members are located is key to how we drive improvements.
How to run this retrospective
To run this retrospective with remote teams, all you need is a video conferencing system (such as Zoom, Google Hangouts, Skype) and access to Google Sheets.
Co-located teams just need some post-its, a whiteboard and someone who can draw a passable impression of a boat.
We’re going to be talking about this retrospective in the context of a scrum sprint, but it’s equally applicable to iterations in lean delivery. Our retrospective format contains just two stages that can be predictably timeboxed.
Step 1 – Weather Report
The Weather Report is a really short exercise to gauge the team’s overall feeling about the sprint using a simple analogy. Everyone places an asterisk alongside their name under the column (Sunny, Mixed, Cloudy or Rainy) which represents best how they feel about the sprint.
To keep this short, give everyone one minute to do this.
Immediately afterwards, each team member gets one sentence to explain why they feel the way they do. The key here is keep it short and punchy – this is just a guide to how people are feeling, not an in-depth discussion. It’s really useful as a warmup exercise to get people talking and to set the scene. “I’m feeling cloudy because whilst we were able to develop everything in that sprint, some dependencies were unforeseen which ended up eating up time that was needed for essential sprint tasks.”
Time needed:
– 1 minute to enter data i.e. team members picking their weather mood
– 1 minute per team member to explain why they feel the way they do
So for a team of 6, this step would take 7 minutes.
Step 2 – Engines and Anchors
This step is where the bulk of our time will be spent. Using the analogy of a boat with ‘engines’ pushing the sprint towards its destination and ‘anchors’ dragging it back, give the team ten minutes to write down under the Engines column things that helped delivery, and under the Anchors column things that hindered delivery.
Duplicates are fine (and should be expected) and some things might appear in both columns (a common example is ‘team commitment’ – shorthand for long hours). It’s important to emphasise that the retrospective must be a no-blame environment – we’re working as a team to make things better, not seeking to apportion blame.
The team should take five minutes to complete their engines and anchors.
Next, each member of the team, in turn, should pick either an engine or an anchor (along with any duplicates or similar ones) and explain to the team why they wrote this down. The team might be in agreement, or they might want to discuss the point further.
To keep the session focussed, try to timebox discussions on each engine or anchor to a maximum of five minutes (using the Google Sheets approach, the facilitator can italicise the engines and anchors that have already been chosen to help the team. In-person, the facilitator can simply cross through/highlight engines and anchors that have been addressed).
Continue with each team member picking an engine or anchor and go around until you’re done with all of the engines or anchors, or until 40 minutes is up.
Making iterative improvements
Finally, as a team, decide on what to focus on improving in the next sprint. Each team member gets three ‘votes’. Alongside each of the Anchors, every person should place one or more of their votes – the Anchors with the two highest votes should be your focus for improvement in the next sprint.
During the next sprint, you can keep these in mind by adding them as a ‘subtitle’ to the name of your next sprint, or maybe even write a bot to remind you of these improvements periodically in your Slack or Hipchat chat channels.
Time needed:
50 minutes (max)
– 5 minutes for entering engines and anchors
– 40 minutes for discussing each ending and anchor as a team
– 5 minutes to highlight 2 areas for improvement to implement in your next sprint
Tried, tested, and effective
I’ve run retrospectives using this format with both remote and co-located teams and it’s a great way to keep retrospectives focussed, tight and interactive.
Additionally, Wunder is a wholly agile company, which means we not only use this retrospective approach to deliver agile web projects for our clients but we also use it after non-delivery activities. For example: when our team is working on proposals together, we evaluate how we can work better or improve our processes next time.
If you haven’t done so yet, I encourage you to try out this agile retrospective approach on your next project. If you’d like to discuss how we can help your company become more agile, simply get in touch to speak with one of our agile experts.