Few suggestions for an effective Offshore Development

On an agile project, the close proximity between customer and developer allows the customer to monitor progress much more frequently, which allows them to spot misunderstandings more quickly. Furthermore a partially developed system can also educate the customer, for often there's a difference between what's asked for and what's needed - and usually that's not apparent until there's some working software. When people consider the requirements gathering in agile methods, they often fail to see the importance of the feedback loop. Often the requirements process is seen as analysts providing requirements, which developers go off and implement. At some later point somebody checks to see if the developers have implemented what they were asked for.

Make sure the environment is sorted out early, and ensure someone is around to fix any environment problems if they appear. There's nothing worse than onshore people pulling down a build, finding problems, and the offshore people being unable to duplicate the problem due to environment configuration issues. Having regular integrated builds allows a US customer to pull down last night's work and try it out. While this isn't quite as immediate as co-location, it still allows the customer to correct any misunderstandings quickly; as well as allowing them to refine their own understanding of the requirements. To make this work, it's critical to sort out the environment issues so that you properly duplicate the environment on both sides of the ocean.

Often people like to wait until something is finished before showing it to others. In these situations, however, it isn't worth the wait. Scrum has long advocated that the development team does a demo to the customers at the end of every iteration. We've adopted this practice pretty widely now - we call it a showcase. Make sure people look at what's built regularly, even if it's only partial functionality. The quicker someone looks at a piece of work, the quicker they can spot any miscommunication. With remote teams we like to do a remote showcase, where the offshore developers show the new features in the software with the help of remote desktop software. Getting the remote team to do this is another example of taking every opportunity to build links between offshore and onshore, and between developers and customers.

Regular Meetings

In our more recent projects we've made a greater use of the wiki, and this has reduced the need for cross-shore stand-ups. Now we do stand-ups within a shore's team, but not between the different shores. Agile methods promote regular short status meetings for the entire team. Carrying this over to remote groups is important, so they can coordinate with other teams. Time zones are often the biggest problem here, particularly between the US and India where any time is awkward for somebody. In our earlier projects we found that twice a week stand-ups seemed to work well and provide enough coordination.

We do however do daily cross-shore meetings, but these don't involve the entire team - just those who focus on the cross shore collaboration.

With small teams, however, we do do the cross-shore stand-ups. We've found that it's a good habit to start conference calls with chit chat on local news. Recent odd bits of local color - politics, sport, weather - helps each side get a sense of the broader life context on the other side of the wire.

One of our clients would only do the calls during their business day, which forced the Indian folks to come in at very awkward hours. With time zone problems it's important for both sides to give and take in picking the time for calls. Pushing the entire onus on one side to accommodate isn't helpful for smooth collaboration. This lack of knowledge, or consideration, runs into other areas as well. Fortunately we were able to convince them to change the date. Even in less serious cases remember that holidays are rarely shared, so you'll often get times when one team is in holiday mode while another team is in a regular work week. One project scheduled a major release during the Indian holiday of Diwali, which is the equivalent of asking an American team to working over Thanksgiving.

Remote Site's Iteration Planning Meeting

A remote team adds its own set of constraints, particularly when you have awkward time zone issues. However despite the pain of awkward meeting times, we still find the IPM to be extremely useful. On most of our projects we've found that a planning meeting at the beginning of each iteration that involves the whole team really helps to get everyone coordinated on the next chunk of work. Before the IPM the US customer sends narratives for each scheduled feature (story) which we like to turn into test scripts before the IPM. During this period any questions are handled by email. Just before the IPM the development team breaks the features down into finer grained tasks. These task breakdowns are shared with the US for feedback. This kind of self-adaptation is an important part of agile processes. All of this pre-work shortens the phone call which now concentrates on any issues that come up from the task breakdown. We find the calls usually last around a half to a couple of hours. It is important to keep the actual phone meeting short, as these kinds of remote meetings are particularly arduous.

Wikis to store common information

Wikis work well because they are simple to use, can be worked with any browser, and are simple to set up. We've played around with various ways to hold common information, our favorite so far is a wiki. Any common information can be put there, story cards, design guidelines, and build instructions, notes on progress - anything that needs to be written down for reference by the team. We've found it's very useful to use the change notification capability that many wikis have, so that page changes trigger notifications through email or an RSS feed. Wikis are by nature unstructured, and this lack of structure is part of the benefit. The team can usually evolve their own structure on the wiki as the project grows. This does mean that someone needs to act as a gardener to make sure it doesn't get overgrown.

Test Scripts to Recognize the Requirements

More mature XP teams use acceptance tests as ways of communicating requirements. With greater distance, you need to put more ceremony into communicating requirements. We've been able to do that while still sticking to many of the techniques that we use in single-site development. Such teams get test scripts written out before the start of an iteration to help clarify the requirements and give the development team a concrete target to aim at. This can be done either for automated or manual testing, although we very much prefer automated tests. As the scripts are developed the US and Indian analysts coordinate by email and IM as well as regular (2-3 times a week) conference calls to review the test scripts. One style that's worked well is for a US based customer to write a short narrative (a couple of pages) to flesh out a feature (story in XP lingo). An Indian based analyst/tester then creates test scripts for this story.

The developers find it easier to ask questions of the Indian analyst rather than dig through the test scripts, so having an Indian analyst/tester is still important. Search engines are good, but humans are often easier to work with. We've found that this has very much helped both the Indian analyst and the US customer really understand the requirements. Writing out the tests forces the Indian analyst to really understand what's needed and to ask questions of the US customer as questions turn up. The biggest problem we found with this technique is to engage the client staff in doing it. As a result on the majority of projects we haven't been able to do it - but when we have we've found the approach valuable.

Short Iterations

A few of the more experienced Indian developers have worked at places which use two to three month iterations and they report that the shorter iterations are much better. At Thought Works almost all projects use iterations of one or two weeks in length. A couple of years ago our distributed projects tended to prefer two week iterations since they found it was difficult to use shorter iterations, but this has changed. Now we've learned how to do one week iterations comfortably on a distributed project. In general agile methods use shorter iterations than a lot of other iterative approaches.

Have a nice time!