Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Embedded Systems

Globally Distributed Development


Khurram is responsible for worldwide enablement of the IBM Rational team software tools.


I recall the days when everyone came to one place to work on software development projects. Today, it's not uncommon for teams to work together on entire projects and never meet face-to-face. But while globalization has reduced the frequent-flyer balance of today's developers, it hasn't reduced the risk and complexity involved in successful project delivery.

Nor has the lure of global development and delivery (GDD) gone unnoticed by management. Organizations in every market are using GDD as a competitive variable. Although most IT organizations know what benefits to expect from GDD, they usually are less sure about how to achieve them. Still, that hasn't affected the speed of GDD adoption. Frequently, business demands force IT organizations to take on GDD before they can establish strategies and platforms for success. And as the train leaves the station and the scope and scale of GDD efforts increase, so does the occurrence of failure. This pattern continues until frustration results in organizations concluding that GDD is more trouble than it's worth.

GDD is neither simple nor natural. Software development has always been a team sport. If you separate a project team by geography and organization, you increase the complexity involved in achieving successful outcomes. Yet global flexibility is the core foundation for achieving advantages in cost, time, and quality. To be successful in GDD, you must protect the team aspect of software development.

The foundation for maintaining team cohesion in GDD is a global process framework that provides the orchestration necessary to ensure that global teams sing in tune together. A process framework provides GDD projects with team cohesion and direction without sacrificing the flexibility necessary for agile development. Instead of forcing GDD teams to adopt a single, "common" process for all projects, it provides teams with the ability to adopt methods and best practices that are visible, practical, and governed. The platform ties global teams together and reduces the risk of failure as global development initiatives become more complex. With a global process framework, you can easily codify lessons learned and achieve continuous global process improvement.

But process is of little value without the ability to institute it. In globally/organizationally distributed teams, GDD platforms become a fundamental instrument for success. The platform should be capable of uniting global development teams with process. It must be capable of providing them with the ability to work locally while they collaborate globally. In global development, the natural communication between development team members is greatly diminished. This can introduce gaps in communication and understanding. A platform that keeps the work of the global team connected and available "in context" across the lifecycle can reduce the risk of these gaps turning into misinterpretations.

Global Process Framework

Tacit and informal communication and collaboration on software projects form the bonds for strong team cohesion. This lets local development teams informally self-correct and self-direct their collaboration, communication, and coordination methods. It's not unusual in these teams for process to be perceived as something that makes life difficult, and more burdensome than beneficial. However, process is essential in directing GDD teams because a great deal of active and informal collaboration is lost in the divides between distributed project teams. Process becomes the bridge between GDD teams and provides the direction and orchestration necessary to ensure successful project delivery. Communication and collaboration that normally wouldn't have been formally defined or captured is necessary to reduce the risk of misinterpretation. The value of a process framework increases significantly as the number of teams and organizations involved in GDD grows. That's because a framework still provides GDD projects with the flexibility to select the right methods and process, while providing organizations with the ability to measure, improve, or retire methods and processes appropriately.

It is important to remember that although the analogy of manufacturing has been often related to software development, they are different. When organizations embark in GDD, they shouldn't treat service providers or auxiliary teams as "software factories." Innovative software development requires creative freedom. A focus on "just enough" process is essential for GDD teams to stay creative and innovative. Process shouldn't be so formalized that creative freedom is lost. A global delivery process should focus on what activities need to be performed and who should perform them, but should provide creative freedom between teams on how the activities are completed, so long as the lines of communication remain open and understood by all parties involved.

For example, in defining and implementing a software specification, there is a tendency to believe that the more detailed and precise the specification is, the better the expected results from offshore teams. However, in practice, wasting collaboration and communication time between distributed teams on the clarification of unnecessary implementation specifics and style contribute little to meeting the requirements of the end product. Implementation style is difficult to direct across GDD teams. Agreeing and incorporating common and understood best practices across GDD teams is the best way to establish cohesion on implementation style. Global methods and process should focus a team's energy on managing and communicating the architecture and requirements. It shouldn't waste time defining the step-by-step directions for how distributed team members should do their jobs.

In GDD, a "my way or the highway" attitude to development is rarely effective. Your process framework must enable GDD teams to work as they naturally do. One approach is to first establish a development methodology that your global process framework advocates. To make your framework as versatile, understood, and applicable as possible, it should focus on providing methods that use common industry best practices. You should also include methodology, process, and adoption of best practices as a part of your services procurement selection criteria.

Process engineering and customization has traditionally been a labor-intensive activity with less than stellar practical application. However, the advent of process frameworks and the platforms that automate and enable them can provide GDD teams with the support necessary for successful application. The Eclipse Process Framework (EPF) project (www.eclipse.org/epf) is one process framework definition that provides this facility. To demonstrate the framework, the project includes an exemplar tool (the Eclipse Process Framework Composer) and process content (Open Unified Process/Basic Unified Process). IBM Rational (the company I work for) provides a commercial implementation of EPF with IBM Rational Method Composer (www-306.ibm.com/software/awdtools/rmc), which includes the IBM Rational Unified Process. Microsoft provides its Microsoft Solutions Framework (www.microsoft.com/technet/solutionaccelerators/msf), which is aligned with Visual Studio Team System.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.