The global collaboration perspective on software development is a stark contrast to the preference for face-to-face communication during development activities.Steve Bate · February 10th, 20182 min read
You should expect to see developers putting on headsets when they start up their development tools - to listen and respond to the voice over IP (VOIP) chatter from peers and delegates spread across the world. Development is now, by default, a global activity (and, as a sidebar, has begun looking like a massively multi-player on-line game (MMOG)).
— Jonathan Schwartz
The global collaboration perspective on software development is a stark contrast to the preference, or requirement for some, for face-to-face communication during development activities. I also prefer face-to-face contact although I’ve seen distributed teams be very effective with intelligent use of tools like email, instant messaging, web-enabled project planning and tracking applications, phone and video conferencing and so forth. Distributed teams also work best if most, or all, of the players are good communicators. This is a risk since many software developers don’t have strong communication skills.
I’ve see this work best when the team has worked together face-to-face for at least several months or invest in significant amounts of travel early in the project to achieve the same effect. I’ve only had experience with distributed teams within the U.S. so I’m not sure how it work in a global setting. Implicit communication through shared mental models may not be so effective across cultures.
Alistair Cockburn’s paper describing software development as a cooperative game is also relevant.
I would like you to consider software development as a cooperative, finite, goal-seeking, group game. The goal is to produce a working system. The group, or team, consists of the sponsor, manager, requirements or usage specialists, software designers, testers, and writers. Usually, the goal is to produce the system as quickly as possible, but there are other factors that affect the time goal: ease of use, cost, defect freedom, and liability protection. In general, it is a resource-limited game, which affects how the moves are made.
— Alistair Cockburn
To be successful as a distributed team, we must learn the rules (guidelines) of the game. Most rules are not absolutes, so we must learn when to apply specific rules and what tradeoffs we are making when a rule is applied. The rules are somewhat different for distributed teams than for collocated teams. For example, active communication becomes more important in a distributed context. A developer who silently waits to be queried for information will represent a risk for a distributed team.
Can a distributed team of great developers can outperform a collocated team of mediocre developers, assuming they are both using agile development techniques?
I’d bet on the distributed team if they are skilled with collaboration tools and communicate effectively. The distributed approach can work well, with many examples from the open source software development community.
However, for some developers to be successful at distributed development they will require additional education and applied experience beyond what they have needed for collocated teams.