DEV Community

Cover image for We moved to async stand-ups and never looked back
Gregory Witek
Gregory Witek

Posted on • Originally published at on

We moved to async stand-ups and never looked back

I've recently read a rather popular blog post about cancelling stand-ups and how it affected team's productivity. While I find the topic extremely interesting and I like experimenting with changing processes, the post lacked some long-term conclusion (hopefully a 2nd part is coming in a few months!). I thought I could share my experience with making stand-ups shorter and more effective. I do not have any hard numbers to show, what I have is experience and some rough estimations from 3 companies I worked with where I participated in daily stand-ups.

15 minutes or 1 hour?

In the 1st company, I was a new employee and I had little say about team processes, so I followed the by-the-book style that the team implemented.

Every morning I arrived at work around 9:30am, I grabbed a cup of coffee, and in 5-10 minutes I was at my desk ready to work. However, at 10am I had a stand-up, so I spent the 20min I had on replying to e-mails and chatting with my coworkers.

Stand-up was in a separate room, where the whole team met at 9:55am so that we could connect with a few people who worked in another office. Ignoring random audio/video problems, we usually wrapped things up in 20 minutes, with occasional 10min follow-up after the call. Sometimes discussion took a bit longer, but usually I was back at my desk by 10:30am, an hour after coming to work.

I guess this is not exactly how stand-up looks like in your "Scrum for beginners" manual, but that's how it worked in practice, and trust me, that company is not an outlier. It worked quite well for some people, especially those who came to work just before 10am, while I found the lost hour a bit frustrating. I tried to change it, but everyone else felt ok with the way things were, so we kept it the way it was.

The total time I spent on stand-ups was around 30min a day, so 2.5h a week (5h if counting the 30min a day that were kind of wasted, but who knows, maybe I would be wasting them anyway).

We moved to async stand-up and never looked back

How to scale a stand-up?

In the 2nd company I was a team lead and we had a classic, quick stand-up. Next to our desks, all people standing in a circle, one by one saying what they did, what they are doing and what's blocking them. Anything to discuss? Do it in smaller groups right after the stand-up. It usually took 1min per person, 10, maximum 15min in total.

This was going well for a while, but over time it became more difficult to manage. First, as we were approaching 15 developers and we split into 2 teams, we needed a way to split the stand-ups as well, but how to do it when we all sit together? First goes one group and then another? That felt awkward, as did having everyone go to a meeting room for 10 minutes.

The 2nd challenge was that we expanded our team to a new office in another country. One of the things I wanted to prevent was separating all work and rituals by location - this alienates people working from new office and makes them feel less attached to the company. We considered having a call every morning, with 2 groups standing in front of the camera in their respective offices. It's not a bad solution, but having experienced it in the past I knew how awkward it feels, and how making sure the connection works can take longer than the meeting itself.

Good morning! Yesterday I...

So what we did was to remove stand-ups. Or rather, we removed stand-up as a meeting, while keeping the update part. We moved it to Slack, so that every morning, every team member was supposed to write a short message when they started working. A short "good morning team!" followed by 3 bullet points. This provided a few benefits:

  • scaling - each team has their own channel where they write the message
  • persistence - messages stay on Slack, so it's always easy to get back to something that I was supposed to follow-up on. Also, it made it possible to add links to tasks or documentation, and discussing any blockers was easy - just reply to the update message
  • flexibility - you come to work, you sit down, you check what you've got to do today and you write "Good morning everyone! Here's my update...". It's the first thing you do, and then you can start working. It takes 2-3 minutes and you don't need to wait for anyone. You can read other updates later when everyone's in, and if someone needs your help, they'll tag you.

So in this case we didn't really save any significant amount of time (not that there was a lot of time to save in the first place). Writing and reading all the messages could even take a bit more than before. But we got a lot in exchange - and we never looked back.

We moved to async stand-up and never looked back

Rinse, repeat

This experience helped me in the 3rd company. When I joined it, stand-ups were happening over a call (around half of the team was remote) and usually took around 30-40 minutes. Yes, you're right, that's way too long. 30-40 minutes * 5 days means 2.5-3 hours a week spent by every team member on what's supposed to be a quick update.

I quickly realized the issue was that while a few people had short and concise updates, others were taking their time and often started longer discussions. I took various attempts to change it - tried to limit stand-up time to 15 minutes, reminding people to discuss other topics after the call in smaller group, etc. but I was not satisfied with the results. Finally I got a small win - we introduced Fridays without meetings and that meant no stand-up either. In order to stay in touch about the progress and blockers, we decided to just write updates on chat. What started as once a week initiative, after a couple of weeks turned into a daily practice, we moved to entirely asynchronous stand-ups and again we never looked back.

As I have mentioned before, the amount of time we saved was around 3 hours per person every week. For me, this was huge!

Not perfect

One thing I'm really happy about is that in both cases where I managed to introduce the change, after a while it gained essentially unanimous support - everyone told me they preferred the asynchronous updates.

There are a few aspects though in which this idea could be improved, and a few in which it will always be worse than a classic meeting. Seeing and hearing your peers is something that can't be replaced. Reading messages removes that human touch, it strips us of things that make us feel that we're talking to real people. In my case this wasn't a big issue as we had enough other calls each week anyway not to miss each other, but it might not be the case in every company.

Missing messages is another challenge - if you come to work first and write your message, then you need to make sure that later you read messages by other people who start work later. If people don't do that, then what's even the point of sending updates? I struggled a bit to follow all messages everyday, something that didn't happen during classic stand-up. This problem can be solved with a dedicated tool that will remind you to send a message each morning, and will compile all updates into one longer message when all team members provide their updates. Alternatively you can set a reminder to read all the messages at some point during day, when you expect them all to be there.

We moved to async stand-up and never looked back

Throw out the book

One of the most common problems I have when trying to improve processes are people who specialize in certain system or methodology (often certified in it), who tell me that's not how things should be done. Whether they're fans of Kanban, Scrum or something else, I often hear "we should not do it, this is against Scrum guides".

I believe such attitude is against the principles of good team work. Whenever something doesn't work, I try to change it. If it gets better, I keep the good parts and keep improving. If it gets worse, I learn the lesson and change the direction.

Me and my teams in the past changed the daily stand-ups, because they didn't work for us. We wanted to stay updated, so we kept that part, and we improved the rest. I don't know if that's going to work in your team too, maybe not - only you can try it out and see if your team likes it. So go ahead, keep the good parts, throw out the rest of the book, try to make your way of work better. Good luck!

Comments and discussion:


Burning book photo by Fred Kearney on Unsplash

Paddleboard photo by Krzysztof Kowalik on Unsplash

Scale photo by Bartosz Kwitkowski on Unsplash

Hand washing photo by Rizal Hilman on Unsplash

Top comments (0)