Making Standups, Planning, Retros, and Reviews Useful

The last page, Capturing Decisions and Following Up, was about making a single meeting’s outcomes survive after everyone leaves the room. This page is about a different problem: the meetings that come back. Standups, planning sessions, retrospectives, reviews — the rituals a team runs every day, week, or sprint, on autopilot.

Recurring meetings have a peculiar disease. A one-off meeting either produces something or it doesn’t, and you notice. A recurring one keeps its slot on the calendar whether or not it produces anything, because the slot itself feels like the point. So it slowly decays into theater — the motions of coordinating, planning, learning, and reviewing, with the substance quietly drained out. This page shows how to keep each of the four common rituals honest, and how to periodically audit all of them so the dead ones get cancelled instead of endured.

Why rituals decay by default

Everything in this part so far has pushed one idea: a meeting earns its place only if it produces a decision, alignment, or work that must happen live. A recurring ritual is just a meeting that has pre-committed to happening on a schedule. That schedule is its great strength and its fatal weakness.

The strength: some coordination genuinely needs a rhythm. A ward that hands off patients at every shift change, a warehouse that syncs before the trucks arrive, a team that decides together what to build next — these benefit from a predictable beat so nobody has to renegotiate when to coordinate every single time.

The weakness: once the beat exists, it runs whether or not there’s anything to coordinate. Attendance stops being a choice and becomes a habit. And a habit doesn’t ask itself the honest question — “what did we just produce?” — because it never had to earn the slot in the first place. It was already on the calendar. Left alone, every ritual drifts toward its emptiest possible version: people showing up, performing the shape of the ritual, and leaving no better coordinated than they arrived.

The fix isn’t to abolish rituals. It’s to know what each one is for, keep it pointed at that, and be willing to kill the ones that have lost the thread.

The common trap — the ritual that survives on its own momentum

The most common failure is not a badly run ritual. It’s a ritual that runs perfectly smoothly and produces nothing. Everyone knows their part, the meeting starts and ends on time, and if you asked “what would break if we stopped?” the honest answer would be “not much.” Smoothness is not the same as usefulness. A ritual can be a well-oiled machine that manufactures the feeling of coordination while the actual coordination happens elsewhere — in side channels, hallway chats, or not at all. Watch for the ritual nobody complains about and nobody would miss.

Standup: coordination, not status theater

A standup (also called a daily huddle or check-in) exists to answer one question for the team: is anything blocking us, and does anyone need to sync with anyone before we scatter? It is coordination among peers. Kept to that, it is one of the most valuable few minutes a team spends.

The classic decay is the “status theater” standup. Each person, in turn, reports what they did yesterday and will do today — not to the team, but to the manager, as proof of work. The other people wait their turn, half-listening, rehearsing their own lines. Nothing gets coordinated. The manager gets a warm sense of visibility, and everyone else loses ten minutes and their morning focus.

The tell is the direction people face. In a healthy standup, teammates talk to each other — “I’ll be touching the same file as you today, let’s sync at eleven,” “I’m stuck on the vendor login, does anyone have the credentials?” In status theater, everyone reports to the front of the room. If your standup would collapse without the manager present, it was never a standup; it was a live status report that a written update would have done better and cheaper.

Status theater (decayed)          Coordination (healthy)
--------------------------        --------------------------
"Yesterday I did X.               "I'm blocked on the vendor
 Today I'll do Y."                 login — anyone have it?"
        ↓ (to manager)            "I'm in the same file as
"Yesterday I did A.                you today, let's sync at 11."
 Today I'll do B."                        ↓ (to each other)
        ↓ (to manager)            "Nothing blocking me —
Everyone waits their turn.         I'll grab whatever's next."

To keep a standup honest: keep it short (a genuine standup is short partly because nobody wants to stand for long), point it at blockers and hand-offs rather than a recitation of tasks, and take any real problem-solving out of the standup into a smaller conversation with only the people involved. The standup surfaces the blocker; it doesn’t solve it in front of eight bored spectators.

In practice — the warehouse pre-shift huddle

A warehouse supervisor runs a five-minute huddle before the first trucks arrive. It isn’t a status report — everyone can see the board. It’s coordination: two people are out sick, so the inbound dock is short-staffed; a large delivery is due at ten, so the forklift needs to be free; the new hire shadows the packing line, not receiving. In five minutes the shift reshapes itself around the day’s real constraints. If it turned into “here’s what I did yesterday,” it would be worthless. The value is entirely in the live rearrangement — exactly the “work that only happens live” that justifies gathering people at all.

Planning: a realistic commitment, not a full backlog

A planning meeting exists to answer: what will we actually commit to doing next, and what stands in the way? It is the ritual where a team turns a wish-list into a realistic set of work and surfaces the dependencies that could sink it.

The decay here is planning that optimizes for filling rather than committing. The team looks at a long list of possible work and tries to cram as much as possible into the next period, because a full plan feels productive. But a plan stuffed to the brim isn’t a commitment — it’s a hope. When it inevitably overflows, everyone learns that the plan doesn’t mean anything, and planning becomes a ritual you attend but don’t believe.

Good planning does two things instead. First, it commits to a realistic amount — a set the team actually believes it can finish, which means saying no to the rest, out loud, now, rather than by silent failure later. Second, it surfaces dependencies: the work that can’t start until something else finishes, the person who’ll be on leave, the approval from another team you’ll need in week two. A dependency named in planning is cheap; the same dependency discovered mid-work is expensive.

A plan that means something states, for the chosen work:
- What we are committing to  (and, implicitly, what we are not)
- Who owns each piece
- What each piece depends on  ← the part usually skipped
- The one or two things most likely to blow the plan up

The honesty test for planning: at the end of the period, does what the team actually did resemble the plan? If plans and reality never match, planning isn’t planning — it’s a ceremony that produces a document nobody trusts. Either the team is over-committing (fix the amount) or something keeps derailing it (fix the dependency-surfacing, or the interruptions).

The common trap — planning as backlog-stuffing

It feels responsible to plan everything that could be done — but a plan’s job is to say what will be done, which means it must leave things out. A team that treats planning as filling a container to the top removes the plan’s only real power: the shared, believed commitment that lets people say “no, that’s not in the plan” when the next shiny request arrives. If your plan can’t be used to decline work, it isn’t a plan. It’s a to-do list wearing a meeting.

Retro: real problems named, a few concrete changes tracked

A retrospective (or “retro,” “debrief,” “after-action review”) exists to answer: what should we do differently, based on what just happened? It is the ritual by which a team learns. Done well, it is how a group gets better instead of just older.

Retros decay in two directions, and you have to defend against both.

The first decay is no safety. If people can’t name the real problem — the process that’s broken, the decision that went badly, the fact that a manager’s pet idea failed — then the retro fills up with safe non-problems (“we should communicate more”) while the actual issue sits untouched in the room. A retro with no psychological safety is worse than none, because it teaches people that naming problems is pointless. The facilitator’s first job is to make it safe to say the true thing: focus on the system and events, not on blaming a person; let quieter people contribute in writing first; and, if you’re the boss, invite criticism of your own calls before anyone else’s.

The second decay is no follow-through. A retro that surfaces ten problems, generates warm discussion, and produces zero tracked changes is a venting session. It might feel cathartic, but nothing improves, and after a few rounds people stop bringing real problems because nothing ever comes of them. The cure is deliberate restraint: pick a small number of concrete changes — one to three — assign each an owner, and track them the way you’d track any action item (as Capturing Decisions and Following Up describes). Three changes that actually happen beat twenty that evaporate.

A retro that works produces:
1. Safety enough to name the real problems (not just the safe ones)
2. A SHORT list of concrete changes — 1 to 3, not 20
3. An owner and a tracked place for each change
4. A quick check next time: did last time's changes actually happen?

That last line matters most. Open each retro by reviewing whether the previous retro’s changes happened. If they didn’t, that is the real problem to discuss — because a retro whose outputs never land is the ritual most likely to quietly die of disbelief.

Case study — Toyota’s andon cord

On Toyota’s production lines, refined through the 1970s and 1980s, any worker who spots a defect can pull a cord (the “andon” cord) that can stop the line and immediately summons help to fix the problem at its source. The lesson for retros isn’t the cord itself — it’s what makes it work: a culture where surfacing a problem is treated as valuable, not as making trouble or admitting fault. Toyota built genuine safety to name problems, then paired it with a system that acted on what surfaced. A retro without that safety collects nothing worth acting on; a retro without the follow-through collects problems and does nothing. You need both halves, exactly as Toyota did. (Treat the specifics as illustrative of the principle, not as a precise operating manual.)

The evidence — safety is the ground learning stands on

Google’s multi-year study of its own teams, known as Project Aristotle and reported around 2015, found that the strongest differentiator of effective teams was not who was on them but psychological safety — the shared belief that you can speak up, admit a mistake, or challenge an idea without being punished or humiliated. That finding lands directly on the retro: the ritual whose entire job is to name what went wrong cannot function without it. If your retros stay shallow, the problem is usually not the format. It’s that people don’t feel safe enough to say the true thing, and no clever template fixes that.

Review: showing real work for a decision, not a performance

A review (a demo, a design review, a sprint review, a case review on a ward) exists to answer: is this work on the right track, and what should change or be decided next? It is the ritual where work meets judgment — stakeholders, peers, or customers look at what’s been done and give feedback or make a call.

The decay is the review-as-performance. The team spends hours polishing a presentation, hides the rough edges, demonstrates only the parts that work, and steers the audience away from the hard questions. Everyone claps. No real feedback is given, no real decision is made, and the problems the review was supposed to catch sail straight through to production or to the customer. The review became a show, and a show is designed to impress, not to be corrected.

A useful review runs the other way. Show the real work, including what’s unfinished or uncertain — because the unfinished parts are exactly where feedback is worth most. Come with a clear ask: “we need a decision on X,” “we want feedback on whether this direction is right,” “we’re stuck on Y and need a steer.” Center the room’s attention on getting that decision or feedback, not on how impressive the demo looked. A review that ends with a real decision or a piece of feedback that changes the next step earned its time. One that ends with applause and nothing else was theater.

In practice — the design review that invites the hard question

A software team demos a new checkout flow to stakeholders. The weak version: a rehearsed click-through of the happy path, skipping the case where a payment fails, ending with “any questions?” and an awkward silence. The strong version: “Here’s the flow. It works for the standard case. We’re not sure about what happens when a payment is declined mid-checkout — here’s our rough handling, and we specifically want your feedback on whether it’s good enough to ship or needs more work.” The second review surfaces the exact risk a review exists to catch. The first hides it behind polish. The difference isn’t skill at demoing; it’s whether the team wants to be corrected or admired.

The audit: what breaks if this disappears?

The four rituals above are the common ones, but the real discipline is not about any single ritual. It’s a habit you apply to all of your recurring meetings, on a schedule — perhaps every quarter. For each recurring meeting, ask one blunt question:

What would actually break if this meeting disappeared?

Then act on the answer honestly:

• If the honest answer is “something real would break” — a hand-off would get dropped, a decision wouldn’t get made, a team would drift out of alignment — then the ritual is earning its keep. Protect it, and make sure it stays pointed at that outcome.
• If the honest answer is “nothing much” — people would get their time back and coordination would happen fine through other channels — then you’ve found a ritual running on pure momentum. Cancel it. Not “shorten it,” not “improve the agenda” — cancel it, and see if anyone actually misses it. You can always bring it back if something breaks.
• If the answer is “the meeting is broken but the need is real” — the standup decayed into status theater, the retro produces no changes, the review is a performance — then don’t cancel the need. Fix the ritual using the principles above.

For each recurring meeting, ask: what breaks if it disappears?

  "Something real"   → it earns its keep. Protect and aim it.
  "Nothing much"     → cancel it. See if anyone notices.
  "Need real, ritual → fix the ritual, keep the need.
   broken"

The reason to do this on a schedule, rather than when you happen to notice, is that decay is invisible from inside the habit. Nobody wakes up and decides a meeting has become theater; it drifts there one unremarkable week at a time. A periodic, deliberate audit is the only reliable way to catch a ritual that has quietly stopped earning its slot — because the people attending it have long since stopped asking.

The common trap — no one wants to be the one to cancel it

The hardest part of the audit isn’t spotting the dead ritual. It’s cancelling it. Cancelling a meeting can feel like admitting it was never needed, or like a signal that you don’t value the people in it, or like a risk if it turns out you were wrong. So dead rituals persist not because anyone defends them but because no one will kill them. Make the cancel safe and reversible: frame it as an experiment — “let’s pause this for a month and see what breaks” — rather than a verdict. That lowers the stakes enough to actually do it, and the answer usually arrives fast.

How it connects

These rituals are where several other parts of the book show up in daily life. The decisions a team makes together often live inside planning and review. The learning a team does depends on the psychological safety discussed in ways of working — a retro is safety made visible. And the whole audit rests on the cost discipline from The Real Cost of a Meeting: a recurring ritual multiplies its cost by every occurrence, so a wasteful weekly meeting is one of the most expensive things on a calendar over a year.

Try this

Pick your team’s most-run recurring ritual — probably a standup or a weekly sync. This week, watch it with one question in mind: which direction are people facing? Are they coordinating with each other, or reporting to the front of the room? Then run the audit question on it out loud with the team: “What would break if we stopped this?” If the answer is thin, propose pausing it for a month as an experiment. If the answer is real but the ritual is decayed, pick one fix from this page and try it next session.

Reflect

1. Take your team’s standup (or daily check-in). Are people coordinating with each other, or reporting status to a manager? What would change if the manager didn’t attend?
2. At the end of your last planning period, how closely did reality match the plan? If they never match, is the team over-committing, or is something derailing the work?
3. When was the last time a retro produced a concrete change that actually got done? If you can’t recall one, is the problem a lack of safety, a lack of follow-through, or both?
4. Think of your last review or demo. Was it a performance designed to impress, or an honest showing designed to get feedback and decisions? What did it hide?
5. Run the audit on every recurring meeting you attend: for each, what would genuinely break if it disappeared? Which one has the weakest honest answer?

Show reflections

1. The direction people face is the fastest diagnostic. If the standup would collapse without the manager, it’s status theater, not coordination — a written update would do the reporting job better, freeing the live time for actual blockers and hand-offs.
2. A plan that never matches reality has lost its meaning. Persistent overflow usually means over-committing (the plan is a wish-list, not a commitment); persistent derailment points at unsurfaced dependencies or too many interruptions. The fix differs, so name which one it is.
3. A retro that produces no landed changes is a venting session, and people eventually stop bringing real problems to it. If problems never surface, suspect safety; if they surface but nothing happens, suspect follow-through. Both are common, and the cure — a short list of tracked, owned changes reviewed next time — addresses follow-through directly while safety needs the facilitator’s deliberate work.
4. The honest answer is often “a bit of both,” but the tell is what got hidden. Reviews exist to catch problems, so hiding the rough edges defeats the purpose entirely. A review that invites the hard question is doing its job; one that steers around it is theater.
5. This is the whole page in one move. The meeting with the weakest answer to “what would break?” is your best candidate to pause as an experiment. Cancelling it costs almost nothing if you’re right and is easily reversed if you’re wrong — which is exactly why the reversible experiment framing makes the audit possible to act on.