Every morning at 9:15, a dozen developers shuffle into a room or log into a video call to answer the same three questions they answered yesterday. What did you do? What will you do? Any blockers?
We have been doing this ritual for so long that questioning it feels like questioning gravity. Stand-ups are just how teams work. Everyone does them. They must be valuable.
Except they are not. The daily stand-up, as practiced in most organisations, is not a communication tool. It is a surveillance mechanism dressed up in Agile clothing. And in 2025, with distributed teams and async-first tooling, it has become an actively harmful anachronism that we keep doing because nobody wants to be the person who suggests we stop.
Let’s be honest about what happens in most stand-ups. Status theatre. People give carefully curated updates designed to sound productive. Nobody says “I stared at a bug for four hours and got nowhere.” They say “I was investigating the authentication issue and making progress.” The information exchanged is optimised for looking good, not for being useful. Blocker silence. The blockers question almost never surfaces real blockers in the moment. If someone is actually stuck, they already pinged someone in Slack or grabbed five minutes with a teammate. The blockers that do get mentioned in stand-up are often already resolved or too vague to action.
Then there is the time waste. Eleven people listening to updates that are relevant to maybe two of them. Do the maths. A 15-minute standup with 12 people is three hours of combined human time. Every day. For information that could be conveyed asynchronously in a fraction of that time. The interruption cost is real too. For developers especially, mornings are often when deep work happens. A 9:15 meeting fragments the morning, making it harder to get into flow before lunch. The stand-up does not just cost 15 minutes. It costs the 20 minutes of context-switching on either side. If the goal is genuine communication, stand-ups are extraordinarily inefficient. But that is not actually the goal.
Strip away the Agile vocabulary and look at what stand-ups actually do. They provide management with a daily assurance that everyone is working. They create a scheduled moment where presence is verified and activity is reported. They give people with status anxiety, both managers and individual contributors, a predictable touchpoint that makes them feel informed and in control. This is surveillance. Friendly surveillance, wrapped in team-building language and justified by methodology, but surveillance nonetheless.
I have worked on teams where the stand-up was the only interaction some managers had with the actual work. They did not read commit messages or pull requests. They did not participate in design discussions or code reviews. But they attended stand-up every day, nodding along to updates they did not really understand, because that is how they knew the team was being productive. The stand-up exists to make managers feel like they are managing and to make workers demonstrate that they are working. The actual communication, the collaboration, the problem-solving, happens in other channels. Always has.
Scrum practitioners will push back here. Stand-ups are not for managers, they will say. They are for the team to self-organise. The Scrum Master is there to facilitate, not to monitor. In theory, sure. In practice, I have never seen a stand-up where the power dynamics magically disappeared because someone read the Scrum Guide. The manager is in the room. The updates are heard. The mental model of “reporting status” persists regardless of what we call the meeting. And even if we achieved the theoretical ideal, even if the stand-up truly was just developers coordinating with each other, the format is still terrible. Synchronous verbal updates are a bad medium for technical coordination. By the time you have described the problem verbally, you could have written it down with enough context for someone to actually help.
The shift to distributed teams made all of this worse. Stand-ups over video call are strictly inferior to in-person stand-ups, which were already not great. The casual sidebar conversations that sometimes made in-person stand-ups worthwhile, two people realising they should sync after hearing each other’s updates, do not happen when everyone is in their own little video rectangle. Instead, you get the awkward “who goes next” dance, the connection issues, the people who are clearly multitasking with muted cameras, the time zone contortions that mean someone is always attending at a bad hour. Some teams responded to this by making stand-ups asynchronous. Post your update in Slack. Write what you did, what you are doing, what is blocking you. This is better than synchronous stand-ups but it still misses the point. The format is the problem. The three questions are the problem. The daily cadence is the problem.
Here is what I have seen work in teams that genuinely communicate well. Continuous async updates tied to work. When you finish something, post in the relevant channel. When you start something, update the ticket. When you are blocked, ask for help immediately, not 18 hours later at the next stand-up. The information flows when it is relevant, not on a calendar schedule. Working in public. Default to visible. Write your design notes in a shared doc, not your head. Think out loud in Slack. Create a paper trail that anyone can catch up on without needing to attend a meeting. This takes practice and cultural support but it creates genuine shared context. Regular actual conversations. Not status updates, conversations. Weekly team time where you talk about the work at a level deeper than “what did you do.” Architecture discussions. Retros that actually change things. One-on-ones that are not checkbox exercises. And trust. Here is the radical idea: assume your teammates are working. Assume they will ask for help when they need it. Assume they will communicate blockers when they encounter them. Stop building processes that assume the opposite.
The teams I have worked on that ditched daily stand-ups did not collapse into chaos. They communicated more, because communication was not artificially concentrated into a 15-minute window. They self-organised better, because they were not relying on a daily ceremony to do the organising for them.
When I suggest dropping stand-ups, I usually get one of two reactions. Managers worry they will lose visibility into what the team is doing. Individual contributors worry they will lose accountability structure that helps them stay focused. Both fears are valid. Both fears reveal something important about how we have structured work. If you need a daily meeting to know what your team is doing, you have a visibility problem that the meeting is masking, not solving. The work should be visible in the tools. The tickets, the commits, the deploys, the discussions. If it is not, fix the tools and processes. Do not add a meeting. If you need a daily meeting to stay accountable, you might have an environment problem or a motivation problem that the meeting is masking, not solving. Are you working on things that matter? Do you have the autonomy to make progress? Is the work structured in a way that provides natural feedback loops? These are harder questions than “did you attend stand-up” but they are the right questions.
I am not saying all synchronous meetings are bad. I am not even saying team check-ins are bad. I am saying that the specific ritual we call “daily stand-up,” with its three questions and its daily cadence and its whole-team attendance, has outlived its usefulness. If you want to keep a regular team sync, make it less frequent. Twice a week. Once a week. Focus on things that actually benefit from synchronous discussion, like upcoming work, dependencies between people, architectural questions. Let the status updates live in async tools where they belong. If you have blockers that need immediate attention, surface them immediately. Slack, a quick call, walking over to someone’s desk. The idea that you would wait until the next morning’s stand-up to raise a blocker is absurd on its face, yet the blocker question persists as if it serves some purpose.
If you want visibility into the team’s work, build dashboards. Read tickets. Watch commits. Join channels. Do the work of staying informed instead of outsourcing it to a daily performance. And if you are a manager who is reading this with rising defensiveness, ask yourself: what would you actually lose if stand-ups disappeared tomorrow? Would you lose information you could not get another way? Would you lose coordination that would not happen otherwise? Or would you lose a daily ritual that makes you feel connected to work you otherwise do not touch?
The stand-up is a security blanket for anxious organisations. In 2025, we have better tools and should demand better practices. Let it go.