Standups: the ceremony agents made obsolete
The daily standup was a synchronisation protocol for a system with no other way to read its own state. Most of what it transmitted is now derivable. The part that is not is worth protecting deliberately.
Nine fifteen. Eight people. Someone says “I’ll go first.” They describe, in about forty seconds, work that is visible in a pull request that six of the eight people cannot see and would not read if they could. They say they are blocked on nothing. The next person says roughly the same thing about a different ticket. Person four says they are blocked on a review, and the person who owes them the review says they will get to it today, and that exchange is genuinely useful and takes eleven seconds. Then four more people report.
Fifteen minutes, eight people, two hours of salaried attention per week, and the useful content was eleven seconds plus whatever social benefit accrues from hearing each other’s voices.
I am not the first person to make this observation. The standup has been a punching bag for as long as it has existed, and it has survived every round of criticism, which should make anyone cautious about declaring it dead. Rituals that survive sustained mockery are usually doing something the critics have not identified. So before writing the obituary it is worth working out what the ceremony was really for, because the case that agents changed things has to rest on the actual function rather than the stated one.
The stated function and the real ones
The stated function is the three questions. What did you do yesterday, what will you do today, what is blocking you. That is a status reporting protocol, and it exists because in 2001 there was no other way to know the state of the work. The board was a physical wall of index cards. Source control was a nightly commit to a central server. The only sensor the system had for its own state was people talking.
If that were the whole function, standups would have died around 2014 when everyone got a digital board with a real-time view. They did not die, which tells you the three questions were carrying other cargo.
Blocker resolution. The eleven useful seconds. A synchronous moment where a dependency gets named in front of the person who can clear it, with mild social pressure attached. This is real and it is valuable.
Ambient awareness. Hearing that a colleague is working on the notification service, and thinking, three days later, that you should check with them before touching the queue. This is diffuse, hard to measure, and probably the most defensible thing standups do.
Commitment and social contract. Saying out loud what you will do today, to peers, creates accountability that no ticket state creates. Some people find this motivating and others find it coercive, and both reactions are legitimate.
Team cohesion. For distributed teams especially, a daily moment where everyone appears as a person. Thin, but not nothing, and its absence is felt over months rather than days.
Now run each of those against a world where agents are producing a large share of the changes.
Status reporting is dead and should be buried
The first function is straightforwardly obsolete, and it was already dying before agents.
If a change exists, it exists in source control. There is a branch, a commit, a pull request, a review state, a merge, a deploy. That is a complete, timestamped, non-negotiable record of what happened, and it is more accurate than anyone’s recollection of yesterday, produced at zero marginal cost, available to everyone including the people who were on holiday.
Agents make this decisive rather than merely true, for a reason that is easy to miss. The standup’s status function assumed the person speaking knew the status. In an agentic team they frequently do not. Work proceeded overnight. Three pull requests opened while they were asleep. A human describing what “they” did yesterday is now giving a partial, second-hand summary of a system’s activity, filtered through their own memory, which is a strictly worse version of what any competent read of source control would produce. You have taken an accurate machine-readable record, degraded it through human recall, and then transmitted it verbally at 150 words per minute to seven people who are checking Slack.
Defending that as a communication mechanism requires arguing that the degradation is a feature. Sometimes people do argue this, on the grounds that summarising forces reflection. It is not a crazy argument. It is just not worth two hours of team time a week.
So: status goes to the derived record. The board reads itself from source control, every pull request is linked to its work item, and the state of the sprint is a page anyone can open at any time rather than a thing that is reconstructed verbally once a day. Tools exist for this now (GroundTruth is ours) and the specific implementation matters much less than the principle, which is that the system of record should reconcile itself against the artefacts rather than against people’s memories.
Blockers are the actual content, and daily is the wrong cadence
Here is where the argument gets more interesting, because blocker resolution is genuinely valuable and it is not obvious that removing the standup improves it.
The case against daily: a blocker that arrives at 10am on Tuesday sits until 9:15 on Wednesday. That was tolerable when work moved at human speed and a day of latency was a small fraction of a task’s duration. It is much less tolerable when an agent can complete the unblocked work in an hour. Batching blocker resolution into a daily window imposes an average delay of half a day on the most time-sensitive information in the system. That is backwards: the more valuable and time-sensitive a signal, the less it should be batched.
The case for daily: blockers are frequently unrecognised. People do not know they are blocked. They know they are stuck, or annoyed, or spinning, and it takes the act of describing it out loud to a room for someone to say “oh, that is the thing we hit last month.” A pure async channel catches declared blockers and misses undeclared ones, and undeclared blockers are the expensive kind.
The reconciliation most functional teams seem to land on is: make blocker raising continuous and low-friction (a channel, a flag on the work item, a norm that saying “I am stuck” costs nothing), and keep a weekly, longer, higher-quality synchronous session for the undeclared kind, where the conversation is about patterns rather than tickets. That gets you low latency on the known and a real forum for the unknown, without the daily tax.
The failure mode to watch: teams that kill the standup and replace it with an async bot that asks the three questions in Slack every morning. This is the worst outcome available. It preserves the reporting overhead, removes the synchronous blocker resolution, removes the ambient awareness, and produces a channel of ignored text. Almost everyone who has done this has quietly abandoned it after a few months, and the lesson they usually draw is “async does not work,” when the actual lesson is that they automated the useless part.
The async standup bot
- Asks the three questions in a channel
- Preserves the obsolete function
- Discards the synchronous moment that had value
- Adds a daily writing task
- The worst outcome available
Continuous plus weekly
- Blockers raised the moment they appear
- Saying "I am stuck" costs nothing socially
- Status derived, never recited
- One weekly session with real substance
- Demos, decisions, what surprised us
What ambient awareness needs instead
The function I would most worry about losing is the diffuse one. Knowing roughly what everyone is doing is load-bearing in ways that show up only when it is absent, as duplicated work, as two people making incompatible assumptions, as a change that surprises someone it should not have.
Standups delivered this badly (verbal, once daily, low retention) but they did deliver it. And the agentic world makes it harder in two ways at once: there is more activity to be aware of, and the activity is less legible because a lot of it did not pass through a human’s hands.
Things that seem to work better than a standup:
A high-signal activity feed, filtered by area rather than by person. Not a firehose of every commit, which nobody reads. Something closer to “changes landed in the systems you own or depend on,” which is a much smaller and much more relevant set. The filtering is the whole product here; an unfiltered feed is worse than nothing because it trains people to ignore it.
Explicit dependency declaration at specification time. If work items name the systems they touch, awareness becomes a query rather than a memory. This costs a little discipline up front and pays continuously.
A weekly synchronous session with actual substance. Not status. Demos, architectural decisions, what surprised us, what class of thing keeps going wrong. Forty-five minutes weekly beats fifteen minutes daily on nearly every dimension including total cost, and it is the format where the interesting conversations actually fit.
Do not underestimate the social layer
One warning, offered without much analytical framing because it is mostly an observation about people.
For distributed teams, the standup is often the only recurring moment where everyone is present as a person rather than as a name in a thread. Remove it in the name of efficiency and you can measure the time saved immediately and the cohesion lost never. Several teams I have talked to about this describe the same arc: killed the standup, enjoyed the reclaimed hours, and six months later noticed the team had become a set of individuals who shared a repository.
If you remove the ceremony, be deliberate about replacing the social function with something that is explicitly social, and do not pretend a Slack channel does it. The efficiency argument is correct about status and silent about belonging.
Where this breaks down
The honest counter-arguments, and a couple of them are strong.
The derived record has to actually exist, and for most teams it does not yet. Everything above assumes you can look at a page and see the true state of the work. If your board is still hand-maintained, killing the standup removes your only sensor and leaves you with nothing. The order of operations is not optional: build the derived record first, verify people trust it, then remove the ceremony. Doing it the other way round is how teams end up reinstating standups within a month and concluding the whole idea was wrong.
Junior engineers lose more than senior ones. A senior engineer with a strong mental model of the system loses fifteen minutes and gains fifteen minutes. A junior engineer loses one of the few structured opportunities to hear how experienced people talk about problems, to notice what they treat as significant, and to ask a small question without scheduling anything. Efficiency arguments about ceremonies are almost always made by the people who need them least. If your team is junior-heavy, the calculation is genuinely different and you should be much more conservative.
Some teams’ work does not live in source control. Data teams working in notebooks and warehouses, platform teams doing console-driven infrastructure work, anyone in a low-code environment: the ground truth is thin or absent, and verbal status is still the best sensor available. The argument in this piece is strongest for product engineering teams with disciplined source control and weakest everywhere else, and it should be applied proportionally.
The three questions do force reflection. Being made to articulate what you will do today is a mild but real planning prompt, and some people genuinely use it that way. Removing it removes that prompt for everyone in order to save time for the majority who did not use it. That is probably the right trade, but it is a trade, not a free win.
And ceremonies are load-bearing in ways that resist analysis. This is the part I hold loosely. The standup has survived twenty-five years of well-argued criticism from smart people. Either the whole industry has been irrationally attached to a bad practice for a quarter of a century, or the ceremony is doing something that the analysis keeps failing to capture. I lean toward the first explanation and I would not bet heavily on it. Remove it as an experiment with an honest review after two months, not as a principled deletion, and pay attention to what gets worse.
The takeaway
The standup was a synchronisation protocol for a system with no other way to read its own state. That justification is gone: source control is a better sensor than human recall, and it is decisively better when a significant share of the work happened while everyone was asleep.
What survives is blocker resolution, which wants continuous low-friction raising plus a weekly forum for the undeclared kind, and ambient awareness, which wants filtered feeds and explicit dependencies rather than a verbal round-robin. And a social function that the efficiency argument does not address at all, and that you should replace deliberately rather than lose by accident.
If daily status stops being a meaningful unit of time, the two-week one starts to look questionable for the same reasons. The next piece takes on sprints: what a boundary is for when the cycle underneath it has collapsed to hours, and which of the four things a sprint does are worth keeping.