Introduction
Today outsourcing, offshoring and working in globally distributed teams are common for an ever-growing number of people in software development. Even though this trend is not new, the ever-increasing implementation of agile principles adds a new twist to the already known challenges. In this article we will explore some challenges of distributed development along with some stories dealing with them and suggestions to tackle these challenges
Separation in Space and Time
Rather obviously the first and foremost obstacle is the distance between the locations the people work in. Even doors or placing people on different floors can hamper collaboration, just because they have less opportunity for relationship building. I have seen at least as many technical problems solved during a coffee break as have been solved in development meetings. Many more “social” problems, like understanding the needs of other people and their intentions are solved while chit-chatting over some drinks than sitting in a conference room. Let’s see what even a small change can do to an organization.
A company was experiencing a shortage of office space, due to its remarkable growth and success. To alleviate the situation a group was moved to a neighboring building. To meet with colleagues from the other location you would just have to go down some floors, walk some 100 meters and go up again. Five minutes max. The effect was rather remarkable and negative, as the number of misunderstandings and short-term clarification meeting increased significantly. The direct contact to other groups was compromised by even that small amount of separation. Instead of clarifying and aligning open points, people started to write long documents and email chains, used up hours on IM communication or plainly worked based on assumptions instead of aligning.
Obviously the communication is generally hampered by separation in location. E-mail chains, instant messaging, documents and wiki pages replace face-to-face communication. This poses several challenges in communication, as fast feedback regarding common understanding is not that easily possible any more. We experience the problems well known from the requirements engineering domain, as we observe the whole bandwidth of issues of natural language communication, just with higher intensity. Language transformations, ambiguities and incomplete definitions become way more common, as direct communication is reduced.
During training on distributed development the participants are separated in teams and have to build identical models. This is to simulate the coordination needed for SW integration. Since the teams do not know the material available to the other teams (“different skills and toolset”) they have to coordinate via phone. In this specific session the teams had identical marshmallows as building material. The following dialog occurred:
Team A: “What size are you marshmallows?”
Team B: “Roughly thumb sized”
Team A: “Ok, ours are only around an inch in size”
Team B: “Fine, we make them smaller” – and tears it apart
As in classical requirements engineering the use of models and clear-cut standards can help here. But instead of using the next available napkin, you have to rely on tools, which are typically more time consuming to use. A quick workaround is your smart phone, snapping a quick picture of what you’ve been drawing and sending it to your peers. But do not forget, that they do not have the advantage of listening to you while you draw something up.
The use of personal video calls and screen sharing can alleviate these issues to a degree. This is especially true for 1-on-1 communications, where the participants focus on the conversation. Web conferencing tools however, mostly fail to deliver an adequate replacement for in person meetings. Two-inch images, latency and bad habits of the participants (like checking emails or chatting with colleagues while on mute) are the most prominent reasons for that.
Full featured, high quality video conferencing systems even allow for very good rapport and interaction and also keep the participants focused. These systems however are rather costly and, if available, are in continuous high demand.
As we can see, there are many ways to convey the information to our peers, but we must be aware of the increased time effort and the increased risk of misunderstandings. Making matters worse is easy. Just place some time zones between the different locations. Now we gradually reduce the time for face-to-face conversations and fast feedback.
A company was developing software using agile methodologies. For reasons beyond technology and organizational needs (namely company politics) the developers and the product owner of a specific product were separated by 6 hours time difference. Even though the company employed all the modern means of communication, the efficiency of the discussions regarding the user stories was definitely hampered as compared to the co-located teams. Additionally the product owner was not available within a short time to answer questions or clarify user stories. This lead to overall delays in implementing stories and also more misunderstandings and a greater need for written documentation.
Distributed Agile
In the Agile Manifesto we read “Individuals and interactions over processes and tools”. To me it is clear that specifically the interactions part is seriously, negatively impacted if we separate team members by location. The farther apart they are, the less opportunities for continuous interaction are there.
In figure 2 we can see the availabilities of people in an international setting I worked in. People involved in the creation of software system and needing to collaborate were placed in five locations around the globe. When looking at the graphics, depicting, no (red), limited (yellow) and full availability (green) of the employees, it becomes obvious that the time window for a “all-location” web conference is limited to roughly 1.5 to 2 hours. And even that requires some persons to extend their normal working hours.
Even if you have the best available infrastructure for electronic cooperation and collaboration you have to adjust to the limitations dictated by your geographical boundary conditions. The sensible remedy to that is to minimize the need for interaction between these teams, while still providing excellent possibilities for interaction and communication for the remaining communication needs.
This sets up constraints for the organization and, according to Conway’s Law, for the architecture of your solution’s. This also defines a solid need for empowerment and autonomy of the teams. Furthermore the reduction of communication possibilities and needs may create trust issues.
The need for In-Person Interaction
You should never forget that we are talking about human interactions and relationships, when we talk about development. It is therefore that you have to ensure that these relationships develop and are maintained between the separated groups. In my experience this can be best achieved if the people meet regularly in person. Spending some time together outside of work, getting to know each other will do magic to collaboration and bring your projects forward way faster than the next couple of web conferences.
In many companies, specifically when they are facing economically difficult times, the travel budgets are among the first to be cut. Given the comparison to other costs these companies incur in other areas this seems doubly counter-productive. Not only are the savings in this area typically quite limited, they are hurting their productivity in an ever so subtle way, that they will pay back this debt in relationship development with rather high interest. This is comparable to cutting down your training budget. And basically the outcome of these budget cuts will therefore violate some principles of the Agile Manifesto, like “give the people the environment and support they need”.
Conclusion
As we can see, the separation in space and time will seriously hamper the collaboration between the people in your organization and thus create the requirement for additional measures from a technical and organizational perspective. Additional challenges are introduced by differences in language and culture. This will be discussed in the second part of this article.
Read the second part of this article.
About the author
Bernhard Burger works for nearly two decades in the IT sector. He has held leading positions in the areas of financial services, telecom and software development. In recent years he successfully built up international quality organizations and focused on their professional growth and effectivity. In 2014 he founded Quality Advantage, a consultancy focused at the idea of the quality over the whole lifecycle.
