Postmortem is a Latin vernacular meaning after death. It originated on the medical field and is the technique or public inquiry to investigate a dead body and determine its cause of death. From that perspective, a postmortem look at what went wrong since the individual is dead.
Since all disciplines borrow practices from each other, Project Management eventually engaged in this end-of-projects analysis to examine the challenges a project has been through, so that good learning can come out from it and mistakes would not be repeated. Postmortems are a matter of continuous improvement in project life.
A postmortem, however, is not a retrospective. Here are some ways in which they greatly differ:
Retrospectives happen at the end of every iteration
A retrospective takes place at the end of every single iteration of a product or service development. That cadence for iteration can be defined by Sprints, for teams running on Scrum, or any other time-period for non-denominational Lean-Agile frameworks, including Kanban.
The purpose of the retrospective stems from the continuous inspect & adapt cycle and having it at every sprint, or short iteration, allows for multiple improvements to take place throughout the development while also simplifying the analysis of the data gathered, as every iteration being short and having a specific challenge content, we have less inputs and smaller scope.
A postmortem will give closure and it happens at the end of the project. This difference in the timing means that no matter how long a project took, we wait until the end to investigate. This increases complexity as people either have to keep a mental or physical log with the main events of a project and many of the discussions and learning will not have any leverage, as the project is now over. The learning can only be used for future endeavors and the team might not be the same.
Retrospectives do not require documentation
A retrospective will be action-oriented: all the preparation, all the data collected, all the interactions have as an objective to improve by next iteration and solve or try something specific> Many times there might be a clear owner for the task. This task can end up on the team board or be managed in some other way. Even though teams can and oftentimes do collect insights or actions from their retrospectives into virtual spaces or team walls or even documents, they are not required to do so. Having learned what was there to be learned and having decided what to do next, the team now frees headspace to actually start the next iteration’s work.
A postmortem does require documentation; it becomes the final photograph of a project as per the team and the management folks that conducted said project. Points raised in a postmortem will make a formal list of claims and acknowledgements that the project will be known for and that is the intention from all parties: client, team, management. Being documented is part of the very nature of a postmortem: a document to register the main facts after the fact. The lessons can be broadcast and systemic errors recognized and avoided from now on.
Retrospectives can be facilitated by anyone
In Scrum and other Agile teams a retrospective will be facilitated by a Scrum Master or an Agile Coach but that is not mandatory. The premise of those being the facilitators come from the fact that their main goal is to enable the team to grow and improve. Their time investment is not about products, deliverables or services. They focus on the team. Therefore, they have more time to analyze a sprint and try and figure out suitable formats and design the experience for their team to have an engaging learning time together.
Postmortems are traditionally run by a figure of authority, the project manager or another manager and the focus is somewhat more organizational. This is not a hard rule and technically a team member can facilitate a postmortem. However, the challenge arises given the audience and the global scope of a postmortem. A lot is to be captured; some of what is of interest for the activity oftentimes comes from outside of the core team, which not everybody has access to. Someone with a broader view of the project impact, participants and stakeholders is better suited for hosting it.
Retrospectives focus on team improvement
As a natural part of improving, retrospectives go beyond “what went well? what went wrong?” questions. It might start like that, it might even be sometimes phrased like so, but a retrospective has a holistic focus on improvement. That means that what went wrong is actually less important than why it went wrong and how we can avoid falling into similar traps. We look for patterns. We look for behaviors. We also look, very enthusiastically, on what went well, and once again, looking for the deep roots of that perceived success.
A retrospective will always focus on team improvement. Both are keywords: team and improvement. That means that analyzing team member’s feelings, dealing with conflict, strong and engaging interactions are a fact. TDD and continuous delivery are very important, but they go hand-in hand with other creative approaches a team can come up with to address challenges they experience or even foresee: practices can be created, not just adopted.
In a postmortem it is rather unlikely that deep human issues will be singularly addressed much less resolved and ideally the outcome will focus on the suggestion, adoption, or at least acknowledgement, of best practices and guidelines. Usually the group involved has more chances of growing technically, as per the scope of this gathering.
Retrospectives look to the past, the present and the future
When adopted in project management, postmortem was at first an approach to see what went wrong in the project so that the mistakes would no longer be repeated in future projects; the lessons learned were collected. It has evolved immensely, but it cannot defy some physical realities, such as the fact that the project is now over and that the team might not even be together again for a second run.
In Agile teams, however, the retrospective being a constant presence, is actually a space to look back at any given point in time, to look at today’s events and the current sprint and even better: to project into the future, the so-called team “futurespectives”. They are an actual space of creativity and openness in which team members are invited to ambitiously dream about what makes them successful and happy and devise strategies to get there. It is in exercise in growth.
Now, these were my five picks on how retrospectives and postmortems differ. I would point out without making a special section for it, that the audience is also key. Not everybody is invited to a team retrospective. It is basically the team’s moment to acknowledge to hopes and dreams, to failures, own up to their shortcomings and be vulnerable. Therefore, one final, key difference between project postmortems and team retrospectives is about who attends the gathering.
It would be really interesting to see other differences and even a conflicting opinion stating that retrospectives and postmortems are the same. That I would be even more curious to understand why!
