Stone Age Project Teams?

Like everyone else in the industry, our team has embarked on the adventure to adopt a variety of agile practices over the last couple of years. First, we picked up scrum and started to develop features in iterations (despite our still waterfall like release model). After a few projects with scrum, many members of the team took up test driven development. After a lot of stumbling, we started to wrap our minds around TDD and writing good unit tests. Now, we have some team members that want to adopt pair programming. Yes, I'll admit that I'm not a huge fan of pair programming but I tried a couple of sessions with a few different people. The whole time I couldn't get over the biggest problem that I've found with pairing and that's the need for a team that works the same hours and is preferably co-located. In today's world of globally disperse teams, it seems wrong to sell people on the need to adopt a coding practice that requires a team from the 20th century.

I have a lot of friends that work as engineers of various types for manufacturing companies and they seem to provide a good roadmap for business as a whole. First, they faced the increased labor costs by sending out the tedious piece work to other countries with a cheaper labor market. As manufacturing learned to cope with this global product development process, additional pieces were moved over - advanced assembly, tech support and even engineering. Today, the large manufactures may have engineering teams in Europe and the US design a product that's built in Mexico and China and finally shipped to a customer in South Africa.

This is the kind of model that we need to get to with software and the pair programming camp has some good intentions but the wrong answer in the end. Instead, we need to start adopting a more social development pattern where we can clearly communicate with each other in asynchronous ways and accept feedback on our designs, code and ideas. Being more social instead of leaning on pair programming will enable companies to hire regardless of the geographic area and still produce a successful product at the end of the day. For proof that this model can work, we just need to look at the various open source projects. Each of them is leading the charge for better tools and working through the organizational issues that having a very distributed team offers. Despite time zones, geography and even language, these projects produce high quality software the the modern world depends on. There's no denying that this model has great success and I'd like to see the agile camp work through some of the cons instead of continuing to promote the ineffective technique of pair programming.