Despite Collaboration Tools, for Teams, Location Matters

It’s conventional wisdom that the best productivity in software engineering comes from teams that work in the same location and in close proximity to each other. Indeed, the “Agile” community makes almost a fetish out of this.

Much of my past experience supports the proposition—I once gained an almost 100 percent productivity improvement amongst several hundred developers simply by moving them around so that team members sat next to each other and had a common, shared work area.

Cutting out “walk time” and getting decisions made immediately because everyone was readily available really made a difference in speed and quality.

Yet the inexorable march of global resourcing is making dispersed teams much more the norm. As we are forced to adapt our working processes to accommodate teams that aren’t within shouting distance, and can’t meet face to face (or even virtually, given time zone differences) to resolve issues, what do we lose in efficiency?

I have been looking at this issue for that past couple of months, analyzing performance data from a couple of thousand projects going back about ten years to the beginning of the shift away from co-location to dispersion.

I have approximately equal populations of co-located teams, lightly dispersed (where the development team is co-located, but not at the client) and aggressively dispersed (where the development team is split between three and five locations).

There are a lot of variables here (team size and experience, degree of dispersion, client attitude, application area, technology . . .) but after controlling for these, I found that there is a statistically significant difference in productivity between the three populations.

First the caveat: This is Systems Integrator data, not internal IT team performance, so there are already factors at work that impact productivity. I haven’t tried to control for these. With that in mind, however, here are the results.

Check out eWEEK.com’s for the latest news, reviews and analysis on IT management from CIOInsight.com.

The most productive teams were the ones located together but away from the client’s location. They benefited from consistent infrastructure, support and technology that wasn’t always available at the client site.

There was relatively little variation in productivity across this population of projects, even though the projects themselves varied quite a lot. Let’s use this group as our normalized baseline and set their performance at 100.

The next most productive group was co-located at the client. They lost several points of productivity because they didn’t have the same consistency of infrastructure, support and technology as the baseline group, plus they had “lifestyle” overheads—travel to and from the client, differences in working habits between the team and the client and so on. Their average performance index was 88, but the variation was quite large—between 60 and 102.

The least productive group was the aggressively dispersed. Typically, some members of this group were client-based, some were onshore and some were offshore, using e-mail, phone calls and video conferencing to coordinate the work. Their productivity index average was 62, but the range was very large (41 to 91) and there were significant time series effects.

In fact, each of the populations showed improvements in productivity over time. Practice, consistency and continuous improvement efforts clearly matter. The baseline group actually improved about 30 percent between 1995 and 2005.

The client-based group improved about 18 percent, but never did better, on average, than the baseline group. And the dispersed group improved the most—roughly 100 percent between 1996 and 2005—although significant infrastructure investments and process engineering improvements were involved in these gains.

For more on managing specific projects, check out eWEEK’s

If I look only at the 2004-2005 period, the gaps in average productivity are closer—100 to 90 to 78—and the variability is much reduced. When you factor in resource costs, the impact becomes significant—an issue I’ll look at next week.