As the world has moved toward remote work, many companies are starting to move towards asynchronous standup meetings as well. Unfortunately, asynchronous standups are not only less effective, but they can also actually be harmful. Here’s why your team should always make the effort to have synchronous standups.
An Example: Asynchronous vs. Synchronous Standups
Many organizations have started moving to asynchronous standups because the purpose of standups is not well understood. The true purpose of a standup meeting is not to just provide status updates to your team. The true purpose is to quickly identify blockers and solutions, and asynchronous standups don’t do this nearly as effectively.
Synchronous standups allow for back-and-forths that can solve and prevent problems quickly. Imagine a fictional team that does asynchronous updates via a Slack thread every day. In this team, Person A is beginning to work on a feature. Person B has some knowledge about the feature, specifically that it might interfere with the work they’re currently doing.
In the daily standup Slack thread, Person B gives their update, then proceeds on with their day. Person A, at a later point, then gives their update, where they mention the feature they’re begun to work on. Neither Person B nor Person A has had direct communication with each other. Both continue with their work until, at some point, the problem surfaces. Maybe the team identifies the problem half an hour after Person B gave their update. Or, maybe the team identifies it hours later after Person B has already done plenty of work that might now need to be undone. Regardless, the team identifies the problem almost immediately in a synchronous standup.
In a synchronous standup, Person B would give their update, mentioning the feature they’re working on. Person A could then jump in and mention that it may interfere with their work. Person A and Person B then agree to speak after standup to clear up the problem.
That’s it, the team avoids the problems and spares themselves headaches.
The Problem with Asynchronous Standups
The previous example also assumes that everyone remembers to post their update in the Slack thread. It may sound ridiculous, but in my experience people (myself included!) will begin to forget to give updates very quickly. Even if everyone gets some notification that they need to post their updates, a notification is easy to put off when you’re in the middle of something. Putting off a synchronous meeting where someone’s absence is obvious is much harder.
A team lead could try to enforce that everyone always posts their updates and that everyone takes the time to read everyone else’s updates. However, this quickly becomes much more cumbersome than just setting up a synchronous standup. It also still does not provide the back-and-forth that quickly surfaces problems.
At the end of the day, we can boil down the argument to this: a standup requires that everyone in the team knows what everyone else is working on. It also requires that everyone can quickly bring up concerns or questions about that work. This is almost impossible to do with asynchronous standups. Because of this, barring situations like major time zone differences, teams should always treat synchronous standups as essential.
IMO stand ups are an anti-pattern anyway. Why does one need to wait until some arbitrary time to raise a concern that they are blocked or tell everyone what they are working on. This is purely a tech-world cargo culting.
If you are blocked then I expect you to raise this issue immediately thru any agreed upon communication channels. A GitHub issue tagging people, or a Slack message or an email.
If you want to let everyone know what you are working on, well again that’s what issues and Kanban boards are for. Drag your ticket from one column into another. If we truly need everyone to know – add some automation to ping everyone concerned when ticket status changes.
I see zero value in stand ups and most people hate them anyways and think it’s a waste of time.
I don’t think you read the post correctly, particularly this part:
“Both continue with their work until, at some point, the problem surfaces. Maybe the team identifies the problem half an hour after Person B gave their update.”
The point here is that the person may not realize that the direction they or someone else is heading in could cause problems. If someone knows they’re blocked, then yeah, obviously they should bring that up immediately.
You may still object to the standup. But that’s not really the point of the article. It’s not “Should you do standups at all?” It’s about problems with doing so asynchronously instead of synchronously. It makes a valid point. You could argue that, with all the time spent doing standups, does the time saved in the few instances of catching these collision courses make them worthwhile?