Build Trust Between Teams with Ambassadors

Distributed teams are a fact of life for many agile projects and are a particularly difficult agile project management challenge. The reality is that even when teams cannot be collocated, individual team members need to meet each other face to face. If the whole team cannot get together, one or two members from each team, at least, should spend time visiting team members in other cities. Think of them as ambassadors. I’ve found that the personal relationships established by ambassadors can be extremely valuable even long after the ambassador returns to native soil.

On one project I coached, for example, I had developers in Denver and Toronto. Teams in the two cities had been thrust together on a common project because of an acquisition, which initially had led to an unfriendly relationship between the two teams. Frank, a programmer in Denver, volunteered for a couple of two-week visits to Toronto. I knew the Toronto developers very well, having already worked with them for two years. I wanted to make sure we got the most benefit from Frank’s trips, so I talked with him about his hobbies and interests outside of work. When I discovered he was a rock climber, I contacted Marcel in Toronto, who was an obsessive climber. I asked Marcel to do me the favor of spending a little time with Frank, possibly setting him up with a guest pass to his indoor rock-climbing gym. Marcel very willingly did so, and the two of them became good friends and discovered they had other interests in common as well.

The budding friendship between Marcel and Frank served the project well right from the start. But it really paid dividends a few months later when a potential conflict started to emerge between departments on the periphery of our two-city project. The IT staff in Denver had named a server “Pandora” that would be used by the Toronto team. The Toronto team was furious over this and assumed the name had been intended as an insult because of the mythological story of Pandora’s box containing all the evils of mankind. I was in Toronto when the trouble started, so I asked Marcel to get Frank on the phone and to ask him if he would discreetly find out if the name had been intended as an insult. Two hours later Frank informed us that the employee who selected the name pulled it from a previously generated list of server names and had no idea who Pandora was.

Because of the trust built between Marcel and Frank, we were able to quickly defuse the situation. I write a great deal more about working with distributed teams in Chapter 18, "Distributed Teams," in Succeeding with Agile.

The Definitive Guide to the What and When of Product Owner Responsibilities

The Definitive Guide to the What and When of Product Owner Responsibilities

Sign up to get your free download below:



Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at If you want to succeed with agile, you can also have Mike email you a short tip each week.

The discussion here is closed but join us in the Agile Mentors Community to further discuss this topic.

Go to