By John P. Puopolo
In today’s business environment, there are many teams working in a distributed manner. It is certainly not unheard of to have developers in the United States, Europe and India coordinating on core development, testing, deployment, etc. With the globalization of companies, availability of low cost multimodal communication, and the continuing use of outsourcing, distributed teams are here to stay.
And they don’t work well for agile development.
What we have come to realize is that the true power of agile comes from the social and synergistic interaction among a group of individuals who act as a team. This synergy translates into the team becoming more than the sum of its parts. For this to happen, however, the individuals who yield some of their ego to the collective, and truly commit to the goal, can only do so when trust, respect, and camaraderie are alive and well. Experience suggests that teams can achieve this level of interaction, and subsequent uplift, only after social bonds have formed and are actively maintained.
What kills team effectiveness, especially on agile projects, is summed up in one word: separation. Separation comes in different forms, each having a negative impact on team dynamics:
- Proximity (same building but on different floors, or different buildings on the same campus)
- Geography (different cities, states, or countries)
- Time (a function of geography or work habits)
- Skill (senior developers vs. junior developers)
- Culture (Americans, Europeans, etc.)
When people are separated by even short distances, they tend to rely on communication channels other than in person.1 This means that people’s willingness to speak in person is somewhat inversely proportional to the distance between them. I believe there are many factors that influence this behavior including personality, laziness, and reliance on technology. You can see these forces at play when IM-ing someone across the hall or calling someone on the other side of the building. These types of interactions are perfectly fine in many situations, but are not robust or dynamic enough to be used by an effective agile team trying to deliver high-quality software.
When geographically separated, your only choice is to use dislocated communication – phone, IM, or e-mail, all of which are far less effective than talking in person. Part in parcel with geographic separation is that of temporal disconnection. It’s much more difficult, frustrating, and time consuming to work with colleagues several time zones away than it is to work with people on the same circadian rhythm. When separated by space and time, team members find themselves cramming meetings and conference calls into their days (for regular meetings, coordination, and side conversations), reducing the amount of time they spend producing shippable product. Managing distributed communications is pure overhead and results in low fidelity results. How many times have you been reading e-mail while “contributing” on a conference call where you are the only remote participant?
Another form of separation is that of skill. For our purposes, we can divide skill into two camps – domain knowledge and technical competency. When there is a significant divide among individuals along these dimensions, or within them, friction, misunderstanding, and miscommunication are inevitable.
Even though we live on "one small, blue planet that’s shrinking every day," we all come to the table with profoundly ingrained attitudes towards life, work, free time, money, productivity, interpersonal chemistry, family, and so on. People from different countries and cultures speak different languages natively, where context and subtlety convey deep meaning and are often lost in translation. To put a fine point on it, we must realize that there are inherent cultural dynamics that either aid or impede communication and understanding. The result: people from the same culture communicate more richly and effectively than those from different cultures.
With all of these forces at play, how in the world can separated team members communicate fruitfully and form the types of bonds required to reach enviable results? The short answer is that they can’t, since each separation factor multiplicatively impacts the positive effect that using agile development practices can have.
To illustrate, let’s take a fictional example of two Scrum teams. The first team is from Belgium. The individuals live in Ghent, speak fluent Dutch, work in the same physical office, and share core hours. The other team is made up of a balanced mix of Indians and Americans. The people on the American team are split between California and Boston, and the Indian team works out of an office in Bangalore.
It’s immediately obvious that the Belgian team has tremendous advantages – people can work side-by-side, communicate effectively from both the language and bandwidth perspectives, are on the same time rhythm, can quickly discuss an important topic on a moment’s notice, enjoy social assumptions, and have the opportunity to form relationships that will help support their goals. They laugh together, peer program, eat lunch, debate, talk politics, and do what people do to develop relationships. If these people work in close physical proximity, the positive effects are enhanced.
It is these connections that enable team members to commit to one another, and subsequently to the sprint goal. No other forms of motivation, especially those imposed by “management,” are nearly as powerful as the promises made among the team members.
If you accept the assertions above, it is obvious that for a team to achieve the highest level of success with agile, you should provide an environment where the members share physical space2 (a team room is a common example), work in a collaborative and dynamic fashion, and have the opportunity to form social bonds strong enough to sustain focus and commitment.
“All of this is well and good;” you say, “however, my teams are distributed, and I have expertise scattered about, so I have to have people all over the place.”
In these situations, strive to divide work so that you can form multiple, local teams. Each local team can work on independent user stories or tasks. In the example above, you could divide the American and Indian teams into two distinct groups. The American team could work on one set of interrelated stories, while the Indian team could do the same. These teams must commit to integrating early and often. Along these lines, if you have experts in a specific domain or technical area, send them where they need to be for short or long-term engagements (as possible), working hand-in-hand with the teams that need them most.
One worry against forming locally oriented teams is that they devolve into an “us and them” mentality. The team in the US, for example, who works together every day, starts to forget about and compete with the team in India, who are also working side-by-side. Although there is a remote chance of this happening, the benefits realized by the collocated teams far outweigh the potential costs of managing a rift that may form between them. Knowing that this social fissure can form, the proactive manager must constantly find ways to quickly break down any walls that form; e.g., regular coordination meetings, instituting a “catch and release” program where pairs of developers swap locations for extended periods of time, and so forth.
As an agile manager, you must continually focus the team and remind them that the only measure of success is shippable product, and that the whole team, in its entirety, is accountable for the results.
If working in dislocated teams is inevitable, help people coordinate via technology. The important thing here is setting up multiple, reliable, and efficient communication pathways. On one distributed project I worked on, we used e-mail, IM, WIKIs, VNC, common servers, and always-on conference bridges to help make up for the lack of team members being physically present.
If you need to work this way, make sure to coordinate with your IT department early – you will need their help to make sure things run smoothly and to fix things when they break. The IT department can ensure conference bridges are available and working, servers have the proper software installed and have enough disk space, routers are configured to allow collaboration software to work properly, etc. You must do everything within your power to enable team communication, trust, and synergy. Every dollar that you spend supporting these goals, you gain back in spades in terms of team productivity. It’s a smart investment.
When teams fail to work in a tightly knit, collaborative fashion, “agile” devolves rapidly into an administrative practice. Under these circumstances, a Scrum team may still have Daily Scrum Meetings, use Burndown Charts, and manage backlogs, but they only realize a mere fraction of the potential benefit.
The real power of agile lies not in administration or governance, but in the wisdom, chemistry, and commitment of collocated teams.
- A study by Kiesler and Cummings found that when people are separated by thirty meters or more, they tended to interact infrequently. In addition, these distances drastically reduced the likelihood of voluntary collaboration. You can find their paper at http://www.ece.ubc.ca/~leei/519/2002-ProxmityDistanceWorkGroup.pdf
- When setting up team friendly environments, remember to respect people’s need for occasional privacy. Have a room where people can make private phone calls, get away, etc.
