I think if your standup can be async, then it's ineffective, and you should get rid of it. And to be clear, that's fine! Not every team needs standups.<p>The only value in a standup is when team members actually share ideas about what they're working on. The detailed conversation happens outside the standup, but the purpose of the standup is just to get that moment of "I know about that, let's talk".<p>In that case, having everyone in a room (real or virtual) at the same time is more efficient than asynchronous updates. With asynchronous updates, people are in meetings, in the bathroom, not online yet, etc, and you have higher coordination costs.<p>I've been on teams that have effective standups, and teams that have worthless ones. I know what each one looks like. But for the life of me, what I can't figure out is why some teams have good ones, and some don't.
In my experience, async standups mean everyone posts their status and does not read any other status.<p>Counterpoint: In my experience, at synchronous standups, people totally ignore everyone until its their time to speak, and then share an update, and then go back to not listening.
Standups as status-updates is an awful antipattern that turns so many people off agile - and specifically Scrum.<p>Standups where each person takes their turn and recites the mantra: 'Yesterday, worked on ticket HN-1234. Today, I'll still be working on it. No blockers.' Sure - if that's all you do, do it asynchronously. Please. Preferably by just updating the Jira ticket, not posting it in Slack. Or... just, don't, because apparently this has <i>no impact on what you do</i>.<p>If all that happens in the standup is everyone shares what they did yesterday, what they're going to do today, and what's blocking them, then... then what? We shared a bunch of information across the team. What are we going to <i>do</i> about it? Is Dave going to change his plan for the day to instead help unblock Karen? Is Peter, now he has heard what Rachel did yesterday, going to do anything different than he just said he was going to do?<p>Daily standups are best when they are really daily <i>replanning</i> meetings. As a team - look at the goal for the sprint. Is it still the right goal? Are we going to get it done? Did anyone do anything that gets us closer yesterday? Does the plan for what we do today still seem like the right thing to do to get us there? Is anything interfering with our chances of getting there?<p>Everyone leaves knowing what everyone else on the team plans to do to move things forward today.
In my opinion, standups are useless - asynchronous or not.<p>Waiting until the next standup to resolve blockers is clearly not efficient.<p>What I've observed during standups is mostly people staring at the void waiting their turn and a few obnoxious nerds trying to bullshit their way up the hierarchy by talking way too much for their own good.<p>The best communication I've seen was during brainstorm meetings.
The whole purpose of daily standups is to be short, to the point, and force developers to discuss blockers.<p>That can't be async, because I need the other members of the team to answer.<p>The issue the author is addressing is that for some, this is wasted time. But a) that's why these meetings are short, thus the standing up part, and b) Usually it isn't but an opportunity for more seniors to chime in with suggestions.<p>Plus, stop with the "here's why" in your titles. I know you're going to tell me what you think, but that doesn't mean that you know THE TRUTH ABOUT WHY something important should be the way you think.
It's true that most daily standups revolve around "The Three Questions," but that's not the point of stand-ups. The point is, every day the team has a forum where it can potentially change course. It's an opportunity to identify whether my plan for the next 24 hours is still valid, in a similar way to how sprint planning lets the team change course for the next 2 weeks. It doesn't solve blockers, true, but it does allow triaging blockers, and helps to ensure that if someone is blocked you don't have no one jumping in to help (or everyone jumping in to help, which is also disruptive).<p>Most teams I've been on with ineffective standups are usually a group of engineers working on independent work streams, who if they had to help each other wouldn't know how. The teams that have effective standups have a clear team goal, and engineers are willing to stop what they're working on in order to ensure that the most important work is getting finished.
Our team does our stand-ups in Slack, in a separate channel called "#daily-status".<p>Every morning, each team member posts a short bullet list of the items they are planning on working on that day, along with details about any things they are blocked by. This happens asynchronously as people start working every day, so one person might post their message at 7 am, while another person posts at 10 am.<p>Any conversation that needs to happen about someone's daily status message happens in a thread under their message. This gives the team and management an easy way to see what each other's intentions are for the day, without a bunch of distractions or bullshit meetings or people's eyes glazing over while someone goes on a side tangent rant for 10 minutes. Instead, the information is quick and to the point.<p>It's also very common for people to post a summary message at the end of the day to let everyone know what they actually got done (or didn't get done).<p>Our whole team is remote, and this method seems to work really well for us.
At my last remote job we had stand-up twice a week. It was a small team and we rarely had a reason to care what anyone else was working on. We didn't need stand-up at all.<p>At my current remote job we have DSU, but the format is simplified. Nobody has to say what they're working on because that's info you can lookup yourself on the JIRA board. The team lead/PM shares any important company info if applicable (usually 2 minutes long) then anyone that has blocking issues is free to speak up if they need help. That's it.<p>Sometimes we go over by 15 minutes or so if someone raises something complex. As the author pointed out this can lead to people not listening, but for me personally that is a good thing. It gives me time to catch up on daily news or disengage from my work for a little bit. It's even better that my DSU starts first thing in the morning, so I get to use that time to let my brain slowly warm-up and get ready for real productive work.
Working intensively remote during this pandemic, we rediscovered an old practice of ours we call "comm-work". Basically we share screens (on Zoom) while talking about whatever is going on at work. It's sorta of a "open-space" equivalent but online and with a mute button.<p>Comm-work is more about showing than telling. A screen is always shared (or a whiteboard). We share emails on screen and sometimes write them together, we hear in into a customer call (like through Teams whilst we remain connected through Zoom), or we just tune out into our thing. It's an impromptu that can last anywhere from 20 to 90 minutes.<p>It's not scheduled, it's not a standup, you don't have to report status (yuck!) or say anything. Just keep working if you feel like it. You can mute yourself or others. Most of our teammates (not all teams are the same) feel like sharing something, be it a milestone, a cool widget they found or a piece of code they feel are blocking. This works great because it just naturally surfaces issues <i>before</i> they are issues.<p>The bad part, if anything, is that it is run by a manager who knows how to improvise, when to call one up (and call it off if someone has to take their kid to the doctor) or how to dig into the team's mind and create the meeting narrative. It also requires some degree of direct speak ("Hey you, whats up with that task?") which also does not work with every ego around. So this is not something that I think can be taught at seminars as it's not very scientific. It's just natural and basically arises whenever a chat room becomes to chatty. I personally believe comm-work is deeply more effective than any agile standup or kanban, which never ever worked for us. Being such an improv keeps people on their feet. They never know when the team is going to meet, what the next customer email will say. Your code editor becomes not so much of a secret place. I know it sounds almighty corny, but screen sharing is the ultimate sharing at a workplace.
My team has been testing out a hybrid of the two-- we use a slackbot to gather our answers to the three questions before standup begins. Then we use the meeting time to discuss anything that might have come up as a result of the slack posts.<p>We've really liked it so far. It cuts out a lot of the bad parts of synchronous standup like trying to remember what you did yesterday on the spot, but still leaves us with the opportunity to share ideas in depth when it makes sense.<p>I think completely going to an async standup right now wouldn't be good at all for our team dynamic. With the whole team remote, standup is the one time a day we're all on a call together. There's a lot of value that comes out of that even if it's inefficient at times.
When I was doing daily standups it could be useful for people to say what they are blocked on and then for someone else to say that they could try to help them. Where it wasn't useful was if the two people tried to solve the issue during the standup while 10 other people were standing around.<p>My other pet peeve for our standups was that they would not start on time. This was very common when I started on the team. After awhile I would just force the standup to start on time no matter how many people were there, even if I was the only one there :) After awhile everyone started getting there on time. I understood why people would arrive late since we were always starting late. An unvirtuous cycle so to speak.
You know who likes standups?<p>Program managers, project managers, and useless middle-managers. What do they have in common? They get to exercise power and justify their existence through calling extra meetings like new project-specific standups.<p>Who hates standups? Everyone else, basically.<p>Really makes you think..
I have come to believe that Agile is a hoax and Scrum too is a hoax. Standup meeting is a bigger hoax. Anyways, long before I understood this I wrote about why the hoaxes should happen towards the end of the day. <a href="http://www.rahul.ws/on-daily-meetings.html" rel="nofollow">http://www.rahul.ws/on-daily-meetings.html</a>
I have yet to be in a standup where I felt safe admitting I was blocked.<p>The manager and project manager are there to glare at anyone who isn't "maintaining velocity".
I think that relatively often part of the real motivation for standups is to put people on the spot a little bit to create pressure and/or accountability.<p>You can ask whether that's a good thing or true to the original vision, but if that's part of what someone aims to get out of standups, then that probably requires them to be face-to-face.<p>I'm not a big fan of seeing negative emotions (shame, guilt, fear, envy) used to motivate employees (especially if it's the only thing in a manager's bag of tricks) but in small doses it can be OK. So maybe it's not ridiculous if part of the value of the standup is the threat of feeling like an ass if you have to say, "Sorry, I basically got nothing done since the last standup."
I totally agree with the idea that teams should remove blockers as they come up. If someone on my team runs into a blocker 10 minutes after the standup, I hope for everyone's sake that they don't wait until tomorrow's standup to say something, if only because being blocked for a whole day is not really what you'd call "morale boosting".<p>I'm not a huge fan of in-person standups, but if you're going to do them really make sure they're useful and efficient. I worked at a small startup once where the entire company (~12 people) did a daily standup, which meant listening to what the salespeople were doing every day, and then telling them which bugs I was fixing. Overall pretty useless.
s/Daily Standups/Status Reporting to Management/<p>Standups must rank in the top 10 most used cargo cult practices in the tech world.<p>Amazing to watch a good, collaborative idea that was used amongst people who actually like working together on something they sort of care about be distorted into some dystopian mandatory process that literally no one likes or gets value from.
I read a lot of comments say standups are for developers to discuss, for developers to raise blockers, etc.<p>In my experience, standups are not only for developers. In my current environment, there is always the product manager of the team who is usually updating us with the information he got from the upper levers of the company. There are also QA testers that discuss their progress. We keep it freakishly short. ~15mins for a team of 10.<p>While I do find my self looking at the void sometimes, other times I'm forcing my self to pay attention to everyone and to be as helpful as possible. What everyone does that, is what makes a team get it right.
I perfer async standup over slack.<p>- It makes it easier to parse information, reread, and catch things like hey 2 people are working on the same thing.<p>- Helps catch people stuck/avoiding work as you can see someone on the same task for 5 days, or rotating between 2 to 3 tasks when none are done.<p>In terms of discussions, questions or post standup followup, a thread tends to get started per checkin which could lead to a meeting. This also creates a good historical trail for when issues come up.<p>Though I am a huge slack fan, having a channel per project/epic and any conversation had or meeting gets summarized and put back into the chat
I like (<20min) sync standups for two reasons:<p>1: Social. By seeing my coworkers over video I remind myself that I work with people, not pull requests or comments. Perhaps more relevant these times.<p>2: Discovery. 2.1: A minute or two to just touch on overall goals can instill team spirit. Sales target hit? No angry customers? Perhaps a complaint. It helps with team alignment 2.2: A quick rundown on how each persons day is looking / what people are working on. Perhaps not for blocking but sometimes it is useful to connect two people and let them follow up post-meeting.
We use Cadence for Fly.io, mostly because standups are useless for us. We're small enough that we don't have external blockers, and we expect people without external blockers to just ... not get blocked.<p>We also don't really give two shits about status updates. We care more about what people have actually done, which is what we use Cadence for. Most of our updates are something like "pushed a draft PR for X purpose" and not "still working on the same thing <i>yawn</i>".
Slightly off-topic:<p>At my last office gig employing daily standups they quickly devolved into a thinly veiled attendance check combined with a passive aggressive attempt to shame unproductive team members on a daily basis.<p>It became just another reason for me to never come to the office. At the time I was in a very head-down overworking phase of life and the leadership would turn my participation at standup into a major component in that shaming tool, because I always had a disproportionate amount of things to discuss.
IME (both as an IC and as a Manager), daily standup is the tech worker equivalent of a time clock. Most developers won't be in office until 1 minute before the daily standup.
Alice: Yesterday I looked at ticket ABC123, to fix the database. I had some issue with the network so I'm following up with IT. Today I'll look at ticket XYZ385.<p>Bob: Yesterday I was working on the migration to the Kokomalta framework. I'll keep doing it today.<p>Charlie: Yesterday I looked at fixing the printing bugs. Today I'll do more bug fixing.<p>I've worked in different companies, industries, countries and it's always the same stupid thing, some sort of cargo cult practice that achieves absolutely nothing and wastes everyone's time. As a manager if I want to know the status of some project I ask the person, I don't wait until 10am the next day. And if someone is blocked, reach out when you're blocked to whoever can unblock you. That's it. That is actually agile, not that stupid daily ceremony.<p>The IT world is full of those dumb cargo cultish practices. One I've started noticing is to prefix everything with "as a user" when writing "stories and epics".
"As a user, when I click there I want to have a window with that input box and this text written here". Super useful! I know there's a proper way to do it ("as a senior compliance officer, I want a daily report about ABC"), but no one does it in practice.
The one thing that I like about daily "standups" (daily meetings rather) is to see my teammate's mug every morning for a brief moment, while taking my first sip of coffee, and that scintilla of a moment when we wish each other a good day, all smiling, as our heart fills with hope that today is gonna be that lovely day where we'll finally experience the <i>flow</i>, the apocryphal stream of uninterrupted productivity. That's what a perfect daily "standup" looks like to me. But sadly, someone always feels the need to tell us what they had to do yesterday in great details and what their plan is for today, as I nod mechanically and cluelessly zone out.<p>At some point I noticed that my teammates, including my manager, often are at least as clueless as me, especially when the verbiage becomes a bit too technical. I thought I'd do everyone a favor by simplifying things. So some time ago, shortly after the start of a sprint I tried a format that corresponds pretty much with what is generally understood from our little speeches, but said more directly: "well, I made some progress on that thing yesterday and I'll work a bit more on it today. That's about it." On the second standup of this, my manager asked that we have an impromptu demo that afternoon, which was really inconvenient, since instead of working on my branch, I now had to spend the morning preparing a presentation that he could understand. That's when I realized that daily standups aren't really designed to boost developers' productivity, but another tool that is easily misused by managers to give themselves the illusion of control.<p>Don't ask me what I think of scrum, it would rhyme.
Best standup process I ever had was just a slack channel called standups, and everyone just posted a couple sentences sometime during the morning: what they did yesterday, and what they plan to do today.<p>It was great because first of all there is a history everyone can look back on, which can save some unnecessary communication and coordination. But most importantly it avoids the dreaded sidetrack conversation that turns your standup into a 20 minute meeting.
This article is monumentally pointless. For one thing it ignores how unlikely it is that your team is actually going to read through everyone's async standup update. Remote standup zooms kinda suck, and certainly make it easy to not pay attention. But there is value in having the team come together, having an open line of communication about what work is getting done, and a forum for updates.
Our stand up is a daily thread in slack. Totally painless and useful. Very often they lead to better collaboration and cutting off duplicate work before it really starts. FWIW I work on a small team at a very large company. Possibly that’s the sweet spot for stand ups like this. As typically someone on our team will make someone else aware of work another team has done we can leverage.
If you're using Slack, the Scrum Police is a great way to organize async standups:
<a href="https://github.com/coveord/scrumpolice" rel="nofollow">https://github.com/coveord/scrumpolice</a><p>Because of the confinement my team has switched to async standups to account for our varied work hours (people on kid duty, etc)
> In an ideal world, daily stand-ups are meant to unblock problems and help teams ship product faster. In reality, there's actually no space in the standup to dive deeper into actual issues. The second you do, everyone else tunes you out, your standup drags on much longer than it needs to, and you're asked by your manager to "take it offline".<p>There is an ideal balance between fully async and going down a rabbit hole. A good standup will have feedback from others in the group, but it is important for everyone to know and respect time boundaries. One or two sentence interjections usually work great.<p>When you're giving updates as frequently as daily, a synchronous feedback loop is necessary for the information to be relevant. If I post in a slack channel that I am debugging issue X, and 2 hours later, someone posts that they dealt with X last week and has a solution for it, I've just wasted 2 hours of time.
> Having a regularly scheduled, synchronous meeting is incredibly disruptive<p>> In fact, the best teams actually unblock problems as they come up<p>Maybe I'm reading them wrong, but it seems to me like these two lines are in direct contradiction. Obviously if a problem is a "fire" then yeah, you want to solve it immediately.<p>But if the problem isn't urgent and can be worked around, why <i>disrupt</i> someone on your team? Overall I think the framework / pattern presented in this post doesn't take urgency or team experience into account -- in my experience, synchronous standups are great and useful for quick discussions of non-urgent blockers, especially when the team is more junior and could benefit from exposure and shared understanding.
This quote at the end sealed it for me:<p>> “It’s clear how even though all companies say they “do agile”, in fact most don’t; they just do random meetings while standing up, which produces bad results that I consider right-out offensive towards developers."
Stand ups mostly exist to remind you that you need to be present at work at an early time of day during a core part of the week. It's an efficient tactic of making sure people get their asses into chairs week in and week out.
We’re a team of 10 and we’ve also found that Cadence replaces our need for stand up meetings. In general, I’ve found that trusting my team to get their work done and unblock themselves has resulted in fewer synchronous meetings
I always think the argument that it should be used to resolve "blockers" is weird. As a professional, you need to be able to resolve "blockers" on your own -- you have to track down people and work with them, it's not always the PMs job. In all my years of experience if I was dealing with a "blocker", then either everyone involved already knew about it way ahead of the standup, or I didn't think the standup was a good way to resolve it.<p>So really the daily standup is about progress reports. Which is totally fine, but, yeah, async is just as effective.
One thing I always find frustrating about posts like this is that they identify a problem but make no attempt to help articulate a path to a solution.<p>It's reasonable to suggest standups and other meetings be async. What would be better is to take the time to design a proposed solution for solving the problem standups solve, even if it ends up being a messy or bad one.<p>That's a much more effective way to complain about a problem than simply spending words trying to convince people that something is bad.<p>Offer an alternative. Create debate. Put in the work to solve it.
I enjoy the daily stand up. Sometimes single digit minutes, sometimes it goes on for half an hour. It is the opportunity to sync with the team. Questions get asked, priorities may be revisited, any new concerns can be voiced, and we all leave with the shared knowledge of what we are all working on today and if there is room for us to help one another. The live aspect of it allows a check point where things can be pivoted live. "Oh, I missed your question in slack, let's talk about it right after this meeting."
Yes, I agree. We just post our stand up to a slack channel. I think it's worthwhile process. It doesn't take very much effort, and it keeps everyone loosely in the loop.
If what you call a 'daily standup' is a status meeting where each dev reports to the team lead/manager then sure it can be async and that would indeed be more practical.<p>But that's not what a 'daily standup' is supposed to be and the point is to get people together.<p>> <i>"It’s clear how even though all companies say they “do agile”, in fact most don’t"</i><p>Well, indeed. That's why everything is called a 'daily standup' these days.
Async stand ups arent stand ups.<p>I do a form of async stand up at work.<p>Its mostly progress tracking for my boss.<p>Never get any feedback. Never share any woth others. (Itried in the beginning)<p>The real time nature of a standup a d implied time pressure has all kinds of effects that cant be duplicated in a lole for like way.<p>Im not fully of the belief it cant be adequately substituted im just saying dont call it async standup. It just sounds like youve never used one.
For me the daily standup is a chance to be debriefed by the project manager so that they can convert my updates to actions in JIRA. It's what liberates me from having to personally interact with JIRA. In that sense the standup is worth its weight in gold no matter the format.
I’m of the opinion that the updates should be async but with the option to highlight an issue or blocker that justifies a meeting about that context.<p>It’s important to strike a workable balance between putting everyone to sleep and unblocking issues quickly.
Oh, that's just mean. "Your team is suck, here's why. How to improve it? I'll tell you somewhere later, don't know when exactly". Are we reading a soap opera here? Hitchcockian cliffhangers, anyone?
That was also one of my side project idea. But the concept should go further: with a time limit !<p>My idea was that you should not be allowed to speak about your daily task more than 42 second on a video record shared to all you team mates.
What?<p>> In reality, there's actually no space in the standup to dive deeper into actual issues.<p>I've never heard of a standup without a parking lot. The entire point of parking lot (and the main value of standup) is to discuss issues with the entire team engaged.<p>> In fact, the best teams actually unblock problems as they come up, instead of waiting for a regularly scheduled standup to report on a blocker.<p>So, instead of having a scheduled time when everyone is available. You want to make decisions disrupting everyone in the middle of their day and not having their full focus?
benefit is raising blockers, ideally resolving them or holding people to follow up, and reducing finger pointing (e.g. I'd have my UI done if jane just finished the API -- ok let's grab jane and ask her what's up).
I've definitely spent a lot of time in standups that are effectively pure micromanage-y accountability plays — what are you working on today. Those were a huge waste of time. In the instances where people could actually help me out, though, they've been very helpful.