I'm planning to introduce project post-mortems to the business I work for. I think they will improve development-client relations. Encourage feedback and improve the quality of service to clients.
However as I have never done them before I don't have a format to follow.
What is the Post-Mortem procedure you use?
Are there any anti-patterns with post-mortems?
Retrospectives have worked well. Google for (agile retrospective) for reading. A retrospective is a periodic review of what went well and what went wrong. There are books http://www.pragprog.com/titles/dlret/agile-retrospectives and blogs galore on the subject. You might start here: http://agilesoftwaredevelopment.com/blog/peterstev/start-trust-start-retrospective
I'll second the Agile Retrospectives book. I've done several different formats, including After Action Reviews, and I like the collaborative nature of the retrospective. Here's a post about our experiences with the first one I ran for our current team:
http://www.cornetdesign.com/2008/07/agile-retrospectives.html.
My friend James Carr is also posting his experiences, like this one:
http://blog.james-carr.org/2008/08/15/adventures-in-agile-retrospectives/
The key is to set ground rules. We used the Focus On/Focus Off to come up with a list of things we needed to, well, focus on during the retrospective, and focus off of.
I spoke to Diana Larsen at Agile2008 about our meetings and after her thoughts I'll probably change some things about our retrospectives but how we've been doing them is to first ask just how everybody felt about the last sprint. Usually we know how we all felt since we're a small team but it's good to ask. Nothing gets written down, it's just done informally.
The meat of our meeting is what we call the Good, Bad, and Ugly (GBU). Good is obvious, it's the stuff we liked and we thought went well. Bad is stuff we could have done without but wasn't horrible. Ugly is ugly, it's stuff we wish we could forget or will have a big impact on the project. Sometimes it's hard to distinguish between Bad and Ugly but we try. We write down everything from all 3 of these sections of the meeting.
In the next sprint's retrospective, we go over what we wrote down for Bad or Ugly and see if it's gotten better or been fixed. Our Scrum Master is pretty good about getting things taken care of if needed so things rarely stay problems for long.
Depending on how we're feeling, sometimes we do Ugly first, then Bad and Good. This is only so we don't end on a bunch of downers by doing Ugly last.
Diana suggested adding Stage Setting and Data sections to the meeting to make sure we're all on the same page as far as what happened during the sprint before we go into the GBU. I'm going to try a timeline where everybody puts notes on what happened when during the sprint. I like that format since we do 4 week sprints and it's sometimes hard to keep track of what happened at what point.
You'll need a big pile of index cards in three different colours. (We use yellow, green and pink).
First stage, we draw a timeline on the whiteboard. Everybody gets to stick the yellow index cards on the timeline marking important events in the release cycle. The idea is to jog everyone's memory as to what happened during the release, and prepare them for the next section.
Second stage, everyone writes down the good and bad points of the release. Green cards are for good things, pink cards are for bad. Generally we try to make sure everyone only puts the two or three most important cards (to them) on the wall.
Step three. Everyone gets the chance to vote, by putting check-marks on the cards that are most important to them. Number of votes per person is usually a function of how many candidates we have to vote for.
Once the votes are in, we go through the top-voted issues and discuss them. The aim is to come up with concrete actions that will either ensure the good stuff gets better, or the bad stuff goes away. The important thing is to come out of the meeting with clear "next steps" on each issue that are assigned to specific individuals to accomplish.
We actually do a cut-down version of this procedure every month, to keep an eye on things that might be impeding development as we go.
Post Implementation Reviews (PIR) are very useful in improving your project delivery, improving your relationship with your clients, and are also a useful place to park issues during the project.
A PIR should have a clear agenda (using cards, a series of questions etc) and should use an impartial facilitator. This person should not be the client, the PM or a team member. They all need to participate.
Once the PIR is complete it's a good idea to create a small paper on the Lessons Learned from the project that should include all the input from the PIR. These are both excellent tools for working out what you did and didn't do well, plus when starting the next project you have some excellent assets for planning.
I have written a template for this which i use (Google Docs or you use the original PIR document). The main headings to analyze what you did well and poorly are;
1. Benefits Delivery (ROI, NPV targets, met requirements?)
2. Scope (were deliverables clear, management of scope changes)
3. Schedule (actual vs planned completion dates, was schedule realistic and clear?)
4. Costs (approved vs actual, capital vs expense, management of budget changes)
5. Quality (was the appropriate level specified and met, was there an appropriate quality plan?)
6. Communication (was there an agreed plan?, examine major stakeholder groups and how they were communicated with, any missed stakeholders?)
7. Staffing (were roles/responsibilities clear, sufficient resources?)
8. Risk (Risk Management Plan?, Risk Register (with mitigation), Risk Reviews?)
10. Procurement Management (was there a plan?, make or buy analyzed?, seller evaluation?, appropriate contracts opened and closed?)
Schedule post-mortems frequently, after a phase or a short cycle. Have them as close to the end of a phase as possible--don't wait or everyone will forget what happened.
Prepare a timeline of events for your phase and circulate before the meeting. Review it briefly to start the meeting to make sure nothing major was left out. This helps people remember and frames the discussion.
Keep the bulk of the meeting simple. Do the "what went right/what went wrong". Although ending on the "right" seems like it will make people feel better at the end of the meeting, resist the urge! Studies show that the right-first/wrong-last structure is better at eliciting the right information.
Don't try to solve any issues in the meeting. However, do try to parse what are root causes versus symptoms.
Pick a consensus top 5 issues to resolve for next time. Assign ownership (this is the most important step, or nothing will get done). Next time around review the issues you were supposed to have resolved.
Keep the meetings on the order of an hour long. If you have a large group (more than 15-20 people), consider splitting into multiple sessions. Anonymous questionnaires are good for those who may not be able to attend, are shy, or fear repercussions. That said, if you're managing this, make sure you don't shoot the messenger--you're going to get opinions, and all opinions are valid. That doesn't mean you have to give each opinion equal standing, but do look for trends that show a decline in morale.
A podcast I really enjoyed listening on retrospectives is on software engineering radio, with Linda Rising.
hey john, you are definitely on track to becoming a mature software dev house when undertake post-mortems (aka. lessons-learnt report in PRINCE2 parlance)
i have two templates, one is thorough (my preferred one), the other can be done in only a few hours( 2-3 hours)
use the short version if you are having trouble selling it to your manager
hope that helps
--LM