The Real Problem with Distributed Teams

Photo by tamahaji

Photo by tamahaji

One of my Scrum Masters was inspired by Adam Weisbart's Agile Anti-Patterns presentation at the Scrum Gathering Paris and has shared many of the ideas in a workshop at his own organization.  Knowing that the topic can be sensitive, my Scrum Master explains that an anti-pattern does not mean that we are doing something completely wrong and against the agile principles because we are bad people--the truth is, we have good intentions and want to be successful in our work.  There is something about the anti-pattern that is appealing and may seem agile at a first glance.  But in the long-term, something about the anti-pattern is preventing us from becoming more agile, hence its name.

In the last workshop he gave, someone brought up that they are on a distributed team across timezones, which means they do not follow the below agile principle:

The most efficient and effective method of 
conveying information to and within a development 
team is face-to-face conversation.

Should we point our fingers and shame management for creating a distributed team that cannot possibly follow this agile principle?  I don't think so.  I feel empathy for the team because I know it can be incredibly hard to be successful with that kind of arrangement, but shaming someone and blaming them for an anti-pattern does not seem productive.  Especially because this person said they've found a way to work well together as a team--to create human connections across distance.

Last week one of my peers, Josh, gave a presentation on Distributed Agile Teams based on his recent experience as a Scrum Master for a fully distributed team (and I'm happy to say he'll be presenting on the same topic at DFW Scrum this month).  Another team has found a way to work well even though they are in different locations.  Should we tell them that it is an agile anti-pattern to have a distributed team and have management do something about that?  I don't think so.

The problem with most distributed teams isn't that they are unable to talk face-to-face; it's that something (or many somethings) is preventing them from following the below principle:

Build projects around motivated individuals. 
Give them the environment and support they need, 
and trust them to get the job done.

If the individuals are not motivated, if they don't feel like a real team, if they don't have the environment and tools and support they need, then they will not be successful.  Making a distributed team successful takes effort.  A motivated team with the right support will find a way to deliver results.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Achieving great team culture and communication in a distributed team

Guest post by my friend and coworker Jane Prusakova; read more on her blog at http://softwareandotherthings.blogspot.com

Photo by Jane Prusakova

Photo by Jane Prusakova

A distributed team faces many challenges that cannot be solved organically through face-to-face conversation amongst its members.  However, it is possible to have a highly productive remote, or distributed, team using technology and various remote communication channels.

Communication setup should be easily available and accessible for all team members.  It is helpful to have high-quality tools – broadband connection for voice and video, good speakers and microphones, large screens.  Conversations tend to flow a lot smoother when people can recognize who is talking by their voice and when face expressions are visible on video without a delay.  The teams should also pre-configure and test communication software and hardware.  Every person on the team should be able to initiate and participate in conversations as needed with minimal hassle.  Meetings that spend the first 15-30 minutes fiddling with software accomplish less and are filled with frustration.

Another good way to foster communication on a distributed team is to allow conversations to flow before and after scheduled meetings, just like they would for a group of people in the same room.  Have a meeting line started ahead of scheduled time and allow people to continue talking after official meeting is over.

When a distributed team consists of several collocated groups, take special care to avoid ‘US vs THEM’ terminology and mentality.   Make sure people from different locations get to work with each other, as well as with team members from their own location.  Inform the entire team of accomplishments of all the other team members, regardless of where they happen to be located.   Every successful team has its own go-to people who are experts in certain areas.  The distributed team develops its experts by distributing information about members’ skills and figuring out ways to work together remotely.

Finally, hold the members of a distributed team accountable for reaching out to their fellow teammates.  It is the responsibility of every professional to gather resources needed for doing their work.  That includes finding the right people to cooperate with, building good working relationships, and establishing effective communication.  Whether local or remote, every member of a team needs to participate in the team if the team is to be productive and successful.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Team Collaboration and Monkey Chatter

Photo by April

Photo by April

I overheard two testers who work on different teams talking the other day.  One defines tasks in sprint planning for creating test cases, executing test cases, and re-testing defects for each user story.  The other thought it was insulting to the developers to create a re-test defects task before defects are found.  Was it merely a difference in how they created tasks?  Apparently the teams are very different in how they collaborate.

The team that plans for defects upfront is not co-located--people are scattered in cubicles across two buildings--and testing does not happen until the code is pushed into their QA environment.  The team that does not plan for defects upfront is co-located, and the developers have the testers start reviewing the features early on in the development environment--defects are found and fixed earlier or avoided through conversations that clarify the user story because of the team collaboration that happens through co-location.  It reminds me of an article I read about monkey chatter.  Monkeys don't necessarily try to communicate certain messages to each other, but their proximity to one another allows for sharing of information [e.g. a certain sound indicates that a predator is near].  Co-located teams have more conversations because they can see and overhear each other; asking a question is seen as less disruptive because of the shared space.

Co-location makes a big difference in a team's culture, and it disheartens me that a team trying to be agile isn't pushing to be co-located.  Teams should be co-located as quickly as possible during an agile adoption--otherwise teams might get stuck in their "good enough" processes and take their distribution for granted and as unchangeable.  Leaders should map the office design to the culture they want because it can have a big positive impact.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Scrum teams need Scrum Masters close by

Photo by Soren Cosmus

Photo by Soren Cosmus

It might sound odd that the Scrum Master needs to be close to the team since seems like an obvious requirement (where else would he be, right?), but that isn't always the case when dealing with distributed team members.  According to the Scrum Guide, the Scrum Master's service to the Development Team includes:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Teaching and leading the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

The Scrum Master's job is more than setting up and facilitating the scrum events, and it's unfortunate when the value of the role seems to be diminished to those few meetings. The Scrum Master does not disappear during a sprint until impediments are raised, and his job is more challenging when some team members are geographically dispersed:

  • A Scrum Master spends time getting to know his team members individually and coaches each of them; this comes more naturally when a team is co-located, but the Scrum Master needs to find a way to do this regardless through phone calls, IMs, video conferences, and if possible, the occasional face-to-face meeting. 
  • A Scrum Master is encouraging the sense of team and self-organization; again, this is easier when the team is co-located, but activities that are inclusive and add play can contribute greatly to this.  I've heard of a team that would include a distant team member in office birthday celebrations via webcam just so he would feel like a part of the team. 
  • A Scrum Master is observing and listening to the team as it works so he can reflect back to the team areas where improvement may be needed so they can see them more clearly and address them. Probably the most challenging, the Scrum Master needs to have a trusting relationship with team members so they can have "how was your day?" conversations without fear of micromanagement. 
  • A Scrum Master is ensuring that information radiators are created and reflect the team's reality.  I love posters and scrum boards on walls, and these same radiators need to be made visible to those outside the office, whether it be through an electronic tool, video, or photos.

A Scrum Master doesn't just attend a daily scrum and remind the team to update its task estimates each day until the end of the sprint.  He has a serious job to do, and his team needs him to be close by--no matter how far apart they might be geographically.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Conflict in Virtual and Distributed Teams

Photo by Azri

Photo by Azri

My coworker Jane shared an interesting article on how to manage conflict in virtual teams that got me thinking about some of the challenges I've seen with virtual and distributed teams.  The article points out that successful virtual teams tend to have online discussion boards in an shared virtual workspace, which is probably quite true, but it implies that such tools are the key to avoid or manage conflict. 

Communication is the answer to avoiding or managing conflict, and an online discussion board is just one way for team members to communicate.  It's been said that software development is a cooperative game, so when team members are not collocated, cooperation is more difficult.  I encourage teams to use the richest synchronous communication tools possible because it helps to ensure shared understanding. It's quite easy to tell Team Member A to pick up the phone and call Team Member B who is hundreds of miles away instead of sending an email, but it won't work if Team Member A cannot make long distance calls from his desk and he does not have cell phone reception because he sits in the basement of the building.  

If you have a virtual or distributed team, make sure its setup for success by having the right communication tools available.  Conflict will happen in any team, and the ability to communicate openly person to person is the only way to resolve it.  Effective communication requires relationships, and relationships are built on regular communication.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.