On the agile-usability Yahoo! group, someone asked about tools to mitigate the consequences of having an off-shore team doing some of the work. I have strong feelings about this.
I’ve seen lots of tools/techniques tried for this.
But it basically comes down to this: as a team, if you are not all colocated in an effective team room, you are going to take a hit in productivity. That hit averages out to about half the productivity level. Everything you do to mitigate this by alleviating the communication difficulties will only get you up to that half-way point. Any desire to get close to the productivity levels of a colocated team is bound to be frustrated.
On the other hand, if you don’t have colocated teams now and if in fact your “teams” aren’t really teams, then putting in some good communication tools can help increase your productivity. Whatever your current state, you can make improvements. Focus your improvement efforts on two things: reducing the cycle time for communication, and improving the richness of the communication channels.
For offshore teams, high-speed access to the same work environment as the “onshore” team is critical (for software, this means code base, development environment, test environment, db environment, tools, etc.). If you have them on separate system (for example due to paranoia about data going outside your company), then getting them on the same system as your onshore guys is going to result in a big improvement. This is a way to improve communcation that for some reason is often overlooked.
If your offshore team is on the opposite side of the earth, then you are going to have to stick mostly with “batch” communication. Every day, a batch of questions, requests, comments, feedback, etc. is going to be batched up by one group or the other and there will be a 24 hour lag time in responses. If you are doing two-week iterations, this is 10% of your time (!!!) just to do what might be a very simple communication. Compare that to people sitting beside each other who might be able to have the same exchange in 15 seconds. If it’s a tough problem, the batching will make this lag even more pronounced. (BTW, some off-shore companies offer people who will work the night shift in order to be available to your team. I ask a simple question: would your on-shore team be willing to work the night shift? Hopefully you can guess my feelings about this practice from that question.)
So, if you are early on in adopting agile methods, I strongly recommend that you don’t use your offshore resources. If the organization insists on paying for them, then let them sit idle. Yes, that’s right: IDLE. Your on-shore team will probably be more productive without them.
If you have lots of experience with agile, then do the experiment: find out if it makes sense. But make sure you have a good way of measuring productivity so that you can tell if the cost savings are worth the hit in productivity.
If the bulk of your team is offshore, and you simply don’t have the expertise on-shore, then send a couple of your customer/business/ requirements experts over to stay full-time with the off-shore team. This is often worth it.
And of course, if you just can’t do it any other way than the “standard” split on and off shore teams, then make the best of it by constantly trying new ways to communicate. The guidance that Martin Fowler gives is sound, and everything else is left up to you to discover based on corporate culture, resources available, etc.