Skip to main content

Using an Agile Software Process with Offshore Development

Popularity Report

Total Popularity Score: 0
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Rank

Related Lists

Bookmark History

Saved by 10 people (-3 private), first by anonymouse user on 2006-09-06


Public Sticky notes

So far we've discovered that we can make it work, although the benefits are still open to debate.

Highlighted by dserebren

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

Highlighted by dserebren

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)

Highlighted by dserebren

Use Continuous Integration to Avoid Integration Headaches

Highlighted by dserebren

Everyone has been delighted with how well this works. Its main benefit is that problems that plague other groups with integration just don't happen to us.

Highlighted by dserebren

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. 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.

Highlighted by dserebren

st too. Continuous Integration requires good connectivity, often better connectivity than people are used to.

Highlighted by dserebren

Have Each Site Send Ambassadors to the Other Sites

Highlighted by dserebren

From the beginning we decided to ensure that at all times there was someone from the US team present in India to facilitate the communication. Such an ambassador already knows the US based people and thus adds his personal contacts to help everyone communicate.

Highlighted by dserebren

We found it useful to send a US developer and a US analyst to India to communicate on both technical and requirements levels.

Highlighted by dserebren

One of the benefits of a business-oriented ambassador on the offshore team is that it helps provide business context to the offshore team.

Highlighted by dserebren

An important part of the ambassador's job is to communicate gossip. On any project there's a lot of informal communication. While much of this isn't important, some of it is - and the trouble is that you can't tell which is which. So part of an ambassadors job is to communicate lots of tidbits which don't seem important enough for more formal communication channels.

Highlighted by dserebren

if an ambassador spends too long abroad they lose contact with home

Highlighted by dserebren

rotate the ambassadors every few months (and in some cases every few weeks)

Highlighted by dserebren

Much of a project manager's job is to help resolve conflicts and flush out problems before they become serious. Experience working on both side of the telephone line is really important for them to do that effectively.

Highlighted by dserebren

Use Contact Visits to build trust

Highlighted by dserebren

vital, but not enough

Highlighted by dserebren

Ambassadors are

Highlighted by dserebren

You can think of two kinds of contact visits: seeding visits

Highlighted by dserebren

maintaining visits

Highlighted by dserebren

It's important for seeding visits to be working trips, since the whole point is to get people used to working with each other, so they should be arranged around some joint task.

Highlighted by dserebren

primary purpose of the visit isn't to do the task, but to the build the working relationships.

Highlighted by dserebren

keep the work pace relaxed

Highlighted by dserebren

Dinners and sightseeing can often be the most useful activity that the visitors do with the hosts.

Highlighted by dserebren

It is important to get seeding visits in as soon as you can.

Highlighted by dserebren

get the developers, or at least the senior developers, together to build the first few iterations. It's in these iterations that the crucial architectural decisions will get made

Highlighted by dserebren

Don't Underestimate the Culture Change

Highlighted by dserebren

Beware that polite acceptance is often a sign of an important issue not getting discussed.

Highlighted by dserebren

The bad news for this is that getting teams to be more pro-active is an uphill battle, and one that inevitably takes a lot of time. You can never assume that problems will be raised, even when they are spotted. Getting people used to a distributed control style of management takes longer than you think.

Highlighted by dserebren

Use wikis to contain common information

Highlighted by dserebren

someone needs to act as a gardener to make sure it doesn't get overgrown.

Highlighted by dserebren

Use Test Scripts to Help Understand the Requirements

Highlighted by dserebren

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. 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.

Highlighted by dserebren

Use Regular Builds to Get Feedback on Functionality

Highlighted by dserebren

Use Regular Short Status Meetings

Highlighted by dserebren

Time zones are often the biggest problem here

Highlighted by dserebren

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. 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.

Highlighted by dserebren

We've found that it's a good habit to start conference calls with chit chat on local news.

Highlighted by dserebren

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.

Highlighted by dserebren

At ThoughtWorks almost all projects use iterations of one or two weeks in length.

Highlighted by dserebren

Use an Iteration Planning Meeting that's Tailored for Remote Sites

Highlighted by dserebren

When Moving a Code Base, Bug Fixing Makes a Good Start

Highlighted by dserebren

Separate teams by functionality not activity

Much of the traditional thinking on the onshore/offshore boundaries is based on the activity that people do. So analysis and design is done onshore, construction done offshore, and acceptance testing is done onshore. This obviously fits well with the waterfall model.

We've found that contrary to this, matters improve when we make the offshore team handle as many activities as possible. So we prefer to see them do as much analysis and design as possible, subject to the limitations that the requirements are coming from onshore.

Highlighted by dserebren

grow the analyst part of the offshore team

Highlighted by dserebren

Expect to need more documents.

Highlighted by dserebren

Documentation, however, becomes more important with offshore development since the face to face communication is reduced. This work is, in a way, a waste since it wouldn't be needed if the whole team was co-located. But given the offshore model, you need to do them - so they are part of the price of doing things offshore.

Highlighted by dserebren

There are two keys to successful documentation on agile projects. The first is finding the point of "just enough" documentation. This is difficult to determine and will vary by project. Fortunately, the iterative nature of agile development allows you to experiment until you get it right. The second key to successful agile documentation is to not get attached to it or have unrealistic hopes of keeping it updated. Documentation must be created to serve a specific purpose, and after it has served that purpose you'll all probably have more important things to do than keep updating the documents. It may seem counter-intuitive, but it's often better to produce fresh documentation the next time some is clearly required. A side benefit of starting over each time you need to document part of your project is that it's great incentive to keep your documentation efficient!

Highlighted by dserebren

Get multiple communication modes working early

Highlighted by dserebren

We've found a lot of value in video presentations. Short lectures about the background of the project that can be recorded and sent over to the remote team.

Highlighted by dserebren

They aren't so good for details, but work better for a broad picture.

Highlighted by dserebren

Email can often be a mixed blessing. In particular we've found that it's good to discourage person-to-person email in favor of broadcast newsgroups or mailing lists. It's too easy for a piece of information not to go to someone who needs it, or be unable to find it. By posting messages and requests in a newsgroup, everyone can see the messages and it's easy to search. People find it easy to skip over threads that they aren't interested in.

Highlighted by dserebren

Costs and Benefits of Offshore Development

Highlighted by dserebren

Most people in the software industry know, or should know, that productivity differences between developers are far greater than salary differences - and even the rate differentials offered by offshore aren't necessarily greater than that. Offshore work also introduces extra costs and risks that may offset the rate differential.

Highlighted by dserebren

Of course a high ceremony organization that uses documents as the primary communication mechanism will not suffer as much from this. Essentially their communication has already taken all the damage from lack of direct contact, so the offshore effect is less notable.

Highlighted by dserebren

Another benefit of offshore that's coming up is the use of 24 hour development to reduce time to market. The benefit that touted is that by putting hands on the code base at all hours of the day, functionality gets written faster. Frankly I think this is a totally bogus argument, since I don't see what adding people does in India that it wouldn't do by adding them to the onshore team. If I need to add people, it's more efficient to do it while minimizing the communication difficulties.

Highlighted by dserebren

The nugget in the 24 hour development idea is that despite the tech slowdown it's still not easy to get talented developers. So often you can't get enough talented developers in the onshore location, so an offshore team is valuable for their talent rather than any lower cost.

Highlighted by dserebren

The Future of Offshore and Agile

As I write this, offshore development is very fashionable, but it's still too early to really understand its true strengths and pitfalls. Certainly anyone doing it because they think they'll get cost savings similar to the rate differences is seriously deluding themselves.

Highlighted by dserebren