Async standups: Pros, cons, do they make sense for you?
Daily standups (or dailies, daily scrums, daily meetings, however you call them) have been a core element of the software development process for years. Popularized by agile practices and the scrum guide, this practice is something we rarely question. We just meet up every day, just as everyone does.
But should we?
While they do bring a lot of benefits, such as daily alignment, quick blocker identification, and enhanced collaboration, they come at a cost — they take a lot of time.
Even if you stick to the 15-minute rule, with a team of say seven people, that’s still over an hour of productive time per week.
To make things worse, we often spend a couple of minutes before a meeting mentally preparing for it (the “I won’t do anything productive in these six minutes” syndrome) and recovering from the meeting. Then also comes the context switching and interrupting people’s deep work time.
At scale, it’s really expensive to meet every single day as a whole team.
That’s why I’ve spent quite a lot of time experimenting with different approaches and alternatives. One of them is having asynchronous standups. We actually ran an experiment for six weeks (equal to six sprints of ours) when we had all our daily meetings asynchronous.
Let me share what we learned.
How asynchronous standup works
The idea of an asynchronous standup is simple. Instead of daily meetings, everyone writes an update on a dedicated channel, pinging relevant people if necessary.
If additional collaboration is needed, people can huddle together, but only in that limited group that’s truly needed to resolve the issue, without bothering the rest of the team.
Regarding timing, there are many approaches, ranging from scheduling updates on a specific hour to doing so anytime during the day. For organizational purposes, we opted for sending an update between 9 and 11 AM.
Conclusions after a 6-week experiment
For six weeks straight, we skipped almost every daily meeting. I say almost, because if there was a big pivot or an important announcement, we did schedule a quick catch-up but that happened two times or so.
The benefits were clear from day one. The three most notable improvements were:
Productivity boost
With the extra time and one less interruption, our productivity improved noticeably. Our velocity went up by roughly 10 percent immediately. That was exciting.
Updates were more relevant, and people actually read them
In a normal meeting, people tend to go on and often over-elaborate on topics. On a chat, however, they tend to go straight to the point, and we liked that.
In the first couple of weeks, people also reported that they actually paid more attention to reading the updates than they ever did during the meeting. I bet you’ve spent some time multitasking yourself.
Less meetings
Most people liked having one less meeting to attend, simple as that.
Challenges of an async standup
After the honeymoon period, the first challenges started to appear. The three main issues were:
Updates became noise
Although initially people excitedly read every single update and paid great attention to writing their own, over time, it became a rut. Most people admitted to not reading these updates, or even knowing who had what challenge, unless they were directly mentioned.
Cycle time to solve problems increased
Although we didn’t measure how long it takes to solve problems (e.g., technical difficulties, a new blocker), we did notice that the longer the experiment was, the longer it took.
Lack of human interaction decreased team morale
Daily standups aren’t only about work. It’s also an opportunity to see each other, have small talk, and have a laugh. While we did add “weekly coffee chat” to maintain team spirit, it didn’t replace the daily interaction.
Finding the middle ground and the unsolvable(?) challenge
To summarize, we missed the spirit and collaborative nature of the daily meetings, although we did enjoy the time off and more “no meeting days” in our calendars.
So, as a next step, we tried a middle ground. We had a daily meeting on Monday and Thursday, while having async updates on the rest of the days.
This helped us solve two out of three challenges. The speed of solving problems increased again, and extra interactions within the team helped boost team dynamics and morale.
On the days we didn’t have a daily, though, updates were still unread. To be clear, people care about what’s going on, but when you get a couple of status updates almost every single day, you become deaf to them.
So we ditched them. The experiment switched to just having two standups a week with ad hoc meetings whenever necessary.
For us, that was the sweet spot.
Does an async standup make sense?
Whether or not the asynchronous standup makes sense is hard to say.
I tried it two times, and the results were the same.
The first couple of weeks were amazing, and everyone was satisfied. But over time, we started caring less about the updates, and the lack of daily synchronous touchpoints with the rest of the team impacted our morale.
In both cases, we just ended up having fewer standups in general (you can read about our second “two standups a week” experiment here).
My theory for now is that asynchronous standup doesn’t make much sense for teams that work closely, such as product teams. However, asynchronous updates still seem like a promising approach for teams that don’t work that closely together but need to keep each other updated. Maybe instead of weekly sync with your marketing team, just send each other a quick update and see if a call is needed?
My conclusion so far is two-fold:
- Asynchronous communication over a meeting is almost always a more efficient approach
- But when there’s too much async communication, it becomes overwhelming, and a good old meeting becomes a better choice
But as always, that depends on a particular context and setup. If you think async standup can work for you, give it a try. In the worst case, you will learn something new about yourself and your team.
Featured image source: IconScout
The post Async standups: Pros, cons, do they make sense for you? appeared first on LogRocket Blog.
This post first appeared on Read More