Offshore Development and Active Software Process
Introduction
 
As the active manifesto states "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." One of the fundamental tenets of any active software methodology is the importance of communication between the various people involved in software development. Extreme Programming emphasizes this with its practice of a single open development space where the team can work closely together. Cockburn's book spends a lot of time talking about the importance of physical proximity in agile methods. Furthermore agile methods put a large premium on improving communication through face-to-face communication.
 
Offshore development seems opposed to active development in a couple of ways. For a start it immediately goes against the notion of physical proximity, since by definition offshore developers are a long way away. Secondly most offshore organizations favor the plan-driven approach where detailed requirements or designs are sent offshore to be constructed. A trend that's been grabbing the software development world recently is the move to offshore development, where much of the development work is done in lower paid and more cost effective countries. 
 
 
Integration
 
 
Continuous Integration was the earliest XP practice to really take hold at Thought Works and we've become so accustomed to it that we were determined to use it with our offshore development. So from the beginning we've put everyone on a single code base, with Cruise Control running to both build and run tests. This way everyone is kept close to the mainline, whatever their location happens to be. And it was effective. It's generally accepted practice that if you commit changes to the mainline, you should not go home until you have received the email message from Cruise Control that says that your changes resulted in a successful build. A late night bad build is much more serious when the remote office is running off the same build. Cruise Control's web page allows all sites to see what's going on abroad. First thing in the morning you can check the Cruise Control web page to see what changes have been made by the other sites. It provides an easy way to catch up on what's going on at the other end of the world. This does require good build discipline, where developers strive hard not to break the build, and fix it immediately if it becomes broken.
 
 
Communication
 
 
In general we keep the build servers in the same site as the majority of developers, but remote sites can find it takes an annoyingly long time to get a fresh update from the mainline. The longer the communication lines are, the more they are prone to anything from glitches to lines being down for a while. Although world-wide Continuous Integration is resoundingly popular, we have run into some problems. Communication pipes aren't as wide and reliable as we'd like, so many source control operations can get awkward from a remote site. All of these issues would mitigated by a clustered code repository, but we haven't experimented with anything like that yet.Having the repository accessible 24 hours makes it annoying to take it down to do backups. 
 
Experienced staff
 
 
The experiences here are based on work done over the last few years by Thought Works. So the fundamental question is whether agile techniques can be used in an offshore setting. If so how does it compare to using an plan-driven methodology (the term I'll use here for non-agile)? This essay describes some of the lessons we've learned so far.
 
As a result we have a very talented group of developers with a mix of experience levels. It's worth talking a little about the way in which we've setup the Bangalore office. We expected the office to be used primarily as an offshore development environment, so we recruited mostly application developers. The majority was hired directly out of college and we seasoned the mix with some more experienced developers. At the beginning we brought over several more experienced US and UK developers, to mentor the newer developers on both software development and the agile/XP practices we've come to enjoy. It was very important to us that we retained our very high hiring standards (typically we only offer jobs to about 1 in 100 applicants), and we continued the model in India.
 
 
Conclusion
 
 
You'll need to build good test doubles for these services so the system can be effectively tested in the development environment. We have found that some source-code control systems are particularly prone to long and painful check-outs - particularly if they are not configured well. It's worth spending time on finding ways to speed up check-out times, and indeed changing source code control systems if you're stuck with one that doesn't handle remote working very well. Continuous Integration requires good connectivity, often better connectivity than people are used to. Interestingly people assume that these communication problems are specifically a problem with a remote site like India - but we've found problems often occur with the infrastructure in the west too. Even with the best connectivity, however, there can be problems if a system requires services that are locked inside an onshore firewall. Hope, everything will be solved with proper communication.