Postmortems vs. Retrospectives: When (and How) to Use Each Effectively
When we announced the launch of our Retrospectives Guide, we wrote about the value of scaling the continuous improvement mindset to beyond Product Development at PagerDuty by establishing the RetroDuty community. In this installment of our blog post series on retrospectives, I highlight the differences between postmortems and retrospectives.
You might have heard of postmortems and/or retrospectives before reading our guides. Both seem to accomplish the same goal—review what happened in a recent project or during your team’s most recent work cadence.
However, there are nuances between postmortems and retrospectives, so we’ll explore them in this post to help you and your teams get the most value out of either (or both) practices.
Difference #1: The Purpose of Postmortems vs. Retrospectives
Postmortems provide a peacetime opportunity for those involved in incident response to reflect on what they’re doing right, where they could improve, and most importantly, how to avoid making the same mistakes in the future in the incident response process. Postmortems are also the forum where you identify action that can be taken to make improvements to the affected systems and/or the incident response process and obtain buy-in to these action items to ensure they’re enacted.
Retrospectives provide teams with the opportunity to review their progress, pace, and delivery at a regular cadence set by the team. They’re meant to be a psychologically safe space where teams can discuss anything that affected their work and/or collaboration. From this discussion, teams decide on a couple of action items to address areas of concern or improvement and assign ownership so that the team is held accountable to enacting these changes and reflecting on their effectiveness in the future.
Difference #2: The Occurrence of Postmortems vs. Retrospectives
As stated in our Postmortem Guide, do a postmortem for every major incident (Sev-2/1), including any instance of triggering incident response. Postmortems are done shortly after resolving the incident so that the context is fresh for everyone involved in the incident response process.
In contrast, retrospectives are normally held at a regular cadence, at the discretion of the team. For example, at PagerDuty, the majority of our Agile delivery teams have retrospectives on a biweekly basis. After completing a major project or project milestone, the involved team(s) may also decide to have a one-off project or project milestone retrospective.
Difference #3: The Style of Postmortems vs. Retrospectives
Postmortems involve a blame-free, root-cause analysis and discussion between the teams directly involved in an incident soon after incident resolution has taken place. Reflection on the incident response process itself and discussion on areas for its improvement is another key aspect of the postmortem process.
Retrospectives typically involve informal discussion between the participants, be they team members or individuals from multiple teams working towards the same project or project milestone. The facilitator can choose from a wide variety of retrospective styles to most effectively direct the team’s conversation. Check out PagerDuty’s guidelines for selecting an appropriate retrospective style in our Retrospectives Guide.
Difference #4: The Discussion Topics in Postmortems vs. Retrospectives
During a postmortem meeting, the involved teams review the postmortem report to align on an incident’s causes, timeline, customer impact, and proposed follow-up action items. However, the discussion should not be overly focused on the immediate concerns documented in the postmortem report. After all, this time is best used to take a step back from the detailed analysis of the postmortem report to better understand the systemic factors that caused the incident. Thus, the highest-priority outcome of the postmortem meeting is obtaining buy-in for the action plan.
During a retrospective, participants have an opportunity to reflect on and discuss areas of strength and areas for improvement of how they work together. The team may also want to share their perception on how their last work cadence went and/or how they’re striving towards their project or project milestone goal(s) with each other. The key outcome of the retrospective is determining action items in order to continuously improve team interactions and processes.
Difference #5: Who Participates in Postmortems vs. Retrospectives
The postmortem owner is responsible for inviting key individuals who triaged and resolved the issue. This includes the incident commander, incident commander shadowee (if there was one), service owners and other key subject matter experts involved in the incident, engineering manager(s) and product manager(s) of the impacted system(s), and customer liaison (for Sev-1 incidents) to the postmortem meeting.
The retrospective facilitator is responsible for inviting the team(s) involved in the work cadence, project, or project milestone and any other necessary roles to the retrospective. Learn more about the role each participant plays in the retrospective here.
Now that you’ve learned the high-level differences between postmortems and retrospectives, take a look at our new Retrospectives Guide to learn how you and your team can make retrospectives a regular practice of continuous improvement. If you’d like a refresh on how to make lasting improvements to your systems and incident response processes, read our Postmortem Guide.
If you’re working in an environment that makes use of retrospectives, join the PagerDuty Community to share your best practices and tips. And if you’re working somewhere that doesn’t yet use retrospectives, maybe give them a try to see if retrospectives can provide value-add to your teams or even your organization—and then join our Community to share your experiences and learnings!