How Do You Run a Postmortem?

Our process has failed us! The payment feature went offline, our team doesn’t have shippable code, and a user story has been in progress for two weeks. In order to deliver software at a consistent pace, it is essential that agile teams iterate on how they work. Below I describe the steps to facilitate a retrospective to address these problems.

So that this post is useful as a reference, I have made each facilitation step a header followed by a recommended time box.

Setting A Goal (2 mins)

Before the team can go about improving its process, the facilitator should focus the team on a specific part of the process that has gone awry. Take a few moments to set the goal of creating action items. This allows the team to solve the problems that will be discovered.

Make sure each team member has a stack of sticky notes and a sharpie marker. Ask them to write legibly, so that everyone can read their thoughts on the whiteboard. They should also limit one idea per sticky note.

Draw sections on the whiteboard for facts, wins, problems, solution ideas, emotes, and action items.

Facts (5 mins)

First, let’s establish what has occurred. Ask the team to spend five minutes writing sticky notes on the details of what has happened with a recent process mishap. Invite the team to leave emotions and opinions out of their phasing. Words like good, bad, difficult, and easy, shouldn’t be used. There will be an opportunity to express opinions and solutions soon. It is also useful to focus on process and not target teammates.

Once five minutes has passed, go around in a circle and ask each team member to share one sticky note. Invite everyone else to shout out simliar ideas or plus ones and pass their sticky notes forward. Group them on the whiteboard under the “facts” section.

After grouping all similar facts, move to the next person. Do this until everyone has read out their facts.

Sorting Facts (10 mins)

Now that the team knows what has happened, spend 10 mins going over each fact and asking the team “Is this a win or a problem?”

Ask them to shout out their opinions. If people disagree, invite a short discussion. If the discussion goes on for more than a minute, place the fact into a parking lot (a set of topics for another meeting).

Do this until there are no facts left unsorted.

Ideas (5 mins)

Now it is time to generate solutions. Briefly restate each problem, ask the team to brainstorm solution ideas on sticky notes. Make sure to direct that you would like one idea per sticky. Timebox this activity to five minutes.

Set the expectation that the team will only attempt one solution per problem. Trying to change the process in too many ways can create problems and make it difficult to see the actual solution.

Numbering each problem will make facilitation easier, allowing you to quickly see which solutions map to which problems. Ask the team to add the number of the problem to their solution sticky.

Starting with the first problem, go around the room and collect all brainstormed solutions. Once again grouping them if there are similar ideas.

Emoting (2 mins)

Before the team determines which solutions to attempt, give them the opportunity to express themselves. Invite the team to spend 2 minutes drawing how this process failure made them feel. It could be an emoji face, a image or whatever they imagine — but no words please.

Collect the emotes and place them on the whiteboard under the “emotes” section.

Action Items (As much time as needed)

Now it is time to chose how to attempt to remedy our problems. From top to bottom, go through each problem that has contributed to the mishap. Ask the team to chose a solution to try during the next iteration. If the discussion is contentious use dot voting to settle on what to try.

Once all of the ideas are converted into action items, read out each one. Find ways to make them specific and concrete. If the actions can’t be more specific, that is okay. After the meeting, make sure to put them on a whiteboard near the team’s workspace and go over them each morning.

At the end of the next iteration, help the team decide if the actions helped solve the process problems. If not, have another retrospective.

If the assigned action items don’t get done by the next two iterations, erase the action items.

Conclusion

Continuous improvement is an essential principle in agile software development. Improvement is easier to achieve if the whole team owns the process. Allowing the team to come up with their own solutions is one way to do that.

I hope that this post based on the 6 Thinking Hats, helps your team improve today.

• process