Product Engineering Services Customized software development services for diverse domains
Sustenance Engineering Going beyond maintenance to prolong life of mature products
Managed Services Achieve scalability, operational efficiency and business continuity
Technology Consulting & Architecture Leverage the extensive knowledge of our Domain Experts
Other than understanding the organizational and cultural aspects related to application of Agile methods, modification and adaptation of Agile practices to suit the organization’s business context and existing systems and processes is imperative for making Agile work. For companies in the Indian software and IT services sector, these challenges are compounded due to the offshore outsourcing execution model coupled with the increasing trend of fixed price contracting. Fixed Price Model presents additional set of constraints that may make application of Agile while achieving margin targets a difficult goal to achieve. Fixed price for changing scope runs counter to profitability and fixed scope is not considered to be a good example for application of Agile.
This article is about making Agile work in offshore outsourcing model whereby the focus is on Scrum method which is arguably the most popular Agile method and has been used by many organizations for building commercial-grade software. This article describes the pure (or standard) Agile Scrum practices, explores the challenges in making pure Agile Scrum work in offshore outsourcing model and proposes modifications and adaptations (including to the management style and practices) to overcome those challenges especially in case of fixed price projects. The proposed modifications and adaptations are based on real life experience gained while working on Agile Scrum projects in Hughes Systique Corporation (HSC).
SDLC models like waterfall (including its variants), iterative, incremental, V, etc. have been around for last so many decades for software development. Agile methods like Scrum, XP, FDD, etc. have got added to the above list since the last decade. Agile methods claim to be adaptive in nature and are based on the principles enlisted in the Agile Manifesto.
Traditional or pure waterfall (depicted in Figure 1) has multiple phases which are executed in a sequential manner. Some of the key characteristics of traditional waterfall are as given below:
Figure 1 Traditional or Pure Waterfall
In reality, however, pure waterfall is never used due to reasons some of which are given below:
The “real” or modified waterfall (depicted in Figure 2) has the following characteristics:
Figure 2 “Real” or Modified Waterfall
Agile methods are supposedly better at handling changes during software development as they believe in “responding to change over following a plan” [3]. Some of the key characteristics of Agile methods (depicted in Figure 3) include:
Though Agile methods, as depicted in Figure 3 below, look similar to modified waterfall (Figure 2) at a high level, the key difference is the duration of each iteration and the parallelization of phases within individual iterations.
Figure 3 Agile Method
Agile methods work well for small co-located teams facing rapidly changing conditions. These methods can benefit greatly in the following situations:
Scrum is arguably the most popular Agile method and has been used by many organizations for building commercial-grade software. Scrum has found increasing acceptance in the companies in the Indian software and IT services sector for following reasons:
Outsourcing is prevalent since last so many decades. After the Y2K bug, offshore outsourcing of software projects to locations in far away countries like India, etc. has become an important part of the business strategy of many companies, especially in the USA, due to the following reasons:
The offshore outsourcing execution model is a distributed delivery model which has multiple stakeholders as depicted in Figure 4 below.
Figure 4 Offshore Outsourcing Model
The offshore outsourcing model has matured over last so many years resulting in offshore software companies moving up the value chain.
A major trend seen in the past few years in the outsourcing model is the increasing prevalence of fixed price projects [9]. Business managers are attempting to move away from effort-based contracting (time and material) to outcome-based contracting (fixed price). This provides customers definitive figures for their software budget and helps in controlling the IT budget by passing on the risk of inflated costs to the software partner.
The challenges in using Agile in an offshore outsourcing delivery model are compounded due to the impact of individual challenges with using Agile and offshore outsourcing. The list below summarizes the major challenges:
For making agile work in offshore outsourcing the multiple stakeholders (as depicted in Figure 4) need to carry certain responsibilities.
Table 1 Responsibility of Stakeholders for Making Agile Work in an Offshore Outsourcing Model
Other than understanding the organizational and cultural aspects related to application of Agile methods, modification and adaptation of Agile practices to suit the organization’s business context and existing systems and processes is imperative for making Agile work. For companies in the Indian software and IT services sector these challenges are inherent due to the offshore outsourcing execution model they use.
The challenge of using agile in offshore outsourcing is further compounded due to the increasing trend of fixed price contracting which presents additional set of constraints that may make application of agile while meeting agreed contracts and thus achieving margin targets a difficult goal to achieve. This challenge is inherent to Agile method as Agile philosophy is about embracing change which might lead to scope creep thus putting pressure on the initial estimates, approved plans and thus profit margins. Fixed price for changing scope runs counter to profitability and fixed scope is not considered to be a good example for application of Agile.
Though fixed price model suits the product and business managers from budget management perspective, but they need to specify the requirements clearly upfront for the software partner to quote a fixed price. This poses contracting challenges – fixed price implies fixed scope (complete and clear requirements upfront) which is a contradiction to the Agile philosophy where the requirements evolves during the project execution through internal and customer feedback on intermediate releases.
The core issue around Agile in offshore outsourcing with fixed price is measurement and tracking of the scope of the work.
Following approaches are commonly employed in this scenario:
The following sections describe the experiences (including adaptations and modifications to pure Agile) gained at HSC while executing Agile projects in offshore outsourcing model with fixed price. HSC, part of the Hughes group of companies, is a communications consulting and software company. HSC executes large and small projects using different software development methodologies such as the Agile methods as well as the traditional waterfall lifecycle models.
The basic drawback in the second approach in Section 5.2 is that it assumes that a good amount of requirements are available upfront and there will be just a few delta changes during project execution. This assumption may hold true in cases where products are developed or maintained against clearly understood requirements and using proven and stable technologies. However in case of new and innovative products this may not hold true.
The table (Table 2) below lists the adaptations and modifications to the pure Agile scrum as were made while executing projects at HSC.
Table 2 Comparative Analysis of Practices in Pure and Modified Agile Scrum
The figures below depict the pure and modified Agile Scrum.
Figure 5 Pure Agile Scrum
Figure 6 Modified Agile Scrum Cycle for Fixed Price Outsourced Project
Agile treats all sprints as equal where the project team works upon selected user stories and delivers working software to the customer. In the modified approach, Sprint 1 is different as there is no working software that gets delivered. Instead Sprint 1 is focused on laying down overall product architecture, bringing the teams on both sides together and establishing the processes. This Sprint makes sure that everyone comes on the same page in relation to final product business idea and key requirements and gets connected which facilitate the comings sprints execution. This sprint also focuses on the planning and design for the next sprint.
If both the parties are working together for the first time or too new on the product, this sprint can be done in the mutual agreed model and the costing and thus commercial negotiation can be done after this sprint1. This one sprint gives a platform for the team to analyze the high level requirements, do some estimates for the total user points required for the current agreement and the associated process to give points to each user story.
In the modified approach these are regular sprints with certain modifications. In addition to the sprint’s regular work the project team also works on the following activities:
These above approach ensure that the engineering team is productive and fully engaged when they are done with the current sprint. In absence of this, they may get hanged up due to dependency and design closure and may lead to delay in commitment, thus adding delay for the product owner and costing for the software development partner.
The focus of this sprint on fit and finish of the outputs from previous sprints and includes packaging and branding. This sprint would not include any new feature. The duration of this sprint may be less than the regular sprint depending on the features added between customer releases.
The real life experience in executing Agile in offshore outsourcing with fixed price illustrates the fact that modifications and adaptations (including to the management style and practices) to pure Agile practices can help to overcome the challenges in such scenarios.
However, additional experience data is required to conclude in a definitive way what modifications and adaptations can be applied generically enough to different kind of projects in the organization and also to different organizations.
