Challenges In Scaling Agile In Offshoring Environment

7/23/2019 Challenges In Scaling Agile In Offshoring Environment

http://slidepdf.com/reader/full/challenges-in-scaling-agile-in-offshoring-environment 1/58

CHALLENGES IN SCALING AGILE SOFT-

WARE DEVELOPMENT IN OFFSHORING

ENVIRONMENT

Master´s Thesis in International Master

in Management of Information Technol-

ogy

Author:

Suresh Kumar Bhattarai

First Supervisor:

Paul Laifa

Second Supervisor:

Anne Rutkowski

Reader:

Hannu Salmela

06.04.2011

Turku



Table of Contents

1 INTRODUCTION ................................................................................................... 7

1.1 Research Background ..................................................................................... 7

1.2

Research Problem ........................................................................................... 8

1.3 Research Boundaries ...................................................................................... 8

1.4 Organization of the thesis ............................................................................... 9

2

IT OFFSHORING ................................................................................................. 10

2.1 Introduction .................................................................................................. 10

2.2 Models of IT Offshoring .............................................................................. 11

2.2.1 Vendor Partners ............................................................................... 11

2.2.2

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

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

2.2.4

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

2.2.5 Mixing of two or more models ........................................................ 12

2.3 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

2.4 Issues of IT Offshoring ................................................................................ 14

2.4.1

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

2.4.2 Changing Requirements ................................................................... 14

2.4.3 Cultural Differences ......................................................................... 15

2.4.4

Distance ........................................................................................... 15

2.4.5 Language & Communication ........................................................... 15

2.4.6 Staff turnover ................................................................................... 15

2.4.7 Quality ............................................................................................. 16

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

3.1 Introduction .................................................................................................. 17

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

3.3 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 Adaptive Agile ............................................................................................. 28

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

4.1 Introduction .................................................................................................. 30

4.2

Scaling Factors ............................................................................................. 31

4.3 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

4.4 Agile Scaling with IT Offshoring Factor ..................................................... 33

4.4.1 Benefits of Agile with IT Offshoring............................................... 33

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

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

5.1.1

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

5.1.2 Survey Research............................................................................... 36

5.1.3 Case Study Research ........................................................................ 36

5.2

Data Collection ............................................................................................. 36

6 RESEARCH OUTCOME ...................................................................................... 37

6.1 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

6.2 Effectiveness of Agile Methods ................................................................... 40

6.3 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

7 CONCLUSION ..................................................................................................... 46

8 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 1990’s (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



1

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 behindoutsourcing. Carmel & Tija (2005) defines offshoring is shifting of tasks and processes to low-

cost 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 pro-

jects 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 customer’s act ive participa-

tion, Quality software development started the process for scaling Agile Methodologies in differ-

ent complex environment such as in large projects, far-located teams and so on. Similarly, Scal-

ing 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 Meth-

odologies. 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 Method-

ologies 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 Develop-

ment 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 consideredhere, only scaling effects due to IT offshoring is considered. The analysis will solely base on the

work experience in the R esearched 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 offshor ing

environment nor only on agile process.



1.4 Organization of the thesis

Figure 1: Organization of the thesis



2

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 caninvolved 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 forcompanies 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 (O’Leonard 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 vendor’s IT skills, service and support are also other majorfactor for project success (O’Leonard 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 andshare 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 requirementare 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 Cultur al 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 providingfeedbacks 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 staffto 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 Rheinland’s 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.



3

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 self -

organising 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

1990’s.

Figure 3: IT Project Resolution during 1990’s (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 1990’s. Extreme Chaos (2001) has labeled those complet-

ed 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 re-quirements (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 1990’s,

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 alsodeveloped 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.



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 de-

velopment 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.

3.3

Agile Methods

Different Practices, which are currently categorized under Agile Software DevelopmentMethodologies, existed before common philosophy was developed by 17 intellectuals during

2001. Hence, these Agile Software Development Methodologies has its own practices but con-

forms to common philosophy. In Figure 4, VersionOne Inc. has visualized the key characteris-

tics 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 develop-

ment‖ (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 gener-

ally 1-4 weeks long. At the start of the project, where a scrum methodology is to be implement-

ed, Product Owner converts the requirement of the project into the features in the Product Back-

log. Then, at the start of each iteration, Sprint Planning meeting is conducted, where Scrum Mas-

ter facilitate between Product Owner and team member for discussion about the features to bedone 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 didn’t and ways to improve on the things which

didn’t 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 befollowed 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 small-

er unit of functionality, called ―User Stories‖, for the project and prioritizing them. Then Devel-

opment team starts working with highest priority User stories by following the practices men-tioned 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 isalso 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 test-

ing, 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 Toyota’s Lean Manufacturing

practices, which was developed by Taiichi Ohno, Toyota’s 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 Pop-

pendieck (Harvey 2004). Lean Software Development focus is to make value stream more effi-

cient 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 prior-itized on the basis of its Return on Investment (Denne & Cleland-Huang 2004). The main princi-

pals of Lean Software Development during this process are (Poppendieck & Poppendieck 2005):



3.3.3.1 El iminate Waste

If features do not add some value to the customer then, team’s 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 con-sidered. The whole ―Value Stream‖ includes from customer request to deployed working sof t-

ware (Poppendieck 2011).

3.3.3.3 Build Quality I n

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 pro-

cess. Here, Lean also recommends reducing dependencies in the code to welcome changes swift-ly.

3.3.3.4

Deciding as Late as Possibl e

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, Deci-sion should be made after time.



3.3.3.5 Deli ver ing 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 onInvestment (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 envi-

ronment for everyone to improve by providing challenge; feedback and making purpose of thework clear (Poppendieck 2011).

3.3.3.7

Learni ng Constantly

Poppendieck (2011) says that result is meaningless – It is more important to increase the capabil-

ities 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 cus-

tomer. 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 uti-

lize 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 – Won’t 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

ImplementationFigure 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 priori-

tized 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 ba-

sis 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 condi-

tion. 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 en-

gineering 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 ofAdaptive 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 con-

tinuous adaptation by welcoming the continuous change and also explains the Dynamic Specu-

late-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).



4

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. Dobb’s

Journal’s 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. Donn’s Journal’s July 2009 State of the IT Union Sur-vey 2009).

Generally, agile approaches are thought to be suitable only for small team and generally co-

located 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 dif-

ferent 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).Character istics Agi le Development Di str ibuted Development

Communication Informal FormalFace-to-Face Computer-mediatedSynchronous Often asynchronousMany-to-Many Tunneled

Coordination Change-driven Plan-drivenMutual adjustment, self-management StandardizationLightweight Command-and-Control

Control Cross-functional team 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 distrib-

uted 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

Regulatory compliance

Domain complexity

Organizational distribution Technical complexity

Organizational complexity

Enterprise discipline

4.3 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‖ (Ambler2009). 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 Agi le Development

In this first step, Core Agile methods such as Scrum and its practices – such as scrum meetingsand requirements envisioning – are optimized for small, co-located team in simple situation

(Ambler 2009).



4.3.2 Discipli ned Agi le 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 isalso 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 Agi li ty 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 tounderstand 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 isshown in the Figure 10.

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



5

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 forother 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 conductedduring early December 2008 and it was conducted by Dr. Dobb’s 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.

http://www.taskmind.net/

http://www.ambysoft.com/surveys/success2008.html



http://www.taskmind.net/



6

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 inscaling 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 viewregarding 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 highernumber 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 traditionaland 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 chall enges when scaling Agile S oftware D evelopment process in off-

shor ing 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, ben-

efits 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 re-

spectively, associated with offshoring environment. Hence, issues associated with offshoring

environment, which are not address by introduction of Agile, can be key challenges in scalingAgile 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 en-

vironment, which are Communication, Quality, Staff Turnover, Cultural Differences, Time Dif-

ference 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 adevelopment 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

DistanceThen, 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 summa-

rized 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 isindicated 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 possibl e solutions for key chal lenges in scali ng Agi le Software Devel-

opment process in off shor ing envir onment ?

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 cul-

ture 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 far -

located 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 haveused 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



7

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 agilemethods 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.



8

REFERENCES

Ågerfalk , P.J., Fitzgerald, B., Olsson, H.H., and Conchúir , E. Ó. 2008, “Benefits of GlobalSoftware 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 Agile-How Agile Processes Can Improve Productivity in Large Distributed Projects. In:Šmite, D., Moe, N. B. and Ågerfalk, P. J. Agile Across Time and Space. BerlinHeidelberg: 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 ComplexEnvironments‖, 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

Car mel, E. and Tjia, P. (eds) 2005, ―Offshoring Information Technology: Sourcing and Out-sourcing to a Global Workforce‖, Cambridge university press

Chakrabarty, S. 2006. The Journey to New Lands: Utilizing the Global IT Workforce throughOffshore-Insourcing. In P. Young, & S. Huff (Eds.), Managing IT Professionals inthe 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 Consortium 2008, ―DSDM Public Version 4.2: Introduction to DSDM‖,http://www.dsdm.org/version4/2/public/default.asp . Last accessed 04th June 2011.

Dr. Do bb’s Journal’s July 2009 State of the IT Union Survey,http://www.ambysoft.com/surveys/stateOfITUnion200907.html

Dr. Dobb’s Journal’s 2008 Project Success Survey – http://www.ambysoft.com/surveys/success2008.html

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

http://www.nebulon.com/fdd/index.html


http://www.dsdm.org/version4/2/public/default.asp

http://www.ambysoft.com/surveys/stateOfITUnion200907.html



http://www.ambysoft.com/surveys/stateOfITUnion200907.html

http://www.dsdm.org/version4/2/public/default.asp




Extreme CHAOS 2001, Standish Group, Standish Group International Inc.,http://standishgroup.com/sample_research/extreme_chaos.pdf . Last accessed 04thMay 2011.

Fowler, M. (2005). “The New Methodology”. Available:http://martinfowler.com/articles/newMethodology.html. Last accessed 04th June2011.

Galliers, R. D. (1991). “Choosing Appropriate Information Systems Research Approaches: ARevised Taxonomy. Information Systems Research: Contemporary Approaches andEmergent Traditions.” Nissen, H. E., Klein H. K., & Hirschheim, R. Elsevier Sci-ence 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, ―Hy brid Agile – Moving Agile Development to the Next Level‖,http://advice.cio.com/michael_hugos/15587/hybrid_agile_moving_agile_development_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 In-sights Market Report Series, Volume 3, Issue 2

Nitsch, D. 2008, “Analysis of Offshoring and Homeshoring, An Interactive Qualifying Project

Report”, Worchester Polytechnic institute

O’Leonard, k. 2005, “Offshoring E-Learning: What Works, Best Practices for Selcting andManaginf 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 Heidel- berg: Springer – Verlag. p339.

Srinivasan, J. (2010). Feature Teams —Distributed and Dispersed. In: Šmite, D., Moe, N. B. andÅgerfalk, P. J. Agile Across Time and Space. Berlin Heidelberg : Springer – Verlag. p117-130.

http://standishgroup.com/sample_research/extreme_chaos.pdf


http://martinfowler.com/articles/newMethodology.html


http://advice.cio.com/michael_hugos/15587/hybrid_agile_moving_agile_development_to_the_next_level



http://www.agilemanifesto.org/

http://www.poppendieck.com/

http://www.poppendieck.com/

http://www.agilemanifesto.org/







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

Development”, 2008 IEEE Internatinal Conference on Global Software Engineering

Sutherland, J. 2010, ―Jeff Sutherland’s Scrim Handbook: Everything you need to know to start aScrum 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 Methodologies‖,http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

Willekens, M. 2007, ―Technology Management Information Technology: Version Platform Out-sourcing Nederland‖, Doctoral thesis, University of Groningen

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf

http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf



Appendix 1 Questionaire for Primary Data Collection

Section: Your Introduction1. What is your current position?

i.

Business Stakeholderii.

Project Leadiii. Software Developeriv. QA Testerv. Others

Your Answer:

2. How many years of work experience do you have?i.

0 yrsii. 0 – 2 yrs

iii.

2 – 5 yrsiv. 5 – 10 yrsv. 10 + yrs

Your Answer:

Section: Rate the following challenges in succeeding with Scaling Agile in offshoring envi-

ronment

1. Communicationa. 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. Qualitya. 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. Blocking ii. Major Challenge

iii. Average Challenge iv. Minor Challenge v. Neutral

vi.

No Idea

Your Answer:

3. Staff Turnovera. 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 Differencea. 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 Differencea. 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.

Distancea. 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 developmenti. Very Effective

ii. Effectiveiii. Neutraliv.

Ineffectivev. Very Ineffective

vi. No Idea

Your Answer:

2. Use of Scrum for Iteration management and for Better Communicationi. Very Effective

ii. Effectiveiii. Neutraliv. Ineffectivev.

Very Ineffectivevi. No Idea

Your Answer:

3.

Use of Iteration meeting for communicating Requirements and Iteration Planningi. Very Effective

ii. Effectiveiii.

Neutraliv. Ineffectivev. Very Ineffective



vi. No Idea

Your Answer:

4. Use of Iteration Development for Quality Maintenance

i.

Very Effectiveii.

Effectiveiii. Neutraliv. Ineffectivev. Very Ineffective

vi. No Idea

Your Answer:

5.

Mixing Experience and Starter from offsite in a project team for Knowledge transferi. Very Effective

ii.

Effectiveiii. Neutraliv. Ineffectivev. Very Ineffective

vi. No Idea

Your Answer:

6. Mixing Experience and Starter from offsite in a project team for Quality Controli. Very Effective

ii.

Effectiveiii. Neutraliv. Ineffectivev.


Your Answer:

7. Mixing Experience and starter from offsite in a project team helps to obtain better bene-fits of XP practice

i. Very Effectiveii.

Effectiveiii. Neutraliv. Ineffectivev.


Your Answer:



8. Development of Feature Team at offsite and onsite (Feature Team is a team which is ca-

pable of delivering the features assigned to it without dependence to another team)i. Very Effective

ii. Effectiveiii.

Neutraliv. Ineffectivev. Very Ineffective

vi. No Idea

Your Answer:

9. Use of Retrospection to improve the management and communication processi. Very Effective

ii.

Effective

iii.

Neutraliv. Ineffectivev.


Your Answer:



Appendix 2 Summary of Collected Primary Data

BlockingMajorChallenge

AverageChallenge

MinorChallenge

Neutral No I

Communication 14 5 3 1Quality 5 9 6 2 1Staff Turnover 9 6 2 1 5Cultural Differences 6 5 10 2Time Difference 5 7 7 4Distance 4 5 6 8

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

ronment

Figure 17: Graphical Summary for Challenges in Suceeding with 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)

Documents

Challenges In Scaling Agile In Offshoring Environment