A popular theory holds that team members need to get to know each other socially through "Forming, Storming and Norming" before they can get to "Performing." You can blame this theory for a lot of silly team building exercises. It leads people to believe that they need to have an expensive and delay-inducing meeting before their distributed team can start performing.

Fortunately, an observation of high-performing teams shows that this theory is backward. Actually, people like to join teams where they can get to work and achieve a goal. Later, after they see they have been "performing," they start to feel very warmly toward their fellow teammates. According to team expert and Harvard professor J. Richard Hackman: "The cause-and-effect is the reverse of what most people believe: When we're productive and we've done something good together we feel satisfied, not the other way around."

Why is it better to start with performing and get to bonding later? Because people want to do a good job. They spend a lot of time at work, and they don't want to waste that time. They don't actually need peer pressure to want to do a good job.

Your distributed team can be a high-performing team even if they never socialize together. Socializing is nice, but it's nice because it makes people feel good, not because it makes them more productive.

Wisdom of teams

In the book "Wisdom of Teams," McKinsey consultants Smith and Katzenberg observed that:

• High performing teams always have a shared goal. They organize around the shared goal.
• Teams can be high performing even if they don't meet and work together, and even when they don't like each other. Smith and Katzenberg found that this was true even in the 1980s when remote workers were connected only by big, heavy telephones. And Hackman says that teams will perform better if they have a "deviant" - the annoying guy who brings up opposing viewpoints.
• "Team" organizations have rotating leadership. For example, a software team might find that a designer is leading at the beginning, while a programmer with architecture skills steps forward to get past a difficult technical hurdle, and a DevOps person takes charge to get everyone working toward reliable deployments.
• "Single-leader" organizations have one person who tells everyone else what to do. Single leader organization work great when the leader knows exactly what to do. But team organizations adapt to change, which is a key objective of Agile projects. If you value the team organization, you will let people step forward from any location, rather than assigning roles by location.

So successful groups start with a goal, make progress toward the goal, then bond into a team. You can help your distributed teams follow these steps.

If you have a lot of opinion-based arguments, political lobbying and factions, you probably lack a strong shared goal. Politics emerges in the absence of the pressure of a shared goal. When people come under pressure to achieve clear goals they become more focused on facts and will agree more.

Shared values?

It is nice if your team shares some values about collaboration and productivity. However, sharing isn't essential, and it can come later in the process. You do not need to force people into a group value system. During World War II the Americans and Soviets didn't share many political values, but because they shared a goal they teamed up into a mighty fighting force. The people that make an iPhone make a beautiful product efficiently. They live in the US, Japan, China, and many other countries. They live in mansions, boats, and dormitories. Do they share values? I doubt it. They don't have to. They share a supply chain.

Productivity comes from shared GOALS, not shared values, and from a process that is structured to allow people to do their jobs separately yet work together. As long as they share a goal and have room to work, they can ignore each other's values. If you are going to insist on shared values, you are going to have a very short supply chain - probably just 5 or 10 people sitting around a campfire singing Kumbaya. That sounds like a Scrum team! Make people more productive, and you can go global.

Retrospectives and happiness surveys

To start the cycle of success, you will need something like a supply chain. You will need a process that works to deliver a great product. How do you get a process that works? Get feedback from your team members.

In traditional Scrum, you do a "retrospective" after each sprint where the team talks about what went right, what went wrong, and what should be done differently in the next sprint. This is a powerful tool for improving your process and making sure that it constantly adapts. However, it can also be tedious work.

A "happiness survey" is a similar idea that can be applied to more cases (including continuous delivery) and that requires less meeting time. I got the idea from Henrik Kniberg and Jeff Sutherland. A happiness survey only takes a few minutes to fill out, so you can do it during any cycle. It uncovers a broad range of improvement opportunities.

A happiness survey can be conducted through an online form or spreadsheet (e.g. a Google spreadsheet) with the following fields:

• Name
• Happiness Rating (1-5)
• "What feels best right now?"
• "What feels worst right now?"
• "What would increase your happiness?"
• Other Comments

After you conduct a happiness survey you will be under pressure to act on the results. If you don't act, people will see the survey as a waste of time and your happiness initiatives will die an unhappy death.

There is also a risk that people will write complaints of the "life sucks and then you die" variety. You can't prevent that. However, I am usually very happy with the results of this type of survey. People write in about specific problems, with actionable suggestions. Most of the time they suggest ways to improve productivity. This goes to prove that people are highly motivated to do a good job.

I like the happiness survey better than a traditional retrospective for two reasons:

1. Traditional retrospectives have a tendency to drone on, become boring, and end without reaching conclusions. A happiness survey is more bounded. The team and team leaders only need to address issues that were mentioned in the survey.
2. Traditional retrospectives are dominated by the most vocal members of the team. These are not always the most careful observers. With a happiness survey everyone can make an equal contribution, and some of the less vocal team members contribute good points.

Private language

One sign that you have a high-performing team is that they develop their own language. I worked on a team that built around a source code system called SourceSafe, which they called "SourceCow" for its plodding ways, and then just "the Cow." Pretty soon everything was named as some sort of cow. Those guys herded a lot of cows very effectively. So it is a good sign if you drop in on a team and can't understand what they are saying.

Crossing cultures

I often get asked if my team suffers from problems in communication caused by cultural differences. For instance, "Yes I can do it" might mean different things to people from different countries. However, I rarely if ever see that problem. All of the members of my team are culturally similar. They are geeks. They are engineers. They focus on facts and they quickly decide what they think is achievable or not achievable. They may feel awkward in their home countries, but they are at home on our team. They have a nature that is more powerful than their nurture. If you think a shared culture is important, then your recruiting process - how you select people - will be more important than the locations that you recruit in.