How to run a successful retrospective - Made Tech Blog
Improving software delivery in every organisation

How to run a successful retrospective

At the end of an iteration it's good to take some time to reflect as a team to assess what worked, what didn't work, and what could be improved upon. This can result in future iterations being more efficient and productive, as well as increasing happiness in the team.

At its most basic level, a retrospective is simply having the team sit together and allowing them to voice their opinions on went well and what didn't. This provides increased insight throughout the team. Teams list out each of the points made and then take a vote on which of these are the highest priority. Keeping this to a small list is most prudent as it won't overload the team, and any points that didn't make the list will show up in future retrospectives if they're a persistent problem.

From that list, action points are agreed upon to tackle each item, and the team bears them in mind when going about their day to day business. In future retrospectives, any action points that led to big improvements within a team should be shared back to the organisation as a whole, so that other teams can potentially benefit from learnings.

The Prime Directive

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand

– Norm Kerth

It's vital that a retrospective is run in a way where all members feel safe to discuss their viewpoints. Mistakes are something to be celebrated, as they present opportunities to learn, so when describing something that went wrong, be sure not to place the blame at the feet of an individual team member. If someone feels unsafe they're unlikely to be able to fully engage with the retrospective. Violations of The Prime Directive, deliberate or otherwise, should be seen as a team smell and may lead to the team going into the next iteration with a negative mindset.

There are some steps you can take to help maintain safety, such as reminding everyone of The Prime Directive before beginning the retrospective proper, or having facilitators conduct safety/pressure checks.

Safety checks

It's worth running safety checks to gauge how comfortable everyone feels before tackling larger issues. The facilitator should ask each team member to write a number between 0 and 5 on a post-it or similar, to mean one of the following:

5 - I’ll talk about anything

4 - I’ll talk about almost anything, but one or two few things might be hard

3 - I’ll talk about some things, but others will be hard to say

2 - I’m not going to say much, I’ll let others bring up issues

1 - I’ll smile, claim everything is great and agree with authority figures

0 - I'm not comfortable talking / I don't want to do this / I want to leave

Once these have been anonymously collected, the facilitator should tally the count. If there are more low numbers than high they should ask if the team would like the retrospective to continue. Either way there should be a brief discussion as to why the team thinks the numbers are low. If it's decided that the retrospective shouldn't run, then it's worth running this quick exercise to determine why people are feeling unsafe:

  • The Facilitator asks everyone to put themselves in the shoes of someone who might not feel safe, then note down what could make them feel that way
  • Based on the submitted notes, have the team work together to list reasons that might cause these issues
  • Based on the potential causes, ask the team to present and discuss potential solutions
  • Run the safety check again

If the safety level has increased after this point, then you can run the retrospective.

Facilitators

A key role in a retrospective is that of the Facilitator. They contribute feedback along with the rest of the team, but they're responsible for:

  • Outlining the retrospective exercise to the team
  • Keeping the exercise on track, with a balance of strict time keeping while trying to keep the atmosphere relaxed and informal
  • Ensuring the Prime Directive is adhered to
  • Helping and prompting thoughts and ideas if the team is struggling
  • Reiterating and sharing any agreed upon action points after the retrospective
  • Trying to ensure everyone on the team contributes to the discussion

To keep retrospectives fresh and different, try occasionally rotating the Facilitator role so that different members of the team get a chance to define how the session will run.

When deciding upon a retrospective activity, you can choose to go with a tried and tested idea, or something wildly different to help spice things up. We'll discuss some different ideas below, but there are numerous websites out there that provide plenty of ideas to take advantage of.

Scheduling and frequency

We derive the most value from retros when we run them at the end of each iteration (for us this is weekly) directly after a showcase. By running them before the next iteration begins, the team is able to take the learnings and outcomes directly into the following week.

If for whatever reason the team is unable to run one, we've found it best to wait until the next scheduled retrospective, so as to not disrupt the current iteration. Ideally these shouldn't be missed barring illness or holidays. If a team member has contributions to make but can't attend they can choose to provide these to the facilitator ahead of time.

Exercises

To keep energy up in a retrospective and help provide focus to the areas the team aims to cover it's common to use exercises.

These are some of our favourite exercises:

The happiness graph

Ask each team member to draw a graph of how happy they were over the duration of the sprint. The X-axis denotes days, and the Y-axis denotes mood. As moods, we use: happy, indifferent, sad and angry, but you may find a different scale works better for you. Have the team chart a line representing their mood over the course of the sprint. When everyone has finished, take the time to discuss any notable peaks and troughs, and make a note of the reasons for each.

As well as being a good way to see how everyone is feeling, with those notes, you can discuss ways you can make sure the things that made people happy continue to happen, and ways to prevent the things that made people unhappy from ever happening.

Hot air balloon

The hot air balloon exercise is popular within our team, with the format being:

  • Draw a hot air balloon on a whiteboard or other canvas, with a sun to the right of the balloon, and a storm to the left.
  • The Facilitator provides a prompt like "Looking back, what was our hot air, taking us higher, and what were our sand bags, bringing us down?"
  • The team then writes these down above and below the balloon as appropriate.
  • The team discusses each point as they go to make sure there is a shared understanding.
  • The facilitator then offers another prompt "Looking ahead, what stormy weather can we see making the route to our goal difficult, and what steps can we take to move towards sunny days and an easier path?""
  • These suggestions are again mapped to their appropriate area on the drawing, and discussed among the team.

By approaching the retrospective in this way we can reflect on the previous iteration, as well as look ahead to try to avoid any potential pitfalls.

Both of these exercises follow the same outline as the basic idea mentioned earlier. Most exercises work to elicit the following from team members:

  • What went badly?
  • What went well?
  • How can we improve going forward?

Don't let retrospectives become monotonous; mixing these exercises up is an ideal way to keep things fresh and provide different perspectives and prompts to these questions.

Action points

The outcomes of a retrospective can be used to identify action points that can be used to try and enact improvements to the next iteration. In the example of the Hot Air Balloon these would be the items listed featured in the sunny area. Ensuring that these action points are focussed and achievable is essential to their success.

Comradrospectives

Where a standard retrospective is for smaller teams, we've taken to holding a company wide retrospective, known as a Comradrospective. They're an hour long, and we hold them at regular intervals, often two weeks, after each team has had a retrospective. They have the following in common with retrospectives:

  • The Prime Directive is read out at the beginning
  • A safety check is held before hand
  • A Facilitator is assigned
  • Action points are decided on at the end of the session

These sessions can be focused on a particular topic, or each team can bring discussion points from their retrospectives, to share with the wider company. For example: things that have been holding them back, and their biggest successes. The facilitator of the team retrospective can collate these in advance and propose them to the wider group.

Through sharing and discussing these points as a group the company can identify issues affecting all teams and create further action points to address them. We make a point of revisiting agreed upon action points in future sessions to discuss whether we've been actively focussed on them, and whether they're still a priority for the company.

Customer inclusive retrospectives

Involving stakeholders from the customer side in a retrospective can be a valuable way to both improve communication and provide greater understanding for both sides. This allows for clear feedback from the customer, beyond the scope of a showcase. As well as that, because they can see you're actively taking steps to address any issues raised previously, it strengthens your working relationship.

Conclusion

Retrospectives, in any of their many forms, are an invaluable tool for maintaining healthy, happy software teams. By giving everyone a platform on which to voice their concerns, learn from their mistakes and celebrate their victories, you're ensuring your team will continue to evolve.

How effective is your business at software delivery?

Answer these 20 questions and find out where the principal software delivery challenges lie within your organisation.

Get started now