I think we need to refine how we define teams and team members when they are geographically dispersed. The issue is how best to implement technical practices, work distribution, and communication among team members in different locations. A key Agile principle recognizes that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversations.” How does this apply in a world of distributed teams?
There are many successful implementations of projects where sub-teams are geographically distributed. What they have in common is that the sub-teams have 2-9 people who can work together in the same location. Successful examples (SolutionsIQ, Sutherland, Yap) show that teams/sub-teams in different time zones can deliver regularly with high quality. In most of the projects where teams have participated in remote pairing, the remote team has had two or more people in that location. If you have this situation, these groups should ideally be feature teams, where the group can deliver a complete feature with minimal integration dependencies.
Though remote pairing has been done successfully several times at SolutionsIQ, some of our strongest developers had a challenge with remote pairing. It should be pointed out that on the highest-performing distributed teams, team members start out working together in the same location for a period of time at the start of the project. This allows relationships to develop and norms of practices and behaviors to be established.
We continue to see challenges with scattered teams where individuals are geographically isolated. New technologies like desktop sharing and video (WebEx, Skype, Vuze, VNC, Join.me) help, but our experience shows significant challenges. Chief among them is that having people work from home, a classic pattern, leads to individuals delivering and maintaining expertise. This is contrasted with the team delivering, and sharing of knowledge and responsibility within the team. Individuals can still follow good technical practices like TDD and CI, but positive peer pressure is reduced. Code review and knowledge sharing has to be dealt with separately if pairing does not happen. Team estimation and team velocity are very difficult, and that leads to limitations on release planning. Demonstrations by remote team members are harder but possible. Product owners can ask questions and seek clarifications via conference call, but conference calls can easily become individual conversations. Most of the scattered teams I have encountered do not meet together on regular basis.
If you have remote individuals, then they need to be managed as individuals, not as a team. Wishing for team behaviors will lead to disappointment.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.