Why Your Daily Standup Sucks (and how to fix it)

Posted on by in Process

The daily standup is the “Hello World” of agile development. It’s a daily, 15-minute meeting, about the current status of a project. Each participant answers three questions: what did I do yesterday, what am I doing today, what is in my way. Sounds simple, right? However, it’s surprisingly easy to turn a standup into another useless meeting.

Let’s look a few common standup “smells” and how to fix them.

Too Much Detail

Excessive rambling will lose everyone’s attention. Keep it short. Summarize like you would in a resume. If someone needs more information, talk to them after the standup.

People are Unprepared

It’s a daily standup, it happens everyday at the same time; it’s not a surprise meeting. Show up on time and come prepared. Review your logged time, source control commits, or in flight stories before standup.

If you’re leading the standup, start and run the standup in a consistent way. Make it obvious to people when it’s their turn to speak and who’s next. Don’t randomly choose people to speak. When leading a standup that includes both local and remote people, establish and follow an overall order across all locations.

Too Much Problem Solving

The daily standup is only a status update. It’s not the time for discussion or problem solving. Your mantra is: “take it offline”.

Setting a time limit for each person is a great way to avoid problem solving. If a few people start to go off on a tangent, regain focus by encouraging them to “take it offline.”

Trying to Remove Blockers

Deal with blockers after the standup. A simple “I can help you with that” from another person is enough.

After the standup, put blockers on a whiteboard to ensure they’re addressed. Just don’t bring the whiteboard to the standup and waste time adding blockers to it.

Starts Too Late

The daily standup starts your day. It’s important to find a time that isn’t too late in the day because developers often don’t start working until after the standup. You don’t want the standup to be halfway through someone’s day, so try to get the team to work relatively similar hours.

If you’re using voice or video conferencing, ensure it’s setup before the standup. Appoint someone to be responsible for this setup and make sure everyone knows who it is.

Once you find a time, start the standup at that time everyday. And don’t wait for anyone.

Constantly Interrupted by Observers

It’s sometimes common at a standup to have people who are not there to participate, only to observe and check on the status of the project.

Observers are often not familiar with standup meetings. Ensure they know the rules to prevent them from interrupting or sidetracking the standup.

Over-reliance on Tools

Avoid using any external tools such as Pivotal Tracker. The standup is not the time to review all the stories that are currently in flight. It’s far too easy to get distracted using tools, lose focus, and waste time.

Keep It Simple

The consensus on standup length is 15 minutes or less. Efficient standups, even with a fairly large team of say 12, often take less than 10 minutes.

If your standup is starting to feel painful, look for some of the above smells. Most of them are due to people not keeping it simple. Simplify and prove you’re agile by continuously addressing these problems and perfecting your standup.

What do you do to keep your daily standup simple?


  Comments: 39

  1. Michael Wynholds

    A few of my own thoughts:

    1. ALWAYS start on time. If people miss the daily or show up late, that should shame them in to getting there on time. (This is true of all meeting, not just standups, in my opinion).

    2. With geographically disparate teams, the leader should establish up front an order for when locations speak in the standup. (ie: San Francisco, then London, then Mars). The leader should always kick things off, and then should specifically identify which person goes next, next, etc.

    3. No lurkers at all. If you’re there, you do your daily. Even if you say “I didn’t do anything yesterday, and probably nothing today… no blockers”, at least then we know. And nobody is wondering who the f*** you are.

    4. Most dailies should have follow-up meetings / conversations come out of them. If there are none, then either you are talking about too much stuff in the daily, or nothing interesting is happening on your project.

    • Addressing point 4. Another reason that you might not have any follow ups from you standup, is that your team is actually functioning effectively and is engaging in a process of constant communication. Not forced discussion is required at an arbitrary time in the morning because the discussion that is needed and valuable has happened, is happening and all the team members are confident it will continue to happen.

      • Michael Wynholds

        I agree, Tim. That is an ideal steady-state for perfectly functioning teams to be in. And in that case I imagine the team knows they are killing it, so nobody worries that nothing new is coming out in the standups.

        But that is a tough scenario to achieve and then maintain. I think 5-15 minutes each morning is a very small price to pay to make sure that no communication is slipping through the cracks.

        • I doubt that 5-15 minutes is enough time to make sure that /nothing/ is missed. in my experience I don’t think it really contributes significantly unless your team has really serious communication problems; but even in that case it only meets the most basic intra-team communication requirements. It doesn’t seem to provide a fail-safe backstop communication channel.

          Rather, I see some team members thinking “well, I did the standup, that is my communication done for the day”.

          • Your team sounds awful. Where is it, so that I can avoid it?

          • Actually, I think the team I am currently in is very good. We build extremely reliable software, mission critical software, and have very good communication in the team and in the whole company. Everyone is friendly, helpful and pro-active. However, my view is that its was not the stand ups that did it (rather they had a negative impact), it took quite a bit of time, experimentation and a lot of other “agile” techniques. It would be a mistake to think that my view on standups comes from an experience of a team not capable of functioning and communicating at a very high level. We talk to each other a lot, many times throughout the day. We work in an open environment where everyone is physically close, everyone can hear each other and is free to join in any conversation. We promote an open shared ownership style, where no one is assigned tasks or special responsibilities and are always free to help other team members. We go often to lunch with each other, know about each others families, help each other out with non-work issues… etc, etc

          • You lost me at “mission critical” and I stopped reading at “pro-active”. If you talk in the same pompous, flowery manner the way you write I would hate you from day 1.

          • Hehe, I am really enjoying talking to you lekoshe. Being insulted and hated by a stranger for the way I speak is a wonderful accomplishment. I wonder if you could be moved to make a threat on my life next, then I could print out this thread for my wall? I hope one day we do end up on the same team. I think it would be a lot of fun to write some mission critical software with you.

          • Happy to oblige. Share it with your friends! That is, if you have any outside your socialist fantasy workplace.

          • lekoshe, you had me at elmo.

            ok seriously lekoshe – I don’t see a reason to read between the lines of what Tim’s writing & find all the fault. I hear a lot of people talk about “mission critical” software, just as some people might work on financial systems and some don’t. No biggie & I didn’t read it to be a pompous gesture.

            I know it’s easy to latch onto words online & ridicule people, but you’ve all made some pretty solid points, and this discussion definitely helped me reflect a bit about how I could communicate with my fellow devs and our bus. users a little better.

            It would be cool if we could keep the conversation at a civil level, without having to make personal attacks…maybe other people can learn from this stuff too. Just my 2 cents.

          • For people who are wondering why “lekoshe” is attacking Tim personally, that is because, he doesn’t have the ability to attack Tim’s arguments (in a rational way), therefore he is attacking Tim personally for deigning to question the status quo.

            That is pattern #3 in my list of anti rhetorical antipatterns:

            It’s great to discuss things but it’s not great to attack people in an attempt to shutdown alternative viewpoints. We as a community need to be vigilant against this since this is a well trodden horse dating back to the XP days.


          • No, I am trolling for sihts and giggles. I haven’t actually made any worthwhile point at all except to express my profound dislike for Tim’s writing style and the subversive trotskyite collective he calls a workplace. Also, a picture of Elmo.

            The truth is I agree completely and we have abandoned standups in favour of loose coordination via IRC, peer-review of git pushes, spontaneous showcases, and a mutual atmosphere of respect and free beer.

            But feel free to promote your blog.

            NB: I visited looking for google ads to click through to help boost your revenue but I couldn’t find any, sorry.

  2. I agree with all the point EXCEPT one; I like using random order when it comes time to do the daily. I feel that a regular order, while expected, causes certain voices to dominate the conversation, others to enter or leave when expected, and overtime can make the whole thing feel stale.

    • Good point, the leader should delegate who goes next. The leader could randomize the order.

    • If you’ve got a leader, sure. But the end goal really ought to be an autonomous team with all members contributing and self-organizing. Correlation: high functioning teams look at all members of the team during stand up. Newly formed teams all address “the leader” and not their fellow team mates.

  3. The one category missing here is when stand up content is irrelevant to the other members. I’d classify the problems above as “good problems” with the exception of “Starts too late”. The problems above indicate that the team is engaged and wants to collaborate. A true stand up problem happens when people are specialists don’t pair or people don’t have overlap in what they’re working on. This standup looks like a bunch of people talking about a bunch of different, mostly unrelated problems, and everyone saying “huh, that’s interesting” but not offering any help. People quickly start to complain about these standups as “a waste of time” without fully understanding that the standup would make more sense if there was more overlap in work.

    • I agree.

      If the attendees concerns really don’t overlap then a solution might be let different groups hold their own standups. Unfortunately I think a more common problem is disparate groups on the same project who should have common concerns failing to find effective ways to actually work together.

      There can be very good reasons for that. Not everyone on a team works on the same problem or is looking at same point in a product’s life. We can try to shorten product cycles and encourage collaboration but it can still be hard to find a way to form a useful standup.

      The best solution I’ve been able to find in that sort of case is to use different standups to address different problems. Developers might meet together and coordinate feature work, changes, pairing arrangements, and so forth. A larger team can then meet up but try to focus on interdependencies and blockers; a designer needs support for a new UI feature, developers need new art assets, a QA engineer needs clarification on a feature’s behavior, or a product manager needs to talk to developers about a new feature they’re considering. Unfortunately I find that still feels either like these groups aren’t talking enough or too long meeting to be a good standup.

      • If you extend this argument to what I now think is its logical conclusion, I believe that if your Team members are really functioning as a Team, working on related things, pairing, etc then they don’t need an arbitrarily timed standup at all, the things that are supposed to happen in a standup happen continuously. Everyone already knows what everyone else is doing.

  4. I can’t agree more. Very good post on common stand-up “smells”.

  5. If the goal is to have a group of people briefly give a status update, why not do it through email? If nobody’s actually talking to each other until after the meeting, what was the point of the meeting?

    • A standup is your chance to listen and identify who you need to talk with in order to let either of you move forward with your current tasks. It does not need to be a time for you to talk at length. Figure out who you need to speak with but there’s no reason to block the entire team with every discussion.

      martinfowler.com has a better overview of the whys and how’s of standups than I can offer off-hand: http://martinfowler.com/articles/itsNotJustStandingUp.html#TheGoalsOfTheDailyStand-upAreGifts

      While email theoretically addresses the technical requirements of a daily update it fails to offer social structure for the team, ensure that everyone actually pays attention, or remain short enough to be useful.

      • It seems to me problematic, and symptomatic of the micro-management approach that daily stands-ups encourage, that the need is felt to use what is effectively a ritual as a substitute for social structure within a team.

        • You sound like the kind of anti-social sourpuss I don’t want in my team at all.

          • If you read my comments closely, you will see that what I am suggesting is quite the opposite. I, and my co-team members, have worked hard to create a friendly, helpful, shared responsibility environment where everyone feels valued and influential. I am simply suggesting that although stand-ups may have some of the appearance of an environment like that, my experience has been that they are actually a substitute for it, and in some ways an obstacle too it.

            For example, I would not think it a useful way of promoting communication to personally insult someone. I prefer to try to create an environment where robust technical discussion can occur, without it turning into enmity, anger or unhappiness.

    • Hi,

      Because face-to-face communication is the best, and you’re not sure if the people will read the email, and you’re not sure if those reading the email are not lazy enough to actually reply to you if they have questions, and you want everyone to participate in the standup meeting. It only takes minutes anyway.

      By the way, I think you might be interested in reading this article 10 Reasons We Have Daily Stand Up Meetings. It’ll probably you help you understand and appreciate those standup meetings.

      • What makes face to face communication “the best”? It may be “the best” at resolving issues, but it isn’t the best for communication rote information.

        I read your list and disagree with forcing everyone to work the same schedule; some people are morning people and some are not. Are you going to fire all the afternoon people so that the morning people are happy? Or vice versa?

        Why not come up with communication that enhances people to be themselves and work their most productive hours versus trying to chain gang everyone into a rote 9-5 environment. Process over people? Sure sounds like it


    • Exactly. If they can’t be trusted to read the email, that is a problem that should be solved. Forcing everyone into a pointless meeting because a few people don’t read their emails is punishing the team for the sins of a few.

      Communication needs to happen but it doesn’t need to happen in a way that coddles the slackers and underperformers.

    • There are a few problems I’ve observed from teams that do email/chat-based standups:

      1. Most people are DROWNING in email or even IMs. This makes the chances of missing story updates very, very good.
      2. It encourages a communication anti-pattern whereby people devolve to resolving issues over email or IM instead of doing it face-to-face. This can slow down progress (see point 1) unless your team’s online communication is solid (i.e. Slack channel with 100% daily active participation)
      3. It’s a very forgettable process; making it not so would require much more management on top of it than needed for a daily standup (i.e. reports on who’s participating in the email standup, rules enforcing the email, etc.)
      4. Many teams use it as a start-of-day marker; email removes this. (Whether it should start the day or not is a different debate.)

      The standup shouldn’t just be a status update; it should also be a time to get people unblocked or working together.

  6. In my experience stand-up meetings have two functions:

    1) allow management to impose a command and control structure for micro-management purposes. software development doesn’t happen on the time scale of days. the best software I have produced involved sitting around variously chatting to other people (domain experts, customers, team members) and reading other software, books, blogs, trying things, etc. really good software is written on the time scale of months and years. daily standup meetings obstruct that, for this reason I don’t think they belong in an agile team.

    2) act as a substitute for real peer-to-peer communication. they replace real (that is to say useful with actual value adding information transfer) communication between team members. people don’t have ideas at the same time every day, and they don’t always have anything meaningful to say just because someone else wants them to. daily standups force developers to concentrate on having something to say the next morning rather than thinking about and contributing to the overall team and business performance. for this reason I do not think they belong in any team.

    Stand up meetings are a smell of poor management, organisation and resource allocation. They are a work around for a poorly performing organisation with inadequate planning, communication and feedback cycles. Rather than fix those much harder problems the development team pretends that software development is something that happens over a few hours each day.

    My biggest regret so far in my software career has been to naively introduce stand-up meetings to teams. I would never do it again.

    • Michael Wynholds

      Tim, I think your points are well thought out and well laid out. However, I disagree with both of them.

      1. Standups are not about command and control. They are about fine-tuned course correction and facilitating peer-to-peer communication (see #2). Software doesn’t get built in a day, but miscommunication happens easily at that granularity, and standups can help avoid that. On a functioning development team, all of those types of communication you mention happen in addition to standups.

      2. Nobody (well, not me anyway) is trying to replace peer-to-peer communication with standups. The exact opposite. Standups facilitate communication by forcing people to communicate a bare-bones synopsis of what they are working on. One developer may think what he is working on could not possibly affect another developer, when in fact that isn’t true – and a 5 minute standup can avoid a huge problem later.

      As a side note – how hard can it possibly be to have something to say when all you are being asked is what you did the day before and what you are going to do today? If you don’t know those things, then what the hell are you doing?

      Final thought – if you think standups are just a tool of micro-management, then have your standups with the development team only. You can do course correction weekly at an iteration planning meeting, which for long projects (like you talk about) is fine-grained enough. And the standup will still catch any miscommunication that might have slipped through the cracks of pure peer-to-peer communication, as well as keep everyone informed of what everyone else is doing.

      • Its not difficult to say what you did the day before; but its the wrong focus to have – its pointless and distracting. If there is little value in what you have to say, then what you say will tend to become uninteresting – you should be in the position of most of the time saying, “everyone already knows what I was doing”. And any time that that wasn’t what you were going to say probably means you have missed the right time to have communicated it.

        If you are forced to compress what you did in a whole day into a 1 minute presentation you will just say task focused stuff. It adds an inertia to the team to carry on doing what was already planned. “I took task X of the task board and I completed it”. Great…. but was it the right thing to do? Did you complete task X because it was easier than saying “I had a brainwave and spend the day thinking about the overall design of the software and comparing it to the architecture of opensource project X because I think we might be going down the wrong route”. My experience is that less confident (conflict avoiding) team members will just complete task X. Sure your velocity will /look/ better…

        I would argue that if your developers need forcing to communicate then you have a much more serious problem than can be fixed by a standup meeting. How about doing more group programming, or group reviews? How about a book-club, or a team lunch or generate some discussions about the latest programming fad.

        • Michael Wynholds

          Your points are very well taken, but would argue that in one minute you can say “I took task X off of the backlog”, and you can also say “And I think we should rethink our overall architecture after taking a look at project X”. And the second thing will spark a follow-up conversation. Dailies that I have been on have done that type of thing over and over again to great benefit.

          As for forcing the team to communicate… I agree with your point but it is not what I am saying. At least for my teams, we do standups, we do group reviews, we do book clubs and we do lunch brown bags. They are all additive, and they all work together. For me, it’s about having as much communication as possible – some scheduled at various granularity (daily, weekly, etc), and some impromptu.

          But just to be clear, I have been doing dailies with my teams for 10 years, and they have been a very useful part of our process. So if they don’t work for you and your teams, then definitely don’t do them. But lack of utility is not an inherent property of standups, it’s just a property of standups on some teams, including clearly the ones that you have been on.

          • But how well could your team have been doing if your weren’t doing standups? How many of your team members didn’t mention that they spent the day looking at project X because they didn’t want to get a (no-doubt-subtle) micromanagement bashing after the standup?

            Ok, so, YMMV and I am not accusing anyone specific of anything, there is so much literature out there, and success reports, that I guess they must be working for someone. But in the teams I have been in, I have often found that it is typically the team members with the loudest voices and the best aptitude for conflict (by which I mean technical disagreement, not shouting at each other) who are also the ones most likely to push standup meetings. So maybe those are the just the ones most up on the literature; or maybe standups are a subtle way for them to control their (defacto) team?

      • I am not saying they are just a tool for micromanagement. I am saying that they are a vector by which micro-management happens. I have tried stand-up meetings with various different compositions. But what I have observed so far is that even then, the more senior development team members (that is to say the people most likely to be held directly responsible for the performance of the team as a whole) will tend towards micromanaging the less senior team members. I think its important to establish a self managing style in a development team. I know that standups are supposed to be peer-to-peer, but I have not been able to create that using them. I have been able to establish that in a less structured, more self-discipline environment.

  7. Agile development is for when you just don’t have enough micro-management in your day. 🙂

    • I actually believe that agile practices are the opposite of micro-management, when done correctly. Take the daily for example; if treated as a meeting to harass and direct your team, you’re doing it wrong. It’s a forum for the team to check in and support each other, done in 15 minutes or less.

  8. Christian Nelson

    I have another tip for kicking off the day right with a daily. Keep it high energy. It’s usually the first moment of the day where the whole team has one another’s attention. It’s a great opportunity for starting things off on a nice high note. Inject some energy into that short meeting and I find the team reflects it back through the day. There are lots of ways to do it, so find what makes sense for you. With some of our sillier/braver/outgoing clients, we’ve ended our dailies with some pretty amusing shenanigans.

  9. Hi Jared. Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time and de-focussed our colleagues). Because of this we developed a SaaS tool to ʺautomateʺ the daily standup meetings – with just a single email. If you like to take a look: http://www.30secondsmail.com. Best, Revino

  10. Size Of Longchamp Medium Le Pliage

    I’m glad to be 1 of many visitors on this outstanding web internet site (:, thankyou for putting up.
    Size Of Longchamp Medium Le Pliage http://www.estimation-immobiliere.fr/immobilier3773/

Your feedback