{{announcement.body}}
{{announcement.title}}

Remote Agile (Part 8): Daily Scrum With Distributed Teams

DZone 's Guide to

Remote Agile (Part 8): Daily Scrum With Distributed Teams

This eighth article in the popular ''Remote Agile'' series now looks into supporting a distributed Development Team organizing a remote Daily Scrum.

· Agile Zone ·
Free Resource

A Remote Daily Scrum With a Distributed Team

We started this series on remote agile with looking into practices and tools; we explored virtual Liberating Structures, and how to master Zoom. We had a look at common remote agile anti-patterns; we analyzed remote Retrospectives, Sprint Plannings as well as remote Sprint Reviews based on Liberating Structures. This eighth article now looks into supporting a distributed Development Team organizing a remote Daily Scrum.

Remote Daily Scrum

The Purpose of the Daily Scrum

The purpose of the Daily Scrum is clearly described in the Scrum Guide — no guessing is necessary:

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key to inspect and adapt to the meeting.

Source: Scrum Guide 2017.

The Daily Scrum is an essential event for inspection and adaption, run by the Development Team, and guiding it for the next 24 hours on its path to achieving the Sprint Goal. The Daily Scrum is hence the shortest planning horizon in Scrum and thus mandatory.

Virtual Liberating Structures for a Remote Daily Scrum

Contrary to popular belief, the Daily Scrum’s 15-minute timebox is not intended to solve all the issues addressed during the event. It is about creating transparency, thus triggering the inspection. If an adaption of the Sprint plan or the Sprint Backlog, for example, is required, the Development Team is free to handle the resulting issues at any time. In my experience, most Daily Scrum issues result from a misunderstanding of this core principle. We hence look at the Daily Scrum’s two parts separately.

Virtual Daily Scrum Part 1: Are We Still on the Right Track to Accomplish the Sprint Goal?

This is the 15-minute time-box where the members of the Development Team inspect the progress towards achieving the Sprint Goal since the previous remote Daily Scrum. To structure this part of the remote Daily Scrum, the Sprint Guides suggests a non-mandatory information-sharing pattern — the three questions — that pretty well translates to a remote set-up. 

One way of applying this pattern to a remote Daily Scrum is to run a virtual Mad Tea to collect and distribute information from all developers rapidly among the team members. Of course, we cannot recreate two concentric circles of attendees facing each other. What we can do is use the set of questions to create a prompt — a half-sentence that the team members shall complete — and the chat channel to create a quick picture of the team’s sentiment. 

As the moderator, prepare the necessary prompts in advance regarding the progress of the team towards the Sprint Goal, for example, “Today, I will support the Development Team by contributing…” Then post that prompt to the chat and ask the participants to add their answer(s) but not to hit enter. That is done simultaneously by all attendees when the moderator asks for it. This way, the Development Team can generate insight synchronously at a rapid pace, identifying potential areas where more collaboration is needed to ensure that the Scrum Team is meeting the Sprint Goal.

Virtual Daily Scrum Part 2: Dealing With Issues

Let us move on to the part of the remote Daily Scrum, where the Development Team collaborates on solving issues that might impede its ability to achieve the Sprint Goal. Consider the following microstructures for the second phase of the remote Daily Scrum, when Development Team members may need individual support, or where the whole team needs to decide how to adapt in the light of new learnings:

  • Troika Consulting proves to be especially helpful at sourcing support at the individual level, for example, from other Development Team members on how to solve a technical issue. To run it in a distributed team, we start by creating breakout rooms for groups of three. Consultants and the consultee have the initial conversation; then, the consultee turns around on his or her chair for the consulting phase. Alternatively, both consultants stop broadcasting their video, so the consultee is just listening to what they have to say. 
  • Min Specs has proven to be a very effective virtual LS microstructure when it becomes apparent that the original plan to achieve the Sprint Goal is no longer valid and needs to be trimmed, probably in collaboration with the Product Owner. Like What, So What, Now What?, a remote Min Specs is a sequence of individual work and group work based on breakout rooms, aggregating findings in shared workspaces to be shared with the whole Development Team in the end.
  • In an inexperienced, new Development Team in its early team-building phase or structures centered around component teams or challenging software architectures, ‘What I Need From You (WINFY)’ could offer the right frame to articulate core needs to achieve the Sprint Goal and coordinate and involve everyone in the collective effort. Again, in a remote setting, we employ breakout rooms, the chat, and shared workspaces. Embedded 1-2-4-All or What, So What, Now What? may support the effort as well.
  • TRIZ may prove to be useful when the team needs to reaffirm its plan to achieve the Sprint Goal, for example, because of outside pressure. Again, TRIZ is a combination of basic elements of virtual Liberating Structures: breakout rooms, embedded 1-2-4-All, and joined workspaces. As a Scrum Master, you may consider supporting the effort by time-keeping on behalf of the participants as they are likely to lose track of time. 
  • Another approach to solving the beforementioned challenge is the Discovery and Action Dialog (DAD) to “Discover, Invent, and Unleash Local Solutions to Chronic Problems.” A remote set-up may result in a heightened bias for action, particularly on the side of stakeholders and the management due to a perceived loss of control, impeding a Scrum Team on its way to achieve its Sprint Goal. DAD can support the Development Team to discover outside intervention and how to address the situation by identifying positive deviant (PD) behaviors and practices to provide solutions to real (and perceived) problems. Technically, a virtual DAD applies standard procedures like breakout rooms, embedded 1-2-4-All, joined workspaces, and probably a Shift & Share.

Supporting Liberating Structures

Two Liberating Structures microstructures can support a remote Daily Scrum and particularly its second phase: 1-2-4-All, and Lean Coffee:

  • To cover 1-2-4-All, we need breakout rooms and a place to aggregate the findings. We start with everyone in the whole group for a minute in silence; then, we split the whole group into pairs using Zoom’s breakroom feature for 2 minutes. After that round, we merge two pairs into a group of four for five minutes—this has to be done manually by the host–and the group aggregates its findings, for example, on a Google sheet prepared for each group in advance. We can introduce each group’s findings to the whole group by screen sharing in a Shift & Share. 
  • Lean Coffee is an excellent example of a workaround for virtual Liberating Structures. Gather all the input in the usual way, for example, engaging in 1-2-4-All, and gather those on a FunRetro.io board while voting is turned off. (Use several columns if the whole group is large to speed up the gathering process.) Then ask the whole group to cluster similar topics, then turn on the voting and order the remaining entries by votes. For here, you continue with a whole group discussion, or you engage smaller groups with breakout rooms. 

Remote Daily Scrum Antipatterns

There are plenty of Daily Scrum anti-patterns in general. However, I want to point at a few anti-patterns that are particularly relevant for a remote Daily Scrum:

  • Orientation lost: The Daily Scrum serves one purpose as it answers a simple question: Are we still on track to meet the Sprint Goal? Or do we need to adapt the plan or the Sprint Backlog or both? Often, the Development Team cannot answer that question immediately. (In that respect, tracking the progress towards the Sprint Goal by regularly updating Scrum boards or ticket systems is even more recommended for a distributed Scrum team.)
  • Cluelessness: Team members do not prepare themselves for the Daily Scrum. (“I was doing some stuff, but I cannot remember what. It was important, though,” is not the right attitude for successfully practicing remote Scrum. This kind of work requires becoming more organized by comparison.)
  • No use of work-item age: A Development team member experiences difficulties in accomplishing an issue over several consecutive days and nobody is offering help. (Often, this result is a sign that people either may not trust each other or do not care for each other. Alternatively, the workload of the Development Team has reached an unproductive level as they no longer can support each other. Note: Of course, the Scrum Guide does not mention the ‘work item age.’ However, it has proven to be a useful practice.)
  • Status report: The Daily Scrum turns into a status report meeting, driven by the fear of the management to ‘lose even more control now’ and Development Team members are waiting in line to ‘report’ progress to the Scrum Master, the Product Owner, a stakeholder, or the manager. (No comment needed; that situation is a case for the Scrum Master to step in and support the Development Team.)
  • Planning meeting: The Development Team hijacks the Daily Scrum to discuss new requirements, to refine user stories, or to have a sort of (Sprint) Planning Meeting. 
  • No routine: The Daily Scrum does not happen at the same time every day. (While routine has the potential to ruin every Sprint Retrospective, it is helpful in the context of the remote Daily Scrum. Think of it as a spontaneous drill: don’t put too much thought into the Daily Scrum, just do it. Skipping them can turn out to be a slippery slope: if you skip one Daily Scrums or two, why not skip four out of five?)

Conclusion

Daily Scrum events — remote or not — are essential to a team’s self-organization and, consequently, its ability to achieve the Sprint Goal. While the first phase, the 15-minute time-box, is relatively straight-forward, the second, the problem-solving phase requires more effort on the side of the moderators, the Scrum Master or Development Team members, in a remote setup. Nevertheless, given the right level of training and support, also the second phase can be fully embraced by a distributed Scrum team. 

What kind of a remote Daily Scrum event have you supported? Please share it with us in the comments.


Further Reading

Remote Agile (Part 1): Practices and Tools

Remote Agile (Part 2): Virtual Liberating Structures

Remote Agile (Part 3): Mastering Zoom

Remote Agile (Part 4): Anti-Patterns

Remote Agile (Part 5): Retrospectives With Distributed Teams

Remote Agile (Part 6): Sprint Planning With Distributed Teams

Remote Agile (Part 7): Sprint Review With Distributed Teams

Topics:
agile, daily scrum, distributed agile, distributed agile teams, liberating structures, scrum, stand up meetings, tutorial

Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}