Raghvinder S. Sangwan, Colin J. Neill, and Phil Laplante

A Framework for Agile Development in Outsourced Environments

Raghvinder S. Sangwan, Colin J. Neill, and Phil Laplante

Engineering Division

The PennsylvaniaStateUniversity

GreatValleySchool of Graduate Professional Studies

Malvern, PA 19355

USA

daniel Paulish, wolfgang kuhn

Siemens Corporate Research

755 College Road East

Princeton, NJ08540

USA

Abstract: - The movement towards globally distributed software development has gathered pace in recent years. This trend coincides with an equally fervent interest in customer-centric, people-oriented agile development that contrasts with the plan- and document-driven approaches that have been the focus of study and application over the last decade. Intuitively we would expect these two trends to be divergent, given the close collaboration and communication required to achieve agility and the massively distributed nature of global outsourcing. It appears, however, that in many US-based IT companies the apparent benefits of both trends are too attractive to ignore and this has led to a convergence of agility and outsourcing. With that aim in mind we have developed a framework of guidelines and process models that supports this new arena of global agility.

Key-Words: -Agile Development, Global Development, Distributed Development, Outsourcing, Offshoring

1Introduction

Gartner and Forrester Research are predicting an increasing trend of US-based IT companies outsourcing their work to offshore development sites [16]. This trend continues despite reports of many projects failing to deliver quality products within budget and on time [9]. Laplante et al. (2004) provide guidelines for strategic decision making that can lead to a successful outcome of an outsourced project [12]. They suggest a collaborative effort with an outsourced partner and the use of a three-tier model where work on project is distributed on-site, loosely on-site or off-site. One must, therefore, define a process that not only manages the collaborative effort effectively but also defines clearly the phases and activities forming a part of the proposed distribution of work. This paper looks at values and principles of agile software development methodologies [14] and proposes ways in which they can be adapted to accomplish these goals.

A standard methodology has four significant stages in the software development lifecycle [1][13].The inception phase is the vision milestone phase wherein the problem to be solved and its potential solutions are investigated to determine feasibility of the project. Once considered feasible, the project enters into the elaboration phase. This is the core architecture milestone phase wherein requirements are prioritized and those deemed architecturally significant implemented first. At the end of the elaboration phase a fairly reliable software development plan is put into place and the construction phase of the software begins. This phase is the operational capability milestone phase since at the end of this phase the software is deployed in the production environment of one or more beta costumers to demonstrate its operational capability. Once operational, the software moves to the transition phase. This is the product release milestone phase as the software product is now generally available in the market.

In an agile process, these phases can span over multiple iterations, each iteration leading to an executable release of a fraction of the complete product. The inception phase typically lasts a single iteration. The number of iterations in the elaboration and construction phases will depend on the size of the project. The transition phase is primarily focused on the product release, and therefore, will have one or two iterations to deploy the product at a beta customer before it is generally available in the market. The length of an iteration is typically 2 – 4 weeks, although longer duration iterations have been suggested for larger projects.

In the following sections we look at the activities of each phase and classify a given activity or a set of activities as likely candidate to be carried out completely off-site, loosely on-site or on-site. Completely off-site implies the offshore development site is fully responsible for an activity, loosely on-site implies the client carries the activity involving its own employees as well as members from the offshore site, and on-site means the client carries out an activity completely in house involving its own employees. The criterion used for the classification of activities is based on the following factors [3]:

• Communication: Distance exacerbates the problem of clearly and unambiguously communicating information between collaborating teams. Therefore, activities must be distributed in way that minimizes communication between such teams. Minimal communication also has a positive impact on coordination and control, the next two factors.
• Coordination: Distance also makes it difficult to coordinate tasks within a distributed development environment. Therefore, the activities must be distributed in a way that minimizes the coordination effort.
• Control: A distributed development environment makes it difficult to enforce common goals, policies, standards and quality levels among collaborating teams. Therefore, activities must be distributed in a way that makes control easier.

We then look at the values and principles of agile development methodologies and how they can be adapted and applied to a given activity or set of activities. Finally, we present an organizational structure allowing for an effective collaboration between the on-site and off-site teams.

2The Inception Phase

The major activities during the inception phase are shown in Fig. 1. These activities occur over the course of a single iteration for small projects or two iterations for larger projects, each iteration lasting about 2 weeks.

Fig. 1Activities in the Inception Phase

The most significant objectives of the activities in this phase of software development are:

• Determine what must be built: A successful accomplishment of this goal requires a clear vision describing the impact of the system under consideration on the target business and a business case describing the return on investment delivered by the system to the customer.
• Determine the most significant system functionality: Fulfilling this objective requires eliciting a set of initial requirements that describe key system functionality, prioritizing the set and analyzing further the architecturally significant requirements to determine the feasibility of the envisioned system.
• Determine the candidate architecture: A series of technical and conceptual proof of concept prototypes must be scheduled to identify the candidate architecture for the system under consideration.
• Determine the risks: A high level project plan must be developed to estimate the schedule and cost of the system to be built. This plan can help identify any cost or schedule risks whereas the activities leading to the candidate architecture can help identify technical and conceptual feasibility risks.

The activities fulfilling a given objective form a cohesive unit requiring closer collaboration and, therefore, effective communication, coordination and control among the people involved. Hence, such activities must be collocated implying that if a given activity from a cohesive unit must be performed on-site then all its related activities must also be performed on-site. Table 1 provides a distribution of activities as on-site, loosely on-site and off-site. Please note that activities associated with a given objective in the table define a cohesive unit.

Establishing a vision and preparation of the Vision document are clearly a task for the major stakeholders of the system, and involves a relatively short period of intense and even emotional interaction, best suited for in-person, on-site meetings. While, ultimately, the product vision needs to be shared across all constituencies, it is neither practical nor appropriate that all stakeholders be involved in the development of this vision because this involves access to high level, and proprietary and sensitive information that cannot be widely distributed.

Similarly, creating a business case is a management function that relies on a relatively short burst of intensive activity. This activity is best left to a small subset of the high-level stakeholders in a set of small on-site meetings.

Objective / Activities / Deliverables / Location
Determine what must be built / Establish the Vision / Vision Document / On-site
Create a Business Case / Business Case
Determine the most significant system functionality / Elicit Requirements / Use Case Model / On-site
Prioritize Requirements
Analyze Requirements / Analysis Model
Determine the candidate architecture / Technical Prototypes / Architecture Description Document / Loosely On-site
Proof of Concept Prototypes
Determine the significant risks / Create a Project Plan / Project Plan / On-site
Create Risk Assessment Document / Risk Assessment Document

Table 1.Distribution for the Inception Phase

In the case of requirements elicitation, prioritization, and analysis, a relatively short period of activity (with respect to the overall software lifecycle) would suggest that an on-site effort is most appropriate. The set of activities involved, including: development of use cases, user stories, Joint Application Development sessions, requirements reviews and walkthroughs, and demonstration of prototypes all involve short bursts of effort and largely require direct customer contact.

Conversely, prototyping construction and planning activities can occur in a loose on-site fashion. That is, the prototypes can be developed anywhere, but the proof of concept is performed on site in conjunction with the customer.

Finally, project planning and risk assessment is an activity that generally needs to be managed on-site. However, there are elements of risk management that can be done off site.

It should be noted that none of these activities fit into the paradigm of agile methodologies and, therefore, it is not surprising that they best fit into a framework where they are implemented by senior level managers at a single location.

3 The Elaboration Phase

The major activities during the elaboration phase are shown inFig. 2. These activities are spread over multiple iterations, each iteration lasting between 2 – 4 weeks.

Fig. 2Activities in the Elaboration Phase

The significant objectives of the activities in this phase are:

• Get detailed understanding of the requirements: The requirements gathered in the inception phase are elaborated to gain detailed understanding of the features and functions of the system under consideration. These requirements are then prioritized based on their criticality, coverage and associated risk.
• Create an executable architecture: Requirements with high risk, criticality and coverage are used for designing the frameworks, application components, application logic and the user interface. These frameworks and components are implemented, tested and integrated into a baseline executable architecture as shown in Fig. 3.

Fig. 3Baseline Executable Architecture

The architecture aims at breaking a complex system into components with well defined interfaces making distributed development easier. Not doing so will lead to a much flatter structure with indeterminate interconnects requiring all team members on multiple development teams working at multiple sites to know many details on many pieces of the system and will require frequent coordination and synchronization. Componentization helps contain teams to discrete tasks on a geographic basis minimizing inter-team communication, an important goal of distributed development [15][19].

• Mitigate the most significant risks: Plan for mitigating schedule and cost risks, and managing requirements that pose a conceptual or technical feasibility risk is formulated.

Table 2 provides the distribution of activities in the elaboration phase.As before, the requirements activities occur on-site. However, activities related to the executable architecture can take place both off-site and on-site. Components can be developed and tested in distributed locations, but must be eventually integrated. While tools are available to allow for builds that span across many sites, it is likely that portions of testing must occur at a single site.

Objective / Activities / Deliverables / Location
Get detailed understand-ing of the require-ments / Elaborate Requirements / Updated Use Case Model / On-site
Prioritize Requirements
Analyze Requirements / Updated Analysis Model
Create an executable architecture / Build an executable architecture (Design, Implement and Test Frameworks and Components / Design Model
Implementation Model
Test Model / Loosely On-site
Integrate and perform integration testing / Baseline Executable Architecture / On-site
Mitigate the most significant risks / Update Project Plan / Updated Project Plan / On-site
Update Risks / Updated Risk Assessment Document

Table 2.Distribution for the Elaboration Phase

Finally, the project planning and risk mitigation activities are largely based on-site, though as mentioned before, some risk mitigation activities are done at the point of attack – where the code is developed.

4 The Implementation Phase

The major activities during the implementation phase of a software product are shown in Fig. 4. These activities are spread over multiple iterations, each iteration lasting between 2 – 4 weeks.

The significant objectives of the activities in this phase are:

• Create a Software Product: The application components, its logic and user interface are designed, developed, tested and integrated using the baseline architecture created in the elaboration phase. It is important to use a uniform development environment for these activities as it will make the development process much easier to track and errors/behavior of the system easier to reproduce from one location to the other [19].
• Create Product Documentation: Installation guides, user manuals and training materials are created.
• Beta Test the Product: A beta site is identified and the software product is tested at that site.

Fig. 4Activities in the Implementation Phase

Table 3 provides the distribution of activities in the implementation phase.

Objective / Activities / Deliverables / Location
Create a software Product / Design, Implement and Test Application Components / Updated Design, Implementation and Test Models / Off-site
Design, Implement and Test Application Logic / Updated Design, Implementation and Test Models / On-site
Design, Implement and Test Application User Interface / Updated Design, Implementation and Test Models / On-site
Integrate and Perform Integration Testing / Updated Test Model / On-site
Create product documenta-tion / Create product documentation / Installation Guides
User Manuals
Training Guides / Loosely On-site
Beta test the product / Prepare a beta customer and perform beta testing / Defect Report / Off-site

Table 3.Distributionfor Implementation Phase

Component level design, implementation and testing can clearly occur at distributed locations. Here each group can adopt their preferred agile methodology (or a highly localized metaphor, to use the eXtreme Programming parlance) as they are effectively working within black-boxes, with respect to each other. Indeed, the practices of eXtreme Programming and its kin, such as stand up meetings, pair-programming, and test driven design, are best implemented locally, and can have specific specializations for each location to accommodate the customs and culture of the site.

Product documentation, again, is not a traditional agile activity. However, just as individual software components can be designed, built, and tested in a distributed manner and then integrated later at a single site, so can the accompanying documentation.

Finally, Beta testing can be performed anywhere that the product can be installed.

5The Transition Phase

Fig. 5shows major activities during the transi-tion phase. These activities are spread over one or two iterations, each iteration lasting between 2 – 4 weeks.

Fig. 5 Activities in the Transition Phase

The significant objectives of the activities in this phase are:

• Make the software product operational: The defects in the beta release of the software are fixed, and the data from the existing system(s) is converted for the new software product. The product is then deployed and run in parallel with the existing system(s). A support plan is drafted to support the customer.
• Cut off from the old to the new product: The users are trained on the new system. The beta customer sign off is obtained and, on an agreed upon date, the customer shuts down the old system and moves all operations to the new system.
• Announce general availability of the product: The new product is made generally available and launched in the market.
• Reflect on the project: The team involved in the creation of the new product reflects on the project and captures the best practices and most valuable lessons learned.

Table 4provides the distribution of activities in the transition phase.

Objective / Activities / Deliverable / Location
Make the software product operational / Fix defects in the beta release / Software Product / On-site
Convert operational databases
Prepare a support plan
Deploy Beta Software Product
Cut off from the old to the new product / Train users / Migration Plan / Off-site
Cut off from the old product
Announce general availability of the product / Launch the product in the market / On-site
Reflect on the project / Capture the best practices and most valuable lessons learned on the project / Best Practices and Lessons Learned Report / On-site

Table 4.Distribution for the Transition Phase

The activities of the transition phase are similar to those in a traditional release-install-support cycle for large enterprise software development. In this regard, emerging standards that provide for a common vocabulary for purpose, process, and terminology are quite helpful. One such standard, the IT Infrastructure Library (ITIL) already has been instantiated in Microsoft’s Operations Framework (MOF) and HP’s Implementation of IT Service Management. These frameworks help foster clear communications across many distributed sites.

Clearly the repair of defects in the beta releases, database conversion, and support plan can be centralized, although some activities, such as the database conversion and support plan writing could be done off site.

User training can be done both on-site (in terms of open training courses) and off-site (in the case of on premise training and consultation). Product cutover from old to new, clearly occurs at off-site at the customer site.