Agile Retrospectives versus Project Post-Mortem – 5 key differences to be aware of
Have you ever wondered why Agile teams hold the event called the “Retrospective”? Have you asked yourself how this event is different from the traditional project lessons-learned or “post-mortems”? Is “Retrospective” just a fancy name for the same old boring activity of rehashing project failures in a meeting room filled with team members who are eager to get started on their next project?
If you have ever thought about these questions, this article will help you gain insights into what a “Retrospective” is, how it works, and why it is a critical aspect of your Agile adoption. Having a solid understanding of this domain will enable you to help your organization and teams achieve greater levels of success. To keep things generic, I will use the term “iteration” as a general term for a fixed timebox.
| Characteristic |
Agile Retrospective |
Project Post-Mortem |
| General Cadence / Timing |
Once per iteration |
Once per project phase, or per project |
| Entry Criteria |
Experience from previous iteration (typically 4 weeks or less) |
Successes and failures over several weeks/months of work |
| Focus of Discussion |
Reinforce positives, identify improvement opportunities |
Identify major failures, celebrate unique successes |
| Participation |
Core project team |
Management plus project team |
| Exit Criteria |
Action items for incremental improvement |
Document that is typically stored away and not leveraged |
Key Difference #1 – Cadence
A typical project post-mortem occurs once per project, usually at the very end of the project after all the work has been done and all the decisions have been made. The intent/objective of this meeting can vary depending on the nature of the project and the cultural norms. Some project teams celebrate successes while others tend to simply “check the box” because it is required by the Project Management Office in order to formally close out the project. The value from this event is questionable since the data collected is usually stored away in a cryptic repository somewhere and never referred to again.
In contrast, an Agile Retrospective is designed to enable the team to inspect progress and processes, and make adjustments that can often increase the probability of success for the team. This event takes place iteratively and consistently throughout the life of the project, which allows the team to make changes to how they work. The team is encouraged to innovate and come up with better ways of getting work done, which improves overall team performance.
Key Difference #2 – Entry Criteria
A project post-mortem typically utilizes the data gathered from the entire project to evaluate where things went well and where failures occurred. This can potentially include several months (or years) of data that is very difficult to sift through and make sense of for a future project. In my experience, many projects do not maintain very thorough documentation which makes it even more difficult to derive value out of a post-mortem discussion.
An Agile Retrospective, on the other hand, takes a focused look at a much shorter period of time, usually two to four weeks of experience. This enables the team to examine the processes that were followed to identify things that worked well as well as areas that did not meet expectations.
Key Difference #3 – Focus of Discussion
More often than not, project post-mortems are either a big celebration or a “witch hunt” where the person who contributed to the failure of the project is criticized for the negative outcome. In my experience, there are very few times where the focus is placed on future improvements and learnings that may improve future performance.
The focus for an Agile Retrospective is placed squarely on identifying potential improvements and making a commitment to do something different in the immediate future so that the team can continuously get better as a collaborative unit.
Key Difference #4 – Participation
Engagement and participation for a project post-mortem can vary greatly across different organizations. Most of the teams that I have worked with tend to involve senior management who is typically not directly involved in the project itself, but is there to either give praise to the team, or find out which team members missed their commitments. In either case, the dynamic can vary greatly.
Having direct engagement from the people doing the work, an Agile Retrospective encourages collaboration and teamwork to identify how the team can work together more effectively. The general feel of the forum is usually positive, especially for teams that have a solid foundation of trust in each other.
Key Difference #5 – Exit Criteria
As I alluded to earlier, a project post-mortem typically generates a document of positives and negatives, and is usually stored away somewhere, never to be seen again. The learnings that were gained from this experience is usually not capitalized upon since it is usually very difficult to locate the documentation when a new project is initiated.
In contrast, the output from an Agile Retrospective is a short list of action items that the team would like to take in effort to make immediate improvements. The data is fresh and is leveraged almost immediately, which significantly increases the value of the information as well as the process.
In summary, there are many elements of an Agile Retrospective that can be applied to any project, not just Agile projects. Even projects that follow a Waterfall model can benefit from implementing iterative feedback loops; if applied at the right stages within a Waterfall project, the Retrospective format can provide valuable insights into what is working (or not working), and empower the team to make course corrections that will enhance project success.
So, next time someone asks you if you plan to conduct a “lessons learned” or “post-mortem”, why not give the Retrospective a try and see how it works for your team?
Agile Coaching Workshop (ICP-ACC)
View Course
