Back in December I was invited to visit a Silicon Valley start-up to review their software architecture and website design. I'll just refer to them as Startup. We spent two days walking through their prototype reviewing usability and performance.

One of the more interesting aspects of their software was that Startup had used off-shore staff augementation to develop the initial prototype. I recognize off-shoring software development is an emerging trend, and wanted to learn more about their experiences for better or worse. I've successfully coordinated virtual teams in the U.S. and was looking forward to an opportunity to see if the same strategies could be successfully applied to off-shore projects.

Startup had used the prototyping process to test out three different development teams, two in India and one in Russia. Having divergent teams work on the prototype was evident in the end result, functionality was duplicated and the architecture was inconsistent. For example, three different search mechanisms had been implemented.

Performance was poor. One page used AJAX for a partial page refresh of 500K worth of data.

Of course, these are the same types of results I would expect if you put three on-shore teams from different companies together on a project with little cross-team communication. Startup had been successful in finding which of the three companies they thought would be best suited for on going work.

Now we embarked on the rigorous process of revamping the prototype for usability and a scalable architecture. We agreed that I would provide architectural guidance, a member of Startup would do database design, and Team Off-Shore would do the grunt work of wiring things up. This sounded great to me, since I prefer the architectural work to writing lots of boring if-then clauses.

However, there are some big caveats to working with any remote team.

1) Experience Matters

Everyone has to make sure they check-in working and complete code. When this doesn't happen in an office, it's fairly easy to go over to the junior programmer desk, kick their chair and say, "You forgot to check-in the database change scripts!".

When the person you are coordinating with has a 12-hour time difference, and they are asleep, it means the rest of the team needs to reverse engineer and rewrite the missing database scripts. This pretty-much blows the cost savings of the off-shoring. The larger the timezone difference, the harder to recover from this type of error without duplicating hours or days worth of effort.

2) Design for Success

Developers work best when then understand the product vision or corporate mission. Specifications have to be very detailed. Its far easier to cooridinate enhancements on an existing well-defined product than on something which is literally in Startup-mode.

Startups by their nature need to be flexible and able to create features very quickly. Having a centralized team for this is faster, and improves the creative exchange. If we fail to communicate anything about design changes to the off-shore team at the end-of the day, they could be going in the wrong direction for a day before we woke up to communicate with them in the morning.

3) Communication

Teams still need to discuss things. Here again, the time barrier is a huge inconvenience. The U.S. team winds up calling India late at night. 8:30 AM in India = 8PM Pacific time = 11PM Eastern time. Having 3 coordinating calls a week to discuss progress, is a lot of overhead when they all happen fairly late in the evening.

While I am still a fan of virtual teams, I have learned that experience, design, and communication escalate non-linearly as the time differences between locations grows. This means managers need to put in even more effort before projects start to mitigate these risks.

Now, I have to go see if my database scripts have turned up yet...

Please post your comments on strategies for managing remote teams.

(The personal contents in this blog do not reflect the opinions, ideas, thoughts, points of view, and any other potential attribution of my current, past, or future employers.)
Copyrighted 2008 by R Wang & Michael Byrne. All rights reserved