Operational Perspective for Distributed Software Development

Posted by jvohra under Offshore Software Product Development

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

Some companies inherit a globally distributed development initiative or organization. This may be for instance through M&A activity. Many companies on the other hand are compelled by business conditions to use geographically distributed teams. For these companies, a key question that arises is whether to invest in a captive facility or partner with a vendor for services.

While making this decision, you should consider the following factors, since they could have long-term business implications:

• Location or country and its legal business framework
• Upfront investment in a captive set-up versus working capital for vendor relationships
• Extent of direct control required, which is typically higher in an self-owned facility
• Management bandwidth available to manage the remote location
• Exit strategy and costs in case of a captive facility

Our experience shows us that on average the minimum team size in a remote geographic location should be 50 people for a captive center to have a shot at being successful.

Regardless of whether one goes the captive route or the outsourced route, the distance and time that separate members of a distributed team tend to magnify the effects of everyday challenges to successful projects.

One of the key challenges is what work to hand off and how to hand off that work to the remote location. We’ve learnt that it is important to partition the work so that at least some level of local collaboration and face-to-face can occur, e.g. individual modules being developed by dispersed teams. That said it is important to communicate frequently and regularly. The frequency and intensity of communication across locations can be increased by using a mix of formal and informal communication channels; e.g. using interactive mediums such as IM to create a feeling of connectedness between individuals. Not only does this break down barriers, and foster a one-team feeling, it also leads to a better grasp of the “larger picture” across dispersed teams.

Another very effective tool for motivating individuals and fostering a collaborative spirit across teams is to reward and more crucially recognize achievement. When the context of the distributed development initiative is understood across locations, recognizing achievement and excellence builds awareness and credibility across teams. This in turn leads teams to trust that other team-members are working toward a shared goal and carrying their weight.

Within this collaborative environment, it is also vital to have standard process to perform common tasks, so work across teams can be coordinated effectively. For instance, developing and sharing standard processes for tasks such as application builds, unit testing, release management, software deployment etc. across teams. Here collaborative infrastructure assets would play a critical role, e.g. a wiki or a project portal, to which this information could be published.

A major benefit of adopting and following standardized processes and methodologies is that all team members understand the plan, their role in the plan, and how they affect others in the plan. Many collaborative tools provide some workflow framework, helping teams structure tasks and understand where they are in the development process. Key here is to have rapid feedback cycles to minimize costs. Agile practices and rapid release cycles increase this feedback, and also tend to overcome the command and control-mindset that seem to pervade certain distributed efforts.

A word of caution here. If you are planning to adopt a methodology, internalize it well within the local organization before extending it globally. For instance, if you intend to use global agile, you need to be first agile in your co-located team. You will need to build your expertise and find the sweet spots in your own process before extending it externally. Then you can test the waters in distributed development by identifying pilot projects that would give the most bang for the buck and thereby impress senior management. That’s where the virtuous cycle starts, success feeds on success and you get buy in from senior management and business heads for engagements with greater scope and duration.

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