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