The Definitive Guide to Agile Retrospectives and Post Mortem Meetings

Excellent firms don’t believe in excellence–only in constant improvement and constant change.
– Tom Peters

No team is perfect, but every team can steer ever toward more meaningful and more impactful work. The best way we know to do this is through a Retrospective meeting. A Retrospective is an occasion for your team to look back, reflect, and plan to work better, together. This guide is meant to break down the process into simple steps that can provide concrete actions for your team.

Every team should be conducting two forms of Retrospectives:

1. The Process Retrospective (aka Post-mortem): At the end of every project sprint or deliverable, the project team involved should look back, create a timeline of the work, and reflect on specific points along the way that were either positive or negative to the outcome of the work.

2. The Team Retrospective: At the end of every month, each department should reflect on its rules, habits, and processes to identify better ways to work together.

The Most Important Part of Any Retrospective Is the Tone

Looking back on the work, especially for a team that hasn’t done it before, can often devolve into blame-storming, scapegoating, or excuse-making. A Retrospective is only useful if you can set and maintain a tone of civility, productivity, and objectivity. Remember, a Retrospective is not the place to single out under-performing team members or pass judgement on other teams inside the business. A Retrospective is an opportunity to look back with the intent to work better as a collective in the future.

How to Conduct a Process Retrospective

1. Draft the team. Identify the people who participated on the project or deliverable. Not every single person MUST attend, but ensure you have a representative selection of both skill set and hierarchy. We think it’s best to keep these meetings to less than ten people, so you might need to break the group up and conduct multiple Retrospectives.

2. Schedule at least 90 minutes for the Retrospective. Trust us, this will be time well spent.

3. Hold a role election. Like all meetings, be sure to start the meeting by electing a Facilitator and a Scribe. Ask the group to vote by writing names on Post-it notes. Remember, it’s the role of the Facilitator to move the meeting along and the role of Scribe to capture key learnings and next steps.

4. Generate major milestones. Give everyone five minutes to silently generate major milestones and deliverables from the project, such as project kickoff, brief development, resourcing, client interviews, launch, etc.

5. Put together a timeline of the work. If you’re the Facilitator, collect the major milestones/deliverables and chart them on a wall (with Post-its) or a whiteboard. Talk through the process with the team to get it right, and to identify milestones that the team might have forgotten.

6. Identify what worked well. Have the team identify moments or actions in the process that worked particularly well to advance the project or the team itself. Give everyone three to five minutes to silently reflect before sharing. As each person shares, give everyone else the opportunity to ask probing questions (e.g. ‘What do you mean by …?”) but don’t let it become a debate. Respect the point of view of the person sharing and move on. Record these moments above the project timeline with a smiley face. Examples: Things moved so much faster because we all wrote the project brief together in a single workshop; OR final approvals were easy because we designated roles at the outset of the project.

7. Identify what didn’t work. Have the team identify moments or actions in the process that slowed, obstructed, or harmed the project or the team. Give everyone three to five minutes to silently reflect before sharing.As each person shares, give everyone else the opportunity to ask probing questions (e.g. ‘What do you mean by …?”) but don’t let it become a debate. Respect the point of view of the person sharing and move on. Record these moments/actions below the project timeline with a sad face. Examples: The project hit a roadblock when we realized we didn’t have enough designers to do the work given our timeline; OR we bit off way too many features and functions in this first release and were burned out before we were able to put something in front of our users.

8. Brainstorm improvements. Now you’re about halfway through the Retrospective, and it’s time to put the team’s feedback into a more actionable format for future projects or deliverables. Give everyone five minutes to silently generate suggestions for approaching the work differently. Specifically, ask the group to mold their suggestions into one of two formats: Policies or Projects. A Policy is a rule that the team should follow for all future projects (e.g. “All briefs should be written by a cross-functional team”). A Project is an initiative or action someone on the team should complete, likely before the start of the next project (e.g. “Source freelance design help in case our internal team can’t get to the work quickly enough”).

9. Let the team discuss. Ask everyone on the team to share their suggestions for Policies and Projects, and give the group five to ten minutes to reflect and react. Encourage honest and direct feedback, but don’t allow members of the team to use this process to berate, belittle, or blame other members of the team. If you’re the Facilitator, use your best judgment to guide the conversation toward constructive, specific, and actionable feedback.

10. Group and rank the suggested improvements. After the team has had a chance to reflect, then it’s time to decide what Policies and Projects should be enacted moving forward. Start by asking the team to group and vote on the suggested Policies and Projects. You’ll likely find overlap between suggestions, so help the group consolidate and simplify the Policies and Projects suggested. For the sake of time and impact, we suggest identifying the top three policies and three projects to focus on in the next step.

11. Make decisions. Now it’s time to make some challenging decisions. More hierarchical teams may want to escalate the group’s feedback to a senior leader for final decision, but we suggest that these decisions be left to the team doing the work. If you’re up to let the group in the room have final say, then we suggest the following criteria:

    1. Projects: If someone in the room is willing to “own” the project, meaning they are willing to rally the people necessary to do the work and they are willing to be held responsible for whether or not the project is completed, then consider the Project approved. Quickly ask anyone in the room if they have a specific concern about the project (e.g. “We don’t have the budget to hire freelancers right now”) that the project owner can follow up on after the meeting. These concerns shouldn’t kill the project, but the project owner should work to identify compromises or creative solutions to any concerns. In the event that no one in the room wants to “own” a specific project, as Facilitator, suggest that this project be scrubbed or put on hold.

    2. Policies: Because a policy is a rule that everyone on the team must follow and enforce, a policy should only be accepted if the full team consents to it. As Facilitator, take each policy one-by-one and ask the group to share any questions, reactions, and objections with the person(s) who originally suggested the policy. Questions help the person add clarity to the policy. Reactions help the person think through unintended consequences of the policy. Outright objections (i.e. “This is patently unsafe for the business and our team”) must be confronted and a compromise must be reached before the policy can be accepted. As Facilitator, it’s your job to help the person(s) who proposed the policy and the person(s) who raised an objection reach a speedy compromise. If a compromise doesn’t seem possible in the room, suggest that the parties involved schedule a follow up discussion.

    3. Close out the meeting. Whew, last step! If you’re the Scribe, make sure you’ve captured the Projects that have been committed to and the owner of each project. Also, make sure you’ve recorded the Policies consented to by the team. Make sure your notes are distributed to everyone involved with the work, in a place or format that’s easily accessible to all team members. As Facilitator, quickly run through the decisions made by the team and congratulate everyone on their hard work and commitment to making things better.

How to Conduct a Team Retrospective

1. Draft the team. Gather the team you spend most of your time with on a day-to-day basis and/or into which you directly report. Like the Process Retrospective, we think it’s best to keep these meetings to less than ten people, so you might need to break your team up and conduct multiple Retrospectives.

2. Schedule at least 60 minutes for the Team Retrospective.

3. Hold a role election. Like all meetings, be sure to start the meeting by electing a Facilitator and a Scribe. Ask the group to vote by writing names on Post-it notes. Remember, it’s the role of the Facilitator to move the meeting along and the role of Scribe to capture key learnings and next steps.

4. Setup the board. On a whiteboard or wall, create three columns with these three headers: happy face, sad face, and a question mark.

5. Happy Face: Have the team identify habits, processes, policies, projects, and/or tools that make work better and the team a more cohesive unit. Give everyone three to five minutes to silently reflect before sharing. Examples: Using Slack as a chat tool cuts down on meetings; our project allocation process is a well oiled machine; our flexible work hours make it easy for me to spend time with my family and still get work done.

6. Sad Face: Have the team identify habits, processes, policies, projects, and/or tools that harm or hinder work and team dynamics. Give everyone three to five minutes to silently reflect before sharing. Examples: I have to stay late to try to catch senior managers for last minute approvals; our lack of process makes every project feel like we’re reinventing the wheel; or, we have too much process in place to be creative.

7. Question Mark: This one’s a bit tougher than the first two–have the team identify habits, processes, policies, and/or tools that are consistently used, but seem to provide no direct value to the day to day work. Examples: we have a daily status meeting but I’m unsure if it helps; we have personal goals but they don’t seem to influence what projects we’re put on; or, we use Basecamp to plan projects but I don’t think anyone ever checks back in on it.

8. Discuss. Just like in the Process Retrospective, now it’s time to let the group discuss and decide on how to move forward. Jump to Step Eight in the Process Retrospective to continue.

As You Gain Practice

After you have a few Process and Team Retrospectives under your belt, feel free to adapt our process to better suit your team and its unique needs. Ask your teams for feedback on these meetings and even consider conducting a Retrospective on the process itself (so meta!). Also, you’ll likely find yourself with a list of Policies and Projects that need to be amended–bring these into subsequent Retrospective meetings and let the team edit or remove them based on how they’re either advancing or hindering good work.

Remember: the only truly wrong way of running a retrospective is not to run one.