A retrospective that isn't theatre

An hour, a whiteboard, three columns, sticky notes, general agreement, four action items with no owner. Everyone leaves feeling it was useful. Nothing is different next quarter.

The retrospective is not failing because people are insincere. It is failing because it produces a feeling of alignment and no durable memory, and those are easy to confuse in the room.

The test

Six months later, someone is about to commit to work of the same shape. Does anything you produced reach them?

Usually not. The notes are in a document named after a date, in a folder they would have to know exists, filed under the ceremony rather than the subject. The knowledge was generated and immediately made unfindable.

One written lesson beats a full report

The single highest-value change is also the smallest: require exactly one sentence answering what do we now know that we did not know when we committed?

Not what went well. Not what to improve. Those produce generalities — "we should communicate earlier" — that were true before the project and will be true after it. The question above forces specificity, because the honest answers are concrete: "the vendor's sandbox does not support batch imports, so any integration like this needs three extra weeks."

One sentence of that is worth more than a page of sentiment, and — this is the part that matters — someone will actually write one sentence.

Attach it to the work, not to the ceremony

Where the lesson lives determines whether it is ever read. Filed under the retrospective, it is found only by someone looking for retrospectives, which nobody is. Attached to the demand it came from, it is found by the person reading that demand — and the demand is what they were already looking at when the question arose.

This is the same reason decision records belong on the work rather than in a decision log. Proximity, not completeness, is what makes a record get read.

Make it required, and keep it cheap

These two have to hold together, or you get one of two failures.

Optional and cheap: it does not happen. The demand is delivered, everyone moves on, and the moment when the knowledge was freshest passes.

Required and expensive: it happens badly. A mandatory hour-long ritual with a template produces filled-in fields the way a mandatory risk register produces invented risks .

Required and cheap is the combination that works: the work is not complete until one lesson is written, and writing it takes a minute. A gate that small is hard to resent and hard to route around.

This is also the second half of what it should take for work to count as complete .

A verdict alone is not a lesson

The tempting shortcut is a rating — did this go well, yes or no — because it is quantifiable and produces a chart.

It records that a retrospective happened. It does not record what was learned, and the two are not related: a demand that went well can carry the most useful lesson on the board, and one that went badly can carry none because everyone already knew the cause.

If you keep a verdict, keep it as context for the lesson rather than instead of it.

How DeliverySheet enforces it

The retrospective sits on the demand and unlocks only once the delivery outcome has been recorded — the product never asks what you learned before you have said what happened. The outcome is shown as context rather than re-asked.

Both a verdict and a lesson are captured, and the rule is that the lesson is required: a "yes, it went well" alone does not complete a demand. That is a server-side predicate with its own unit test, not a hint in the UI, because the shortcut it prevents is the exact one every retrospective process drifts toward.

A demand is complete only when both the outcome and the lesson exist — which is also what moves it out of the active pipeline. Completion is a state you reach by writing something down, not by the work stopping.