Putting retrospectives in perspective

January 13th, 2023   |   Ian Arrowsmith

Retrospectives are a great way to capture learnings and create a moment for teams from a period of time working on a project or initiative. Here are a few thoughts on what to do before, during, and beyond your next retrospective to set your project team up for success.

Before the retrospective

Before getting started, consider what type or format of retrospective you are looking to run; as with a lot of things, it’s all about context.

Are you working with a scrum team delivering in sprints? In this case, a retro can be critical to identify actionable process and ways of working improvements that can have meaningful impacts. In this situation, running the retrospective in a similar format each week can also be beneficial so the team becomes familiar with how it works. 

If, however, you’re part of a team that has completed a significant project milestone, it may be more valuable to try and make a moment out of a retrospective, using it to draw out feedback and feelings from events that have taken place over a period of time.

Don’t forget to frame your retrospective—this helps people reflect over the time relevant to the retro. This can be as simple as telling people what calendar period the retro will cover ahead of time. Or, if you’re following a full scrum process, a sprint review where you show work achieved in the sprint will be helpful. 

Suppose you’re running a retrospective over a long period of time. In this case, run short framing exercises, such as asking people to map their emotions, or their appreciation of how well the project work met the defined scope, throughout the project.

During the retro

Depending on the retro’s format, there will likely be various comments from participants falling under different categories. Regardless of your format, here are a couple of pointers for running an effective retro.

Manage the allotted time 

Gathering a project team for a retrospective can be a significant use of everyone’s time, so the momentum of the retro itself is important. Keeping sections time-boxed can be useful. Typical sections include:

  • Introduction—this might be an explanation or recap of the retro model

  • Framing—if needed

  • Collecting feedback—asking participants to add their feedback

  • Reviewing feedback—time for participants to read collected feedback

  • Discussing feedback—often the slightly longer section as this is when feedback is clarified

  • Actions and close

 The amount of time allotted to each of these will vary depending on the period considered for the retro and the format involved.

Chairing a meeting can be tough. It’s worth considering inviting an outside chair who might be better placed to manage a team through the process, rather than anyone too close to the project.

Look for bright spots (as well as negatives)

Humans have a natural tendency to focus on the negative. Reflecting on negative experiences is important, but because it’s a natural tendency, it is easy for a retrospective to put a disproportionate amount of weight and time behind negatives that pop up. 

It’s just as important, if not more, for project teams to identify and discuss things they think went well over a project. Success is not a given or easy to recreate. If your team did something well, identify it and reinforce it, so it has a greater chance of happening again. If it’s not something that’s been celebrated yet, also take some time to do so.

Ending the retro and beyond

Make some actions (where possible)

As part of closing a retrospective, try and capture some actions. For example, if your team identified reviewing pull requests as something that prevented them from working as efficiently as they could, an action might be to ensure all team members review pull requests each day. 

Or if something was identified as a more significant problem, such as: “We don’t have a strategy for providing stable test environments,” just capture the first action. That might just be having a meeting to discuss establishing stable test environments with those needed from the team.’ 

Sometimes there can be a tendency to make solving the whole issue an action. This can often be a trap in busy work environments. ‘Large’ actions will often get left to the wayside in favour of short-term gains, so try and keep your initial actions small. They still have a higher chance of being completed, and the overall issue that might be behind them has a greater chance of gaining momentum.

Other good practice around actions should also be considered, such as assigning owners, or applying deadlines or timelines.

Do the follow-up

If you organised a retrospective or helped chair one, you have a responsibility that carries on after the retro has happened. For it to be truly successful, it’s really important to check in with the team to see if actions have been followed up and changes have happened.

If it’s a case of running a team in scrum or a team that regularly works together, this might happen more naturally than it does after a one-off retro, but try to make the time to follow up.

Making change happen is hard, but it can be the difference between success and failure. Any energy and momentum you can provide to help move towards success is extremely valuable and will positively affect your team.