Running a distributed team: Hurdles and solutions

There is a classic underdog story. A struggling baseball team realises that the talent scouts are missing out on opportunities and the reliance on decades-old wisdom has been the root cause behind this. By enhancing their scouting tactics and imbibing modern tools and practices, the team identifies and hires a bunch of underestimated players and subsequently triumphs over opponents with far larger payrolls. Author Michael Lewis has penned down this story in his book called Moneyball: The Art of Winning an Unfair Game. Business organisations play ‘moneyball’ by using distributed teams.

Moneyball’s greatest lesson for business organisations is that whether you are a large enterprise or a startup looking for an edge over an incumbent that can outspend you, there is an opportunity to adapt your tactics and hire an untapped pool of top-of-the-line quality talent by discerning when the conventional wisdom on building teams no longer reflects reality. Building a distributed team is challenging and overcoming the difficulties would eventually be fruitful in the long run for organisations. Let’s look at what obstacles do firms encounter while building and running a distributed team and how can they tackle the problematic instances.

Distributed team and the challenges involved

When the people you closely collaborate with (i.e. your team) are sitting in a different office building than the one you are working in, you are distributed. One can even argue that when a team has people working on different floors, then it is also distributed. A simple illustration by Johanna Rothman, a management consultant, delineates 4 variants as is given below:

Before heading over to the challenges encountered by distributed teams, let’s take a look at a scenario where different members of a distributed team offer their views (see the figure below).

Now, let’s break down the significant hurdles that are seen in a distributed environment.

Language difference

Different parts of the globe speak different languages. The teams would have to communicate in a language that is common to both of them. Let’s say that English is the language that they consider to use for formal communications. Then, it can turn out to be a tricky situation when it is not the primary language of either team. It can get challenging to communicate clearly keeping a neutral accent.

Issues with building trust

For work to be done collaboratively, there has to be greater trust between the team members separated by a distance. Trust building develops when people connect in person and spend quality time together. Absence of trust may lead to high risk of negative feedback being given or taken. For instance, a lack of trust may lead to greater negative consequences and difficulty in maintaining collective code ownership where, rather a single team member, the entire team owns a piece of code.

Ignorance of culture

Often constituted with teams spread across countries and continents, distributed development have to confront with people of different culture. Ignorance of culture can be detrimental and even an innocuous gesture or the lack of it can lead to ill-will among people. For instance, directly saying “no” can be quite uncomfortable for people in some countries and it can be perfectly alright in other countries where that is preferred over a mixed response. Situations like this can lead to misunderstandings, obstruct the building of trust, and affect software delivery.

Visibility of work

Getting good visibility of work that is happening in other locations may get difficult thereby leading to multiple sources of truth, misunderstandings and unpleasant surprises.

Different time zones

If one team works in, let's say, the United States and another in India, the vast difference in time zones can pose a challenge in overlapping working hours. Pondering over if either or both sides should start work early or end work late can lead to rancour.

Distance between Product Owner/Business Analyst and the team

When the Product Owner (PO) and Business Analyst (BA) are in a different location than the rest of the delivery team, it can get troublesome. Even though they may conduct sessions to offer a big picture view, their interactions around the big picture may get ignored and many team members may only see limited pieces of the puzzle. Also, opportunities for evoking and clarifying requirements are rare. Naturally, this may result in more documentation for communicating requirements and clarifications done over phone and video call. Here, requirements may get misunderstood if there is no common primary language.

Affecting morale

Sometimes distributed development may result in low morale of some of the team members. For instance, when onshore team members have a superiority complex, they carry a belief that the work done by the offshore team is not as good as compared to the work done by them.

Integration of work

Things may get tricky when the work, that is performed across different locations, has to be integrated. Practising continuous integration in the workflow can improve the situation.

Overcoming hurdles

People, process, tools and infrastructure are the major areas to be focussed upon while tackling the hindrances during distributed development.

When considering ‘People’ related solutions for distributed development, it is imperative to understand the importance of a PO. In a distributed setup, the PO is most likely handling things remotely. A proxy PO can be of great help. He or she has to be co-located with the remote team(s) so that the team members can spend adequate time with the PO to understand the key requirements in detail and win the trust and confidence of PO.

Hold cultural awareness sessions and orientation sessions across locations to orient team members about cultures in other locations

Further, there has to be a face-to-face meeting between people working in a distributed environment for trust building. For instance, onshore team members can visit the offshore team and vice versa. Also, it is fruitful to hold cultural awareness sessions and orientation sessions across locations to orient team members about cultures in other locations. Even the positive feedback to team members is of paramount significance for strengthening relationships and build a feeling of oneness. To add to this, feedback on what is not working helps denude misunderstandings. And it is better to let the team members with better communication skills lead the conversation (as explained in the figure below).

Once the people-related concerns are handled, it is time to move on to the ‘process’. There can be a plethora of betterment done in the processes involved during distributed development. A project kick-off workshop at the incipient stage itself is a huge deal as it encompasses integral decisions that will impact the overall outcome of the project. These decisions can be on the lines of business and technical scope, significant project drivers like time to market, cost etc. and arriving at a common understanding vis-à-vis business vision. Most importantly, this helps in cementing the relationship between stakeholders.

Stand-up meetings are efficacious for leading an Agile team

Moreover, stand-up meetings are efficacious for leading an Agile team. Like stand-ups, joint retrospectives are a must. Tools like Scrumble and Ideaboardz can be of great help for exchanging information in real-time and can act as the single source of truth for the retrospectives of distributed teams. Also, maximising overlap hours across locations assists in enhancing communication and collaboration and there has to be an eagerness to compromise and be adaptable. Also, by showcasing the work in progress after every iteration minimises the unpleasant surprises and builds trust and confidence.

Considerations related to ‘tools and infrastructure’ ensues once the process-related concerns are taken care of.

For instance, trunk-based development can be beneficial which enables team members to view code alterations swiftly and give feedback before pushing their commits to the central repository.

Also, tools like Slack, Skype, or Google hangouts among others can be considered for team communication and collaboration. Tools that align with the security policies of your organisation can be a good choice for communication. Furthermore, the choice of network, access rights, and bandwidth must be addressed before the teams working across different locations starts functioning.

Conclusion

To taste success in the global economy, more and more organisations are relying on the geographically distributed workforce. They build teams that provide the best functional expertise from around the globe in addition to the deep, local knowledge of most promising markets. This is great for international diversity, bringing together people from different cultures with varied work experiences and different stance on strategic and organisational hurdles.

Offering ambitious digital experiences has been at the forefront of our objectives and we have been doing that with a suite of services. Contact us at [email protected] and let us know how do you want us to be a part of your distributed development environment and build innovative solutions.