#2782

A Field Guide to Team Distribution

This is a bit like the Scrum Bestiary minus the continual references to farmyard animals. Instead I’ll be using diagrams as a visual aid. Not as amusing but trust me I tried.

This is a work in progress and incomplete. I’m working on it as part of my talk on distributed agile teams at Agile 2009 and a possible updated version of the white paper. If you have any feedback on scenarios I’ve missed I’d be happy to hear them.

Here a collocated team is made of eleven members representing three different functions. The dotted line shows the team’s communication boundary. Orange lines on the diagrams below denote explicit lines of communication between remote teams or team members.

Partially distributed teams

Partially distributed teams superficially seem like they aren’t distributed but in fact are. Often they work in different parts of the same building and don’t share the same working hours. This leads to many of the same problems which face distributed teams.

The important thing about partially distributed teams is to recognize them and treat them accordingly. In some cases you may be able to remove some of the constraints that cause the team to behave as though it is distributed. If this is not possible then employ some of the strategies used by distributed teams.

Example: The team works in the same building and meets every day for standup meetings but work in different parts of the building, perhaps in different offices on different floors.

Example: Danny, the project’s senior tester, doesn’t like bright lights. He turns up in the team room at 5pm and works until 2am. This makes it difficult for the rest of the team to communicate with him.

Distributed teams

Some team members do not share the same working hours and/or working location.

Symmetrically distributed

The team is completely distributed, each member of the team is in a separate location. This means all communication happens over the wire although the team may get together for periodic face to face meetings.

In some ways being completely distributed solves makes distribution easier to handle as it avoids situations where some team members are better able to communicate. Because all communication takes place over the wire the team is completely reliant on the availability of communication bandwidth.

Example: Widgets.Com is a small startup and cannot afford office space. The four or five employees each work out of their own homes in different cities on the East coast. They communicate using phone, email, IM and video conferencing and hold all their meetings this way.

Asymmetrical distribution

Some team members share the same (core) location while others are remote, maybe forming sub groups or maybe isolated.

As the degree of asymmetry increases the communication problems increase. It’s too easy for remote team members to be left out of key conversations by the bulk of the team in their core location. When this is unavoidable there are strategies—like the team buddy—to help keep the remote team members from being forgotten.

Example: Jay is a developer on his team but relocated to Denver. He still works with his team in Boston but does so remotely.

Functionally distributed

The team is distributed by function. This model is quite common but has it’s own problems. It suffers from some of the problems of asymmetric distribution and also promotes the them-and-us or “throw it over the wall” mentality between different functional groups. The (agile) engineering team approach tries to avoid building walls which problems can be thrown over, and forgotten.

Example: The project team all works out of a single team room in England but their testing team is outsourced to an offshore team in Turkey. The two functions have to coordinate their activities across a two hour time difference.

Cross time zone distribution

Time zones should also be considered as they make communication harder. In the extreme, some team members may not share any working hours with other people on the team. If given the option opt for north-south distribution—with minimal time zones—over east-west distribution.

I’ll be discussing this further in a few weeks at Agile 2009.