At SD West last week, I sat in on the Agile — With or Despite of Global Development roundtable. While traditional agile development (as you might see in XP or Scrum, to some extent) recommends small teams that sit together, many organizations and projects are larger, with team members in multiple locations.
This separation makes producing software more difficult. (That’s one of the reasons agile development tries to keep team sizes small and everyone together.)
The most important question of the whole discussion was “How do you measure the effect of distributed development?” I assume that there are business reasons to split a project among multiple sites. If it’s possible to measure producticity at all, it should be possible to measure the productivity on a colocated project against the productivity on a distributed project.
The room’s assumption seemed to be that distributing a project has a cost in productivity. There were plenty of anecdotes. Yet without measuring this against the benefits of distributing a project, it’s difficult to analyze distributed agility.
There are plenty of potential issues when attempting to work on the same project with a distributed team:
- There may be cultural boundaries and friction. For example, one participant mentioned that a team composed mainly of developers from another background tended to participate en masse in meetings that would normally only involve a few people. Why? Their culture tends to value physical demonstrations of support and solidarity.
- Teams may have different levels of skill and experience. It’s much easier to train people to your coding standards and the history of the project in person. It’s very difficult to do so remotely.
- Different timezones can increase the latency of communications dramatically. If you had to wait a day for an answer to a question, you might program very differently. (Another participant suggested that his team set aside that particular feature of a story until they could get a definitive answer from their remote customer.) Of course, timezone differences can be a benefit, as with people who need flexible schedules (or people who want to come in early or late to avoid bad traffic.)
- Sharing status and other knowledge that’s almost implicitly available in a shared workspace is much more difficult. It’s possible to do this electronically, but that adds some overhead. It’s probably worth it, though. To some degree, most of the successful teams communicate more strongly through unambiguous means–such as automated and executable tests.
Some of the participants reported successes, however. It takes a good team, a budget to fly people around often, and even possibly some luck. Modifying agile practices to reflect agile principles and values seemed very common.
