Twelve people. Thirty-five minutes. Six of those minutes were relevant to more than two people in the room. The rest was status reporting that could have been a Slack message, except nobody reads those either.
That’s not a made-up example. That’s what a lot of standups actually look like once you measure them. The format survives because it’s easy to schedule and nobody wants to be the person who cancels the meeting. But the meeting is not the problem. Bad structure is the problem.
Why most standups fail
There are a few failure modes that show up over and over.
The first is treating the standup as a status report to a manager. When people answer “what did you do yesterday, what will you do today, what’s blocking you,” they’re often talking to the person who runs sprints, not to the team. The format was designed for peer-to-peer coordination. When it becomes a reporting ritual, engineers learn to give answers that sound productive rather than answers that create actual coordination.
The second is letting the standup become a problem-solving session. Someone mentions a blocker, someone else has a suggestion, and you’re 8 minutes in on a topic that affects two of the 12 people in the room. This is the one that’s hardest to stop because it feels productive in the moment. It’s not. Take it offline.
The third is size. Standups with more than 8 or 9 people almost always have a relevance problem. Half the updates don’t apply to half the team. The Amazon two-pizza rule exists for a reason. If your standup has more people than can share a pizza delivery order, consider whether it should be split.
The fourth is sitting down. This sounds minor but it’s not. Standups that happen while people are seated at their desks regularly run longer than ones where everyone is physically standing. The physical cue matters.
Walk the board instead of round-robin
The three-question round-robin format (yesterday, today, blockers) is fine as a default but it has a structural weakness: it’s person-centric, not work-centric. Each update is a self-contained island with no connection to adjacent work.
“Walking the board” means going through the work items on your sprint board from right to left (closest to done first) and having whoever owns each item give a one-line status. It reorients the conversation around the work instead of the individual.
This format tends to surface blockers more naturally. When you’re reviewing a ticket that’s been in “In Review” for three days, someone in the room usually knows why and says so. In the round-robin format, the same information often gets buried in a long per-person update or skipped entirely.
It also cuts the social overhead. People don’t feel like they have to summarize their entire day to justify their existence on the team. They just say what’s true about the card they own.
The time limit is not optional
Fifteen minutes is the hard cap. Not a guideline. The moment you treat 15 minutes as approximate, you’re at 22 minutes every other day.
How you enforce it matters. A timer on a shared screen works better than someone politely noting that time is running long. The visual cue changes behavior. Alternatively, a designated facilitator who actively cuts off tangents works well if someone on the team has the standing and willingness to do it consistently.
One minute per person is a reasonable target for round-robin standups. If someone’s update reliably takes 4 minutes, that’s a signal that they need a different forum for what they’re trying to communicate, not a longer standup.
Async standups work better than you might expect
For remote teams and teams across time zones, replacing the synchronous standup with an async format in Slack or a dedicated tool like Geekbot or Range is worth trying. Engineers post their update when they start work. Everyone reads before they start their own day.
I’ve seen this work well for teams that are genuinely distributed across more than 3 time zones. I’ve also seen it fail spectacularly for teams that use it as an excuse to never actually talk to each other. Async works when the team already has strong communication habits and uses the async standup as a supplement to real coordination, not a replacement for it.
For co-located teams, I’d be skeptical of going fully async. The synchronous standup, even an imperfect one, creates a shared pulse that distributed work habits can erode. The Harvard Business Review’s research on team coordination suggests that brief daily synchronous touchpoints reduce coordination failures more reliably than async alternatives, at least for teams doing interdependent work.
When to replace the daily standup entirely
Some teams replace the daily standup with a Monday kickoff meeting (15 minutes) and a Thursday check-in (10 minutes). This cadence works when the work is relatively independent day to day and the main coordination need is weekly rather than daily. It doesn’t work well for teams doing tightly coupled sprint work where blockers compound quickly.
The question isn’t “is the daily standup good or bad?” It’s “what coordination problem does this team actually have?” A team where people are frequently blocked waiting on each other probably needs more synchronous contact, not less. A team of senior engineers who work independently and self-direct needs less ceremony, not more.
The BLS Productivity Research consistently shows that meeting time per knowledge worker has grown substantially over the last decade. The standup is one of the few meetings that can absorb that pressure without expanding, but only if the team treats the time limit seriously.
One specific fix worth trying this week
If your standup is running long, try this: end the standup with a “parking lot” instead of trying to solve things in the meeting. Anyone can raise a topic that needs discussion. You write it down. You schedule 15 minutes to address it separately. The standup ends on time and the actual problems still get addressed, just not in front of people who have no stake in the outcome.
Craqly’s meeting notes feature can automatically summarize what came up in a standup, flag recurring blockers across multiple meetings, and surface patterns that might indicate a team coordination problem worth addressing. It won’t fix a broken standup by itself, but it makes the meta-work of improving standups easier when you can see a written record of what actually happened versus what you remember happening.
What change has made the biggest difference in a standup you’ve run or been part of?