How to run our first post mortem?

Question

I'd like to do a post mortem ("lessons learned") analysis of a recent feature development. It would be the first formal post mortem we do. It was a comparedly small project (roughly 3 weeks), but surfaced enough problems worth analyzing.

A bit of background: I'm probably the typical lead developer becoming responsible for project management. Involved are 3 of the 7 software developers (me as manager, the product manager of the feature in question, and the developer implementing it).

I'm looking for general suggestions, but here are some questions I'm unsure about:

• Should other developers / roles be involved, or just us three "affected"?
• How much "preparation" should be expected, and what kind? (I'd probably list the "flow of events" and problems I see to give a starting point. Should I ask the other gys to prepare that as well, or would that put to much pressure on the meeting itself?)
• Time allocated? I'd expect an hour.
• What outcome would one expect - e.g. a half page "was good / was bad / ideas for improvement"?

Answer 1

Let me start off by saying I prefer using the term Retrospective rather than Post-mortem. The latter is too negative and implies the project is dead and we're looking to find the cause of death.

You'd usually like to get out of a retrospective session with a list of lessons learned containing changes to existing processes as well as things that went well and that you'd like to maintain and nurture in the existing processes going forward.

Preparations
I like to prepare for the retrospective by defining a short list of items the team would like to analyze and discuss. This involves sending out in advance a request to the team for topics for discussion. You should review the topics and choose the ones that are more frequently raised. Publish the final prioritized list of topics ahead of the session so people can come prepared with facts, opinions and suggestions.

The session itself
It's important to set some ground rules for the session itself. You should maintain a positive atmosphere and avoid finger pointing. The main focus is to come up with lessons learned and optimizations for the processes rather than finding who's to blame for whatever happened in the project.
When analyzing a topic, first get to an agreement on the facts, i.e. what really happened. You'll soon find out that different people remember different things (and also percept the reality in a different way). Once you have the facts straight, analyze what was good about it and what can be improved. Put focus on the process rather on a specific example or incident. Then you should try to generalize the analyzed scenario and try to figure out what changes can be introduced to the existing processes to deal with situations like the one you're analyzing.

After the session
It's important to send out the list of insights, decisions, and lessons learned after the session is over. It's even more important to take action and actually adapt your processes according to the lessons learned. This way the team will soon learn that the retrospective is really a great tool and a means for them to affect the processes. If you're working in an Agile environment, the retrospective is something you're doing regularly. I found out that when we adapt our processes as a result of good retrospective sessions, in the subsequent retrospectives the team is much more engaged and people come up with really good ideas for improvements.

Answer 2

I try to jot down problem points in a notebook as I encounter them, to be able to easily enumerate them after. I usually briefly describe them in the agenda; if you ask me, a post mortem should very precisely target the specific pain points you've encountered, and not so much be a general discussion of how you felt it all went. If you're the only one shouldering PM responsibilities, then I'd say it suffice to say that the other invitees are welcome to make additions to the agenda, if they feel you've missed something.

The time needed of course depends on the number of points you want to discuss, but keep in mind that it also depends on the number of people you invite. I try to keep my meetings focused around the small groups of people whose particular expertise are of most interest to the task at hand. Opinions from a broad range of people is a good thing, but a post mortem is not the place for it.

Your "was good / was bad" is a part of the process of finding out ideas for improvement, if you ask me. It has no place in the actual outcome. What I'm looking for with meetings like this is to pin down exactly what we can do to make sure that the problems you've encountered are addressed in an ideal manner. Perhaps some items were due to error during configuration that will in the future be automated, and no action needs to be taken. Other issues might have higher probabilities of reappearance. The key should be actions to prevent that problems you've faced occur again.

Answer 3

The best post-mortem is a team post-mortem. The project manager sees things differently from developers, and developers see things differently from each other.

I would recommend you give everybody a heads-up a day or two in advance, and ask them to prepare and bring points -- three positives (things that went well that we want to keep) and three negatives to try to improve in the future.

Then in the post-mortem, run through everybody's items and see which ones appear again and again. These are easy candidates to focus on, and represent a team-wide acceptance on what went well and what didn't.

If you're prepared, you can have a ton of discussion in an hour, even with a large team. I've done this in a team of 12 and we had more than enough time in an hour.

Answer 4

This might not be very relevant here but I think the best “post mortem” is a “pre mortem”. A pre mortem is when you do not wait for a project to fail. Instead you take the team in a room while the project is running and you tell them “Assume we have moved ahead 2 months in time and the project has failed. What according to you are the reasons which caused the project to fail?” This is a fun exercise because everyone knows the project hasn’t failed, but at the same time it allows people to express their opinions on why it might. It is an excellent way to bring out potential problems in a project before they become urgent issues.

Answer 5

I often use the Sticky Note technique: get everyone together in a room (not only the team but also important players of other involved departments), give them a pack of sticky notes and let them write everything they think about. Each thought on a different note.

• What went well
• What could be better

After 20 minutes collect everything on a white board and cluster them. Just as Ashes explained, focus first on those things that reappear most frequently.

Answer 6

I used to work at a company where post-mortems were fun, and we looked forward to them.

• A clear list of issues is prepared. This can be collected during the project or polled for (verbally or by email) after the project.
• List of issues is disseminated before the meeting.
  • No names are mentioned. Not in the list and not at any time during the post-mortem process.
• All guilty parties, along with relevant managers are invited.
• A nice cake - or other favorite food - used as the centerpiece of the round table, along with drinks and popcorn.
  • The joke was that a nicer cake meant that more things went wrong.
• Issues are brought up one at a time, and typically the person responsible would fess-up and say: "it was my fault. It happened because of x, y and z". (Facts, causes, but no names.)
  • Classically this causes other people to say: " Actually it was my fault, because of a, b and c". (Facts, causes, but no names.)
  • If nobody owns up then the PM can set a good example and own it: "I guess as PM I should have prevented this from happening. I wonder what caused it to happen".
• A short discussion then ensues to figure out how to prevent it recurring.
  • At no point does one try to figure out whose fault it was.
  • Not every item on the list needs to have a solution.
• After the meeting, the lessons learned are disseminated as widely as needed.
  • It's not always necessary to include the thing that went wrong.
  • It's never necessary to include people's names.
  • It sometimes makes sense to include the rationale.

It goes without saying that nobody gets punished for any mistakes that are discussed.

While it's great to have lessons learned that all teams can implement, and they become corporate culture, typically the post-mortem generates a few items, with owners.

These Action Items should be tracked and followed up on, to ensure they are implemented.