Thursday, April 05, 2007

An offshore agile success story

In a previous post, I briefly mentioned the success my team had applying an agile approach on an offshore project. Here is some more about what we did that worked well for us.
In agile methodologies, a co-located team is critical to success - a prerequisite, some would argue. But what if you're stuck with a geopgraphically distributed team? Even worse, what if part of the team is offshore, 15 time zones away, it's members a part of a very different culture, and their English comprehension is limited? Is it possible to be agile in this situation? If so, how?

This is the situation I faced on my recent project. The onshore (US) team was colocated with the customer, and consisted of a project manager, a business analyst, and 2 architects/senior developers. The offshore contingent was located in Hangzhou, China and was a team of 8-10 developers and testers.

The project: build a leading-edge video streaming application using linux, MySQL, Java, javascript, and a few other technologies (Perl, PHP) thrown in for good measure.

The result: we delivered a high-quality application on time, to rave reviews from end users.

How did we make offshore agile work? To some extent, by being less agile, and less offshore. Here is how we organized the project for success.

  • Bring your offshore team onshore and have a single colocated team - at the customer site - as early as possible, and for as long as you can. We had our entire China contingent onsite for 3-4 months at the beginning of the project.
Note: obtaining visas can be tricky. We used B-1 visas, although we were pushing the limit on what can be done with B-1's. H-1B and L-1 visas are possbile in some cases. J-1 visas are another option, and there may be organizations that can help you arrange these. BoldTech worked with CAST, the Chinese Association for Science and Technology USA, to obtain L-1 visas for some people.
  • Share the vision. The entire team should know and be continually reminded of the vision and road map for the project. What is the end goal? Who are the end users? What are the key features in the next release?
  • The offshore team participates in - and drives - demonstrations to the customer. Delivering potentially shippable software each iteration has a very tangible meaning to developers if they know they will be personally demonstrating it to the customer. We got lax on this and stopped doing it after the team went back to China - looking back I kick myself for not making it continue.
  • Send US team members to your offshore location. Do this as often and for as long as you can. When the developers returned to China, I spent 4 months in China as the team lead, and brought my family with me. It's hard to find people willing to take that assignment, but you can send various US folks on a rotating basis for shorter visits if that's the best you can do.
  • Sufficient analysis and documentation. Once the offshore team was offshore again, scribbling a few notes on a note card wasn't sufficient to communicate requirements. The developers comprehension of spoken English was limited, so thorough requirements documentation became very important. And unless you like to answer the phone at 3 am to answer questions from China, I recommend that you have good-enough documentation. We combined screen mock-ups, narrative text, and use cases, as appropriate for each feature / user story.
  • Online collaboration tools. We used XPlanner, Mantis, and Mediawiki. For meetings and communcation, we liberally applied phone calls, web conferences, IM, and email.
  • Shift work schedules so working hours between locations overlap
  • Adjust your communication style. Listen closely to a conversation between two native English speakers, and you'll quickly learn that a huge proportion of what we say is idioms, expressions, and sayings. "Are we on the same page?" "Don't go down that rat hole." When you're talking to folks from China, you can't talk that way. Slow down, use common, simple words, and avoid the idioms.


Amit said...

Excellent points. Get their heads in the game is so important with an offshore team. Often they work in what seems like a vacuum to them. Getting team co-located seem to mitigate a lot of the problems. One problem I find with communication is that a lot of good material gets lost in the phone-call, IM and Email space. Lately, I have looked at project management software such as Basecamp which seems to address a lot of issues for geographically distributed teams. Keep it together in one place as much as possible.

Anonymous said...

How did you integrate XPlanner with Mantis? We currently use Mantis and i would like to bring in some XP tools such as XPlanner.

Brad Swanson said...

Peter, the integration between xplanner and mantis was rather loose, just using xplanner's wiki-style linking mechanism. Within xplanner items, we could enter something like "mantis:1234" and xplanner would automatically create a link to mantis issue #1234. I don't remember if that's the exact syntax but you can read about the feature here:

Brad Swanson said...

One more comment. I've since used Scrumworks - the free version - and for the most part I prefer it over xplanner, mainly because it allows you to drag-n-drop stories and tasks to reorder them or move them into/out of the product backlog. I don't think the free version of scrumworks has a integration/linking feature simliar to xplanner's wiki-style linking, however.

Ronan Rodriguez said...

Getting group co-located seem to minimize a lot of the issues.I discover with interaction is that a lot of excellent content gets missing in the phone-call, IM and E-mail area.