Let’s talk about project retrospectives! Project retrospectives (sometimes called post-mortems) are pretty loosely defined as a meeting held after the completion of a project during which you discuss your achievements and what the team can do to make improvements in the future. ‘Project’ could mean a contained project that is completely wrapping up, or it could be a phase or major milestone within a larger project.
Sounds pretty great, right? BUT…Is it possible to love figuring out how to improve as an individual and team, but still not love doing retrospectives? That might be me (and maybe secretly everyone).
Though retrospectives may seem simple in concept, they can also bring with them a few challenges to navigate.
- Even when the project goes really well, it’s easy for you and the team to feel like you’re mentally done with a project when it wraps. When your brain is ready to take a break from thinking about something that you’ve been immersed in for a long time, it can be hard to be motivated to take the time to think back, and rehash all of the details of the project.
- Talking about things that didn’t go well takes courage and candor that everyone on the team must be willing to offer.
- While talking about achievements as a team is fun and gratifying, discussing the root cause of a project’s pain points can be challenging to do without assigning blame.
Recently I went through a rabbit hole of research on the concept of a blame-free retrospective. I came across some really thorough resources, but ultimately felt like a lot of the proposed methods were extremely dense, formal, and downright intimidating. I was looking for a lightweight, casual guide to having a productive, freeform conversation with my teammates after a project. I ultimately decided to develop my own template — a set of loose guidelines that follow a two-step process. These guidelines are copied into a collaborative document and shared with the team a week or so before the scheduled retrospective meeting.
The first step is intended to be done asynchronously. It offers a few different options for noting observations which are intended to be flexible for different communication styles and sensitive to concerns which some folks may not feel entirely comfortable raising verbally in a meeting. It being a blame-free retrospective, it may go without saying that it’s not productive to call out an individual team or teammate during a retrospective meeting when discussing challenges. If legitimate personnel or team dynamic concerns arise, this template gives people a framework for reflection and an option to flag these concerns with the PM privately. It’s up to the PM to determine how or if these concerns can be raised productively and in a blame-free fashion during the retrospective.
The second step is intended to synthesize the observations from step 1 into actionable steps, as well as give space for additional questions and thoughts that may arise during the discussion.
You may wonder, “How is this template inherently blame-free?” In a lot of ways, that depends on how the conversation is led. Intentional moderation is so important. Whether the retrospective is led by the engineering lead, or the project manager (as is the case on our team), the focus must be on examining and improving process vs. targeting individual performance. Looking at pain points as a failure of process is essential in removing the blame from individuals when things go wrong. If something was overlooked in QA, then the QA process must be examined for blind spots or weak points, not the individuals who carry out the process.
The team must take ownership of the process, and share the responsibility of creating solutions when they are needed.
Also, an important value in the culture of &yet is inherent trust. It’s not really addressed directly in this template, but when we’re conducting retrospectives at &yet, we’re all coming to the table with a high level of trust in our teammates, and the understanding that everyone on the project has contributed to the project with the same goals and same commitment to success in mind.
In general, two main points encapsulate the mindset required for a blame-free retrospective:
- A focus on examining and improving process vs. individual performance
- An inherent level of respect and trust in our teammates
These guidelines have worked well so far, but I’m always looking to improve and iterate on the retrospective process as well. The concept of a blame-free retrospective is something that I’m very interested in, and would love to hear what has worked for other teams.
Project Retrospective Template:
Step 1:
Complete individually prior to the group discussion
Options:
- Posting directly in the doc prior to the meeting
- Making private notes to be shared verbally in the meeting
- Flagging concerns/thoughts/questions privately with the PM
List personal or group wins. What worked well?
What were the pain points, and how could the process* be improved to avoid these things in the future?
What was different than expected or surprising about this project, and why?
* ‘Process’ can be defined as: communication style or method, boundaries, tools used, where communication happens, workflow, etc.
Step 2:
Complete as a group during the discussion
Goals for ongoing or future work:
Actionable steps:
Questions or other thoughts: