1. 39
  1. 42

    I don’t see daily standups being a big deal either way (having or not having them), but it’s hard for me to look past the acidic tone lacing pretty much the whole article. Even if a good point is made in there somewhere, it would be obscured by the corrosive spray. In fact, I’d pass on an opportunity at a workplace where this level of negativity was the norm.

    1. 26

      Standups don’t have to be synchronous. I’ve been on distributed teams that worked very effectively by posting their daily status in a chat room.

      1. 8

        At a previous company, we’d do async standups (in chat) some days and sync standups (video cal) other days. I always preferred the async standups since they were more in-depth. Yes, I can look at Jira and tell you’re working on “the widget”, which is what they’d say in person for time constraints. But in chat, they can include links to code or docs that they’re struggling with. Or I can respond with links to code or docs to help out.

        And 7 hours later in the day, I can go back and consult the chat if I found something relevant in my own work.

      2. 24

        I suppose I’m not an expert but never, in all my years, have I had a daily stand-up that helped in any way. I think it might have to do with the fact that I’ve always worked on fairly small teams (the largest was perhaps seven people), so if we needed something, we just communicated directly.

        Now, more in-depth weekly meetings for code review, whatever? Yep. Those can be useful (though they have often, in my experience, devolved into simply reading the bug tracker/project board).

        1. 5

          I’m curious what a code-review meeting is like, or what you mean by that. I’ve always done code review as one-on-one (or maybe 2 reviewers), and asynchronously. In a code-review meeting, are you basically trying to let people know about recent changes, as opposed to getting feedback on a patch before merging?

          1. 5

            Well again, this may be a function of team size, but…

            The meetings I had in mind when I wrote that were specifically for weekly-update-type situations. Specifically for what, for lack of a better term, would be called “detection logic updates.” I’ve spent most of my career working on security-related products across multiple companies, and each company has had weekly releases of new detection logic (of various kinds for the various companies).

            These pieces of logic are generally pretty small (the biggest are perhaps 50-100 LoC) and the consequences of failure high (false positives in security monitoring systems or even blocking of legitimate traffic that takes down upstream services), so they tend to get reviewed in toto by the entire team. Each team member brings forward their stuff for the week, we all look at it, explain what could go wrong, and so on.

            I’ve always liked this approach for numerous reasons: it catches many problems before they go out, and it removes blame from individuals. If a bad piece of logic goes out, well, the team as a whole should’ve caught it. (Thankfully those were rare, but man I have some stories.)

            For bigger pieces of code (i.e. what most other people would just call “code”), those have always been one-on-one type situations done “when it’s time”.

            But yeah, for the past fifteen years or so of my life, across three or four different companies, I’ve had a weekly meeting called “sigreview” doing essentially the same thing. Sometimes I’m the person who wrote the sigs, other times I’m the person who wrote the engine the signatures run on, other times I was the person who wrote the compiler between the two…but regardless, I’ve been doing these meetings for a long, long time and I realize it’s probably skewed my idea of what code-review meetings should be like.

        2. 11

          I rather like daily stand-up, because I get to brag about what I accomplished yesterday. It’s also usually the only time I interact with teammates from the QA, frontend dev, and UX.

          I do think I’m the lone extrovert on my team, perhaps that’s why I like the stand-up meetings?

          1. 12

            I rather like daily stand-up, because I get to brag about what I accomplished yesterday

            I used to feel this way too, but eventually I realized it was a pretty serious anti-pattern. If you feel like you need to spend a bunch of your co-workers’ time just to prove that you haven’t been wasting the past day then it’s probably indicative of deeper-seated trust problems.

            It’s also usually the only time I interact with teammates from the QA, frontend dev, and UX.

            This problem on the other hand, I’m more sympathetic to. But you can still schedule social meetings just to catch up with your team; if your team culture makes you feel like every meeting has to be productive all the time, I guess that’s another red flag.

            1. 7

              If it helps any, our stand-ups are always less than ten minutes long, but I see your point. I’ll think about it more.

              1. 3

                If you feel like you need to spend a bunch of your co-workers’ time just to prove that you haven’t been wasting the past day then it’s probably indicative of deeper-seated trust problems.

                Isn’t it typical for managers to distrust individual contributors like this? I constantly had to justify why I was employed ever since I left the incubator, with employers ranging from startups to dinosaurs. This is likely SRE-specific, as the pressure was at its least when I was on an all-SRE team, which suggests that the problem is ultimately due to misaligned incentives. Specifically, product managers want services to churn their features, while SREs want services to stabilize.

                1. 2

                  Yeah, it is typical, and at the same time a huge red flag and and antipattern. Funny how often those things go hand-in-hand in tech companies.

                2. 2

                  Not quite the bragging or justifying my existence to co-workers, but the one thing I liked about the weekly status meetings that we had on a previous project was that it made me realise that I actually had achieved something that week. We had them on a Wednesday evening and I’d often feel like I’d wasted a week by the end of Tuesday, then spend half an hour on Wednesday afternoon writing down the things I’d done that week for the status meeting and realise that I’d actually done a lot of useful things.

                  I don’t know how common this is but having something that forced me to objectively look at what I’d done over a week was a really useful psychological boost and helped a lot to help counter imposter syndrome.

                3. 6

                  I’m in between being an extrovert and introvert, and I think stand ups are important. Especially on a distributed team, there are potentially very few chances to get face time with your colleagues. No, your engineers won’t necessarily by default interact with each other. Yes, you should consider other formats besides yesterday/today/blockers.

                4. 6

                  I’m not surprised anyone finds standups useless if their experience matches that of the author.

                  There are two separate issues addressed though: everyone-in-different-time zones and standup-by-numbers.

                  When I used to work entirely asynchronous you, across time zones, we talked via IRC and it was asynchronous. There was no standup. I don’t know what the purpose would have been if we did.

                  When I was a lead developer and everyone worked in the same office, I also got to be ‘scrum master’, and we had standups.

                  They were at the earliest time everyone was actually in the office. We all gathered around a whiteboard and we had a look at our situation.

                  The day previously, I’d been walking up to the board every few minutes and making adjustments.

                  I’d be thinking about whether we should be doing everything that was on the board, if everything in the ‘incoming’ list was heading for being in good shape to even start looking at, moving tickets up in priority where there was a security risk and no-one else was giving it enough priority…

                  When everyone arrived to discuss, I first checked if everyone was okay. This where someone might say they might have to leave early if their child is sent home from school as they might be sick, or that they will be on a virtual course all morning, etc. This was the sort of thing the rest of the team needed to know - and to hear right then, when their attention was focused, so they would be able to plan getting their changes tested - perhaps borrowing a QA from another team, or asking a developer a deep technical question they had assumed they would be able to.

                  I caught them up with any news I might have received and they might not have, such as that Id spotted a message from operations that they were going to reboot some build servers at X o’clock, or that the new license keys for FooSoft had been approved and promised today so maybe get it installed and updated in preparation.

                  I’d then ask if anyone needed any help or had any other news that others might benefit from.

                  A developer might say they couldn’t figure out how to do something in a legacy system that they’d had to get running as it had suddenly been flagged as out of policy on something. Someone would volunteer to come and look at it with them - often me.

                  A QA might say they were finding that they were getting issues testing in Firefox at the moment and if people saw similar then they should downgrade to the previous version for now as that worked around the problem.

                  We tried to keep these meetings to five minutes. If anything showed signs of needing more attention, we made a note and addressed it outside the meeting.

                  My humble opinion is that the above is a good use of five minutes as it helps people avoid bumps in their day, humanises everyone (we have lives outside work and we need help with things) and builds team spirit.

                  Just one more thing: Teams can change rapidly and new members would feel comfortable much more quickly when they got offers to be shown around something or helped when stuck.

                  1. 1

                    This is what I’ve done for standup, both remote and not, and I’ve always found it to be a good use of time. The standups varied between five minutes and twenty minutes, but most of the time when we got past five it was more socializing than standup and people that didn’t want to chitchat had gone back to their work. Folks would also miss standup if they were heads down or just doing something else in their life. In depth discussions were usually relegated to standup-adjacent conversations.

                  2. 6

                    The biggest practical issue is when the “5 minute standup” balloons to 30 minutes, an hour, or even more. This was an issue at pretty much every place I worked at, until I moved to New Zealand when our standups were at midnight or 1am my local time, and I felt fairly confident and justified to just cut people off if they were talking for more than a minute.

                    It’s always the same people who will go on about all sorts of details no one cares about in a standup while all they need to say “I worked on improving the performance of the frobblybob” or “I’m having trouble improving the performance of the frobblybob, can anyone help me out?”, “sure, I worked on it before”, “Great, let’s discuss later, or something along those lines.

                    But most of the time, I don’t think it really matters and haven’t really seen any value from them. Especially in a “GitHub-like” workflow where everyone opens draft/WIP PRs fairly quickly you tend to have a good idea what people are roughly working on. The biggest advantage is people who are too shy to ask for help unless it’s in a standup, but that can probably be solved in other better ways.

                    1. 4

                      Stand-up meetings don’t always have to be about the classic three questions (“What did I do yesterday? What do I plan to do today? Do I have blockers?”). Instead they can be about the team looking at the current iteration and potentially shifting resources to achieve a set goal.

                      That being said I agree that these meetings don’t have to be synchronous. And that you shouldn’t wait for a set time to announce that you are blocked by something.

                      1. 9

                        Instead they can be about the team looking at the current iteration and potentially shifting resources to achieve a set goal.

                        You don’t need to talk about that every day, and when you do talk about it, you should do so for longer than a stand up meeting.

                      2. 3

                        Due to COVID my team’s standup has gone from a daily meeting to just an optional Slack bot thread for updates / blockers. Engineers are smart and know how to get unblocked, they’ll just reach out directly to the person or team.

                        However, the meeting is still on the schedule and it’s naturally become a time to hang out and chat, completely optional. It’s accidentally become a great regular social time for people to check in, and it regularly goes past the 15 minute mark if the conversation is good.

                        1. 3

                          I actually really appreciated the standups at my last job, which was fully remote, with co-workers spread across the United States. A 15-30 minute standup was a welcome break from communcating in Slack. It helped that we broke it up into two parts: status and discussion points, and people were free to leave if they weren’t intertested in or weren’t needed for the discussion points.

                          Personally, I think the hate towards standups is kinda funny, given some of the other common complaints people have. On one hand people complain about open offices because of all the distractions, but then at the same time standups are hated because, “If I’m blocked I’ll just go talk to the person”. And then there’s the “I’m only truly productive 2 or 3 hours a day” people and the ones hanging outat the kegerator from 3:30-5 most afternoons but a 15-30 minute meeting is a big waste of their time.

                          In any case, retro is a great time to bring up procedural problems like consistently going over time or straying off topic.

                          1. 2

                            Standups are a tool to make tactical decisions between team members working on the same set of tasks, where one’s progress might depend on someone else’s. Unless you have this precise situation happening, nothing can be gained by having standup meetings.

                            Frankly, based on my experience, this post feels like a knee jerk reaction against the agile fad but while it correctly identifies that there is a lot of superficiality around those topics, just being a contrarian doesn’t really make you any better.

                            I wrote about standups a while ago: https://kristoff.it/blog/good-bad-ugly-standup/

                            1. 2

                              A good way to think of standups is that they are a replacement for meeting culture. If you’re already doing a lot of meetings, then you’re doing the work of standups, only in a more rigid and inefficient manner. I find that teams that do them without understanding why they’re doing them rarely do them very well.

                              1. 2

                                I propose end of sprint standup. During a sprint let the people connect on need basis.

                                1. 2

                                  The overly derisive tone of this essay is enough to ward me away from ever wanting to work with the person.

                                  That being said, I think there’s some validity to the argument. However, stand-ups may still be a reliable tool for teams who aren’t completely comprised of excellent performers - some less fortunate teams have to find ways to deal with mediocrity and stand-ups can help in that respect, I think.

                                  1. 2

                                    Why We Don’t $THING at $STARTUP

                                    1. 1

                                      IMO forced meetings are harmful. You are pressed to find something useful to talk about in order to avoid making the meeting a loss of time. Turns out having to find useful things, you only end up with sub-par items. And for actual useful items, you end up waiting a day at which point you either forget some of it or are not enthusiastic about it anymore and this is multiplied with the number of participants. So unless the meeting coincides with the issue, it ends up harming more than helping.

                                      The more useful way of doing things is to complain about your blockers soon after trying your best. It doesn’t matter if it is caused by your lack of skills or competence or just bureaucracy. And declare your tasks as complete as soon as you are ready and comfortable.