There’s nothing retrospective about dull retrospectives
— Agile — 4 min read
My current client has a prescribed retrospective format in Confluence so that all teams can pipe their output into a bigger ‘retrospective of retrospectives’ which ultimately then generates a list of actions to improve processes across the entire programme of work.
The format for the retrospectives are:
- What should the team start doing?
- What should the team keep doing?
- What should the team stop doing?
This format is great for reporting but not amazing for engaging a team in the looking at the way the sprint went as they come with solutions instead of problems to the session.
Interestingly the team rejected the approach initially not because of the fact there was no room to switch things up but because they had been using an app in the past that made things ‘fun’ but ultimately this app was just a kanban board with the same structure of start, stop, continue.
The issue with both approaches are that they don’t allow the team the freedom to explore the issues outside of those boxes so I decided to take the retrospectives we held back to basics.
Going back to the board
I’ve yet to see an electronic tool that beats sticky notes and a board for exploring ideas, the fact that information can be re-arranged easily and quickly to aid conversation is just something that can’t be done well outside of ‘meat space’.
Another advantage of sticky notes and a board is you can illustrate the ideas you’re trying to get the team to think about as part of the retrospective exercise, diagrams of spaceships hurtling towards an asteroid field are a lot easier to draw on a board than on a computer.
My team is split between two offices so we rely on a video call showing the board for others to join in and we jot down their suggestions for them which has some overhead but it’s worth it for the flexibility.
At the end of the sprint I do a quick Google for retrospective ideas but a few of my favourites are:
Getting to the moon
Draw a spaceship (the team) propelled by a massive thruster (the process) flying towards the moon (the goal) and add an asteroid belt (risks) in front of the moon.
Have the team place post it notes on:
- The astroid belt — What are the risks stopping us meeting the goal?
- The thruster — What is fuelling the thruster (good parts of the process)?
- The ship — What we could do to the ship to make things more aerodynamic (improvements)?
It’s common that there will be some overlap between peoples answers for the different questions.
I cluster these answers and then do a root cause (ask the 5 whys) on the biggest clusters on each section, this then gives us a bunch of actions we can do to improve our process, mitigate risks and understand what works well.
User Story Oscars
Create 3 columns (or more if you’d like) categories and have the team nominate the user stories worked on in the sprint into the different categories.
I tend to use:
- Best story — A story that had all the information it needed, was estimated well and delivered on time
- Most enjoyable story — A story that was fun to work on, may have seen the team learn something new or some other aspect that the team member enjoyed
- Most annoying story — A story that was a pain in the arse to deliver
It’s common that the most annoying story will be one that affected a lot of people in the team or one that required a lot of rework so don’t be surprised if one story gets multiple votes.
I like this retrospective format as it prompts the team to talk about the stories and not the process, of course the process will have affected the stories but I think the slight removal helps frame the conversation better.
Once we have the story nominations in I tally up the votes against each story and then do a root cause on the top 2 in each category.
Have each team member use one word to describe how they felt the sprint went and then the team probes deeper into why they chose that word.
I like this approach as it allows you to quickly get into a 5 whys root cause discussion compared to the other formats I’ve listed.
The only thing I have against this approach is that it’s easy to be negative but I might try and extend the format to three words next time and force one to be positive so people celebrate successes and understand what helped that success.
Compiling the output into the corporate format
After running the retro I then sit down and compile the output into stop, start and continue points so they fit into the corporate format, document the list of actions we’d created and send this off to the team for agreement so I can fill it away.
Since taking this approach I have found that my time discussing the team’s retrospectives have increased but are far more valuable as we have sufficient detail, having looked at the symptom and the root cause.
Of course, at this higher level the majority of items aren’t valid due to being inside the team but when we have valid items it’s great to present both the symptoms we’re seeing in the team and the greater programme as well as options to improve.
I have also been asked by other team leaders in that meeting about the approaches and if it works, I think some people assumed that each retrospective had to follow that prescribed structure so I’m hoping they’ll get adventurous in the future.
Switching things up makes the team more engaged
Since we moved to using different formats and using a physical board I’ve found the team members are more engaged and some even look forward to the meeting as they know they’ll get a chance to explore the inner workings of the process the team follows.
Other members just look forward to seeing what I’ll pull out of the hat this time which is fine because it means they at least want to attend even if it’s to see if I can draw a sailboat properly.