BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Agile 2016: Communicating and Collaborating - How Distributed Teams Can Thrive

Agile 2016: Communicating and Collaborating - How Distributed Teams Can Thrive

Leia em Português

This item in japanese

David Horowitz and Mark Kilby presented at the Agile2016 conference on how distributed teams can thrive. The premise of their talk was that distributed teams need to be connected, and that while face-to-face is important for collaboration, it isn’t as important as connectedness.

They described three types of distributed teams:

  1. Satellite - one or a few working remote, the rest in the office
  2. Clusters - sub-teams in different locations
  3. Nebula - everyone is spread out

They suggested that in order for distributed teams to thrive, each member should have a safe way to contribute. They described three ways that distributed teams develop safety when using distributed communications.

  1. Always have a chat channel as a back channel - There is always another avenue to contribute or ask questions, even in a meeting. This back channel can be anything from text messages, instant messages, chat functions on the virtual conference tool, a wiki, slack, or even snapchat. It is a safe way for introverts to contribute, as well as remote members to ask questions or make comments without interrupting. 
  2. Buddy up - Each remote person has a buddy in the main room. When using the back channel, the buddy represents the remote person to make sure their contributions are heard, or points out to the facilitator that the remote person is trying to chime in and contribute.
  3. Co-Pilot - Someone in another location that can help the facilitator coordinate the whole team. They watch body language, etc. Clusters might have a co-pilot at each location.

David and Mark facilitated a Marshmallow Challenge to magnify the challenges and results of distributed teams, and they pointed out ways to fix them.

There was one very interesting twist in the session. When building the spaghetti towers, participants were forced to organize themselves within the conference center into one of the three models (Satellite, Nebula, or Cluster) and build the tower using distributed models of communication. Many participants considered the project a massive challenge! 

For example, one group was assigned the Nebula model of team structure. The group members did not know each other before the session. They quickly self-organized, and decided to use a login of one of their web conferencing tools as their communication platform. They dispersed throughout the building with a URL for the instant meeting set up. One person stayed at the table with the spaghetti, tape, string and marshmallow kit to be the builder. The group proceeded to IM one another, using the video tool to show sample drawings, and chatting through ideas to build the tower together. The frustrations of being distributed were more than magnified! But remarkably, in 20 minutes, they had built a standing tower! 

Next Mark and David facilitated a retrospective of over 100 people. Here are the results of the main learnings that 20+ tables came away with:

Overall Learnings:

  1. Someone has to be focused on the communication aspects of the team and each meeting.
  2. Knowing each other personally helps immensely. Take time to do silly things, to laugh together and keep it fun; it goes a long way.
  3. Check in with those that are absent or offline. “Is everything okay, I noticed you were offline or not engaged?"

Detailed Learnings from All Three Team Types (Satellite, Cluster, and Nebula):

  • For the most part, the safety process worked to give everyone a way to chime in.
  • Their strategy as a team had to adapt, and they had to communicate and rally around ideas quickly, accepting that not everyone was fully on board.
  • Sometimes the team got caught up in the tools and forgot to revert back to basic communication methods.
  • Tools have a learning curve. Most are easy once demonstrated or established, but can be a major challenge when in fire drill mode and no time to ground themselves and learn the tool.

Satellite Team Model - Top Learnings

  • Team needs to make extra effort to include remote people. Remote people often checked out.
  • Took too much time discussing which tools to use. Waited until too late to test and found critical defect.
  • When stress kicked in, it is easy to drop the buddy plan.
  • The buddy in the main room had to sacrifice their own role to keep their remote buddy engaged.
  • Remote team member had to force themselves to stay engaged. It’s extremely easy to check out and multi task.
  • Remote team member made up a fake birthday to get attention from the team and get engaged.

Cluster Team Model - Top Learnings

  • Build team in the room became too engaged and ignored the advice of remote team.
  • Feedback loop was missing or latent. Build team moved on before feedback came.
  • Video was a helpful tool, but communication was biggest challenge.
  • The team had a vision, but then different locations split and adapted their ideas of the vision as the deadline approached.

Nebula Team Model - Top Learnings

  • The team became distracted by tech and needed to go back to the basics. Learning curve to get up to speed was higher with everyone relying on tools.
  • Tools used impacted results. Surprised that one team member quit and checked out completely.
  • With tool stress, there was a shift to antiquated communication system, and it worked!

 

Guest editor Angela Wick is an Agile Coach and Trainer, she is the Founder & CEO of BA-Squared, LLC a training and consulting company that helps organizations modernize requirements practices. She helps traditional, agile, and hybrid teams develop the skills they need to build the right solutions that deliver the intended value to the organization.

Rate this Article

Adoption
Style

BT