Training

Ironically, the most often forgotten item is training. This is perhaps because within a co-located development team training just “happens.” Even new teams members get one or two days of orientation (“this is your CVS login”); the rest of the training happens in the daily interactions with the rest of the team. When dealing with a remote team, this just won't work.

Even minor changes to the requirements, the GUI or (especially) the architecture requires that the remote team be formally trained. This includes preparing written materials and a formal slide presentation or some other means of conducting a sequenced training session. There are products out there to do remote whiteboarding, and they work more or less well, but it is still best to have the material written ahead of the presentation.

The training session itself is very different from one with everybody sitting around the same table. For one, the presenters must constantly check for understanding.

Depending on the presenter or the communication lines (voice and data) or even as a side-effect of accents, it may be difficult for the remote team to follow the presentation, but out of politeness they may say “yes” when they really should be asking for clarification. Particularly when there are more than one presenter, any time they speak over each other, the remote team will most likely not be able to follow both speakers; they may politely complaint the first few times, but after a while it just gets tiresome and they'll let it go.

It is up to the presenters or, better, a trained facilitator to make sure that these obfuscations don't happen. If they do happen, a facilitator will catch them and make the presenters backtrack for the benefit of the remote team.

For the initial training and other major changes, it is best for someone from the team that originated the changes to travel to the other facility to do the training in person. For an offshore facility this may be expensive to do, particularly if it wasn't accounted for in the budget, but not doing is asking for trouble. The easiest way to end up with a failed project is to allow misunderstandings about major changes, say, in the architecture of the product.

Travel »