Demos, retros, rhythm of learning

Most teams already run demos and retros. The demo happens on Friday, the retro at the end of the sprint, attendance is fine, the notes are dutiful. And the team repeats the same mistakes anyway. I argued in an earlier essay on meeting audits that demos and retros are the two recurring meetings most worth defending, and I owe you the mechanics of that claim. The defense is conditional: these two meetings earn their place only when they work as a single learning loop, where the demo supplies the truth about what the team actually built and the retro converts that truth into changes that stick. Run them as two unrelated ceremonies and you get the calendar of a learning team with none of the learning. That is the whole difference between a team that compounds and a team that stagnates on schedule.

Wire the demo and the retro into one loop

The demo and the retro are not two rituals that happen to share a calendar; they are the two halves of one mechanism. The demo generates the evidence: what ran, what didn't, what surprised people, where claimed progress and observed behavior parted ways. The retro consumes that evidence while it is still warm and decides what to adjust.

Separate them and both degrade: a retro with no demo upstream argues from memory and anecdote and becomes a feelings survey where the loudest recollection wins. A demo with no retro downstream is applause without adjustment; the team sees the gap, and nothing happens to close it.

Sports teams figured this out long ago. A serious football club treats the match and the film room as one system, and nobody at the club asks whether film review earns its cost, because watching what actually happened and adjusting for the next match is, obviously, what improvement is. The demo is your match, and the retro is your film room. Teams that run both but never wire them together conclude that rituals don't work, but the rituals were fine; the loop was never connected.

Wiring them is a sequencing job: demo first, retro within a day or two while the evidence is fresh, and the retro opens with what the demos showed rather than with a blank board and a prompt about feelings.

Demo the behavior

The mechanics of a good demo are short and strict: live software, small time slots, anyone on the team demos, no slides. If it cannot run in front of people, it is not demoed; it is described, and everyone in the room knows the difference.

Demo days get sold as a momentum engine: celebration and cross-team visibility. Both happen, and both are side effects, but the function of a demo is truth. A status report drifts toward optimism because a person writes it and people want to bring good news, but a demo cannot drift: the software either does the thing in front of everyone or it does not. It is the cheapest honest signal a team produces, and the one report that does not need auditing.

Demo theater is the way this goes wrong, and it looks exactly like success. An engineer rehearses the happy path, the demo works, the room applauds, and the broken edge that was carefully steered around surfaces weeks later in production, where it costs ten times more to find. The deeper damage comes later: once a team learns that demos are judged as performances, engineers stop bringing risky, half-working things, and the demo stops sampling the truth at all. You end up with a highlight reel where you needed game film.

The bar for what gets demoed comes from two places. If it cannot be shown running, say which version of done is being claimed. And demo the effect on the user rather than the artifact: the question is not whether it shipped but whether it worked.

Turn findings into changed defaults

Open the retro notes of a team that has stopped improving and you will find a backlog: ten action items per retro, owners assigned, half done once and forgotten, the same improvement re-proposed every quarter under a new name. The action-item graveyard is the single most common reason retros die, and the fix is not better follow-up discipline; it is changing what a retro is allowed to produce.

The unit of retro output is a changed default: a line in the PR template, a checklist entry, a CI gate, a review norm, a standing calendar block. An action item is work; you do it once, and it stops mattering the moment everyone looks away. A default is a system; it runs every time, including when nobody remembers the incident that created it. One or two changed defaults per retro beat ten action items, because the defaults are still working in a year and the action items are not.

Every long-running team has one of these if you look: a checklist line or a CI gate that quietly catches a mistake every few months, written after some retro years ago, still on duty after everyone who was in that room is gone. That artifact is what compounding looks like up close. Nobody is maintaining it; it just runs.

The same conversion, applied to incidents instead of sprints, is what makes a postmortem change behavior.

Route findings by authority

Some findings cannot become a team default, because the team does not control the thing that needs to change: the release approval chain, or a policy set two levels up. When a team stops acting on its retros, leaders diagnose a discipline problem, but a large share of "we never act on our retros" is an authority mismatch. The team keeps voting on something it has no power to decide, and the item returns every retro like a ghost.

So split every finding by authority: what the team can change becomes a changed default this week, owned inside the room. What the team cannot change, the leader carries up, visibly, and reports back with an answer, including when the answer is no. A real no closes the loop; silence leaves it open forever.

Watch for the item that has appeared in three consecutive retros without dying. By the third appearance it is not a discussion topic anymore; it is an escalation that has not been filed. Teams spend quarters voting on these, and then a leader carries the item up once, in the open, and it resolves in weeks. The work was never hard; it was sitting with people who had no power to do it.

This one is the leader's to get wrong. If you nod, write it down, and nothing changes, the team learns that the retro is where complaints go to be archived. People keep showing up, but they stop saying anything that matters, and that polite silence is easy to misread as health.

Speed up the demos, elevate the retros

The two-week cadence for both meetings was calibrated to a world where a feature took a sprint to build. Agent-assisted teams are leaving that world: when a feature goes from spec to merged code in hours, a fortnightly demo has a backlog problem, and a fortnightly retro reflects on work nobody quite remembers doing.

The wrong fix is to speed everything up uniformly; the right fix splits the loop. Demos accelerate with the batch size: run them weekly, or go fully continuous, with short recorded runs dropped into a shared channel as work ships and the live session is kept for the work that deserves a room. Retros keep their slower beat but aim higher.

Aiming higher means changing the kind of learning the retro does, and a retro can do two kinds. The first tunes the existing process: what slowed us down, where did the handoff break. The second questions the process itself: should this even be a handoff, and are we building the right way at all. Most teams never get to the second kind, because the first kind fills the hour. Telemetry now answers the first kind without a meeting: cycle time and review latency are sitting in a dashboard already. Let the dashboards have those questions, and spend the humans on the second kind, the questions no dashboard can ask.

The mistake is speeding the retro up alongside the demos: a stream of shallow weekly fixes, and the deeper question never gets asked. The same compression is reshaping planning and standups too.

Reach for format last

When retros go flat, the standard reflex is a new format. There is an entire catalog industry built on this: themed boards and metaphor exercises. The implicit theory is that retros fail because they are stale, but staleness is the symptom; absence of consequence is the disease.

Before touching format, check two things. First: do people say the risky thing in the room? If the real problem is unsayable, no board layout will surface it. Second: did the last retro change anything? If the honest answer is no, the team has correctly concluded the meeting is decorative, and they are bored because boredom is the rational response.

A stale format with real follow-through beats a novel format with none, every time. Rotating formats is an anesthetic: a new board keeps people entertained for a quarter while nothing changes, and then they are bored again, worse than before. Fix safety and follow-through first. Then, if the meeting is honest and consequential and still flat, by all means go pull something from the format catalog.

Prune the loop, and know what it cannot do

Two boundaries keep this system honest.

First, defaults pile up: a team that converts findings into checklist lines and gates for three years ends up with a checklist nobody reads and a CI pipeline that takes an hour. The retro that installs defaults must also retire them: once a quarter, ask which defaults stopped earning their cost, the same audit you apply to the meetings themselves. A default whose reason nobody can state is a candidate for retirement.

Second, retros judge how the team worked; they do not judge whether the bet was right. Whether the project should have been killed is a question you answer badly in hindsight, when the outcome is known and everyone is wise. That judgment belongs to kill criteria written before the bet was placed. The retro asks how we worked; whether we should have worked on it at all was decided, or should have been, in advance.

Held inside those boundaries, the loop is the reason these two meetings survive every meeting audit I run. The demo tells the team the truth about what it built, and the retro turns that truth into defaults that keep working after everyone has forgotten why. String enough of those defaults together and you get a team that is genuinely better this quarter than last, and will be better again next quarter, whether or not anyone remembers how it happened.