In-Depth

Three Keys to Successful Distributed Development

Software development from multiple locations is becoming a fact of IT life. Here are three tips for moving from traditional standalone methods to distributed development environments.

• By Chris Barbin
• 11/01/2005

Whether it’s a byproduct of a merger or acquisition, mandated as a cost-cutting measure, or represents a necessary means to attract and retain top talent, distributed development—where software development teams are dispersed across different locations—is becoming increasingly common. The vast majority of companies—those experiencing a merger, outsourcing development projects, employing remote workers, or leveraging multiple development sites—are impacted by some type of distribution.

It makes no difference whether your development teams are distributed around the world as part of an outsourcing initiative or across town in what used to be a competitor's campus—distribution adds another layer of complexity to the software development puzzle. With complexity comes costs, which in development are often hidden in difficult-to-measure, unanticipated factors such as lost productivity, management overhead, and communications.

Unfortunately, many companies have unrealistic expectations or insufficient processes and infrastructure to adapt to this new development paradigm. To deal with this, some simply adopt inefficient, manual processes (more meetings, more travel, and more Word documents). Others bury their heads in the sand and turn away from the problem because they cannot see a viable solution.

tributed development is here to stay. The challenge for IT management is to plan for the inevitable challenges and new hurdles in operating geographically dispersed development teams. IT must embrace new methods and technologies that will make distributed development both productive and manageable.

A Catalyst for Fundamental Change in Software Development

While other business areas (such as finance, call centers, and sales) have established processes and operational guidelines that ease merging disparate teams and operating across geographies, software development is still generally treated more as an art than as a managed business process. Unfortunately, modern-day software development is often marked by notoriously poor project management, a lack of visibility into and across projects, and a minimal understanding of the development process by operational managers.

If software development is this difficult to manage within the confines of a single engineering floor or wing, imagine the magnitude of dysfunction that arises when these threadbare processes and disjointed operations are saddled with the additional strain of great distances, disparate time zones, multiple platforms, and language and culture barriers.

One published study on development collaboration offers some insight into the high costs that these factors inflict on already-strapped development efforts. The research found that problems that span two or more locations in multi-site projects occur no more often than problems within a single site. The trouble is that these problems take two to four times longer to resolve in the multi-site projects. The researchers also found that developers who rely on information originating from other sites are often left waiting—blocked from making progress on their highest-priority work for an average of five days per month.

Transforming from Craft to Managed Business Process

As companies struggle with the toll that different locations, time zones, and languages exact on software quality, consistency, and time to market, the need to transform traditional software development has taken on greater urgency. To increase productivity and ROI in a world of distributed development, organizations must make fundamental changes in the way they go about developing software.

It is time to stop treating application development as an art and make it a managed business process—a methodology that is automated by technology and carried out by capable teams to be efficient, predictable and successful across geographic or organizational boundaries. Innovative companies that have already taken the necessary steps to transform their development operations have achieved significant results, including increasing the number of software development projects by 30 to 40 percent, decreasing software defects by up to 500 percent, and automating up to 60 percent of development processes.

The first step in this transformation is the creation of effective, repeatable processes. The goal here is to empower teams through consistent practices, including definitions, deliverable templates, and workflow steps. Unfortunately, it is all too easy to over-engineer the process part of the equation, adding to the confusion and complexity rather than reducing it. To avoid this, organizations should start small, focusing on processes that yield quick wins, such as constructing high-level process flow diagrams or establishing a scheduled habit of short (but frequent) meetings to keep communication open. These efforts can evolve incrementally once all teams are operating on the same page.

The second key lever for enabling distributed development is technology. Application lifecycle management (ALM) products can help organizations understand, define, and manage the entire development process. ALM products make it possible for an organization to put their processes into practice by streamlining procedures through automation, enabling team members to be productive within those processes, and providing IT management with visibility and control.

An ALM platform can improve collaboration, connecting each phase of the project lifecycle through a centralized repository that contains all project assets and ensures that all the team members have a consistent and up-to-date view of these assets. Additionally, a fully integrated ALM platform can give each person on the development team a view into projects from their unique perspective, while still maintaining visibility into how their activities impact (or are impacted by) other phases and projects in the organization—regardless of the physical distance between team members.

The final factor in software development transformation must not be overlooked. Processes and technologies are worthless if they sit idle—software can’t be made in a vacuum. It takes people and an investment in making sure those people have the skills they need to be effective. However, just like process improvement, training should not be a one-size-fits-all approach. Training should fit into the environment, learning preferences, and processes in which teams function. It will also need to be continually refreshed and updated, to ensure that the team keeps pace with the lessons the organization will inevitably learn.

Finding Success

The shortcomings of current development processes—whether distributed or centralized—cannot be solved with a single tool or a few templates. However, organizations willing to commit to a comprehensive, integrated effort that will establish the appropriate processes and align them with the right training and technology infrastructure can begin to create significant value within months. Most organizations achieve substantial development performance improvements in 12 to 18 months. Further, enterprises often see that the pressures created by distributed development will catalyze transformation across the IT organization.

Distributed development is a new addition to our vernacular, something that is disruptive and challenging. One day, all software teams will be dispersed, and we'll simply use the term development. Look around your company or pick up a trade publication. Globalization, virtualization, consolidation. All of these trends lead us further away from a reality where corporate applications are developed and delivered by a singularly located team.

Yes, distributed development presents us with challenges, but it also represents a great opportunity: to take the art of software development to the next level.