Let’s face it, unless your development process or self-control has utterly failed, nobody died.
The purpose of a postmortem is to meet and review a project, release, or other situation with the goal of reflection and development. To put it simply, you want to work out what went well and how to repeat it, and what went badly, and how to prevent that from happening again, or to mitigate it if it does. You can think of this process as being similar to a performance review for a team or project in a particular situation.
A postmortem shouldn’t devolve into finger pointing or shouting, or leave anyone walking away feeling miserable or full of rage. It’s not a kangaroo court, held purely to assign blame. Neither should it resemble the traditional Festivus “Airing of the Grievances”. People shouldn’t dread coming to postmortems, or they will avoid doing so.
Don’t just run postmortems for projects that have failed or otherwise been problematic. Run them for the successful projects as well. It’s important to capture what the team did that went well and made the project succeed. Make a postmortem part of your normal process: the bookend to a kickoff meeting.
Here, then, are some tips on running a constructive postmortem.
The ideal postmortem happens soon enough after the event that everybody remembers what happened. You need to balance this with giving people enough time to reflect and, if things have gone badly, to calm down. A few days to a week afterwards is often about right.
Typically, a postmortem will be led by a project or release manager, or lead developer or sysadmin. If you’re reading this, this may well be you.
If you have strong emotions or opinions about what’s happened, I’d recommend getting them out beforehand. You can do by working out stress in whatever way appeals to you: writing a long angry email and then deleting it, going for a run, talking to a friend or spouse, or spending an evening gunning down zombies. The main thing is to have vented whatever steam you have built up before arriving at the meeting, or writing the agenda.
Have a detailed agenda. I’d suggest:
- Set the scope of what you’re talking about and stick to it. If the topic is Release X, say that upfront. Don’t stray off into general problems that exist with, for example, relationships between the development team and ops or marketing.
- Write down some facts about the topic. This might include the timeline, who was responsible for what, and links to any external documents (project plan, budget, or bug reports, for example).
- What went well? Even in the worst situation, something probably went well. Did the team work well together? Did all your boxes stay up under load? If they crashed, did your monitoring system tell you so? Seed this with a couple of items beforehand and add to it during the postmortem.
- What could have gone better: Remember, avoid finger pointing. Chances are, if someone screwed up, they know it. If they are oblivious to personal poor performance, bringing it up in a group meeting won’t help, and you’ll need to address this via other avenues. Focus on tasks and items that failed or could have gone better, not people who could have done better. Again, seed this with a couple of items.
- Suggested improvements for next time: This is the best and most constructive part of a postmortem. Given the facts that have just been discussed, this can be a brainstorming session on how to work better in future.
- Actions : Improvements will go nowhere without actions. I recommend each action has an owner, a deadline, and a deliverable, even if it’s just emailing the group with the result of your research.
During the postmortem
Begin by making sure everyone understands the parameters of the meeting. Your job as leader is not to do all the talking or share out the blame, but to go over the facts, and make sure people stay on track.
If the discussion gets too heated or off track, go to your happy place, put down the Nerf gun, and get people back on the agenda. Sometimes you can achieve this by asking people to take a long, heated, or irrelevant discussion offline, or simply by saying “Let’s move on.”
You might be surprised at how creative and constructive people can be, especially in the face of failure. I think the best, most constructive postmortem I have been involved in was the one after my biggest disaster. Engineers and sysadmins hate to fail. Focus on problem solving for the next iteration.
These discussions can be draining. I tend to coast on adrenalin after a release or crisis, and only hit the post-adrenalin exhaustion after the postmortem. It’s not a bad thing to schedule a postmortem just before lunch, or at the end of the day, to give people a chance to relax and refuel afterwards.
Author’s Note: I originally drafted this post as part of an idea for a book last year. I still hope to write that book at some point, but I thought it would make a good blog post in the meantime.