I’ve been meeting people who call their teams distributed. But their teams are dispersed. That is, some team members are in one place, and some team members are in another. In the worst cases, there are separate people all over the world.
For example, if you have cross-functional teams in Boston, Chicago, San Francisco, and Bangalore, you have 4 distributed teams. If you have 4 teams, each with 2 developers from Boston and Chicago, a BA from San Francisco, and a tester from Bangalore, you have dispersed teams.
You’ll have the same number of people with different results. The dispersed teams will take longer to create deliverables of sufficient quality to use. Not because they aren’t capable, just because the time difference creates delays in finishing work.
We see examples of successful dispersed teams all the time–open source projects are a prime example. But if you have a short schedule, distributed teams are better than dispersed. And, co-located teams are best, assuming you have schedule constraints.
I’ve been working with programs of people who have dispersed teams all over the world. Those people are finding it quite difficult to be agile, because the dispersal creates a systemic obstacle. I’ll get into that more later.
