Daily Standup Alternatives: The Evidence and the Scripts

Someone on your team has already typed the message. Something close to “I don’t think the daily standup is working for us.” Then they looked at it, thought about how it would land, deleted it, and joined the call.

That deletion is the actual subject of this piece. The research on standups is not hard to find and most of it points the same way. What is hard is the sentence. You are trying to say a thing that carries three separate social risks at once, and all three of them attach to you personally.

Risk one: you sound lazy. Any request to remove a meeting reads, by default, as a request to be observed less.

Risk two: you sound like you are not a team player. The standup is framed as the thing that keeps everyone aligned. Objecting to it sounds like objecting to alignment.

Risk three: you are attacking a person, not a process. Someone owns that meeting. A scrum master, a manager, or the person who set it up two years ago. They will hear a critique of the ritual as a critique of their judgment, because in most rooms it is.

So people say nothing, and the meeting keeps running on the strength of nobody having found the words.

The good news is that the words exist and they are not complicated. They just have to be assembled in a specific order, and the order matters more than the evidence does.

The reframe that wins the argument

Do not argue that the standup is a waste of time. That argument loses, every time, for the three reasons above.

Argue instead that the version your team runs is not the meeting it is supposed to be, and offer a reversible experiment to fix it.

The Scrum Guide is on your side here, which is the part most people never check. The 2020 Guide¹ defines the Daily Scrum as a 15 minute event held for the Developers of the Scrum Team, to inspect progress toward the Sprint Goal and adapt the plan. It is not defined as a report to a manager. The 2020 revision also removed the three prescribed questions that most teams still recite every morning.¹

If your standup runs as a circle of people reporting yesterday and today to whoever is most senior in the room, you are not defending Scrum by keeping it. You are running something the rulebook already dropped, and you can say that out loud without accusing anyone of anything.

That is the whole move. You are not asking for less accountability. You are asking to run the meeting the way the framework describes it, and to test whether a cheaper format holds up.

Part 1: The reasons that hold up under scrutiny

I have cut a lot of the numbers that circulate on this topic. There is a note at the end explaining which ones and why. What follows is what I would put in front of a skeptical manager.

1. It has become an upward status report, which the framework says it should not be. The most documented failure mode. Stray, Sjøberg and Dingsøyr’s grounded theory study of daily stand-ups found that participants valued them for information sharing and joint problem solving, and reacted negatively when the meeting turned into status reporting to a manager or ran too frequently and too long.² The same finding shows up in the practitioner literature from the same research group.⁴

2. The three questions produce narration instead of coordination. “Yesterday I worked on the ticket, today I will continue on the ticket.” Nobody asks a follow up. Nothing changes as a result. The format encourages a performance of activity rather than an inspection of progress toward a goal, which is why the 2020 Guide dropped the questions.¹

3. Senior engineers and large teams get the least out of it. Stray and colleagues surveyed professional developers and found ratings clustered around neutral overall, with junior developers more positive and senior developers and members of larger teams more likely to see little value.³ If your most experienced people are the least engaged in the room, that is a signal about the format, not about them.

4. It splits the morning. Paul Graham’s argument from 2009¹³ still holds. People who make things need long uninterrupted blocks, and a single meeting in the middle of a morning can ruin the whole morning by cutting it into two pieces too small to do hard work in. A 10:30 standup is the canonical example. There is also an anticipatory cost. People avoid starting anything deep in the 45 minutes before it.

5. Switching tasks degrades the work on both sides of the meeting. Sophie Leroy’s research introduced attention residue: when you switch from one task to another, part of your attention stays behind on the first task and your performance on the second one suffers.⁵ A standup forces that switch twice for every attendee, once in and once out.

6. Getting back into the work takes real time. Gloria Mark’s interruption research is the source of the widely quoted figure of roughly 23 minutes to return to an interrupted task, and her work with Gudith and Klocke also found that people compensate for interruptions by working faster, at the cost of higher stress, frustration and perceived workload.⁶ Quote this one carefully. It is the most abused number in the productivity conversation and a manager who has seen it debunked will use that against you.

7. Blockers get named but not resolved. Watch for this in your own team. Someone says they are blocked, everyone nods, and the actual resolution happens forty minutes later in a DM between two people. If that is the pattern, the meeting did not solve the blocker. It only scheduled the conversation that did.

8. Meeting load accumulates physiologically. Microsoft’s Human Factors Lab ran EEG on participants in back to back meetings and found stress markers building across the sequence, with short breaks reducing that buildup.⁸ Steven Rogelberg’s meeting science work documents the same thing from the survey side, along with the recovery time people spend decompressing after a bad meeting, which sits on top of the meeting’s own length.⁷

9. It does not fit distributed teams. Somebody is always taking it at a bad hour. GitLab’s all remote handbook¹⁴ is the most complete public argument for handling status asynchronously instead, and it is a useful reference precisely because it comes from a company operating this way at scale rather than from a blog.

10. A daily cadence charges a daily price whether or not there is anything to coordinate. On teams whose work is loosely coupled, the genuine coordination need is intermittent. The fixed meeting overpays on every quiet day.

Part 2: The counter-evidence, which you should bring yourself

Walk in with the case against you already made. It is the fastest route to being taken seriously, and it stops your manager from feeling like they have to defend the meeting alone.

Standups, run well, do three things that are hard to replace.

They surface blockers early. A problem raised at 09:30 that would otherwise have consumed a full day is worth the fifteen minutes on its own. This is the function your replacement absolutely has to cover.

They build a shared picture of who is doing what, which reduces duplicated and conflicting work. Stray and Dingsøyr document this as one of the genuine benefits people report.²

They support psychological safety. Rietze and Zacher found a positive relation between daily stand-up meetings and psychological safety, which in turn related to work satisfaction and perceptions of team performance.¹⁰ That sits on top of Edmondson’s foundational work connecting psychological safety to team learning behaviour.⁹ A regular low stakes touchpoint does something for trust, especially on new or distributed teams.

So concede the point where it is true. If your team is small, tightly coupled, junior, or three weeks old, the standup is probably earning its cost and you should say so.

Part 3: Get your own data before you open your mouth

Two weeks. Three things. Do this before the conversation, because opinion against ritual loses and arithmetic against ritual does not.

Measure the real length, not the scheduled length. Time it every day. Most teams find the 15 minute meeting is a 22 minute meeting.

Do the salary math. Attendees, multiplied by actual duration in hours, multiplied by working days in a year. A team of eight at a genuine 15 minutes is 2 person hours a day, about 10 a week, roughly 460 person hours a year. At a loaded cost of 60 euros an hour that is around 27,000 euros, and that figure ignores the recovery cost on either side. Use your own team’s numbers so nobody can argue with the inputs.

Count the blockers. For ten working days, write down every blocker raised in standup, and mark whether it was resolved inside the meeting or somewhere else afterward. This is usually the number that ends the debate.

Ask the team anonymously. One question. Does the standup help you do your job, yes or no, and why. Anonymity is what gets you the real answer, and it also means you are speaking for the team rather than for yourself, which removes risk two from the list at the top.

Part 4: The wording

Four situations, four scripts. Adapt the specifics, keep the structure, because the structure is doing the work.

Every one of these follows the same four beats. Validate what the other person actually needs. Name the cost in their terms. Propose something reversible and time boxed. Put the burden of proof and the setup work on yourself.

To your manager, in a one to one

“I want to protect the team’s focus time without you losing visibility, and I have two weeks of data on how our standup is actually being used. It runs 22 minutes, not 15. That is about 460 person hours a year across the eight of us. In ten days, six blockers were raised and one was actually resolved in the meeting. The rest got solved afterward in DMs.

I would like to run this for four weeks. Written updates in a shared channel by 09:30 that you can read whenever you want, a dedicated blockers channel where people tag you directly the moment something is stuck, and one live sync a week. I will track blocker resolution time against what we have now. If it gets worse, we go back and I will say so in the retro. I will set all of it up.“

To your scrum master

“I have been reading the 2020 Guide again. It defines the Daily Scrum as an event for the developers, and it dropped the three questions. Ours has drifted into a round of updates aimed at whoever is most senior in the room, which is the thing the Guide is specifically trying to prevent.

Could we try running it off the board instead of round the circle, for one sprint, and ask the developers afterward whether it got more useful for them?“

Note what this does. It hands them the framework as the authority rather than you, and it makes them the person restoring the practice rather than the person defending a broken version of it.

To your peers, before you do anything else

“Be straight with me. Does standup actually help you, or is it just something you get through? I want to raise it, and I only want to do that if I am speaking for the team rather than for myself.”

Do this first. Always. If two people say the standup is the only time they get to ask for help, your proposal has to keep that, and now you know before you have committed to a position in public.

In a retrospective

“I want to inspect one thing today. I tracked our standup for two weeks. Here is what it costs and here is how many blockers it actually resolved. I am not asking us to cancel it. I am asking whether we change the format for one sprint and look at the numbers before we decide anything permanent.”

As a written proposal

Subject: Four week experiment, async standup

Right now our daily standup runs 22 minutes across eight people, which is about 460 person hours a year. Over the last ten working days, six blockers were raised in it and one was resolved inside the meeting.

Proposal, four weeks, fully reversible:

Written check ins in #team-standup by 09:30, three lines each. Progress toward the sprint goal, focus for today, anything blocked. Blockers tagged directly to the relevant person the moment they appear, rather than held until the next morning. One live 30 minute sync on Monday for planning and everything that needs a conversation.

I will track blocker resolution time, cycle time, and a short team pulse, and bring all three to the retro on [date]. If blocker resolution time gets worse, we revert. I will configure the tooling and run the trial.

The explicit revert condition is the most important line in that message. It is what converts your proposal from a change into a test, and it is usually what earns the yes.

Part 5: What they will say back

“I need visibility on what everyone is doing.” Written updates give you more than a meeting does. They are searchable, they persist, and you can read them at 07:00 or 19:00 instead of being in a room at 09:30.

“Blockers will sit there.” The opposite. A blocker posted the moment it appears gets attention faster than one held for the next morning. That is the specific metric I am proposing we track, and it is the one that would make me call the trial off.

“It is only fifteen minutes.” It is fifteen minutes times eight people, every working day, plus the time each person needs to get back into what they were doing. Here is the annual number.

“Scrum requires a Daily Scrum.” Scrum requires a Daily Scrum for the developers, and the 2020 Guide removed the three questions we are still using. What we run is not the thing the Guide describes.¹

“The team will lose cohesion.” That is a real risk and it is why the weekly sync stays. I am also tracking a team pulse during the trial, so if cohesion drops we will see it rather than guess about it.

Part 6: Five ways people lose this argument

Framing it as wanting to do less. This confirms the exact suspicion the other person walked in with.

Killing the meeting without naming a replacement. The mess that follows gets attributed to you personally, and it should.

Deciding alone. A team ritual changes as a team decision or it comes back within a month.

Skipping the trial and the metrics, which turns a testable proposal into an opinion contest against the status quo, and the status quo wins those.

Ignoring the people it works for. If the junior on the team relies on it, design around them and say so in the room. It costs you nothing and it removes the strongest objection before anyone raises it.

Part 7: What replaces it

	Live daily standup	Async written updates	Weekly sync plus blocker channel
Time cost	High, scales with headcount	Near zero synchronous cost	Low
Interruption cost	High, daily, mid morning	Minimal, self scheduled	Low, one fixed point
Blocker speed	Up to 24 hours of waiting	Immediate if tagged	Immediate if tagged
Record	None unless someone writes it	Searchable by default	Partial
Works across time zones	Poorly	Well	Reasonably
Cohesion	Good when run well	Weak on its own	Good

Seven options, with the honest downside attached to each.

Async written check ins via a bot. Geekbot, Standuply or Range prompt each person and post to a shared channel.¹⁷ Works across time zones, leaves a searchable record. Can decay into unread status theatre if nobody responds to what gets posted.

Twice weekly standups. Keeps the live sync, cuts the frequency. Simple to sell because it is a small change. Needs a companion channel for anything urgent.

Board walk instead of a circle. Go through the work items right to left and talk about the tickets rather than the people. Kills the personal reporting dynamic immediately. Only works if the board is actually current.

A dedicated blockers channel. The single highest value piece and the cheapest to add. Requires the discipline to post, and someone watching it.

On demand pairing. Fastest possible resolution, no audience. Reduces whole team visibility, so it needs a written trail.

One weekly deep sync. Room for the conversations a 15 minute meeting cannot hold. Too infrequent to work alone.

No meeting days. Shopify’s 2023 calendar purge is the most cited corporate example, reported as clearing thousands of recurring meetings from the company calendar.¹⁵ This is a focus policy rather than a coordination mechanism, so it has to be combined with one of the above.

The combination that works most often: written updates for daily awareness, a blockers channel for anything urgent, one live sync a week for the rest.

Part 8: Designing the trial so it survives contact with a retro

Pick your success metrics before you start, and pick ones your manager already believes in.

Delivery. One DORA style measure, usually lead time for changes or deployment frequency.¹² Cycle time works if you do not deploy often.

Blocker resolution time. Your safeguard on the main risk. This is the metric that should be able to kill the experiment, and saying that out loud is what makes the experiment credible.

Team pulse. One question, weekly, anonymous. This maps to the satisfaction dimension of the SPACE framework, which exists specifically because single metric productivity measurement goes wrong.¹¹ Without it you can improve throughput while quietly burning people out and never notice.

Four weeks is the right length. Two is too short to see anything past the novelty. Eight is long enough that reverting starts to feel like a public failure, which makes people defend the trial instead of reading it honestly.

The part that is actually hard

Everything above is available to anyone who spends an afternoon reading. Most people who need it will still not send the message.

The evidence is not what is missing. What is missing is a version of the sentence that says the meeting is not working without implying that the person who runs it is not working, and that is a much harder thing to write than a list of citations. It gets rewritten six times in a Slack draft box and then abandoned.

That gap is the reason we build Subtext. Most of the messages people cannot send are not complicated in content. They are messages where being right is not enough, and the wording carries the whole risk. A standup proposal is a small one. The same shape shows up in asking for a raise, declining scope, telling a founder the roadmap is wrong, and saying no to a friend.

If you take one thing from this: send the message with the revert condition in it. “If blocker resolution time gets worse, we go back and I will say so.” That single clause removes the reason anyone had to say no.

A note on the numbers I left out

Several figures circulate widely on this topic and I could not stand behind them, so they are not in the text above.

The claim that 80% of developers rate irrelevant updates as their top standup frustration does not appear in the Stray survey it is usually attributed to. The claim that 80% of meeting action items are never completed travels without a source. The often quoted “40% longer and 50% more errors” statistic attributed to a recent Journal of Experimental Psychology paper appears to be a garbled version of Rubinstein, Meyer and Evans in 2001, which measured lab based task switching and does not straightforwardly extend to a morning meeting.¹⁸ Various per team annual dollar figures for wasted meeting time depend entirely on the assumptions behind them, which is why the arithmetic in Part 3 uses your own team’s inputs instead.

One more honest gap. I could not find a rigorous controlled study directly comparing asynchronous written status updates against synchronous status meetings on delivery outcomes. GitLab, Doist and Basecamp all argue for the written version and all three have a position to defend. If your manager asks for that comparison, the accurate answer is that it does not appear to exist yet, and that your four week trial is how you generate it for your own team.

Think your standup earns its cost, or that I read the evidence wrong? Tell me on LinkedIn.

Samet Durgun is the co-founder of Subtext, an app that catches the emotional tone of your messages and rewrites them in your own voice. He’s based in Berlin.

Sources

Every link above goes to the primary source where one exists.

The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, scrumguides.org. The single most useful document for this argument. Read the Daily Scrum section directly and quote it verbatim. Establishes that the event is for the developers, is 15 minutes, and that the three questions were removed in the 2020 revision.
Stray, V., Sjøberg, D. I. K., and Dingsøyr, T. (2016). “The daily stand-up meeting: A grounded theory study.” Journal of Systems and Software, volume 114. Peer reviewed. Documents both the value (information sharing, joint problem solving) and the failure modes (status reporting to a manager, excessive frequency and duration). Send this one to a scrum master. Confirm the exact page range and DOI on ScienceDirect before you quote it formally.
Stray, V., Moe, N. B., and Bergersen, G. R. (2017). “Are Daily Stand-up Meetings Valuable? A Survey of Developers in Software Teams.” XP 2017, Lecture Notes in Business Information Processing. Survey of professional developers. Reported figures include 87% of agile teams holding daily standups with average ratings around neutral, junior developers more positive, senior developers and larger teams less so. I have used the directional finding rather than the percentage. Verify the exact figures in the paper before citing a number.
Stray, V. and Moe, N. B., practitioner writing in IEEE Software on adapting daily stand-up practice. Argues that rigid standup rituals should be adapted to the team rather than followed by default. Verify the exact title and year before citing, as the version circulating online includes participant counts I could not confirm.
Leroy, S. (2009). “Why is it so hard to do my work? The challenge of attention residue when switching between work tasks.” Organizational Behavior and Human Decision Processes, volume 109, issue 2. The origin of attention residue. Strong non agile evidence that task switching degrades the quality of what comes next.
Mark, G., Gudith, D., and Klocke, U. (2008). “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. And Mark, G. (2023). Attention Span. Hanover Square Press. Source of the interrupted work findings and of the roughly 23 minute resumption figure that circulates everywhere. The figure is real but frequently quoted with more precision than the underlying research supports, so cite the primary work and phrase it as “over 20 minutes.”
Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. The standard reference on meeting waste and post meeting recovery. I have used the qualitative finding rather than a specific percentage, because the numbers vary by survey.
Microsoft Human Factors Lab, EEG study on breaks between meetings, published via Microsoft WorkLab and the 2021 Work Trend Index. Physiological evidence that stress accumulates across consecutive meetings and that breaks reduce it. Useful because it is measurement rather than survey. Confirm the exact wording at the WorkLab page before quoting a figure.
Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. The foundational psychological safety citation. About teams generally rather than standups specifically, so do not overclaim a causal link.
Rietze, S. and Zacher, H., research on daily stand-up meetings, psychological safety, work satisfaction and team performance perceptions, European Journal of Work and Organizational Psychology. The strongest published argument in favour of standups, which is exactly why you should bring it yourself. Verify the publication year and exact title, as the version circulating gives a 2025 date I could not confirm.
Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. Freely readable. Use the satisfaction and wellbeing dimension to justify tracking a team pulse alongside delivery metrics.
Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. Source of the four DORA delivery metrics. Use one of them as your throughput measure so the metric is defensible rather than invented for the occasion.
Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” paulgraham.com/makersschedule.html. Short, free, and the most persuasive thing to forward to a colleague who is undecided.
GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. A large organisation publicly operating with asynchronous status updates. Proof that the model works at scale, though GitLab has an interest in the argument.
Shopify calendar purge, January 2023, as reported by Bloomberg, Fortune and others. Reported as removing thousands of recurring meetings from the company calendar and prohibiting recurring meetings above two people on Wednesdays. The specific hours reclaimed figure comes from the company, so attribute it to Shopify rather than stating it as measured fact.
Atlassian Agile Coach, standup guidance. Industry guidance recommending that standups be kept concise and adapted to team needs, including asynchronous formats. Useful because it comes from a source your manager already trusts on agile practice.
Tools: Geekbot and Standuply for async standups in Slack and Teams, Range for team check ins. Verify current pricing and product status before recommending one internally.
Rubinstein, J. S., Meyer, D. E., and Evans, J. E. (2001). “Executive Control of Cognitive Processes in Task Switching.” Journal of Experimental Psychology: Human Perception and Performance. The actual origin of the “up to 40% of productive time” task switching claim. Listed here so you can check it yourself rather than repeat the garbled version.