9:30 am: “What did you do yesterday? What are you doing today? Any blockers?”

Daily Standup is a status meeting at best and a manager’s opportunity to legitimize micro-management at worst.

I get why the 3-questions dogma has become so popular and I really don’t intend to upset any scrum master who follows this ancient, daily ritual. But, when did you last take a second to review its impact?

One thing I find particularly telling is the sheer number of articles trying to inspire “how to make daily standup more efficient”, “suck less”, etc. If we need thousands of articles to tell us how to run a reoccurring 15–30 min meeting, then we have a problem.

Daily scrum was originally designed for developers. Nowadays everyone wants to pitch in, causing the once quick and concise meeting to drag on. The most inefficient standup meetings occur when everyone takes turns reporting on their work schedule. What happened to focus on delivering value to customers and driving progress forward?

What’s even more fun to watch is how every d*mn department has introduced daily standups. Sales teams, customer success managers, and finance folks. Like developer ceremonies weren’t enough, non-development teams now also start calling themselves “FinOps”, “SalesOps”, etc.

Even Management Consultants feel left out. I’m hearing the phrase “PowerPoint developer” more frequently now.

I get the same feeling when vegans draw parallels to regular food by labeling vegan options “plant beef”, such as “tender vegan roast beef”. It’s not beef. It’s not tender. It’s plant mush. The same goes for daily standup. It has become management mush.

There’s a lot of organizational and monetary overhead when doing daily standups. People need to set aside time, 5 days a week, for 30 min (yes, it’s no longer 15 min when everyone needs to talk). Imagine a team of 10 averaging ~65$ per hour. That’s about 6500$ per month. Just for synchronizing. We haven’t even started thinking about other rituals such as retrospectives, demos, planning, refinement, or managing a laborious agile (kanban) board.

The daily standup is a status meeting. Period.

No matter how much you fight it, it is a status meeting. How is “what did you do yesterday? What are you doing today? Any blockers?” not a status update? Come on.

The daily scrum “serves to keep the team coordinated and on track” (according to Moreira, 2010). Let’s be honest, if the team can’t keep on track by themselves, then the members haven’t internalized the right principles, and the daily scrum is for management’s sake, to keep developers on a short leash. At this point, you got other problems to attend to.

How can we do things differently?

I don’t have a definitive answer, but what I can tell you is the absolute best software projects I’ve worked on only involved very few developers. The perfect team size is 3. At that size, you don’t need a formal synchronization process. What you do need is the following:

• Access to business analysts and the product owner.
• A shared vision and understanding of what you’re doing and where you’re going.
• A set of common principles, i.e. when to reach out for help, what code quality level to strive for, and how often each member demo progress (preferably daily demos).
• Frequent pair programming. This is a must.

The primary goal is to ensure the team is aligned and provides value to its customers. That’s it. It doesn’t have to be difficult. You don’t need several coordination events.

I get that we can’t abolish daily standup (completely at least)

It’s often not feasible to get rid of daily standup, but, we can significantly improve it by shifting our focus to the right aspects. The common practice of asking each developer what they did yesterday, what they plan to do today, and if they face any obstacles is not a very effective approach, in my opinion.

Instead, the team I’m currently working with has discovered a more effective rhythm that centers around the tasks currently in progress. We concentrate on the following key questions:

• What is the progress of the task and what work remains?
• Have any new insights emerged regarding the task or feature?
• Has the scope changed, or is the complexity greater than initially anticipated?

These questions serve as a starting point, and we don’t rigidly stick to them. Furthermore, it’s important to note that these questions are not directed at anyone in particular. We encourage anyone with relevant knowledge to contribute and share their insights.