What makes a great Retrospective?

We often refer to the Retrospective as “the easiest meeting to run, but the hardest to do well.” So we decided to ask people what they thought made a good retrospective?

What is a Retrospective?

Before we get into the detail, let’s just clarify what we mean by a Retrospective.

In our book, Scrum 101, we introduce Sprint Retrospectives as:

[An] opportunity to inspect and adapt. Each Retrospective is time-boxed and should be held at the end of each Sprint, before the next Sprint’s planning session.

The whole team should be involved, including the Product Owner and Scrum Master. The Product Owner is present only in the capacity as one of the team, not as a dominant force in the meeting. The Scrum Master usually plays the role of facilitator.

A Retrospective’s focus is to consider how well the newly concluded Sprint went. In terms of processes, collaboration, tools, etc, not in terms of judging the results of what was produced (keep that for the Sprint Review) or an individual’s performance. There are many ways of running Retrospectives but the broad goals, regardless of style, are to identify:

• what went well (so you can keep doing it), and
• where there is room for improvement.

What makes a great retrospective?

At a recent meeting of LADG we asked the group to create a list of dos and don’ts for Retrospectives. We managed to create loose groups, but don’t take too much notice of them and feel free to create different ones yourself.

Preparation

• Communicate date/time well ahead of retrospective (including location)
• Make it a regular and unavoidable event
• Make sure it’s a comfortable environment (e.g. heat, seating, room size, snacks?)
• Make sure the technology (e.g. audio visual, online conferencing system) works beforehand
• Establish who is going to facilitate beforehand
• Prepare anyone else that you want a specific contribution from (if necessary)

Structure

• Vary the format
• Explain agenda at beginning
• Establish structure at start (e.g. set time, phases) OR have less structure (e.g. lean coffee format)
• Agree ground rules
• Give clear instructions for any exercises
• Time-boxed
• Keep to allocated time (of overall session and any segments)

Safety and voice

• Make sure people feel safe to talk (maybe start with the Prime Directive)
• Show respect
• Encourage an open culture
• Make sure everyone has an equal voice
• Give everyone a time box to speak (without interruption)
• Don’t be dismissive
• Recognise that every individual’s experience is valid
• Don’t filter people’s ideas
• Keep focused on relevant topics (e.g. don’t start planning the next Sprint)
• Don’t lead the conversation
• Show vulnerability / admit weaknesses
• No blame culture

People

• Whole development team is expected to attend
• Team should decide who else should attend (e.g. don’t let external stakeholders invite themselves)
• Vary facilitator (allow people to volunteer)
• Make sure that everyone is mentally in the room (i.e. no phones, laptops)
• Everyone physically in the same room OR everyone remote (i.e. if someone is remote then everyone dials in – even those in the same location – so that it is the same for everyone). This point had a lot of discussion but I think we agreed that, if we had a choice, we would prefer everyone to be in the same location for the retro
• Get an external, independent facilitator to run some sessions

Actions

• Don’t have a preconceived idea about the outcome of the retro
• Generate actionable items as output
• Make action points clear
• Link actions to hypotheses
• Assign owners to action points
• Don’t have too many action points (~3 seems to be a good number)
• Keep actions visible after the retro
• Go through action points at the start of the next retro (to see if situation has improved)

Do you have any further comments? Please add them below.