On a distributed Scrum project, 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.
Tags: distributed teams
Thanks for this tip Mike. I agree members of distributed teams should do their best to spend time face to face early in the project.
When people ask me how to develop teamwork and trust on distributed teams, my first tip is this: Learn to reliably build teamwork and trust on co-located teams. Why? If you can’t do it there, no collaboration tool or technology will magically do it for you in a distributed team.
The issue is that most people don’t have any kind of reliable framework for building and leading teams. It is not the same as project management. But it is semi-predictable.
I’ve found a framework that helps build teams near or far. I call it the Team Orientation Process (TOP). It is based on—and leverages—the science of group cohesion (i.e., what brings people together). Here are the first few steps:
TOP Pre-Step: Assume personal responsibility for the success of the team. It matters not your role on the team, the more members who feel a sense of ownership for the entire team, the more likely good team-building things will happen.
TOP Step1: Build shared clarity about the task (and keep pointing to it as the reason for the team). This is the single greatest lever for team-building. Feeling a sense of positive interdependence (i.e., you moving your work forward helps me accomplish mine) or “being in the same boat together” drives a natural shift in behavior toward helpfulness and trust.
TOP Step 2: Discover personal motivations toward the task (beyond a paycheck). “Win/Win” is a common cliche about teamwork because it is pivotal. So the #2 lever for team-building is to discover the “what’s in it for me” for each member. Don’t be afraid that the answer is “nothing.” If that is true then they would not be there. You can’t support team mates in winning if you don’t understand what a win is for them.
TOP Step 3: Make and keep agreements. This is the #3 lever that builds cohesiveness. A few healthy operating agreements create the “fabric” for team flow. And making and keeping agreements is a solid recipe for building trust.
These are the big 3 levers I encourage you to learn and use to build any team any time. There isn’t anything fancy or terribly subtle about them, Just straight-forward conversations and dialogs that you can have anywhere and anytime.
Hi Christopher–
Thanks for sharing this. TOP sounds like a great idea. I’ve done something like this rather intuitively but it is fantastic to see the steps formalized as you’ve listed them here.
One thing I love about your TOP process description here is the early emphasis on the task. I’ve never been big on artificial team-building exercises (“Fall backwards and we’ll catch you…”). I read a research paper by Lynda Gratton of London Business School that said that the best way to build a cohesive team was to focus early on the tasks and to save the team building stuff for later. If teams do too much socializing / team-building early on, they tend to form subgroups based on superficial commonalities. If the team holds itself accountable early on for completing some work, team members learn about each other’s skills, passions, and so on. They can then form subgroups around these more meaningful commonalities.
I like how I see how this can work with your Team Orientation Process (TOP). Thanks.
Hi Mike,
Thanks. Your intuition was on-target.
The team-building industry began in the late 1940’s and 1950’s. It focused on research findings suggesting group cohesion is a function of “liking” or mutual appreciation. The Myers Briggs Type Indicator (MBTI) was published in 1962 and became the standard for “team building” interventions. The assumption is that if we can understand each other better then we can appreciate each other better and “come together as a team.” This style of team building has been a blessing and a curse. The curse is that it doesn’t focus on the reason for being a team.
Better research tools in the 1970’s and 1980’s showed another variable to be a better predictor of group cohesion than mutual appreciation. That variable is “outcome interdependence.” Simply put, if my preferred outcome depends on cooperating with you, then I’m more likely to do so. This is what I refer to as “shared task clarity” or getting in the same boat together.
Hence, the single most powerful device a team builder has available is her ability to maintain a dialog with team members around this question: What must we do together that is bigger then any of us, requires all of us, and none of us can claim individual victory until it is done?
I’ve been teaching the TOP to team leaders and members for almost 20 years. It’s in my book “Teamwork Is An Individual Skill”
Hi Christopher–
Thanks for pointing this out. I didn’t know when the team-building industry began but this history makes sense. I like also your question for team members to maintain a dialogue around.