Running the Daily Scrum remotely

On a video call, a Daily Scrum has none of the quiet cues of a room. Nobody sees who has stopped listening, nobody drifts over to look at the board, and a long silence is hard to read. The framework does not change. The Guide's requirements are the same, and the work is to rebuild with tools what the room gave for free.

What does not change

The purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. It is a 15-minute event for the Developers, at the same time and place each working day, and the structure is the Developers' to choose, as long as it focuses on the goal and ends with an actionable plan for the next day.

For a remote team, "the same place" means the same link and the same channel every day. The Guide's reason for fixed time and place is to reduce complexity, and a changing link adds the exact complexity it wants to avoid.

The Guide also says that, optimally, all events are held at the same time and place. A distributed team cannot be in one place, so it should at least keep the time and the virtual place constant. Team members who are in different time zones need a different treatment, covered in a later post.

What the room used to do

Think about what a stand-up round a physical board gives you without effort. Everyone is looking at the same thing. Silence is visible. Side conversations are physically separated. People can see when the clock is close. Moving to a call changes each of these. The remedy for each is a habit.

A shared board, on screen, for everyone. The GOV.UK Service Manual's advice on agile working environments says teams need a shared visual workspace, which can be a physical wall or a digital board that can be reached from any location, used at daily stand-ups online or in person. Share it and keep it on screen throughout. The board is what you talk about, not the speaker's last twenty-four hours.

A fixed, early start. Start on the minute. Waiting for latecomers punishes the punctual and drifts the time.

Cameras on, when possible. Faces tell the team who is engaged. Do not make it a rule that breeds resentment: some connections or circumstances make it hard. Agree a team norm.

A clear order for speaking. Without a room's cues, people talk over each other or wait too long. A visible order, such as the board's columns or a list of names in the chat, removes the guesswork.

A timer in view. Fifteen minutes passes differently when you cannot see people shifting. A visible clock keeps the box honest.

A place to continue. When a topic needs more time, the people concerned stay on the call or move to a breakout room. Everyone else leaves.

A worked example

This is an illustrative case. A team of six works from four cities. They hold the Daily Scrum at 09:30 on a video call, with the Sprint Backlog board shared.

The Scrum Master, who is attending as a facilitator, starts it on the minute. They agree on a format: walk the board from the right. The first item, the order confirmation page, is in review. Someone says they will review it right after the call. The second, the notification service, is blocked on a staging environment. A Developer notes it has been blocked since yesterday. The team asks who can chase the infrastructure owner. One person agrees to message them before ten.

At minute eleven, a Developer raises a design question about how to retry failed notifications. The Scrum Master asks who needs to be in the discussion. Two hands go up, and the call ends at minute fourteen with those two staying. The updated board shows four tasks for the day with names.

Compare a worse version of the same morning: the link is different each day, three people join late, the board is not shared and each person reads their updates from memory. The meeting runs twenty minutes and nobody knows who is chasing the environment.

Pitfalls

• The talking-head round. If everyone reports in turn without the board, you have a status meeting on video. Use the board.
• Multitasking. Without being observed, people read email. A short meeting, a visible board and real questions help.
• The dominant voice. On a call, the person who talks fastest controls the time. The facilitator can invite quieter people by name.
• Technical delays. Test links and tools. Agree a fallback, such as a phone number or chat, if the call fails.
• Over-recording. Recording every Daily Scrum is rarely helpful and tends to make people more guarded. The Sprint Backlog is the record.
• Meetings after the meeting. Remote work generates more "quick calls". Keep them to those who need them.

When asynchronous is acceptable

Sometimes a team cannot meet at the same time every day, perhaps because members are twelve hours apart. A written update can serve for some days: each person adds a short note to the board or a thread before a set time, saying what moved toward the Sprint Goal, what is blocked and what they plan to do. The team then holds a short live conversation at an overlapping time, for those who can, to adapt the plan.

This preserves the Guide's purpose if the notes do inspect progress toward the goal and result in an adapted plan. It fails when it becomes a log nobody reads. Use it as a supplement to the live event, not as a permanent replacement, and review it in the Retrospective. The Guide itself insists on regularity, and says failing to operate events as prescribed results in lost opportunities to inspect and adapt.

Hybrid teams

A mixed team, with some people in a room and some on a screen, has a particular risk: the people in the room form a conversation that the remote participants cannot join. The remedy is simple and unpopular. Everyone joins from their own device, even those sitting together, so that everyone has equal voice and sees the same board.

How to practise it

Run your next remote Daily Scrum with only one change, the board on screen throughout, and note how many blockers were named. In the simulator the team's work is on a board you see at each step, so you can practise reading it as a team would in a stand-up.