One of the most important, and often most-overlooked, aspects of adopting a “little-a” agile culture lies in the application of continuous improvement practices.  By far the most important of these practices is looking back over past efforts so that we can identify root cause and propose remedial efforts. And while Scrum has this function built in on the team level, the sprint retrospective is insufficient to serve the needs of continual improvement of the organization as a whole.  As product managers, we owe it to the larger culture to engage in regular, structured post-mortem analyses when we hit significant milestones in our efforts. We need to extend the culture of continuous improvement beyond the development teams, and inure it as part of the entire organization.

Why Are Post-Mortems Important?

A good retrospective provides us all with an opportunity to take a step back from the constant go-go-go and think about how we’re getting from point A to point B (or not, as the case may be).  A well-structured post-mortem does three things: 

  1. It leverages our perspective of looking back from an end-point and using our 20/20 hindsight 
  2. It allows us to identify both successes that we had as well as the challenges that we faced
  3. It focuses us not on applying blame or making excuses, but on improving our processes so that we can avoid or mitigate some of the challenges should they rear their face in the future.

We all know the adage, “hindsight is 20/20” — usually used in a disparaging way to describe someone second-guessing the choices of another after the fact.  But post-mortem analyses allow us to leverage this truism and use its power to build up, rather than tear down. While we can’t predict ahead of time the problems that we might encounter, we can look back to how we got where we are and assess the process critically, leveraging that 20/20 hindsight.  From the perspective of a final destination, we’re best suited to examine the path that we took to get there, even if we did engage in some corrections along the way.  It’s only when we’ve got the context of the endpoint that we can really dig in on how we got there.

When we’re looking back with those 20/20 glasses, we want to make sure that we’re not just focusing on the negatives — which can be an easy path, since that’s what’s probably on everyone’s minds at the time of a post-mortem.  Rather, we need to be equally capable of focusing on and documenting the things that went well, the successes that we had along the way, no matter how small they were.  Continuous improvement isn’t always about stopping things that aren’t working well or that are somehow dysfunctional; it’s equally about identifying those things that we’re doing that are working, and ensuring that we continue doing them and communicate them to others so that they might know of different approaches that are proven successes.  This can actually be the hardest part of performing a good post-mortem, but it’s essential to obtaining the maximum value from the effort. If you’re engaging in a post-mortem but not finding anything that was done right, you need to try a little harder.

While we’re focusing on ensuring that we’re capturing good and bad, we need to also ensure that we’re looking back with a lens on the actual process that was used (or that wasn’t, in some cases) — it’s really not enough to just identify the mistakes that were made or the successes that were achieved.  We have to ensure that we’re creating plans and processes that will allow us to avoid repeating the mistakes that we made, as well as ensuring that we can repeat the successes that we achieved. It’s important to double-check that everyone involved understands that the goal of our post-mortem isn’t just a checklist of mistakes and successes that everyone can nod their head at and then instantly forget.  The whole point of a post-mortem is to identify process failures, validate stress-points, and assess weaknesses in our processes. If we don’t actually change anything coming out of a post-mortem, we’ve failed ourselves, our teams, and our companies.

Driving Down to Root Cause

The good thing about performing good post-mortems is that we already have most of the tools to do it right and extract value from the process.  As product managers, it’s our job to dig below the surface requests and issues that we hear from customers on a regular basis, and those skills are directly transferred to facilitating effective post-mortems.  If we approach post-mortems in the same way that we approach problem and customer discovery, we’re likely to achieve great success.

The single biggest failure that many teams suffer from when trying to perform post-mortem analysis is an inability or unwillingness to go beyond the surface-level considerations that are obvious to everyone.  The problem with this is that it’s rarely these surface-level issues that result in meaningful change — if all that we focus on is surface issues, we’ll never really improve the way that we need to. Sure, we might make some minor, incremental improvements here and there, but until or unless we dig in deeply and understand the actual, root causes of the issues that we encountered (and the successes we achieved), we’re really just wasting our time and the time of those engaged with us.  The deeper we can drive, the closer we get to the true root causes, the more likely the changes that we make to not only have significant effects, but to also have ripple effects beyond just the one obvious problem that we all identified.

One of the best tools that we have as product managers in situations where we’re trying to drive beyond the surface of any conversation is something I like to refer to as the “Five Whys”.  I honestly cannot recall where I first picked this up from, but it’s a tool that I’ve been using for over a decade. The principle is simple — when you’re engaged with someone or a group of people about a topic about which you want to drive down into the deep meaning, you follow up each answer with a simple question — “Why?”  And you don’t stop until you’ve asked that question at least five times. While this sounds like a game that a five-year-old might play, it actually works exceptionally well at making people think about the topic that you’re discussing.  If something went wrong, why did it go wrong? For that reason, why did that happen? Each “why” gives us answers that are one level deeper than the one before it, until we can’t go any further and we have the final, root cause.

In addition to using the tool of the Five Whys, we need to ensure that when we’re working through a post-mortem, we’re avoiding calling out specific people unless it’s absolutely necessary.  We’re not engaging in this structured analysis of successes and failures just to turn it into a blame session. Only in the most extreme of circumstances, when there’s no other root cause that we can identify, should we focus on a specific person as a root cause — and even when we think that’s the case, we should revisit that conclusion until we are positive that there’s no issue related to training, tools, or other considerations that may have led to the specific person causing issues.  We do this because ideally we’re eliciting feedback from the team members, and any indication that the result of this process is going to result in names being named and blame being laid might result in team members being less interested in cooperating and providing honest feedback.  Focusing on the what, not the who, is essential to a successful post-mortem.

Focus on Remedial Efforts

Ultimately, the end-game of a post-mortem isn’t just to come up with a list of things that went well and things that didn’t.  It’s not to create a punch-list of successes and failures. It’s not to gloat over our wins and cry over our losses. The goal of any effective post-mortem analysis is simply to identify things that worked so that we can keep doing them, and things that didn’t so that we can create plans and put in place remedial measures to mitigate the harm or prevent them from happening entirely the next time we do similar work.

It can be tricky to navigate the path from project to post-mortem, and there’s always a temptation to focus solely on the past events, both the good and the bad.  But that’s just a starting point — the real point of a post-mortem is to focus on the future, to put in place the kinds of remedial plans that will protect us from the problems of the past.  The best predictor of future outcomes is past performance — and the best means that we have to change the future is to identify patterns from the past so that we can prevent them from repeating.

But it’s not enough to just identify these changes that need to be made; we have to make sure that they’re actionable and acted upon — there are many post-mortems I’ve been involved in where the methods were solid, the information gained incredibly insightful, and the remedial efforts specifically targeted toward preventing future recurrence of past mistakes.  But then the next post-mortem raised similar issues. And the next. Because while we checked every single box, the people who needed to actually implement the changes failed to do so — there was no responsibility, no accountability, and thus there was no impetus to actually make the changes happen.  We need to make sure not only that we identify the root causes of issues, and not only do we identify what remedial efforts we could take to prevent them, but we must make sure that there’s a commitment to making those actions actually happen, to implement the remedial measures and not just give them lip service.

Go Forth and Do Good

Not every project needs a full-court-press post-mortem, but those that do deserve the attention and effort to dig deep, figure out what worked and what didn’t, and implement measures designed to repeat what worked and prevent what didn’t from recurring.  We owe it to our products, our teams, and our companies to do whatever we can to instill and reinforce a culture of continuous improvement, and one of the best ways we can do that is to run efficient, effective, and actionable post-mortems when necessary and appropriate.