When I was a developer, I understood in theory that retrospectives were a good things and were there to help the team improve over time. The thing was, that isn’t how it worked in practice. Our ScrumMaster ran the same retro every time. He would walk in, draw three columns on a flip chart, and labelled them Positive, Negative, and Delta. The team would then sit quietly and write up the same things on stickies that we had written last time. Our ScrumMaster would then quickly read out the good things, let us spend half an hour whinging at each other about the negatives, and finally we would agree to change all the things that we hadn’t changed before. When I decided to become a ScrumMaster, I promised myself that I would never put a team through that.
A Nicer Way of Doing Things
As you can imagine, whilst experiencing the above scenario there wasn’t much psychological safety and given the lack of value we were finding it was an unpleasant thing to go through each sprint. I realised that I didn’t know enough about what good retrospectives look like to be able to run one without some research. I found the fantastic book by Esther Derby and Diana Larson called Agile Retrospectives: Making Good Teams Great, that I cannot recommend enough. Esther’s approach to retrospectives has five stages:
- Set the stage; set the tone of the meeting
- Gather data; create a shared understanding of the iteration
- Generate insights; look for patterns, themes, and connections, and to think about potential solutions
- Decide what to do; generate and prioritise potential actions
- Close the retro; end the meeting (hopefully on a positive note)
Build the Steps Out
To set the stage we need to acknowledge that everyone did their best and was working together towards the common goal. (I’ve worked with teams where this really isn’t the case, but for the scope of this article let’s imagine we are working with a good team.) Many people read out the prime directive for retrospectives and move on, but I like to use this step – and the Close the Retro step – as moments for the team to get to know each other better, acknowledge their strengths and weaknesses to themselves and each other, and helpfully bond a little along the way. For my most recent retro I used Unlikely Superheroes and Shower of Appreciation, which are great at doing just that.
The middle three steps are the meat of the retro. When I first started using this approach, I often found it hard to make them flow together well. Nowadays I take time when planning a retro to play out in my mind what the flow might be like. The trick is to make sure that the output of step two can become the input of step three, and the output of step three can become the input of step four. I still get it wrong from time to time, and when I do it’s a great learning experience towards my own continuous improvement. I make sure that these steps are in some way creative, engaging, and allow introverts to have an equal opportunity to be heard as extraverts by using tricks such as idea writing and dot voting.
When the team has got to a point where they’ve got a bunch of things they want to change, I encourage them to choose one key thing that they will definitely improve in the next iteration. After that, I ask them to choose two or three smaller things that we might not get to, but that we can be mindful of. Remember that at the end of the next iteration we’ll be looking at our process again and we can change another thing then. Also as agilists, we’re trying to be empirical so by only changing one thing at a time we can be certain of a causal relationship between the thing we’ve changed and the results we see.
Give it Time
I spend anything from 30 minutes to an hour to prepare the area for the retrospective before hand. Most of the resources that are required for the activities that I typically run in retrospectives are available in the average agile office. I try to always have some things for the team to play and fiddle with during the session too such as lego, pipe cleaners, pens and paper, or anything else that helps to create focus. These are nice to haves, but I wouldn’t do a retro without them now.
I set aside two hours for the retrospective session. I have run shorter retrospectives, but I don’t think it allows enough time for the team to work through the five steps without rushing. I’ve had managers and team members question the need for the length, but when I explain the reasons I’ve presented here and after they see that things do genuinely change and improve over time then people start to become advocates of taking the time to reflect properly.