We should use project postmortems to improve our software process. But few teams do, and fewer teams reliably learn from project postmortems. You can introduce postmortems to your team easily with a timeline postmortem process. If you are already doing postmortems, a timeline-based approach may improve your results.
- Takes little time (a few hours).
- Has a high degree of software engineer acceptance.
- Provides immediate feedback into your development process.
- Increases team cohesion and rapport.
- Reduces finger pointing.
You've got to accentuate the positive
Eliminate the negative
Latch on to the affirmative
Don't mess with Mister In-Between
-- lyrics by Johnny Mercer
Inevitably, something goes wrong on projects. Ideally, something else goes right. On the next project, you want to prevent the failures from reoccurring and reproduce the successes. This is why you need postmortems.
Most teams don't use postmortems. The teams that do don't always get value from them. Frequently, postmortems have a habit of either turning into "the blame game" or whitewashing mistakes. A bad postmortem can create dissention and institutionalize mistakes.
A good postmortem builds team rapport, rewards project successes, and improves the next project after it. Good postmortems are rare, but they don't have to be. Whether you're introducing postmortems to a team that doesn't use them, rescuing a failed postmortem process, or improving a successful one, timeline postmortems can help.
The complete timeline postmortem process takes three to four hours of team time plus a little preparation for the moderator. The process produces results that are immediately applicable and focuses on primary benefits. You'll be able to introduce incremental change that the team can adapt to rather than reinvent the entire development process.
In keeping with this philosophy, the process elements can be separated and introduced one at a time.
The basic steps of a timeline postmortem are:
- Create the project timeline.
- Walk through the timeline, identifying successes, failures, and "themes" of the project.
- Group successes, failures, and themes by project phase.
- Adjust your software process to address the failures and recreate the successes.
- Only implement process changes that affect the immediate future.
- Revisit the postmortem when subsequent projects enter a new phase.
Key Elements of the Process
Here are some valuable things to keep in mind:
- Separate actions from interpretation and stay away from fuzzy "why" questions like "Why did that fail?" Instead, ask "what" or "how" questions like, "What happened to cause it to fail?" or, How did it fail?"
Creating a timeline of project events allows the team to talk about events and process without pointing fingers. Getting agreement on the timeline first, without any analysis, keeps the later discussions from devolving into "did not/did too" exchanges.
In addition, the timeline becomes the "official truth" for the team. Shared history increases "teamly-ness." Just the act of creating the timeline can resolve esprit issues after a difficult project.
- Give equal attention to each part of the project. Postmortems can easily shift focus to the pains of the final phases of a project because that's the freshest in the team's minds. A good timeline will remind the team of successes and failures throughout the entire project.
- Do a postmortem right after the project is over. You can use the timeline process before that if a project is stalled or failing. Waiting until another project begins provides a useful perspective.
On failing projects, set up a recommitment meeting when creating a timeline. Doing so implies that any issues are part of the past and focus should remain on the results rather than the difficulties.
- Always have an impartial moderator/facilitator. This moderator only asks questions and writes down answers the team agrees on. The moderator should not be contributing opinions.
If your company doesn't have someone impartial, hire an outsider.
If you have to lead the postmortem yourself, create a clear distinction between providing facilitation and providing your opinion. One good approach is to stand and sit when in a specific role: standing when asking for information and repeating what the team says, sit when giving your opinions. Have