How our Project Managers learn from each project.

Welcome to Retrospectives...reviewing a project in order to learn for the next one, a great way for both the Project Manager and their team to reflect on their projects. Tips on what to do before, during and beyond your next retro.

Planning the retro

Before getting started, consider what type or format of retrospective you want to run, 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/ways-of-working improvements that have meaningful impacts. Running the retrospective in a similar format each week is beneficial to the team as they become familiar with how it works. 

Have you completed a significant project milestone? It's valuable to make a moment out of a retrospective. Use it to draw out feedback and feelings from events that have taken place over a period of time. This can be as simple as defining a calendar period or (if you’re following a full scrum process) a sprint review where you show work achieved in the sprint. 

And if you’re running a retrospective over a long period of time, run short framing exercises; ask people to map their emotions, or their appreciation of how well the project work met the defined scope, throughout the project.

Running the retro

Depending on the retro’s format, there will likely be various comments from participants falling under different categories. How to run 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. Keep sections time-boxed and include:

• Introduction - maybe an explanation/recap of the retro model

• Framing - if needed

• Collect feedback - ask participants to add their feedback

• Review feedback- time for participants to read collected feedback

• Discuss feedback - often slightly longer, this is when feedback is clarified

• Actions and close

The amount of time allotted to each section will vary depending on the (time) period considered and the format used.

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

Reflecting on negative experiences is important, but because it’s a natural human tendency it's easy for a retro to put a disproportionate amount of weight and time behind negatives that occur. 

It’s just as important - if not more - for project teams to identify and discuss things they think went well. 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.

Closing the retro (dealing with actions)

As part of closing a retrospective, 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,” capture the first action and follow up with a meeting to discuss the issue with the relevent members. 

There can be a tendency to make solving the whole issue, an action. This can be a trap in busy work environments. ‘Large’ actions can be forgotten in favour of short-term gains, so 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. Also consider assigning owners, applying deadlines or timelines.

The retro 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 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.