There are many different experiences and pieces of advice with regard to distributed teams, and most deal with how to get the communication to work in the best possible way within the given parameters. Active use of electronic aids such as Skype, Communicator, SharePoint, etc., are often recommended to ensure good communication across borders and time zones, and to remove some of the disadvantages associated with having a distributed team.
There is a common perception that the co-located team is better positioned to ensure good communication and deliver more efficiently than distributed teams. But in a world where global collaboration becomes increasingly common, teams often consists of people from different parts of the world working together as distributed teams. And with this, it is interesting to note that while there are some clear challenges with having a distributed team, there can also be some advantages.
A distributed team can be cost-effective. This can be manifested in the form of reduced travel costs and the use of resources from countries with lower labor costs. Traveling can be replaced with efficient work, and the reduced travel load in itself can be a motivating factor for many.
A distributed team can also provide access to higher skills, because you do not have to limit your resource search to a specific area.
In some cases, having a distributed team also enables some team members to sit together with customers in multiple locations. Some also claim that distributed teams are more focused on information sharing within the team -- but then again it can also make the communication more formal, with the advantages and disadvantages this may cause.
But there are obviously some definite challenges with having distributed teams. One of the most important lessons is to not manage a distributed team as if it were co-located. It is crucial to be aware of this and to address the obstacles that the team will have to deal with in terms of communication and cooperation.
Many development practices (e.g., from Extreme Programming) stipulate rules for teamwork, and it is important not to ignore such practices just because we have a distributed team. If your current situation makes it impossible to follow a defined practice, you should either modify or replace it with something that works better within the given situation. The key is to make sure that you are aware of the purpose of the practice, and make sure that an alternative or replacement provides the same benefit. For example, pair programming can be replaced or simulated by performing code reviews. User stories can be written out in even greater detail to make up for some of what you'll be missing if you cannot have the same degree of conversation within the team during a planning session. Don’t get me wrong -- I would never state that this is a good substitute for conversation, but I use this example to show that, even in cases where we can't follow the very core beliefs of the Agile Manifesto (interactions over tools), we should still make some effort to improve the situation.
Another challenge with distributed teams is that we often fall for the convenience of assigning tasks based on the team's spread. This can result in specializations within the geographic locations, and so we create dependencies between these locations. This could greatly reduce the team's ability to complete a function within an iteration. Actually, studies show that such negative effects increase with the size of the team.1
Some would argue that it can be impossible to avoid such situations. Sometimes all the experts within an specific field are in just one of the locations, and therefore it's not appropriate to allocate this expertise to the other locations. Such discussions will always be based on the different experiences of different people, which may not be directly comparable.
A person who claims that ensuring competence distribution across locations makes sense probably is quite right in the circumstances he or she experiences. Maybe much was to be gained from having a cross-functional team just because in the given case there were many dependencies across tasks. Or because the duration of the delivery was so far out that investment in training and transferring skills was actually quite reasonable.
A person who claims the opposite, who simply does not see the point in having a cross-functional team, will also have experiences that support this. Maybe it was a short enough delivery duration that it didn't pay to drive knowledge transfer. Maybe there were more people at a given location with the same skills and therefore they were not so dependent on one individual. Perhaps the dependencies across tasks were so small that it worked just fine to have different expertise in various locations.
Most people, regardless of experience, will agree that there will always be an advantage to having a cross-functional team. The intention behind this principle of Scrum is that you should avoid dependencies on individuals and make good decisions based on discussions among several people who have expertise in an area.
But ultimately it must be taken case by case, and you must observe and evaluate what makes the most sense in the given situation.
In a global setting, language itself is another challenge within distributed teams, as are different working hours (time zones) and especially cultural differences. In Scandinavia, many people believe that we are more practiced at enhancing collaboration and that our style is more inclusive compared with, for example, the U.S. Meanwhile, a leader in the U.S. might find it easier to confront employees whose performance is inadequate, which many executives in, for instance, Norway are reluctant to do. In Asia you are keen not to lose face; in Saudia Arabia, it is disrespectful to sit with legs crossed and show the soles of the feet; in Russia, an inclusive leadership style is perceived as a weak leadership style.
There are countless examples of cultural differences, but what does this mean in the context of securing communication within a distributed team?
Despite all these cultural differences, we humans are very similar when it comes to relationships with others. It's primarily about building trust by respecting others, with words and actions that are in relation to each other.
All functional teams should be based on these principles and, therefore, establishing these principles is perhaps the most important thing one can do to ensure that team members have the opportunity to build this basic trust in each other.
Confidence exists at several levels in a distributed team
Trust is built through interaction and communication. A developer who takes responsibility for a task and delivers it well inspires confidence in others. A ScrumMaster who protects the team has the confidence of the team. A product owner who dares trust that the team will use its technical expertise to deliver in the best possible way will create mutual trust and increased commitment from the team.
But confidence also means accountability. If the team feels that others do not deliver as expected and that this is not handled and solved, you've got a situation that could be damaging to both motivation and efficiency. Accountability can also be seen in that a product owner sets expectations that the team delivers on, according to what they have committed to for a sprint.
To lay the foundation for mutual trust and cooperation, it's often recommend that distributed teams gather physically at the start of a new project. This helps team members get to know each other, which forms an excellent basis for continuing dialogue and cooperation. It also provides a good opportunity for the team to establish a common set of rules for collaboration and communication. (This is something every new team should do at its inception, regardless of whether the team members meet physically or not.)
In 2003, a study of global IT teams revealed that key factors for successful distributed teams included a set of common goals, open dialogue, attention to building interpersonal relationships, and making sure that someone was responsible as a facilitator to support collaboration and communication.2
What is interesting in this context is that this study addressed all types of IT projects, not only those based on the Agile framework.
By using the Scrum framework, a team should, theoretically, have very good conditions to ensure a focus on these key factors. The daily Scrum encourages regular dialogue and communication between among team members, the team sets out common goals for each iteration, and the ScrumMaster acts as facilitator.
This is in no way an attempt to argue that the Scrum itself is the solution, but the principles that the framework is built on will help keep a focus on the key factors that, as experience shows, are important for efficient distributed teams. Again, back to the eternal mantra that should form the basis for all Agile development: Understand the intent of the framework and established practices, base them in reality, and make adjustments so that one can achieve the intention.
In distributed teams with different nationalities, it is wise to be aware that people have experiences and expectations based on other traditions. Generally speaking, it is often also wise to be open to other ways of doing things. But the basic expectations of trust and cooperation are largely the same, regardless of borders and frontiers. A very good rule of thumb is to always have more questions than we have answers. Acquire more information while avoiding coming across as arrogant and as having all the answers. The information you'll gain will support broader and more informed decisions and assist everyone in making the right decisions.
When it comes to having a distributed team, then, it's primarily about building trust and having mutual respect for each other, along with a common focus on communication and as close a collaboration as possible.
It's difficult to give one-size-fits-all advice, but I hope the areas discussed form good suggestions as to what can and should be focused on when working with distributed teams. In practice, the world is such that no project or team is equal, and you have to do assessments and make decisions based on the assumptions that apply to the appropriate team. In its simplest form, it's about communicating, observing, and reacting.
1 Craig Larman and Bas Vodde, Scaling Lean & Agile Development. Addison-Wesley Professional, 2008.
2 Dr. Niki Panteli, lecturer in Information Systems, School of Management, University of Bath. (Link to survey: http://www.ariadne.ac.uk/issue43/panteli)