Why Have Daily Standups

What you're doing wrong and how to do them right


Part of my CTO Coaching

Sometimes I see blow-back against daily standups. “They are a waste of time” I hear. “They are boring” I hear. “We don’t do them” I hear. If they don’t work for you, they don’t work for you, which is fine. Choose the tools that work for you.

If you want them to work for you, listen. For me, they worked just fine, I’d even sa Daily Standups are essential.

Daily standups have several positive effects:

  • Alignment
  • Accountability
  • Productivity boost
  • Less other meetings
  • Remote team building

Alignment is one of the big challenges for managers. People who are unaligned move into different directions, often cancelling each others efforts out. Everyone pulling in the same direction produces much more momentum and less friction. Daily standups are one way to align people. Developers talk about their decisions and the decisions they want to make and get feedback. As a manager, you can begin and end the standup with giving context, and aligning people around strategy and vision and direction (shut up during the standup, only talk when asked).

Accountability is something managers often struggle with. The best way is to hold teams accountable. For that, it’s best the team members hold each other accountable to their commitments, around finishing dates, code quality or architecture. Which is hard to do, in Slack and around code reviews. Which is easier todo when people discuss upcoming decisions in standups. Also, “Why is no one working on this task?”

Productivity boost—I see some developers not asking for help or advice but struggling on their own for long periods of time. Perhaps they don’t feel safe (work on the root cause)—but nevertheless, it hinders team productivity. Supporting and helping each other boosts productivity, one opportunity to ask for help is the daily standup.

Condense other meetings into the daily standup. I see too many meetings—often requested and forced on developers by people outside of development. A way to minimize interruptions is to get people to the daily standup—people outside of development. Make it the standard and enforce it as the one way to interact with developers. Not whenever it suits people, but in the daily standup. When I attended standups as a manager, I encouraged everyone to discuss everything open and all questions right after the standup, when everyone was still there and out of the zone. In the office, two or three people step a few steps back to discuss what they have to discuss after the standup. Remote, have a break-out session to discuss things and ask questions after the meeting with those who this concerns. This is the time to discuss things for the day. Don’t end the daily and thirty minutes later ask a question to a developer, forcing them out of the zone. Ask after the daily and remove constant interruptions and speed up development. Which means you need to be prepared and also listen what happens in the standup. It’s not as convenient as jumping on a developer whenever it suits you, but it helps productivity (and it’s not about your convenience!).

Remote team building—CTOs today make the mistake, that they think remote is just like office but without the office. But there are many micro interactions in an office, teams sitting together that support building a team just by proximity. These go away with remote—so you need to actively do something to compensate. Daily standups are often the only way (they shouldn’t!) where teams see each other and interact. Interacting, seeing others act, understanding others builds trust. Daily standups are important for team building in remote teams and to build trust.

Anti patterns of daily standups

Why do developers often despise dailies? Why don’t they want to show up? Why do they push back on dailies? The reasons are that managers and cultures embody antipatterns of software development, meetings in general and daily standups in particular.

I have seen many antipatterns as a manager:

  • Teams too large
  • Meeting not for the people but for you
  • Manager in center
  • Wrong attendees
  • Push / push more work

Teams too large—Most of the teams I see are too large. With five or more developers, and perhaps QA and DevOps and product management. These split into several subteams naturally—so they are a team by name only. There are many downsides to this, in the case of meetings, there are many more opinions and many more people who want to talk—often repeating the same things. Everyone else is bored. If you have a daily with essentially three sub-teams (or even worse, have a daily, with different teams in one meeting, for your convenience, so you only need to attend one meeting instead of three), everyone except the team currently discussing things is bored—rightfully so. Smaller teams mean fewer attendees, which makes everything one says relevant to all attendees and not only a subgroup.

Meeting not for the people but for you - too many managers create meetings not for the people but for them. They want a status update (never have a meeting for this, only let people escalate if the status goes red, otherwise do not care about status), they want to push people and press them into deadlines. Managers want to put people on the spot. They don’t think about the attendees in the meeting, what is in it for them? For every meeting, think about what the attendees need, not what you need. Dear manager, (most) meetings are not for you.

Manager in the center is related to the last one. When I watch dailies in the office and remote, managers standing in the middle, going through the tasks and asking questions, often status updates. This signals to developers they are doing the work for you, they are reporting to you. You are responsible for everything they think. This takes away responsibility, ownership and takes the sense out of daily standups for developers. They dread them, waiting in line until you call them up like children.

Often there are the wrong attendees. The idea of dailies was that customers attend a daily to ask questions and be asked questions. This deteriorated into only product managers attending. No customers, e.g., customer support or marketing are attending, but product management acts as messengers, not adding value but delays and latency. Developers ask a question, PMs go to marketing, sit together, ask questions, then update a ticket, etc. which adds days to development and keeps developers waiting. With the right people attending, there is faster clearing blockers and sped up development.

Managers use daily standups to push or force more work. They want daily standups to push developers to work faster and harder. Managers want daily standups to extend the pressure they are getting (instead of pushing back on the pressure). Product managers often use dailies to push more work (“Can you do this too?” “This needs to be also done” “I added something to that ticket”) - no wonder developers dread daily standups that make their jobs more difficult instead of easier!

With all that said, focusing on the benefits and not falling into anti-patterns, daily standups can and should be useful to developers - they should love them not hate them.

Join CTO Newsletter

Join more than 3500 CTOs and Engineering Managers

More Stuff from Stephan

Other interesting articles for CTOs

Best books for CTOThe CTO BookExperienced CTO CoachCTO CoachingConsulting and Workshops to Save you TimeCTO MentorCTO MentoringCTO NewsletterHow many developers do you need?Postgres for Everything Technology and RoadmapsHow to become a CTO in a company - a career path

Other Articles

ManyCam dishonored my lifetime license

The Luck Formula

How Unit Tests Really Help Preventing Bugs

Fair Developer Salaries for Remote Work

Launch A Project In One Day