1. 24

How do you get the most out of daily standups?

When there are ~10 people doing different things telling what they did yesterday and what are they working on today, it feels sometimes a bit useless.

Limiting the time per person does help on that it does not take too long, but the informational value might not be worth it. Maybe just sharing this info between 2-3 people teams would be wisest.

Do you have any tips or experiences to share on this subject? How and when do you do your standup meetings?

  1.  

  2. 26

    I’ve never been part of a standup that hasn’t devolved into “make yesterday sound productive” competitions/drivels. I think there are a few causes:

    • Stakeholders are present so engineers are vouching for their team
    • Managers are present so engineers are vouching for their raises
    • Engineers are afraid to look lazy when compared to their peers

    So, to make standups more productive I’d remove Stakeholders, Managers, and Engineers from the meeting.

    😉

    Edit: I was being playful, but I don’t think standups are useful meetings… at all. The idea that you should wait until the next day to bring up that you’re blocked seems ridiculous to me. However, if I were to run them this would be the format.

    • What are you doing today?
    • Is anything blocking you?

    Note how there’s no “what did you do yesterday?” Talking about yesterday would be strictly forbidden. Not only does it run a high risk of turning into drivel, but everyone already attended yesterdays standup, so it’s purely redundant information.

    1. 5

      everyone already attended yesterdays standup, so it’s purely redundant information.

      That very much depends on team context. I’ve worked on teams where that is mostly (though not always) true. And I’ve worked on teams where what people said they were going to do ended up varying dramatically from what they actually ended up doing.

      During peak season for one of my company’s sub-products, the development team supporting that product is very likely to be pulled into debugging production issues. Occasionally a team member’s expertise is urgently needed by another team. And of course, if you say more than one thing in your list of intentions, if anything takes longer than expected, then the rest of your intended actions may or may not relate.

      It’s important not only to communicate what it is that you are trying to do, but also what you actually ended up doing so that if the source of change is a problem somehow, that problem can be addressed.

      1. 2

        Where does it say you have to wait until next standup to bring up blockers? The ‘What did you do yesterday, today, and what are your blockers’ is just a training exercise to get novices trained to bring up blockers daily. It’s to get people into a habit if bringing them up every day. Believe it or not, some people will struggle for weeks with blockers until they bring them up, or quietly fail. This is especially true for newer people in the field.

      2. 17

        Standups should not

        • Try to resolve an issue live
          Don’t try to trouble shoot something or hash out details in a standup. Use the standup to report it, then grab someone after the meeting. Otherwise you are wasting everyone time. This one drives me nuts as it seems to happen in my stand ups all the time.

        • Include a measure of how productive you are.
          If you need that measure there are burn downs. Also its generally a good idea to not include any unnecessary management, as that does tend things to devolve into ‘make yesterday sound productive’ as @pab said.

        • Be longer than 1 minute per person.
          You want to report your current position, and where you are going. If it takes you more than 60 seconds to report this you are probably running into the prior two bullet points.

        • Be longer than 10 minutes in total.
          You don’t want to give time for devs to glaze over. If its taking longer either brevity is suffering from loquacious individuals, or the team may be getting too big.

        • Happen prior to caffeination, lunch adjacent (unless team eats together), or near EOD
          Stands ups should facilitate follow up communication between members. You want people be alert enough to help, but during a time where they wanting to wrap something because they have something else to do at that time.

        1. 2

          Yup. I think you hit the nail on the head. I did stand ups years ago as project lead. First 5-10 mins of work: 1) what are you doing 2) any foreseeable pain points, connect with your peers that your tasks need you to coordinate on.

          Done. Everyone thought they were extremely productive (to my knowledge).

          1. 2

            Some tools that we use to achieve these goals:

            • It is always OK and preferable for someone to say “can we / you continue this discussion after the daily?”. Not everything that is currently interesting and relevant you is that to everyone. It is very easy to forget this when you get excited!

            • Keep everything short: It is OK if there is nothing peculiar happening or you don’t need input/help!

            • Always briefly go through every task which has been worked on since last daily. From end of the process pipeline to the beginning (in our current case: task moved to production -> tasks moved to ready -> tasks moved to review -> tasks moved to in progress -> stories taken to in progress -> stories groomed to backlog). There is couple reasons for this “backwards” order. First it gives personal productivity measure (I deployed/did stuff that needs review/etc). Secondly it creates natural pull for people to review and take new tasks/stories to be worked on, which removes insane amount of that fruitless “is this the next thing, or this, or this” kind of conversation. Having physical kanban wall makes this really easy by the way.

            • First couple items in the tip of the backlog are in strict priority order, so when previous story is done one just needs to take next one to be worked on. No need to converse about this during daily.

            • Pick a time when daily starts. Be very strict about this. Making others to wait is rude, no one is that important.

            Currently our team is 16 people, our dailies take 5 to 15 minutes. Depending on how much churn there has been.

            1. 0

              FYI The first known recorded standup from the highly productive Borland Quattro pro team was an hour long. Standups should be mini planner meetings, not status meetings.

            2. 7

              … by not attending them, and spending that time on writing code instead.

              1. 6

                I suggest each person answer as briefly as possible the following questions:

                1. Where am I?
                2. Where do I want to be?
                3. What’s the next think to do to get me there?
                1. 5

                  The first thing I’d say is that 10 people in a standup is way too many. I like to sit around 5 or less. Actually 10 people in an engineering squad is probably too many, and the group should probably be split in two at least, but how feasible that is is something I don’t know for your case.

                  I also like to not just focus on what we did/are doing but also how we’re blocked. Identifying blockers to solve “offline” is one of the great benefits of a daily standup. So each person, within 2 minutes or so, should outline what they did yesterday, what they’re doing today, and how they’re blocked for the future.

                  Beyond that, for generalities, I love this article.

                  1. 5

                    We switched from going round each person to going round each ticket (those in progress, in code review, blocked, QA). It cut down on time wasted justifying the day before or talking about finished work. If something major happened yesterday that needs to be raised it will naturally come up but no one’s waiting their turn trying to think of what to say to sound busy. It tends to be 5 or so minutes on the tickets, a couple on the overall progress of the sprint goals, and feels pretty useful. I don’t know if it’s capital A Agile. Edit: 4 engineers, 1-3 managers depending on who’s interested.

                    1. 4

                      Make the weekly! We do standups every Monday and have a slack channel where you post what you’re working on that day.

                      1. 4

                        I’ve found my current “stand-up” status update to be much better now that I have become remote. We always go in the same order, and I can put myself on mute, make some coffee, ignore everyone, and listen for my name. Unmute, speak for 20 seconds, and I’m done. I’m quite confident no-one on my team could repeat back what I just said, just as I have no idea what their update was. Sometimes it’s kind of nice to zone out for 15-20 minutes in that way - unless we’re hit with the occasional reminder to work both faster and better.

                        Obviously it’s largely a waste of time, for most of the people on my team, and incredibly inefficient. but the meeting is for my manager. Now that the manager is mostly too busy to come I’m not sure who it’s for, but doubtless the charade will continue.

                        1. 4

                          After twenty years of working as a developer, I’ve come to the conclusion that daily standups and other rituals do not exist for the benefit of developers. Furthermore, I have never been to a meeting that could not have been replaced by a brief email exchange.

                          1. 3

                            When there are ~10 people doing different things telling what they did yesterday and what are they working on today

                            Is the problem that you are trying to pretend that the ten people doing different things are a team, or that the ten different tasks dished out in planning represent a team goal?

                            1. 1

                              This is very succinct and I suspect goes to the true heart of the problem.

                            2. 3

                              I do not.

                              1. 3

                                I get out of most daily standups by standing up and walking away.

                                1. 2

                                  At my previous job, we only used a few seconds, each. Move tasks into doing/done/blocked, and maybe say something about it. Any discussion was deferred to after standup, and those interested could stick around. We were usually around 8 people, and it would take maybe 5 minutes.

                                  1. 2

                                    I think it helps immensely if the person leading the startup takes an interest in understanding what each person is working on, and asks good questions.

                                    An example:

                                    • Programmer1 - “Still working on foobar… sigh”
                                    • Leader - “Hey, I remember you were stuck on baz, did you get the help you needed on that?”
                                    • Programmer1 - “That wasn’t too bad actually, now I have a problem with xyz actually.”
                                    • Leader - “I remember Programmer2 was working on xyz on Monday.”
                                    • Programmer2 - “Oh yeah, maybe I can help with that, lets talk after standup”

                                    I think some enthusiasm from the leader can break the monotony of the standup and get some more useful info out. The caveat is that it requires some charisma on the part of the leader. Which if you don’t have, basically anything can be boring and useless.

                                    1. 2

                                      I despise daily standups as they’re done in most settings. Having a meeting where ~10 people go around a room and give a status update is a waste of time. If it’s just a status meeting, then you can disseminate those updates via email / chat.

                                      I do find daily, unstructured check-ins with fellow project members useful. It’s just a simple conversation between humans, not a sacred ritual at the altar of Agile.

                                      1. 2

                                        The best part of my current day job’s policy is that meetings are not obligatory. I make the most of my daily standups by not attending. I’m not concerned about taking 10 minutes to discuss something in the morning. It’s the fact that we’re holding a synchronised ritual with zero value in what should be a distributed and asynchronous team that plays on my mind and frustrates me to no end right at the beginning of my working day.

                                        Last year we didn’t have project managers — we were self managed. We had a strong culture of documentation. Everyone on the team had a habit of writing papers to articulate their thoughts, and tasks were thoroughly annotated in Trello with both technical and business context.

                                        Now we bring in a project manager (because that’s just what you’re meant to do, right?), and the first reflex for every instance of dialogue (or indeed, monologue!) is a synchronous meeting. Documentation quality (and I don’t mean code library documentation) has plummeted.

                                        When I inevitably run a tech team full time, there will be no ritual standups, and there will be no project managers. And there sure as hell won’t be any “Agile Coaches”. You’re all banned.

                                        1. 2

                                          Don’t have them. If you must, have a small medicine ball or something with a little bit of weight that people hold in front of them in order to talk. If you’re already thinking how unfair that is because people who are physically stronger can talk longer, you’ve already begun to overthink it.

                                          1. 2

                                            It’s Not Just Standing Up: Patterns for Daily Standup Meetings was a guest by Jason Yip on Martin Fowler’s blog about this very topic.

                                            I find “Walk the Wall” combined with “Rotate the Facilitator” to work well. The team should own the standup. Which means, if no one finds it valuable, then don’t do it.

                                            1. 2

                                              I left a whiny comment below, which didn’t try to answer your question at all. Hopefully I can contribute something, though there are some very insightful comments here already.

                                              I think the widespread adoption of team chat has largely obviated the need for the traditional everyone-in-a-circle morning stand-up, which (as others have noted) tends to turn into status updates and “make yesterday sound productive” (per @pab). I think status updates are overly derided, though, and that it’s okay for these meetings to be for the benefit of the manager or other parties. If your manager takes 10-15 minutes of your time every day for their own productivity then that’s their prerogative and that’s fine. Sure, it’s not what stand-up is “supposed to be”, but that doesn’t mean they’re entirely useless. It’s not about you - get over it.

                                              Of course, status updates can be achieved over chat or email as easily, or in the traditional way by the interested party asking you directly.

                                              So that’s where everyone needs to be honest about who the meeting is really for, and what it’s achieving. If your manager wants status updates, figure out an efficient and not-disruptive way to do status updates. If the manager is using stand-up as a way to get people into the office (this has happened to me) then you should really be talking about office hours, and what’s expected of the team in terms of attendance. If the manager swears the meeting is for the team, and the team doesn’t want the meeting, then it should probably be canceled. There’s no point doing the ritual if no-one is getting anything from it.

                                              1. [Comment removed by author]

                                                1. 3

                                                  Five minutes per person!! That sounds interminable. One minute per person, including (short!!) clarifying questions from other members, seems like a much more reasonable limit. Standups are strictly for orientation; any meaningful or deeper conversation should occur elsewhere.

                                                  edit: I see I agree with jpatrick, basically.

                                                  1. -1

                                                    The goal is to let people know you are working on things and the kind of things you are working on

                                                    The goal is to replan the sprint. It is a mini planner.

                                                    See “Daily Scrum” in http://www.scrumbook.org/

                                                  2. 1

                                                    I give my answer as succinctly as possible primarily focusing on questions I might have for my teammates and how my work may impact another’s. When someone is going into too much detail I propose making a meeting about it where it only has the people involved in that discussion.

                                                    1. 1

                                                      I am somewhat successfully using them at my current work.

                                                      We are a small team though, we’re 5 in my team, and ideally we like to finish it in >10 minutes - two minutes per person, one minute for what you did yesterday and one minute for what you’re going to do today and if you can see any challenges.

                                                      The one minute for yesterday is a small retrospective, to try to reflect on whether what was said yesterday was somewhat correct, in the sense, was the prediction of what was going to be hard correct or not?

                                                      I think there’s some value in it, but it’s nothing that wasn’t already available by a short daily status meeting prior to SCRUMification.

                                                      1. 1

                                                        We used to do “What I did -> What am I doing”-standups, and they generally meant each person spent 2-5 minutes explaining their current task, issues and who it related to. In the end, people could only vaguely remember what other team members were doing, save for those they were directly collaborating with.

                                                        We recently have been doing something different:

                                                        1. Tell us if you are experiencing any troubles (just raise the flag, no live troubleshooting).
                                                        2. Tell us if you are blocking anyone or are being blocked by anyone (and resolve it after).
                                                        3. Tell us if you think you will make your sprint or whether some tasks will have to be pushed.

                                                        Our sprints are two weeks long and we have a concrete sprint task planning at the start, a loose “what is coming next sprint”-meeting (1 hour max) in the middle of the sprint and a retrospective at the end (3 notes per member, usually they group together and we talk about 1-3 major points). All in all I think we are fairly productive and everyone is on track most of the time. You still have to deal with under-specified tasks, over/under-estimating task time and such, but I should think those cannot really be avoided ;)

                                                        1. 1

                                                          At my previous company, people were encouraged to write weekly snippets representing what they did. I found this pretty useful to know about what people were working on (I also used it to promote a political agenda by plotting my review latency histograms, encouraging people to review things faster). This was also essential when you had to do annual performance reviews, as you could look back to a yearly summary of what you had done.

                                                          At my current company, we use a slack bot to do daily “what did you do / what are you going to do” standups. It’s nice, but I miss the yearly roll-up view and the weekly frequency – you had more leeway to put in more information, like histograms or longer explanations of things.

                                                          1. 1

                                                            I think standups are all doomed to devolve into misery without an incredibly strong and dedicated hand leading and cutting people off. That would be step 1 for me: find someone who is willing to say “No, you’re standing up so you are as uncomfortable as we are… No your time is up…”

                                                            I only find the first two or three sentences of what anyone is doing to be useful. The other thing that is useful is to know what problem anyone is wrestling with at the time in case someone knows how to help.

                                                            If I was running my Iron Fist standups, I think I could get it down to 30s per person ;)

                                                            1. 0

                                                              Don’t treat them like a status meeting. They are meant to be a mini sprint planner. They are for replanning the sprint daily. See “Daily Scrum” in http://www.scrumbook.org/

                                                              1. 1

                                                                How do you “replan the sprint” without understanding the status of open tasks?

                                                                Basically, your current status is the input to replanning—are you done with that task that was planned to take 3 days after only 1 day? Better pull something else into the sprint!

                                                                1. 0

                                                                  You are correct that status is important for planning. I agree and didn’t say status isn’t involved, or isn’t important, just pointing out it isn’t the goal of the meeting. As I said, they are not status meetings but planning meetings.