Remote teams
Running stand-ups with a remote team
A stand-up with a distributed team stays under fifteen minutes once you drop the status round. Walk the board and only talk about work that is stuck.
A good stand-up with a remote team takes fifteen minutes and is about work that is stuck. Status barely belongs in it, because the board already shows it. Drop the status round and you have time for the questions developers need each other for.
Why the status round fails on a call
The familiar format is a round of three questions per person: what did you do yesterday, what will you do today, is anything blocking you. On a video call this drags. Everyone waits for their turn, and after a few people the rest have stopped listening. Most of what gets said is already in the tickets or the pull requests.
The Scrum Guide has not prescribed those questions since the 2020 edition. What is left is a 15-minute Daily Scrum for the developers, to inspect progress toward the sprint goal and adjust the plan for the coming day. How the team does that is up to the team.
Walk the board
I would run the stand-up around the board. Share your screen and walk the columns from right to left: first what is nearly done, then what is in review, then what is in progress. For each ticket, the owner only speaks up if there is something to say.
That brings out what is stuck, such as a PR that has waited two days for review or a ticket that has said "in progress" for a week. That is what the conversation should be about. Someone with nothing on the board stands out too, and that is a question for after the stand-up.
Right to left works because finishing work is worth more than starting new work. A ticket that is nearly done and waiting on one answer is the one you want closed today.
What to cut
Some things seem handy in a stand-up but make it long:
- Technical discussions. If two people start one, agree that they pick it up together straight after.
- Detailed updates. What someone did yesterday is in the commits and the tickets.
- Shifting priorities or reassigning work. That belongs in planning or with the product owner.
- Announcements for everyone. Post those in chat.
What remains is short: what is stuck, and who needs someone else to get it moving.
A fixed time, not first thing in the morning
Pick a fixed time when everyone is available. With a team in Serbia that is easy. Serbia is on Central European Time, the same as the Netherlands, Germany and Belgium, so a stand-up at 9:30 in Amsterdam or Munich is 9:30 in Belgrade.
Do not make the stand-up the first thing of the day. Someone who starts at nine has not yet looked at what happened since yesterday. Half an hour later, everyone has caught up on email, reviews and chat.
Keep the time fixed when something else comes up, because people start skipping a stand-up that keeps moving.
Cameras, notes and who runs it
Cameras on help, especially when there are new people on the team: you notice sooner when someone hesitates or does not follow. Do not make it a rule you have to enforce. If the rest of the team has their camera on, a new colleague usually does too. For the first weeks of a new team member, see onboarding a remote developer.
Do not minute everything, but do record the agreements. Who looks at which problem with whom after the stand-up? That is one line in the team channel, so anyone who missed it knows what was agreed.
Do not let the same person run the stand-up every day either. If the lead on the client side does all the talking, it quickly turns into reporting to the boss. Rotate it within the team and it stays a conversation between developers.
Async as a supplement
A written stand-up in chat can replace the call on days when half the team is off or tied up in other meetings. Each developer writes two lines: what I am working on and what I am waiting for. How to write that so someone else can act on it is covered in async work: what to write down.
I would not make async the default. A short call keeps a team in different places together. You hear it when someone is struggling, and you rarely read that in two lines of text.
When the stand-up runs long
If the stand-up regularly takes more than fifteen minutes, the team is too big or the stand-up is being used for something else. My limit is around eight people. Above that, split by stream of work and let the leads sync briefly afterwards.
If developers hear things in the stand-up for the first time that should have been in a ticket, the problem is in how the work is prepared, and a longer stand-up will not fix it. Look at your tickets first, for example with the points in writing tickets a remote developer understands.
Sources
Frequently asked questions
How long should a stand-up with a remote team take?
Fifteen minutes. The Scrum Guide describes the Daily Scrum as a 15-minute event. If it regularly runs longer, the team is too big or the stand-up is being used for discussions that belong afterwards.
Do you have to use the three stand-up questions?
No. The 2020 edition of the Scrum Guide removed them. With a remote team it works better to walk the board and only talk about work that is stuck.
Can a stand-up be done asynchronously in chat?
Yes, as a supplement on days when a call does not work out. As a default I would avoid it, because in a short call you notice sooner that someone is stuck.
About the author
Aleksa
Tech lead, Belgrade
Aleksa is tech lead in Belgrade. He leads the development team, oversees the architecture and reports to Erik.
More from Aleksa
