Agile Retrospectives : Making Good Teams Great

Posted on June 20, 2011

The principle purpose of an Agile retrospective is to reflect on the recently completed Sprint in order to adapt the teams practices and improve the way in which they deliver software. Most teams will begin by asking three simple questions:

What went well?
What did not go so well?
What changes can we make to improve?

Early on, I took this rather simplistic approach and to be quite honest very little insight was generated. There were still benefits in that the team were sharing their experiences and learning from one another but this became stale very quickly. I needed to learn more about facilitating Agile retrospectives and so invested in a copy of Agile Retrospectives by Esther Derby and Diana Larsen.

Helping Your Team Inspect and Adapt

We all know about the three fundamental questions on which Agile retrospectives focus. Often, this approach does not provide enough structure to the discussion or indeed, stimulate discussion. It becomes stale and repetitive and so the activity depreciates over time.

An alternative structure is recommended that includes:

Set the Stage
Gather Data
Generate Insights
Decide What to Do
Close the Retrospective

Now, I’m not particularly gifted when it comes to facilitating meetings so I like to have a well structured meeting with a pre-agreed agenda. I like the look of this structure as it communicates what we are trying to achieve and our approach.

Others might be more comfortable with less structure but to that I would say, even if you are good at facilitating meetings the participants may not be good at participating. You really have to find your own comfort zone when it comes to how much preparation and structure.

A Retrospective Custom-Fit to Your Team

Every team and environment have different characteristics and so it is useful to tailor the retrospective to suit.

For example, I like to have a rather informal approach to the retrospective and I do this by organising some fizzy drinks and sweets. I still follow the structure etc. but doing this allows people to relax a little after the hectic activity of the previous sprint. I select different goals dependent on events during previous sprints and don’t typically invite people outside the team. I try to limit the duration to two hours but if it goes a little over that’s fine. I select activities that are somewhat familiar to the team but different enough to be interesting.

These are some of the things that might make our retrospective different to others and there is no one size fits all. Esther and Diana discuss the ‘customising’ of Agile retrospectives and describe the relevant considerations to be made.

Leading Retrospectives

Facilitating an Agile retrospective (indeed any meeting) is an art rather than a science. It might be ok to prompt certain discussion but not to lead discussion, and there can be a fine line between them. You need to manage the structure of the retrospective while allowing enough freedom to have free flowing discussion when required. You need to manage the dynamic of the group to ensure appropriate levels of participation etc.

This comes naturally to some, not so to others so it is useful to read others experience and insight into facilitating.

Activities to Set the Stage

One of the things I liked most about this book is the description/definition of a number of activities that can be performed at each of the steps during the retrospective.

At the start of the retrospective, you set the stage by preparing the team for the activities that will take place. You describe the purpose of the retrospective before describing a theme which bounds the discussion. For example, quality might be a theme you choose after an unusually high number of bug returns. You can then select an activity from the those described or use one of your own.

Activities to Gather Data

To ensure all participants have the relevant information, you now gather information to create a picture of what happened during the previous sprint. This should be bounded by the theme and not allowed to drift in and out of a number of topics. Again there are a number of activities you can undertake to help gather data.

One such activity is to create a time line by asking everyone to identify two significant events (that occurred during the previous iteration) relating to the theme. One should be positive and the other negative. People find it easy to participate in this activity and see the benefit quite quickly. This is not true of all the activities so you need to pick your activities with the experience of the team in mind.

Activities to Generate Insights

Now that we have the data, we need to generate ‘insights’ i.e why did these events unfold in the way they did. We are not looking for solutions yet, but trying to understand the root cause of events.

One of the activities to generate insights is called ‘Five Whys’. Essentially, sitting in a circle, each team member will select an event and ask the person to their left why it occurred. They will then continue to ask why eventually arriving at the root cause. When I first read about this activity it sounded a bit like a child enquiring as to why they had to go to school or could not have a treat. But it actually worked quite well in practice.

Activities to Decide What to Do

So now we know the root cause, what do we do about it.

You could try and activity called ‘Short Subjects’. This activity involves listing things the team should start, stop and keep doing. The list is then prioritised based on the impact the team believe the item will have on the theme. The team decides which of these they want to implement in the next sprint. Simple yet effective!

Activities to Close the Retrospective

Having completed the activities relating to the retrospective theme, you can take a little time to reflect on the retrospective itself and to share appreciations between team members. It’s all getting a little touchy-feely now but credit where credit is due, if someone has went above and beyond in the pursuit of team excellence now is a time to acknowledge it.

Release and Project Retrospectives

Dogs are not just for Christmas, and retrospectives are not just for Sprints. It is worthwhile to have release and project retrospectives with a wider audience. This can help other stakeholders appreciate what it is the team are trying to achieve and also help the team appreciate the context in which they are delivering software.

Thoughts

I found it difficult to find resources on facilitating Agile retrospectives and was very happy with the content of this book. Facilitating a retrospective requires a lot more thought than it is generally given and the structure outlined by Esther and Diane really helped stimulate some ideas as to how to maximise the value of the retrospective.

I loved the ideas for the activities provided for each of the stages of the retrospective. Varying the activities in this way keeps the retrospectives interesting and helps stimulate new ideas by providing different perspectives.

I’d have no hesitation in recommending this book. Excellent!