Daily Scrum time-box in remote

I don't think that there's a reason to increase the timebox just because you are remote and are using videoconferencing tools.

I believe that most of the problems that you mention have readily available solutions.

For screen sharing, make sure that the person or people responsible for sharing various content has the content open and ready to go at the start of the timebox. Load any tools or pages in advance and refresh them just before the event starts to make sure they are up-to-date. I find it helpful, at least in the context of the Daily Scrum, to have one person share all of the content. It doesn't have to be the same person every single time, but knowing who is responsible so they can take a few minutes in advance to prepare would be sufficient.

For checking audio and video, most tools have mic and camera checks built-in. I think that it's reasonable for everyone to make sure that they have a reliable Internet connection, are connected to any VPNs, and are authenticated in any tools. As they log into tools like the video conference, they should be aware of their mic and camera settings so they know if they are broadcasting or if they will need to unmute when speaking. If they are using headsets with built-in speak-to-unmute, they should be aware of this as well.

These things may add a little bit of time needed but shouldn't add to the timebox to accomplish the event's objectives. People may not be able to just "wander in" at the allocated start of the timebox and expect to be efficient, but this should be built into any event. Perhaps you do want to put 30 minutes on people's calendars just to make sure that they aren't switching from another meeting (which may or may not be well run), but blocking 30 minutes on a calendar is not the same as expanding the 15-minute timebox.

To avoid this overhead, we increased our time-box to 30min, because in 15min we couldn't share all the info needed (we were not coordinated at all after the meeting), and also if some small thing to be solved is raised (e.g. 5mins), moving that to another meeting would increase notably the time requiered to get a definition/guide (~30mins).

I'd suggest that, in reality, you *didn't* avoid this overhead. What you did was to hide it by extending the time-box allowed for a Daily Scrum. Doing so results in the associated impediments then being accepted.

Do you think this is against the spirit of Scrum for remote teams? 

What do you think? I reckon you already suspect the answer.

I think you should consider other potential impediments, as well as the technology you are using.

Communication within the team will have inevitably changed. Could it be that the inability to hold an effective Daily Scrum within 15 minutes is a symptom of some dysfunction within the team; such as poor refinement, an unacceptable overhead to having impromptu discussion during the day, a lack of alignment around the Sprint Goal, lost accountability (or the perception of it), or team members who are overworked or struggling psychologically with the current circumstances?

In my opinion, all of these would be more severe problems than the loss of 15 minutes per day, and if you suspect any to be true, I encourage you to work with the whole Scrum Team to investigate.



Practically speaking, it could also be down to how well team members are using their time. I have seen that the Development Teams I work with are generally able to stick to the timebox, but it's reasonably common for some of the developers to stay on the conference call after the Daily Scrum, in order to discuss a specific matter in detail.

I am certain that the folks who need to talk more are a small segment of the people at the Daily Scrum. So have your Daily Scrum and ask the others to meet after in a breakout session.

We are holding all our events remote. In the beginning we also had issues with share and not being connected to development server in Reviews, but this improved, the change is now quite fast and everyone is prepared for those meetings. It is a matter of the team, to be prepared and if it would not work, I would bring this up, latest in the Retro.

As for the daily, we often join in earlier to have a short chat and we start at the hour. Yes, sometimes someone is talking to mute, but this does hardly cost more than 5 sec to get over it. And if someone is having connection issues, the status is posted in the chat or we retry at the end.

There is no side-communication and if they need to clarify something, they do it after everyone is through with the status.

We currently have a DevTeam of 8 and they manage to keep in the 15min Timebox in a remote (MS Teams) Daily Scrum.

We have 57 teams in our company and everyone of them are working remote.  The move to online events has been easy.  All of the teams understand the purpose of each event and are honoring it.  Many of our teams can complete the Daily Scrum in less than 15 minutes.  They just moved to online and did exactly the same thing that they did in person.  The differences are that each team knows who will be sharing for the event before the event starts.  That individual will have everything needed pre-loaded and refreshed as @Thomas Owens suggested.  

As for the issues with the online tool.  They are all sofwared professionals and are fully capable of learning a product and managing it. We use a video conference tool and everyone has their video turned on. There is an indicator on each individual that shows if they are muted.  If we see lips moving and the mute indicator, we tell them.  It takes seconds to click the button to unmute. 

I agree with @Simon Mayer that you probably have bigger problems that are leading people to place blame on the tools. If you aren't using a video chat where you can see people, it is very likely that they are doing other things and not paying attention to the event in progress. 

You have found an impediment and instead of removing it, you are accomodating it because that is easier. Sometimes difficult conversations have to occur in order to improve.  This might be time for one. 

To avoid this overhead, we increased our time-box to 30min, because in 15min we couldn't share all the info needed

@José Santiago Bonilla Pazmiño, Here's an easier perspective. First understand the true reason why timeboxes are specified, and then, consider if you are still practicing Scrum if you go over a minute from the 15 minute timebox?

Thanks a lot for your responses. I really appreciate them.

A few thoughts of mine about your responses.

I believe that most of the problems that you mention have readily available solutions.

That is perfectly correct, but I do not think it was the same working remotely or co-located. For sure, we can change our way of working, so we are spending now 15min coordinating (Daily Scrum) and 15min in the same videoconference room solving some quick issues (only with the people needed). Sometimes we spend 13min, other 19min in total, a very few 30min, so I can say my timebox is 30min now (I now it is not Scrum, and we should improve).

I'd suggest that, in reality, you *didn't* avoid this overhead. What you did was to hide it by extending the time-box allowed for a Daily Scrum

Fair to say that, I agree. However, I have another point of view: If everybody working post-covid (remotely, not just tech people) does some extra pre-daily scrum activities, e.g. 5min: checking tools, opening tabs, checking internet (low bandwidth here in Latam, by the way), etc. it is still overhead we did not have working co-located. So in some way, it is more *transparent* to say we are preparing ourselves 5min to daily scrum and using 15min in the event, but it is still 20min in total for a Daily Scrum (not just the meeting, the total activity).

(…)such as poor refinement, an unacceptable overhead to having impromptu discussion during the day, a lack of alignment around the Sprint Goal, lost accountability (or the perception of it), or team members who are overworked or struggling psychologically with the current circumstances. In my opinion, all of these would be more severe problems than the loss of 15 minutes per day

That is a good point. In fact, we had some of those problems. By the way, at the beginning in retrospectives some people have told us some of those concerns, so we tried to solve most of them (at our best), but nobody asked about daily meeting after COVID in restrospectives.

(...)but it's reasonably common for some of the developers to stay on the conference call after the Daily Scrum, in order to discuss a specific matter in detail.

That is our case: in the first meetings we spent 1hour daily because of many of those concerns (e.g. we do not have a VPN, how can we work remotely?, are we going to be fired?, when are we going to work at office?) then we switched to 15min, and then the team asked 30min (15min daily and 15min quick solving). It seems it is working now, but again we can improve.

So have your Daily Scrum and ask the others to meet after in a breakout session.

We tried, the team told us: we are all in this meeting, let us discuss a bit more this topic here instead of opening another session.

 Then, we provided them some more videoconference rooms, and then they are a bit more comfortable to discuss some big issues in another session, but small ones *after* the daily scrum.  

As for the daily, we often join in earlier to have a short chat and we start at the hour.

That is an elegant solution. Still extra pre-daily activities. If the team is aware of that, it is transparent enough that total daily coordination is taking more than 15min at day.

They are all sofwared professionals and are fully capable of learning a product and managing it.

I understand, but you are assuming this, Scrum is not just for software development.

First understand the true reason why timeboxes are specified, and then, consider if you are still practicing Scrum if you go over a minute from the 15 minute timebox?

All of your views have given me a new perspective, so I am trying with my team your suggestions.

Thanks a lot again.

That is perfectly correct, but I do not think it was the same working remotely or co-located. For sure, we can change our way of working, so we are spending now 15min coordinating (Daily Scrum) and 15min in the same videoconference room solving some quick issues (only with the people needed). Sometimes we spend 13min, other 19min in total, a very few 30min, so I can say my timebox is 30min now (I now it is not Scrum, and we should improve).

I think that you need to do what works best for your team, whether it's aligned with the rules of Scrum or not. Personally, my recommendation would be to hold the Daily Scrum with everyone and get through the coordination aspects first. Then, anyone can "hang out" in the virtual meeting room or open up other calls to have other discussions as needed. This would optimize everyone's time - everyone only needs to allocate 15 minutes for the event. They can schedule time, including immediately after the Daily Scrum.

This type of approach is consistent with how I worked with teams when we were in the office. I usually suggest booking the room for Daily Scrum for 30-45 minute increments. This makes sure that there's enough time before to set up the room and after for short conversations among the team. With good time management, it also lets the team clean up and clear out of the room before any other people move in.

I would recommend experimenting with this approach of a 15 minute Daily Scrum, and then additional conversations after. Spend a Sprint doing that and see what the team thinks. Maybe the team will find that this is good. Maybe they won't and would rather allocate 30 minutes and have conversations interjected into the middle of the Daily Scrum rather than at the end.

I will say, though, that allowing extraneous conversations in the middle can put pressure on the timebox, even if you extend it to 30 minutes. If the conversations run long or go too in-depth, you may just run out of time for the planning and coordination aspects.

If everybody working post-covid (remotely, not just tech people) does some extra pre-daily scrum activities, e.g. 5min: checking tools, opening tabs, checking internet (low bandwidth here in Latam, by the way), etc. it is still overhead we did not have working co-located. So in some way, it is more *transparent* to say we are preparing ourselves 5min to daily scrum and using 15min in the event, but it is still 20min in total for a Daily Scrum (not just the meeting, the total activity).

I've worked with partially remote teams. Some of the people were fully remote. Others worked remotely (usually from home) a couple of days a week. Of course, in this situation, it was by their choice, since the office had space for them. In the current situation, the office may be closed or operating at reduced capacity and people are working remotely by mandate rather than choice.

This preparation is not part of the event itself. I don't think you're adding transparency, since the time you are spending is not reflective of the time spent performing the required actions. If there is a question about if you are spending 15 minutes or 20 minutes performing the daily coordination activities of the Daily Scrum, transparency is reduced.

I'd also point out that this doesn't just apply to the Daily Scrum, but any scheduled event. I believe that all participants should be ready to go at the scheduled start time. There may be cases where someone is coming from another meeting and has to context switch, but this should probably be the exception and not the norm.

I understand, but you are assuming this, Scrum is not just for software development.

I would expect any professional to be proficient at using the tools at their disposal. It may take a little time to get used to the new tools, but that doesn't mean that they can't. There should be no problems loading the Sprint backlog and board, logging into the videoconferencing software, checking audio and video, and sharing a screen. These should be routine tasks that don't add significant overhead to the event.