Why Your Retrospectives (KPT) Don't Stick — Fixing "Write It and Forget It"

“Wait — didn’t we make this exact mistake before?”

Have you caught yourself thinking that midway through a project? You ran the retrospectives (KPT) properly, and yet here you are, stepping into the same hole again. I’ve felt this many times myself.

Retrospectives are a habit on most teams. And yet surprisingly few people can say with confidence that they “paid off next time.” Why? The cause isn’t a lack of individual diligence — it’s the structure that the practice of retrospecting sits inside.

Reason 1: The retrospective ends the moment it’s written

The instant you finish writing out KPT, a sense of accomplishment kicks in. Fill in Keep, Problem, and Try, and you feel like you’ve reflected. But the real goal isn’t writing — it’s changing the next action.

When the record becomes the goal, the retrospective turns into a ritual for leaving behind “proof that we did it.” Documents pile up; behavior doesn’t change. That’s the first step toward a hollow ritual.

Reason 2: When it matters, you can’t find it

Even if you write a good Try, the time you’d reference it is weeks or months later, in a “similar situation.” But by then, the past retrospective is scattered somewhere across Excel, meeting notes, and chat — and you can’t dig it out.

What makes it worse: the words you use then and now are different. A problem you wrote as “short on resources” becomes “not enough people” on the next project. If the keywords don’t match, full-text search won’t surface it. “Can’t find it” becomes “might as well not exist.”

I wrote more about this sense of time evaporating into searching in the post about losing an hour every day.

Reason 3: No one remembers it at the moment it’s needed

This is the biggest one. A past lesson, unless it resurfaces automatically in the next similar situation, may as well not exist.

Human memory is unreliable. The only person who can think “there was a lesson about this somewhere” is someone who already remembers the lesson. A new team member, or the person buried under today’s workload, never reaches the past retrospective. The learning never becomes a team asset; it stays locked inside one person’s head.

For example, say you recorded a Problem six months ago: “an external API spec change made a huge number of tests fail.” When you start a similar project, if that lesson is quietly handed to you during requirements definition, you avoid the same trap. But in reality, no one opens that file, and the team steps on the same problem again. The retrospective was never connected to “the entrance of the next project.”

This is continuous with the culture of accumulating and using failure across an organization. I dig into the mechanism of turning failure into learning in my reading notes on Black Box Thinking.

The direction of a fix: from “store it” to “it reaches you when needed”

To sum up, retrospectives don’t stick because three things overlap: “write and stop,” “can’t find it,” and “no one remembers it.” Put the other way around: if a past retrospective is automatically placed in front of you in the next similar situation, much of the problem dissolves.

The key is semantic search. If you judge relevance by closeness in meaning rather than exact keywords, you can link “short on resources” and “not enough people” as the same problem. What you stored becomes an asset that reaches you at the right moment.

The way I turned this idea into a tool is “Tasukiba,” an AI work-management secretary. It remembers your past projects, issues, and retrospectives, and automatically suggests the ones relevant to what you’re working on now through semantic search. It’s a tool for turning a “write and forget” retrospective into something that “comes to you when you need it.”

In closing

You don’t need to stop retrospecting. What you should change is the structure that buries what you wrote afterward.

The next time you write KPT, try asking once: “Could the me of six months from now receive this without searching for it?” That question is the first step in turning a retrospective from a ritual into an asset.