Let’s Go Retro: How To Run An Effective Project Retrospective
Here’s a good mantra for your project retrospectives: “Sometimes you gotta look backwards to move forward.”
You’re inching closer to a project due date. The sponsor is expecting to see your awesome deliverable presented on time, under budget and with all the bells and whistles they asked for.
Your project team is working towards meeting their overall project and individual goals. You as the project manager are hoping you can hold it all together.
D-day finally arrives. No — we’re not talking about an amphibious beach landing to retake territory, we’re talking about deliverable delivery date. You and your awesome project team have managed to complete the project and your stakeholders are happy.
Like many project managers you are probably going to need to complete some project closure activities like archiving documentation, invoicing the client, performance reviews for your team, and of course the most important thing — the project retrospective.
Wait, hold up — the project retro is the most important thing at the end of a project? What about the end of project team celebration?
While everyone likes a good party, it’s also very important to do a project retrospective with your team when a project has reached its conclusion or a significant phase or milestone has been completed.
In this article, I’ll go over what a project retrospective is, what an agenda for a successful retrospective meeting could look like, and answer some questions you may have.
I’ll cover:
- What Is AProject Retrospective?
- How To Run Project Retrospectives
- Project Retrospective Meeting Agenda
- FAQs About Project Retrospectives
What Is A Project Retrospective?
If someone on a project team says “let’s have a retro”, they don’t mean let’s throw an 80’s themed party (although, as mentioned, everyone loves a great party and the 80s did have some amazing music and movies).
A project retrospective refers to a formal activity where project stakeholders are asked to look back on the project and reflect on what went well, what didn’t go so well, and what could be improved.
As one of the key agile events, or ceremonies, retrospectives are “the time the team spends together to assess how they are working together and define steps to improve that process. It needs to be a “safe place” where people are able to speak openly and honestly” (PMI).
Being able to get people to be open and share feedback can sound easy on paper, but how do you do that in reality?
Take into account that people have feelings and during a feedback session like this, honest (and possibly unpleasant) feedback may be shared. How do you also encourage the introverts and quieter people on your team to speak up and participate?
How To Run Project Retrospectives
Let’s take a look at some practical steps and advice for how to facilitate an effective retrospective session for your project.
Step 1: Build a culture of trust
As mentioned, getting people to be open and provide feedback can be hard. It is even more difficult to do when there is distrust among the project team and stakeholders.
- In the past, was feedback criticized?
- Were team members made to feel intimidated by sharing ideas and feedback?
- After feedback was shared, were negative actions taken that may be viewed as punitive (for example, taking away certain perks)?
- Was the blame game played if problems were uncovered?
If you answered yes to any of these questions, these are definite reasons why there may be mistrust and an unwillingness to be open.
So how do you get people to be open and share feedback? How do you build a culture of trust and make people feel they are in a safe space?
You can try the following:
- Encourage open and honest communication: Ensure that your team feels that they are valued and appreciated. What they have to say is important. If people feel this way, they may be more willing to open up and share if they know they won’t be ignored or marginalized
- Create opportunities for collaboration: These could be daily project status check-ins or non-project tasks like a team building activity. If people are given opportunities to collaborate, they will be more comfortable communicating
- Make feedback part of the team’s culture: In software development projects, it is common for team members to have their code peer-reviewed by others on the team as part of the regular development process. Is there something similar that can be done on your project? Are there opportunities for the team to get and receive both positive and negative feedback on a regular basis? If they are, look to add these to the project’s schedule and processes.
Step 2: Determine what type of feedback you would like to collect
A lot happens during a project and as such, there is a lot of opportunity to collect a broad spectrum of feedback during a retrospective. This is okay, but it can also be overwhelming.
When planning to do a retrospective, it may help to define the scope of the feedback you would like to receive from participants.
It might be helpful to define some themes that you would like to collect feedback such as:
- Team performance: How did the team perform during the project? Were deadlines met? Was the work of quality?
- Communications & Stakeholder Engagement: Was information shared to the right people, at the right time, using the right tools? Was it too much or too little information?
- Project deliverable: Did the project deliverable meet the expectations of stakeholders? Why or why not?
- Project processes and tools: Did any processes help or hinder project performance? Were processes missing or too much? Were the tools used in the project helpful or harmful?
Step 3: Set a dedicated time for the project retrospective
If the retrospective is going to be done at the end of the project, there will no doubt be competing demands on everyone’s time during this phase.
As such, it’s important to set aside and schedule a retrospective at a dedicated time when participants will be available. If possible, try and schedule and send out calendar invitations (or ‘save-the-date’ appointments) a few weeks in advance.
Likewise, when scheduling your retrospective, it is helpful to send out your agenda with the invitation too (which we will get to soon).
Also, if there are any expectations for participants (for example if participants are required to complete any pre-meeting tasks such as downloading a specific software tool), it is good to also include this in your invitation.
Project Retrospective Meeting Agenda
A retrospective does not have to be a super complicated activity. The purpose of a project retrospective is to gain feedback on the project to make continuous improvements for your next projects.
As such, here’s a sample agenda that can be used and tailored based on the length of the session:
- Welcome and introduction: Welcome participants to the session, introduce the facilitator, and state the purpose & objectives of the session
- Overview of how feedback will be collected: Provide a brief summary of how feedback will be collected during the session (oral, written, hybrid, anonymous, etc) and what tools will be used (a virtual whiteboard, roundtable discussion, etc)
- Review any rules of engagement for the session: Let participants know of any ground-rules (for example: feedback should be constructive and honest, provide both positive and negative feedback, etc.)
- Collect feedback: Capture the feedback you wish to collect using your desired tool
- Review feedback with participants: Review all feedback collected (the good, the bad, & the ugly). During this part of the session, feedback should only be presented. Questions and discussion around specific feedback points should be limited (this is to ensure that all feedback is reviewed and time is not spent on 1 or 2 items)
- Discuss feedback and questions: Gather thoughts, opinions, and responses from the participants. Do they agree with the feedback? Is there additional insight/context that needs to be shared? Discuss and capture the results.
- Formulate actions and next steps for improvements: Based on the feedback presented, are there some steps and action items that can be taken by the project team to make improvements. During this section of the session, detailed plans on how the improvements will be implemented do not need to be discussed (this can be done in a follow-up session). Ask for volunteers to take ownership of any follow-up actions or improvement items
- Summarize feedback and improvements: Before ending the session, it’s good to do a quick summary and highlight the feedback captured in the meeting notes and any next steps or actions that will be taken
- Thank-you and session adjournment: Thank the participants for their time and feedback. Also, if there are any follow-up sessions that may be scheduled, share the details. Likewise, share information on where the feedback collected during the session will be stored and if it will be available to participants later (for example, on a shared GoogleDrive).
FAQs About Project Retrospectives
What is the difference between a sprint and project retrospective?
A sprint retrospective is an agile event that is completed at the end of a sprint or increment. The purpose of a sprint retrospective is to examine what improvements can be made to the processes for the subsequent and future sprints.
As sprints are time-boxed events (ranging anywhere from 2 weeks to a month), a sprint retrospective will generate feedback and improvements from a short period during the project’s timeline, whereas a project retrospective looks at what went well, what did not go well, and what improvements can be made for future projects based on the entire project timeframe.
Should You Include The Client?
That depends on the type of feedback you wish to capture during the project retrospective. If you are seeking feedback on the project’s communications, stakeholder engagement, and deliverable(s), then yes. If it is on the project team’s performance — maybe, but likely not. This is up to the discretion of the project manager and team.
Who Should You Run A Project Retrospective?
One could assume that the project manager or Scrum master should facilitate a retrospective session. Ideally it can be any member of the project team that is willing to facilitate the session and, if required, complete any of the preparation work. If the retrospective session may bring up negative or controversial feedback, a neutral-third party facilitator can also be used.
In an organization I previously worked at, project managers would be asked to facilitate retrospective sessions for other project teams within the organization to ensure a neutral facilitator, but to also allow the team’s project manager to fully participate in the session as a stakeholder.
What Tools Can I Use for a Project Retrospective?
There are some great tools available for organizations to use to conduct retrospectives. Here’s a few recommendations.
Online Collaboration/Whiteboards
- Miro or Mural: both of the tools allow users to create virtual whiteboards and canvasses for teams to post their feedback. Ideal for remote teams.
- IdeaBoardz: Free and easy-to-use tool that allows users to create customizable online boards for retrospectives and feedback gathering anonymously via virtual sticky notes.
Retrospective Software
- Atlassian Confluence: Online collaborative workspace that has built-in retrospective templates. Good tool to use if an organization is using other Atlassian products such as Jira
- GoRetro: Customizable, agile retrospective tool that offers many free templates
For in-person or on-site retrospective sessions
- A white-board and erasable whiteboard markers
- Post-it-notes
- Flip-chart paper
- Camera phone to take pictures of the whiteboards or flip chart papers to save for later & share
What is the Difference Between a Retrospective, Lessons Learned Session and a Post-Mortem?
A lessons learned activity is similar to a project retrospective. Based on the waterfall project delivery methodology, a lessons learned activity is usually completed during the closing phase of a project. The intent is to document any useful lessons and learnings for improvements that can be utilized by future project teams.
Retrospectives come from the Scrum (agile) delivery methodology and are mostly conducted at the completion of an increment or ‘sprint’. They serve the purpose of asking a team to reflect on what went well, what did not go well, and what could be improved based on the completed increment.
Retrospectives aim to uncover improvements that can be acted on immediately, whereas lessons learned activities provide inputs for future improvements. Alternatively, if a project has ended prematurely (whether it was canceled before the scheduled end or was not completed successfully), a post-mortem may be done to determine what happened during the project.
Does a Project Retrospective Have to Be Done at the End of the Project?
No — a project retrospective can (and should) be done at any point during a project. If a significant milestone or phase has been completed, it may make logical sense to schedule a retrospective. Likewise, if something has gone wrong during a project, a retrospective can be done too. The important thing is that feedback is captured and that steps and actions are taken to make any necessary improvements.
Feel Free To Go And Do A Retro (Or Be Retro If You Like)
Now that you know what a project retrospective is, you can conduct one with your team to get some valuable insight and feedback. They are a good opportunity to engage with your team and stakeholders and to improve on the overall quality and efficiency of your project.
No need to go back to the 1980s, unless of course you’re a fan of big hair, Bon Jovi, and the moonwalk. If you have done a retrospective for your team and would like to share your experience or tips & tricks, connect with me on Twitter or LinkedIn.
Make sure to subscribe to The Digital Project Manager newsletter for more on retros and other handy tools and strategies for project management.
Originally published at https://thedigitalprojectmanager.com on December 21, 2022.
