CHALLENGES IN SCALING AGILE SOFTWARE DEVELOPMENT IN OFFSHORING

ENVIRONMENT

Masters Thesis in International Master

in Management of Information Technology

Author:
Suresh Kumar Bhattarai
First Supervisor:
Paul Laifa
Second Supervisor:
Anne Rutkowski
Reader:
Hannu Salmela
06.04.2011
Turku

Turun kauppakorkeakoulu Turku School of Economics

Table of Contents
1

INTRODUCTION ................................................................................................... 7
1.1
1.2
1.3
1.4

Research Background..................................................................................... 7
Research Problem........................................................................................... 8
Research Boundaries ...................................................................................... 8
Organization of the thesis............................................................................... 9

IT OFFSHORING ................................................................................................. 10
2.1
2.2

Introduction .................................................................................................. 10
Models of IT Offshoring .............................................................................. 11
2.2.1 Vendor Partners ............................................................................... 11
2.2.2
2.2.3

2.3

2.4

2.2.4 Captive Center Model ...................................................................... 12

2.2.5 Mixing of two or more models ........................................................ 12
Benefits of IT Offshoring ............................................................................. 12
2.3.1 Cost Savings .................................................................................... 13
2.3.2 Focus on Core Competences............................................................ 13
2.3.3 Improve Quality and Knowledge Transfer ...................................... 13
2.3.4 Time-to-Market ................................................................................ 14
Issues of IT Offshoring ................................................................................ 14
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
2.4.7

Joint Venture .................................................................................... 11

Build-Operate-Transfer (BOT) Model............................................. 12

Lack of Control ................................................................................ 14

Changing Requirements ................................................................... 14
Cultural Differences ......................................................................... 15
Distance ........................................................................................... 15
Language & Communication ........................................................... 15
Staff turnover ................................................................................... 15
Quality ............................................................................................. 16

AGILE METHODOLOGIES ................................................................................ 17

3.1

Introduction .................................................................................................. 17

3.2
3.3

Principals of Agile Methodologies............................................................... 18

Agile Methods .............................................................................................. 19
3.3.1 Scrum ............................................................................................... 20
3.3.2 Extreme Programming ..................................................................... 22
3.3.3 Lean Software Development ........................................................... 23
3.3.4 Feature Driven Developement ......................................................... 25
3.3.5 Dynamic Systems Development Method (DSDM) ......................... 27

3.4
4

SCALING AGILE ................................................................................................. 30

4.1
4.2
4.3

4.4

Adaptive Agile ............................................................................................. 28

Introduction .................................................................................................. 30
Scaling Factors ............................................................................................. 31
Agile Scaling Model (ASM) ........................................................................ 31
4.3.1 Core Agile Development ................................................................. 31
4.3.2 Disciplined Agile Delivery .............................................................. 32
4.3.3 Agility at Scale ................................................................................. 32
Agile Scaling with IT Offshoring Factor ..................................................... 33
4.4.1 Benefits of Agile with IT Offshoring............................................... 33

RESEARCH METHODOLOGY .......................................................................... 35

5.1

Research Strategy ......................................................................................... 35

5.2

5.1.1 Review Research .............................................................................. 35

5.1.2 Survey Research............................................................................... 36
5.1.3 Case Study Research ........................................................................ 36
Data Collection ............................................................................................. 36

RESEARCH OUTCOME...................................................................................... 37
6.1

6.2
6.3

Distribution of Participants .......................................................................... 37

6.1.1 Distribution of Participants for Primary Data Collection ................ 38
6.1.2 Distribution of Participants in Secondary Data ............................... 39
Effectiveness of Agile Methods ................................................................... 40
Answer for Research Questions ................................................................... 41
6.3.1 What are the challenges when scaling Agile Software Development
process in offshoring environment? ................................................. 41
6.3.2 What are the possible solutions for key challenges in scaling Agile
Software Development process in offshoring environment? ........... 43

CONCLUSION ..................................................................................................... 46

REFERENCES ...................................................................................................... 47

List of Figures
Figure 1: Organization of the thesis ............................................................................. 9
Figure 2: (In/Out) sourcing from (on/off) shore (Source: Chakrabarty 2006) ........... 10
Figure 3: IT Project Resolution during 1990s (source: Extreme Chaos 2001)......... 17
Figure 4: Visual of the standard Agile Software Development Methodology (Source:
VersionOne, Inc.) ............................................................................... 20
Figure 5: Scrum Process (Source: Sutherland, J. 2010)............................................. 21
Figure 6: An Overview of Feature Driven Development (Source: Williams 2007) .. 26
Figure 7: The DSDM Development Process (Source: DSDM Consortium 2008) .... 28
Figure 8: Dynamic Speculate-Collaborate-Learn Life Cycle (Source: Highsmith
2002). .................................................................................................. 29
Figure 9: Overview of the Agile Scaling Model (Source: Ambler 2009) .................. 32
Figure 10: Benefits of blending Agile and Offshoring (Source: Forrester Research
Inc. 2004)............................................................................................ 34
Figure 11: Participants by their current position ........................................................ 38
Figure 12: Participants distribution according to their experience ............................ 39
Figure 13: Participants of Secondary Data Collection by their roles ......................... 39
Figure 14: Participants of Secondary Data Collection by their experience ............... 40
Figure 15: Categorization of the Challenges of Scaling Agile in Offshoring
environment ........................................................................................ 42
Figure 16: Categorization of possible strategies in scaling Agile in offshoring
environment ........................................................................................ 45
Figure 17: Graphical Summary for Challenges in Suceeding with scaling Agile in
offshoring environment ...................................................................... 55
Figure 18: Strategies for Scaling Agile in offshoring Environment .......................... 56

Figure 19: Project Success Rate by Development Paradigm (Source: DDJ 2008
Project Success Survey) ..................................................................... 57
Figure 20: Effectiveness of Development Paradigms (Source: DDJ 2008 Project
Success Survey) .................................................................................. 57
Figure 21: Project Success Rate by Paradigm and Distribution Level (Source: DDJ
2008 Project Success Survey) ............................................................ 58

List of Tables
Table 1: Characteristics of agile versus traditional distributed software development
(Source: mite, Moe, and gerfalk 2010) ......................................... 30
Table 2: Different Research Methods (Galliers 1991) ............................................... 35
Table 3: Tabular Summary for Challenges in Suceeding with scaling Agile in
offshoring environment ...................................................................... 55
Table 4: Summary Table for Strategies for Scaling Agile in offshoring Environment56

INTRODUCTION

1.1

Research Background

Long has gone the days, when IT operations were just kept inside on departs or inside a
company. Nowadays, IT Outsourcing has become integral part of Business. Not only Business
firms, But also IT Companies are also utilizing the benefits of IT Outsourcing. IT Outsouring can
be defined as the process of involvement in the partnership with the third parties to perform IT
tasks and process of an organization. Decreasing total cost of ownership of IT-Services, realizing
a strategic focus on central competences, shortening time-to-market for new IT services and
many others factors are the beneficial reasons behind outsourcing (Willekens 2007). With the
evolution of outsourcing, offshoring has become popular option to address factors behind
outsourcing. Carmel & Tija (2005) defines offshoring is shifting of tasks and processes to lowcost nations, which are developing countries or emerging countries (Carmel & Tija 2005, P.
XVIII). As era of Offshoring started, different models of Offshoring evolved for various reasons
such as: nature of business and business objectives of companies, to mitigate the problem of lack
of control and co-ordination, to gain expected quality for the contracted tasks or processes and
many others. Different types of Offshoring models that companies have tried out are establishing
their own captive center, working with vendor partners, entering into a joint venture with
offshore companies, build-operate-transfer (BOT) model, and a mix of two or more of these
models (Machigad & Acharya 2008).Nowadays, many IT companies are expanding to offshore
by setting up their own new subsidiary. IT Companies establish offshore subsidiary in order to
protect IP (Intellectual Property), gain control over the operations, knowledge transfer and
retention, strengthen their presence in local market, and reduce cost (Machigad & Acharya
2008).
At the meantime, Agile Methodologies started to become popular and Seventeen Intellectual
gather together to bring different Agile practices together and developed common principals.
Agile Methodologies was regarded appropriate for small and co-located team and for small projects rather than big ones. But Agile Methodologies were accepted quickly as adaptation of agile
process has significant advantages such as Iterative delivery with small iteration, involvement
and interaction with customer, Flexibility wth changing requirement, test driven development
(Arefin & Korzun 2010). Success rate, Customer satisfaction due to customers active participation, Quality software development started the process for scaling Agile Methodologies in different complex environment such as in large projects, far-located teams and so on. Similarly, Scaling of Agile Methodologies in IT Offshoring environment has become very important due to

increase in offshoring and increase in benefits in software development brought by Agile Methodologies. But just bringing both technique together does not mean significant results. There
remains the challenge of making both technique to co-exist and provide the continuous
governance. Hence, there is challenges to improve in the offshore environment which has
adapted the Agile process for IT project development.
This thesis further describes challenges faced by far-located team in scaling of Agile Methodologies in offshoring environment.

1.2

Research Problem

The research will attempt to answers related with the challenges of scaling Agile software
development process in offshoring environment. The research will try to find critical root causes
that are affecting the Business scaling Agile process in its offshoring environment and then
formulate the solution for the critical root causes affecting scaling process in the organization.
Hence, the research will attempt to provide answer for following questions:

What are the challenges when scaling Agile Software Development process in offshore
sourcing environment?

What are the possible solutions for key challenges in scaling Agile Software Development process in offshore sourcing environment?

1.3

Research Boundaries

Scaling of Agile Software Development happens due to different factors, such as Geographical
distribution, Size of the team, and others. Factors for scaling Agile Software Development will
be discussed in Chapter 4. But before starting with the research, we need to set the scope or
boundaries of the Research. This research att empt to find out the key challenges faced in Scaling
Agile Software Development process in IT offshoring environment and provides the solution for
it on the basis of Researched Organization. Hence, All Scaling factors will not be considered
here, only scaling effects due to IT offshoring is considered. The analysis will solely base on the
work experience in the Researched Organization and on the different documents analyzed during
the research. The primary data will be collected with the individual associated with Researched
Organization. Hence, this research may not be able to cover all types of issue related with scaling
Agile in Offshoring environment. The research will neither focus solely on the offshoring
environment nor only on agile process.

1.4

Organization of the thesis

Figure 1: Organization of the thesis

IT OFFSHORING

2.1

Introduction

IT Offshoring, as shown in Figure 2, can be simply defined as the process of moving IT related
work outside the country. Rise of Internet made it enable to reduce the distance and integration
issues that could have arise when moving out IT related tasks and processes. Slowly, opportunity
arised to reduce the cost of software production drastically by offshoring to low-cost nations.
Hence, Carmel & Tija (2005) defines IT offshoring is shifting of tasks ans processes to low cost
nations, shich are developing countries or emerging countries (Carmel & Tija 2005, P. XVIII).
As era of offshoring started, concept of IT offshoring evolved and Idea of IT offshoring
incorporated cross-organizational boundaries.

Figure 2: (In/Out) sourcing from (on/off) shore (Source: Chakrabarty 2006)

As shown in Figure 2, IT Offshoring included both insourcing (within company by creating

subsidiary) and outsourcing (outside company to vendor). Carmel & Agrawal (2002) defines IT
Offshoring as Offshore Sourcing, which means both offshore outsourcing to a third party
provider and offshore insourcing to its own offhsore subsidiary (Carmel & Agrawal 2002).

2.2

Models of IT Offshoring

As concept of software development went global with IT Offshoring, Software development not
only involved different people in cultural aspects ,time zone differences ,different working
process but also different risks associated with IT offshoring. Then, Business and IT Companies
started to develop different types of model of IT Offshoring according to their business
objectives and the model that will realize them much higher or full benefits of IT Offshoring.
Machigad & Acharya (2008) has come up with following types of IT Offshoring models that IT
Companies and Business have tried out (Machigad & Acharya 2008):

2.2.1

Vendor Partners

In this form of Partnership, IT Offshoring company (Client Company) finds the vendors with IT
Capabilites for the area, which is related with the task that is being offshored. The involvement
in partnership with vendor allows Client companies to concentrate in their own core business
(Vashistha & Vashistha 2005). Companies such as GE, Verisign and American Express has
already used this model of IT Offshoring ( Vashistha & Vashistha 2005).

2.2.2

Joint Venture

Joint Venture is the form of partnership in which two or more companies come together and
involving parties generally have commercial and economical objectives. Joint Venture can
involved local partners and its main advantage is to reduce startup costs and operating risks,
although revenue will be shared (Vashistha & Vashistha 2005).

2.2.3

Build-Operate-Transfer (BOT) Model

In Build-Operate-Transfer Model of Partnership, Offshore supplier builts the offshore unit and it
is transfered after the contracted time span to foriegn Client or in another case offshore unit is
brought by the foriegn client (Vashistha & Vashistha 2005). In BOT model, all assets, operations
and staffs are handed over to the foriegn client. Aetna and AIG followed the BOT model and
now own the subsidiary developed by the offshore supplier (Vashistha & Vashistha 2005).

2.2.4

Captive Center Model

In Captive Center Model, IT companies or Business, who are looking to offshore their IT task
and process, build their own subsidiary in the offshoring nation. The key motivation for
companies to setup their own subsidiary was for Intellectual Property(IP) proctection (Machigad
& Acharya 2008). This model was initially adopted by companies, like GE, when offshoring to
India in early 90s (Machigad & Acharya 2008).

2.2.5

Mixing of two or more models

The models discussed earlier has their own benefits and disadvantages. Hence, Companies
prepare the hybrid model by mixing of two or more models stated above, so that they can take
advantages of the different models. One of the best example is Dedicated Center. Lack of control
and quality issue related with offshoring model Vendor Partners; and Higher cost of seting up
own subsidiary such as captive center, whether it is for single project offshoring or for long term
offshoring, Dedicated Center was a better option for offshoring (Vashistha & Vashistha 2005). In
Dedicated Center model, IT operations are offshore to Vendor partners, but Vendor Partners
provide separate dedicated center with staffs, equipments and facilities for the offshoring client
(Vashistha & Vashistha 2005).

2.3

Benefits of IT Offshoring

Increase in the IT Capabilities allowed the Business and IT companies to offshore their task and
process. But without the real benefits for Business, it was not possible to move the task and
process outside the organizational boundaries. Decrease in the cost of the project was the major

benefits which Business can realized from the IT Offshoring. But gradually other benefits, which
Business can realized, opened up. Here we point out some of those key benefits.

2.3.1

Cost Savings

Moore and Barnett (2004) says that Labor costs (86%) and Project time to completion (37%) are
the major areas where significant cost savings are realized for IT Offshoring projects (Moore &
Barnett 2004). Hence, IT offshoring provides the options for training IT managers to demostrate
their worth to their organization by reducing the cost of IT projects (OLeonard 2005). Cost
savings was considered major benefits for offshoring the IT projects in low cost nation. But, it
alone cannot decide the success of the projects to rip the total benefits of offshoring the IT
projects and other factors such as vendors IT skills, service and support are also other major
factor for project success (OLeonard 2005).

2.3.2

Focus on Core Competences

IT Offshoring can have strategic benefits to the Business and IT Companies. The key strategic
benefit for the Business is the focus on its core competencies and strategic issues while
offshoring non-critical software and project-management functions (Vogel & Connolly 2005). It
also means for non IT-Business, they can offshore their IT related task and process to IT
specialist vendor and they can focus on their non-IT related task and process, which is the core of
their Business.

2.3.3

Improve Quality and Knowledge Transfer

Offshoring creates an environment where collaboration of team members with different cultural,
national, and organizational background cometogether, which in turn increase innovation and
share the best practices (gerfalk et. all 2008). And this kind of sharing best practices and other
knowledge will increase the quality of the project. Also, Nowadays Vendors with CMM Level 5
can be found for the offshoring and they use formal and mature software development processes,
which will assure overall quality and efficieny of the project (Moore & Barnett 2004).

2.3.4

Time-to-Market

The offshoring setup creates the collaboration environment between onsite and offsite to work
for 24 hours a day due to difference in time zone. This process of creating environment for 24
hours software development is called round-the-clock development. This round-the-clock
development allows significant improve in time-to-market (Vogel & Connolly 2005).

2.4

Issues of IT Offshoring

When IT Companies started to offshore their IT task and process to offshore center, they started
to faces challenges, which was critical for the success of IT offshoring. If the issues of IT
Offshoring is not considered before offshoring task and process, then these issues gradually
becomes obstacle and result in failure of the IT offshoring project, which might add cost to the
project itself. Here, we list some of the key issues faced during IT Offshoring.

2.4.1

Lack of Control

When IT task and process are offshored, these operations moves away from the companies and
companies are dependent on the vendor for the true completion of it (Nischat 2008). Hence,
Companies feel lack of control over the completion of the offshored IT task and process. And in
case of incompletion of task within the timeframe specified and incomplete task, Companies face
loss in case of money and value of the project.

2.4.2

Changing Requirements

Client companies always want to built right software, which will provide good value for the
money invested. But when building a new product (software) and also when projects requirement
are not well specified, then changes will come up as development phase move on (Bicer 2007).
Integration of these new changes are essential for building right software, but integration these
new changes will add the cost of the project (Bicer 2007).

2.4.3

Cultural Differences

Generally Cultural differences are ignored, when transitioning onshore process flow and
knowledge, and also when making the communication. Hence, culture difference will raise
integration issues and add up costs and delay (NeoIT 2005).

2.4.4

Distance

Geographical distance, created between the team on onsite and offsite due to offshoring, also
introduce time difference and increase difficulty in the project completion (Palmer & Lawler
2005). Geographical distance introduces travelling cost and while time difference reduce the
communication and co-ordination time between the teams and results in delay in providing
feedbacks and other necessary ideas (gerfalk et. al 2008).

2.4.5

Language & Communication

Communication is the big challenge in itself and in offshoring environment, it is the critical issue
due to communication involved between the far-located teams. And when there is difference in
language then different language styles, and difference in use and understanding of vocabulary
creates miscommunication (Vogel & Connolly 2005). Vogel and Connolly (2005) says that good
communication is essential for accurate understanding of the feature requirements and project
requirement as a whole (Vogel & Connolly 2005).

2.4.6

Staff turnover

Staff turnover is another key issue related with offshoring. Staff turnover has direct impact on
loss of overall knowledge of offshore center if Knowledge is not transfered from terminated staff
to hired staff (Palmer & Lamler 2005). Knowledge management has been challenge in itself for
the Business. Staff turnover also has impact on the ongoing project development and service
needed for maintenace for earlier projects (Palmer & Lamler 2005).

2.4.7

Quality

Although quality is one of the benefits associated with IT offshoring, due to which Business and
IT companies offshore their IT task and Process, Quality of software or project delivered can be
a major issue in IT offshoring. Vogel and Connolly (2005) has describe the experience of one of
the Client company, which was surprised to recieve poor quality of source code, when they were
delivered the software (Vogel & Connolly 2005). Also Vogel and Connolly (2005) quotes
Krishnan Puthucode, head of TUV Rheinlands Software Quality Services, an SEI-authorized
lead assessor for CMM-based assessments, saying that some Indian software companies using
CMM for increasing the market value rather than improving their process as they inflate their
CMM rating from internal assessment (Vogel & Connolly 2005). Hence quality is key issue
associated with IT offshoring.

AGILE METHODOLOGIES

3.1

Introduction

Sureshchandra and Shrinivasavadhani (2008) defines Agile methodologies as which focus on

short iterative release of working software for which there is collaborative team and selforganising team rather than documentation and are responsive to the changing requirement
(Sureshchandra & Shrinivasavadhani 2008). The definition of Agile methodologies, itself defines
the benefits of adapting Agile methodologies in IT project, which address the shortcomings of
traditional software development model. The shortcomings of traditional software development
models can be depicted by Figure 3, which illustrates the success/failure rate of IT project during
1990s.

Figure 3: IT Project Resolution during 1990s (source: Extreme Chaos 2001)

Although, Figure 3 indicates slight increase in Succeeded IT Project and subsequent decrease
in Failed IT Project, large portion in the graph includes IT Projects categorized as Challenged,
which remains same over the years in 1990s. Extreme Chaos (2001) has labeled those completed and operation IT projects as Challenged, which was completed over the estimated budget,
over the estimated time and the included features were less than initially specified feature requirements (Extreme Chaos 2001).
This statement can be further clarified by the Manifesto for agile software development,
developed by 17 software developers at the Snowbird, Utah in Febrauary 2001, which says We
are uncovering better ways of developing software by doing it and helping others do it. Through
this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.
(Manifesto for Agile Software Development 2001).
This has been defined by Shrivastava & Date (2010) as the way to move away from the
heaviness associated with the traditional software development methodologies to become more
productive (Shrivastava & Date 2010). After appearance of Agile methodologies in mid 1990s,
it has been adapted quickly from the start of 21st century as Agile methodologies has been
showing vast superior results in compare to traditional software development process. This fact
can be supported by the finding of a large financial services company, where it has indicated that
use of eXtreme Programming (XP), one of Agile methodologies, has reduced defect rates by
60% and their customer satisfaction was increased by 30%, when used for 6 projects (Moore &
Barnett 2004).

3.2

Principals of Agile Methodologies

When 17 software developers came together in Snowbird, Utah in February 2001, they also
developed principal behind the Agile Manifesto, which are actually the principals for Agile
software development methodologies. The twelve prinicpals given by those software developer
are: (Manifesto for Agile Software Development 2001)

Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.

3.3

Welcome changing requirements, even late in development. Agile processes harness

change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

Agile Methods

Different Practices, which are currently categorized under Agile Software Development
Methodologies, existed before common philosophy was developed by 17 intellectuals during
2001. Hence, these Agile Software Development Methodologies has its own practices but conforms to common philosophy. In Figure 4, VersionOne Inc. has visualized the key characteristics of standard agile software development methodology, which conforms to principals of agile
methodologies.

Figure 4: Visual of the standard Agile Software Development Methodology (Source:

VersionOne, Inc.)
Now, we describe some common Agile Software Development Methodologies, which has
been practiced by agile society.

3.3.1

Scrum

Scrum is an iterative, incremental framework for projects and product or application development (Sutherland 2010). Scrum can be defined as Project management process where projects

progress and are managed in the short iterations. Iterations are called sprints and they are generally 1-4 weeks long. At the start of the project, where a scrum methodology is to be implemented, Product Owner converts the requirement of the project into the features in the Product Backlog. Then, at the start of each iteration, Sprint Planning meeting is conducted, where Scrum Master facilitate between Product Owner and team member for discussion about the features to be
done in the sprint and Team member commits to perform certain features in the sprint, which are
moved to the Sprint Backlog. Features can be broken down into different tasks, depending on the
size of the features. After the start of the sprint, Daily Scrum meeting, which last for 15 minutes,
is held in every 24 hours to communicate three points with other team members: What did you
do after last scrum meeting? Are you facing any obstacles? What will you do before next scrum
meeting? The main aim of this meeting is to control the progress of the sprint. After the end of
Daily Scrum meeting, it may be essential to conduct other meeting to clear the obstacles faced by
any team member. At the end of every sprint, product with new functionalities is achieved. Then,
Team member along with Stakeholder come together for Sprint Review, where what was done in
last sprint is inspected. After review is completed, Team goes for Retrospection, where team
discusses on things that went right and that didnt and ways to improve on the things which
didnt went right. This scrum process is depicted in Figure 5.

Figure 5: Scrum Process (Source: Sutherland, J. 2010)

3.3.2

Extreme Programming

Extreme Programming (XP) is a lightweight, efficient, low-risk, flexible, predictable, scientific,

and fun way to develop software (Beck 1999). But At the same time, Beck (1999) argue that XP
is very disciplined (Beck 1999). XP requires self-discipline and all the practices of XP should be
followed in order to categorize as Extreme Programming. Beck (1999) provided 12 practices for
XP, which need to perform to become XP:

Planning Game

Short Releases

Metaphor

Simple Design
Testing
Refactoring
Pair Programming
Collective Ownership
Continuous Integration
40-Hour Week
On-Site Customer
Coding Standards

In XP, Customer works closely with the development team and helps them by creating smaller unit of functionality, called User Stories, for the project and prioritizing them. Then Development team starts working with highest priority User stories by following the practices mentioned above and delivering the working software on the iteration basis. Although these practices
provides recipe for practicing XP, there are always some values of practices which need to align
with Organization Environment in order to be implement the practice. Beck (1999) also provided
four such values, which are:

3.3.2.1 Communication
Lack of communication among the stakeholders of the projects can jeopardize the projects.
Hence, XP values Communication which is helped by practices such as Pair Programming, task
estimation and Testing, which in turn helps communication among customers, developers and
managers.

3.3.2.2 Simplicity
Simplicity is closely related with Communication value. Increase in Communication will help to
make things simple and clearer. XP also provides practices such as Simple Design, Coding
standards, Refactoring to make project simple and easier to make change and cost of change is
also low.

3.3.2.3 Feedback
Optimism is an occupational hazard of programming. Feedback is the treatment, (Beck 1999).
XP welcomes the changes from the continuous feedback through continuous functionality testing, involvement of the customer in the projects.

3.3.2.4 Courage
As we already said XP is about discipline, while Courage is about maintaining the discipline by
following the practices of XP based on the values defined earlier.

3.3.3

Lean Software Development

The foundation for Lean Software Development is based on the Toyotas Lean Manufacturing
practices, which was developed by Taiichi Ohno, Toyotas Assembly Shop Manager (Harvey
2004). Mary Poppendieck combined her experience of software development with Industrial
Manufacturing knowledge to come up with Lean Software Development along with Tom Poppendieck (Harvey 2004). Lean Software Development focus is to make value stream more efficient in order to deliver higher value to customer. Lean software development is also iterative
methodology. Here, Scope of the project changes continuously as features are changed and prioritized on the basis of its Return on Investment (Denne & Cleland-Huang 2004). The main principals of Lean Software Development during this process are (Poppendieck & Poppendieck 2005):

3.3.3.1 Eliminate Waste

If features do not add some value to the customer then, teams effort should not be wasted on this
activity. Poppendieck (2011) has stated, there are three biggest wastes in software Development:
Building the Wrong Thing
Failure to Learn
Thrashing

3.3.3.2 Optimize the Whole

This principal focus on seeing the full picture i.e. when considering the value added by certain
feature, not only its individual value but also actual effect on whole Value Stream should be considered. The whole Value Stream includes from customer request to deployed working software (Poppendieck 2011).

3.3.3.3 Build Quality In

This principal argues that automated unit tests, integrated tests should be performed along with
the development so that defects in the software should not detected during the verification process. Here, Lean also recommends reducing dependencies in the code to welcome changes swiftly.

3.3.3.4 Deciding as Late as Possible

Predictable Organization develops the capabilities to respond quickly to uncertain future as it
starts to unfold (Poppendieck 2011). But decision should not be made in hurry, so you have to
change it later and it might be expensive to implement the changes. This does not mean, Decision should be made after time.

3.3.3.5 Delivering as fast as possible

In lean, Scope of the project changes continuously as features are changed and prioritized on the
basis of its Return on Investment (Denne & Cleland-Huang 2004). As this will help to increase
the speed of productivity as unwanted feature are avoided and features with higher Return on
Investment (ROI) is deliver earlier.

3.3.3.6 Engage Everyone

Lean Software Development asks to avoid micromanagement and empower the people. Lean
Approach is related with efficient use of team resources and concentrates on enabling the environment for everyone to improve by providing challenge; feedback and making purpose of the
work clear (Poppendieck 2011).

3.3.3.7 Learning Constantly

Poppendieck (2011) says that result is meaningless It is more important to increase the capabilities of human resources and systems constantly in order to achieve result. Even Failure should
be taken as the opportunity to learn and increase individual capabilities. Continuous feedback in
Lean provides another measure for continuous Learning.

3.3.4

Feature Driven Developement

Feature Driven Development (FDD) is a model-driven software development method which is

processed on the basis of short design by feature, build by feature iterations. Overall, FDD
process can be divided into following five main stages (De Luca 2011):
Develop an overall model
Build a features list
Plan by feature
Design by Feature
Build by Feature

Above stages are depicted in the Figure 6. First three stages represent the phase of creation of
features for implementation. Hence, it is very important and requires active participation of customer. After this phase, last two stages represents phase of implementation of features.

Figure 6: An Overview of Feature Driven Development (Source: Williams 2007)

The FDD process is followed by using following eight practices:

Domain Object Modeling

Developing by Feature

Component/Class Ownership

Feature Teams

Inspections

Configuration Management

Regular Builds

Visibility of progress and results

One of the different practices from other Agile is creation of Feature Teams. Feature Team is
a team which is capable of delivery whole business functionality, here, features (Eckstein 2010).
Feature team is used method for scaling the Agile (Eckstein 2010).

3.3.5

Dynamic Systems Development Method (DSDM)

DSDM is considered as formalization of Rapid Application Development (RAD) practices.

DSDM Consortium (2008) defines DSDM as a tool and technique independent framework with
emphasis on the people as most of projects fail due to people issues rather than technology issues
(DSDM Consortium 2008). DSDM follows following nine principals which are confronts with
Agile Manifesto (Highsmith 2002):

Active user involvement is imperative.

DSDM teams must be empowered to make decisions.

The focus is on frequent delivery of products.

Fitness for business purpose is the essential criterion for acceptance of deliverables.
Iterative and incremental development is necessary to converge on an accurate business
solution.

All changes during development are reversible.

Requirements are baselined at a high level.

Testing is integrated throughout the life cycle.

A collaborative and cooperative approach between all stakeholders is essential.

As Principals above outlines that DSDM is also iterative and incremental development, it utilize MoSCoW Rules to prioritize the requirements of projects and plan on iteration and work on
them on iteration basis. Here, MoSCoW is:

M Must have requirements

S Should have if at all possible

C Could have but not critical

W Wont have this time, but potentially later

While, DSDM projects are carried out in five phases:

The Feasibility Study

The Business Study

Functional Model Iteration

Design and Build Iteration

Implementation
Figure 7 depicts the five phases of the DSDM development process. Although, there are four
clear phases in the Figure 7, Feasibility study and Business study is carried out in sequential
manner. Here, in Functional Model Iteration, initial prototype is developed on the basis of prioritized list of requirements. Then, in Design and Build Iteration, Prototypes are refined to meet all
functional and non-functional requirements. Implementation Phase brings out the Systems
(Highsmith 2002).

Figure 7: The DSDM Development Process (Source: DSDM Consortium 2008)

3.4

Adaptive Agile

Adaptive Agile is an approach to move away from just one set of agile practice and adapting
different agile practices according to situation and project. Hence, in Adaptive Agile, on the basis of experience with single agile practices and need of hybrid model, different agile practices
are tailored and adapted when single agile practice is unable to solve problem in different condition. The concept of Adaptive Agile is supported by Martin Fowler, one of the intellectual, who
was involved in developing the manifesto for Agile Software Development. Fowler (2005) says,
Agile methods are adaptive rather than predictive (Fowler 2005) in comparison with other engineering methods. Engineering methods make plan for software process, which work until
changes occurs. But Engineering methods are not change adaptive so changes are not accepted.
While, Agile Methods are change adaptive by principal. Jim Highsmith describes a model of
Adaptive Agile which has four different layers (Hugos 2011):

First Layer Technical skills, which addressed by XP

Second Layer Iteration Management, which can be handled by Scrum

Third Layer Products and Projects, which can be helped by DSDM

Fourth Layer Portfolio Governance, for which Agile Project Management Book can
be utilized
Also, Highsmith (2002) explains his Adaptive Software Development (ASD) is based on continuous adaptation by welcoming the continuous change and also explains the Dynamic Speculate-Collaborate-Learn life cycle for adapting the changes through continuous learning.

Figure 8: Dynamic Speculate-Collaborate-Learn Life Cycle (Source: Highsmith 2002).

Here, Highsmith proposed dynamic life cycle, which adapts the change, as shown in the Figure 8.
Speculate is used here in Dynamic Life cycle in place of static planning, because speculating also
establish a target and a direct but much changes during the life of a project are expected and
welcomed (Highsmith 2002).

SCALING AGILE

4.1

Introduction

Although, Agile Manifesto was formulated in 2001, Agile was still practiced before that. But
only after the formulation of Agile Manifesto and when different Agile Practices came under
Agile Methodologies, Agile practices started to become popular. And Adaption rate of Agile has
been very fast. It has been just a decade after formulation of Agile Manifesto, but Dr. Dobbs
Journals 2008 Project Success Survey (2009) indicated that 76% of organizations already have
one or more projects that follow agile practice. Rapid adoption rate of Agile practices can be
attributed to higher success rates, higher quality, higher return on investment, more satisfied
stakeholders and shorter market time (Dr. Donns Journals July 2009 State of the IT Union Survey 2009).
Generally, agile approaches are thought to be suitable only for small team and generally colocated team. This may be due to need of extensive informal communication and collaboration
required between the team members in agile practices. But, Agile process are being used in different types of organizations, such as financial companies, manufacturers, and others; in different
project teams, such as large project team size, distributed team, complex environment (Ambler
2009).
Characteristics
Communication

Coordination

Control

Agile Development
Informal
Face-to-Face
Synchronous
Many-to-Many
Change-driven
Mutual adjustment, self-management
Lightweight
Cross-functional team

Distributed Development
Formal
Computer-mediated
Often asynchronous
Tunneled
Plan-driven
Standardization
Command-and-Control
Clear separation of roles

Table 1: Characteristics of agile versus traditional distributed software development (Source:

mite, Moe, and gerfalk 2010)
The differences in characteristics between Agile software development and traditional distributed software development indicated in Table 1 provides an idea How challenging it will be to
mold Agile in Distributed environment. Distributed environment is one of the complex areas,
where Agile is being adopted. And these Complex areas have their own unique situation, hence
scaling of Agile in these Complex Area becomes challenging. For this problem, Ambler (2009)

presents the Agile Scaling model (ASM) which is built around on the basics of tailoring agile
methods and practices according to the situation presented by those complex situations.

4.2

Scaling Factors

Before defining the Agile Scaling Model, we list the different scaling factors which create
unique situation as indicated by Ambler (2009), which are:

Team Size

Geographical distribution

4.3

Regulatory compliance
Domain complexity
Organizational distribution
Technical complexity
Organizational complexity
Enterprise discipline

Agile Scaling Model (ASM)

The Agile Scaling Model (ASM) is a contextual framework for effective adoption and tailoring
of agile practices to meet the unique challenges faced by a system delivery of any size (Ambler
2009). The Overview of ASM is depicted in Figure 9. Before scaling of Agile is done through
tailoring it, others initial steps are defined in the model to enter into full-fledged, discipline Agile
Delivery Process (Ambler 2009). The steps in ASM are:

4.3.1

Core Agile Development

In this first step, Core Agile methods such as Scrum and its practices such as scrum meetings
and requirements envisioning are optimized for small, co-located team in simple situation
(Ambler 2009).

4.3.2

Disciplined Agile Delivery

Core Agile Development only addresses part of development lifecycle. So, Disciplined Agile
Delivery Processes such as DSDM are introduced, which cover full development lifecycle
from project inception to delivered system in the production environment (Ambler 2009). This is
also done for small, co-located team in simple situation. This step along with first step brings in
agile discipline within appropriate governance.

4.3.3

Agility at Scale

Now, at this step Agile scaling occurs according to the scaling factors applicable to discipline
agile delivery in step 2. Different scaling factors are indicated at Chapter 4.2. It is important to
understand that those scaling factors are ranges, so applicable scaling factors depends according
to the unique situation of the projects (Ambler 2009).

Figure 9: Overview of the Agile Scaling Model (Source: Ambler 2009)

4.4

Agile Scaling with IT Offshoring Factor

4.4.1

Benefits of Agile with IT Offshoring

We have already discussed about the benefits provided by the Agile and offshoring individually.
But Are there any benefits for the Business to blend Agile and offshoring? Scaling of Agile in
offshoring environment provides some significant benefits for the Business and IT Companies
and those benefits are related with mitigating some of the issues realted with offshoring also.
Avritzer, Bronsard and Matos (2010) defines some benefits realted with scaling in distributed
environment and global projects. Here, we discuss the following relevant benefits associated
with scaling Agile in offshoring environment (Avritzer, Bronsard & Matos 2010):

4.4.1.1 Managing Customer Expectation

Product owner can be representative of the interest of all stakeholders associated with the project
or can be Client himself. And Product Owner is responsible to provide the prioritized list of
features according to its importance. There is a open collaboration between development team
and the product owner and this in turn helps to provide transparency of effort estimation for the
planned features. Also, this is provide continuous and iterative delivery of valuable software to
the customer as development is done on the basis of prioritized features. And also Customer or
Product Owner can continuously add or remove the requested feature from the list.

4.4.1.2 Continuous Integration

Distance created due to offshoring can result in unseen development results and has to wait till
delivery point for visible result. But continuous integration brings transparency of development
results, avoids late integration issues, allows for continuous testing of the project.

4.4.1.3 Unstable Requirements

Due to competitive environment and continuous changing requirements of customer, interest of
stakeholders are also changing continuously and they in turn will affect the features needed to be

included in the project, so that competitive software is developed according to current need.
Agile approach will allow to integrate this changing requirement as short and iterative
development allows to re-phase and reprioiritize the features of the product. While, chaning the
requirements in offshoring is one of the issues associated with the offshoring as we discussed
earlier.
While, according to Moore and Barnett (2004), there are two ways of blending offshore and
Agile Software development and the benefits associated with scaling Agile with offshoring
depends on the type of blending. Blending of Agile and offshoring depends on teams already
doing Offshore or Agile as benefits for adapting another process is different (Moore & Barnett
2004). So it can be categorized as:

Injecting offshore into Agile development projects

Injecting Agile processes into offshore projects

The benefits associated with blending of Agile and Offshoring according to blending model is
shown in the Figure 10.

Figure 10: Benefits of blending Agile and Offshoring (Source: Forrester Research Inc. 2004)

RESEARCH METHODOLOGY

5.1

Research Strategy

Research is the process of using the different research methods available in order to investigate
new or exisitngs question, search for new theories, and review and prove older theories. Hence,
Research methods is key strategy for conducting the research. Here, we try to define the type of
research methods, we have used for this research.
Galliers (1991, p.149) has identified the following different types of research methods, which
are categorized under Scientific Methods and Interpretivist Methods and listed in the Table 2
below:
Scientific Methods
Interpretivist Methods
Laboratory Experiments
Subjective/Argumentative
Field Experiments
Reviews
Surveys
Action Research
Case Studies
Case Studies
Theorem Proof
Descriptive/Interpretive
Forecasting
Futures Research
Simulation
Role/Game Playing
Table 2: Different Research Methods (Galliers 1991)
For this research, we have used following three research methods from the list above:

5.1.1

Review Research

At the first stage ot the research, we attempt to describe agile practices, offshoring, and scaling
Agile and review their benefits and issues also. And this stage is essential for better
understanding of research topic and understanding need to bring the area of agile and offshoring
together. This research forms the basis of the research question.

5.1.2

Survey Research

In this research, we use survey in order to collect the data for quantitative analysis. Quantitative
analysis is done to find the key challenges associated with scaling the agile in offshoring
environment. And also Quantatitive analysis is done to find the strategies for scaling the agile in
offshoring environment. Here, it is essential to perform survey in order to conform the challenges
and strategies with the people associated with scaling the agile in offshoring environment.

5.1.3

Case Study Research

As for this research, survey was carried out on the onsite and offsite of one researched
organization, hence it resemble the case study research. But, this research can be important for
other organization following scaling of agile in offshoring environment.

5.2

Data Collection

For this research, there are two sources of data: Primary data and Secondary data. Primary data
was collected from the onsite location and offsite location of the researched organization.
Collected Primary data includes following section:

Rating the different challenges in succeeding with Scaling Agile in Offshoring

Environment

Rating the different strategies for Scaling Agile in Offshoring Environment

Primary data was collected on onsite by creating online survey. And online survey task was
circulated within the survey population with the help of the task management tool called
taskmind (www.taskmind.net). While the same survey for primary data collection on offsite was
carried out with the help of online communication tool Skype inorder to communicate the main
idea about the questions in the survey and filling the form.
Then, for secondary data collection, survey result found online. This survey was conducted
during early December 2008 and it was conducted by Dr. Dobbs Journal (DDJ) and this survey
can be found in http://www.ambysoft.com/surveys/success2008.html
Both Survey for primary data collection and secondary data collection can be found in the
Appendix 1 & 2 and Appendix 3 respectively.

RESEARCH OUTCOME

In this chapter, we introduce the result of the survey conducted and also introduce the secondary
data that will be used for analysis. Then, we will analysis primary data and secondary data and
use them to support our research and then to answer the research questions that was posted in the
chapter 1.
Now, we will analyze the survey question, we have used to conduct the survey for collecting
primary data. The survey questionaire is provided in the Appendix 1. In the survey, we have
three section. The first section of the survey questionaire is Introduction part, where we collected
information about current position of survey participants and their number of year of experience.
This section will help us to understand the validity of the participants.
While, In second section of the survey questionaire for primary data collection, we try to find
answer for our first research question regarding the key challenges involved in suceeding in
scaling agile in offshoring environment. Here, we have provided six possible key challenges and
ask the participants to rate the challenges on the basis of their experience. Here we have also
provided the option of selecting No Idea in case participants have no experience regarding the
challenge in the question.
Then, In third section of the survey questionaire, we try to find answer for our second
research question, which is possible strategies that can be used for suceeding in scaling Agile in
offshoring environment. Here, we pose nine different questions to the participants and
participants answer the questions on the basis of their expereince categorizing the question
according to its effectiveness. In this section also, participants has been provided the privilege of
selecting No Idea option in case of no experience regarding the scenario in the quesiton.
Now, we will analyze the collected primary data and use secondary data for supporting the
use of Agile Method.

6.1

Distribution of Participants

It is important to analyze the distribution of the population, who has participated in the survey,
involved in both primary data collection and secondary data collection because it provides the
idea whether collected data is valid for the context of the research. Now, Here we analyze the
distribution of participants in primary data collection and secondary data collection according to
their current position and their years of experience.

6.1.1

Distribution of Participants for Primary Data Collection

The number of participants for primary data Collection is relatively low to the number of
participants for secondary data collection as primary data collection was made in single
organization. The main use of collected primary data is use to answer the both research question
regarding the challenges and the possible strategies to address the challenges. So, the question
are related with challenges faced in the operation level on the day to day activity. While
strategies is related with strategic level but they are supposed to implemented on the operation
level to make it smooth. Hence, we have incorporated mostly non-Business stakeholder, which
can be visualized from Figure 11: Participants by their current positionFigure 11. Software
Developer, QA Tester, Project Lead, and others compose about 95% of the total participants.
Position Others included in the survey degines Non-Business Stakeholder role and it can be
role such as Designer, Architect. Hence, Survey is supposed to provide the generalized view
regarding the challenges faced on the operational basis if Agile methods is used in offshoring
environment.

Figure 11: Participants by their current position

The distribution of the participants on the basis of their experience shows relatively higher
number of participants with 0-2 years of experience. But, participants were involved in
answering the question regarding the environment currently they are working on as they are not
asked to make comparison with other working environment in which they might not have been
involved into. Hence, views provided by the participants with less than 2 years are also

considered for the analysis. The distribution of the participants on the basis of their work
experience can be seen in the Figure 12.

Figure 12: Participants distribution according to their experience

6.1.2

Distribution of Participants in Secondary Data

We try to find the effectiveness of using Agile methods using secondary data. So, it is necessary
that distribution of participants in term of roles should be distributed well so that there is fair
view on the effectiveness of the agile both from Business stakeholder point of view and also
from the Non-Business Stakeholders point of view. The distribution of particiants of secondary
data shown in the Figure 13 indicates fair distribution of participants in term of roles.

Figure 13: Participants of Secondary Data Collection by their roles

As secondary data is used to analyze effectiveness of Agile methods in comparison to other
methods, it is necessary the distribution of the participants in term of their experience should
indicate they are experience enough to make comparison between different software
development methods on the basis of their experience of working in those different environment.
The Distribution of the participants for secondary data collection in term of their experience is
shown in the Figure 14, which indicates more than 90% of participants have higher than 5 years
of experience.

Figure 14: Participants of Secondary Data Collection by their experience

6.2

Effectiveness of Agile Methods

We have already analyzed the benefits of Agile Methods when using it with offshoring
environment with different literature reference. But, here we try to provide statistical data
reference to prove the effectiveness of Agile methods which is necessary in order for Agile
methods to be implemented in offshoring environment to reap those benefits. And then we can
analyze the challenges faced in scaling Agile in offshoring environment in order to reap those
benefits.
Here, we use the secondary data from DDJ Project Success Survey 2008 for understanding the
effectivenss of Agile Methods. The secondary data from DDJ Project succss survey 2008 is
attached in the Appendix 3 in graphical form as Figure 19, Figure 20 and Figure 21. Here Agile
is compared with Iterative method, Traditional Method and Ad-Hoc Method. As indicated in
Figure 19, Agile and Iterative methods have comparitively higher success rate than traditional
and Ad-hoc methods. And also Agile and Iterative methods have higher effectiveness in term of
quality, functionality, Money and Schedule than Ad-hoc and traditional methods as shown in
Figure 20. Quality, Money and Schedule are key components in term of successful completion of
projects. And Iterative Development is one of the key principal of Agile Development, so we can
say Agile methods, in general, are more effective than traditional and Ad-hoc methods.
Similarly, When considering effectiveness of Agile methods in different distribution level of
the team, Agile methods has comparatively higher success than other development paradigm
such as traditional and Ad-hoc methods. It can be clear by making comparison between the
average success percentage for all distribution level of team in Figure 21. Hence, depending on
the type of model of offshoring, there may be co-located or far-located team created for the
software development, but success rate of Agile methods used, independent of location of team,
is higher than other methods.

6.3

Answer for Research Questions

6.3.1

What are the challenges when scaling Agile Software Development process in offshoring environment?

Introduction of Agile software development process in offshoring environment is not to mitigate

the issues associated with IT offshoring. Instead, Introduction of Agile helps to reap benefits of
managing customer expectation, handling unstable requirements, and continuous integration, as

we discussed in section 4.4.1, over the traditional software development methodology. But, benefits of Agile in offshoring environment, as discussed in section 4.4.1, helps to mitigate problem
of lack of control and changing requirements, as discussed in section 2.4.1 and section 2.4.2 respectively, associated with offshoring environment. Hence, issues associated with offshoring
environment, which are not address by introduction of Agile, can be key challenges in scaling
Agile Software Development in offshoring environment. So, we have brought those unaddressed
issues in survey for determining the key challenges associated in scaling Agile in offshoring environment, which are Communication, Quality, Staff Turnover, Cultural Differences, Time Difference and Distance as discussed in section 2.4.
Apart from the issues of offshoring environment, when we analyze about Agile Methods in
section 3.1 and 3.2, we can say that communication is essential for Agile as it says Individuals
and interactions over processes and tools. And also emphasis is there on the distance as it also
indicates, The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation in one of its principal in section 3.2. Hence, on
the basis of these analyses, we came up with following possible key challenges, which were used
in survey to be rated by participants:

Communication

Quality

Staff Turnover

Cultural Differences

Time Difference

Distance
Then, survey was conducted to answer first research question regarding the key challenges
involved in Scaling Agile in offshoring environment by using above possible challenges. The
participants of the survey rated those possible challenges in the range of Blocking to Neutral,
while another option was No Idea for the participants with no knowledge about it. The summarized table and graph for the data collected can be found in Table 3 and Figure 17 respectively
under Appendix 2. The analysis of the data in Table 3 shows that Participants have categorized
Communication and Staff Turnover as major challenge, Quality and Time Difference as Average
Challenge, Cultural Differences as Minor Challenge and Distance as Neutral Challenge, which is
indicated in the Figure 15.

Figure 15: Categorization of the Challenges of Scaling Agile in Offshoring environment

Hence, we can consider Communication, Quality, Staff Turnover and Time Difference as Key
Challenge associated with Scaling Agile in Offshoring environment on the basis of survey result.
In the survey result, Distance was categorized as Neutral in term of challenges; this might be due
to increasing number of online communication tools which can reduce the distance such as
Skype and also due to task management tools such as taskmind.

6.3.2

What are the possible solutions for key challenges in scaling Agile Software Development process in offshoring environment?

After possible key challenges for scaling Agile in offshoring environment were formulated, it
was essential to formulate some strategies, which could tackle these possible key challenges.
When formulating possible strategies for these possible key challenges, Challenge for Distance
was not considered as introduction and evolution of highly rich communication tools has made it
possible to have virtual face-to-face communication and reduce the effect of distance. Similarly
as discussed in section 6.3.1, task management software such as taskmind can help to manage the
task through different stage and drastically reducing the distance for managing the task.
Also, Cultural difference and time difference were not considered, when formulating possible
Strategies for the survey. The issue, which could possibly arise due to cultural difference, can be
prevented by understanding the culture of involving parties. The understanding of another culture can be developed by providing the training on cultural difference and learning from another

involved team. But Culture difference is very important factor to be considered, when planning
for offshoring or scaling agile in offshoring environment. Similarly, time difference is another
factor, which influence should be considered, but as discussed in section 2.4.4 reduction of
communication time is key issue arised from the time difference, so we did not prepare strategy
for time difference, but we will go through possibilities of increasing communication.
Hence, we developed possible strategies for succeeding with scaling agile in offshoring
environment by considering three possible key challenges only: communication, quality and staff
turnover. As staff turover is more HR related issue, we did not look for solution to reduce the
staff turnover for the survey. But, we included possible strategy to reduce the impact of staff
turnover by looking for possibilities how we can help starter to develop quickly for knowledge
transfer and quality improvement. Hence, we try to find the impact of bringing experience and
starter employees together in a project for prospect of quick knowledge transfer, Quality control
(better to say quality improvement) and may be obtaining better benefits of XP ( section 3.3.2)
practices in the survey.
And in the search of possible strategies for increase communication, we look for some of the
practices involved in different agile methods that could possibly provides platform for better
communication. Hence, we opted scrum, one of the Agile methods, for possible strategies for
improving communication and iteration management and iteration meeting for communicating
requirements and planning for iteration involving both onsite and offsite team in case of farlocated teams.
Now, we needed to develop some strategies to improve quality, which is our third key
possible challenge. For quality improvement, we need to improve individual development
capabilities, go through probable quality issues in every short period rather than giving those
quality issues to accumulate, and to develop the team which is capable to deliver assigned task in
best quality on both onsite and offsite depending on the nature of offshoring model. Hence, we
introduced use of XP practices, iteration development for quality maintenance, and development
of feature teams as possible strategies in survey for quality improvement.
After we have developed some strategies to address some possible key challenges, we need a
strategy which will regularly inspect whole process of software development and continuously
consolidate the process with feedback from the people working on the process. Hence, we have
used retrospection as another possible strategy in the survey, which brings the idea of inspection
and consolidation.
Then, survey was conducted to answer our second research question regarding the possible
strategies for facking key challenges involved in Scaling Agile in offshoring environment. The
participants of the survey rated those possible strategies in the range of Very Effective to Very
Ineffective, while another option was No Idea for the participants with no knowledge about it.

The summarized table and graph for the data collected can be found in Table 4 and Figure 18
respectively under Appendix 2. The analysis of the data in Table 4 indicates all the possible
strategies formulated were considered as effective or very effective by the participants of the
survey which has been indicated in the Figure 16.
Development of Feature team and Using Iteration meeting for communicating
requirements and iteration planning are considered as very effective strategy by the participants
of the survey. While, other strategies are considered as effective strategy. From the Figure 18 and
Table 4, although it seems survey data for all strategy may be little distributed, survey data is
distributed highly between effective and very effective option. Hence, survey data can be taken
positively regardless of distributed nature of survey result.
Now if we look little deeply on the those selected possible strategies, we can see that there is
mix of different Agile Methods such as XP practices, Scrum and Feature Team Development
(feature of FDD refer section 3.3.4). Hence, Concept of Adaptive Agile (see section 3.4) can also
be implemented in scaling Agile in offshoring environment. So, Different agile methods can be
utilized according to the need of situation, project and issues and thus create the hybrid model
which can work in offshoring environment also.

Figure 16: Categorization of possible strategies in scaling Agile in offshoring environment

CONCLUSION

Hence, we have successfully answered the both Research Question with the help of survey. And
it was partially supported with the use of secondary data also. And we came to conclusion that
we can create Hybrid model of Agile methods due to adaptive nature of Agile to solve the
challenges involved in scaling agile in offshoring environment. So, Adaptive nature of Agile and
possible creation of Agile methods should be considered when scaling agile in offshoring
environment. Agile Scaling Model (ASM), discussed in section 4.3, separate different agile
methods into Core Agile Development methods and Disciplined Agile Delivery methods and
creates hybrid model of Agile methods and describe the scaling method. Whatever model is used
to scale agile in IT offshoring environment, we have described the key challenges involved in
scaling agile in IT offshoring environment, which should be considered for success of scaling
Agile in IT offshoring environment. Also, result on possible strategies shows that although agile
methods demand for increase in communication level, it also provides platform for addressing
communication issues, for example, use of iteration meeting for flow of project requirements and
iteration plans.

REFERENCES

gerfalk, P.J., Fitzgerald, B., Olsson, H.H., and Conchir, E. . 2008, Benefits of Global
Software Development: The Known and Unknown, Q. Wang, D.Pfahl, and D.M.
Raffo (Eds.): ICSP 2008, LNCS 5007, p1-9
Avritzer, A., Bronsard, F., and Matos, G. (2010). Improving Global Development Using AgileHow Agile Processes Can Improve Productivity in Large Distributed Projects. In:
mite, D., Moe, N. B. and gerfalk, P. J. Agile Across Time and Space. Berlin
Heidelberg: Springer Verlag. p133-148.
Arefin, M. and Korzun, D 2010, Improvement of the new agile process for distributed projects,
Chalmers University of Technology
Ambler, S.W. 2009, The Agile Scaling Model (ASM): Adapting Agile Methods for Complex
Environments, Rational software, IBM
Beck, K. 1999, Extreme Programming Explained: Embrace Change, First Edition, ISBN:
0201616416
Bicer, J. 2007, How Fixed Priced Projects can actually increase your risk, septium corporation
Carmel, E. and Tjia, P. (eds) 2005, Offshoring Information Technology: Sourcing and Outsourcing to a Global Workforce, Cambridge university press
Chakrabarty, S. 2006. The Journey to New Lands: Utilizing the Global IT Workforce through
Offshore-Insourcing. In P. Young, & S. Huff (Eds.), Managing IT Professionals in
the Internet Age, 1 ed.: 277-318. Hershey, PA: IGI Publishing
De Luca, J. 2011, Agile Software Development using Feature Driven Development,
http://www.nebulon.com/fdd/index.html. Last accessed 04th June 2011.
Denne, M. and Cleland-Huang, J. 2004, Software by Numbers, Prentice Hall
DSDM
Dr.
Dr.

Consortium 2008, DSDM Public Version 4.2: Introduction to DSDM,

http://www.dsdm.org/version4/2/public/default.asp . Last accessed 04th June 2011.
Dobbs
Journals
July
2009
State
of
the
IT
Union
http://www.ambysoft.com/surveys/stateOfITUnion200907.html
Dobbs
Journals
2008
Project
Success
http://www.ambysoft.com/surveys/success2008.html

Survey

Survey,

Eckstein, J. (2010). Feature TeamsDistributed and Dispersed. In: mite, D., Moe, N. B. and
gerfalk, P. J. Agile Across Time and Space. Berlin Heidelberg : Springer Verlag
. p279-287.

Extreme

CHAOS 2001, Standish Group, Standish Group International Inc.,

http://standishgroup.com/sample_research/extreme_chaos.pdf. Last accessed 04th
May 2011.

Fowler,

M.
(2005).
The
New
Methodology.
Available:
http://martinfowler.com/articles/newMethodology.html. Last accessed 04th June
2011.

Galliers, R. D. (1991). Choosing Appropriate Information Systems Research Approaches: A

Revised Taxonomy. Information Systems Research: Contemporary Approaches and
Emergent Traditions. Nissen, H. E., Klein H. K., & Hirschheim, R. Elsevier Science Publisher. North Holland. pp. 327-345
Harvery, D. 2004, Lean, Agile, Paper for Workshop The Software Value Stream OT2004
Highsmith, J. 2002, Agile Software Development Ecosystems, Addison Wesley
Hugos, M. 2011, Hybrid Agile Moving Agile Development to the Next Level,
http://advice.cio.com/michael_hugos/15587/hybrid_agile_moving_agile_developm
ent_to_the_next_level. Last accessed 04th May 2011.
Machigad, V. and Acharya, K. 2008, Offshore Models for engineering product development:
Captive center Vs Vendor Partner
Manifesto for agile software development 2001, www.agilemanifesto.org
neoIT 2005, HR Challenges with Offshore Captive Centers, Research Summary, Offshore Insights Market Report Series, Volume 3, Issue 2
Nitsch, D. 2008, Analysis of Offshoring and Homeshoring, An Interactive Qualifying Project
Report, Worchester Polytechnic institute
OLeonard, k. 2005, Offshoring E-Learning: What Works, Best Practices for Selcting and
Managinf an Offshore Partnership, white paper, Bersin & Associates
Poppendieck LLC (2011), Lean Software Development: Deliver Value Quickly, Effectively,
Reliably Everytime, http://www.poppendieck.com Last accessed 04th May
2011.
Poppendieck, M. and Poppendieck, T. 2005, Lean Software Development: An Agile Toolkit,
Addison Wesley
mite, D., Moe, N. B., and gerfalk, P. J. (2010). Agile Across Time and Space. Berlin Heidelberg: Springer Verlag. p339.
Srinivasan, J. (2010). Feature TeamsDistributed and Dispersed. In: mite, D., Moe, N. B. and
gerfalk, P. J. Agile Across Time and Space. Berlin Heidelberg : Springer Verlag
. p117-130.

Sureshchandra, K. and Shrinivasavadhani, J. 2008, Adopting Agile in Distributed

Development, 2008 IEEE Internatinal Conference on Global Software Engineering
Sutherland, J. 2010, Jeff Sutherlands Scrim Handbook: Everything you need to know to start a
Scrum project in your organization, Scrum Training Institute Press
Vashistha, A. and Vashistha A. 2005, The Offshore Nation: the Rise of Services Globalization,
Tata McGraw-Hill publishing Company
Vogel, D.A. and Connolly, J.E. 2005, Best Practices for Dealing with Offshore Software
Development, Intertech Engineering Associates, Inc.
Williams,

L.
2007,
A
survey
of
Agile
Development
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

Methodologies,

Willekens, M. 2007, Technology Management Information Technology: Version Platform Outsourcing Nederland, Doctoral thesis, University of Groningen

Appendix 1 Questionaire for Primary Data Collection

Section: Your Introduction
1. What is your current position?
i. Business Stakeholder
ii. Project Lead
iii. Software Developer
iv. QA Tester
v. Others
Your Answer:
2. How many years of work experience do you have?
i. 0 yrs
ii. 0 2 yrs
iii. 2 5 yrs
iv. 5 10 yrs
v. 10 + yrs
Your Answer:

Section: Rate the following challenges in succeeding with Scaling Agile in offshoring environment
1. Communication
a. What is your experience regarding communicating requirements, ideas, question,
knowledge transfer between Agile software development teams in a offshoring
environment?
i. Blocking
ii. Major Challenge
iii. Average Challenge
iv. Minor Challenge
v. Neutral
vi. No Idea
Your Answer:
2. Quality
a. What is your experience regarding the problems associated with the quality of the
system delivered with Agile software development teams in a offshoring
environment?

i.
ii.
iii.
iv.
v.
vi.

Blocking
Major Challenge
Average Challenge
Minor Challenge
Neutral
No Idea

Your Answer:
3. Staff Turnover
a. What is your experience regarding effects of Staff turnover with Agile software
development teams in a offshoring environment?
i. Blocking
ii. Major Challenge
iii. Average Challenge
iv. Minor Challenge
v. Neutral
vi. No Idea
Your Answer:
4. Cultural Difference
a. What is your experience regarding effects of cultural difference with Agile
software development teams in a offshoring environment?
i. Blocking
ii. Major Challenge
iii. Average Challenge
iv. Minor Challenge
v. Neutral
vi. No Idea
Your Answer:
5. Time Difference
a. What is your experience regarding effects of time difference in collaboration with
Agile software development teams in a offshoring environment?
i. Blocking
ii. Major Challenge
iii. Average Challenge
iv. Minor Challenge
v. Neutral
vi. No Idea

Your Answer:
6. Distance
a. What is your experience regarding effects of distance with Agile software
development teams in a offshoring environment?
i. Blocking
ii. Major Challenge
iii. Average Challenge
iv. Minor Challenge
v. Neutral
vi. No Idea
Your Answer:
Section: Rate the following strategies for Scaling Agile in offshoring Environment
1. Following XP practices helps in Technical skills development
i. Very Effective
ii. Effective
iii. Neutral
iv. Ineffective
v. Very Ineffective
vi. No Idea
Your Answer:
2. Use of Scrum for Iteration management and for Better Communication
i. Very Effective
ii. Effective
iii. Neutral
iv. Ineffective
v. Very Ineffective
vi. No Idea
Your Answer:
3. Use of Iteration meeting for communicating Requirements and Iteration Planning
i. Very Effective
ii. Effective
iii. Neutral
iv. Ineffective
v. Very Ineffective

vi. No Idea
Your Answer:
4. Use of Iteration Development for Quality Maintenance
i. Very Effective
ii. Effective
iii. Neutral
iv. Ineffective
v. Very Ineffective
vi. No Idea
Your Answer:
5. Mixing Experience and Starter from offsite in a project team for Knowledge transfer
i. Very Effective
ii. Effective
iii. Neutral
iv. Ineffective
v. Very Ineffective
vi. No Idea
Your Answer:
6. Mixing Experience and Starter from offsite in a project team for Quality Control
i. Very Effective
ii. Effective
iii. Neutral
iv. Ineffective
v. Very Ineffective
vi. No Idea
Your Answer:
7. Mixing Experience and starter from offsite in a project team helps to obtain better benefits of XP practice
i. Very Effective
ii. Effective
iii. Neutral
iv. Ineffective
v. Very Ineffective
vi. No Idea
Your Answer:

8. Development of Feature Team at offsite and onsite (Feature Team is a team which is capable of delivering the features assigned to it without dependence to another team)
i. Very Effective
ii. Effective
iii. Neutral
iv. Ineffective
v. Very Ineffective
vi. No Idea
Your Answer:
9. Use of Retrospection to improve the management and communication process
i. Very Effective
ii. Effective
iii. Neutral
iv. Ineffective
v. Very Ineffective
vi. No Idea
Your Answer:

Appendix 2 Summary of Collected Primary Data

Blocking
Communication
Quality
Staff Turnover
Cultural Differences
Time Difference
Distance

Major
Challenge
14
5
9
6
5
4

Average
Challenge
5
9
6
5
7
5

Minor
Challenge
3
6
2
10
7
6

Neutral
1
2
1
2
4
8

Table 3: Tabular Summary for Challenges in Suceeding with scaling Agile in offshoring environment

Figure 17: Graphical Summary for Challenges in Suceeding with scaling Agile in offshoring
environment

No Idea
1
5

Very
Very
No
Effective Effective Neutral Ineffective Ineffective Idea
Following XP practices helps in Technical skills development
Use of Scrum for Iteration management and for Better
Communication
Use of Iteration meeting for communicating Requirements and Iteration Planning
Use of Iteration Development for Quality Maintenance
Mixing Experience and Starter from offsite in a project
team for Knowledge transfer
Mixing Experience and Starter from offsite in a project
team for Quality Control
Mixing Experience and starter from offsite in a project
team helps to obtain better benefits of XP practice
Development of Feature Team at offsite and onsite (Feature Team is a team which is capable of delivering the
features assigned to it without dependence to another
team)
Use of Retrospection to improve the management and
communication process

12

12

11
8

6
10

3
2

3
2

11

10

10

12

1
1

Table 4: Summary Table for Strategies for Scaling Agile in offshoring Environment

Figure 18: Strategies for Scaling Agile in offshoring Environment

Appendix 3 Graphical Representation of Secondary Data

Figure 19: Project Success Rate by Development Paradigm (Source: DDJ 2008 Project Success
Survey)

Figure 20: Effectiveness of Development Paradigms (Source: DDJ 2008 Project Success Survey)

Figure 21: Project Success Rate by Paradigm and Distribution Level (Source: DDJ 2008 Project
Success Survey)