Deep Dive: Retrospectives

The term “retrospective” is prevalent for any of the Continual Improvement meetings, largely due to the popularity of Scrum. However, this post really refers to any meeting where a change to process is made. Whatever you might call this, it is very important, as I hope I will show in this post.

Why should the team do a Retrospective?

1. It allows them to talk about their feelings in a safe space (Social Connection/Relatedness)
2. It allows them to make small changes to their processes, to try to make their delivery better (Mastery/Competence)
3. It allows them to feel in control (Autonomy)
4. It allows them to step back and see what they’ve achieved (Purpose/Competence)

So a Retrospective gives a lot of the things that Self-Determination Theory holds are important for motivation (highlighted in bold in the list above). If you aren’t doing retrospectives in some form, then you are perhaps missing out on a chance to motivate and inspire the team, as well as not helping them to deliver more.

Who should run it?

There are a few options here:

1. An external (to the team) facilitator. This has the advantage of allowing each team member to equally participate. The disadvantage is that the team members may feel that the meeting is happening to them, rather than for them. And of course someone needs to arrange the facilitator.
2. A scrum master or similar. Advantages include that they are probably good at facilitating, and know how to help the team work well together, and that it is their role so they will make sure the meeting is organised. The main disadvantage is that it can dis-empower the  team (as above).
3. A team member. This has the advantage of making team members feel engaged with the process (especially if they each take a turn). It has the disadvantage of needing meta-coordination, and can lead to variable quality.
4. A manager. I think this is a bad idea as it reinforces the hierarchical ideas, unless the manager is a very effective Servant-Leader and able to keep her/his opinions to a minimum!

Who should be there?

Everyone interested in the team performing well. So definitely the team including Product Owner (or equivalent), and anyone else who might having valuable insights to share.

What should the outcome be?

The outcome of a Retrospective should be a very small number of SMART actions. A small number since the team can be considered a Complex Adaptive System, and as such according to Cynefin (and common sense) should be conducting small experiments rather than many large changes. By SMART, I mean Specific, Measurable, Achievable, Relevant, and Time-based. Sometimes these actions will be about how the team work together, other times they might be about improving the working environment, software, tools, or interactions with others. Whatever is important to the team at the time.

It is also very important that a Retrospective is FUN! The  desired outcome here is that the team want to do it again.

What should happen in a Retrospective?

I’d describe a good Retrospective as Serious play. By that I mean playful but about something serious, with serious outcomes. Tools like retromat give great ideas for how to construct these kind of playful sessions. In particular, using colourful postit-notes, images, memes and other creative tools can make the session feel more fun. For me the important parts are:

• Set the scene and let people check in. It is important here to get the energy levels up and frame this positively.
• Write down separately comments about the last Time Period in some form
• Allow people to speak about them
• Agree on important core issue
• Get the team to come up with and commit to a SMART solution or experiment
• Get feedback on the retrospective itself

I think it is important to allow people to separately write things down because it allows the less vocal in the team to say what they feel without interruption by the more extrovert. It also keeps the discussion wide initially, before narrowing. This intentionally mirrors the Explore-Exploit of “the bandit problem” which is often applied to innovation theory. Essentially with Retrospectives we are helping the team to innovate themselves.

How often should we do Retrospectives?

Scrum says once a Sprint, where a Sprint is usually between one and three weeks. However, the team should decide the frequency. More frequent Retrospectives give fast feedback, and shorter feedback loops, so if you are very “agile” then it is likely you will be doing this very regularly. I’ve worked in teams that have a Retrospective each week, and others that have a Retrospective only once month.And of course they can change the frequency whenever they need, through the Retrospective itself. It really depends on what the team wants (more often is better as it gives faster learning).