Learn from your mistakes with postmortems

Perfection is unattainable–especially with a software development project. Eliminating all mistakes is simply impractical. The real goal is to learn from the mistakes that are made so those mistakes can be avoided in the future.

Companies that observe best practices for retrospectives and postmortems gain valuable insight that give them a strategic advantage over competitors:

“Stuff” happens. It’s an imperfect world, especially when it comes to software. No amount of safeguards or preparation can prevent every possible incident, and sometimes simple human error can have significant consequences to a development project. You can’t avoid it, but you can learn from it and take steps to minimize the chances of a similar incident in the future. The question is how software organizations can best go about learning from mistakes with agile postmortems.

Retrospective or postmortem?

There are two methods of analyzing the past to learn and improve that are prevalent in business today: the retrospective and the postmortem. There’s a fair amount of confusion when it comes to the terms “retrospective” and “postmortem.” You can also add the phrase “after action review” to the list of terms that many people use interchangeably.

To muddy the waters further, the retrospective is an evolution of a traditional postmortem, and now a new deep postmortem has emerged as an evolution of the retrospective.Developers conducted postmortems before agile but only at the completion of a project, sort of the final step before closing the book and moving to the next project. The retrospective applies that concept throughout development, but there’s still a need to do a deeper dive after the fact, which has led to the new and improved postmortem. In the age of DevOps and continuous development and deployment, though, a project may never really be “complete” and the opportunity for a postmortem may never occur.

Andrew Storms, VP of security services at New Context, describes the retrospective as a component of the agile development methodology. He says that the retrospective occurs at the end of an iteration or sprint within the project development lifecycle, an opportunity for the team to get together and talk about what went well and what could have been done better. A list of action items is created and the team is empowered to enact the changes necessary to improve.

A post on the Software Process and Measurement blog illustrates the difference between a retrospective and a classic postmortem: “The differences between agile retrospectives and postmortems boil down [to] 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 [as] a means of validating and maintaining a standard process.”

According to TK Keanini, CTO of Lancope, they’re similar or interchangeable to an extent. He styles the postmortem as simply the final and last retrospective for a project that has concluded. “The key differentiator for me is in the term ‘mortem,’ whereby something is dead or the process finality has happened, and one individual or the team can look back at it in its entirety, whereas a retrospective can happen retroactively at every step of the way.”

Check out the complete story on TechBeacon: Making the most of mistakes: Best practices for Agile retrospective, postmortems.