Distributed Development Enablers Part 1: People

Having examined the challenges of Distributed Development, let us look at some enablers that can help alleviate the challenges under three broad categories – People, Process, and Tools and Infrastructure. Let us start with people related enablers.

Proxy Product Owner

We all know the importance of having a Product Owner (PO) in the team. The PO provides business context to the team, prioritizes the requirements and signs off the developed features and stories. In a distributed setup, however, the PO is likely to be located remotely from most of the team members. In this scenario, creating a Proxy PO role can help immensely. The Proxy PO needs to be co-located with remote team(s). They need to spend adequate time with the PO to understand the business context, the drivers for the solution and the key requirements in detail. Most importantly, they need to win the trust and confidence of the PO.

The Proxy PO should be in a position to provide context and clarifications to the team, to a large extent. They should be the single point of contact with the PO. While the PO may still be involved directly in major decisions like feature prioritization and sign offs, the Proxy PO should shadow the PO very closely on such matters. This will significantly help in building the Proxy PO’s capabilities quickly, thereby drastically reducing dependency on the PO. It is important that the Proxy PO is empowered to make most decisions, for the role to be meaningful and effective.

An effective Proxy PO will ensure better collaboration with the business, faster decision making and an increase in end user satisfaction.

Cross Pollination

A key to working effectively in a distributed environment is the level of trust between the team members. People meeting face-to-face and spending time together is the first and most important step towards building trust. There are two major anti-patterns, which need to be avoided:

Having only onshore team members visit the offshore team, which might imply that offshore teams members need not visit onshore.

This makes it look like a ‘one way street’ and will not bring in optimal results. People traveling both ways, i.e. people onshore traveling offshore and vice versa, is necessary for cross pollination to be effective. It gives people, across locations, an opportunity to understand and appreciate the context and constraints that the distributed team members work in. Moreover, it helps build stronger relationships amongst the distributed teams.

The value lies in people spending time together not only at the office, but also when they socialize together after office hours. That is a huge enabler towards building trust.

The visits are for a very short period of time, perhaps just a week.

This is usually a waste when people are visiting from very different time zones—jet-lag usually has a negative impact on the visit. On a week-long visit—the first day is spent in warming up and getting to know the other people, the next two to three days is when work momentum begins to gather pace, and the last day is spent on wrapping up and good-byes. Subject to visa and family constraints, the duration of visits should be anywhere between two to four weeks, the longer the better. Assuming that the necessary infrastructure, including communication channels, are in place, people traveling should be able to continue their work with minimal disruption while they are on the road. 

The main obstacle for people being able to travel, is budget constraint. Typically, leaders look at money spent on travel as an expense. In distributed development, the money spent on travel is not an expense, but an investment, which is necessary for people to work collaboratively. The payoff on this investment is huge.

Cultural Sensitivity

When we discussed the challenges of distributed working, we examined how the lack of cultural sensitivity can become an  impediment towards people working together.

It is important to invest the time and effort to educate people who are travelling, especially for the first time, to a location which has different culture from theirs. These orientation sessions can be done by external  experts or even by those within the organization who are well travelled and have good exposure to the particular region in reference.

It is also crucial to hold cultural awareness sessions in general, across locations, to orient team members about cultures in other locations. Culture will come into play when people communicate. For example, many people in India nod their head in a particular way to communicate a “yes”, which might be very different from how people nod their head in many parts of the world for the same reason. If, for example, a team is distributed between India and USA, it is advisable to educate the people in USA about this behaviour in India. Conversely , it is important to make the India team aware of how this can be misinterpreted by people in the USA.

Feedback Culture

Feedback is one of the key elements of Agility, and it becomes even more important when the team members are distributed. Positive feedback to team members helps a great deal to strengthen relationships and creating a feeling of oneness, while feedback on what is not working helps to avoid misunderstandings and resentment.

Team members should be encouraged to give feedback, both positive and constructive, as appropriate to other team members. The timing of the feedback is critical—feedback given late can actually become counterproductive.

Here is an example of how feedback on a seemingly trivial, but important matter, helped a team. The team was distributed between USA and India, and was quite new to working in this manner. During joint meetings, the team members in USA would sit at a rectangle shaped table with the telephone in the middle of the table. The team members in India could  hear people who were sitting closer to the telephone, but could hardly hear those who were sitting at the corners. This not only impacted the effectiveness of the meetings, but also made the team members in India quite frustrated. The team members in USA were unaware of this problem, until it was pointed out to them. Once they got feedback about the issue, the team members occupying the corner slots started walking up to get closer to the phone or moved the microphone closer to them when they spoke.

It is important to understand why the team members in India did not give feedback to their USA colleagues, until they were prompted to do so. It could be attributed to ‘onshore-offshore’ syndrome, where the offshore team members have an inferiority complex and the onshore team members have a superiority complex. Or it could be because it did not strike them that the problem could be resolved with some very minor adjustments. Regardless of the reasons, the team was negatively impacted. If the problem had continued, it might have led to the team members in India feeling even more frustrated and also perhaps resentful towards the USA team members.

Leveraging Effective Communicators

It is a fact that working in a distributed environment requires superior communication skills.  It is also a fact that not all team-members have the same level of proficiency in communication skills.

It is important that a team takes stock of the communication skills of all team members and ensures that team members with better communication skills lead the conversation/communication. This is particularly important when: 

• The team is new to the distributed way of working
• Trust is yet to be established with team members who are not co-located
• Something unpleasant or negative needs to be communicated

Communication, particularly verbal, is not just about fluency but also about using the right vocabulary and tone. These can become very important in situations mentioned above.

While some people have a natural flair for communication, for others this skill can be developed over time through observation, mentoring and practice. Team members with better communication skills may take the lead for some time, however, they should consciously help their co-workers develop their own capabilities.

In the next part of the series, we will examine process-related enablers.