On the evening of 27 January 1967, a flash fire swept through the Apollo 1 command module during a countdown rehearsal at Cape Kennedy. Gus Grissom, Ed White and Roger Chaffee could not get the inward-opening hatch open, and all three died. The rocket had not been fuelled, so, as NASA’s history office notes, the test had been considered non-hazardous and was not reviewed by the relevant safety organizations.
In Houston, Gene Kranz was a flight director in Mission Control. Half a century later he told a Senate subcommittee, “The crew could have called it off. I could have called it off.” Nobody, he said, had said stop.
So his team sat down. “We sat down after we finished and wrote up the searing impressions we had in such a fashion that we would never go through this again,” Kranz told the senators. They called the document The Foundations. The case has the rest.
Before the fire
Most teams look back like that only when something has burned. A retrospective is the habit of doing it every round, while the stakes are still small.
The Scrum Guide, the official description of the Scrum method for software teams, puts it in one line: the purpose of the Sprint Retrospective “is to plan ways to increase quality and effectiveness.” At the end of each sprint, a fixed stretch of a month or less, the team looks at how the last one went: people, interactions, processes, tools. It discusses what went well, what problems it ran into and how they were, or were not, solved. The most useful improvements, the guide says, are addressed as soon as possible and “may even be added to the Sprint Backlog for the next Sprint.”
After each round, the team looks back at how it worked and picks something to change. The last part matters most. A list of lessons that nobody acts on is a diary, not a retrospective.
Think of a football team watching the match video on Monday. The point of the hour in front of the screen is that Saturday’s training looks different.
Does it work?
On average, yes, with a caveat about how it is done. Scott Tannenbaum and Christopher Cerasoli pooled 46 samples covering 2,136 people in a 2013 meta-analysis. Debriefs, they found, improved effectiveness over control groups by about 25% on average, for teams and individuals, in simulations and real work, in medicine and outside it.
What gets discussed matters too. In a 2005 quasi-field experiment, Shmuel Ellis and Inbar Davidi followed soldiers doing navigation exercises on successive days. Those debriefed after each day on both their failures and their successes improved significantly more than those who reviewed only their failures.
Why they go stale
Ed Catmull, Pixar’s cofounder, wrote in 2008 that although people learn from postmortems, the end-of-film reviews his studio held, “they don’t like to do them.” Leaders want to hand out praise. People would rather talk about what went right. “Left to their own devices,” he wrote, “people will game the system to avoid confronting the unpleasant.” His fixes were to vary the format, since the same format tends to turn up the same lessons; to ask each group for the top five things it would do again and the top five it wouldn’t; and to bring data.
Imagine a team of five whose fortnightly retrospective lists “too many meetings” every time. Nothing changes, because nobody owns the change. After a few rounds, people may stop raising anything at all. The same team might instead cancel one recurring meeting for the next sprint, as a test, and check at the following retrospective whether anyone missed it.
A retrospective for an agent
“Each Claude Code session begins with a fresh context window,” its documentation says, so last week’s lesson is gone unless something writes it down. The documentation treats its CLAUDE.md file as “the place you write down what you’d otherwise re-explain,” and lists when to add to it: when Claude “makes the same mistake a second time,” when a code review catches something it should have known, or when you find yourself typing the same correction you typed last session.
Its auto memory goes a step further. Among the notes Claude saves for itself are “corrections you give Claude and approaches you confirm”: what worked as well as what didn’t, much as in the soldiers’ debriefs. One thing is different. A team’s retrospective is a conversation among the people who will change. An agent’s lessons are plain text files, and the documentation notes you can read, edit or delete them at any time. Someone still has to look at what it decided to learn.
The Foundations took a fire to write. A retrospective is the attempt to learn the same way without one.