Agile engineering practices
Distributed Development Enablers Part 1: People
By definition, Distributed Development is difficult due to the ‘tyranny of distance’. In fact, in the early days of Agile adoption, some purists believed that Agility and Distributed Development could not coexist, going by this principle - “The most efficient and effective method of conveying information to and within a development team is via face-to-face conversation”. Distributed Development is a reality today and in most cases, a necessity due to some very convincing reasons. Despite all the advancements in technology related to communication and collaboration of virtual teams, Distributed Development still faces challenges, as people are ‘not in the same room’. Let us examine some of these challenges in this post.
Barriers to Communication and Collaboration
Culture
Distributed Development often involves teams spread across nations and continents. As we all know, cultures vary widely across the globe. When people are ignorant of culture, even an innocuous gesture, or the lack of it, can cause ill-will among people.
An example will illustrate this point. In some countries, it can be quite uncomfortable for many people to directly say ‘no’, whereas in others, it is perfectly acceptable to say so, and also expected, rather than getting a mixed response. One can imagine the awkwardness on a telephone conference call when there is a long silence or an incoherent response, when the person actually means to convey a ‘no’. Such situations could potentially create major misunderstandings, and can impede building of trust, and impact software delivery as well.
Time Zone
Distance between teams not only inhibits face-to-face communication, but poses additional practical challenges as well. If teams are working in vastly different time zones, e.g. San Francisco (US West Coast) and Pune (India), there is a challenge in overlapping working hours. Either or both sides would have to start work early or end work late, and this can lead to another problem, one of resentment.
Language
Another situation that often characterizes distributed teams is when both teams are from different parts of the world, and their primary language is not the same. A team in China, that speaks Mandarin, finds it difficult to communicate with another in Brazil, that speaks Portuguese. These teams would have to use a language common to both, say English. Given that it is not the primary language of either team, the ability to communicate clearly and crisply, while keeping a neutral accent, is challenging.
Lack of the ‘Big Picture’ View
This challenge typically occurs when the Product Owner (PO) and Business Analyst (BA) are in separate locations from the rest of the delivery team. While they may conduct a ‘big bang’ session to provide the big picture view, their conversations around the big picture may get ignored, and most of the team members might just get to see limited pieces of the puzzle. The problem is further aggravated when the team's work is directed from a remote location.
Requirements Misunderstanding
Another challenge arising from the distance between the PO/BA and the team is that opportunities to elicit and clarify requirements are rare. This can naturally lead to higher documentation for communicating requirements, and clarifications done over the phone. This poses a huge risk of requirements being misunderstood, especially if there is no common primary language.
Lack of Trust
Building trust between team members is a ‘chicken and egg’ problem. When people are separated by distance, there needs to be greater trust between them, to work collaboratively. And trust cannot be built between people unless people connect in person and spend meaningful time together. Absence of trust leads to a ‘throw over the wall’ mindset and finger pointing when things slip or fail. In this situation, there is a very high risk of negative feedback being given or taken in the wrong spirit.
This is an important challenge when teams are distributed and have a high level of dependencies between them. Imagine a day when a team in Pune (India) leaves behind a broken Build as the other team in San Francisco starts the workday. This will result in loss of productivity for the team in San Francisco. Even if there is every reason to believe that this was an inadvertent slip from the India team, it could cause resentment in the US team, thereby leading to an increase in the trust deficit.
Lack of Visibility
While working from a remote location, it is quite difficult to get good visibility of work happening in other locations, as radiation of information across locations is a huge challenge. This can lead to ‘multiple sources of truth’, which can result in misunderstandings and unpleasant surprises.
Low Morale
This is typically seen at offshore locations, when onshore has a superiority complex. When onshore team members carry the belief that the work done by the offshore team is relatively of low value as compared to their work, they seldom appreciate the other team members. This can lead to a feeling of being taken for granted and result in low morale.
Lack of Collective Code Ownership
Collective code ownership means that no single member of the team owns a piece of code, it is owned by the entire team. This means that the code is up for refactoring to all team members. Implementing this in a distributed environment poses two major challenges. First, unless appropriate tools and a Version Control System is used, maintaining collective code ownership can be difficult across locations. Second, lack of trust between team members can lead to highly negative consequences like blaming each other.
Risk of Unpleasant Surprises when ‘Everything Comes Together’
When multiple locations are producing work that needs to be integrated at some point, there is a huge risk of things falling apart, unless Continuous Integration is practiced rigorously. Inconsistencies between locations in types of tools used, an unsuitable Version Control System and lack of common quality standards can become major impediments towards achieving ‘surprise-free’ integration.
Summary
After reading all the above challenges, it might appear that Distributed Development is doomed for failure. However, many organizations have worked towards implementing measures which significantly help in overcoming these challenges, if not fully eliminating them. I am going to share some of these good practices in my subsequent posts.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
