People Perspective for Distributed Software Development

Posted by jvohra under Offshore Software Product Development

How do you build stellar teams for distributed software development? The people perspective

Being an outsourced software development services company, we serve our clients globally from our development center in Pune, India. In our partnerships with leading software companies over the last 8 years, we’ve assimilated experiences of building distributed development teams.

From our experience, the issues managers face while adopting a distributed product engineering strategy span three broad areas:

• People
• Infrastructure
• Operations: both startup and ongoing

 I’ll dig deeper into each of these in subsequent posts, and start here with people:

People are the bedrock of an execution plan. In a rapidly changing environment, the importance of people or “knowledge workers” has come sharply into focus. While labor arbitrage was a primary driver for distributing development across several low-cost locations, there is increasing realization that lower costs are only one piece of the puzzle. Talent is global, and smart firms are reorganizing themselves to tap into this global pool.

The essential challenge of distributed development is to transfer complex knowledge about products or processes, held in the heads of a group of people in one location, into the heads of a group of people at another location. We’ve seen that a higher intensity of interactions between individuals is more critical than comprehensive documentation or elaborate processes and time-consuming tools, especially if requirements are rapidly evolving

So, the people perspective for distributed development is about practices that enable and ensure communication and interactions across locations. By selecting the right people and instilling a culture that facilitates communication we can not only achieve superior productivity but also ensure that we retain these teams on a sustainable basis. So, how does one achieve that?

For starters, by priming the existing team for an imminent cultural shift. If your organization currently does not leverage agile practices, then it would be important to instill these practices as also build processes and infrastructure that can be extended to a distributed team in the future.

What is important is to envision an effective team structure and a communication plan, within which specific roles in distributed locations are incented to encourage communication. Some roles, more than others, play a critical role in not only facilitating the transition to the new paradigm but also supporting it on an on-going basis. The project manager is a key promoter of the one-team concept. Business analysts who serve as proxy customers can ensure functionality is understood clearly and well in time. Onsite liaisons from the distant location also serve as key contributors to a successful transition. Depending on the team-size, the onsite liaison should be capable of serving as the project manager, business analyst, and proxy customer all rolled into one. Once this team structure is envisioned, it is important to communicate the anticipated change in roles, emphasizing the interaction mechanisms with the distant team.

Hiring team members at a distant location typically involves working with a vendor organization or your own captive operation. Either way, multiple organizations are involved, bringing with them potential cultural, language and time zone issues. Participation in the hiring process can ensure the right team members come on board. For example at Silicus we work with our customers to put their team together in what we call a Hired-to-Order exercise. On its own, our HR department is fully capable of staffing the engagement with the best and brightest, but we involve our customers in selecting team members based on specific requirements like skills, domain knowledge, experience, etc. The selection process is essentially a joint exercise between the project manager and the offsite HR person. During this process, the Project Manager can either be present physically at the distant location or be available via video conferencing for the interview sessions.

While pre-selecting candidates, we place as much importance on soft skills as their technical ability. People with experience living in or working with other cultures, or who have traveled outside their home country are more open to forming relationships across cultural boundaries. Hence we’ve found them to be more effective in communication. Additionally, people with familiarity with our customer’s software vertical or domain are able to jumpstart the learning curve and act as mentors to other team members. If you are setting up a remote location as part of an outsourcing relationship with a vendor, ensure that the vendor is well versed with agile practices and the team members you are hiring also have past experience in agile development.

Ok – so now we have distributed teams that are ready to engage as a single team, even if they are in different locations. But is this sufficient to achieve success? To further nurture the one-team culture, we exercise best practices that continue to cement relationships – both people-to-people as well as people to organization.

Many organizations have grown from small close-knit teams. Such organizations do not have the mindset of having staff members travelling or working off-site. Often these organizations could also be sensitive about sending critical data or source code off-site. Providing access to team members who are offsite entails putting security measures in place. We will discuss this aspect in a subsequent webinar on infrastructure best practices. Also, even after putting security measures in place, management and senior team members are distrustful. And then, some employees may perceive a team at a distant location as a threat to their positions – especially if the distant location is a low-cost development center.

These issues can be addressed by building practices that emphasize a one-team concept. Having a “seeding” visit before diving into the distributed development initiative is a good way to start.  A seeding visit occurs the first time people from the off-site team visit the local site or vice versa. The first seeding visit should usually occur when team members from either location meet face-to-face to help articulate the general vision for the combined teams in terms of roles, responsibilities, communication practices as well as day-to-day operational practices. Collaborating in this fashion leads to a shared vision between the distributed teams. Subsequently, regular maintenance visits or visits by team (goodwill) ambassadors who dedicate time at the offsite location for a period of time can build and sustain the one-team structure.

Encouraging the teams to participate more in product strategy and roadmap discussions ensures that your off-site team is dedicated to customer commitments and has a common understanding of your vision and approach for execution. Most often, remote teams are not viewed as a strategic part of your organization’s assets, giving them no incentive to remain passionate about developing your product. This stems mainly from the mindset that the remote team is part of the offshore (or a vendor’s) organization, whose job is only to carry out instructions and tasks – a command and control mindset. To get a remote team to deliver, especially for time-sensitive deliverables, team members get involved early in the process and are considered integral to the successful delivery of the code – not just as workhorses for cranking out a section of the code.

Finally, there are cultural exchange programs that can greatly impact the success or failure of distributed development. Occasional cultural programs, which aim to get the teams better acquainted with the other’s culture and way of life, go a long way in ensuring cross team integration. The HR manager could take the lead in drawing up a calendar of such events, especially if they include non-work activities that also introduce aspects of the other culture. A short game of baseball or cricket during maintenance visits is not only fun; it also presents the opportunity to glean insights into another’s culture.

So, if you haven’t already done so to build the next generation of your product engineering team, we believe it is time to start scouring the globe for talent! Remember that the benefits are no longer limited to large organizations alone.

About the Author

The author is a principal at Silicus Technologies (An Offshore Software Development Company) and has managed large distributed software development engagements.