Why Is Retrospective Difficult And How to Learn From the Past

“Memory never recaptures reality. Memory reconstructs. All reconstructions change the original” — Frank Herbert

Engineering requires regular diagnostics, retrospectives, postmortems, root cause analysis, etc. We want to reflect on the past and learn something from it.

But often this doesn’t work. Some teams identify causes and still struggle with the same issues over and over again. Some people “never learn”. It seems like we don’t always learn even from the best descriptions and analysis of past events.

Many times I have seen fantastic root cause analysis, and as soon as the next day, the people reverted to the usual, almost instinctive behaviour. Everything was identified, but nothing changed.

Why is this so?

We don’t like ambiguity, so we make stories with “logical” conclusions. It gives a sense of safety. I love the term the author used: “delusional clarity”.

When doing a retro, there is no way to know for sure if we took everything that happened into account (unknown unknowns). We may even have a preference where we wish a root cause to be (a specific person, team or a system) — and tailor our story to fit that. A mix of facts and assumptions is tough to “debug”.

Sure, some people are a bit more objective than the others, but let’s be honest; objectivity sometimes doesn’t mix well with talk about what went wrong and why (depending on the team).

What to do about this and how to learn from mistakes?

Describing a chain of events is good to kick start a discussion. And that is all it’s suitable for.

The most valuable learning is to find out what was (and what was not) in our minds during the time of the error.

Ask this:

• Why did it look reasonable for us to do this the way we did?
• Why the important things were not important to us before the error and at the time of error?

Next-level retros

Do a retro when everything went well. Ask questions like “What could have happened that would have made us fail? What can we optimize even more? What should change in the future so that our solution will require a change? How will we detect a need for change?”