How you can use team, project and personal retros to create regular moments of reflection and opportunities to improve.

I’ve written about how you can evolve your product culture using many of the good practices that we use to develop our products. One of those is continuous deployment.

As with shipping code, making small changes to how you work regularly, rather than packaging up lots of change into a big bang release is normally most effective. Continual improvement is less likely to create disruption. It’s easy to roll back changes that don’t work. And it delivers the benefits immediately.

One of the best tools to help you create a culture of continuous improvement and understand if changes are effective is the retrospective.

At FutureLearn we used retrospectives in a few different ways to create regular moments of reflection. They enabled groups to discuss what was going well, what was going less well and collectively decide what to do about it.

Broadly, there were four different flavours of retros: product team retros, discipline team retros, project retros and personal retros. I’ll talk through each of these in turn.

With all retros the key to making them successful is to make sure that they are a safe environment, free from blame where people feel able to honestly share. You can do this by reminding people of the prime directive originally coined by Norm Kerth:

The prime objective should also apply to personal retros.

We ran end of sprint retrospectives from the very first sprint at FutureLearn. It was a great way to consciously define the product culture we wanted and then iterate it. As we grew from one to multiple cross-functional teams, we continued to use end-of-sprint team retros as part of our agile process and encouraged teams to make improvements themselves.

These retros followed the classic model of things that went well, things that went less well and questions that had arisen. Teams spent a few minutes quietly writing thoughts on post-it notes before they were grouped into themes, discussed and potential actions proposed.

Regular retros make it easy to make changes. Teams can come to an agreement to change something and try it for a sprint and revert back if it doesn’t work. This helps people commit to making a change.

The key things to remember are to keep the list of actions small and to make them a specific person’s responsibility. Much like your sprint goals, if you try to do too many things at once, you’re likely to get less done and feel dispirited. And unless someone is accountable (preferably in the team) the actions might fall between the cracks.

Leadership needs to encourage teams to feel empowered to make their own changes. This might be by also being clear about what they can change and what they can’t.

Some things will be hard for teams to change on their own or independently of other teams. This means there needs to be a mechanism to have a dialogue with the product leadership team where teams can raise bigger issues and ask for help. This could be having regular office hours in the diary where teams can bring suggestions, simply raising them via one-to-ones or via a discipline retro…

Running less frequent retrospectives within the matrixed job disciplines is also helpful. At FutureLearn, we ran monthly retrospectives with the product management team. This was a great way for the PM teams to support each other and share specific concerns that they may not have with their cross-functional product teams or propose holistic improvements beyond team silos.

These followed a similar format to team retros: good things, bad things and questions. The whole product management team was present, including myself as the team leader, enabling me to get a good read on the big issues without being in any of the team retros. They provided a great mechanism to spot themes and issues affecting multiple teams.

PMs would take some of the agreed actions away. Sometimes they might agree to pair on solving the problem. Others would be for me to take back to the product leadership team to agree how to address them.

Alongside regular team meetings, Product Manager retros helped create a culture of mutual support and a sense of team, whilst the PMs spent the majority of their time in their cross-functional teams.

We also ran end-of-project retrospectives for big initiatives that involved people from across the organisation — not just the product teams. These are important to capture the things that you need to learn and change for the next project and see how the product organisation was interacting with others in the company.

These were typically longer than a regular retro (1.5 hour or perhaps 2 hours for big and complex initiatives) and required a little more planning. They normally began with collaboratively creating a timeline of the key milestones as a way to help people recall the key moments.

The facilitator, ideally someone not directly involved in the project, would crowdsource these from key people involved in the project before the session. They would then give the opportunity for everyone involved to review them and add to them at the start of the meeting. This was a good way of grounding the session and getting everyone to agree on a set of facts.

Things that went well, things that went less well and questions can then be stuck up on the timeline. This is an easy way to help group things into themes and then talk through them chronologically.

One fun technique you can use is to get people to draw a line as to how they were feeling at various points in the project. This created quite a fun visual representation of the emotional journey. It allows you to quickly identify where the key moments where everyone agreed things were going well, badly or spot times where different people were feeling very different things and then dig into them to understand why this might be.

If the project is a big company initiative, particularly one that went particularly well or particularly badly, it is really helpful if members of the leadership team are present to also hear the conversation and the key takeaways that need to be applied to future projects.

Often at a leadership team level why projects have gone well or less well is not always obvious, or can be distorted by different individuals’ perspectives. Taking part in a retro is a great way to get a much more complete picture and understand the key points to learn from.

Often the findings will require the leadership team’s backing to make a change so ensuring that they are part of the conversation to hear the key insights will help ensure that there is backing to make the improvements.

You can also use the principles of retros on a personal level. Finishing each week by taking a quiet moment to reflect on what went well, what you might have done differently and what questions it has posed is a really useful tool for self reflection alongside setting yourself weekly goals.

There are tools that encourage teams to do this — we used 15Five at FutureLearn — but simply doing it in your own notepad is just as effective.

Whilst continuous deployment is typically the least costly and disruptive way to make changes and retros are a good tool to support this, sometimes there is a pivotal moment of change that you need to make or embrace. In these situations you can also use retros to help your team feel empowered in times of extreme change.

Read more about how I used a ‘Big Retro’ as a tool to manage a seismic moment of change.