Retrospectives: Retrospectives vs. Classic Postmortem, a Difference in Mindset

The team owns the results of a retrospective!

Early in the adoption of Agile of someone will often ask, “What is the difference between an Agile retrospective and the classic postmortem?” Three mindset differences stand out in particular: action, permission and ownership.

Action:
Tim Lister made one of the most important comments I have ever heard on the idea of “lessons learned”. Tim said, in essence – if the end-of-project lessons learned were really important, then we would begin every project with an obligatory reading of lessons learned. I have never seen that ritual performed. Agile retrospectives occur at point of usefulness, rather than at the end of the project. They are about changing how the project is being done now rather than about how a project might be done later. The bias in the Agile retrospective is for taking action today rather than action tomorrow.

Permission:
The second major mindset difference is a focus on the meeting the needs of the Agile team, rather than addressing the needs of the standard process. Agile retrospectives focus on how work is being done today which involves scrutinizing team skills, capacity and processes. The retrospective is about finding changes that will allow the team to deliver more value than the last sprint. The team is in charge of identifying and making changes. The team doesn’t need to ask for permission to make changes. In a classic postmortem, because the focus is on the standard process, the team can only make recommendations. Why the focus on the standard process? Because classically at the end of a project teams are disbanded and reformed, therefore findings that involve how individuals work together do not make sense.

Ownership:
This final mindset difference may sound a bit repetitive, but it is not. An Agile retrospective is a team tool, whereas the classic postmortem is done for the organization (e.g Engineering Process Group or management). Postmortem attendees can include anyone involved in the project or supporting the process. Classic postmortems collect information about the project for later use. Whether metrics, process improvement recommendations or lessons learned, the information is collected for posterity. The deliverable of a postmortem is a formal report that may well become shelfware. Participation in an Agile retrospective generally only includes core team members – the Scrum Master, the development team and the Product Owner. The only deliverable generally created is notes that are taken needed to plan actions for the next sprint or about obstacles that the Scrum Master will focus on removing. Any documentation that is created is for the team and not for consumption elsewhere.

The differences between Agile retrospectives and postmortems boil down differences in mindset. Agile retrospectives have a bias for action. Agile retrospectives are about making changes in how work is being done. The team does not need permission to make the changes demanded by an Agile retrospective. Finally Agile retrospectives are done to help the team, rather than a means of validating and maintaining a standard process.

Retrospectives: Obstacles

Retrospectives: Listing Techniques

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event

Software Process and Measurement