I’ve coached and served as scrum master for dozens of remote teams over the years. In light of current events, I’ve posted a collation of the notes I have for helping distributed teams working effectively.
The rule is, if one person on a team is participating from a remote location, the team is a distributed team. Making distinctions such as “distributed team” vs. “fully distributed team” when some or all members of the team are working from remote locations risks marginalizing team members who are working at locations away from the home or central office.
To help ensure that the concept of “team” remains intact during distributed team conditions, this post is intended to serve as a guide for scrum masters for how best to facilitate and monitor team interactions and performance with distributed teams.
Scrum masters have the added burden of developing the skills within their teams for effective distributed team collaboration and communication. Distributed teams can function better than collocated teams when the team’s skills for organization and communication have been improved by necessity such that they are better positioned to function effectively as a team.
Even with ideal conditions (i.e. plenty of bandwidth for audio and video, intra-team familiarity, clear agenda, etc.) working with distributed teams will always have a degree of asynchronous communication. Fields of vision are limited to what’s in frame for the video camera, network latency issues, and a general lack of access to in-person non-verbal cues will cause people to speak over and interrupt each other and miss-read intent more than they would during in-person meetings. To mitigate these constraints, it is important to have a well understood and practiced set of etiquette rules for distributed team meetings.
- The principle challenge is to keep everyone on the team focused. Shorter, more frequent meetings are better than long meetings that invite participants to “multi-task” out of boredom. Invite essential people to the meeting. Use of a responsibility assignment matrix is a very useful tool for determining who to invite. People associated with the “consulted” or “informed” roles generally don’t need to be invited to formal Scrum meetings.
- Communicate an agenda – however sparse – prior to the meeting. Let the team know what the purpose and objectives of the meeting are so everyone knows when they are done. Agendas are scope management tools and help keep the meeting focused. Set the expectation the everyone on the team will be aware of the agenda prior to the start of the meeting.
- Ensure that all the necessary equipment is in working order and that all team members have verified connectivity. Test screen sharing capabilities and application accessibility prior to the meeting.
- It is preferred that the scrum master host the on-line meeting so that on the rare occasion they may need to take control of the meeting by muting or bumping someone from the meeting they may do so.
- Set the expectation that team members will participate from a location that is free from background noise and other distractions. Joining from coffee shops or while driving is to be discouraged as they end up being distractions for the entire team.
- Coach the team for how to take turns in a conversation.
- Coach the team on how to use any mute features.
- The rules of common courtesy apply to on-line meetings. If we wouldn’t accept a behavior in a face-to-face meeting, it shouldn’t be accepted in an on-line meeting either.
- Turn off notifications from applications such as email and instant messaging.
- Meeting participants need to be aware of what’s in the visual and auditory background and work to anticipate and mitigate potential interruptions.
In-Progress Meeting Activities
- Continue to stress that team members be on time for the meeting. Set the expectation that they will join on-line several minutes early to accommodate any last-minute technical issues.
- Meetings serve both a practical and social purpose for distributed teams. Allow time for casual conversation (and still expect everyone to be one time) as it is critical to building and maintaining rapport among distributed team members. Small talk, catching up, sharing interesting news bits, interesting (short) stories – any of these helps make the on-line meeting a more enjoyable experience and help set a positive tone for the duration.
- If a team member joins a meeting late, they should not announce to the team they have arrived. Doing will potentially disrupt a conversation already in progress.
- When a team member needs to contribute to a conversation while others are talking, the best approach is to state, “I have a comment.” or “I have a question.” and then pause. This serves as a signal to the team that you wish to speak. Either the conversation will naturally break, or the scrum master can listen for a break and offer the team member the opportunity to speak. The natural in-person behavior is to simply start talking. With distributed teams this frequently leads to several people talking at once and a degradation in communication.
- Ask for the opinion of someone on the team who has not yet participated in the meeting or has been silent for a period of time. This will help keep them focused on the meeting if they know they may be asked a question.
- Team members should leave a comment in the meeting chat window if they need to step away from the meeting for a short time or leave the meeting. Announcing such departures tend to be disruptive, but the team will likely need to know if any team members are not absent from the meeting.
- Remain attentive to anyone who is dominating the conversation or otherwise preventing others from contributing.
- For stand-ups, call out the person who is going to start the conversation. Assign that person the task of choosing the next person to speak and so on until everyone has had their turn at contributing. This will help keep each team member’s attention as they will not sure when they will be called on. Similarly (but less desirable) randomly call on team members and vary the pattern day-to-day.
- When conducting a meeting where only one or two people are attending remotely, ensure that both the conference room and the remote individuals are using video. This will allow for additional non-verbal cues to be included in the communication and help keep the conference room aware that one or more of their team members is attending remotely.
- Leverage chat for one-off conversations or bringing non-priority items to the host’s attention
- If video is in use, be aware of the need for patience when waiting for network latency to catch up with any shared screens.
- Start the meeting with everyone on video. After a few minutes for casual conversation and catching up, allow team members to switch off video to reduce bandwidth issues.
- Provide a recap of what was accomplished and identify any of the goal or agenda items were not addressed.
- State any next steps.
- State any action items and the names of people responsible for completing them. Action items without assigned names are in-action items.
- If a member of the team has a pattern of responding to questions with some version of “I didn’t understand the question. Can you restate it?” or they have to be prompted with “Are you there?” due to a non-response, there is a likelihood that they are not focused on the meeting and busy with something else. If the pattern is persistent, the scrum master will need to discuss this with the team member off-line.
- Be attentive to the introverts on the team and work to have them contribute to each meeting. Ask them for their opinion or any open-ended question that has more than a yes-no answer.
- The metrics a scrum master may use to assess team participation and performance will need to be more robust than the usual data-based and subjective measures. Assessing morale or the presence of intra-team conflict may not be as apparent with distributed teams. Scrum masters may need to meet virtually one-to-one with each of the team members more frequently and asses any time management or morale issues.
How to Collaborate Effectively If Your Team Is Remote by Erica Dhawan and Tomas Chamorro-Premuzic
SwiftFest Boston ’19: Remote Connections: Fostering Relationships in Distributed Teams
Photo by Tanya Nevidoma on Unsplash (Edited)
There is a story about a bunch of corporate employees that have been working together for so long they’ve cataloged and numbered all the jokes they’ve told (and re-told) over the years. Eventually, no one need actually tell the joke. Someone simply yells out something like “Number Nine!” and everyone laughs in reply.
As Agile methodologies and practices become ubiquitous in the business world and jump more and more functional domain gaps, I’m seeing this type of cataloging and rote behavior emerge. Frameworks become reinforced structures. Practices become policies. “Stand-up” becomes code for “status meeting.” “Sprint Review” becomes code for “bigger status meeting.” Eventually, everyone is going through the motions and all that was Agile has drained from the project.
When you see this happening on any of your teams, start introducing small bits of randomness and pattern interruptions. In fact, do this anyway as a preventative measure.
- One day a week, instead of the usual stand-up drill (Yesterday. Today. In the way.), have each team member answer the question “Why are you working on what today?” Or have each team member talk about what someone else on the team is working on.
- Deliberately change the order in which team members “have the mic” during stand-ups.
- Hold a sprint prospective. What are the specific things the team will be doing to further their success? What blockers or impediments can they foresee in the next sprint? Who will be dependent on what work to be completed by when?
- Set aside story points or time estimates for several sprints. I guarantee the world won’t end. (And if it does, well, we’ve got bigger problems than my failed guarantee.) How did that impact performance? What was the impact on morale?
- During a backlog refinement session, run the larger story cards through the 5 Whys. Begin with “Why are we doing this work?” This invariably ends up in smaller cards and additions to the backlog.
There’s no end to the small changes that can be introduced on the spur of the moment to shake things up just a bit without upsetting things a lot. The goal is to keep people in a mindset of fluidity, adaptability, and recalibration to the goal.
It’s more than a little ironic and somewhat funny to see autopilot-type behavior emerge in the name of Agile. But if you really want funny…Number Seven!
The dialog about the value of stand-up meetings is as vigorous as ever. I hope it never gets settled. That’s because I frequently argue both sides. Just not at the same time. Which side I’m on depends entirely on the context. If the team composed of a single functional domain that has worked together for an extended period of time while co-located in a tuned collaboration work environment, then stand-ups of any frequency are probably a waste of time. If the team is for the most part remote and composed of independent contractors representing multiple functional domains, than it can be argued that daily stand-ups become THE most important scrum meeting.
I want to talk about the latter scenario in this post. Remote stand-ups can be the most challenging meetings for a scrum master to facilitate. (In the interests of space, I’ll have to set aside cultural and language issues that are frequently an issue while running scrum with remote teams. I do this not to minimize the importance of these issues, but to recognize they are worthy of much better treatment than I can cover here.)
Remember the agile manifesto? The first two line read:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
Simply stated: Don’t bother taking notes during a stand-up. Not as a group, anyway. Individual agile delivery team members are certainly free to do so if it helps their individual efforts. Stand-up notes are a false crutch. It’s as near to a 100% guarantee one can get to say that no one will every go back and re-read stand-up notes. If someone is demanding stand-up notes be taken, suspect a waterfall zombie in your midst and respond accordingly. Worse yet is that the poor agile delivery team member tasked with serving as scribe is going to be so busy trying to capture stuff they will miss much of the conversation and information exchange that makes a quality stand-up so vital.
- Early in a project the scrum master should specifically call out team members during the stand-up and do so in a different order each day. This will prevent team members from talking over one another as they miss the visual cues that tell people meeting in person who is likely to speak next. Changing up the order keeps the whole team alert as they will not know when their name will be called. As the team gains experience with each other, switch to calling out the name of the team member who’ll kick off the stand-up conversation. When they’ve completed informing the team what they’ve worked on yesterday, what they’re working on today, and anything in the way of success the delivery team member calls out the next team member to take the conversation. This will further develop the remote behaviors that compensate for the missing non-verbal communication.
- At least once a week, more frequent if warranted, briefly reiterate the sprint goals and minimum viable product (MVP) definition at the start of the stand-up. I’ve also found it very effective to challenge the team about mid-sprint with an intuitive check on how they are doing with respect to the sprint goals and MVP definition. Any feelings of dread there? Any sense of anxiety? If so, what’s causing that feeling. Move down the 5 Whys path to find any root causes. This will help shake out any hidden dependencies or reluctance by any one team member to ask for help.
Consider quality virtual meeting hardware and software an essential tool for your business. We wouldn’t accept a surgeon who goes into the operating room with kitchen knives because they’re “good enough.” Sound professional, be professional. Clear and efficient communication is essential to the success of remote agile teams. Have the best possible communication tools available in place and cut corners someplace else.
- A good view of the scrum board via web conferencing. This is the big picture the team needs to keep their individual efforts in context of the whole sprint effort.
- A high quality and reliable audio connection
- How each team member’s cell reception? Does their connection drop frequently? Is their voice muffled or otherwise hard to hear? They may need a phone upgrade, particularly if their phone cannot leverage WiFi calling.
- Are they on a land-line?
- Are they using a cordless phone that’s subject to interference or cuts in and out?
Scrum mastering remote teams demands an extra set of skills than those required for co-located teams. The non-verbal cues we’ve learned growing up and throughout our careers are often not available with remote teams. Consequently, we have to train our ears to listen more attentively and follow-up to verify any assumptions regarding meaning from conference call, email, or instant message communications.
As scrum masters, we also need to coach team members to deliberately introduce practices that accommodate the lack of non-verbal cues during scrum meetings. For example, there are two practices I implement during remote stand-ups that facilitate the feel of co-located stand-ups.
- I call out the name of the team member who’ll kick off the stand-up conversation. When they’ve completed informing the team what they’ve worked on yesterday, what they’re working on today, and anything in the way of success the delivery team member calls out the next team member to take the conversation. I’ve found this keeps the rest of the team focused on the conversation better as they won’t know when they’ll be called. Everyone will have to track who has already presented to the team. In the past I would randomly call out names until everyone on the team had their chance to speak. While they didn’t know when their name would be called they could still count on me to make sure everyone had their turn. Frequently, however, I’d have to call out a name several times to get that person’s attention away from whatever it was they were “multitasking” on. Having the team call out the next person to present has helped resolve this issue.
- After the team member has presented and before they pass the conversation to the next team member, I coach them to pause and ask if there are any questions from the team. In addition to signaling the end of their presentation, this makes the remote stand-up a little less mechanical and puts the thought “Do I have any questions?” in the minds of the rest of the team. More specifically, I coach the team with some version of the following: “Pause after your presentation and ask the team if there are any questions, observations, suggestions, comments, or clever remarks.”
Using techniques like this with remote teams does not replace the richness of co-located scrum meetings. They do, however, move the two a little closer.