7/28/2019 p110-hossain

1/10

Towards an Understanding of Tailoring Scrum in GlobalSoftware Development: A Multi-case Study

Emam HossainThe University of New South Wales

Kensington, NSWAustralia

+61 423 918 804

Emam.Hossain@nicta.com.au

Paul L BannermanNICTA, Eveleigh, NSW, Australia

The University of NSW,Kensington, NSW, Australia

+61 2 9376 2169

Paul.Bannerman@nicta.com.au

Ross JefferyNICTA, Eveleigh, NSW, Australia

The University of NSW,Kensington, NSW, Australia

+61 2 9376 2188

Ross.Jeffery@nicta.com.au

ABSTRACT There is growing interest in applying Scrum practices in GlobalSoftware Development to leverage the advantages of both.However, the effective use of Scrum practices largely depends onclose interactions between project stakeholders. The distribution

of project stakeholders in GSD provides significant challengesrelated to project collaboration processes that may limit the use of Scrum. However, project managers increasingly seek to use theScrum model in their distributed projects. While there is anemerging body of industrial experience, there are limitedempirical studies that discuss Scrum tailoring in GSD. The paperreports a multi-case study that investigates the impact of keyproject contextual factors on the use of Scrum practices in GSD.This study is relevant to researchers and practitioners who areseeking ways to use Scrum in GSD and improve projecteffectiveness.

Categories and Subject Descriptors D.2.9 [Management ]: Software Process models, programmingteams.

General Terms Management, Economics, Theory.

KeywordsGlobal Software Development, Scrum, Case study.

1. INTRODUCTIONThere is growing interest in applying Agile practices in GlobalSoftware Development (GSD). Among the Agile methodsavailable, an increasing number of project managers areconsidering using Scrum as an Agile project management methodin their distributed projects [1]. However, the effective use of Scrum practices significantly depends on close interactionsbetween project stakeholders. In GSD, geographical, temporal and

socio-cultural distances create challenges that may restrict teamcollaboration [2]. Moreover, other GSD project contextual factorsuch as project personnel, number of distributed sites, and producdomain may further exacerbate team collaboration [1]. As a resulsome researchers note that Scrum is difficult to scale up to suppodistributed arrangements [3] and the fundamental question owhether Scrum practices can be used in a distributed setting habeen a subject of debate [4].However, despite apparent significant differences between thefundamental principles of Scrum and distributed development, Systematic Literature Review (SLR) found success cases in usinScrum practices in GSD [1]. However, the SLR findings indicatethat in most GSD projects, Scrum use was adapted to fit thecircumstances of the project [5, 6]. The study also found thaempirical research on the use of Scrum in GSD is scarce and thadescription of how project contextual factors impact the tailorinof Scrum in distributed projects in the literature is limited [1].Nevertheless, the Scrum model offers the potential of improvedvisibility and control over distributed developments through itpractices of frequent development and review iterations andcollaborative communication between developers. Thereforegiven the relative novelty of the phenomenon and the paucity othe empirical evidence, there is a need for more empirical studieto better understand how Scrum might be tailored to operateeffectively in GSD projects. Specifically, this paper considers thimpact of key project contextual factors in tailoring the Scrummodel for GSD.A multi-case study design is used for the study. Four GSDprojects in which Scrum practices were used are examined for thinfluence of project-, team- and distance-specific contextuafactors on the adaptation of the Scrum model deployed. Thesfactors are based on an analytical framework developed in [19]The research is important and relevant to both researchers andpractitioners in understanding how an emergent softwaredevelopment management method might be extended beyond thbounds of its original operating setting to bring similar benefits tGSD.The paper is structured as follows. Section 2 provides backgrounto the research and Section 3 describes the research methodologused. Section 4 describes the four cases and provides initiawithin-case analysis and Section 5 details the cross-case analysiFinally, Section 6 discusses the limitations and implications of thstudy and reaches conclusions about its contributions.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.

ICSSP11 , May 2122, 2011, Waikiki, Honolulu, HI, USA.Copyright 2011 ACM 978-1-4503-0580-8/11/05$10.00.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for prot or commercial advantage and that copiesbear this notice and the full citation on the rst page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specicpermission and/or a fee. ICSSP 11, May 2122, 2011, Waikiki, Honolulu, HI, USACopyright 2011 ACM 978-1-4503-0730-7/11/05 ...$10.00

110

7/28/2019 p110-hossain

2/10

2. RESEARCH BACKGROUNDThis section briefly reviews the literature on the Scrum method inGSD and the research context of the study.

2.1 Scrum Method in GSD

GSD (including outsourcing and partnerships across nationalborders) is a major trend in software development. It has gainedsignificant adoption as a means of reducing time to market,increasing productivity, improving quality and gaining costeffectiveness and efficiency [7]. In addition to these expectedbenefits, however, several challenges of GSD have also beenidentified [8]. In particular, GSD is normally characterized bystakeholders from different national and organizational cultures,located in separate geographic locations and time zones, usingdifferent information and communication technologies tocollaborate. Such conditions usually result in major problems inrelation to team communication, coordination and collaboration[9]. Furthermore, key project-specific, team-specific and distance-specific contextual factors may also impact on team effectiveness[1]. These include, for example, the nature of the contract;application domain; requirements volatility; project personnel;distribution of sites; team experience; and temporal, geographicaland socio-cultural distance between partners and sites [1].Scrum is an iterative and incremental project managementapproach that has a number of practices that largely depend onclose interactions between developers, business stakeholders andcustomers. Indeed, [10] claims that a major reason for the successof Scrum is the collocation of development team members. Thisinteraction is difficult to achieve in GSD. However, Scrum is aflexible Agile method that can be tailored according to the projectcontext [11]. Despite apparent and significant differences betweenthe fundamental principles of Scrum and distributed developmentapproaches, there is a growing interest in assessing the viability of using Scrum practices for GSD [1]. One recent empirical studyfound that using Scrum practices in GSD improved

communication, trust, motivation and product quality [5]. Inaddition, industry experience suggests that using Scrum practicespromotes communication and collaboration, ensures frequentdelivery of product and provides an opportunity to reduce someGSD challenges [6]. To identify Scrum practices that can be usedin GSD, we examined a number of studies (e.g. [5], [12], [13])and chose the seven Scrum practices identified in [5], asindicative of Scrum use in GSD for examination in our study.These practices are: sprint, sprint planning, daily Scrum, Scrum of Scrums, sprint review, retrospective, and backlog.

2.2 Research ContextCommunication and collaboration processes are at the heart of using Scrum practices. However, GSD project contextual factorsmay create additional challenges that restrict the use of Scrum

practices [1]. Some solutions have already been proposed in theliterature for using Scrum in GSD. Sutherland et al. [6] proposethree Scrum models that can be used in GSD: isolated Scrums;distributed Scrum of Scrums and; totally integrated Scrums. Forexample, in their proposed distributed Scrum of Scrums model,the Scrum team is geographically separated but integrated by aScrum of Scrums practice. Similarly, in a totally integratedScrum model, Scrum teams are cross-functional with teammembers distributed across geographical locations. In addition, arelated stream of research has focused on the tailoring of Agilemethods to the actual needs of the GSD context. For example, one

approach suggests developing hybrid Scrum and plan-baseddevelopment methods, with criteria for deciding when (underwhat conditions) each should be used [14]. Moreover, a number opractitioners more generally suggest that the effective use of Agillargely depends on the tailoring process in GSD [2, 4, 15].

Despite some discussion of the tailoring of Scrum methods inGSD, there is little focused empirical research on tailoring in GSin the literature [1]. To contribute to this research gap, theobjective of our research is to explore and understand how Scrumpractices are used (based on the seven practices identified in [5]and how project contextual factors impact the tailoring of Scrumpractices in GSD projects (based on the key project contextuafactors in [19]). We also investigate how collaboration tools andsupporting mechanisms are used in tailoring the Scrum practices.

3. RESEARCH METHODOLGYInvestigating the research problem in this study requires rich andeep description of GSD projects using Scrum practices in actuaindustry settings. Case studies are the preferred strategy for thitype of study; that is, for when (a) how or why questions arbeing posed, (b) the investigator has little control over events, an(c) the focus is on a contemporary phenomenon within some reallife context [16, p3]. To carry out the study we followed Yinsguidelines [16]. This started with development of a researchprotocol as a record of the procedures to be followed. This helpemaintain consistency and reliability in the research. The unit oanalysis is a Scrum practice used in GSD. We used purposefusampling, selecting projects that involve software developmenusing Scum in a global setting. To preserve privacy, identities arwithheld and the four selected projects are given pseudonymsPaperInfo, EnergyInfo, CollaborationSoft, and TestSoft.The primary source of data was interviews, supplemented byinformal conversations, observations, tool demonstrationsdocumentation and photographs. Fifteen semi-structuredinterviews were conducted; each lasting 1-2 hours. The interviewwere carried out by two researchers, one interviewing and theother taking notes. Most interviews were conducted face-to-facin industry settings. For PaperInfo, the onshore-based projecmanager and architect were interviewed. The offshore-based teamlead and architect were also interviewed via Skype. ForEnergyInfo, the onshore-based project manager, team lead,process manager and offshore Scrum master (on an occasionwhen he was visiting the onshore site) were interviewed. FoCollaborationSoft, four project team members were interviewedincluding the onshore-based project manager. For TestSoft, theproject manager was interviewed and two offshore team membervia Skype. Documents made available to the research teamincluded system specifications, project plans, testing scripts anthe completed software. Documentary information was also useto corroborate (triangulate) and augment evidence found from thinterviews and discussions that focused on the use of Scrumpractices in distributed projects. The raw data was stored in ananalyzed using NVivo7 (a qualitative data analysis tool), as thecase study database.Data analysis comprised qualitative content analysis [17]complemented by framework analysis [18] aimed at identifyingdescribing and making sense of how Scrum practices weretailored by considering the influence of key project contextuafactors. NVivo7 was used for coding, grouping and analyzing thetextual data. Evidence was categorized according to relevan

111

7/28/2019 p110-hossain

3/10

themes and apparent relationships. The coded data (with crossreferences to sources) was then charted to summarize the findings.Charting helped to understand the whole dataset. To improve thequality of the analysis, initial findings were reported to the keyinformant on the project (the Project Manager/Scrum Master),who provided feedback identifying omissions and rectifyingmisunderstandings.Case study design was based upon the four criteria recommendedby Yin [16] for ensuring high integrity case study research. First,construct validity , which involves establishing valid operationalmeasures for the concepts being studied, was facilitated by usingmultiple sources of evidence, establishing a chain of evidence,and having key informants review draft case study reports.Second,internal validity was supported by use of three forms of triangulation: multiple data types (interviews, documents, etc.);multiple sources within type (multiple team members, multipledocuments, etc.), and; observer triangulation. For the third,external validity, the multi-case design enhances the possibility of generalizing findings but the study aimed only to generalize totheory, not to other settings. Finally, reliability was supported by

use of a case study protocol and a case study database: a detailedcase study protocol was developed, tested and applied consistentlyacross all cases, and; NVivo7 was used to ensure consistency inhandling, coding and analyzing data from each case and enablechains of evidence to be established.

4. CASE DESCRIPTIONSUsing the framework developed in [19], the key project contextualfactors characterizing the four projects are summarized in Table 1and the Scrum practice utilization is summarized in Table 2. Eachproject is described, following.

4.1 PaperInfoWe start by describing the PaperInfo development project.

4.1.1 Project DescriptionPaperInfo is a project of a global supplier of process industrymachinery and systems. The project was part of a large productdevelopment comprising different projects that produced bothhardware and software products. The project contributed to thedevelopment of an information system product to maintain qualitycontrol in paper mill industries. Many large customers all over theworld use the product. Requirements changed moderately duringthe project. The project was distributed in two countries: Finlandand an offshore country (see the project structure in Figure 1). Thefour-person domain knowledge-based Finnish team included theproject manager/Scrum master, project architect, developer andtest engineer at one onshore location. The main roles of theonshore team were to maintain the product backlog, generate andmaintain specifications for the offshore development teams

sprints (the sprint backlog), and verify the quality of completedsoftware before delivery to customers. Due to its domainexpertise, the onshore team also did some development thatrequired specific domain knowledge. The onshore team washighly experienced. For example, the project manager had overthirty years experience in software development. The six-personoffshore team was distributed across three sites in the offshorecountry. Two people were located at each site. All six workedtogether as a single Scrum team. The offshore development teammembers experience varied from six to ten years.

The project involved temporal, geographical and socio-culturadistances. The sites spanned multiple time zones. The main ananother offshore site were one hour ahead of the Finnish site andthe third offshore site was four hours ahead of the other twooffshore sites (i.e., five hours ahead of Finland). Hence, theproject featured a low temporal distance (less than four hoursexcept for one offshore site (less than eight hours). There was ndirect flight between the onshore and offshore main site, resultinin a flight time of five hours. Travel was further exacerbated aone of the offshore sites needed an additional four hours flightime. Therefore, based on the main offshore site, it can beconcluded that the project experienced moderate geographicadistance (less than eight hours). Based on Hofstedes indices osocio-cultural distance [20] and participant opinions, the projecexperienced significant socio-cultural distance.

Figure 1. PaperInfo Project Structure

4.1.2 Use of Scrum PracticesScrum was adapted to suit the project. Some practices were usein a pure distributed form (sprint, daily Scrum and backlog)some were tailored (sprint planning, Scrum of Scrums and sprinreview) and others were rarely used (retrospectives).Sprints weremostly standardized. Initially, sprint length varied from 2-4 weekbut after a few cycles they were fixed at 4 weeks. However, thlength of some sprints had to be modified to accommodatedifferent holiday practices between the two countries.Sprint

planning was also adapted. At the beginning of the sprint, a sprintpre-planning meeting was held (called a goal introductionmeeting), in which the onshore team presented the goals andprioritized backlog for the upcoming offshore sprint throughOffice Communications Server (OCS) and Live Meeting toolsThis meeting lasted for 1-2 hours and was recorded. In themeeting, offshore team members were able to ask relevantquestions to minimize misunderstanding. The offshore team theconducted its internal sprint planning meeting using Skype, whiclasted for up to 4 hours. During this meeting, the offshore teamcould replay the recorded goal introduction meeting if needed

or communicate with onshore team members through OCS toclarify any issues. The next day, the offshore team presented theidetailed sprint plan to the onshore team in a plan introductionmeeting, lasting thirty minutes, through OCS and Live MeetingIn this meeting, the onshore team verified the offshore teams plaand provided feedback as necessary. Based on the onshorefeedback, the offshore team finalized its sprint plan and developethe sprint backlog in Team Foundation Server (TFS) tool.

112

7/28/2019 p110-hossain

4/10

Table1. Key project contextual factors

Contextual Factors PaperInfo EnergyInfo CollaborationSoft TestSoftProject SpecificContract nature Product DomainRequirements changes

Offshore SubcontractorAutomation industryModerate

Offshore SubcontractorAutomation industryModerate

Intra-organizationalEnterprise software solutionsModerate

Intra-organizationalTelecommunicationLow

Team Specific Project personnel(team size)

Distributed sitesExperience

10 (onshore management team 4;offshore development team 6)

4 (onshore 1; offshore 3)Highly experienced managementteam; development teamexperience varied from 5 to 15years

11 (onshore management team 4;offshore development team 7)

2 (onshore 1; offshore 1)Highly experienced managementteam, offshore development teammostly inexperienced

15 (onshore management anddevelopment team 11; offshoredevelopment team 4)2 (onshore 1; offshore 1)Highly experienced managementteam; low experienceddevelopment team (varied from 1to 5 years)

15(management team 1; offshoredevelopment team 14)

4 (onshore 1, offshore 3)Highly experienced managementteam, mostly experienceddevelopment team (varied from 1to 15 years)

DistanceTemporal

Geographical

Socio-cultural

Low (1 hour); except 1 offshoresite (5 hours)Moderate distance; Finland and anearshore country, 5 hours flighttime, one of the offshore siteneeds 9 hoursSignificant; differences inlanguage, culture and norms

Low (1 hour)

Moderate distance; Finland and anearshore country. Moderatedistance, 5 hours flight time

Significant; differences inlanguage, culture and norms

High (19 hours in winter and 17hours in summer)High geographical distance;Australia and US more than 15hours flight time

Low; similar language, cultureand norms

High (no overlapping workinghours between two of the sites)High geographical distance;Finland, Germany, India andBrazil. flight time from India toBrazil 30 hoursSignificant; differences inlanguage, culture and norms

Daily Scrum was used in a standard manner by the distributedoffshore team via Skype. The meeting focused on answering thethree standard Scrum questions: What has been accomplishedsince the last meeting? What is going to be done before the nextmeeting? and What obstacles are in the way? Questions anddiscussion between team members then followed. The meetinglasted 5-15 minutes depending on the extent of discussion.Theonshore team did not participate in the daily Scrum as their focuswas on generating and maintaining project specifications.Theoffshore teams operated as a single Scrum so theScrum of Scrums practice was not used. However, to stay on track, update theoffshore team with any changes and resolve any cross-site issuesand dependencies, the onshore and offshore Scrum masters held aweekly status meeting via Skype. This meeting served as a proxyfor a Scrum of Scrums meeting.The sprint review practice was also tailored. At the end of thesprint, rather than hold a traditional review meeting, thecompleted code from the sprint was released to the onshore testengineer for acceptance testing. Retrospectives were held in theinitial 5-6 sprints using OCS. However, the practice wasdiscontinued because the Scrum model was working effectivelyand any issues or changes could be adequately handled throughthe other meetings. Thebacklog practice was used in the project.The onshore site developed and updated the product backlog,maintained in TFS using ScrumWorks. At the beginning of thesprint, the backlog was prioritized in the sprint pre-planningmeeting. Based on this meeting, the offshore team then developedthe sprint backlog, also in TFS. During the sprint, the developersmaintained the status and updated the remaining time of the

allocated tasks on a daily basis. TFS was also integrated with theburndown chart, indicating project progress.

4.2 EnergyInfoNext, we describe the EnergyInfo development project.

4.2.1 Project DescriptionThe EnergyInfo project was part of a large product developmentat the same company as PaperInfo but involved a different productline. The project developed an information system to control apower, energy and oil refinery system. It was a new developmentthat had moderate change requirements. The project manager

hired a subcontractor company from a nearshore country as themain development team. As in PaperInfo, the project wasdistributed in two countries: Finland and the same offshorecountry (see the project structure in Figure 2). The Finland-basefour-person onshore team held the project domain knowledge. Icomprised a product owner/project manager, architect, technicalead and test engineer. The onshore management teams main taswas to generate and maintain specifications provided to theoffshore development team. However, due to the offshore teamslack of domain knowledge, the onshore team also did somedevelopment that required domain knowledge. The seven-persooffshore team comprised the main project developers. Experiencvaried. The onshore team had over ten year experience in softwardevelopment. However, the offshore team was less experiencedalthough the development lead also had more than ten yearexperience in software development.As the project was distributed (similarly to the PaperInfos mainonshore and offshore sites), it involved temporal, geographicaand socio-cultural distances similar to those of PaperInfo.

Figure 2. EnergyInfo Project Structure

4.2.2 Use of Scrum PracticesAs in PaperInfo, Scrum was adapted to suit the circumstances othe project. Some practices were used in a distributed form (sprinsprint review, backlog), some were used in a collocated form(daily Scrum), others were tailored (sprint planning), and some

113

7/28/2019 p110-hossain

5/10

Table 2. Summary of Scrum practice usage in case projectsPractice

CaseSprint Sprint

planning Daily Scrum Scrum of Scrums Sprint review Retrospective Backlog

PaperInfo Used (lengthinitiallyvaried; thenfixed at 4weeks)

Use modified(added pre- andpost-planningmeetings withonshore team)

Used (by offshoredistributed teams viaSkype; onshore teamnot directlyinvolved)

Use modified(weekly statusmeeting betweenonshore projectmanager andoffshore team lead)

Use modified(reviewed byonshore-based QAteam)

Ultimately notused (used ininitial sprints butlater discontinued)

Used (maintained inScrumWorks); productbacklog maintainedonshore; sprint backlogdeveloped and burndownchart maintained byoffshore Scrum team

EnergyInfo Used (lengthinitiallyvaried; thenfixed at 1.5weeks)

Use modified(held anadditional sprintpre-planningmeeting)

Used in collocatedform (used byoffshore teamwithout onshoreteams involvement)

Not used (othermeetings andcommunicationopportunities wereconsidered to besufficient)

Used (onshore andoffshore teamsinvolved via OCS;only commonmeeting)

Not used (tries butdiscontinued dueto lack of feedback fromboth teams)

Used (maintained inLotus Notes); productbacklog maintainedonshore; sprint backlogdeveloped and burndownchart maintained byoffshore Scrum teams

Collabora-tionSoft

Used(initially 4weeks thenfixed at 2weeks)

Use modified(held weeklywith projectmanager andsub-teamcoordinators)

Use modified(onshore andoffshore separate;two daily onshoremeetings; offshorerepresentation viaSkype)

Use modified(combined withweekly sprintplanning and reviewmeetings)

Use modified(sprint outputreviewed byonshore-based QAteam)

Use modified(held every 4weeks, site-based;results posted inproject Wiki)

Used (maintained in Jira);product backlogmaintained centrally;sprint backlog developedand burndown chartmaintained by Scrum sub-teams

TestSoft Used (fixedat 2 weeks)

Use modified(held anadditional sprintpre-planningmeeting)

Use modified(Europe- and Brazil-based teams heldseparate Scrums;Europe-based Scrumteam held meetingevery second day)

Use modified(weekly statusmeeting was heldinvolving projectmanager and the twooffshore Scrummasters)

Use modified(only Scrummasters, projectmanager andcustomerinvolved)

Used (Europe-based teamsresults publishedin Wiki)

Used (maintained inScrumWorks); productbacklog maintained byonshore project manager;sprint backlog developedand burndown chartmaintained by Scrumteams

were not used at all (Scrum of Scrums, retrospective). After somevariation,sprints were set at 1.5 weeks, although some sprintlengths needed to be varied to synchronize with different onshoreholiday patterns. The shorter period enabled tight scrutiny andfeedback on work completed by the offshore team.Sprint planning was adapted. Due to the offshore teams lack of domain knowledge, at the beginning of every sprint, the offshoreteam participated in a sprint pre-planning meeting with the

product owner/project manager through OCS and Live Meeting.In this meeting (which took up to two hours and was recorded),the product backlog was prioritized for the offshore teamsupcoming sprint and nominated item specifications explained.During the meeting, offshore team members were able to askquestions about the proposed tasks. Based on the prioritizations,the offshore team members then held their own detailed sprintplanning meeting, which lasted up to four or more hours. Toclarify issues and reduce misunderstandings, offshore teammembers could replay the recorded sprint pre-planning meeting.During and after the planning meeting, offshore team memberscould also communicate one-on-one with onshore stakeholders toclarify any issues, mostly via OCS. The sprint backlog wasdeveloped in this local planning meeting and maintained in thecompany standard collaboration tool, Lotus Notes (which replacedTFS). Thedaily Scrum was used in a collocated rather than distributedform at the offshore site. The onshore team had no daily Scrum astheir development team was small and the sites focus was mainlyon generating and maintaining project specifications. The dailyScrum process was similar to that of PaperInfo. Thesprint review meeting was a key practice in this project in distributed form. Atthe end of a sprint, the offshore team presented what they hadaccomplished during the sprint to the onshore team through OCSand Live Meeting tools. As proxy customer, the product owner / project manager checked the completed sprint and provided

feedback as necessary. TheScrum of Scrums practice was notused because, even though the two sites operated as separateScrums, most development was centered at the offshore siteMoreover, the short sprint length provided frequent opportunity tdiscuss and resolve any cross-site issues and dependenciesSimilarly, whileretrospective had been attempted, the practicewas discontinued due to lack of feedback from both sites. Thbacklog practice was used in this project. The product backlogwas created and maintained by the onshore team, in Lotus Notesand was prioritized for the offshore teams sprints by the onshorteam in the sprint pre-planning meeting. In turn, the offshore teamdeveloped the sprint backlog in their local sprint planningmeeting, which was also maintained in Lotus Notes. To supporthe burndown chart, a separate application on top of Lotus Notewas used to indicate detailed project progress.

4.3 CollaborationSoftHere, we describe the CollaborationSoft project.

4.3.1 Project Description CollaborationSoft is a project of an enterprise collaborationsoftware vendor that is well-known for serving Agile softwaredevelopment. The CollaborationSoft project was developing anenterprise wiki for intranets and a knowledge management

application. The project was distributed in two countriesAustralia and the US. The eleven-person Sydney-based onshorsite had the domain knowledge-based management team and maidevelopers, including the project customer, QA team and otherelevant stakeholders. The core product was developed onshoreThe onshore team was divided in four sub-teams, each of whicwere allocated a separate feature-based part of the productExperienced team members were selected as coordinators of eacsub-team. A four-person offshore-based sub-team, in SanFrancisco, worked independently on various application plug-into the main product. However, the offshore teams deliveries wer

114

7/28/2019 p110-hossain

6/10

integrated with the main product regularly. Team members had avariety of skills and experience. For example, the project managerhad over ten years experience in software development.The projects distribution in Australia and the US createdgeographical, temporal and socio-cultural distances. There is a

seventeen or nineteen hour time difference (depending on the timeof the year) between Sydney and San Francisco. At best, thisresulted in half a days overlap in business hours between the twosites, four days a week. Also, Australia and the US are onopposite sides of the Pacific Ocean. There was no direct flightbetween the two sites and it took almost a day to travel from theonshore to offshore site. However, based on Hofstedes [20]socio-cultural indices for Australia and US and informantopinions, the project involved low socio-cultural distance.

Figure 3. CollaborationSoft Project Structure

4.3.2 Use of Scrum PracticesIn this project, Scrum was also adapted. Some practices were usedin a traditional form (sprint and backlog) while the rest weretailored in some manner (sprint planning, daily Scrum, Scrum of Scrums, sprint review and retrospective).Sprints were mostlystandardized. Initially, the sprint length was 4 weeks but was thenfixed at 2 weeks to increase project visibility and deliveryfrequency.Sprint planning was adapted. At the beginning of thesprint, representatives from the five sub-teams participated in asprint planning meeting, via video conferencing, in which thebacklog was reviewed and prioritized for the upcoming sprint.Scrum team representatives also negotiated what backlog itemswould be assigned to their Scrum teams. Based on the prioritizedbacklog, Scrum team members then planned their own sprintbacklog for the upcoming sprint, which was maintained in the Jiratool. Mid-sprint, another meeting reviewed issues and progress,and discussed new ideas and proposals. This meeting also servedas a Scrum of Scrums meeting, to resolve any cross-team issuesand dependencies. Also, two people from each site participated inadditional chat- or telephone-based meetings, twice a week, todiscuss sprint progress and any other matters of relevance.Thedaily Scrum was modified to suit the project design (into sub-teams) and the time zone distance between sites. Separate dailyScrums (stand-ups) were held in each site but representativeoffshore team members could participate in the onshore dailyScrums via Skype with video (and increasingly did so towards theend of release cycles). Two daily Scrum meetings were held

onshore due to the large project personnel and to limit the meetinduration to ten minutes.Thesprint review meeting was also tailored due to the way workwas allocated to development teams and the nature of the producproduced by the project. Code from each sub-team was reviewe

by another sub-team. Also, at the end of each sprint, completedsoftware was passed to the onshore QA team for review.Feedback was provided to the Scrum teams as necessary.

Retrospectives were also tailored due to the temporal distancebetween sites and the segmentation of work. Onshore and offshorteams conducted retrospectives separately. In the retrospectivesub-teams analyzed team performance by focusing discussion owhat the team had achieved, what impediments were encounteredwhat tasks could not be finished or started at all, and any otherelevant topic (such as, what did not go well and what needed tobe improved). The obstacles were noted. Each sites retrospectivresults were posted in the project wiki, which was accessible byall stakeholders. Initially, retrospectives were held at the end oevery sprint. Later, however, as operations began to run smoothlythe time interval was increased to the end of every second sprint.The Backlog practice was integrated with the weekly planningcycle (as described above). Product and sub-team backlogs wermaintained in Jira. The burndown chart was maintained in arelated tool, GreenHopper, to indicate project progress in detail.

4.4 TestSoftFinally, we describe the TestSoft GSD project.

4.4.1 Project Description TestSoft was a project in a large market leader in the manufacturof telecommunications products for a global market. The projecwas developing software for a product testing platform for thecompanys own use and the use of other large customers aroundthe world. The project was a new development and had moderatlevels of requirements changes in its initial release cycles

However, the project manager was expecting more requirementchanges in coming releases as the needs of other customers werconsidered. The project involved 15 people distributed in foucountries. The Finland-based onshore product owner had morethan ten years project management experience. The projectinvolved two offshore development teams which they referredto as the Brazil-based and Europe-based teams. The Brazil-baseeleven-person subcontractor team was located in a single site anwas considered to be the projects main development team. In thiteam, Scrum experience varied from highly experienced toinexperience but domain knowledge was generally low. TheEurope-based team had three people, two of whom were locatein Germany and the other in India. Finland had the main domainknowledge (vested in the product owner/project manager),although the Europe-based team was also strong in domain

understanding. In this team, experience in software developmenvaried from 7 to 20 years. In general, each offshore team wasallocated independent architectural subsystems (although modulewere cycled around between teams, in different sprints, to spreaand share knowledge within the project).The project distribution in four countries created temporal,geographical and socio-cultural distances. The project involvedhigh temporal distance. For example, there was no overlap inbusiness hours between sites in India and Brazil. The project alsinvolved high geographical distance as there were no direct flightbetween distributed sites and travel could take up to 30 hours

115

7/28/2019 p110-hossain

7/10

Visa requirements further increased geographical distance. Basedon Hofstedes [20] definitions of cultural dimensions for Brazil,India, Finland and Germany, and informant opinions, the projectalso involved significant socio-cultural distance.

ProductBacklog

Backlog Prioritisation Meeting

Time zone difference:

6 hours

SprintBacklog

SprintBacklog

GloballyDistributedCustomers

Three-person Europe-basedDevelopment Team

2 Developers,Germany

One Developer /Test Engineer, India

Scrum TeamMember

ScrumMaster

Scrum TeamMember

Eleven-person Brazil-basedDevelopment Team

ScrumMaster

Scrum TeamMembers

Twice Weekly Status Meeting

Biweekly Architectural

Meeting

ProductOwner

Finland

1 hour 2.5 hours

Figure 4. TestSoft Project Structure

4.4.2 Use of Scrum Practice In this project, the Scrum model was adapted to suit the project.Only the sprint was used in a traditional way, while the otherpractices were tailored (sprint planning, daily Scrum, Scrum of Scrums, sprint review, retrospective and backlog). The twodevelopment teams (Europe-based and Brazil-based) ran separateScrums but used the same sprint cycle.Sprints were two weekslong (the standard duration adopted by the company).Sprint planning was adapted. At the beginning of the sprint, twoformal joint meetings were held. First, a sprint pre-planning

meeting via teleconferencing, involving only the product ownerand Scrum masters. This was then followed by each teams localsprint planning meeting. The first prioritized the product backlogitems to be worked on in the two parallel sprints, and the secondplanned how each team would develop its assigned items. TheBrazil-based team was collocated but the Europe-based team, inGermany and India, held its sprint planning meeting viateleconferencing.

Daily Scrum was also adapted. Both Scrum teams ran separatedaily Scrum meetings. Only the Europe-based teams meeting wasdistributed, due to its locations in two countries, but it was heldevery second day due to the smallness of the team. The Brazilianteam held a collocated Scrum meeting on a daily basis, however,its meetings were not well-managed as they took too long tocomplete. TheScrum of Scrums practice was also tailored. To

resolve cross-team issues and dependencies, the product owner,Scrum masters and, sometimes, some customers, participated in atwice-a-week management status meeting via teleconferencing. Inthis meeting, sprint progress was discussed, any impediments toprogress were explored and the sprint plan was adjusted.Furthermore, in this meeting, new requirements were collectedand the product backlog was updated as necessary.At the end of each sprint, a jointsprint review/retrospective meeting was held by each Scrum team and the results were postedon the project wiki. The meeting reviewed what was done, whatwas not finished (or even started), what problems were

encountered and what needed to be improved. The sprint demo tcustomers involved only the management team (productowner/project management and Scrum masters), rather than thwhole Scrum team, and was conducted through OCS and LivMeeting. In this review, the management team could immediatelcheck the completed sprint, identify problems early and providfeedback to the development teams as necessary.Finally, thebacklog practice was also used in this project, in aslightly modified form. As the project progressed, the Scrummanagement team met biweekly with customers to identify newbacklog items, eliminate noise, and clean and refine the items lisfor future sprints. The product owner and Scrum masters also hela sprint pre-planning meeting to prioritize the backlog for eachteams upcoming sprint. Backlogs and burndown charts weremaintained in ScrumWorks.

5. CASE ANALYSISThis section presents and discusses the results from the cross-casanalysis of the data gathered from the four cases.

5.1 Impact of Project Contextual Factors onUsing Scrum PracticesThis sub-section discusses the impact of key project-, team- andistance-specific contextual factors on how the seven Scrumpractices were used.

5.1.1 Sprint The multi-case data indicates that the project-specific factorsrequirement changes and product domain impacted use of the sprint practice. For example, in CollaborationSoft, due tofrequent requirements changes, the Project Manager changed th4-week sprint length to 2 weeks. This shorter duration enabled thproject to take on and deliver requirements changes in morefrequent iterations throughout the project. Case data also indicatethat the offshore teams lack of domain knowledge influencedtailoring sprint practices. For example, in EnergyInfo, the offshorteams lack of domain knowledge created somemisunderstandings. As a result, the sprint length was shortened t1.5 weeks to enable the project manager to verify the offshoresprint more frequently, increasing project visibility. The data alsoshows that the distance-specific factorsocio-cultural distance impacted use of the sprint practice. For example, in PaperInfosprint length had to be synchronized at the offshore developmensite due to different onshore holiday patterns.

5.1.2 Sprint Planning MeetingThe case studies show that the project-specific factorproduct domain had an impact on using sprint planning meeting. In allfour cases, due to the offshore teams lack of domain knowledgethe sprint planning meeting became a sprint planning process tha

involved additional meetings. For example, in PaperInfo, tocomplete the offshore teams sprint planning meeting, onshoreand offshore team members participated in two joint meetingsFirst, in a sprint pre-planning meeting (called a goal introductiomeeting, which was recorded), the onshore team presented thgoals and prioritized backlog for the upcoming offshore sprint. Inthis meeting, offshore team members were able to ask relevanquestions to the onshore domain knowledge-based team memberwhich minimized misunderstandings. Based on the onshoreteams prioritization of the backlog, offshore team members thenheld their sprint planning meeting. During this meeting, the

116

7/28/2019 p110-hossain

8/10

offshore team could replay the recorded goal introductionmeeting if needed. The next day, the offshore team presented itsdetailed sprint plan to the onshore team in a sprint post-planningmeeting (called a plan introduction meeting). In this meeting,the onshore team verified the offshore teams plan and providedfeedback as necessary.The data also indicates that the team-specific factorsproject

personnel, and distributed sites impacted tailoring of thesprint planning practice. For example, in CollaborationSoft, due tothe large project personnel, key representatives from each sub-team participated in a sprint pre-planning meeting. In thismeeting, onshore management team members, together with theScrum team representatives, prioritized the product backlog forthe upcoming sprint. Based on the product backlog prioritization,sub-team members then held their own detailed sprint planningmeetings. Similarly, due to the distribution of sites, the projectmanager divided work into separate modules and allocated thesemodules to the site-based sub-teams. Thus each sub-teamconducted its own site-based sprint planning meeting.The data also indicates that the distance-specific factorstemporal, geographical and socio-cultural distance hadan impact on use of sprint planning meetings. It shows that projectmanagers used a wide range of collaboration tools and supportingmechanisms to conduct sprint planning meetings due to thesedistances. For example, due to hightemporal distance inCollaborationSoft, only one or two US-based team members usedthe mechanism adjust working hours to join in the weeklysprint planning meeting via video conferencing. Similarly, inPaperInfo, due togeographical distance , offshore distributed teammembers participated in their sprint planning meeting throughSkype. Moreover, in the case projects, team members used themechanismvisit so that they could participate in sprintplanning face-to-face. For example, in TestSoft, offshore teammembers sometimes visited the onshore site to participate insprint pre-planning meetings. Also, in PaperInfo, to avoid

challenges due tosocio-cultural distance , the sprint pre-planningmeeting was recorded using the OCS tool. In that case, to clarifymisunderstandings or confusion, the offshore team was able toreplay the recorded presentation.

5.1.3 Daily ScrumThe case data indicates that the project-specific factorproduct domain may have impacted use of the daily Scrum practice. Forexample, in CollaborationSoft, towards the end of the project, anoffshore team representative participated in onshore daily Scrummeetings to help resolve any misunderstandings due to lack of domain knowledge. The data also suggests that the team-specificfactorteam size had an impact on the daily Scrum practice. Forexample, in CollaborationSoft, the onshore team membersinitially participated in a single daily Scrum. However, due to thelarge team size, the project manager organized two separate dailyScrums. Similarly, in TestSoft, due to the small size and spread of one Scrum team, daily Scrums were held every second day. Casefindings also suggest that the team-specific factorexperience impacted the daily Scrum. For example, in TestInfo, the Brazilianteam members were less experienced in both Scrum and domainknowledge. As a result, their daily Scrum meetings were muchlonger than the usual 10-15 minutes because they went into toomuch detail, as a group, in the meeting (rather than to resolveissues via collaborative discussions after the meeting).

The study also found that project managers used collaborationtools and mechanisms to support the use of daily Scrum andmitigate challenges due to the distance-specific factorstemporal, geographical and socio-cultural distance. Forexample, in PaperInfo, due to temporal distance, offshore teammembers used the mechanismadjust working hours toparticipate in the daily Scrum. Similarly, in TestSoft, due to thegeographical distance, Europe-based Scrum team members usethe collaboration toolteleconference to participate in dailyScrums. Case data also suggests that socio-cultural distance haan impact on the daily Scrum. For example, in CollaborationSofa socio-cultural issue, doubtful of others capabilities , arosebetween the onshore and offshore sites. As a result, an offshoreteam representative participated in onshoredaily Scrums ,particularly at the end of release cycles, to help reduce mistrusand misunderstandings.

5.1.4 Scrum of ScrumsThe study indicates that the team-specific factorteam size hadan impact on the Scrum of Scrums practice. For example, inPaperInfo, the offshore teams operated as a single Scrum sostrictly speaking, the Scrum of Scrums practice was not used inthat project. However, to stay on track, update the offshore teamwith any changes and resolve any cross-site issues anddependencies, the onshore project manager and offshore projeclead held a weekly status meeting. Evidence suggests that thedistance-specific factortemporal and geographical distancealso impacted the Scrum of Scrums practice. In CollaborationSoffor example, due to the high temporal distance, representativefrom each sub-team used the mechanismadjust working hours to participate in a weekly status meeting. Similarly, in TestSoftdue to the geographical distance, Scrum masters and the projecmanager participated twice weekly in a status meeting via ateleconferencing . In addition, due to geographical distance,team representatives used the mechanismvisit to travelbetween sites to participate in status meetings face-to-face. Fo

example, in PaperInfo, the offshore project lead frequently visitethe onshore site to participate in the projects weekly statusmeetings.

5.1.5 Sprint ReviewThe case evidence also indicates that the team-specific factoteam size had an impact on use of the sprint review practice.For example, in TestSoft, rather than the entire Scrum team (duto one team being too small and the other too large), only theScrum master of each team participated with the project manageand customers in the sprint demo. The sprint review meeting waalso tailored due to geographical and temporal distance. HoweveProject Managers employed a range of collaboration tools andmechanisms to support sprint review meetings in their distributeproject environments. For example, in TestSoft, due to thetemporal and geographical distances involved, each team heldseparate reviews locally and posted the results on the project wikBy contrast, EnergyInfo used the mechanismadjust workinghours to participate in sprint review meetings viaOCS and Live

Meeting tools (the only common meeting of all team members). Insome projects, distributed team members also had an opportunitto participate in some sprint review meetings face-to-face, througthe visit mechanism. For example, in EnergyInfo, sometimesoffshore team members participated in review meetings face-toface, while visiting the onshore location.

117

7/28/2019 p110-hossain

9/10

5.1.6 Sprint RetrospectiveThe case data indicates that the team-specific factorteam size anddistributed sites impacted use of the retrospective practice.For example, in CollaborationSoft, due to the large team size,retrospectives were held after every second sprint, locally at each

site, with the results posted on the project wiki. Similarly, due tothe distribution of teams in TestSoft, each team similarly held aseparate retrospective and posted the results in the project wiki.The retrospective practice was also affected by the distance-specific factors temporal and geographical distance. Forexample, in TestSoft, due to the temporal and geographicaldistances involved, the Europe-based Scrum team members usedthe mechanismsadjust working hours andteleconference tohold their retrospective meetings.

5.1.7 BacklogOne case also indicates that the project-specific factorproduct domain had an impact on use of the backlog practice. Due to thespecific interests of diverse customers, in TestInfo, the Scrummanagement team met biweekly with customers to identify newbacklog items, eliminate noise, and clean and refine the items listfor future sprints. The study also indicates that use of the backlogpractice was supported by collaborative tools due to the distance-specific factor geographical distance . For example, inPaperInfo and TestInfo, product and sprint backlogs weremaintained in a globally accessible toolScrumWorks. Similarly,the burndown chart was also maintained in globally accessibletools. For example, in CollaborationSoft, the burndown chart wasmaintained inGreenHopper , which was integrated with thebacklog tool Jira.

5.2 Benefits of Tailored Scrum ModelIn this multi-case study, although the projects faced variouschallenges resulting from the distribution of project stakeholders,informants indicated that they were satisfied with their tailoredScrum model. Informants from PaperInfo, EnergyInfo andTestSoft noted that the existing tailored Scrum enabled them tominimize some of the project challenges that they could not, orbetter than they could, under the previous plan-driven model. Forexample, lack of offshore work visibility was identified as one of the key challenges. However, the sprint model provided iterativecycles and many formal and informal contact opportunities thatensured the frequent delivery of working software, increasingproject visibility. Moreover, all of the project managers noted thatin their sprint model, they were able to incrementally adjust theplan according to sprint outcomes. Informants also stated thattasks were well-organized under Scrum, minimizing overwork,and that project teams were required to be largely self-organized,increasing motivation and a sense of teamness. As a result, the useof Scrum improved coordination in the distributed project andgave the project manager a greater sense of control and improved

transparency of progress towards goals. The Scrum meetingpractices also enabled team members to participate regularly, on apredictable cycle, improving team collaboration and creating anenvironment of high trust. However, informants also noted thatthe effective use of Scrum in GSD critically depends on the use of good collaboration tools (e.g. wiki, chat, conferencing) and othersupporting mechanisms (e.g. adjust working hours and visit).

6. DISCUSSIONIn this paper, we presented a multi-case study on tailoring Scrumpractices in four globally distributed projects. We also considered

the use of collaboration tools and supporting mechanisms intailoring Scrum in GSD projects. The contributions of the paper tknowledge are threefold. First, supported by collaboration tooland enabling mechanisms, it illustrates how key project contextuafactors can influence the adaptation of the Scrum model in amanner that can mitigate significant GSD challenges. Second, icontributes to a paucity of empirical literature on the use of Scrumin distributed environments. Third, it presents experiences andviews of project managers who have used Scrum in GSD projectthat may inform practitioners seeking to improve their ownproject performance.

6.1 Limitations and Further ResearchThe paper has some limitations. As a qualitative study, causality iimplied by the relationships between constructs as establishedfrom analysis of the accounts of informants (some of the analyseare only partially explicated due to the limitations of space, buare coded and charted in our dataset). Consequently, the authormake no claims that the findings are generalizable to other GSDprojects. Indeed, an implicit assumption of the paper is that theris no one way to adapt the Scrum model in a GSD project. Ratheproject managers will respond to the challenges of GSD bycrafting a Scum model to fit the circumstance of the project (arepresented here by certain key projects contextual factors)Instead, the paper contributes to a body of knowledge from whicgeneral principles may emerge on how Scrum can be used in noncollocated environments.Furthermore, GSD projects take many forms. Four case studieare informative but not necessarily indicative or representativeMore case studies are needed to provide cumulative insight inttailoring the Scrum method in GSD by considering a range oproject settings. Also, other research methods such as surveycould be employed as the volume of industry experience grows.Another limitation of the paper is that it focuses only on tailorinthe Scrum method in GSD. Effective management of GSD

projects may be achievable by adapting other project managemenand development methods, with the support of enabling tools anmechanisms. The paper makes no claim that Scrum is the onlyor best method for GSD. Rather, it is a response to growinginterest by practitioners and researchers in deploying Scrum, as aAgile method, outside of its original domain of development by collocated team.

6.2 ImplicationsThe main implication of the study, for both theory and practice, ithat viewing Scrum as a process for managing collocated softwarproject teams may be imposing an artificial and unnecessaryconstraint on the method. Today, electronic conferencing andcomputer-mediated work tools, and mechanisms such as adjusworking hours and visit are increasingly becoming standardoperational support capabilities as trends towards globalizationand inter-organisational collaboration become part of the normalandscape of business. Electronic conferencing may provide adifferent experience to face-to-face contact and meetings in termof quality of knowledge exchange. However, the cases examinedin this study suggest that the Scrum method, which presupposecollocation, may be tailored in dispersed environments, and witthe help of collaboration tools and supporting mechanisms, bused to effectively manage software development in challenginglobal landscapes. If this is so in general, it challenges thetraditional proximity assumptions of Agile methods and open

118

7/28/2019 p110-hossain

10/10

opportunities to interpret and develop them more broadly inresearch and practice.

6.3 ConclusionThis paper reports an empirically-based qualitative research studyof four projects that has aimed to contribute knowledge andunderstanding on the use of Scrum practices in GSD and on howScrum can be tailored in GSD by considering key projectcontextual factors, including collaboration challenges resultingfrom temporal, geographical and socio-cultural distances. Thefindings support emergent views that the Scrum model offers thepotential of improved visibility and control over distributeddevelopments through its practices of frequent development andreview iterations and collaborative communication betweendevelopers. Adapting the model to the characteristics of theproject and finding suitable collaboration tools and enablingmechanisms would appear to be critical to realizing these benefits.

7. ACKNOWLEDGMENTSNICTA is funded by the Australian Government as represented by

the Department of Broadband, Communications and DigitalEconomy and the Australian Research Council through the ICTCentre of Excellence program.

8. REFERENCES[1] Hossain, E., Babar, A.M. and Paik, H. 2009. Using Scrum in

Global Software Development: A Systematic LiteratureReview. InProceedings of the 4 th IEEE InternationalConference on Global Software Engineering , Limerick, pp175-184.

[2] gerfalk, P.J. and Fitzgerald, B. 2006. Flexible anddistributed software processes: old petunias in new bowls?Communication of the ACM , Vol.49, No. 10, pp.27-34.

[3] Turk, D., France, R. and Rumpe, B. 2002. Limitations of

Agile Software Processes. InProceedings of XP/AgileUniverse , pp. 43-46.[4] Abbattista, F., Calefato, F., Gendarmi, D. and Lanubile, F.

2008. Incorporating Social Software into Distributed AgileDevelopment Environments. InProceedings of the 23 rd

IEEE/ACM International Conference on Automated Software Engineering , pp. 46-51.

[5] Paasivaara, M., Durasiewicz, S. and Lassenius, C. 2008.Distributed Agile Development: Using Scrum in a LargeProject.Software Process Improvement and Practice , 13(6),pp. 527-544.

[6] Sutherland, J., Schoonheim, G. and Rijk, M. 2009. FullyDistributed Scrum: Replacing Local Productivity and Qualitywith Offshore Teams. InProceedings of the Conference on

HICSS42 , Hawaii, pp 1-8.[7] Herbsleb, J. and Moitra, D. 2001. Global SoftwareDevelopment. IEEE Software , 18(2), pp. 16-20.

[8] Jimenez, M., Piattini, M. and Vizcaino, A. 2009. Challengesand improvements in distributed software development: A

systematic review. Advances in Software Engineering ,Article ID 710971, pp. 1-14.

[9] Holmstrm, H., Fitzgerald, B., gerfalk, P.J. and Conchuir,E.O. 2006. Agile Practices Reduce Distance in GlobalSoftware Development. Information Systems Management ,

23(3), pp. 7-26.[10] Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J.2002. Agile software development methods: Review and analysis . VTT Publications.

[11] Sutherland, J. and Schwaber, K. 2007.The Scrum Papers: Nuts, Bolts, and Origins of an Agile Method . Scrum, Inc.,Boston.

[12] Paasivaara, M., Durasiewicz, S. and Lassenius C. 2009.Using Scrum in Distributed Agile Development: A MultipleCase Study. InProceedings of the 4 th IEEE InternationalConference on Global Software Engineering (ICGSE09),Limerick, pp. 195-204.

[13] Hossain, E., Babar, A.M. and Verner, J. 2009. How CanAgile Practices Minimize Global Software Development Co-ordination Risks? InProceedings of the 16 th EuropeanConference on Software Process Improvement (EuroSPI09),Madrid, CCIS 42, pp. 81-92.

[14] Sarkar, S. and Sarker, S. 2009. Exploring Agility inDistributed Information Systems Development Teams: AnInterpretive Study in an Offshoring Context. InformationSystems Research , 20(3), pp. 440-461.

[15] Phalnikar, R., Deshpande, V.S. and Joshi S.D. 2009.Applying Agile Principles for Distributed SoftwareDevelopment. InProceedings of the InternationalConference on Advanced Computer Control , pp. 535-539.

[16] Yin, R.K. 2009.Case Study Research: Design and Methods .4th edn. Sage publications, Thousand Oaks.

[17] Miles, M. B. and Huberman, A.M. 1994.Qualitative Data Analysis: An expanded Sourcebook . Second Edition. SagePublications, Thousand Oaks.

[18] Ritchie, J., and Spencer, L. 1994. Qualitative Data Analysisfor Applied Policy Research. In Bryman, A., and Burgess,R.G., (Eds.), Analyzing Qualitative Data , Routledge,London, pp. 173-194.

[19] Hossain, E., Babar, A.M. and Verner J. 2009. Towards aFramework for Using Agile Approaches in Global SoftwareDevelopment. InProceedings of the 10 th InternationalConference on Product Focused Software Development and Process Improvement (PROFES09), Oulu, Finland, pp. 126-140.

[20] Hofstede, G. 2001.Culture's Consequences: ComparingValues, Behaviors, Institutions and Organizations across

Nations , Second Edition, Sage Publications.

119