Post-mortem recipe

A post-mortem can be organized when an opportunity to learn and improve arises as a direct result of an incident. It is in no way intended to assign blame. Make sure this is clearly understood by all participants.

Ingredients

• Team members involved with the change that needs to be addressed
• A meeting room
• Video call software (if the retrospective is conducted remotely)

Cooking

The following steps serve as guidelines for the discussion. Feel free to move between them based on where the conversation leads and wherever the most value is expected.

Ensure someone takes notes to capture important items or actions.

Step 1: Incident description

Describe the incident that occurred: What happened? Who was affected? What was the impact?

This helps frame the severity of the incident. For example, something discovered internally before the release will have less impact than a customer system failing in production. Understanding the consequences of an issue is crucial to ensuring appropriate corrective actions are taken at the right stages of the development cycle.

Step 2: Root cause

What is the root cause of the issue? Is it a specific piece of code, an invalid configuration, or something else?

Identifying the root cause enables structural fixes rather than temporary workarounds.

Step 3: Lead-up

Reconstruct the timeline. What chain of events led to this incident? Go back as far as necessary.

This could involve the introduction of a particular change prioritized for a specific reason or an unexpected event that triggered an unknown issue.

Having a complete timeline allows you to identify one or more points where similar issues could be prevented in the future.

Step 4: Corrective actions

What corrective actions have been taken, or are planned, to prevent this and similar incidents from recurring?

Depending on the severity and urgency, some actions—such as a code fix or reverting a faulty change—may already have taken place. However, it is important to think beyond only the immediate software fix.

Examples include:

• Are other scenarios for the same feature also missing test coverage?
• Would extra documentation, an update to the Definition of Done, or a new policy help prevent similar situations?
• Could extra logging or error generation help detect this type of issue earlier?

Make sure any planned actions are clear and actionable.

Step 5: Lessons learned

What has the team learned from this incident? Typically, these insights will have led to corrective actions.

Dare to challenge each other; not to assign blame, but rather as an opportunity to learn and improve moving forward.

Follow-up

Share the outcome of the post-mortem with stakeholders and colleagues to maintain transparency. Ensure all team members involved agree with the content of the report.

Sharing the post-mortem outcome allows colleagues and other teams to learn from your experience and find inspiration.