Ask HN: Have you been in a team that did “daily standups” asynchronously?
In the past, all of my teams have had daily-standup meetings. Ie, recurring meetings scheduled for a specific time, when everyone would join the meeting (either physically or virtually) and give their updates
In an attempt to reduce people's meeting load and avoid interruptions, we're considering doing asynchronous slack standups instead. Ie, everyone posts their daily-update on slack at the start of their workday (no specific time). People can then follow up either on slack, or in-person, or offline, regarding any of the updates that others have posted.
Has anyone had experience with doing similar asynchronous daily updates, as an alternative to daily standup meetings? If so, how did it go?
41 comments
[ 4.6 ms ] story [ 133 ms ] threadIf you closed/updated a ticket the interested party will see it, or you can explicitly mention them in the ticket.
If you're blocked, you usually know who's blocking you, so you can contact them directly.
Let's say you're a FE dev waiting for a BE dev to finish a specific API request for you. You ask him how long it will take, and if it's possible to provide a dummy API in the meantime. Alternatively you can mock this API by yourself. If no solution found you can switch to another task or escalate it to the PM.
But this problem shouldn't exist in the first place. It's only exists b/c of Scrum. In mini-waterfall based SDLC methodologies (i.e. Design/Plan->Build(Iterate)->Ship cycles) developers are working on much larger work chunks (i.e. mini-projects), they're opening and managing tickets by themselves, instead of being assigned tickets opened by PM/PO. So if they're blocked on a specific API request, they still have other things to work on.
Standups should be short hence do them standing with no digital screens around and team-size is optimally ~5. 30-60 secs per person probably. Writing a line on Slack spreads them out and takes away more focus IMHO.
Many people will just ignore what is written in the Slack channel and you lose the advantage that everyone knows what is going on and can give feedback. Instant helping out or course correct does not happen.
You lose the team feeling a sense of the team making progress, it easily becomes each dev for themselves.
It often devolves into ticking a box and keeping up the appearance that you are on track, instead of quickly catching those potential situations. I have seen devs then get into terrible psychological pressure since they have over-reported in a way that is much harder in a real standup.
If you need to focus more I would prefer to just drop the daily standup completely once or twice a week.
I haven't worked at a company that did physical standups, but what I've heard over and over is that they tend to devolve into longer meetings, and even worse, into blame game sessions.
In my experience with a handful of teams so far, this has never consistently happened. There are always a few people (if not most of the team) that seem to not be able to be succinct. And many times, the standup turns into a back and forth between 2 or 3 members on a topic that's unrelated to what the rest of the members are doing and therefore a waste of their time.
And most of the time, it's just mind numbingly mechanical and boring, something to get over with so I can get on with my work.
I feel like a team meeting at the beginning of the week to sync up and then ad hoc meetings during the week between relevant parties would be better.
Maybe I've just had bad luck with stand ups or maybe it's me. Not sure.
If you keep noticing this wherever you go, you should be the one to say it.
The underlying prerequisite here is that you need to have a strong reading culture on your team.
It accomplished a number of things: people could make their own hours as long as they post sometime within 24 hours it didn't matter, it was persistent so people can search history (what was everyone doing on Friday), and commentable so those who need to get involved can start a thread on the post and schedule a meeting if need be for sync communication to follow up. It accomplishes everything of an in person standup, but is more efficient and respects people's time.
Daily stand-ups provide zero value in my opinion, asynchronous or not. If one has a blocker then it should be raised to the team in slack/email as soon as you realize you need help from the team. Waiting until daily stand-up doesn't seem sensible to me.
Paying attention to conversations the team is having in slack, the ticket tracker and pull requests gives a much better sense of progress than stand-up in my experience.
So I have mixed feelings. For people who don't want to invest in paying attention to PRs and slack, synchronous stand-up seems to provide more value because they are forced to listen. Personally I'd rather not have stand-up, but if it's required then I'd rather do it asynchronously so it minimizes my time wasted.
The point of the daily stand-up is honestly more for identifying when people are struggling but not reaching out for help. A lot of people have a lone wolf attitude towards work even if they have a team so spotting when someone is avoiding asking for help is important.
By asking people what they are working on all day? "Hey can you tell me the status of xyz please" type things?
Wander by the cubicle and peek over the shoulder?
Feels like stuff that would get people accused of being micromanagers. Honestly far better imo to just have a pre-set, teamwide thing set up.
This also involves the whole team in identifying and solving blockers rather than everything going through a lead, who could then just become a bottleneck (or a human-shaped blocker)
Notice when things aren't getting done by the time they were estimated to be done, and notice if the person seems to be continually pushing back completion dates. After a day or two of "thought I could get it cone but couldn't", it's negligent to _not_ dig in to _why_ the person is struggling. Really not meaning to be snarky, but if a manager isn't doing this, I'm not sure what exactly they are doing.
IME most solid engineers prefer autonomy and trust over schedule and process, and would strongly resent having to spend their time in a meeting because their manager was unable to do people management.
With a text-based standup, I organize my thoughts, ping people who might find the update relevant (to bump it to their attention), and can follow up with a reply-in-thread option (for blockers and such).
Standups have taken a life of their own as each company adopted the agile paradigm. - Replaced weekly status reports - purely individual status oriented instead of taking the form of a team huddle to remove obstacles - Blockers are usually outside of the team doing the standup so it usually goes something like this “I have a blocker with certain microservice, I will/ have reached out to the other team and waiting to hear back”. This doesn’t solve any problem nor the team can do anything to unblock. So a rep from the team has to attend a meta standup to blurt out the blocker
However, I do feel like synchronous stand-ups are more productive
The rest of the day might be spent in solitude. If we're not in an office, let's at least leverage the scrums for some coffee talk.
You don't need to do daily standups just because most dev teams do.