Your Daily Standup Is a Status Meeting in a Trench Coat

A single-practice autopsy, and a one-week test that will tell you whether your team is actually standing up — or just standing.

Of all the practices that survived the agile bait-and-switch, the daily standup is the one that hides its corpse the best. The body is dressed nicely. It still goes to work in the morning. It looks, from a distance, like the practice it used to be. And almost every engineering organization I've talked to in the past decade — including ones that consider themselves "high-functioning agile shops" — is running a standup that died years ago and hasn't been told yet.

This is the post where we say it out loud. Your daily standup is, with overwhelming probability, a status meeting wearing a trench coat. And the reason it's not delivering value isn't that standups are bad. It's that you're not running one.

What the standup was supposed to do

The original idea is almost embarrassingly simple. A team working on the same problem will, over the course of a day, learn things. Someone will discover a dependency they didn't know about. Someone will hit a blocker. Someone will realize the approach they committed to yesterday won't work. Someone will finish ahead of schedule and have capacity to help.

Without a forcing function, those discoveries get hoarded. The person who hit the blocker waits until their 1:1. The person who finished early picks up the next ticket from the backlog instead of asking who needs help. The person who realized the approach won't work spends another half-day proving it before mentioning it. By the end of the week, the team has accumulated a debt of un-shared information that quietly degrades everything they're doing.

The standup is the forcing function. Every day, briefly, the team re-coordinates. New information surfaces. Plans change based on what surfaced. People help each other. Blockers get unblocked. The standup is not a meeting where people report what they're doing. It's a meeting where people change what they're doing because of what they hear.

That last sentence is the entire test. Read it twice.

If, in your team's standup, no one has changed what they were going to do that day because of something they heard from someone else — you didn't have a standup. You had fifteen minutes of public homework recital.

What it became

Here's how the practice dies, in slow motion, in almost every organization that adopts it.

It starts with a manager in the room. Not necessarily a hostile one — often a well-meaning one who "just wants to stay informed." But the manager's presence changes the audience. Engineers stop talking to each other and start talking to the manager. The unit of communication shifts from "what does my team need to know" to "what does my manager need to hear." Voices subtly change. Updates get cleaner. Uncertainty gets sanded off. The meeting starts to sound like a status report because, functionally, that's what it now is.

Next, the format calcifies. The three questions — what did you do yesterday, what will you do today, what's blocking you — get treated as a script rather than a prompt. People answer them in order, in turn, without deviation. The meeting becomes a round-robin recital. Anyone who tries to actually have a conversation about what they heard gets gently redirected: "let's take that offline." The meeting is now optimized for finishing on time, not for changing what anyone is doing.

Then the metrics arrive. Leadership wants to know whether the standup is "working." Working gets defined as "happens daily, finishes in 15 minutes, everyone attends." All three are easy to measure and none of them measure the thing that matters. Teams optimize for the metrics. The standup becomes a compliance ritual. It happens daily, finishes in 15 minutes, everyone attends, and nothing changes because of it.

Finally, the meeting goes remote and async. Engineers post their three answers in a Slack channel. A bot collects them. Nobody reads the channel except the manager looking for "blockers" they can escalate. The meeting has now achieved its final form: a unidirectional reporting channel from the team to management, dressed in agile vocabulary, performing zero of the function the original practice was designed to perform.

At each stage, somebody will tell you the standup is "working well." They will mean: it happens reliably, it doesn't take long, and people show up. They will not mean: the team coordinates better than it would without it. Nobody has measured that, because nobody knows how.

The one-week diagnostic

Here's how to find out, in five working days, what your standup is actually doing. You don't need to change anything about the meeting — just observe it differently.

Monday — count the changes. During the standup, keep a tally. Every time someone changes their plan for the day based on something a teammate said in the meeting, that's one tick. Not "agrees with what they heard." Not "acknowledges the blocker." Changes their plan. "Oh, if you're touching the auth service today I'll wait on my migration" counts. "Acknowledged, thanks for the update" doesn't.

Most teams running real standups produce two to five plan changes per meeting. Most teams running status meetings produce zero. Be honest about which one you saw.

Tuesday — track the audience. Watch where people's eyes go when they speak. Do they look at their teammates? At the manager or lead? At their own video tile? At the wall? People look at the audience they're actually addressing. If everyone is addressing the manager — and most teams are, even ones that swear they aren't — your standup has a single listener and twelve performers, and that's a status meeting by definition.

Wednesday — measure who talks to whom. Count the cross-talk. Specifically: how many times during the meeting did one engineer ask another engineer a follow-up question, propose a coordination, or offer help? On a healthy team of six to eight, you'd expect this to happen four or five times in a fifteen-minute meeting. If it happened zero or one times, you're watching parallel monologues, not a coordination meeting.

Thursday — check what happens to blockers. When someone says "I'm blocked on X," what happens next? In a real standup, somebody else in the room — not the manager, not the Scrum Master, somebody on the team who happens to have context — engages with it. They offer a workaround, they say "I hit that last week, here's how I got around it," they volunteer to pair on it after the meeting. In a status meeting, the manager says "let's track that" and writes it down. Watch which one happens. The first means the team is using each other. The second means the team is reporting to management and waiting for management to fix things.

Friday — ask the team the right question. Don't ask "is the standup working?" Everyone will say yes because they don't want to look like the difficult person. Ask instead: "In the last week, did anything you heard in standup change what you actually did that day? Can you give me a specific example?" Ask each person separately. If most of the team can't produce a concrete example from the past five days, your standup isn't producing the value it's supposed to produce. It might be producing other things — visibility for managers, a sense of team cohesion, a reliable start to the day — but it's not doing the job a standup is supposed to do.

A team running a real standup will, on this week's data, produce a tally of plan changes, evidence of cross-talk, peer-to-peer blocker resolution, eyes that move between teammates, and concrete recent examples of decisions that shifted because of the meeting. A team running a status meeting in a trench coat will produce silence on most of these dimensions and a defensive insistence that the meeting is working anyway.

If you ran the diagnostic and don't like what you found, the question to sit with is not "how do we fix the standup." The question is: what about our organization made the standup turn into this?

Why it always turns into this

The standup, like every agile practice, sits inside an organizational context. And the context, in most companies, is structured to convert the standup into a status meeting whether anyone intends that or not. Three forces do most of the work.

The first is managerial accountability. Managers are measured on their team's output and timelines. To answer the questions they're held accountable for, they need information about what their people are doing. The standup is a daily, free, low-friction channel for that information. The moment a manager attends the standup primarily as an information consumer, the practice begins its conversion. Engineers are not stupid. They will adjust what they say to match who is listening.

The second is psychological safety, or the lack of it. Real standups require engineers to publicly say things like "I'm stuck," "I went down the wrong path yesterday," "I don't know how to do this," and "the approach I committed to isn't working." On a team without high psychological safety, none of those statements are safe to make in front of management. So engineers don't make them. They report polished versions. The polished versions don't surface anything coordination-worthy, because the un-polished versions were where the coordination opportunities lived.

The third is the metrics regime. If your organization measures standup health by attendance and duration, you will get high-attendance, on-time standups that don't coordinate anything. The metrics select for compliance, not function. This is a special case of a more general law: the practices an organization measures will optimize for the measurement, even when the measurement misses the point.

These forces are why the standup keeps dying the same death across companies that look very different on the surface. It's not a failure of training. It's not a failure of "buy-in." It's a structural conversion that happens when you put the practice into an environment that's built to extract status reporting from every available channel. The practice doesn't stand a chance.

What "fixing" the standup actually requires

If you ran the diagnostic and found a status meeting in a trench coat, the impulse will be to redesign the meeting. New format. New questions. New facilitator. Stand instead of sit. Walk the board instead of go around the room. Use a token. Pair the introverts. Time-box each speaker. There are about forty popular variations and most of them will improve nothing, because the meeting isn't the problem.

The meeting is downstream of the conditions. Real standups happen in teams that have managerial restraint (managers who attend, if at all, as observers and resist the gravitational pull toward consuming information from the meeting), psychological safety (engineers can say "I'm stuck" without it landing on a performance review), peer authority to coordinate (engineers can change their own plans based on what they hear, without escalating to a lead), and absence of vanity metrics (nobody is tracking standup health by attendance and duration).

Where those conditions exist, the standup mostly runs itself. Where they don't, no amount of meeting redesign will save it. You can switch to walking the board, switch back, go async, return to synchronous, change the questions, drop the questions entirely — and you'll keep getting status meetings in different costumes, because the organization is selecting for status meetings.

This is why we keep saying, in this series, that the practices aren't really the lever. The conditions under which the practices operate are the lever. Most "agile transformations" tried to install the practices without changing the conditions, then blamed the practices when they got eaten by the conditions. The standup is the most legible example of that pattern, but it's not unique. It's the rule.

What to do this week

If your team's standup, on this week's diagnostic, looks more like a status meeting than a standup, here's the move that's worth making before any meeting redesign. Have an honest conversation with the team — without the manager in the room — about what the meeting is actually for, what it's actually doing, and whether it's worth the fifteen minutes a day. Most teams, asked the question that directly, can tell you exactly what's wrong and exactly what they'd want instead. The information has been there the whole time. The meeting structure was preventing it from surfacing.

That conversation, by itself, is worth more than any standup variant you'll find in a book. It's a tiny dose of the actual practice — people on the team coordinating, in real time, based on shared information, to change what they do next. The fact that you have to step outside the standup to have it is, of course, the whole point.

Next in the series: AI didn't kill agile. It exposed teams that were faking it.