Rethinking the Product Post-Mortem

Post-Mortems have gotten a bad rap. Caling it a “post-mortem” certainly doesn´t help - any kind of meeting that conjures up an image of a bluish-gray corpse lying under abrasive lighting in an all-white room on a stainless steel table could probably use a tweak in the naming convention. But the act itself of bringing the team together to participate in an introspective activity to talk about what worked and what didn´t during the development of the product can be a powerful learning opportunity to impact the development of future projects.  Below are tips and best practices for getting the most out of these meetings:

Change the name

I was going to add this at the end but I simply cannot continue to write post-mortem in this post. Call it a retrospective (as I will here), call it a project conclusion meeting, project critique, a review -- any collection of words that don´t immediately conjure up death is a small, but important start.

Set the tone

 It is critical that the team is aware from the initial invitation to the meeting that the purpose of the retrospective is not a blame game. The purpose is not to point fingers at any particular person or group of people. Trying to figure out who is responsible for what went wrong with a project will inevitably lead to that individual becoming defensive, and shutting down all potential constructive conversation that could otherwise occur if they were feeling comfortable openly sharing their perspective. It isn´t worth it. Trust is critical in this exercise, and taking blame off of the table helps to build it. Norm Kerth, a highly respected software consultant and author wrote the book Project Retrospectives: A Handbook for Team Reviews which includes the “Prime Directive” which is extremely valuable to share with team members at the beginning of the the retrospective:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

At the end of a project everyone knows more than they did when they started, and we wish we could start over using what we learned. Kerth states that is wisdom to be celebrated, not judgement used to embarrass. Build a culture of trust. Take blame off the table, and get to the learning that comes from a successful retrospective meeting.

Require pre-work 

Have the whole team come to the meeting prepared. They will each have different perspectives based on their role in the project and what they share can impact future projects. The danger in waiting until everyone shows up in a conference room ready to “brainstorm” is that important pieces may be missed as conversations flow in various directions. Have the team come prepared with answers to these questions and/or ask them to send responses to the person running the meeting ahead of time. Keep it simple:

  • What worked?
  • What didn´t work?
  • What do you wish you knew at the beginning of the project you know now?
  • What should we do differently next time?

If you feel it necessary to give the option for some anonymous feedback you can set up an online review questionnaire to gather this feedback prior to the meeting. The person running the meeting will need to determine what/if any anonymous feedback should be brought into the live meeting (provided it follows the tone of a blameless retrospective). 

Start with the positive

It is natural in these meetings (especially if a project wasn´t successful) to immediately want to jump right into what didn´t go well and what the team could do differently for future projects. Most participants come prepared with a longer list of what they would have done differently than what they did right. Start on the positive. Beginning with what went well not only sets the meeting off on a positive tone, it praises the team for work that was really well done and acknowledges the pieces of excellence that should be carried over for future projects. Even projects that don´t hit their overall goals can have pockets of excellence that are worth sharing. And if you had a project that went swimmingly from start to stop? That´s worth the whole team (and other teams) knowing.

Keep it simple

A retrospective doesn´t need to be and shouldn´t be complicated. The pre-work questions above are the meat of the meeting. Below is a sample, simple agenda for an effective retrospective.

  • Opening - Repeat the Norm Kerth prime directive above to the whole team. Reiterate the goal is about learning from this project to impact future projects and NOT about blame. Trust, open communication and respect is required for this to run effectively.
  • What worked?
  • What didn´t work?
  • What should we do differently next time?

The question in the pre-work above regarding what the team wishes they knew at the beginning of the project that they now know will most likely come up during the portion of the conversation on what didn´t work. If not, it is worth asking this specifically to the team.

Keep it focused

A retrospective is only as effective as the moderator who is running it. The moderator is responsible for making sure conversations are on topic, the meeting is on time, and the tone of the meeting is constructive. A top priority of the moderator is to ensure that everyone´s voices are heard. The pre-work helps. Before going deeply into any one topic the moderator should ensure all topics are on the table and captured (note taker needed, and white boards are effective in managing the discussion live). One way to do this is to have each team member say one comment, followed by another team member, etc.  Once all topics are captured the team can spend the most time discussing those topics that surfaced from the most people.

Leave with action items

The whole purpose of the retrospective is to learn from what worked and what didn´t on a project so that it can impact future projects. Leave with a list of action items, along with who is responsible for these items and the time-frame expected.

DON´T WAIT FOR AN OFFICIAL POST-MORTEM!

While a well-run retrospective is an effective way for the team to uncover processes that worked and/or didn´t work to help impact future projects, the best teams will include a more agile approach to their development process that allows them to adapt and impact a product that is CURRENTLY in development . Why wait until a product launches to have these meetings?  An easy way to start is by introducing a simple process into your regularly scheduled team meetings:

  • What do we need to START doing on this project?

  • What do we need to STOP doing?

  • What do we need to CONTINUE doing?

The best teams learn from their successes, their mistakes and from each other. Retrospectives help.  We can as well. Reach out if you would like to discuss how we can work with your teams to learn from the successes and failures of previous product launches to positively impact your next one.