Ambassadors and Carrier Pigeons was another session about ways and means of making distributed teams more effective.

• Distributed teams are frequently created from business constraints (e.g. low perceived cost of outsourcing, distributed expertise);
• It's best to avoid splitting teams by function (e.g. having testers in one location and developers in another);
• Challenges include being "out of sight, out of mind" with little tacit communication; having a product vision that evolves without being communicated across teams; and being reliant on documentation and technology;
• Cultural differences can include language barriers, varying expectations of appropriate levels of communication, cultural and linguistic divides, and in particular differences over the words "no" or "yes" - which can have opposite meanings in certain contexts. As an example, the speaker highlighted the lack of smalltalk before meetings in Israeli business culture, contrasted with the importance they place on eating together;
• Working across time zones can lead to staggered work days, times when the other teams are asleep and thus unavailable, and jetlag post-travel affecting performance;
• Cross-team dependencies can include shared components, collective code ownership (and how to manage code reviews), daily sync-ups, and cost/budget constraints;
• Deep specialists can be a problem: they're typically limited in number, localised, and be trouble to work with;
• The "Ambassador model" was suggested: using individuals to bridge the gaps between teams, having a single team member visit the remote location whilst serving on and acting for their original team; other models proposed included...
• "Touring rock star", typically a Product Owner/Manager who travels to share the product vision;
• "Visiting professor", a temporary team member taking a tactical role to bring a specific skill or serve a specific need;
• "Foreign exchange worker", swapped with a counterpart across teams; ideally an extrovert. This can be palatable from a funding perspective (no-one loses a member of staff), but works best with one person at a time moving (so you don't have pairs who are less inclined to socialise with their new teams);
• "Paratrooper", deployed to address a tactical issue and who gets in, fixes it, and gets out;
• The audience also suggested whole-team relocation (I brought this up, drawing on our experience) and the "whip cracker", who turns up to put the pressure on. A few raised eyebrows around that last one...
• We had a brief discussion around tools for collaboration... all the usual stuff, IM, videoconferencing, project management tools, engineering tools, testing, modelling, etc. I brought up something I noticed the guys do when Thom broke his ankle - having an open skype audio call to give a bit of ambient chatter between office and an out-of-office worker;
• Eclipse apparently has some pair programming tools; CodeStriker was also mentioned to help with code reviews;