Standups Considered Harmful
Ever since they were introduced to software in the 1990s, standup meetings have become very popular, either informally or as part of Scrum, Agile, and related “methodologies” (although ironically the Agile manifesto says “individuals and interactions over processes”). It can be hard to find a product team that isn’t using a daily meeting like this to organize their work, such that it’s become a default way of organization. However I think there are a number of downsides that should be considered before adopting standups. They can be useful for certain types of work, but I do not believe that this is the majority of software work being done. In this article I’ll summarize some of the problems that come from standups, how we can minimize them, and when they might be more or less appropriate.
What is a Standup?
First I want to be explicit about what I mean by “standup”. This is a short (10-30 min) meeting attended by an entire engineering team. Each team member describes what work they have done in the past day and what work they plan to do. The motivation is to ensure everyone is aware of what the team is doing and any blockers or dependencies can be addressed. This is meant to ensure that work is proceeding according to schedule. Sometimes other stakeholders (manager, PM, designer, etc) also attend to observe.
Readers might be tempted to make “no true Scotsman” claims disputing this article, such as “well, we don’t have X problem because we do standups the right way.” I don’t really believe that any small adjustments fundamentally affect my claims, so although some improvement is possible, ultimately the criticisms will affect any sort of daily status update/planning meeting, whatever you want to call it.
Maker Schedules
Meetings in general are disruptive to engineers’ schedules, as Paul Graham famously wrote about. Each meeting adds a lot of cognitive load in terms of disrupting flow, requiring preparation for the meeting, and then getting back into the context of what you were doing before. For example, say you finished doing something and now have 15 min before your meeting. That might not be enough to do anything else, so instead of starting and quickly being interrupted you’d rather just do nothing. As a result, while adding an additional daily meeting might not seem like much of a time commitment, in reality adding these disruptions can cause the “15 min” to be more like 30-45 min in time spent. That might be around 10% of total working hours, we had better be really sure that we are getting something valuable out of that time.
In addition, one of the (logical) rules of standups is that they must be held at the same time every day and every team member must attend. This can be very awkward when considering different work schedules, especially with distributed/remote teams. For example, ideally a standup is at the beginning of your work hours, so you can get help with any blockers. But with a distributed team it’s likely impossible to meet that for everyone. If half your team has the standup at the end of their work hours it’s much less useful, and having it in the middle is maximally disruptive. Even if everyone is in the same time zone, due to differing obligations it can be hard for some team members to make the standup consistently, which will cause issues. It really feels like standups were born in a time of simpler “9-5” jobs, and doesn’t make as much sense in the modern world of flexible/remote work.
Short-term Work
Standups promote a focus on short-term work. Because you have the pressure to have accomplished something at every standup, and explain what you will do that day, it can feel uncomfortable to work on anything longer term. This means work like tech debt cleanup, refactoring, longer-term exploration/experimentation, and digging into tricky bugs is implicitly deprioritized. It’s much easier to say you “built feature X” (even if it was done in a terrible way that introduced tech debt) than you “started exploring how to refactor the code to enable faster development in the future”. Similarly, it sounds better if you “fixed bug Y” than you “started looking into bug Z” even if Y is not very significant and Z would be critical to fix for the business.
The quick nature of a standup means it’s not conducive to longer discussions or changing plans. If a junior engineer on your team runs into an issue that makes you realize their whole approach is problematic, it’s going to be very awkward to discuss that in the standup format. You probably have to schedule a follow up, and in the meantime they will perhaps keep working in the wrong direction. Or say you are experimenting with different approaches. Having to explain this daily makes it difficult, because you can’t really say you are “done” very cleanly. So instead you are incentivized to simply go with the first thing you tried, thus ending up stuck in a local optimum.
Status Seeking and Politics
A standup can feel like a status seeking contest. This is especially (but not exclusively!) if there are non-engineers at standups (such as managers). Everyone feels that they need to justify the work they will be doing, and try to avoid criticism. It can feel bad when someone not directly working on your feature/project has critical comments about your plans, and a standup is a poor format in which to have such a discussion (or to fully explain your work). This means people tend to discuss what they are doing in only vague or overly positive terms, which makes it feel like even more of a waste of time.
There can also be political games around who works on what. For example, A might say their project X is super important but needs more help, which leads the manager to later ask B to pitch in more to help A. But the short form of a standup and limited context means these decisions aren’t made with complete information.
When do Standups make sense?
Given all this criticism, you might think I am universally against standups. That’s not exactly true. What I am against is using them as a blanket default regardless of the team/project at hand. It’s important to recognize the limitations of any organizational approach, and pick the right one for the situation at hand. Standups can be effective if most if not all of the following criteria are met:
Very well-scoped work. The work being discussed needs to be scoped to a specific project with very clear requirements.
Smaller, focused team. Everyone attending should care about all the work being discussed. It shouldn’t consist of unrelated status updates on N different projects.
Team has less experienced (more junior) engineers. They can benefit from the additional structure and guidance much more.
Strict external deadlines. There should be a reason for needing to keep everyone on the right schedule.
Only engineer attendance. The meeting should be about getting things done, not status or politics.
Similar work schedules/time zones. If not everyone can attend at the same time it greatly diminishes the value of a standup.
Additionally, consider if you can have your standup asynchronously. Each person could write what they wanted to say in a Slack message, and you can have some broader time window in which everyone posts these, to account for differing schedules.
In my experience it is rarely the case that all of these criteria are present. For everything else, it’s time to consider alternatives.
What is a better approach?
My favorite alternative is a combination of two things:
Frequent informal communication among stakeholders. This can be over Slack, e-mail, or anything else asynchronous. Rather than waiting till a specific time to communicate, you should communicate as soon as there is any issue. Not sure about some edge case? Immediately send a message about it. Waiting on a dependency? Ask the person responsible how it’s going. These communications should be narrowly focused to the people working in that area, to avoid disrupting everyone else.
Weekly/biweekly team meeting. This can be longer, like 30 min-1 hour, depending on the agenda (only make it longer if you actually have something to talk about). The goal of this meeting is to have more involved discussions about project work and to give the whole team higher-level updates. For example you might summarize your project plan for some upcoming work, and get feedback about what people think. Or you might discuss some tradeoffs in implementing a feature, to figure out what the best approach is. This should be very flexible depending on the needs of your team.
With this setup you get a lot of the “move fast” benefits of standups (indeed, even faster in some cases), while reducing the disruption and unnecessary daily process that can feel like a burden. The quick discussions that happen in standups can be handled even better with the informal communication, and any longer discussions you can handle at the team meeting (or, if needed, schedule ad hoc meetings, of course). Of course often teams using standups also have these two things as well, but my argument is that in that case the standup itself is completely unnecessary and overall negative.
Avoiding standups means that engineers are more able to focus on tech debt and other longer-term work (when important). They don’t feel the need to justify their own workload and have reduced stress and better work flexibility. They are more able to experiment and adjust their work to focus on the important things that come up.
I don’t expect this to make a strong dent in the prevalence of standups. Sadly, I think in practice they are actually used as a form of micromanagement to give managers and other stakeholders the illusion of control over the inherently disorderly world of software engineering.