The last few large projects that my team and I have worked on have involved the use of offshore development resources as a supplement to the onshore (stateside) development team. I can see why companies lean toward the relatively economical pricetag of offshore developers, but the results I’ve seen are so varied that I’m still not convinced that this approach is for everyone, despite the fact that the industry seems to be rushing headlong in this direction.
Back in 2006, Martin Fowler published a good article on how to make the most of your offshore development resources here. In addition, Stephanie Moore, Liz Barnett, and Kimberly Dowling have collaborated on a well thought out article on how to leverage Agile processes and offshore development resources effectively. Despite the dates on these articles, I think their points still hold, but in cases where my teams have had the most success, I’ve noticed some distinct trends. In addition to the advice given in the articles above (and the advice of others too numerous to list…just go a google’n) I’d add (or re-inforce) the following:
Present Governing Principles Up Front –
Fowler and others warn us to expect to have to prepare more documents…but we don’t have to go to extremes. For maintenance tasks, you’ll already have an architecture. For a large, ground up build, you will likely have front loaded pattern selection and general architectural principles as high priority, high cost work items for early sprints…either way, your architect will likely have an inkling of system tiers, principles governing separation of concerns, etc. Share these in a web conference up front as development kicks off so that onshore and offshore are on the same page as to the guiding principles that will covern development. This includes coding standards, FX Cop settings, rules for source code check-ins, etc.
Allocate offshore devs by concern
This is where I’ve seen a lot of offshore projects fall down. Onshore project managers and tech leads leave the resource allocation tasks to an offshore coordinator, or worse yet, chance. It’s your money so ask for the resumes of your assigned offshore resources and subdivide them by area of expertise appropriate to the tiers or functional areas of your application. This builds offshore expertise and responsibility in specific, traceable areas. The three people working on the services tier of your app become experts in the services tier and suddenly any integration problems or code quality issues are immediately traceable to 3 people rather than 10-15. Stove-piping development where offshore resources implement a task stretching from data to UI leads to you having to develop a soup to nuts understanding of a large system with a remote group of people across a communication barrier.
Take advantage of the 24 hour development cycle -
While others have written on the challenges of Agile development with offshore teams (good examples can be found here, here, and here), several projects I’ve worked on have suffered through long onshore design cycles, perhaps with the development of a small amount of functional (concept demonstration code). A great pile of documents is then fired across the sea, only to come back (accompanied by a pile of code) 4-6 weeks later. Consider the workload implications for this approach. First, your offshore team sits idle for the first design iteration and is blind to the process, missing out on valuable team interaction during requirements discussions, design pattern decisions, etc. Second, once the offshore team is done, the onshore team must interrupt their design or development efforts to integrate and QA/QC the code delivery coming back, further idling offshore until onshore gets back to development. Why, as a company, you would not leverage a 24 hour dev cycle is beyond me. First, if you’ve got 5 onshore devs and 5 offshore, from a schedule and throughput perspective would you want 10 people working 8 hrs on a task each day or would you want 5 of them to work 8 hrs for awhile, and then let the other 5 work on it for 8 hrs for awhile? Use offshore as your “second shift”. Second, if you’re a successful agile team, would you throw it all away just to get a few more devs? Didn’t think so… Besides, leveraging the 24 hr development cycle opens up a door to another point…
The Offshore Sprint is 1 day -
Irregardless of your onshore agile process and format, confine your offshore sprints to the 24 hour period. You are effectively running a sprint of sprints in this case but let’s consider the main advantage of doing this. Continuous integration…when using a 24 hr dev cycle, offshore’s work is checked into source control and ready for review when your onshore team logs on at the beginning of their day…or shortly thereafter. Working in this scenario, I was able to review the previous night’s code, do an automated build, and verify/integrate everything during the first hour of my day. Why?..small bites. I could then mop up outstanding tasks and continue with the work items for my portion of the current sprint (ours were 4 weeks). The last hour of the onshore team’s day is verifying buildable code, checking everything in to source control, and assigning/documenting offshore tasks for the evening sprint. We did almost all of our instruction and tasking via work items with a quick email summary of the workload each day. You’d be amazed at how much get’s done this way! You also identify trouble spots and weak links in the chain very quickly.
Use common source control –
You and your offshore team should be on a common source control platform. If you are not, you should at least have a plan for automating rollovers of the source at the end of your day to offshore, and back again at the end of their day. This cross-product syncing can be tricky, but some products like Star Team offer a cache server that can be configured to sync the source at configured time periods. This allows you to all work on an integrated source tree and prevents reconcile and merge nightmares. The worry of stepping on each others toes between source sync operations should be minimal since you’re working in opposing shifts.
Schedule “Adapt and Change” Meetings -
Whatever process you put in place for working with offshore, semi-monthly or monthly con calls with the teams are a good idea. These meetings are used to summarize overall progress and discuss any changes that need to be made to your dev process and offshore interaction model. Your quick sprints with the offshore team are going to reveal holes and areas for improvement very quickly and you’ll need to adapt your process to keep things running smoothly. Be sure these meetings are bi-directional…allowing and empowering offshore developers to make comments on what does/does not work reveals an interesting perspective that can often result in important process improvements.
