The Case Against Daily Standups in 2026

The Case Against Daily Standups in 2026

I’ve been thinking about daily standups lately—specifically, whether they still make sense for engineering teams in 2026.

This isn’t a “standups are terrible” rant. I’ve run teams with effective standups and teams where standups were pure theater. The question isn’t whether standups are universally good or bad; it’s whether the standard daily standup format still fits how engineering teams work today.

My conclusion: for many teams, it doesn’t. Here’s why.

What Standups Were Designed to Solve

To evaluate whether standups still work, we need to understand what problem they were designed to solve.

Daily standups emerged from Scrum in the 1990s, when software teams typically worked in the same office, on the same hours, with limited digital communication tools. The goals were:

Synchronization: Ensuring everyone knew what everyone else was working on, reducing duplication and coordination failures.

Blockers: Surfacing problems quickly so they could be addressed before causing delays.

Accountability: Creating a daily checkpoint where progress (or lack thereof) was visible.

Team cohesion: Maintaining a sense of shared purpose and collective effort.

These are legitimate goals. The question is whether a daily synchronous meeting is still the best way to achieve them.

Why Standups Often Fail Today

The Time Zone Problem

Distributed teams are now the norm, not the exception. When your team spans multiple time zones, finding a standup time that works for everyone means someone is always joining at an inconvenient hour.

The “solution” is usually to pick a time that’s bad for different people on different days, or to settle on a time that’s merely suboptimal for everyone. Neither approach is great. And the people joining at awkward hours aren’t fully present—they’re tired, distracted, or rushing to get to the meeting.

The Interruption Cost

Software development requires sustained focus. Deep work—the kind that produces good code—happens when developers can concentrate without interruption.

A daily meeting, even a short one, creates an interruption in the middle of the day. It’s not just the 15 minutes in the meeting; it’s the context switch before and after. Research suggests that recovering from an interruption takes 10-25 minutes. A “15-minute standup” might actually cost 45 minutes of productive time.

When standups happen at 10 AM, they split the morning. When they happen at 2 PM, they split the afternoon. There’s no time that doesn’t interrupt something.

Status Theater

Let’s be honest: many standups devolve into status theater. People recite what they did yesterday and what they’ll do today, not because the information is useful, but because that’s the ritual.

The three questions—“What did you do yesterday? What will you do today? Any blockers?"—become rote. People prepare their answers in advance, deliver them mechanically, and tune out while others speak. The standup becomes a performance rather than a genuine coordination exercise.

When was the last time your standup produced genuinely useful information that changed someone’s behavior? For many teams, the honest answer is “rarely.”

Blockers Don’t Wait

The theory is that standups surface blockers quickly. In practice, if someone is blocked, waiting until the next standup to mention it is terrible practice. Blockers should be surfaced immediately—through Slack, through a quick call, through whatever channel gets the fastest response.

Teams that rely on standups for blocker communication are actually slowing down blocker resolution. The standup becomes a scheduled delay in problem-solving rather than an accelerant.

Async Tools Are Better Now

In the 1990s, when Scrum was developed, asynchronous communication tools were primitive. Email was the main option, and it wasn’t great for quick team coordination.

Today, we have Slack, Teams, Discord, Notion, Linear, Jira, and countless other tools designed for team coordination. Status updates can be shared asynchronously. Blockers can be flagged instantly. Progress can be tracked in real-time through project management tools.

The information that standups provide can be captured asynchronously, without requiring everyone to be present at the same time.

When Standups Still Make Sense

I’m not arguing that standups should be abolished universally. There are situations where they still provide value.

Newly Formed Teams

When a team is new, the relationships and communication patterns haven’t been established. Standups provide a structured opportunity for face time that helps people learn to work together. The information exchange is secondary to the relationship building.

Crisis Mode

When something is broken and the team is in firefighting mode, frequent synchronous check-ins make sense. The situation is changing rapidly, coordination is critical, and the cost of being out of sync is high.

Complex Coordination

Some projects involve tight coupling between team members, where what A does today directly affects what B can do. In these situations, daily sync might be necessary to avoid blocking each other.

Teams That Want Them

If your team genuinely values standups—not out of habit or obligation, but because they find them useful—keep them. Team preference matters. Just make sure the preference is real and not just “we’ve always done it this way.”

Alternatives That Work Better

For teams where traditional standups aren’t working, here are alternatives to consider.

Async Standups

Replace the synchronous meeting with asynchronous updates. Each team member posts their update—what they’re working on, any blockers, any requests for help—in a dedicated Slack channel or tool like Geekbot.

Benefits:

  • No time zone constraints
  • No interruption to focus time
  • Updates are searchable and persistent
  • People can write thoughtful updates instead of speaking off the cuff

The key is making async standups genuinely useful, not just a written version of status theater. Good async updates include context, flag real issues, and invite specific collaboration.

Check-in Questions

Instead of the standard three questions, use rotating questions that prompt more useful responses:

  • “What’s the most important thing you need to accomplish today?”
  • “What’s one thing you learned yesterday?”
  • “Who on the team could you use help from?”
  • “What’s one risk or concern you have about the current work?”

Varying the questions prevents rote answers and surfaces different types of information.

Twice-Weekly Syncs

For many teams, daily is overkill. Meeting twice a week provides enough coordination while reducing interruption cost. Monday and Thursday works well—Monday to plan the week and surface issues from the weekend, Thursday to check progress and plan for Friday.

Office Hours

Instead of a meeting everyone attends, designate “office hours” where people are available for quick syncs. Those who need coordination show up; those who don’t, skip it. This self-selects for people who actually need to talk.

Walking Meetings

For co-located teams, replace sitting-in-a-room standups with walking meetings. The physical movement changes the dynamic, conversations become more natural, and you get the health benefits of not sitting all day.

Sprint-Based Alternatives

If you’re running sprints, you might not need daily standups at all. Good sprint planning at the start and regular PR reviews provide much of the same coordination. Add a mid-sprint check-in if two weeks feels too long without synchronization.

Making the Transition

If you decide to move away from daily standups, here’s how to do it without losing the benefits they provided.

Identify What You Actually Need

Before eliminating standups, identify what coordination needs they were (theoretically) meeting:

  • Do people need to know what others are working on?
  • Are blockers being surfaced and resolved?
  • Is there accountability for progress?
  • Is the team feeling connected?

Make sure your alternative approach addresses these needs.

Experiment Explicitly

Don’t just stop having standups and hope for the best. Explicitly try an alternative for a fixed period (say, 4 weeks) and then evaluate.

Questions to ask:

  • Is coordination better, worse, or the same?
  • How quickly are blockers being resolved?
  • Do people feel more or less connected to the team?
  • Is productivity improving?

If the experiment isn’t working, you can always go back.

Strengthen Other Communication

Removing standups means other communication channels need to pick up the slack. Make sure your team has:

  • Clear norms for async communication
  • Expectation of responsiveness on blockers
  • Regular (not necessarily daily) opportunities for face time
  • Visibility into what everyone is working on

Keep Some Synchronous Time

Async-first doesn’t mean async-only. Humans benefit from face time, and some conversations are better synchronous. Keep regular touchpoints—weekly team meetings, retrospectives, pair programming sessions—even if you eliminate daily standups.

The AI Factor

One more consideration: AI tools are changing how we work in ways that affect standup relevance.

AI-assisted coding means developers can often make faster progress on their individual work. But it also means they’re generating more code that needs coordination—more PRs, more potential merge conflicts, more integration work.

Some argue this makes standups more important: there’s more to coordinate. Others argue it makes standups less important: if everyone is moving faster, interrupting for a meeting is even more costly.

AI can also help with async updates. Tools can summarize git activity into natural-language updates, automatically surface potential conflicts, and draft status reports. The mechanical aspects of standup—gathering and sharing status information—can be partially automated.

This suggests a future where synchronous standups are reserved for the genuinely human aspects—relationship building, nuanced coordination, creative problem-solving—while the information-sharing aspects are handled asynchronously by tools.

Making the Decision

Should your team keep daily standups? Here’s a framework:

Keep them if:

  • Your team genuinely finds them valuable (not just habitual)
  • You’re in a phase that requires tight daily coordination
  • You’re a new team still building relationships
  • You’ve tried alternatives and they didn’t work

Reconsider them if:

  • They’ve become status theater
  • Time zones make scheduling painful
  • The interruption cost is noticeable
  • You have good async communication practices

Experiment with alternatives if:

  • You suspect standups aren’t working but aren’t sure
  • Your team is open to trying something different
  • You have the async tools and norms to support an alternative

The worst option is continuing standups out of inertia—because that’s what you’ve always done, or because Scrum says you should, or because stopping them feels risky. If standups aren’t providing value, they’re just a daily tax on your team’s time and focus.

Conclusion

Daily standups were a good idea for the context in which they were invented. Teams working in the same office, during the same hours, with limited async tools benefited from a brief daily sync.

That context has changed dramatically. Distributed teams, sophisticated async tools, and different work patterns mean the traditional standup often creates more costs than benefits.

This doesn’t mean synchronous coordination is dead. It means we should be intentional about when and how we coordinate synchronously, rather than defaulting to a format designed for a different era.

The best teams I’ve seen treat standups as one option in a toolkit, not a mandatory ritual. They use synchronous meetings when synchronous meetings add value, and async approaches when async approaches work better.

In 2026, that usually means fewer daily standups and more thoughtful alternatives. Your team might be different—but it’s worth asking the question rather than assuming the answer.

Related Posts

AI Code Review: The Hidden Bottleneck Nobody's Talking About
Process-MethodologyDevelopment-Practices
Feb 6, 2026
8 minutes

AI Code Review: The Hidden Bottleneck Nobody's Talking About

Here’s a problem that’s creeping up on engineering teams: AI tools are dramatically increasing the volume of code being produced, but they haven’t done anything to increase code review capacity. The bottleneck has shifted.

Where teams once spent the bulk of their time writing code, they now spend increasing time reviewing code—much of it AI-generated. And reviewing AI-generated code is harder than reviewing human-written code in ways that aren’t immediately obvious.

Jul 25, 2016
3 minutes

The Scrum Daily Standup

One of the hallmarks of the Scrum method of agile software development is a daily meeting, or “standup”. The purpose of the Scrum Daily Standup is to make sure the Scrum team is aware of what tasks the other members of the team are working on as well as asking for and offering assistance to other members of the team as needed. The Scrum Daily Standup is NOT a meeting to gather the project’s status. In addition, this is not a planning meeting, so the discussion of implementation details is outside the scope of the meeting, and should be handled in a separate meeting, or after the conclusion of the Daily Standup. The is typically characterized by being 15 minute long at its longest, and everyone stands during the meeting. Each speaking member of the meeting will typically answer these three questions:

The AI Productivity Paradox: Why Experienced Developers Are Slowing Down
Industry-InsightsEngineering-Leadership
Feb 2, 2026
6 minutes

The AI Productivity Paradox: Why Experienced Developers Are Slowing Down

There’s something strange happening in software development right now, and I think we need to talk about it.

Recent research has surfaced a troubling finding: experienced developers working on complex systems are actually 19% slower when using AI coding tools—despite perceiving themselves as working faster. This isn’t a minor discrepancy. It’s a fundamental disconnect between how productive we feel and how productive we actually are.

As someone who’s been experimenting with AI tools extensively (and writing about the results), this finding resonates with my experience. Let me break down what’s happening and what it means for engineering teams.