The Post-partum Meeting

by Loren Larsen

Last updated: 4/20/2006

The field of software engineering uses the "post-mortem meeting" as a supposed best practice for identifying what went wrong on a project and fixing it. It's time to skewer that sacred cow. First, the name has got to go. Anyone using that term needs to think long and hard about what message you are sending to your team that almost certainly just finished putting in long hours and making personal sacrifices to get the release out. The message you are likely sending is "it's dead". The literal meaning of post-mortem is fairly obviously "after death". Now most software releases go out with some bugs, but hopefully they aren't dead on arrival.

So start by changing the name. Next adopt an agenda for the meeting that will really juice up the team and energize them. Try starting with a discussion about what went really well with the release and what the team is really proud about in the work they did. Hopefully you can keep that discussion going for a while and if you do this right, your team members will begin to get excited about their work and their team. Only positive stuff allowed. This sets the stage for the rest of the process. Remember - people must be in an excitatory state where they are noticing and sorting for what works.

Next you you begin to ask the question about what would we like the next release/project to be like that would make it even better? You can go in different directions here like - "What would make coming to work everyday fantastic?" Again the ground rules are that all comments need to framed in the positive, that is, it has to be framed in terms of what people want! Not what they don't want. Some examples of what to go for here:

  1. We could have fully automated regression tests
  2. We could conduct code reviews
  3. We could get 90% code coverage with our unit tests
  4. We could get the requirements defined up front so there is minimal change
  5. We could prototype the interfaces and get them validated with our product management/customer before we write all the code.

Not so good examples:

  1. We could have Fred work more hours.
  2. Bob could stop writing such crappy code.
  3. We could get some PCs that don't suck so we don't wait all day for compiles.

You get the idea I'm sure. With a little skill you can redirect, re-frame, or rephrase any of these off-base comments if they come up,ut honestly if you've done the first step well of guiding the group into the excitatory state (and being there yourself) you really aren't likely to see much of this come up in my experience.

The next step is to identify the gap between the current state and the desired goal that has been proposed. Remember to keep phrasing things in terms of what is working. For example if the desired goal is to have all the check-ins to your source control system actually get stored correctly 100% of the time (yes there are still systems out there that struggle with this), then the current situation is what? Yeah it's something like - The check-ins to source control work 95% of the time.

Now, what is the gap? On the surface it's "we need to get that extra 5% of check-ins accurate". Now here is the tricky step, you really want to build a full, detailed representation of what it will be like to have 100% reliable source code. You really want to visualize and articulate as a group what that will be like. Once that has been done you want to ask, what was has to be true in order for this to be true? There are actually a number of different questions that are useful here, but we'll stick to this one as an example. In this case you might get multiple items like "We would have to have a new source control system" or "we would need a reliable server" or....

The end result of this last step is that you want to build a plan to get from the current state to the desired state and you want to have minimally the NEXT ACTION identified as to what has to be done to begin making that happen AND you want someone to be responsible and accountable for making that happen.

So to summarize the process it goes something like this:

  1. Discuss and inventory what worked on the project. This phase exits when everyone is in the excitatory state.
  2. Identify the new desired state. This is a fun brainstorm session and I usually run this until people begin to get just a bit tired and the ideas stop flowing as quickly.
  3. For each desired state you want to work with, identify the current state in positive terms, the desired state and what is missing.
  4. Build a plan to get from current to desired with at least a next action identified and someone accountable for taking that action.

First I will acknowledge that I have shamelessly adapted this process (well not adapted much) from the Satisfaction Cycle(tm) developed by Dr. Joseph Riggio.

If you would like to comment on this article please click here