Retros that change something
Most retrospectives produce a list of action items that nobody looks at again. The ones that worked on my teams produced one change, tracked until it was real. How I run them, and the question I ask that usually finds the real problem.
A team I joined had held a retrospective at the end of every sprint for two years. I read through the notes. The same three complaints appeared, in slightly different words, in almost every one. Unclear requirements. Late testing. Too many meetings. Each retro had produced action items about them. None of the action items had been done.
Two years of honest feedback, carefully written down and completely ignored. The team had learned that retros were a place to complain safely and that nothing would come of it, which is worse than not holding them.
One change, then prove it happened
The first thing I did was cut the output. A retro on my teams now ends with one change. Not five action items. One thing we are going to do differently, with a name next to it and a date, and the first agenda item of the next retro is whether it happened.
This feels stingy and it is the reason it works. One change can be followed through. Five cannot, and a list of five that becomes a list of zero teaches the team that the whole exercise is theater.
The change also has to be something the team controls. "Product should write better requirements" is a wish. "We will not start a ticket until it has acceptance criteria, and we will send it back if it does not" is a change.
The question that finds the real problem
Retros drift toward symptoms. The build was slow. The review took a week. The spec changed. All true, and all one layer above the thing worth fixing.
The question I ask, for each item that comes up, is: what would have to be true for this not to happen again? Not who did it, not why it happened. What would have to be true. That question turns "the review took a week" into "reviews are not anyone's responsibility until someone asks," which is a thing you can actually change.
Separate the project retro from the sprint retro
Sprint retros are about the process and they should be short, twenty minutes at most. Project retros are different and deserve more. When a project ships, or is cancelled, I hold a dedicated session with everyone who touched it, and I prepare for it.
Preparation means a timeline, written before the meeting, of what happened when. The kickoff, the estimates, the moment the scope changed, the week it slipped, the day it shipped. People remember projects as a blur and the timeline gives them something to react to. Half the insights in a project retro come from someone looking at the timeline and saying "wait, we knew about that in week three."
Blame is not the point, and neither is comfort
The rule everyone knows is that retros are blameless. The rule people forget is that blameless does not mean vague. "Mistakes were made" is blameless and useless. "We estimated the integration at two weeks and it took seven, and the reason is that nobody had looked at the vendor's API before the estimate" is blameless and specific.
I model this by going first with my own mistakes. If I approved the estimate, I say so, and I say what I would do differently. A retro where the manager's decisions are off the table is a retro where the most important decisions are off the table.
The retro after the pilot
The most useful retro I have run was after the six week AI pilot. Three engineers, three projects, all delivered. The temptation was to celebrate and move on. Instead we spent two hours on the timeline, and the things that came out of it shaped the whole rollout.
The pull requests had gotten huge and review had nearly broken. The estimates for the second project were wildly wrong in the optimistic direction, because we had extrapolated from the first. One engineer had spent a full week fighting a tool on a task that would have taken a day by hand, and had not said so because everything was supposed to be faster now.
Every one of those became a rule in the rollout: size caps, ranges by work type instead of one number, and an explicit norm that saying "the tool is slower for this" was useful information rather than resistance. The pilot's success was real. The retro is what made it repeatable.
What I track
I keep a running list of every change that came out of a retro and whether it stuck. The list is short and most of the entries are boring, and the boring ones are the point. A team that has made twenty small process changes in a year and kept fifteen of them is a team that has stopped having the same retro twice.