DistributedAgilePatterns:AnApproachtoFacilitateAgileAdoptioninOffshoreSoftware

Development

MaryamKausar

CollegeofScienceandTechnologySchoolofComputing,ScienceandEngineering

UniversityofSalford,Manchester,UK

SubmittedinPartialFulfilmentoftheRequirementsoftheDegreeofDoctorofPhilosophy

October2017

2

TableofContents

LISTOFTABLES 5

LISTOFFIGURES 6

ACKNOWLEDGEMENTS 7

DECLARATION 8

ABSTRACT: 9

CHAPTER1 INTRODUCTION 111.1RESEARCHPROBLEM 131.2RESEARCHAIMANDOBJECTIVES 161.3RESEARCHQUESTIONS 161.4RESEARCHCONTRIBUTIONS 171.5RESEARCHMETHODOLOGY 181.6STRUCTUREANDHOWTOREADTHEREPORT 211.7CHAPTERSUMMARY 22

CHAPTER2 OFFSHORESOFTWAREDEVELOPMENT 232.1INTRODUCTION 232.2BACKGROUNDOFOFFSHORESOFTWAREDEVELOPMENT 232.2.1OVERVIEWOFOFFSHOREMODELS 232.2.1.1DomesticOutsourcing 242.2.1.2 SharedServices 252.2.1.3 InternalOffshoring 262.2.1.4 OffshoreOutsourcing 272.2.2BENEFITSOFOFFSHORESOFTWAREDEVELOPMENT 292.2.2.1 EconomicBenefits 292.2.2.2 Political-LegalBenefits 312.2.2.3 DemographicandGeographicBenefits 322.2.3.4 TechnologicalBenefits 332.3ASTUDYONIDENTIFYINGTHECHALLENGESOFOFFSHORESOFTWAREDEVELOPMENT 342.3.1TRUSTISSUES 362.3.2SOCIO-CULTURALISSUES 372.3.3COMMUNICATIONANDCOORDINATIONISSUES 442.3.4KNOWLEDGETRANSFERISSUES 462.4CRITICALANALYSISOFOFFSHORECHALLENGESONSOFTWAREDEVELOPMENTPHASE 502.5AGILEOFFSHORESOFTWAREDEVELOPMENT 642.5.1AGILESOFTWAREDEVELOPMENT 642.5.2AGILEMETHODOLOGYINOFFSHORING 652.6AGILEADOPTIONINOFFSHORESOFTWAREDEVELOPMENT 672.6.1TRANSITIONFROMTRADITIONALSOFTWAREDEVELOPMENTTOADOPTINGAGILEPRACTICES 672.6.1.1 FacilitatorstoAssistAgileAdoption 672.6.1.2 FrameworktoSupporttheEvaluation,AdoptionandImprovementofAgile Methods 682.6.1.3 SharedMentalModelstoUnderstandAgilePractices 692.6.2AGILEADOPTIONINOFFSHORING 702.6.2.1UseofPatternsinAgileAdoption 702.6.2.2 FactorsContributingtotheSuccessandFailureofAgileAdoption 732.6.2.3 UseofToolsinAgileAdoptioninOffshoreDevelopment 74

3

2.6.3EFFECTOFOFFSHORINGONAGILEADOPTION 772.7ASTUDYONTHEUSEOFPATTERNSINAGILEADOPTIONINOFFSHOREDEVELOPMENT 832.7.1CURRENTPATTERNSFORAGILEADOPTION 842.7.2DISTRIBUTEDAGILEPATTERNS 942.8CHAPTERSUMMARY 94

CHAPTER3 RESEARCHMETHODOLOGY 963.1INTRODUCTION 963.2OVERVIEWOFRESEARCHONION 963.3RESEARCHMETHODOLOGYUSEDTODESIGNDISTRIBUTEDAGILEPATTERNS 1033.3.1RESEARCHPHILOSOPHY 1033.3.2RESEARCHAPPROACH 1043.3.3RESEARCHSTRATEGY 1113.3.4CHOICE 1203.3.5TIMEHORIZON 1223.3.6DATACOLLECTION 1233.4CHAPTERSUMMARY 124

CHAPTER4 DISTRIBUTEDAGILEPATTERNS 1254.1INTRODUCTION 1254.2DESIGNINGTEMPLATEFORDISTRIBUTEDAGILEPATTERNS 1254.3SELECTINGTHERIGHTPATTERNFROMTHEDISTRIBUTEDAGILEPATTERNSCATALOGUE 1284.4ORGANISINGTHEDISTRIBUTEDAGILEPATTERNSCATALOGUE 1314.5FULLDISTRIBUTEDAGILEPATTERNSCATALOGUE 1334.5.1MANAGEMENTPATTERNS 1334.5.1.1 DistributedScrumofScrumPattern 1334.5.1.2 LocalStandupMeeting 1364.5.1.3 LocalSprintPlanningMeetingPattern 1394.5.1.4 LocalPairProgrammingPattern 1414.5.1.5 AsynchronousRetrospectiveMeetingsPattern 1434.5.2COMMUNICATIONPATTERNS 1464.5.2.1 GlobalScrumBoardPattern 1464.5.2.2 CentralCodeRepositoryPattern 1494.5.2.3 AsynchronousInformationTransferPattern 1514.5.2.4 SynchronousCommunicationPattern 1534.5.3COLLABORATIONPATTERNS 1554.5.3.1 CollaborativePlanningPokerPattern 1564.5.3.2 Follow-the-SunPattern 1584.5.3.3 CollectiveProjectPlanningPattern 1614.5.3.4 VisitOnshore-OffshoreTeamPattern 1644.5.4VERIFICATIONPATTERNS 1664.5.4.1 ProjectCharterPattern 1664.5.4.2 OnshoreReviewMeetingPattern 1684.6CHAPTERSUMMARY 171

CHAPTER5 VALIDATIONANDEVALUATIONOFTHEDISTRIBUTEDAGILEPATTERNSCATALOGUE 1725.1INTRODUCTION 1725.2REVISEDDISTRIBUTEDAGILEPATTERNS 1725.3EVALUATINGDISTRIBUTEDAGILEPATTERNS 1795.4CHAPTERSUMMARY 184

4

CHAPTER6 CASESTUDYTOSHOWAPPLICABILITYOFDISTRIBUTEDAGILEPATTERNS 1856.1INTRODUCTION 1856.2OVERVIEWOFREQUIREMENTSENGINEERINGPROCESS 1856.3REQUIREMENTSENGINEERINGPROCESSINTRADITIONALSOFTWAREDEVELOPMENTVS.AGILEMETHODOLOGY 1866.4APPROACHESTOIMPROVEREQUIREMENTSENGINEERINGPROCESSINAGILE 1876.5DISTRIBUTEDAGILEPATTERNSUSEDTOOVERCOMEREQUIREMENTSENGINEERINGCHALLENGES 1936.6MAPPINGDISTRIBUTEDAGILEPATTERNSONTHEREQUIREMENTSENGINEERINGLIFECYCLE 1966.7CHAPTERSUMMARY 198

CHAPTER7 CONCLUSIONSANDFUTUREWORK 1997.1INTRODUCTION 1997.2MEETINGTHEAIMANDOBJECTIVESANDANSWERINGTHERESEARCHQUESTIONS 2007.3RECOMMENDATIONFORFUTUREWORK 2017.4LIMITATIONOFTHESTUDY 2027.5CHAPTERSUMMARY 203

REFERENCES: 204

APPENDIXA:SELECTEDSTUDIESFOROFFSHORECHALLENGES 223

APPENDIXB:OVERVIEWOFEXISTINGSOFTWAREDEVELOPMENTAPPROACHES228

APPENDIXC:OVERVIEWOFBEECHAMETAL.(2014)GSDSOLUTION 229

APPENDIXD:SAMPLEQUESTIONSFORSEMI-STRUCTUREDINTERVIEWS 230

APPENDIXE:CONSENTFORMANDDATAPROCESSINGSTATEMENT 232

APPENDIXF:UNREVISEDDISTRIBUTEDAGILEPATTERNCATALOGUE 234

5

ListofTablesTABLE2.1.CHALLENGESINOFFSHORESOFTWAREDEVELOPMENT. 35TABLE2.2SEVENVALUESFORCULTURALDIMENSIONS(TROMPENAARSETAL.,2004). 38TABLE2.3.CULTURALCOMPARISONBETWEENJAPANANDCHINA(OZAWAETAL.,2013). 41TABLE2.4.CULTURALPATTERNSINSOFTWAREPROCESSMISHAPS(MACGREGORETAL.2005). 42TABLE2.5.FACTORSAFFECTINGTASKALLOCATIONPROCESSINOFFSHOREDEVELOPMENT

(SAJJADETAL.2015). 47TABLE2.6.OFFSHORECHALLENGESAFFECTINGSOFTWAREDEVELOPMENTPHASES. 51TABLE2.7.OVERVIEWOFEXISTINGAPPROACHESUSEDTOOVERCOMEOFFSHORECHALLENGES. 59TABLE2.8.COMPARISONOFAGILEDEVELOPMENTVERSESOFFSHOREDEVELOPMENT(ŠMITEETAL.2010). 66TABLE2.9.AGILEPRACTICESUSEDFOROFFSHOREDEVELOPMENT(PAASIVAARAETAL.,2009). 76TABLE2.10.AGILEPRACTICESAFFECTEDBYOFFSHORECHALLENGES. 78TABLE2.11.DETAILOFTHREESITESADOPTINGAGILEPRACTICESATR&DUNITOFERICSSON(PAASIVAARAET

AL.,2013). 80TABLE2.12.EXISTINGOFFSHORESOFTWAREDEVELOPMENTPATTERNS. 85TABLE2.13.PATTERNSFORAGILESOFTWAREDEVELOPMENT. 89TABLE2.14.OVERVIEWOFAGILEADOPTIONPATTERNS(ELSSAMADISYETAL.,2006). 93TABLE3.1.OVERVIEWOFRESEARCHONION. 98TABLE3.2:KEYCONCEPTSSELECTEDFORRELATIONALANALYSIS. 106TABLE3.3.SEARCHTERMSUSEDINTHISREVIEW. 114TABLE3.4.OCCURRENCEOFAGILEPRACTICESINLITERATURE 115TABLE3.5.SIXSOURCESFORDATACOLLECTIONCOMPARISON(YIN,2003). 116TABLE3.6.TYPEOFINTERVIEWS(EASTERBY-SMITHETAL.,2012). 118TABLE3.7.DETAILOFCOMPANIESINTERVIEWED. 119TABLE3.8.OVERVIEWOFTHEQUANTITATIVEANDQUALITATIVEMETHODSUSEDINTHISRESEARCH. 120TABLE3.9.TIMEHORIZONACROSSFOUR-YEARPHDRESEARCH. 122TABLE4.1.COMPARISONOFEXISTINGPATTERNS. 125TABLE4.2.CATEGORIESOFDISTRIBUTEDAGILEPATTERNS. 132TABLE5.1.DETAILSOFTHECOMPANIES. 172TABLE5.2.DETAILSOFTHEPARTICIPANTSATTENDEDTHEWORKSHOP. 173TABLE5.3.AGENDAOFTHEREFLECTIONWORKSHOP. 174TABLE5.4.FLIPCHARTFORMATFORTHEREFLECTIONWORKSHOP(KERTH,2001). 174TABLE5.5.FLIPCHARTOFCOMPANY3PARTICIPANT5(C3P5). 176TABLE5.6.SUMMARISEDFLIPCHARTOFTHECOMPANIES. 177TABLE5.7.FEEDBACKONTHECHALLENGESDISTRIBUTEDAGILEPATTERNSSOLVE. 178TABLE5.8.EXISTINGSOLUTIONSINCOMPARISONTOTHEDAPCATALOGUE. 180TABLE6.1.USINGDISTRIBUTEDAGILEPATTERNSTOADDRESSREQUIREMENTSENGINEERINGCHALLENGESIN

AGILEOFFSHOREDEVELOPMENT. 193

6

ListofFigures

FIGURE1.1RESEARCHMETHODOLOGY 18FIGURE2.1BUSINESSMODELSFORGLOBALSOFTWAREENGINEERING(OECD,2004). 24FIGURE2.2.DISTRIBUTIONOFWORKAMONGMULTIPLEDISTRIBUTEDTEAMS. 33FIGURE2.3.TRADITIONALSOFTWAREDEVELOPMENTLIFECYCLE. 50FIGURE2.4.THEMAINCOMPONENTSOFTHEAGILESOFTWARESOLUTIONFRAMEWORK(QUMERETAL.2008).68FIGURE2.5.AGILEADOPTIONANDIMPROVEMENTMODEL(QUMERETAL.,2007) 69FIGURE2.6.SOFTWAREPROJECTSUCCESSRATEFOROFFSHOREPROJECTS(MALIKETAL.,2010). 74FIGURE3.1.THERESEARCHONION(SAUNDERSETAL.,2007) 97FIGURE3.2.OVERVIEWOFDESIGNANDDEVELOPMENTOFDISTRIBUTEDAGILEPATTERNCATALOGUE 108FIGURE.3.3.THESELECTIONPROCESSOFPRIMARYPAPERS. 113FIGURE4.1.PROCESSOFSELECTINGPATTERNSFROMTHEDISTRIBUTEDAGILEPATTERNCATALOGUE. 130FIGURE4.2.DISTRIBUTEDAGILEPATTERNSAPPLICATIONONTRADITIONALSCRUMLIFECYCLE 130FIGURE4.3.DISTRIBUTIONOFWORKAMONGTHREEDISTRIBUTEDTEAMS(GUPTA,2009). 160FIGURE.5.1.DOCUMENTPRESENTEDINREFLECTIONWORKSHOPTOTHEPARTICIPANT 175FIGURE6.1.TRADITIONALREQUIREMENTSENGINEERINGPROCESS. 186FIGURE6.2.AGILEREQUIREMENTSCHANGEMANAGEMENTPROCESS. 187FIGURE6.3.STORYCARDBASEDMETHODOLOGYFOLLOWEDBYSOBATOOL(PATELETAL.,2008). 188FIGURE6.4.THEUSERSTORYDELIVERYPROCESS(DANEVAETAL.,2013). 191

7

Acknowledgements

Firstandforemost,thisresearchwouldnotbepossiblewithouttheblessingofmyLord

ALLAH,themostMerciful,whohasgivenmethepatienceandstrengthtofinishthis

PhDjourney.

Iwouldliketoexpressmygratitudeandsincereappreciationtomysupervisor,Dr.Adil

Al-Yasiri,forhisassistance,guidance,andfeedbackduringmyPhD.

Special thanks to my parents, Kausar Iqbal Malik and Khalida Parveen, for their

encouragementandprayers.

IwouldliketoextendmythankstothemembersoftheSchoolofComputing,Science,

andEngineeringattheUniversityofSalford,forsupportingmeduringmyPhD.

Finally, Iwouldliketosaythankstoeveryonewhohelpedmeachievesuccessinthis

research.

8

Declaration

Parts of the research presented in this thesis has been published in the following

papersandpresentations:

1-Kausar,M.,&Al-Yasiri,A.(2015).DistributedAgilePatternsforOffshoreSoftware

Development. Presented in the 12th International Joint Conference on Computer

ScienceandSoftwareEngineering(JCSSE2015).IEEEConference2015.

2- Kausar,M.,&Al-Yasiri, A. (2016).UsingDistributedAgile Patterns for Developing

Offshore Projects. Presented in the Proceedings of the CSE 2016 Annual PGR

Symposium(CSE-PGSym16),UniversityofSalford,Manchester,UnitedKingdom,2016

3-Kausar,M.,&Al-Yasiri,A.(2017).UsingDistributedAgilePatternsforSupportingthe

Requirements Engineering Process. Presented in the Requirements Engineering for

ServiceandCloudComputing.SpringerInternationalPublishing,2017.291-316.

9

Abstract:

Over a decade, companies have been using agile methods for the development of

software. However with the increasing trends of offshore software development,

companies are becomingmore interested in using agile methods for such projects.

While offshore development has several dynamic benefits such as cost reduction,

flexibility, proximity tomarket, concentration on core processes and easy access to

talent, they have introduced new challenges, such as trust, socio-cultural,

communicationandcoordination,andknowledgetransferissues.Thesechallengesnot

onlyaffectthedevelopmentprocessbutalsoaffecttheapplicabilityofagilepractices

in offshore development. As a consequence, companies have been modifying and

adaptingagilepracticestoovercomethesechallenges.Howevertherehasbeenlittle

effort put to collect and document the common practices that have been used

repeatedlytosolverecurringproblemsinoffshoredevelopment.

Using the systematic literature review approach and applying customised search

criteriabasedon the researchquestions,we identifiedand reviewedover200cases

fromliterature.Aspartofthisresearchwealsoconductedsemi-structuredinterviews,

in which we involved practicing professionals who were working with distributed

teams.Asaresult,weidentifiedanddocumentedanumberofsolutionstoaddressthe

commonagileissuesinsoftwaredevelopment,whichweclassifiedasdistributedagile

patterns.

This research presents the challenges caused by offshore development, how they

affect the applicability of agile practices in offshoring. We have then developed a

catalogue containing the identified fifteen distributed agile patterns and have

classifiedthemintofourcategories.Wehaveusedacasestudytoexplainhowthese

patternscanbeappliedinoffshoresoftwaredevelopment.Toverifyandvalidateour

catalogue,weconducteda reflectionworkshop, inwhichwe invitedprofessionals to

review and comment on the patterns. The participants engaged in reviewing the

patterns and gave constructive feedback, which helped in improving the catalogue.

10

Based on their feedback, the distributed agile patterns cataloguewas finalised. The

cataloguecanhelppractitionersmakeamoreinformeddecisionwhilechoosingagile

fortheiroffshoreprojects.

11

Chapter1 Introduction

Recentadvancesinsoftwaredevelopmenthavemadeitpossibleandattractiveforthe

industrytomovetowardsGlobalSoftwareDevelopment(GSD).GSDisreferredtothe

practice in which companies move some/all part of their software project to an

offshorelocation.Forsomecompaniesthemotivationistocutdownoncost,whilefor

others themotivation is tobenefit fromthevariety in talentsavailable fromallover

theworld,orcloseness tomarket.Nonetheless,whatever the reasonwas tomaking

suchadecision,itisveryimportantforthemtoconsiderwhichtypeofglobalsoftware

engineering business model they will be using. Work has been done on proposing

different frameworks fromwhich organisations can selectwhich type ofGSDmodel

theywant to use (Robinson et. al, 1996; Prikladnicki et al. 2007 and Agerfalk et al.

2008).WehavepresentedanoverviewofdifferentmodelsinSection2.2.1.

Theterm“offshoreoutsourcingoroffshoring”iscommonlyusedforthepracticeofa

companytosubcontractworktothirdpartycompanies,whichareplacedatcountries

likeIndia,Pakistan,ChinaandRussia(Prikladnicketal.,2007).Thisway,acompanycan

focuson itscorebusinessand leavethedevelopmentofproductstocompaniesthat

canperformtheminhigherstandardsoratcheaperrates(Pilattietal.,2006).

The concept of offshoring isn’t new or exclusive to software development; many

companiesforyearshavebeenusingsubcontractorstoprovideassistanceinmultiple

areas,fromcleaningservicestoconsultations(Jahns,etal.,2006).Whathaschangedis

thatwiththehelpoftechnologythescopeofoffshoringhasexpandedinternationally

(Van, 2004). As technology has reduced the cost of communication, companies can

exchangeworkproductstofarawayplaces,cheaplyandefficiently.

A decade ago the trend of offshoring had increased mainly in the sector of

manufacturing(Garner,2004)butascommunicationbecamecheaperandfastermore

companies from different sectors started adopting the practice. In the IT sector,

offshoringhasbeenchanginghoworganisationsdevelopsoftwarearoundtheworld.

12

Themain reason why companies choose offshoring is because of lower production

cost (Pilattietal.,2006)which ismainlybecauseof lowsalaries incountriesoutside

Europe, the US and Japan. For example in India an average ICT worker earns one

seventh of the amount earned by a British employee (Global Wages Comparison,

2013).

Offshoring can offer additional commercial advantages beyond cheaper labour; for

exampleinacountrylikeIndia,whichprofits90%oftherevenuesofallITandservice

offshore activity, produces two million university graduates per year (Kobayashi-

Hillary,2005).Withthisoffshorecompaniescanseenewopportunitiessuchasaccess

to larger pool of skilled people, shared best practices andproximity tomarkets and

customers (Smite et al., 2011). Kobayashi-Hillary who went to Bangalore to open a

software facility comments “The issue now was not finding good people; it was

filteringtheexcellentfromthegood”(Kobayashi-Hillary,2005).

TherearemanyadvantagesofoffshoredevelopmentbutasGSDcontinuestogrowit

has been noted that it causes some issues, which are caused as teams become

distributedoverdifferentgeographical locations(Damianetal.,2006). Issuessuchas

trust, socio-cultural, communication and co-ordination and knowledge transfer are

examplesofthechallengesfacingGSD.Ononehandsuchissuesrepresentbarriersto

thedistributedteams;ontheotherhandithasparticularimpactonAgileteamswhich

favour face-to-face communication and co-working between team members. A

numberof teamshaveexperimentedandadaptedvariousagilepractices inorder to

overcometheabovechallenges.Suchefforts(althoughdocumented)remainindividual

anddifficult to share. In this researchwehaveprovidedsolutions for someof these

challengesbyidentifyingagilepracticesthatarebeingusedrepeatedlyforaddressing

global software development issues.We believe that by identifying and cataloguing

thesepracticestheycanbeeasilyretrievedandappliedforsimilarproblems.

13

1.1 ResearchProblem

Traditionally,softwarewasdevelopedatonelocationwherethewholeteamworked

fromthesameoffice.Similarlytheclients/sponsorsoftheprojectweresituatedinthe

same country. But as onshore software development became expensive companies

startedlookingforalternativewaystocutdownonsoftwaredevelopmentcost(Pilatti,

Audy, 2006).One suchalternativewas tomove someof their processes tooffshore

locations, as due to decrease in global communication rates companies could

coordinateworkviaonlinecommunicationtoolsandsetupcostincountrieslikeIndia

andChinaischeaperincomparisonstocountrieslikeUSA,UKandJapan(Prikladnick&

Audy,2012;Bush,Tiwana,andTsuji,2008;McLaughlin,2003)

Butascompaniescontinued to switch tooffshoredevelopment itbecameclear that

achieving reduced cost is not as straightforward as it initially seemed. As even if

companiesmanagetocutdowncostondevelopmentbysettingupcheapofficesand

finding cheap labor (Global Wages Comparison, 2013), offshoring introduces new

challenges. These challenges appear because companies distributed their team to

different locations having different time zones, different language and social values,

causingchallengessuchas:

• Theissueoftrustcausesdifficultyinformingalliancesamongfirmsthatdonot

know each other. It also introduces a risk of project failure as clients are

concerned with whether the offshore service provider will deliver the work

promisedwithoutcompromisingontheirrequirements.Lackoftrustcancause

misunderstanding and conflicts between the firms (Battin et al., 2001). This

issuewillbediscussedindetailinsection2.3.1.

• Socio-Culturalconflicts,suchasadifference in languages,nationaltraditions,

valuesandnormscauseproblems inoffshoresoftwaredevelopment (Carmel,

1999;Hofneretal.,2007).Asthedifferenceinlanguageorlanguagestylecan

cause problems while developing the code as the offshore team leaves

comments for the onshore team regardingwhat they have done but due to

14

difference in language the onshore team cannot understand their comments

hence resulting in a delay in the project development. This issue will be

discussedindetailinsection2.3.2.

• Theteamfacescommunicationandcoordinationissues(Beulenetal.,2002),as

theteammembersaredistributedondifferentlocationsandtimedifferences,

whichmakesitdifficulttohavereal-timeface-to-facecommunication.Thiscan

causeproblemsinsharinginformation.Thisissuewillbediscussedindetail in

section2.3.3.

• Companiesstartedtofaceknowledgetransferissuestheymovedtheirbusiness

anddevelopmentprocesstooffshorelocations,asanymistakeinthetransfer

process can cause projects to fail (Kedia et al., 2007). This issue will be

discussedindetailinsection2.3.4.

Thesechallengeswerenotpartoftraditionalsoftwaredevelopmentbecausetheteam

workedinthesamecountryhavingthesametimezone,face-to-facecommunication,

and same social values (Meyer, 2006). If these challenges are not handled properly

theycanmaketheoverallcostoftheprojectseveraltimeshigherthaniftheproject

wasdevelopedatanyonshorelocation(Iacovouetal.,2008;Hartmannetal.,2011).

In offshoring, companies also have to deal with additional tasks as the team is

distributedoverdifferenttimezones(Evaristoetal.,2004).Theadditionaltasksare:

i) They have to maintain good communication with all its offshore offices

otherwisetheinformationflowwillbeaffected(Carmeletal.,2005),

ii) The onshore office has to decide which work/project should be sent to

offshore locationandwhichshouldbedeveloped in-house (Lamersdorfet

al.,2008)and

15

iii) Once theprojectorprocess is selected theyneed tobecoordinatedwith

the onshore office in order to develop a product that meets the clients

requirements(Aundhetal.,2009).

Another problemwith offshoring is that the developmentmethodology for offshore

software development is different from the traditional approach as now companies

can either follow a global standard methodology for all its offices or it can have

differentdevelopmentmethodologiesfordistributedlocations(Senguptaetal.,2006).

Similarly the standard development methodologies starting from waterfall

developmentlifecycletoagileassumethattheteamislocatedatthesamelocation.

So if a company applies any of the standard development techniques by the book,

offshore projects are bound to fail. Many companies have customised agile

methodologies foroffshoreprojects, but thereare still limitations tohow successful

thoseprojectswillbeasagilemethodologyfocusesonface-to-facemeetingssuchas

daily-standupmeetingandretrospectivemeetings(Becketal.,2001).

The above challenges can directly cause problems in the software development life

cycle,whichcanresultintoaprojecttofail;morediscussionisprovidedinSection2.4.

Theproblemthatthisresearchwilltackleishowtoovercometheidentifiedchallenges

between the onshore and offshore teams as it affects agile practices on offshore

projects. This isparticularly important, as theemphasisof agilemethodologies ison

face-to-face meetings such as daily-stand ups, sprint meetings and sprint review

meetings(Benketal.2001),whicharedifficulttoconductinoffshoringastheteamis

distributedgeographicallyindifferenttimezones.Similarlyagilefocusesontheteam

to be self-organised (Benk et al. 2001) but due to lack or delay in communication

between theonshoreandoffshore team, it is difficult todistributeworkamong the

teammembersefficiently.TheseissuesarediscussedindetailinSection2.5.2.

16

1.2ResearchAimandObjectives

Inordertoaddressthechallengesbetweenonshoreandoffshoreteamssuchastrust,

socio-cultural, communication and coordination, and knowledge transfer issues,this

researchaimstoproposeapatternbasedapproachbyidentifyingrepeatingsolutions

which have been proven in overcoming those challenges so that practitioners can

applythisapproachinordertomitigatetheeffectofthechallengesintheirprojects.In

additiontothemaingoaloftheresearch,wehavefourspecificobjectivesandtheyare

summarisedasthefollowing:

i. Toconductsystematicliteraturereviewtounderstandandanalysetheexisting

literature on offshore software development. Thiswill build up the research

foundationandformtheresearchquestionsforthisresearch.

ii. Identifying the key challenges from literature that occur while developing

softwareonoffshorelocationsandinvestigatehowagilepracticescanbeused

toovercomethosechallengesand.Basedonliteratureandinterviewsidentify

if there is a recurringagilepracticesbeingused to solve the samechallenge

thatwecanclassifyasapattern.

iii. Developacatalogueof the identifiedpatternsthatwillbedocumented,as it

willfocusonfacilitatingoffshoresoftwaredevelopmentprojectsbyproviding

asaguidelineforpractitionersthatwanttooffshoretheirprojects.

iv. ValidatingtheDistributedAgilePatternscataloguebyusingKerth’sreflection

workshopmethod(Kerth,2001)andevaluatethecataloguebycomparingthe

existingsolutionspresentedinliterature.

1.3ResearchQuestions

Duringthecourseofthisresearch,anumberofquestionshavebeenidentifiedtobe

addressed:

17

RQ:Whataretherecurringadaptationsofagilepracticesthatarebeingusedwithin

offshoresoftwaredevelopmentinordertoaddresstheidentifiedissues?

Tobemorespecific,thestudy’sfocuswasonthefollowingtwoquestions:

RQ1: What are the agile practices that are being commonly used to deal with

offshorechallenges?

RQ2: Are the challenges identified in RQ1 recurring in offshore software

development?

1.4ResearchContributions

Thereisalackofeffortincollectingcommonpracticesthathavebeenusedrepeatedly

tosolverecurringproblemsinoffshoredevelopment.Inthisresearchwehavestudied

over200casesfromtheliteratureandinterviewedpracticingprofessionalsthatwork

in distributed teams. As a result we have observed a number of solutions for agile

issues in distributed development settings, which we have classified as Distributed

AgilePatterns.Wedefineddistributedagilepatternsasadaptationofanagilepractice

thatisbeingrepeatedlyappliedinordertosolvearecurringchallengeinadistributed

project scenario. The difference between distributed patterns and distributed agile

patternsisthatdistributedpatternsonlyfocusonpracticesthatarebeingrepeatedly

appliedinordertosolvearecurringchallengeinanoffshoreprojectirrespectiveofif

thosepracticesareagileornotwhereasdistributedagilepatternsfocusonrepeating

agilepractices.

This research confirms that there are four main challenges in offshore software

development, which are trust, socio-cultural, communication and coordination, and

knowledge transfer issues, thateveryorganisation facesand that theyhaveadapted

agilepracticestoovercomethosechallenges.

18

The findings of this research will strengthen the existing literature on distributed

softwaredevelopmentandprovideaknowledgebaseforagilepractitionerswhouse

orintendtouseagileapproachesinoffshoresoftwaredevelopment.Thedocumented

findingshavebeenobservedfromliteratureandpractitionersinordertopreparethe

patternscatalogue.

Practitionerscanusethepatterncatalogue inthebeginningofoffshoreprojectsand

makeinformeddecisionsabouthowtoadoptagileapproachesasgeneralizedpatterns

makeiteasierforothercompaniestoreflectonandtoapplytheresultstotheirown

cases.

1.5ResearchMethodology

Thefollowingresearchmethodology isdevelopedandadoptedforthisresearch.The

mainstagesofthemethodologyareoutlinedinFigure1.1anddetailofeachstageis

presentedinChapter3ResearchMethodology.

Figure1.1ResearchMethodology

19

Step1:ReviewPreviousLiteraturesandRelevantOffshoringChallenges.

In this step the previous relevant works is reviewed, to identify challenges

practitioners faces while developing their projects offshore. This helps in

acquiring a goodunderstanding ofwhat factors affect offshore projects. This

stepalsohelpsinansweringtheRQ1mentionedinSection1.3,astherewasa

needtostudywhatagilepracticesarebeingusedinGSD.

Step2:IdentifyandDefinetheResearchProblem.

The research starts by making assumptions on how to successfully develop

softwareonoffshore locations tomeet theobjectivesof the research. Todo

this,theresearchfocusesonstudyingandanalysingfactorsthataffectoffshore

softwaredevelopment,basedonthecasestudiesofdifferentcompaniesasthis

helpsinansweringtheRQ1mentionedinSection1.3inordertoidentifywhat

agilepracticesarebeingusedandalsotoanswerRQ2thatistoidentifyifthose

practicesarerecurringornot.

Toperformthisstepsemi-structuredinterviewsareconductedwithcompanies

who had chosen offshore processes for their projects. The research also

analyseshowmanycompaniesuseagiledevelopmentmethodologiesfortheir

offshoresoftwaredevelopmentprojectsandwhatlimitationstheyface.

Step3:CollectDatafromSystematicLiteratureReviewandInterviewingOffshore

Companies.

This research is carried out by, following Kitchenham’s guidelines for

conductingSystematicLiteratureReview(Kitchenhametal.2007).Thisisdone

to select primary studies from the existing literature.We also conducted 20

semi-structured interviewswithoffshorecompaniestogetpractitionerspoint

ofviewonthechallengestheyfacewhileworkingonoffshoreprojects.

20

Step4:AnalyseDatacollectedfromSystematicLiteratureReviewandInterviewing

Offshorecompanies.

To analyse the data collected we use content analysis as proposed by

Kripendorfftoverifytheresultsofourfindings(Kripendorff,2004). Detailsof

thisstepispresentedinsection3.3.2.

Step5:DesignanddeveloptheDistributedAgilePatternsCatalogue.

BasedonthefindingsaDistributedAgilePatternsCatalogueisdeveloped;this

ispresentedinSection4.5.

Step6:ValidateandEvaluatethePatternCatalogue.

Inorder tovalidate theDistributedAgilePatternsCatalogue,weconducteda

workshopbyusingKerth’skeep/tryreflectionworkshopmethod(Kerth,2007).

Bydoing this, feedbackcollected fromthecompanies (whowouldhavebeen

interviewed) is sought to obtain their views on the catalogue, and its

effectiveness.Basedontheiranswersthecatalogueisvalidatedandthishelps

inansweringtheRQ2mentioned inSection1.3as itconfirmsthattheseagile

practicesarebeingusedtosolverecurringproblemsinGSD.

To evaluate the pattern catalogue we compare the catalogue with other

solutions mentioned in the literature for solving GSD challenges, which is

presentedinSection5.3.

Step7:ModifytheCataloguetoImproveResults.

Thenecessarymodificationsaremadeinthecataloguebasedonthefeedback

givenby the companies. This stepallows the research to improve the results

producedinthecatalogue.

21

Step8:DocumentthePatternCatalogue.

The final stageof the research is todocument thepatterns catalogue,which

incorporates the answers of all the research questionsmentioned in Section

1.3.

Basedontheabovediscussionitcanbeseenthatwehaveusedaninductiveapproach,

astheresearchmovesfromspecific togeneral.Aswefirst identifiedanddesigneda

specificresearchproblemandthendevelopedagenericcatalogueofdistributedagile

patterns. In section 3.3.2 we have presented detail explanation on how we have

appliedinductiveapproachinourresearchapproach.

1.6StructureandHowtoReadtheReport

ThisthesispresentsthecompleteDistributedAgilePatternsCatalogue.Theremainder

ofthethesisisarrangedinthefollowingchapters.Chapter1presentstheresearchaim

and objectives, the research problem, the research questionswewill answer in this

studyandtheoverviewoftheresearchmethodologythatiscarriedouttoanswerthe

aim and objectives set for this study. Chapter 2 Offshore Software Development,

presents the background of offshore software development which concentrates on

describingdifferenttypesglobalsoftwaredevelopmentmodelsaswellaswhatarethe

benefitsandchallengesofoffshoresoftwaredevelopmentandwhatroleagileplaysin

overcomingthosechallenges.Italsofocusesonhowpatternscanbeusedtoovercome

the challenges of offshore development. In Chapter 3 we present the research

methodology that has been followed in order to conduct this research. Chapter 4

consistsof the final versionof theDistributedAgilePatterns catalogue,aswedidn’t

wanttoconfusethereaderbypresentingtwoversionsofthecatalogue,theunrevised

versioncanbefoundinAppendixF.Chapter5presentshowthecatalogueisvalidated

and evaluated with the use of reflective workshop and comparing other solutions

present in literature for offshore software development. To help practitioners

understandhow theDistributedAgilePatterns canbeapplied,Chapter6presents a

case study on how the requirement phase is conducted using the distributed agile

22

patterns catalogue and finally in Chapter 7, the conclusions has summarised the

findingsofthisresearchandwehavepresentedanoverviewofthefuturework.

1.7ChapterSummaryThis chapter presented an introduction to the thesis through defining the research

problem and discussing the researchmotivation, then the aim of the research, the

objectives, and researchquestionswerepresented. The research contributions have

beendefinedalongwiththeresearchmethodology,inadditiontodefiningtheoutline

ofthethesis.

In summary, this thesis presents a catalogue of distributed agile patterns which

practitionerscanusewhileoffshoringtheirprojects.Inthenextchapter,abackground

fortheresearchfieldispresented.

23

Chapter2 OffshoreSoftwareDevelopment

2.1Introduction

This section summaries the work that has been completed to-date. It presents the

background research that has been done on offshore software development so far.

The background involves reviewing the models of offshoring and the benefits it

provides. The review also covers and highlights the main challenges and issues

offshore software development which we identified using Systematic Literature

Review.Wehavealsomentionedhowagilecanbeusedtoovercomethosechallenges

andwhatarethelimitationsofagile.Wehavealsopresentedfiveapproachesusedin

literature to facilitatepractitioners inagileadoption. Lastlywehavementionedhow

patternscanaidinagileadoptioninoffshoresoftwaredevelopmentbypresentingan

overviewofcurrentpatternsbeingusedforagileadoptionandgivinganoverviewof

thedistributedagilepatterns.

2.2BackgroundofOffshoreSoftwareDevelopment

In this section we have presented a background study on offshore software

development to understand why organisation move towards offshoring their

processes.Wegaveanoverviewofdifferenttypesofoffshoremodelsbasedonwhat

typeofbusinessmodel theychose to followwhileoffshoring theirprojects.Wealso

presentedwhatarethekeybenefitsthatorganisationsconsiderwhiledecidingtogo

foroffshoresoftwaredevelopment.

2.2.1OverviewofOffshoreModels

Whenanorganisationdecidestomovesomeoftheirprocessestootherlocations,itis

very important for them to consider which type of global software engineering

businessmodeltheywillbeusing.Robinsonprovidedaframeworktocategorisethese

24

business models based upon relationship structure and geographical location

(Robinsonetal.,2004).

PrinkladnickiusedanadaptationofRobinson’sframeworkbasedonthemostcommon

models used in practice, whichwas than presented in Agerfalk and Fitzgeraldwork

(Prinkladnickietal.,2007;Robinsonetal.2004;Agerfalketal.,2008).Inthisthesiswe

haveusedafurtheradaptedversionwith inputsfromtheOrganisationforEconomic

Co-operation&Developmentreport(OECD,2004)showninFigure2.1.Thereasonfor

choosing this version is because it clearly identified the fourmain business models

selectedbyorganisationsthatdecidetomovetheirprocessestoadifferent location,

where its in thesamecountryoranoffshore location.Thissectiondiscusseseachof

thesemodelsindetail.

Figure2.1BusinessModelsforGlobalSoftwareEngineering(OECD,2004).

2.2.1.1DomesticOutsourcing

Domesticoutsourcingisalsoreferredasonshoreoutsourcing(Robinsonetal.,2004).

In this business model an external company acts as a subcontractor for providing

software development services or software products to an organisation. In this

scenariothesubcontractingcompanyislocatedonshore(Prikladnickietal.,2012).The

25

companies that select this type of businessmodel go for a joint-venture offshoring

approach.

In joint venture offshoring, an organisation collaborates with a local company to

developsoftware.Thiscollaborationcantakemanydifferentforms.Insomecasesthe

revenuestreamisseparatedfromrestofthecompany’sbusinessastheserversbeing

outsource generates its own revenuewhich results in reduced risk for the company

offshoringtheirservices.Boththecompanyshareapercentageoftherevenueearned.

Inothercases,jointventurescanbebetweentwoormorecompanies,thegoalbeing

tobuildanoffshorecentrewithmultipleownersinordertoreducethestart-upcosts

andoperational risks.Hence in jointventurescompanies’collaborationcanbeequal

that isbothof thecompanyhaveequal stakeor thecompaniescanbe independent

butjustcontributetheirresourcestoeachother.Thegoalofthismodel istobenefit

from the strengths of the organisations, in order to achieve awin-win situation for

bothofthem(Babu,2005).

Tomotivate both the companies to go for joint venture contracts,many companies

include a build-operate-transfer (BOT) clause. This clause helps the companies to

decideonhowtheywillworktogetherinordertocompletetheproducts(Vashisthaet

al.,2005)andfurthermoreitalsoallowstheonshorecompaniestoselltheirstakesto

foreigncompaniesafterachievingagreed-uponmilestones.

Jointventureoffshoringhasmanyadvantagessuchasboththecompanieslearnfrom

eachother.Italsohelpsbuildrelationshipsacrossthevendersandboththecompanies

sharetheirrecoursestodevelopthebestproduct(Babu,2005).

2.2.1.2 SharedServices

SharedServicesisalsoreferredasonshoreinsourcing.Inthisbusinessmodelthereisa

department in the company’s building or a subsidiary in the same country that

provides software development services for the internal projects (Prikladnicki et al.,

26

2012).Thismodelisthemostsimpleandknownbusinessmodelasnotmanyrisksare

involvedinadoptingitsincealltheteamsareworkinginthesamecountry(Prikladnicki

etal.,2007).

Manycompanieschooseonshoreinsourcinginordertoavoidtheriskofmovingtheir

processes to an offshore location. A study done by Amiti in the United States, the

United Kingdom, andmany other industrialised countries showed that jobs in these

countriesarepreferredtobe insourcedratherthantooutsourcethembecausethey

areconcernedthat if theyoutsourcedmore jobstheywillbe losinganetamountof

jobsfortheirnationals(Amitietal.,2005).

Onshoreinsourcingisconsideredthebetteralternativetooutsourcingasthejobsstay

inthecountryandtheydonothavetoinvestinthestart-upcosts(Prikladnickietal.,

2012). Similarly companies can avoid challenges such as communication and

coordination problems, language issues, software quality standard issues and trust

issues(Prikladnickietal.,2007).

2.2.1.3 InternalOffshoring

Internal Offshoring is also referred as offshore insourcing. In this businessmodel, a

company internally offshores its services by creating its own software development

centre (subsidiary) in foreigncountry (Prikladnickietal.,2012).Somecompaniesopt

fortheultimateapproach,“doityourself”thatisgooutandbuiltyourownsubsidiary

centreinanoffshorelocation(Vashisthaetal.,2005).Manycompaniesgodirectly in

for a subsidiary or local offices instead of opting for joint ventures, as there

managementiscomfortableindealingwithinternationalandlocalmarketoperations.

Thecommontermsusedforthiskindofmodel includeoffshoredevelopmentcentre

(ODC),captivedevelopmentcentre,branchorlocaloffice.

Companies usually use such a model when they already have very large physical

presences in thecountries involved in theoffshoring.Sometimesthecaptivecentres

27

run independent businesseswith their ownbudget and bottom-line accounting.GE,

HSBC,andAmericanExpressareconsideredthemostsophisticatedatdeploying this

model. Another example is Citibank who does commercial banking in Brazil and

Portland.

Theadvantagesofthismodelare,itguaranteesmarketforacompany’sservicesandit

helps in establishing management hierarchy. It also alleviates some organisational

issuessuchascontrolandpoliticsthatmanagetheback-officeoffshoreactivitieswith

external vendors (Robinson et al., 2004). This approach has one key challenge that

apart from internationalisation and localisation of business management, managers

are concerned about finding the right staff, line works, technical experts and line

managersfrommulticulturalbackgrounds(Aronetal.,2005).

Manylargeorganisationsarecomfortableinmanagingtheirtechnologydevelopment

andinnovationatlocaloffices.LargesoftwaredevelopmentcompaniesincludingIBM,

Microsoft and Oracle already have global marketplace and are comfortably moving

workaroundtheworld(Babu,2005).

2.2.1.4 OffshoreOutsourcing

OffshoringOutsourcing is also referred, asoffshoring. It is themost commonlyused

business model by companies. In this business model external suppliers that are

located in other countries (offshore) provide software development services

(Prikladnickietal.,2012).Carmeldefinesoffshoringasmovingbusinessprocessesthat

werebeingdoneatalocalcompanytoaforeigncountryinordertotakeadvantageof

cheaplabour(Carmeletal.,2005).Whileselectingthisbusinessmodelcompaniescan

choosefromthreedifferentapproachessuchas:

i. Service-provideroffshoring,

ii. Dedicatedcentresand

iii. Third-partytransplant.

28

In service-provideroffshoring,companiessubcontractdevelopmentwork tooffshore

organisationsinordertofocusoncorebusinessactivities(Vashisthaetal.,2005).The

advantagesofchoosingthistypeofoffshoringratherthanbuildingsubsidiaryoutletsis

similar to the advantages provided by offshoring rather than keeping all the

functionalities in house such as getting product developed at low cost and

concentratingmoreoncorebusinessactivities(Vashisthaetal.,2005).Henceinorder

toavoidtherisksattachedwithoffshoringandcapitalizefromthebenefitsitprovides

companies choose to outsource projects, program, and individual work orders to

offshorevendors.

Thismodelisbecomingincreasinglypopularanditencompassesawiderangeofwork

includingsmallprojectstomulti-yearcontractscontainingofbudgetup-tomillionsof

dollars(Aronetal.,2005).PopularcompaniessuchasGE,AmericanExpress,VeriSign

andAbbeyNationalarealreadyusingthismodelsuccessfully(Vashisthaetal.,2005).

Anotherapproachofthismodelistocreateadedicatedcentrethatissomecompanies

are too cautiousaboutquality,whichprevents them fromhiringanoffshore service

provider,andtheyalsohaveissueswithcost,whichpreventsthemfrombuildingtheir

ownoffshorecentre.Suchcompaniestakeanalternativeapproachinwhichtheybuild

dedicatedcentrerelationship.Inthismodelanoffshoresupplieroperatesadedicated

centreforacompanybutthestaff,equipmentandresourcesareallwhollydedicated

tothecompany.

Such centres do share some processes and long-term risks, which include co-

ownership or co-leasing of resources. An example of a company using thismodel is

Wipro.WiproisadedicatedcentreforSunMicrosystemasitrunsthe“Orbit”,whichis

ahighlytechnicaldeveloperassistancecentreforSunMicrosystem’SolarisOperating

System(Sadagopan,2002).Afterworkingasadedicatedcentrefor10yearstheynow

have access to Sun’s Wide Area Network and troubleshoots developer needs from

aroundtheworld.

29

In third-party transplant approach, a third-party rather than a company builds and

maintains the offshore presences of a company (Vashistha et al., 2005). Many

companies that already outsources theirwork on onshore third- party locations use

thismodelasit’sanaturalprogresstomovetheirworktooffshorelocationsinorder

toeithercutdownoncostortogainprofitbymarginingwithathird-party,orboth.

Anexampleofacompanyusingsuchamodel isAccenture. Ithasmorethan83,000

employees;over5,000arebasedinlow-costdeliverycentresinlocationssuchasIndia

and the Philippines (Robinson et al., 2004).This allows its client companies to that

advantage from the low- priced labour without having to go through the risk of

starting up in those markets. The objective of Accenture is to provide a faultless

outsourcingexperienceforcorporations(Hendriketal.,2011).

Thismodelallowscompanies likeAccenturetodistributeandmanagetheiractivities

acrossmultiple global locations at lower rateswithout risk. It also answers to faster

time-to-market requests by dividing work among onshore and offshore locations

(Robinsonetal.,2004).Manylargecompaniesthathireglobaloutsourcerspreferthis

distributed approach as this model saves clients from huge investments on team

employmentanditadaptstothechangingrequirementsoftheclient.

2.2.2BenefitsofOffshoreSoftwareDevelopment

BasedupontheframeworkmentionedinFigure2.1thefocusofthisreportisonthe

offshoring.Inthissectionwewilldiscussthebenefitsduetowhichcompanieschoose

offshoresoftwaredevelopment(Hittetal.,2002).

2.2.2.1 EconomicBenefits

AsmentionedinChapter1thatthemainreasonforcompaniestoswitchtooffshoring

istocutdownoncost(Pilattietal.,2006;Radlo,2016).Similarlyaresearchdoneby

Smiteconfirmsthatthemainreasonforcompaniestoadoptoffshoredevelopmentis

to reduce cost (Smite et al., 2011). Cut-down on cost is achieved by paying lower

30

salariestotheiremployees(Smiteetal.,2011).AsinIndia,asoftwaredeveloper’sbase

annualsalaryisU.S$15,000thatisonequarterofthesalaryofanIrishdeveloperwho

earnshalf incomparisontoaUSdeveloper(Conchúiretal.,2009).Othereconomical

factorsthatencourageoffshoringare interestrates,developmentofcapitalmarkets,

capitalcostanddevelopmentoftechnologycentres.

Among the above-mentioned factors, development of technology centres plays an

important role in finding the required resources.We know that talenteddevelopers

arethekeyfactorforgreatdevelopmentproductivityandqualityhoweveritisdifficult

tofindthemingeneral.Withthehelpofoffshoringthisconstrainthasbeensolvedas

itprovidescompanies’accesstotechnicalexpertsfromallovertheworld(Smiteetal.,

2011).ForexamplecountrieslikeIndiaandChinaarehighlypopulatedastheyhave1

billionpeopleandtheyproducehundredsofthousandsofsoftwareengineersperyear

(Conchúiretal.,2009).

Manysoftwarecompaniesgetintooffshoresoftwaredevelopmentinordertoprovide

theirclientswithawidehorizonofexpertstochoosefrom.Astheygatherspecialised

peoplewith specific skill setandability toexcel inonearea,whichenables them to

deliverperfect-engineeredapplications.

Anotheradvantageprovidedbydevelopmentoftechnologycentresisthatitprovides

competitive advantageby getting innovative ideas fromdifferent countries. Thishas

been also confirmed by amanager at Global Investments who said “Having people

coming from different backgrounds will always help, getting different views from

different people, since people coming fromdifferent parts of theworldwould have

differentwaysofdoingsomething.” (Conchúiretal.,2009).ResearchdonebyPorter

andStern shows thatAsianeconomies showahigh rateof investment intonational

innovativecapacityincomparisontoLatinAmericaneconomies(Porteretal.,2001).

31

2.2.2.2 Political-LegalBenefits

Political-legalbenefitsincludetaxationlaws(Hittetal.,2002),rightsandworkinghours

of labours, trade barriers such as tariff and non-tariff barriers (Stack et al., 2005).

Treaties and agreementwithin trade unions such asMERCOSUE,NAFTA andASEAN

playanimportantroleinencouragingcompaniestogoforoffshoring.Anexampleof

trade barriers is that for the past 10 years they keep on decreasing, which aid in

facilitatingoffshoreagreements(Jahnsetal.,2006;Oshrietal.,2015).

An example of flexible labour laws can be see from the success of an overseas IT

services providerWipro. It is India’s most successful outsourcing consultant. It gets

12%of itswork fromUKcompanies (TheEconomist,04-03-2004)and in2012 ithas

achieved the awardof ‘OffshoringProject of the Year' byUK'sNationalOutsourcing

Associationfortheirproject ‘BTRecognized’(Wipro,14-12-2012). Inastudydoneby

EconomicTimesshowedthat India isstill theNo.1destinationfor IToffshoring(The

EconomicTimes21-12-2010).

Considering that UK economy only represents one-sixth of the west-European total

economyshowshowmuchUKcompaniesareinclinedtowardsoffshorebusiness.One

majorreasonbehindthisistheflexiblelabourlawsintheUK,whichmakesitrelatively

easyforUKcompaniestorelocatejobsoffshore.

As thepolitical and legal factors provide certainbenefits they alsohave adownside

suchasduetothemlabourconditionsareexploitedandsomedebatethatduetothis

thenational labourmarket iseffectedasthenation losses jobstooffshorecountries

thoughthereisstillnoconsentonthismatter(vonCampenhausen,2005).Anexample

of this is that in a debate, titled “Offshoring in 2012 and beyond” held by British

ComputerSocietyconcludedwiththattheUKisnotgoingtonecessarilyloseIT-related

jobstooverseasprofessionalsasinorderforoffshoringtoworksuccessfullytheyneed

ahighlyskilledteamontheonshorelocation,whichcreatesnewjobopportunitiesfor

thepeopleintheUK(BritishComputerSociety,2012).

32

2.2.2.3 DemographicandGeographicBenefits

Socio-demographic benefits include population size, age structure, education levels,

workforcemotivationandtimezonedifference.Asmentionedearlierthatincountries

likeIndiaandChinaarehighlypopulated.Theyhave1billionpeopleinwhich53%of

the population is under the age of 25 (Robinson et al., 2004) hence producing

hundredsofthousandsofsoftwareengineersperyear(Conchúiretal.,2009).Another

significantfactoristheavailabilityofEnglish-speakingpopulationincountieslikeIndia,

South- Africa and Philippines, which makes it easy for companies to outsource

customerservicessuchascall-centrestosuchlocations(vanZoest,2004).

Considering the time zonedifferencebetween theoffshore countries companies cut

downon costby increasedevelopment timebyadopting “follow the sun”workflow

which means it allows 24 hours development as due to different time zones a

company’s employees can do development 24hrs a day (Carmel, et al., 2001). For

exampleanemployeeworksfrom9a.m.to5p.m.intheUSA.At5p.m.shehandsover

theincompletetasktoacolleagueinAustraliawhoworksfrom9a.m.to5p.m.based

onhistimezone.At5p.m.accordingtohiscountry,hetransferstheupdatedtasktoa

colleagueinPolandwhoworksontheupdatedtaskforthenexteight-hoursandthen

forwardsittohiscolleagueintheUSA(Gupta,2009).

WhiletheemployeeintheUSAhadleftworktwoofhercolleaguesworkedonhertask

aswhenshewillcometotheofficenextmorningalotoftheworkwouldhavebeen

done. Thiswork scenario takes advantage of the geographical distances as it allows

peoplefromdifferenttimezonestoworkround-the-clockinordertobuildsoftware

(Gupta,2007).

Thework distribution among the team can be done in twoways. First either the 3

teamsdistributedondifferentgeographicallocationsworkonthesametaskandeach

teamkeepsupdatedthetaskasmentionedintheabovescenarioorsecondlyamost

efficientwayisthatwedivideddifferentaspectofthesameproblemamongtheteam

33

for example in Figure 2.2 we can see how a problem has been distributed among

differentteamsallovertheworld.

Figure2.2.DistributionofWorkamongMultipleDistributedTeams.

2.2.3.4 TechnologicalBenefits

Technological benefits are referred to the development of telecommunication and

transportationtechnologiesespeciallytheInternetandmobilecommunication.Most

ofthesedevelopmentshappenedduetothedramaticincreaseinthememorysizeof

microprocessors,storage, increaseintheintegrationof informationtechnologiesand

telecommunications(Picotetal.,2003).

Many companies started moving towards offshoring as it became cheaper to

communicate with offshore offices via conference calls and video conferencing

(Prikladnicki et al., 2012). With the help of cheaper technology available the

organisational and national boundaries remained no longer important as now

companiescanrelocatetheirofficestooffshorelocationswithoutfacingahugehurdle

ofcommunicationandtransportationcosts(Jahnsetal.,2006;Oshrietal.,2015).

Similarly use of standard tools for development of software across countries helps

informationsharingasalltheinformationisrepresentedinthesameformat(Beulenet

al.,2005).Fromaservice-providerpointofviewuseofstandardglobaltoolssupports

34

consistent and cost effective service provisioning, which means it allows consistent

follow of information throughout the team and it encourages efficient delivery of

services(Beulenetal.,2005).

2.3 AStudyonIdentifyingtheChallengesofOffshoreSoftwareDevelopment

As highlighted in the previous section there aremany benefits to adopting offshore

development, however as it continues to grow (Damian et al., 2006) it has been

observed that it causes some challenges, due to temporal, geographical and socio-

culturaldifferences (Holmstromet al., 2006).As softwaredevelopment is ahuman-

centric and socio-technical process, it depends on complex interaction, attitudes,

behavioural norms and communication approaches, which can lead to

misunderstandings due to anymisinterpretation of the project aims that can result

intoconflicts,mistrustandunderutilizationoftalent(Ozawaetal.,2013).Studiesdone

by Carmel (Carmel et al., 2005) and by Sahay (Sahay et al. (2003) show that these

challengescancausecomplications to theprojectprocessessuchascommunication,

coordinationandcontrolofprojectactivities(Damian,2002,Janetal.,2016).

It has also been observed that due to the significant differences in engineering

culture/stylearoundtheworldcollaborationsbetweencountrieshaveuniqueflavours

(Herbslebetal.,2005). In this sectionwewill studyhowtemporal,geographicaland

socio-cultural differencescan pose different challenges for companies adopting

offshoresoftwaredevelopment.Thestudyfocusesonthechallengesthatoccurinthe-

offshoringbusinessmodel,offshoreoutsourcing.

As the characteristics of onshore and offshore are different causing different

challenges. Based on an extensive literature review on offshore software

development,we identified fourkeychallenges thatoccuras theteam isdistributed

over different time zones and these challenges also affect the adoption of agile

practices in offshore development. In this section we study the challenges that are

inherenttooffshoringandthenwediscusshowtheyaffectagilepractices.Table2.1

35

showstheresultsofthestudythatwecarriedouttoidentifytheinherentchallenges,

which are trust; socio-cultural; communication and co-ordination; and knowledge

transferissues.Thereasonforchoosingtofocusonthesefourchallengesisbecause

of their repeatedoccurrence in literature. Table2.1 shows the frequency that these

challengeshaveoccurredintheliterature.Thefirstcolumnshowsthecategoriesofthe

challengesconstructedfromthedataextractedfromtheevidencethatarepresented

inthesecondcolumn.Eachoccurrencehasthesameweight,thusthefrequencyofthe

occurrence shows the number of times a category has occurred in literature. The

selectedstudiesarepresentedinAppendixA.

Table2.1.ChallengesinOffshoreSoftwareDevelopment.

No. Challenge Evidence Occurrence

1 Trust E1, E2, E3, E4, E5, E6, E7, E11, E13,

E19,E20,E24,E28,E29,E30,E33,E38,

E41,E42,E45,E46,E47,E49,E54,E56,

E57,E62,E67

29

2 Socio-Cultural E1, E2, E3, E4, E6, E7, E11, E12, E16,

E18,E19,E24,E26,E27,E28,E31,E32,

E35,E41,E42,E46,E47,E44,E48,E52,

E62,E66,E67

29

3 Communication

andCo-ordination

E1,E4,E6,E8,E9,E10,E16,E16,E18,

E19,E21,E22,E23,E24,E25,E28,E36,

E37,E39,E40,E41,E43,E46,E47,E48,

E50,E52,E53,E55,E58,E59,E60,E61,

E62,E63,E64,E65

37

4 Knowledge

Transfer

E1,E10,E14,E15,E22,E32,E34,E46,

E47,E51,E53,E55,E60,

13

36

2.3.1 TrustIssues

The firstmajor challenge to offshore development is the factor of trust. Trust is an

important aspect of interpersonal (Boon et al., 1991) aswell as inter-organisational

relationship (Ring et al., 1994) in order to have successful partnership and alliances

amongthefirms(Dasetal.,1998).Itisalsoconsideredasacrucialfactorforbuilding

business relationships as trust enables open communication which, results in high

performance of the team, high quality of projects and satisfactory decision making

process(Kanawattanachaietal.,2002;Morganetal.,1994;Rousseauetal.,1998).

In terms of software outsourcing, trust helps in establishing an open exchange of

information and cooperative behaviour among the companies. It also helps in

removingconflictandnegotiationonsoftwaredevelopmentcostanditalsoimproves

response to any crises, whichmight occur during a project (Rousseau et al., 1998).

Moreover trust also enables ease in development process as it encourages an open

discussion in the requirement gathering process and helps remove unnecessary

expensivedocumentation(Humphrey,1989).

Trustplaysanimportantroleinoffshoresoftwaredevelopmenthoweveritisdifficult

to establish because it is difficult to develop a relationship with unknown foreign

partnersthataretimelyandgeographicallydistant(Prikladnickietal.,2012).Themain

reason behind this is that the companies do not have any relationship beyond the

projectitself,whichisofalimitedduration.Moreovertrustcanbedifficulttoestablish

as most projects are developed through structural mechanisms, which include

deliverables, penalty clauses and reporting arrangements whereas in-house

developmentrelaysmoreontrustratherthanondetailsstructuredreporting(Lander

etal.,2004).

Whilerealisingthedifficultyinestablishingtrustinoffshoreprojectitisstillneededin

ordertocooperatedwithforeigncompaniesasdistrustcanhurttheperformancesasit

leads to finger pointing and each organisation starts focusing on how other

organisations may have hurt the project whereas trust improves the performance

37

(Sabherwal, 1999). Issues in trust have led some organisations to create their own

software development centres in countries like India, China, Russia and Brazil

(Prikladnickietal.,2012).InSection2.4wehavedemonstratedhowtrusteffectseach

stageofsoftwaredevelopmentlifecycle.

2.3.2 Socio-CulturalIssues

Inoffshoredevelopmentdistributedteamsfacemanysocio-culturaldifferences,such

asdifference in languages, national traditions, values andnorms. Kluckhohn identify

fiveareaswhichall-culturalgroupshavefundamentalthroughdifferingbeliefs,which

arelistedasfollows(Kluckhohnetal.,1961):

• Howacultureviewshumannature,

• Therelationshipofitspeoplewithnature

• Priorityitgivestotraditionalcustoms,futureplansorpresentevents.

• Howisthesocietyorganised,isitlinearinhierarchy?

• Howisbusinessandlifeconducted?Publicallyorprivately,oramixofboth?

Similarly another widely refereed work on culture is by Hofstede (1980,1997), who

developedasetofculturalindices.Heidentifiedfiveculturaldimensions,whichare:

• PowerDistance

• Individualism/Collectivism

• Masculinity/Femininity

• UncertaintyAvoidance

• Long-Term/Short-TermOrientation.

Thesocio-culturaldistance is themeasureofoneperson’sunderstandingofanother

person’svaluesandnorms (Pilattietal.,2006). It iscommonlyobservedthatpeople

from one society strangely perceive the actions of people from another society as

noted by Kotlarsky, culture can have a huge effect on how people understand and

reacttocertainsituations(Kotlarskyetal.,2005).Ithasalsobeenobservedthatteam

38

memberswithdifferentvaluescauseconflictswithintheteamresultingindecreasein

motivation, involvement and cohesiveness with the team members (Ozawa et al.,

2013).

TrompenaarsandHampden-TurnerbuildtheirworkonHofstede’sculturaldimensions

withthefocusontheimpactof interculturalvariancesonbusinessandmanagement

process (Trompenaars et al., 2004). They developed a set of seven values for

dimension,whichareshowninTable2.2below:

Table2.2SevenValuesforCulturalDimensions(Trompenaarsetal.,2004).

No. CulturalValueDimension

1.

Universalismsvs.Particularism

Rules to be followed under all

circumstances

Special consideration based on the

uniquenessofthesituation.

2. Individualismvs.Communication

People believe in personal freedom

andachievement

Peoplebelievethatthegroupismore

important than individual

achievement.

3. Specificvs.Diffuse

Keep work and personal lives

separate. Focused on work-oriented

relationships.

Overlap between work and personal

life.Believethatinordertohavegood

relationshipswithco-worksisvitalfor

thesuccessoftheirbusiness.

4. Neutralvs.Emotional

39

Reluctant to reveal their feelings and

make an effort to control their

emotions.

Display their thoughts and feelings

openly. People find ways to express

theiremotions,evenspontaneouslyat

work.

5. Achievementvs.Ascription

Theorganisational culture values you

based on your performance at work.

They believe that you are what you

do.

Status intheorganisationisbasedon

a variety of factors such as power,

titleandposition.

6. SequentialTimevs.SynchronousTime

Likeevents tohappen inasequential

order. They place a high value on

punctuality, planning and sticking to

schedules.

Focus on past, present and future

events as interwoven periods. Work

on several projects at once and

consider planning and commits

flexibly.

7. InternalDirectionvs.OuterDirection

Control nature of their environment

to achieve their goal. This includes

how they work with teams within

theirorganisations.

Consider that the nature of the

environment controls them and that

they must work with their

environmenttoachievetheirgoals.At

work they focus their actions on

others in order to avoid conflicts

where possible and need constant

reassurance that they are going a

goodjob.

40

Tylor,awellknownSociologistandAnthropologistdefinedculture,as“Cultureisthat

complexwholewhich includes knowledge, belief, art,morals, law, customs and any

other capabilitiesandhabitsacquiredbymanasamemberof society” (Tylor1871).

Fromthisdefinitionofcultureitisclearthatcultureplaysagreatroleinallaspectof

life. Similarly in offshore software development the socio-cultural distance between

distributesteamsisacomplexdimensionasitinvolvesorganisationalculture,national

culture and language, politics and motivation of individuals and work ethics

(Holmstrometal.,2006).

Ozawa et al. (2013) identified three main challenges causes due to socio-cultural

differences,whichare:

i) Differenceintheopennessinthesociety.

ii) Differenceinthewillingnesstoadoptnewtechniquesandtechnologies.

iii) Differenceincommunicationmethods,implicitoverexplicitcommunication

The most obvious disadvantage is language, as English is not the first language in

counties like India, Pakistan and China so extra effort is required to communicate.

Differences in language can lead to miscommunication due to language style or

incorrect use of vocabulary (Carmel, 1999; Hofner et al., 2007). Some reports show

thatlanguageproblemaffectstheproductandthecodeitselfasthecommentsinthe

codefromanoffshoreteamwhosefirstlanguageisnotEnglishmayseemoddornot

understandable byonshore team.Hence adding a hidden cost of codemaintenance

(Matloff,2005).

InaresearchdonebyLee,showsthatculturaldifferencesaffecttheproductandthe

processofdevelopment(Leeetal.,2001).Alotofworkhasbeendoneonhowmuch

culturaldifferencesaffect theendproduct inorder forpeopleofa region toengage

withtheproduct(Yeo,2001).ForexampleanemployeeinaUScompanycandirectly

passworktohispeerinIndiaeasilybypassingthemanagementhierarchywhereasan

employee in India cannot do so without upsetting higher management. This shows

41

howculturesoftwodifferentcountriesaffecttheworkplaceenvironmentasinIndia,

theyfollowstrictmanagementhierarchiesandinUStheydon’t(Matloff,2005).

AsimilarexperiencewasobservedwhenaJapanesecompanyoffshoredtheirsoftware

projecttoacompanyinChina(Ozawaetal.,2013).Theywerefacingdifficultiesdueto

thelowqualitydeliverablesandahighturnoverrateofChinesemembersbecauseof

socio-culturaldifferences.BasedonOzawaetal.(2013)wepresentasummaryofthe

socio-culturaldifferencebetweenJapanandChinainTable2.3(Ozawaetal.,2013).

Table2.3.CulturalComparisonbetweenJapanandChina(Ozawaetal.,2013).

No. Japan China

1. Ajobisforalifetime. Acquirenewskillsandswitchjobs.

2.

Hire fresh graduates and teach them

tofitintheirorganisationratherthan

tohireexperiencedpeople.

Preferhiringexperiencedpeople.

3.

Focus on avoiding failure and use

existing methodologies rather then

focusing on attaining success and

tryingnewtechnologies.

Want to acquire new skills and try

new methodologies and

technologies. More focused on

success.

4.

Tight grouped communities, so they

understand each other without

“implicitly”sayingthem.

Morediversity, sousemoreexplicit

informationincommunication.

5. Questioningconsideredhumiliation. Questioningconsideredhumiliation.

Due to the differences in the teams’ socio-cultural values, the Japanese company

foundithardtoretainitsChineseemployees,astheirmotivationtoworkwaslow.The

projectspecificationswerenotclear,astheJapanesecompanyreliedmoreonimplicit

42

information,whichwerenotcleartotheChineseteammembersandsincequestioning

isconsideredhumiliation inboththecultures, theChineseteammembersdidn’task

the Japanese clients to clarify the requirements hence resulting in low quality

deliverables.

MacGregor identified 5 cultural patterns, which highlight the problems caused by

socio-cultural challenge when the team is distributed over different locations

(MacGregoretal.,2005).Table2.4,givesanoverviewoftheirpatterns.Thoughthey

arecallingthempatternstheyhaveclassifiedsomeofthemasanti-patterns.

Table2.4.CulturalPatternsinSoftwareProcessMishaps(MacGregoretal.2005).

No. PatternName Assumption PatternOverview

1. Yes(butNo) PersonAhasassumed

PersonBmeant“YesIwill

doit,whenPersonB

meantIheardwhatyou

said.”

- PersonBperceivedPerson

Atobehigherin

hierarchy.

- Bdoesn’twanttoaffect

thedeadline.

- Makeclarificationand

rephraserequest.

2. ProxyPattern Companiesarenotwilling

toinvestinintercultural

training

- Placebi-codedindividuals

inapositionwherethey

cantranslatebetweenthe

cultures.

3. We’ll-take-you-

literally(Anti-

Pattern)

Differentculturesmay

havedifferentperceptions

foradevelopment

practice,processor

- Resultingininefficient,

frustrationanddistress

amongdifferentcultural

teams.

43

artefact.

4. We’re-one-single-

team

Agileencourages“flat

team”howeverinsome

culturestheyfollowa

morehierarchical

approachdependingon

powerdistance

- Formalcommunication

withpeopleonhigher

hierarchylevel.

- Developersdon’tfeelthey

havearighttotake

decisionsregardingthe

systemtheyare

developing.

5. The-customer-is-

king(Anti-Pattern)

Lesshierarchydominant

structureencourageopen

anddirectcommunication

betweentheclientand

developers.Whilehigh

hierarchyorganisation

preferindirect

communicationbetween

theclientanddevelopers.

- Whenproblemarises,

developersfromhigh

hierarchyorganisation,

thedeveloperscannot

contacttheclientdirectly

hencecausingdelayin

developmenttime.

- Similarlytheclientmight

feelthatthe

communicationislimited.

- Asnatureofsocialculture

alsoaffectsthe

relationshipbetweenthe

developersandclientsuch

aswhereitiswork-

orientedorrelationship

oriented.

44

Fromtheaboveexamples,wecanseethatsocio-culturalconflictscancauseproblems

in the development of an offshore project. In order to solve such conflicts, the

organisationsneedtocreateanenvironmentthatencouragesteamstocommunicate

witheachother.Theyneedtocontinuouslyadaptteamrolesbasedonthechanging

relationship between the teammembers. This can reducedissatisfaction among the

employeesandincreasetrustresultingingivingeachothermoreresponsibilities,thus

improvingthequalityofsoftware.

2.3.3 CommunicationandCoordinationIssues

In offshore development as the team is separated and implemented at different

geographical locations they face many communication and coordination issues

because the team members work on different time zones or time shifts in a day

(Alzoubietal., 2016). This reduces theopportunity for real-timecommunication (Al-

Zaidietal.,2017).Thebasicissueinoffshoringishandlingthecomplexcommunication

and team coordination, as they can’t have frequent face-to-face communication

(Sahayetal.,2003).Insufficientteamcommunicationoftencreateschallengessuchas

trust,relationshipsandefficiencyoftheteam(Lanubileetal.,2013).

AresearchdonebyEbertshowsthatapproximatelyhalfofallthedistributedprojects

fail due to insufficient communication and trust among the team members (Ebert,

2012). In order to increase communication among the teammembers, awareness is

necessary. Awareness in distributed teams helps in ensuring that individual

contributions,contributetothewholegroup’sefforttodevelopsoftwaresuccessfully.

PaulDourishandVictoriaBellottidescribedgroupawarenessas“anunderstandingof

the activities of others, which provides a context for your activity” (Dourish et al.,

1992).

Groupawarenesscanhelpovercomesomechallengesofoffshoreprojects(Lanubileet

al.,2013).Therearefourtypesofgroupawareness,whichare(Gutwinetal.,1996):

45

• Informal awareness provides information about which team members are

aroundandavailableforwork.

• Group-structuralawarenessfocusesontheknowledgerolesonteammembers

andstructureoftheteam.

• Workspace awareness gives information about the interactions the team

membershavewithsharedresourcesataworkspace.

• Social awareness consistsof information that teammembersmaintainabout

each other in conversational context for the purpose of social connections

withintheteam.

In order to achieve group awareness in distributed teams, technology plays an

important role. In the survey conducted by Lanubile focused onwhich technologies

andtoolssupportgroupawarenessandcollaborationsuchasforinformalawareness,

IM (Instant Message) and VoIP (Voice over Internet Protocol) tools can be used

similarlyforworkspaceawarenessemailsandRSScanbeused(Lanubileetal.,2013).

Another way to increase the communication between the teams is to keep the

workinghoursflexiblesothattheonshoreandoffshoreteamscanachieveoverlapping

hours with each other. For example in order to get real-time communication,

occasionallyoneteamhastostaylateandtheotherteamhastocomeearlytohavea

combinedmeetingviavideo/audioconferencingtools(Yuetal.,2016).Henceinorder

to organise work between geographically distributed teams we must consider

temporaldistancetofacilitatethereal-timecommunication(Holmstrometal.,2006).

Temporaldistance isameasureof thedislocation intimeexperiencedbytwoactors

whowishtointeract(Pilattietal.,2006).

Asynchronous tools are seen as a crucial part for communication and coordination

amongremotelocations.Duetotemporaldistancetheincreaseintheresponsetime

46

createsafeelingof“beingbehind”aswhenonelocationsendsarequesttheygetreply

thenextday.Asseen inthecasestudydonebyBolandandFitzgeraldasynchronous

communicationovernightcanbeoverwhelmingforadeveloperbeginningworkinthe

morning (Boland et al., 2004). Also a study done by Holmstrom shows that limited

overlapwithcollegescausesdelay inresponsewhichmakespeople losetrackof the

overall work process which leads to problems in distributed yet time-crucial work

(Holmstrom et al., 2006). Similar results were noted by Herbsleb, the drag in the

problemand response could cause increase in the cost (Herbsleb,2007).Asa result

response time increases when working hours do not overlap between the remote

locations(Sarkeretal.,2004).

2.3.4 KnowledgeTransferIssues

Knowledge is a very common and widely used concept. In order to clarify what is

referredasknowledgewehaveusedthedefinitionprovidedbyDavenportandPrusak

(Davenportetal.,1998).Theydefinedknowledgeas“Afluidmixofframedexperience,

values, contextual information, and expert insight that provides a framework for

evaluating and incorporating new experiences and information. It originates and is

applied in theminds of knowers. In organisations, it often becomes embedded not

only in documents or repositories but also in organisational routines, processes,

practices,andnorms.”(Davenportetal.,1998)

Using the above-mentioned definition of knowledge, as companies started moving

their business and development process to offshore locations, knowledge transfer

became critical (Zahedi et al., 2016).A studydonebyAccenture shows thatpeople,

patentandknowledgecomprisefor70%ofExchange-listedcompaniesvaluewhereas

in1980itwasjust20%(Aronsson,2007).Thisshowshowimportantknowledgeisfor

companiesandanymistakeduringaknowledgetransfercancauseanegativeaffecton

thecompanies.Inoffshoringtheprocessofknowledgetransferisnotstraightforward

as when transferring knowledge from one country to another the factor of cultural

differencescauseschallenges(Kediaetal.,2007).Culturedoesnotautomaticallyaffect

47

theknowledgetransferprocessbutifthereispoormanagementitcancauseprojects

tofail(Javidanetal.,2005).SimilarlyinastudydonebyRadoff’sshowsthatifwedo

notunderstandtheculturaldifferencesbetweenthecountriesitcancauseanegative

impact on outsourcing (Radoff, 2006). As we need to understand the cultural

differences inorder to successfullymanage theprojects. The report also shows that

thecompaniesthateducatetheiremployeesof interculturalcommunicationincrease

theirproductivityby30%.

Onemajorchallengeorganisationsface,whichdirectlyaffectstheknowledgetransfer

process, is when they decide to offshore their process before they have tested the

readiness of their management. This includes the difficulties of keeping awareness,

andknowledgecohesionwhenvariousworkinggroupsconcurrentlyaccessit(Khanet

al., 2014). These difficulties directly affect how work is distributed through task

allocation in distributed environment. According to Sajjad the factors presented in

table2.5shouldbeconsideredwhileallocatingtaskswhentheteamisdistributedto

overcometheknowledgetransferchallenges(Sajjadetal.,2015).

Table2.5.FactorsAffectingTaskAllocationProcessinOffshoreDevelopment(Sajjad

etal.2015).

No. Factors Percentage AffectofFactoronTaskAllocationProcessin

OffshoreDevelopment

1. SiteTechnical

Expertise

68% Selectsitewithappropriatedomainexpertiseand

knowledgeiscrucial.

2. TimeZone

Different

63% Allocation of tasks should be based on the time

zone.Therearetwocommonapproachesusedby

practitionerswhileconsideringthetimezone,they

eitherallocate tasksbasedonTime-ZoneBandor

Follow-the-Sun.Theselectionismadeconsidering

the fact that it shouldallow thedifferent sites to

be able to have synchronous communication to

48

allowknowledgesharing.

3. Resource

Cost

47% ProjectManagers do aim to assignwork units to

low cost labour sites in order to cut down on

developmentcost.

4. Task

Dependency

44% Keeping the cost benefit in mind, it is however

advised to not only consider the cost while

assigning the tasks but to also consider task

dependencies. As high task dependent tasks

shouldbe assigned to the same location inorder

tosavetimeoncommunicationandcoordination.

5. Vendor

Reliability

36% The perceived reliability of a particular vendor

helps clients to bettermanage tasks allocation in

globalsoftwaredevelopment.

6. TaskSize 29% Tasksizehasalsobeenconsideredimportantasit

helps in deciding how much time the team will

spendtodevelopit.

7. Vendor

Maturity

Level

21%

Itisimportanttoconsiderthematuritylevelofthe

vendor as, if they are new to offshore

development, they may face issues in code

integration.

8. Local

Government

Regulations

13% This factor isn't directly related to the software

development process, however it has been

perceivedasanimportantfactortobeconsidered

whiletaskallocation.

49

9. Requirements

Stability

7% Based on the type of project, requirements

stability is important in order to break them into

tasksfortheteamtodevelop.Howeverithasonly

beenconsideredtobean important factorby7%

based on the selected literature of this research,

as it is a universal fact that requirements do

change and organisations have placed

requirementchangemanagementmodelsinplace

tohandlethisissue.

10. Product

Architecture

7% Since the requirements keep changing, the

product architecture keeps evolving throughout

thesoftwaredevelopmentlifecycle.Thishasbeen

consideredasanimportantfactorby7%basedon

thearticlesselectedfromliterature.

11. Intellectual

Property

Ownership

2% In distributed software development, as code is

being developed at different locations, it is

important to consider the issue of intellectual

property however this factor isn't considered

critical for task allocation as the client is usually

the onewho has the intellectual property of the

codebeingdeveloped.

Thecommonproblemsbetweenwiththecompanythatistransferringknowledgeand

the company that is receiving the knowledge are: i) communication problem, ii)

differentwaystoconductwork,iii)differentworkattitudes,andiv)differentdecision-

makingprocess(Radoff,2006).

50

2.4 CriticalAnalysisofOffshoreChallengesonSoftwareDevelopmentPhase

Inthissectionwewilldiscusshowtheabove,identifiedchallengesaffectthedifferent

phasesofsoftwaredevelopmentandpresentacriticalanalysis.

The traditional software development lifecycle consists of five stages, which are,

Requirements, Design, Coding, Testing and Integration. Figure 2.3 below shows the

softwaredevelopmentlifecycle.

Figure2.3.TraditionalSoftwareDevelopmentLifecycle.

Theexecutionofthesephasesdependsonwhicheversoftwaredevelopmentapproach

thedevelopmentteamdecidestoselected.Anoverviewoftheexistingapproachesis

presented in theAppendix B showing how these phases are executed based on the

selectedapproach.

Based on the literature review, we present in Table 2.6 how each phase of the

traditional software development lifecycle is affectedwhen organisations choose to

move their projectsoffshore. Wehavemapped the four key challengesof offshore

developmentoneachlifecyclephasetoshowhowtheseoffshorechallengeseffectthe

executionofeachphase.

51

Table2.6.OffshoreChallengesAffectingSoftwareDevelopmentPhases.

No. Phase Offshore

Challenge

EffectofOffshoreChallengeonSoftware

DevelopmentPhase

1. Requirements Trust • Establishing correct estimates of

requirements is difficult, as onshore

team does not have clear

understanding of offshore team skills

(Alnuemetal.,2012).

• Getting the main objective and core

functional requirementsof theproject

clear toall the teammembers located

atdifferentsitesisdifficult(Herbslebet

al.,2001).

Socio-Cultural • Differences in cultural values and

language can cause misunderstanding

ofrequirements(Damianetal.,2003).

• As at the beginning of the project the

clientisn'tsureofalltherequirements,

which can result in vague

requirements, which need to be later

clarified to the teams who aren’t on-

site(Birdetal.,2009).

• Difference in ways to express

dissatisfaction, perception regarding

punctuality, scheduling, hierarch,

52

urgency or risk often leads to

misunderstanding among the client

andteammembershencespoiling the

relationship (Damianet al., 2003;Niaz

etal.,2012;Bhatetal.,2006).

Communication

andCoordination

• Changesintherequirements,needsto

becommunicatedtoallthedistributed

teams. Any mistake in recording the

change can cause problems in the

development of the system (Sengupta

etal.,2006).

Knowledge

Transfer

• As the project is being developed at

different locations, there can be

inconsistencies in the work done and

documented user stories (Bhat et al.,

2006).

• Maintainingbidirectionaltraceabilityof

requirements across different sites is

difficult as each site is working on

different requirements (Berenbach et

al.,2006).

• Managing requirements, on-site

customer and daily meetings become

difficultwithdistributedteams(Bhatet

al.,2006).

53

2. Design Trust • Lack of standard method that can

proactivity verify organisation

structure can createmistrust between

the client and the team (Herbsleb,

2007).

Socio-Cultural • It is difficult to communicate

architecture design decisions to

geographicallyandculturallydispersed

teams(Clerc,2008).

• Synchronous meetings of architecture

and developers are difficult, which

impinge building of common

understanding of architecture and

developers(Boschetal.,2010)

Communication

andCoordination

• Coordination problems occur due to

lack of common understanding of

architecture design (Jaakkola et al.,

2010).

• Itisdifficulttodiscoverthecorrelation

betweenarchitecturedecisionandthe

coordination requirements they will

enforce(Herbsleb,2007).

Knowledge

Transfer

• Non-textual artefacts make it difficult

to highlight and manage change

(Sengupta,etal.,2006).

54

• Lack of documents that describe the

overall architecture of the software

under development (Ovaska et al.,

2003).

• Out-dated documentation leads to

rework(Cataldo,etal.,2007).

3. Coding Trust

Socio-Cultural

• Insufficient social integration can

degrade the performance, lower

motivation and satisfaction of the

developer. Resulting in creating

mistrust between the client and the

development team (Koehne et al.,

2012).

• Duetoculturaldifferences,developers

often misinterpretation each other,

causing wrong requirements to be

coded(Herbslebetal.,2005).

• Misinterpretations of technical

vocabulary due to dissimilarity in

technical cultures causes

misunderstanding, rework and

consequently delays in the projects

(Herbslebetal.,2005).

• Developersatremotesites,insufficient

use version control systems due to

different organisational cultural habits

55

(Cataldoetal.,2007).

• Developers belonging to higher

economycountriesusuallydonothelp

people belonging to low economy

countries infearof losingtheir jobsto

them(Birdetal.,2009).

Communication

andCoordination

• Usage of different process and

disparity in process maturity at

different sites can cause coordination

problems(Birdetal.,2009;Herbslebet

al.,2005).

• Staff members at new offshore sites

haveatendencytonotreplyquicklyto

emails of onshoremembers (Herbsleb

etal.,2005).

• Communicating all the details and

normsoftheprocesstobefollowedto

remote teams is very time consuming

(Mullick,etal.,2006).

Knowledge

Transfer

• Difficulties in tracking information in

distributed development (Herbsleb et

al.,2005;Koehneetal.,2012).

• Divergence in tool usage among

different teams causes knowledge

transferproblems(Birdetal.,2009).

56

4. Testing Trust • Customers feel insecure to trust their

real-life data with offshore

organisations, as they haven’t worked

withthembefore,hencetheygenerate

mock databases for the purpose of

testing(Senguptaetal.,2006).

• In acceptance testing, as feedback is

being provided indirectly, vital

information can be lost, causing the

client to not trust the development

team(Liskin,etal.,2012).

Socio-Cultural • Offshore testers don’t get sufficient

cooperation from the onshore

members due to misunderstanding

(Tervonenetal.,2013).

• Communicationisdifficultbetweenthe

onshore testers and offshore testers

due to the absence of a common

native language and different

vocabulary(Camachoetal.,2013).

Communication

andCoordination

• Face-to-facemeetingsaredifficultand

expensive causing communication and

coordination gaps among the team

members(Tervonenetal.,2009).

• Reduced awareness of work due to

lack of informal contact and

57

geographical dispersion (Tervonen et

al.,2013).

• Limited budget restricts

communication, coordination and

collaborationmechanism (Tervonenet

al.,2013).

Knowledge

Transfer

• It is hard to spot a developer of the

codewhereabug is found (Grechanik

etal.,2010).

• Testers in the development countries

arenotfamiliarwiththeclientstesting

tools and code, which is to be tested

(Liskin,etal.,2012).

• Due to frequent misinterpretations of

requirements and interface

specification confusions and

misunderstanding occur, which cause

inconsistence, which are not exposed

until integration testing (Sengupta et

al.,2006).

5. Integration Trust • Inadequate and incomplete interface

specificationsareidentifiedonlyatthe

integration phase, which cause

mistrust among the client and

development team (Sengupta et al.,

2006).

58

Socio-Cultural • It isdifficult toresolvedifficultieswith

unfamiliar remote participants while

integrating the code (Conchúir et al.,

2006).

• Due to lack of cohesiveness and

cooperation between the different

locations,theoffshoreteamfeelsthey

are integrating components of

competitors(Herbsleb,etal.,2005).

Communication

andCoordination

• Inadequatecommunicationandlackof

domain knowledge lead to lack of

understanding in developers about

requirements, which often lead to

misinterpretedandconflictingmodules

(Damianetal.,2003;Bhat,etal.,2006;

Senguptaetal.,2006).

• Communication between remote site

only through a single mediator can

because the cause of integration

failure(Čavraketal.,2012).

Knowledge

Transfer

• Implementing different code branches

at each development site can lead to

complex integration problems

(Herbsleb,etal.,2005).

• Inadequateknowledgeandexpertisein

GSD of integration team can increase

59

risks of integration failure (Kommeren

etal.,2007).

• Risk of integration failure increases

withtheincreaseininterdependencies

between modules to be developed

(Herbsleb,2007).

Basedontheabovetablewecanseehoweachphaseofthedevelopmentlifecycleis

effectedbyoffshorechallenges.Fromthesefindingswecanobservehowtheoffshore

challengesare interlinkedandunderstandhowthesechallengesare interrelatedand

affect the development lifecycle such as we can now say that trust, socio-cultural,

communicationandcoordinationandknowledgetransfer issueseffectall thephases

ofthedevelopmentlifecycle.

To overcome the challenges mentioned in Table 2.6, work has been done using

differentapproachessuchaspatterns,ontology-basedandagilemethodology. Table

2.7givesanoverviewofsuchapproaches.

Table2.7.OverviewofExistingApproachesusedtoOvercomeOffshoreChallenges.

No. Approach OverviewoftheApproach

1. UseofPatternsfor

GlobalSoftware

Development

MacGregor(MacGregoretal.,2005),Shah(Shahetal.,

2012), Paasivaara (Paasivaara et al., 2003), Bricout

(Bricout, 2004), Lescher (Lescher, 2010), van Heesch

(van Heesch, 2015), Valimaki (Valimaki et al., 2009),

Pehmöller (Pehmöller et al., 2010) and Salger (Salger

et al., 2010) provided patterns to be used in Global

Software Development. Details of their patterns can

befoundinSection2.7.

2. UsingAgilePracticesto Beecham proposed to use agile practices to solve

60

SolveGlobalSoftware

DevelopmentProblems

global software development problems (Beecham et

al., 2014). The aim of their researchwas to answer

theresearchquestion:

• WhatGSDproblemscanagilemethodssolve?

They interviewed24practitioners fromFS groupand

fromthattheypresented16issuesthatwereraisedby

the practitioners while they developed software

offshore.Theyanswered9issuesusingagilepractices

and partially answered 3 and left 4 unanswered.

DetailoftheirsolutioncanbeseeninAppendixC.

3. Ontology-BasedMulti-

AgentSystemto

SupportRequirements

TraceabilityinMulti-

SiteSoftware

Development

Environment

Pakdeetrakulwong proposed an ontology-based

solution using multi-agents to collect requirements

when the project is being developed is offshore

(Pakdeetrakulwong et al., 2015). Their proposed

architecturehadfouragents:

i) UserAgent

ii) RecommenderAgent

iii) OntologyAgent

iv) EvolutionAgent

Themaincapabilitiesoftheseagentsareto:

• Handle change in the requirements

(add/update/deleted).

• Identify requirements traceability information

andgeneratetraceabilitymatrix.

• Analyse change impact on requirements and

61

softwareartefacts.

• Sendmessagetonotifyrelevantuseraboutthe

impactofrequirementchange;and

• Recommend incomplete requirement

information.

4. Experimentsfor

offshoreprojectto

addresscentrifugal

forces.

Based on Carmel’s identified five centrifugal forces

thatpullpeople,teamandproductgroupapartwhich

areasfollows(Carmel,2010):

• Geographicaldispersion

• Coordinationbreakdown

• Lossofcommunicationrichness

• Lossofteam-ness

• CulturalDifferences

CragLarmanandBasVoddedesignedexperimentsto

be conducted by offshore teams in order to address

these issues (Larman et. al., 2010). An overview of

theirexperimentsislistedbelow:

• Try..Fewersites

• Try..Think“multisite”evenwhenclose.

• Avoid..Believinginmulti-sitedailyscrummagic

orthatmultisiteforcesareinconsequential.

• Avoid.. Thinking distributed must mean

dispersed.

• Try..Oneiteration(Sprint)fortheproduct,not

forsite.

Similarly they designed experiments related to team

62

and site structures, interaction and coordination,

multisitecultureandnorms,tool,andtests.

5. Understanding

CollaborativePractices

inDistributedAgile

Developmentusing

TheoreticalConcepts

Modi presented a research proposal in which they

usedaninterpretativequalitativeapproachalongside

case studies, to gain deeper understanding into how

teams collaborated in distributed agile development

scenario(Modietal.,2013).Thereanalysiswasbased

on theoretical concepts such as common ground,

boundary objects and awareness,. The aim of their

research was to answer the following research

questions:

• How do global teams collaborate to establish

commonground/sharedunderstanding?

• Howdoesknowledgesharingtakeplace?

• Whattransformationtakesplace?

• What can we learn from existing distributed

agileteams?

Based on their selected theoretical concepts they

explainedonhowtheycanhelpdistributed teams to

solve the collaboration challenges. Below we have

defined each concept and given an overview of how

they can help improve collaboration in distributed

scenario:

• Common Ground: According to Clark theory of

common ground regarding mutual knowledge,

beliefs and assumptions maintain that the

participants must have a shared awareness to

63

carry out a joint activity (Clark et al., 1991).

According toModi’s research failure to establish

and maintain a common ground can result in

serious breakdowns in collaborative work (Modi

etal.,2013).

• BoundaryObjects:Stardefinedboundaryobjects

as objects, which are both plastic enough to

adapt to local needs and constraints of the

several parties employing them, yet robust

enoughtomaintainacommonidentifyacrosssite

(Staretal., 1989). BasedonModi’s research, in

GSDtheprojectartefactssuchasuserstories,the

sharedcodeandtestcasesaretheintegralpartof

agile and canbe viewedasboundaryobjects in-

use, as they provide a common focus to the

project goals and act as mediators for

communication, coordination and cooperation

among the team members distributed over

differentsites(Modietal.,2013).

• Awareness isdefinedasanunderstandingof the

activities of others, which provide a context for

the project activates. According to Modi’s

research the 3C collaboration model, defines

collaboration as the union of communication,

coordinationandcooperationefforts(Modietal.,

2013).

In Table 2.7 we presented different approaches that are being used to overcome

offshorechallengeshowevertheyhavelimitationsforexampleusingagilepracticesto

solve global software development problems has limitation that even though this

64

approachanswersGSDchallenges itdoesnotdiscuss indetailhowpractitioners can

solve themas theyonlypresented single line solutions similarlyusingontologies for

requirementsapproachonlyfocusesonovercomingthechallengesoftherequirement

phasebyusingontologiesanditprovidesaverytechnicalsolutionwhichisdifficultto

beusedbyproductownersthataren’tfromITbackground.Furtherwehavediscussed

theseapproachesintable5.8.

2.5 AgileOffshoreSoftwareDevelopment

In this section we will first explain what agile is and then how we can use agile

methodologiesforoffshoresoftwaredevelopment.Wehavealsomentionedwhatare

thelimitationsofagilewhenusedforoffshoring.

2.5.1 AgileSoftwareDevelopment

In2001theformationofagilemanifestohasbroughtunprecedentedchangestohow

softwareisdeveloped(Becketal.2001).Themanifestofocusesonfourpointswhich

are: i) individuals and interaction over process and tools ii) working software over

comprehensive documentation iii) customer collaboration over contract negotiation

andiv)respondingtochangeoverfollowingaplan.Broadlyspeakingagileencourages

collaborativedevelopmentinwhichpeopleareinvolvedthroughoutthedevelopment

processallowingthemtoopenlyexchangewhichhelpsbridgethegapbetweenclients

anddevelopersresultinginasuccessfulproduct.

Agilesoftwaredevelopmentfocuseson12principleswhichareasfollowing(Becket

al.,2001):

• “Customersatisfactionbyrapiddeliveryofusefulsoftware

• Welcomechangingrequirements,evenlateindevelopment

• Workingsoftwareisdeliveredfrequently(weeksratherthanmonths)

• Workingsoftwareistheprincipalmeasureofprogress

• Sustainabledevelopment,abletomaintainaconstantpace

65

• Close,dailycooperationbetweenbusinesspeopleanddevelopers

• Face-to-faceconversationisthebestformofcommunication(co-location)

• Projectsarebuiltaroundmotivatedindividuals,whoshouldbetrusted

• Continuousattentiontotechnicalexcellenceandgooddesign

• Simplicity—theartofmaximizingtheamountofworknotdone—isessential

• Self-organizingteams

• Regularadaptationtochangingcircumstances”.

Agilesoftwaredevelopmentisaniterativeandincrementaldevelopmentmodelwere

the requirement of the project and its solution keeps on changing based on the

collaborationandcoordinationofself-organisedandcross-functional teams (Larman,

2004).AgiledevelopmentlifecyclehasmanymethodologiessuchasAgileModelling,

Agile Unified Processes, Crystal Methods, Dynamic System Development Method

(DSDM), Extreme Programming (XP), Scrum and Lean etc. (Dybå et al., 2008). In

generalagilemethodologiesemphasizeson frequentdeliveryofproduct increments,

time boxes, communication and collaboration, working software as a measure of

progress,adaptiveplanningandmeetings.

Alotofworkisbeingdoneonagileanditisbeingwidelyadaptedbymanycompanies

todevelopsoftware(Abrahamssonetal.,2003).AliteraturesearchintheISIWebof

Science showed that 1551 research papers have been published on agile software

developmentfrom2001till2010(Dingsøyretal.,2012).

2.5.2 AgileMethodologyinOffshoring

Companiesthatoptforoffshoringperceiveitastheyaretakingriskinsomeaspectsof

the software development process in order to reduce cost of software production

(Nisar et al., 2004). As there is tension between agile benefits and difficulties of

implementingagile.Agilemethodshelpbuildtrustandconfidencebetweenclientsas

it considers customers as part of the team. It also helps in reducing the risk of

production of low quality software as by using agile methods like unit testing, pair

66

programming, continuous integration etc. ensures good quality software (Danait,

2005). However the process of adopting agility with distributed projects is not

straightforward(Šmiteetal.,2010).Globalsoftwareengineeringshouldfocusonhow

to cleverly use information and communication technology to compensate for the

inherentproblemsofdistributedworksandbridgetheremotesitestogether(Hanssen,

2011).

Inindustrytherearetwodifferentopinionswhenitcomestoagile:

• Some companies believe that agile methods are a best fit for offshore

development as offshore projects involve high risks of security, decreased

development visibility, management and integration. Thus with the help of

agile methods such projects can be better planned and executed (Simons,

2002,Hayes,2003,Massol,2004).

• SomebelievethatAgilemethodsareamismatchwithoffshoring(Kontioetal.,

2004). Taylor claim that projects that use agile for offshore development go

throughalotofdifficultiesbecauseofthedifferencesindevelopmentpractices

aswell as due to complex development environment (Taylor et al., 2006). A

characteristic comparison done by Šmite shows how agile development is

different fromoffshore development shown in Table 2.8 below (Šmite et al.,

2010):

Table2.8.ComparisonofAgileDevelopmentversesOffshoreDevelopment(Šmiteet

al.2010).

No. Characteristics AgileDevelopment Offshore

Development

1. Communication Informal

Face-to-face

Synchronous

Many-toMany

Formal

Computer-mediated

OftenSynchronous

Tunnelled

67

2. Coordination Change-driven

Mutualadjustment,self

management

Plan-driven

Standardisation

3. Control Lightweight

Cross-functionalteam

Command-and-

control

Clearseparationof

roles

2.6AgileAdoptioninOffshoreSoftwareDevelopment

In this sectionwewill highlight approaches used by organisation to transition from

traditional software development to agile methodology, we also present different

approachesusedtoadoptagileinoffshoreenvironment.

2.6.1TransitionfromTraditionalSoftwareDevelopmenttoAdoptingAgile

Practices

In this section we have focused on approaches present in literature that focus on

facilitatingorganisationstotransit fromanytraditionalsoftwaredevelopmentmodel

toadoptingagilepractices.Wehaven’tconsideredthecomplexityaddedbyoffshore

softwaredevelopment.

2.6.1.1 FacilitatorstoAssistAgileAdoption

Javdaniconductedastudyconsistingof33agileexpertsacross13differentcountries

to identify facilitators that would help organization to transition and adopt of agile

methods (Javdani et al., 2014). They identified 8 facilitators that would help agile

practitionerstodotheirjob,whichareasfollows:

• Training

• Goodcoachingandmentoring

• Managementbuy-in

68

• Teammemberbuy-in

• Rightpeopleselectionandempoweringteam

• Continuousmeetingandnegotiation

• Agilechampions

• Incentivefactors

Based on their results it is clear that for the success of agile adoption, the team

membersandmanagementneedtohavecommoninterest.Howeverthelimitationof

thisresearchisthatitonlyfocusesonco-locatedteammembersanddoesnotdiscuss

thecomplexityaddedduetooffshoreteams.

2.6.1.2 FrameworktoSupporttheEvaluation,AdoptionandImprovementofAgile

Methods

Qumer also suggested a framework to support the evaluation, adoption and

improvement of agile methods (Qumer et al., 2008). In their framework they

developed an Agile Toolkit, which facilitated the construction and evaluation of

processes in complex software projects. Figure 2.4 shows themain components’ of

their agile software solution framework, which are Agile Toolkit, Method Core and

SoftwareTechnology.

Figure2.4.TheMainComponentsoftheAgileSoftwareSolutionFramework(Qumer

etal.2008).

69

They also developed an analytical tool that evaluated the degree of agility in a

developmentpractice.TheyalsodesignedanAgileAdoptionandImprovementModel

(AAIM)basedonindustryanalysisandagroundedtheoryresearchmethodology.The

AAIMhas3agileblocks:i)AgileBlock:Prompt,ii)AgileBlock:Cruxandiii)AgileBlock:

ApexwhicharefurtherdividedintosixstagesasshownintheFigure2.5below.This

model focuses more on how to evaluate the degree of agility adopted in an

organisationratherthenprovidingaguidelineonhowagileshouldbeadoptedandit

doesn’tnotexplainhowagileshouldbeadoptedinoffshoresoftwaredevelopment.

Figure2.5.AgileAdoptionandImprovementModel(Qumeretal.,2007)

2.6.1.3 SharedMentalModelstoUnderstandAgilePractices

Yuuseda theory fromcognitivepsychologyknownassharedmentalmodels tohelp

practitionersunderstandandapplyagilepractices,asaccordingtoempiricalresearch

70

itwas found that theperceivedbenefitsofagile softwaredevelopmentarenot fully

understoodinresearchorbyorganisations(Yuetal.,2014).Hencecausingtofailures

in achieving the required results. There research emphases on answering three

researchquestions:

i) Why is improved interaction needed among development teams and

customers?

ii) Whataspectsof interactions shouldbeemphasisedamong thedevelopment

teamandcustomers?

iii) How does increased interaction improve collaboration during software

development?

TheyfocusedonthreeScrumandXPpractices,whichwereSystemmetaphor,Standup

meetingsandon-sitecustomerandlinkedthemtothetypesofsharedmentalmodel

that would facilitate understanding and adoption of agile practices. For example,

according to their research, standup meetings using shared mental model practice

reflexivity can enhance developers understanding of the project. Similarly that with

efficientreflectivediscussesduringthestandupmeeting,theteamunderstandabout

theprojectgoals,challenges,limitationsandsystemrequirements.

2.6.2AgileAdoptioninOffshoring

Inthissectionwehavepresenteddifferentapproachespresentinliteraturethatare

usedtoadoptagilepracticesinoffshoresoftwaredevelopment.

2.6.2.1UseofPatternsinAgileAdoption

AsmentionedinSection2.4workhasbeendoneonusingpatternsinglobalsoftware

development. In this sectionwewill give anoverviewofwhat is a pattern andhow

they can be used to facilitate agile adoption in offshore software development.We

further conducted a study on identifying existing patterns used in GSD and then

investigating specific patterns that are being used for agile adoption, which is

presentedinSection2.7.

71

The term ‘pattern’ was introduced in software development as an inspiration of

Christopher Alexanderwork on architectural patterns. He defined patterns as “Each

patterndescribesaproblemwhichoccursoverandoveragaininourenvironment,and

thendescribesthecoreofthesolutiontothatproblem,insuchawaythatyoucanuse

this solution a million times over, without ever doing it the same way twice”

(Alexander et al. 1977). He used this definition for buildings and town patterns

howeverwhathesaysaretrueforsoftwarepatternsaswell.

Generallyapatternhasfouressentialelements(Gamma,etal.,1997):

• Thepattername:togiveahighlevelofabstracttothepattern.Itgivesusthe

ideaofwhatproblemthepatternisprovidingasolutionforinawordortwo.

Givinganametoapatternmakesiteasyforustotalkaboutitwithpeopleand

fordocumentation.

• Theproblem:helpsindescribingwhenthepatterncanbeapplied.Itprovides

details of the problem and its context. It may include lists of conditions or

scenarios,whichmustbemetinordertoapplythepattern.

• The solution: describes the elements that makeup the patterns, their

relationships and responsibilities. The solution doesn’t describe a particular

concretepracticeorimplementation,becauseapatternislikeatemplatethat

canbeappliedinmanydifferentscenarios.Apatterndoesprovideanabstract

descriptionofaproblemandhowageneralarrangementofelements/practices

cansolveit.

• The consequence: describes the outcome of applying the pattern. They are

criticalforevaluatingapatternandforunderstandingthebenefitofapplyinga

patterntoseeifithelpedinsolvingtheproblemandifyes,uptowhatextend.

Forsoftwaretheconsequenceoftenrefertospaceandtimetrade-offs.

72

Currentlytherearesixtypesofpatterns:

- Requirements Patterns: Robertson defined requirement patterns as

patterns that provide high-level abstraction of system requirements

(Robertson, 1996). They help in the creation of better and precise

requirementdescriptionsinlessertime.

- Anaylsis Patterns: Fowler defined analysis patterns as patterns that

“reflects conceptual structures of business processes rather than actual

softwareimplementations"(Fowler,1997).

- Design Patterns: Gamma defined as “descriptions of communicating

objectsandclassesthatarecustomizedtosolveageneraldesignproblem

inaparticularcontext(Gamma,etal.,1997).

- Architectural Patterns: Buschmann defined architecture patterns as

patterns that contain best practices for decomposing a software system

into sub-systems (Buschmann et al., 1996). They also specify the

responsibilitiesbetweenthesub-systemsthat includerulesandguidelines

fororganizingtherelationshipsbetweenthem.

- Anti-Patterns:Browndefinedanti-patternsasthosepatternsthatdescribe

negativeexamplesofsolutions(Brownetal.,1998).Theydescriberepeated

negative practices observed while solving a problem and provide better

solutions.

- Idioms: They are patterns of the lowest level of abstraction. They show

commonprogrammingtechniquesandconventionsthatrecurwhilesolving

programmingtasks.Theyareoftenlanguage-specific.

73

Workhasalsobeendoneonidentifyingoffshoresoftwaredevelopmentpatternsand

agile patterns in offshore development. MacGregor and Shah designed cultural

patterns to manage the cultural difference challenges in offshore development

(MacGregor et al., 2005; Shah et al., 2012). Paasivaara, Bricout, Lescher and van

Heesch designed communication and coordination patterns to overcome

communicationandcoordinationchallengesthatonshoreandoffshoreteammembers

facewhileworkingtogether(Paasivaaraetal.,2003;Bricout,2004;Lescher,2010;van

Heesch, 2015). Valimaki designed patterns for projectmanagement (Valimaki et al.,

2009)andPehmöllerdesignedtestingpatterns(Pehmölleretal.,2010).Salgerworked

ondesigningpatterns for the requirementsengineeringprocess (Salgeretal.,2010).

OverviewofthesepatternsispresentedinTable2.12.

Similarlyworkhasbeendoneonidentifyingagileoffshorepatterns.Hvatumdesigned

magicbacklogpatternstomanagethebacklogwhentheprojectisbeingdevelopedat

multiplesites(Hvatumetal.,2015).Fowlerdesigneddaily-standuppatterns(Fowler,

2016)andVälimäkidesignedninedistributedprojectmanagementandscrumpatterns

(Välimäki et al., 2008). Cordeiro designedmulti-site software development patterns

(Cordeiro et al., 2007) and Elssamadisy focused on the dynamics of agile adoption

(Elssamadisy et al., 2006). Overview of these patterns has been presented in Table.

2.13

2.6.2.2 FactorsContributingtotheSuccessandFailureofAgileAdoption

Malik identified factors that contributed to the success and failure of agile offshore

softwaredevelopment,whichareasfollows(Maliketal.,2010):

• DevelopmentStrategy

• ProjectType

• CommunicationChannel

• CulturalDifference

• SplitLocation

74

• SizeofProject

According to their research, coding and testing phases should be considered to be

offshored and that critical modules such as project planning and design should be

done on onshore location. The type of projects that havemost success in offshore

developmentarewebsitesandwebapplications.Figure2.6showstheresultoftheir

researchonfindingwhatprojecttypeissuitableforoffshoredevelopment.

Figure2.6.SoftwareProjectSuccessRateforOffshoreProjects(Maliketal.,2010).

2.6.2.3 UseofToolsinAgileAdoptioninOffshoreDevelopment

AsmentionedinSection2.3.3,themainissuewithoffshoringiscommunicationgapas

agile is a bigmismatch as itsmethods focus on regular face-to-face communication

henceincreasingthedemandforcommunication(Becketal.,2001).Analternativeto

this approach is that agile methods solve communication problem by “Offshore

Development requires more communication, Agile methods provides more

communication”(Nisaretal.,2004).

75

Nowthequestionishowtoapplyagilemethodsinsuchawaythatwecanreducethe

gap without providing face-to-face communication as the teams are geographically

split. Many companies have solved this issue with the use of technology as they

(Fowler,2006;Simons,2002;Danait,2005):

• Holdonlinevoiceorvideochatsessionsastheyprovidereal-timeface-to-face

meetings,whichallowtheteamstohaveanefficientconversation (Kotlarsky,

Oshri,2005).

• Collaborative tools such asWiki, IM and discussion boards help improve the

qualityofcommunicationofinformation.

Another issue isthetransfersofprocessesas inoffshoringcompaniesmovesomeof

theirbusinessordevelopmentprocessestooffshorelocation,whichcausesproblems

when companies outsource critical modules of domain specific projects. General

Motors is an example of such offshoring projects where they outsourced the

development of their web-based “New Owner Centre” project. Agile provides a

solutiontothisproblembysendingambassadorsfromoneoffshoresitetoanotherin

ordertohelpgatherinformationofthebusinessdomain.Butthedisadvantagetothis

approachisthatthispracticeiscostly(Fowler,2004).

Companies also face trust issues in offshoring as mentioned in Section 2.3.1, agile

suggests to use web conferencing for virtual white-boarding to share and discuss

projectdesignsandinformation(Braithwaiteetal.,2005).Thishelpstosolvetheissue

ofknowledgetransfermentionedinsection2.3.4asthewholeteamisdirectlysharing

informationface-to-faceviaInternet.Agilemethodsalsosuggestusingasharedcode-

repositoryasitallowstheteamstoseeeachother’swork(Danait,2005).

Somecompaniesevenopttocollocatetheteamduringtheinitialperiodoftheproject

sothattheteammemberscangettoknoweachother(Cottmeyer,2008).Thishelpsin

building trust among the team and develops sense of that they all are one team

despitelocatedatdistributedlocations(Danait,2005).Howevertocollocatetheteam

76

isacostlyprocess (Nisaretal.,2004). Ina literaturestudydonebyPaasivaaraetal.

(2009) they classified how different agile practices contribute in offshore agile

projects,Table2.9summarisestheirclassification.

Table2.9.AgilePracticesusedforOffshoreDevelopment(Paasivaaraetal.,2009).

No. NameofAgilePractice Description

1. DailyScrums For coordination and communication which in

offshoreprojectsisdoneviavideo/audioprofessional

conferencing tools such as Skype (Berczuk, 2007;

Danait,2005;Jensen,2003).

2. Sprint Planning

Meeting

Meetingdoneatthestartofeverysprint.Ifdifficultto

schedule it for whole team due to time-zone

difference, only team leads can hold this meeting

using synchronous communication tools. (Berczuk,

2007; Holmstrom, Conchùir, Agerfalk, Fitzgerald,

2006;Layman,Williams,Damian,andBures,2006).

3. SprintReviewMeeting Thewholeteamincludingtheoffshoreteammembers

are present in this meeting using synchronous

communication tools to discuss the progress of the

project(Berczuk,2007).

4. Demonstrationof

WorkingFunctionality

Aftereachsprint,newfunctionalitiesareaddeddueto

the sprint review meeting. These new requirements

need to be shared via videoconferencing or through

desktopsharing(Berczuk,2007;Danait,2005;Fowler,

2006).

5. Proxy/Remote

Customers

Somecompanieschooseproxycustomers inorder to

improve quality of product and to add a third party

77

whichcommunicateswiththerealcustomersandthe

team. The proxy customers can take decisions on

behalf of the real team. They communicatewith the

team via videoconferencing or email (Kircher, Jain,

Corsaro,andLevine,2001;Layman,Williams,Damian,

andBures,2006;Nisar,andHameed,2004).

6. Distributed Scrum of

Scrums

This isusedwhenthe team isvery large.Onlyscrum

mastersmeet every 2-3 days either in person or via

videoconferencing to discuss the progress of the

project(JensenandZilmer,2003;Smits,andPshigoda,

2007).

2.6.3EffectofOffshoringonAgileAdoption

In the Section 2.3 we identified four key challenges that affect offshore software

development, which also affect the adoption of agile practices in offshore software

development (Ghafoor et al., 2017). For example, consider the trust issue; it can

introduce certain difficulties in agile practices such as dispute over collective

ownership of code andmaintaining a sustainable pace of the project development.

Similarly,issuescausedduetosocio-culturaldifferencesalsoaffectagilepracticessuch

asfrequentdeliveryofcode,self-organisingteams,embracingchangeandresponding

inatimelymanner.

For teams wanting to adopt agile, communication and coordination issues are very

importantastheyimpactmostoftheagilepractices.Likewise,knowledgeandtransfer

ofknowledgearecentraltotheprinciplesofagilesoftwaredevelopmentastheyaidin

achieving sustainable pace of development, motivated individuals and continuous

code review. In Table 2.10 belowwehave highlighted some agile practices that are

affectedbytheoffshorechallenges.

78

Table2.10.AgilePracticesaffectedbyOffshoreChallenges.

No. Offshore

Challenge

AgilePractice EffectofChallengeonagile

practice

1. Trust CollectiveOwnership Dispute over code ownership

among the onshore and

offshoreteammembers

SustainablePace Difficulties in maintaining a

sustainable pace of project

development

2. Socio-cultural Iterativeand

incremental

development

Delays in frequent delivery of

code.

Self-organisingteams

Problemsinunderstandingeach

other’sculturalandsocialvalues

can cause a barrier in the

formation of self-organising

teams.

3.

Communication

and

Coordination

SprintPlanning

As the team is distributed, due

to lack of sufficient

communication, it can cause

projects in designing a correct

sprint.

ContinuousIntegration

Multiple versions of code

developed at different location

can cause any build to break

79

duetoerrorsbeingintegratedin

thecode.

4.

Knowledge

Transfer

ProductBacklog

Any change in product backlog

not documented correctly can

causeaprojecttofail.

SprintReview

Due to multiple locations of

sprint development. It causes

problems in determining the

progressoftheworkdone.

Table 2.10 demonstrates that agile practices cannot be used as it is in offshore

softwaredevelopmentandthatiswhypractitionershavebeenmodifyingandadapting

agilepractices.Webelieve thatpatternscanmake theagileadoptionprocesseasier

forpractitioners.

A case study done by Paasivaara showedhowR&Dunit of Ericsson, amultinational

telecommunication equipment and services company, integrated its global sites into

the leanandagiletransformation(Paasivaaraetal.,2013).Aspartofthisstudythey

observed how Ericsson integrated three sites,whichwere Finland, Hungary andUS.

TheystartedtheagileadoptionprocesswiththeFinlandsiteinwhichtheytransitioned

toagilemethodologyusinganevolutionarymodel,thatistheygraduallytransformed

theirprocessesoneatatimeandtheneventuallythewholesiteshiftedtousingagile

practices for their projects. Table 2.11, demonstrates an overview of how agile

practices were adopted at the three sites. Later we have explained what were the

successandfailuresoftheirtransition:

80

Table2.11.DetailofThreeSitesAdoptingAgilePracticesatR&DUnitofEricsson

(Paasivaaraetal.,2013).

No. Finland Hungary US

1. TransitionUsingfour

phase:

• Studyingand

Planning

• PilotTeams

• Full-ScaleRollOut

• Maturationand

Continuous

Improvement

Transitionsusingtwo

phases:

• Piloting

• RollOut

Transitionusingthree

phases:

• Studying

• Planning

• TeamStartWorking

2. Hiringexternal

consultingfirmtotrain

inagile.

Hiredapersonfroma

competitorwhohad

startedusingagile

TheacquiredUS

companyhadasimilar

productwiththe

existingcustomer.

Finnishteamcoached

them.

3. Impedimentbacklog

wasatFinland.

Didn’thaveelectronic

access,howeverwouldget

updatesusingphonecall

orsometimespicturesof

thebacklog.

Theinformationwas

madeavailabletothe

USteammembersas

soonaspossible.

4. Usedanevolutionary

changeapproach.

Usedaverydramatically

changeapproach.

Themanagementdid

finalteamselection.

5. Mostdevelopersin Developersweremostly TheUSteamhasbeen

81

Finlandhaveover10

yearsexperience

workinginEricsson.

youngandinexperience.

Hiredrightoutofschool.

usingleanandagile

practicesfor

developmentandthat

wasevidentfromtheir

work.

6. Hadmoreproduct

knowledgecomparedto

Hungariandevelopers.

Beforethetransition,the

Hungarianteamwas

viewedmoreasasub-

contractingsiteworking

onlyonspecificproduct

parts.

Whatwasdifferent

betweentheHungary

andUSteamsisthat

theyUSteamwere

involvedinallthelevels

oftheproject.

7. Causingincompetency

gapsbetweenthe

FinlandandHungary

developersasaresult

anexchangeprogram

wasdesigned.

Someofthedevelopers

lefttheHungaryteam,as

theydidn’twanttoadopt

agilepractices.

Theteamstarted

integratingwithother

sitesbystartingtheir

processesbyintensive

collaborationplanning

phase

8. Languagebarrier

stoppedFinnishteam

memberstocommitto

longstaysinHungary.

Feltthesupportofthe

management,asthey

visitedtheHungaryteam.

Mutualvisitsbetween

thesitesatalllevels

wereencouraged

betweentheUSand

Finnishteams.

9. Duetothenationaland

organisationalculture,

theFinnishteam

membersweremore

comfortableforming

HowevertheHungary

teammembersfeltthey

needtobetoldwhatthey

shoulddo.

Finnishexpertsvisiting

andsupportingatthe

USsite,duringthefirst

fewmonthsof

transition,helpedthe

82

self-organisingteams teamstounderstand

eachother’scultural

differences.

Based on the above presented transition process between the three sites, Ericsson,

foundsuccessbyfollowingthepracticesmentionedbelow:

• Earlyinvolvementofglobalsites

• Broadinvolvementofatallorganisationallevels.

• CompetenceExchangeProgram.

• ConstantCommunicationandCross-sitevisits.

• JointInfrastructure.

However having presented the success factors above, Ericsson still faced some

challengesduringtheintegrationprocess,whichare:

• Creatingasharedunderstandingofthechange,thatiseventhoughtheFinland

and Hungary sites, were able to create a shared understanding at the

managementlevel,butcommunicatingittothelowerlevelswasdifficult.

• EnablingEnd-toEndDevelopment,astheconceptofdeliveringaworkingpiece

of code within 2-4 week duration was a new concept for the development

team.

• Bridging cultural differences, as all the three sites had different natural and

organisationalculturalvalues.

• Creating Transparency between the sites, as the Hungary site felt as if they

were not part of the actual team as all the software artefacts were at the

FinlandsiteandwerenotavailabletotheHungarysiteelectronically.Thisissue

waslaterresolvedbyusingonlinewikis.

83

Researchers such as Holmstrom have done work on how we can solve

communication and coordination issues using agile practices as it is such as

(Holmstrometal.,2006):

• XPPairProgramming-Helpstoincreasetimeoverlap,whichinturnhelps

in reducing temporal distance. However they did not discuss about how

much time would be wasted in order to just coordinate different time

zones.

• Scrum Simple Planning: Helps increase “team-ness”,which in turn helps

reducegeographicaldistance. The limitation to thisapproach isasabove

mentionedtheauthorsdidn’tdiscusshowmucheffortwouldberequired

tocommunicationandcoordinatethedistributedteams.

• XPPairProgrammingandScrumPre-GamePhase:Helpsincreasemutual

understandingand collaborationbetween the teams,which in turnhelps

reducesocioculturaldistance.Similarlytheresearchersdidn’tdiscusshow

efficientlytheteamsshouldcollaborateinordertoachievethisbenefitas

in order to collaborate with geographically distributed teams requires

coordinationoftimefromallthedistributedsites.

2.7 AStudyontheUseofPatternsinAgileAdoptioninOffshore

Development

Inthissectionwehavegivenanoverviewofpatternscurrentlypresentinliteraturefor

agileadoptionandwehavealsopresentedanoverviewofourdistributedagile

patternscatalogue.

84

2.7.1CurrentPatternsforAgileAdoption

Based on the definition of patterns mentioned in Section 2.6.2.1, we define agile

patternsas“focusonhowanagilepracticeisbeingrepeatedlymodifiedandusedin

order to solve a recurring agile problem in a particular context”. The difference

betweenanagilepracticeandagilepattern is thatagilepracticesarea collectionof

methodsandtechniquesputtogethertosupporttheapplicationofagilemethodology

fordevelopingaproject,whereasanagilepatternfocusesonagilebestpracticesthat

occur repeatedly while applying agile methodology for developing software. That

meansanagilepatternconsistsofbestagilepracticethatisbeingrepeatedlyusedto

overcomeaspecificchallengeinapplyingapractice.

For example, daily standup meeting is an agile practice, which helps the team to

coordinate their daily activity by answering three questions: i) What did you do

yesterday ii)Whatareyougoing todo today?and iii)What isgetting inyourway?,

whereasdailymorning standupmeeting is an agile pattern as it has been observed

that conducting daily standup meeting in the morning is more effective than

conductingitduringmid-dayorattheendofwork-day.Therepeatedobservationof

themodifiedpractice ledtothecreationofdailymorningstandupmeetingpatterns.

With thehelpof thispatternweaddressedthechallengeofknowledgetransferand

communicationandcoordinationissues.

As companies are choosing to develop software offshore, new patterns are being

designed. Noll has worked on making a decision support system for offshore

development to help practitioners by providing them with patterns that occur in

offshoring (Noll et al., 2014). Lescher provided collaboration patterns for global

development that he observed in Siemens (Lescher, 2010). He identified 5 patterns

whichfocusedonimprovingthegeneralcommunicationandcoordinationoftheteam

inoffshoredevelopmentforexampleonepatternheidentifiedwasTailoredTraining

inwhich the team is co-locate early on in the project for training to familiarize the

wholeteamwithtechnologiesneededintheproject.SimilarlyvanHeeschpresented

two collaborative patterns for offshore development, which focused on how the

85

onshoreandoffshoreteamshouldbeformedinordertoimprovecollaborationamong

the teams (Heesch et al., 2015). Table 2.12 demonstrates the offshore software

developmentpatternspresentedbypractitionersandresearchers:

Table2.12.ExistingOffshoreSoftwareDevelopmentPatterns.

No. Scope Detail

1. CulturalPatterns Based on the exploration and evidence from the

literaturedesigneda fewpatternsandsomeof them

might be considered as anti patterns (MacGregor et

al.,2005).Belowisthelistoftheircatalogue:

• Yes(butNo)

• ProxyPattern

• We’ll-take-you-literally(Anti-Pattern)

• We’re-one-single-team(Anti-Pattern)

• Thecustomer-is-king(Anti-Pattern)

Shah presented the idea of “cultural models” as

patternsthatgovernconventionalbehaviours(Shahet

al., 2012). As according to them patterns identified

using dimensions specified by Hofstede’s and

Hampden-Turner,limitsthemeaningofculture,make

culture to be viewed as a static entity and

characterises teams based on nationality rather then

individuals.Followingaremodelspresentedbythem:

• UnproductiveProductivity

• HesitanttoalwayssayYes

• Owningratherthanmodularizing

2. Communication

and Collaboration

The identified four types of communicationpatterns,

whichareasfollowing(Paasivaaraetal.,2003):

86

Patterns • ProblemSolving

• Informing,monitoringandfeedback

• RelationshipBuilding

• DecisionMakingandCoordination

Bricoutpresentedthirteencommunicationpatternsto

deal with communication between the team and

differentpartsoftheorganisation,whichare(Bricout,

2004):

• OneProject

• ExplicitCommunicationStrategy

• EarlyBonding

• Face-to-faceEvery2Months

• IterateasyouMeet

• CommonTerminology

• ContinuallyAlignedProcess

• ResponsibilityModel

• CultureAwareness

• FlexibleHours

• TemporaryEngagement

• SocialFunds

• JoinforCompletion

Based on Lescher observation of offshore software

development at Siemens, identified five collaborative

patterns,whichare(Lescher,2010):

• TailoredTraining

• Co-locatedAnalysisPhase

• OnsiteManagementVisits

• Cross-siteDelegation

• UnfilteredLineManagerCommunication

87

vanHeeschpresentedtwocollaborativepatterns(van

Heesch,2015)whichhelinkedwiththeworkdoneby

Lescher and Bricout (Lescher, 2010; Bricout, 2004),

whichare:

• ExperienceMix

• DissolveGeographicalBoundaries

3. Patternsfor

Project

Management

A catalogue was presented for global software

developmentpatternsforprojectmanagement,which

includedthefollowing(Valimakietal.,2009):

• GSDStrategy

• FuzzyFront-end

• CommunicateEarly

• DivideandConquereachIteration

• KeyRolesOn-site

• CommunicationTools

• CommonRepositoriesandTools

• WorkAllocation

• ArchitecturalWorkAllocation

• Phase-basedWorkAllocation

• Feature-BasedWorkAllocation

• UseCommonProcesses

• IterationPlanning

• Multi-leveldailyMeetings

• IterationReview

• OrganiseKnowledgeTransfer

• ManageCompetence

• NoticeCulturalDifferences

4. TestingPatterns A research conducted with Technische Universitat

88

Munchen (TUM) in cooperation with Capgemini, a

Germansoftwareandconsultancycompanytoidentify

the problems in testing a GSD project and provide a

solution to those problems (Pehmöller et al., 2010).

They developed 16 testing patterns for offshore

projects,whichare:

• TestcasesasMemorandumofunderstanding

ofKnowledgeTransfer

• Light-weightPer-AcceptanceTest

• CommunicationonEyeLevel

• UsetoolforBugTracking

• Movingon-/offBusinessAnalyst

• ComplementingTestingAttitudes

• AlignunderstandingofGeneralTesting

Approach

• ContinuousIntegrationTesting

• MirroredTeamManager

• ExtensionoftheDay

• TraceableTestCases

• Tester’sSparringPartner

• ComplementtestSkills

• SynchronisedTestEnvironment

• CentralTestEnvironment

• EvaluationofConstraintsoftestdata

5. Requirement

Engineering

Patterns

Salger presented “Specification Patterns”, which

describe practices that analysts should keep inmind

while writing down the software requirement

specificationdocumentforanoffshoreproject(Salger

etal.,2010).Theidentifiedthefollowingpatterns:

89

• Define‘BusinessRule’

• Define‘UseCase’

• On-boardBusinessAnalystduringRequirement

Engineering

• ShipTestCases

• UseWorkPackagesandHandoverCheckpoints

• UseBidirectionalCrossReferences

• MapBusinessTermstoEntityAttributes.

Work has also been done on identifying agile patterns in offshore development.

Cordeiro combined organisational patterns and scrum to provide a solution for

offshoredevelopment(Cordeiroetal.,2007).Theyidentified6patternsandproposed

apatternlanguagestructurebasedonliteratureandlateradaptedthepatternsbased

on the authors’ experience of running somemulti-site projects. Välimäki presented

patterns fordistributedscrum,whichfocusedonfindingpracticestosupportproject

managementindistributedscrumprojectsthatuseApplicationlifecyclemanagement

suchasEstablishApplicationLifecycleManagementtool(Välimäkietal.,2008).Table

2.13belowliststheagilepatternsidentifiedsofar:

Table2.13.PatternsforAgileSoftwareDevelopment.

No. PatternName Detail

1. MagicBacklog

Patterns

Identified nine backlog patterns to help practitioners

document correct story cards as a need to formalise

thebacklogincreasedwiththesizeoftheproject.The

pattern catalogue was designed based on their 50+

years experience in system development, however

their focushasbeenonco-locatedteams(Hvatumet

al.,2015).Theirpatternsare:

• BacklogFrame

• BacklogViews

90

• BacklogPeople

• BacklogTales

• BacklogUsageModels

• BacklogPlaceholders

• BacklogPlans

• BacklogConnections

• BacklogAnswers

2. DailyStandup

Patterns

Fowler presented patterns for daily standupmeeting

howeverhedidn’tconsidersoftwarebeingdeveloped

offshore(Fowler,2016).Thelistofhispatternsis:

• WorkItemsAttend

• YesterdayTodayObstacles

• ImprovementBoard

• WalktheBoard

• ObstaclesarenotRaised

3. DistributedProject

Managementand

ScrumPatterns

Nine distributed project management and scrum

patterns were presented, which are (Välimäki et al.,

2008):

• HaveaKick-offMeeting

• MakeaReleasePlanwithsomeSprints

• OrganiseneededScrumRolesineachSites

• EstablishApplicationLifecycleManagement

Tool

• Establishafastandreliableinfra

• Establishefficientcommunicationmethods

• KnowledgeTransfer

• VisualiseStatusofProject

91

• HavemergeDailyScrums

4. Multi-site

Software

Development

Patterns

Apatternlanguagewasdesignedtomanagemulti-site

software projects (Cordeiro et al., 2007). They

combined organisational patterns and scrum to form

their pattern language, in which they proposed 6

patterns,listedbelow:

• SurrogateCustomer

• StoriesReworkSubsystem

• InversionofControl

• CodeLine(CodeOwnership)

• IntegrationBuild

• PlanBugsonSustainablePace

5. AgileAdoption

Patterns

Elssamadisyfocusedonthedynamicsofagileadoption

that is focused more on understanding the ideas,

values and philosophy supporting agility in order to

optimise the agile adoption process (Elssamadisy et

al., 2006). He designed a pattern catalogue of seven

patterns that intended to focus on the granularity of

agilepracticesandhow itwouldhelppractitioners in

adoptingagile.Thelistofthisproposedpatternsinas

following:

• ReciprocalVisibility

• StaticInformationRadiator

• DynamicInformationRadiator

• EvocativeDocumentation

• StandupMeeting

• ReaffirmationRitual

92

• SolidarityRitual

Elssamadisyprovidedatemplatefortheiradoptionpattern,whichis(Elssamadisyet

al.,2006):

• Name:Uniquenameofthepattern.

• Sketch:Astorythatactsasa‘sketch’forthedesignofthepattern.

• Context:Whoandinwhatcircumstancesthepatternisuseful.

• Forces:Usedtoelaboratethecontextsectionandgivespecificissuesthatcan

beresolvedwiththehelpofthepattern.

• Therefore:Descriptionofthepattern.

• But:Consequencesandlimitationsofthepattern.

• How:Guidelinesofhowthepatternshouldbeadopted.Alsoincludessmellsto

indicatewhereapatternadoptioncangowrong.

• a.k.a:Similarpublishedpatterns.

Theyproposedthecustomisedformatforthepurposeofdocumentingtheirpatterns;

they introduced the conceptof smells inpatternsand introduced theexplicituseof

“AbstractPatterns”.Abstractpatternmightbeseenasacategoryofpatternsasitlacks

animplementationindependenceofitsconcretepatterns.

AccordingtoAmrElssamadisyand),inordertoachievesuccessfulagileadoption,itis

not just enough to focus on what practices should be adopted rather we need to

answeradditionalquestionssuchas(Elssamadisyetal.,2006):

• WhichpracticesdoIadoptfirst?

• Whichpracticesrelatetoothers?

• CanIincrementallyadoptagivenpracticeorincrementallyadoptfromasetof

practices?

• CanIadopttheformofapracticewithoutalteringitssubstance?

• CanIaddtoordeletefromaspecifiedsetofpractices?

93

• Whatvaluesandassumptionsarepresupposedbyagivenpractice?

• And, consistent with the spirit of agility, what business value does each

practicedeliver?

They identified 7 patterns, which are mentioned in Table 2.13. Overview of

ElssamadisypatternsisexplainedinTable2.14(Elssamadisyetal.,2006).

Table2.14.OverviewofAgileAdoptionPatterns(Elssamadisyetal.,2006).

No. PatternName Overview

1. Reciprocal

Visibility

ImpedimentChangeisrecordedandmadevisibletothe

wholeteam.

2. Static

Information

Radiator

ScrumMastermakescommonScrumBoardchartforthe

wholeteamtoview

3. Dynamic

Information

Radiator

DailyStandupmeetingsandretrospectivetakeplaceinorder

toexchangeinformation.

4. Evocative

Document

Documentisdoneusingsymbolsandinformalstylesothatit

iseasiertounderstand.

5. StandupMeeting Dailystandupmeetingareconductedwiththeteamandthis

isatime-boxedactivity.

6. Reaffirmation

Ritual

Theorganisation’satmosphereiskeptlaid-backinorderto

keeptheteammotivatedtowork.

7. SolidarityRitual Theteamhasitsownconsolidatedspacetoworkand

conducttheirmeetings.

94

Howevertheirfocuswasonhowtoimprovecommunicationandcoordinationamong

the team members, which are co-located and did not consider the complications

addedduetodistributedteamslocatedindifferenttimezones.

2.7.2DistributedAgilePatterns

The work done so far is either generic to patterns observed in offshore software

development, or the ones that target agile development which tend to focus on

projectmanagementandcoordinationofaproject. Incontrast,ourresearchfocuses

on identifying distributed agile patterns that will help practitioners’ adopt the agile

practices inanoffshoresoftwaredevelopmentcontext.Westudiedmanycasesfrom

the literature and observed some common practices that companies utilise to

overcomethechallengesofoffshoredevelopmentbyapplyinganagilemethodology.

From our observation we found recurring solutions for recurring offshore problems

thattheteamfacefromrequirementgatheringtodeploymentoftheproject.Building

onthepreviousdefinitionofagilepatterns,wedefineadistributedagilepattern as

adaptationofanagilepractice that isbeing repeatedlyapplied inorder to solvea

recurringchallengeinadistributedprojectscenario.Inourresearch,weappliedthe

systematic literature review and content analysis research methods to develop a

catalogueof distributed agile patterns.As a resultwehave identified15distributed

agile patterns, which we have organised in four categories. Details about the

distributedagilepatternscataloguehavebeendiscussedinChapter4.

2.8ChapterSummary

This chapter presented an overview of the work done in the area of agile offshore

development. The chapter started by presenting a background on offshore

development in which we discussed different offshore models and what are the

benefitsofoffshoring.Wethenpresentedastudyinwhichweidentifiedchallengesin

offshoredevelopmentandhowthosechallengesaffected thesoftwaredevelopment

95

process.Wealsodiscussedaboutagilesoftwaredevelopmentandhowagile isbeing

adoptedinoffshoresoftwaredevelopment.Wethenpresentedastudyontheuseof

patternsinagileadoptioninsoftwaredevelopmentinwhichwepresentedthecurrent

patternsthatarebeingusedinagileadoptionandgaveanoverviewofourdistributed

agilepatterns.

In the next chapter, the research methodology used in this research has been

presented.

96

Chapter3 ResearchMethodology

3.1Introduction

Researchmethodologycanbedefinedassomethingpeopleundertakeinordertofind

out things in a systematic way thereby increasing their knowledge (Saunders et al.,

2007). There are many ways in which research methods can be explained. In this

chapterwewill firstlydiscussdifferent stagesof the researchmethodologywith the

help of Saunders’s research onion and then we will map those stages to how we

carriedoutourresearch(Saundersetal.,2007).Basedonourresearchmethodology,

wehavediscussedtheresearchphilosophywehavefollowedthroughouttheresearch

which is realism and then presented our research approach and strategy based on

whichwedesignedourresearchquestionsanddiscussedthedatasourceandsearch

strategiesusedtocollectthedatafortheresearch.Lastlywehavedemonstratedthe

validationprocessusedforvalidatingtheresultsofthisresearch.

3.2OverviewofResearchOnion

The researchonionwasdevelopedbySaunders to illustrate thestages thatmustbe

coveredwhen undertaking research (Saunders et al., 2007). Each outer layer in the

research onion describes a more detailed stage of research process and contains

differentwaysinwhichalayerofresearchcanbeconducted.Thisapproachprovides

aneffectiveprogressionthroughwhicharesearchmethodologycanbedesignedand

its usefulness lies in the fact that it can adapt to almost any type of research

methodologyandcanbeusedinawiderangeofcontexts(Bryman,2012).

TheFigure3.1demonstratesanoverviewofSaunders’sResearchModelshowingthe

mainstagesoftheresearchprocess.

97

Figure3.1.TheResearchOnion(Saundersetal.,2007)

According toSaunders’s researchonion showed in Figure3.1, the researchneeds to

startbydefiningtheresearchphilosophyasithelpsincreatingastartingpointforthe

selectionoftheappropriateresearchapproach,whichaccordingtothemisthesecond

stepoftheresearchprocess(Saundersetal.,2007).Oncetheresearcherhasselected

theresearchwhatresearchapproachtheywillbeusingtheymoveontothenextstage

oftheresearchprocessinwhichtheywilldecidewhatresearchstrategytheywilluse,

thatiswhatplantheywillfollowtoanswertheirresearchquestions.Thefourthstepis

deciding the researchapproach thatwill beusedby the researcher, that is are they

goingtousemono-method,mixedmethodormulti-method.Thefifthstepisdefining

the time horizon for the research, as that will determine the time frame for data

collection.The last stepaccording the researchonion isdatacollection, in this stage

theresearcherdecidedhowhe/shewillbecollectingdatafortheirresearch,isitgoing

tobebyusingprimarydataorsecondarydata.

In order to explain each phase of the research onion we have designed Table 3.1,

whichgivesanoverviewofeach research stepandprovidesdetailofwhatdifferent

typeofprocesses researchers canuse toconduct their research ina systematicway

withthehelpofSaunders’sresearchonion(Saundersetal.,2007).

98

Table3.1.OverviewofResearchOnion.

No. Research

Phase

Definition Type Detail

1. Research

Philosophy

Reflectstheway

researchers

think about the

development

knowledge,

which affects

the way, the

researcher does

hisresearch.

Positivism Assumes that the reality exists

independent from the variables

under observation. This type of

research philosophy is usually

considered quantitative as the

problem is identified from

literaturehenceonly focusingon

certainvariables.

Realism Focusesonthewaypeoplemake

sense of theworld, especially by

sharingtheirexperiences(Hussey

etal.,1997).Thistypeofresearch

is usually considered qualitative,

as it requires the researcher to

examine real-life events in order

to explain how and why certain

obstacles occurred during the

research.

2. Research

Approaches

Definesthe

approachthe

researchchoses

toconducthis

research.

Deductive In this approach the researcher

starts with theoretical

proposition and them moves

towards concrete empirical

evidence. That is the researcher

develops the hypothesis upon a

pre-existing theory and then

99

formulateshisresearchapproach

to test it. This type of research

owes to positivism research

philosophy as it allows the

researcher to formulate

hypothesis and statistical testing

fortheexpectedresults.

Inductive Characterised as to move from

specific to general, that

observation are considered a

starting point and patterns are

looked at from the data to

formulate a research problem

and find its solution.This typeof

research follows a more realism

researchphilosophy.

3. Research

Strategies

Itisaplanto

answerresearch

questions,

whichwill

satisfythe

research

objectives.

Experiment Refereed to the strategy of

creating a research process that

examines the results of an

experiment against the expected

results. This research strategy is

used when you have a limited

number of factors and youwant

tostudytherelationshipbetween

themandjudgethemagainstthe

expectedresearchresults.

Survey Tend to be used in quantitative

research projects and involve

100

samplingofdifferentproportions

ofvariables.

CaseStudy Usedwhen the researcherwants

togainin-depthunderstandingof

the context of the research

problem. Yin also recommended

to use case study strategy for

when the researcher has little

controlovereventsandwhenthe

focus inon contemporaryevents

(Yin,2003).

Grounded

Theory

It is a qualitative methodology

that draws on an inductive

approach in which patterns are

derived from the data as

preconditionsforthestudy(May,

2011).

Ethnography Involves close observation of

people and examines their

cultural interactions and their

meaning(Bryman,2012).

Action

Research

Characterised as a practical

approach to a specific research

problem, within a community of

practice (Bryman, 2012). It

involves reflective practices, in

whichprofessionals get feedback

101

on their research, to improve

theirresults.

Archival

Research

In this research strategy, the

research is conducted from

existing material (Flick, 2012).

Thisformofresearchmayinvolve

systematic literature review,

where the researcher examines

patterns inordertoestablishthe

sumofknowledgeonaparticular

study or to examine the

applicationofexistingresearchto

identifyaspecificproblem.

4. Choice Outlinesthe

researchby

decidedwhat

research

approachthe

researcherwill

use.

Mono

Method

As the name suggests it involves

the researcher using one

approachforhisresearch.

Mixed

Method

Inmixedmethod, the researcher

uses two or more methods of

research such as using both

quantitative and qualitative

methodology(Bryman,2012)

Multi-

Method

Thisinvolvesthatmixedmethods

combine create a single dataset

(Flick,2011)

5. TimeHorizon Focusesonwhat

timeisallocated

Cross

Sectional

The time frame is already

established according to which

102

to complete the

research.

thedatahastobecollected.

Longitudinal Collectionofdatarepeatedlyover

an extended time period and is

usedwhereanimportantfactoris

beingexaminedoverachangeof

time(Goddardetal.,2004).

6. Data

Collection

There are a

variety of ways

through which

data can be

collected. In

quantitative

methodology,

the researcher

is focused on

measuring

variables or

counts their

occurrence.

Whereas in

qualitative

methodology,

the research

emphasises on

the experience

of a

phenomena.

PrimaryData Refers to data that is derived

from first-hand sources such as

data collected through

interviews, direct observation,

participant observation,

questionnairesandsurveys.

Secondary

Data

Data isderived fromtheworkor

opinions of other researchers

(Newman, 1988). For example

archival records, organisational

documentation, publications and

annualreports.

103

3.3ResearchMethodologyusedtoDesignDistributedAgilePatterns

InthissectionwehavefocusedonthehowwehaveusedSaundersresearchonionin

ordertoconductourresearch(Saundersetal.,2007).

3.3.1ResearchPhilosophy

BasedonthedefinitionofresearchphilosophymentionedinTable3.1wehaveused

Realism research philosophy for conducting our research. Since the focus of this

researchistounderstandhowpractitionersdevelopprojectsoffshorewhileusingagile

practices. We are studying these variables in the real-life events. This is reflected

throughout our research methodology mentioned in Figure 1.1 Research

Methodology.

AsfromStep1:ReviewPreviousLiterature,wearefocusingonidentifyingcasestudies

thatdemonstratehowpractitionersareusingdevelopingsoftwareatoffshorelocation

in order to formulate our research questions, which is Step 2 of our research

methodologythatistoIdentifyandDefinetheResearchProblem.

In order to conduct Step 3: Collect Data from Literature and Interviews, to identify

recurringagilepracticesthatarebeingusedbypractitionerstoovercomechallengesin

offshoredevelopment,wefocusedonexaminingthehowandwhypractitionerschose

toadaptanagilepracticesandifthatsolutionhasbeenusedrecurrentlytosolvethe

sameoffshorechallengebyotherpractitioners.

In Step 4: Analysing Data Collected from Literature and Interviews, we used

Krippendorff’s content analysis (Krippendorff, 2004). Since the data being analysed

was based on real-life events in order to explain how practitioners adapted agile

practices for their offshore projects, hence this reflects our research philosophy of

realism.

104

Basedonthedatacollected inStep3andtheanalysesdone inStep4.Wedesigned

ourDistributedAgilePatternCatalogue.AsStep3andStep4wereconductedusing

real-lifedata fromevents, thepatterncatalogue isbasedonpatternsobservedfrom

literature and by practitioners. Hence Step 5: Design and Develop Distributed Agile

PatternsCataloguehasbeendonefollowingtherealismresearchphilosophy.

Step 6: Validate and Evaluate the Distributed Agile Patter Catalogue we involved

experts toreviewourpatterncatalogueandbasedontheir feedbackStep7:Modify

the Catalogue to Improve the Results is conducted in which we havemodified our

catalogue.

Basedontheoverviewofeachstepofourresearchmethodologyitisevidentthatthe

researchphilosophychosenbyusforthisresearchisrealism.

3.3.2ResearchApproach

As mentioned in Table 3.1 there are two types of research approaches that are

DeductiveandInductive.TheresearchapproachusedforthisresearchisInductive.As

the research started by reviewing the previous literature on Global Software

Development at mentioned in Figure 1.1 Research Methodology’s Step 1: Review

PreviousLiterature.Inthatstepwefocusedonstudyingcasesinliteraturetoidentify

whatarethechallengesinGlobalSoftwaredevelopmentandbasedonthatstudywe

definedourresearchproblemandformulatedourresearchquestions,whichisStep2:

IdentifyandDefineResearchProblem.

To further refine our research problem we conducted Step 3: Collect Data from

Literature Review and Interviews, to identify how specific challenges in offshore

softwaredevelopmentaffecttheapplicationofagilepracticesandwemovedtowards

developing generic distributed agile patterns that practitioners could use while

planningtomovetheirprocessestooffshorelocations.

105

In Step4:AnalysingDataCollected fromLiteratureand Interviews,wego intomore

detail by using Krippendorff’s content analysis approach to analyse the data we

collected in Step 3, to get meaningful information (Krippendorff, 2004). Content

Analysis is a research tool used to determine the presences of certain words or

concepts within text or set of texts. Researchers use it to quantify and analyse the

presencesofmeaningandrelationshipofwordsandconcepts.Theyareusuallyused

forthefollowingpurposes:

• Revealinternaldifferencesincommunicationcontext.

• Detecttheexistenceofpropaganda.

• Identifytheintentions,focusorcommunicationtrendsofan individual,group

orinstitutions’.

• Describeattitudinalandbehaviouralresponsestocommunication.

• Determinepsychologicaloremotionalstateofapersonorgroupofpeople.

The reasonwe selected this approachwas to identify the trends of global software

developmentandunderstandtheattitudinalbehaviourofoffshoredevelopmentand

how it effects the adoption of agile in offshore projects. There are two types of

contentanalysis,conceptualandrelational,definedbelow(Writing@CSU,2004):

• ConceptualAnalysis:Theyonlyfocusoffindingtheexistenceandfrequencyof

atext/wordbutdonotfocusonifthattext/wordhasanyrelationwithwords

aroundit.

• Relational Analysis: It is one step further from conceptual analysis and it

focuses on examining the relationships among concepts in a text and it also

identifieswordsthathavesimilarmeaning.

For thepurposeofour researchwehaveusedrelationalanalysisaswearenotonly

focusingoncountingthefrequencyof“GlobalSoftwareDevelopment”ratherwealso

106

consider its relationshipwith agiledevelopment andwealso consideredwordswith

similarmeaning.Table3.2showsourselectedkeyconceptsandtheirsimilarmeaning.

Table3.2:KeyConceptsSelectedforRelationalAnalysis.

Type KeyConcepts SimilarMeaning

1 GlobalSoftwareDevelopment GlobalSoftwareEngineering

OffshoreSoftwareDevelopment

Offshoring

DistributedSoftwareDevelopment

DistributedDevelopment

2 AgileMethodology Agile

Agilepractices

Agilemethods

Scrum

XP

RelationalAnalysishaseightkeystepsthatare(Writing@CSU,2004):

• Identifythequestion,asitindicatesweretheresearchisheadedandwhy?

• Chooseasampleorsamplesforanalysisthatisyouneedtodecidehowmuch

informationisrequiredforanalysis.Thisstepneedstobeconductedcarefully

as the sample will determine your results and insufficient samples can limit

yourresultsandtoomuchsamplescancausedifficultiesincodingthesample.

• Determinethetypeofanalysis.Therearethreetypesofanalysisyoucanselect

from: Affect extraction, Proximity analysis and Cognitive mapping. The

approachweselectedwasproximityanalysisasitevaluatesconceptsbasedon

co-occurrences because we wanted to analyse global software development

107

and itseffectonagile softwaredevelopment.Whereasaffectextraction just

focused on evaluating individual concepts and cognitivemapping focused on

creatingmodels,whichisn'trelevanttoourresearch.

• Reduce the text to categories and code for words or patterns. At this stage

codingisdonetoidentifymereexistenceofaconcept/word.

• Exploretherelationshipsbetweenconcepts.Thatistodeterminethedegreeto

which two or more concepts are related to each other and whether that

relationship is positive or negative. Lastly focus on the direction of the

relationshipe.g.impactofXonYandinourcaseitwouldbestudytheimpact

ofglobalsoftwaredevelopmentonagilesoftwaredevelopment.

• Code the relationships. In this step statements and relationships between

conceptsarecoded.Assigningcodestorelationshipsisanefforttodetermine

whethertheambiguouswordsarejustfiltersorholdsinformation.

• Performstatisticalanalyses. In thisstepweexplore thedifferenceor look for

relationshipsamongthekeywords/concepts.

• Map out the representations. You can use graphical notations to represent

your findings. However we did not use this approach as our focus was on

identifying the relationship and developing our distributed agile pattern

catalogue.

DetailoftheanalysisispresentedinSection3.3.3,basedontheresultsoftheanalysis

wemovedtowardsStep5:DesignandDevelopDistributedAgilePatternsCatalogue.

The main follow of the steps followed to develop and design the catalogue is

demonstratedinFigure3.2below:

108

Figure3.2.OverviewofDesignandDevelopmentofDistributedAgilePattern

Catalogue

Anoverviewofwhathappensineachstepisgivenbelow:

Step1:Identifyexistingpatternsandrecurringpractices.

Asmentioned inSection3.3.1, the research startedby reviewing theexisting

literature fromwhichwe identified our research problem. In order to find a

solutionfortheidentifiedproblem,weconductedsystematicliteraturereview

toidentifypatternsusedtosolvechallengesinoffshoresoftwaredevelopment.

Based on this step we were able to collect data that was required for

conducting this research. We also conducted semi-structured interviews to

identifypatterns.Detailsofhowthisstep isexecutedhavebeenpresented in

Section3.3.3.

Step2:Analysetheidentifiedpatterns.

Inordertofocusoncollectingtherightdataforourresearch,wefirstfilteredcase

studiesbasedontheidentifiedresearchquestionsmentionedinSection1.3andto

furtherrefineourdatawesetaselectioncriteriawhichwasthatthepapersshould

addressthefollowingquestions:

109

- Does a paper address a challenge in applying any Agile Practice in

distributedprojects?

- Does a paper discuss any real life experience of using Agile practices for

distributedprojects?

- Is their any Agile Practice that has been repeatedly adapted and used to

solveissueswithdistributedprojects?

Basedontheabove-identifiedcriteria,wewantedtoidentifypatternsinliterature

thatarebeingusedtosolveanoffshoredevelopmentchallenge.Furtherwealso

focused on identifying solutions that practitioners used to overcome offshore

challenges and analyse if any other practitioner has used a similar solution.We

havedemonstratedindetailthefiltrationandselectionprocessinSection3.3.3.

After the data collection phase was completed we moved towards studying

literatureonexistingpatternsused insoftwaredevelopment.Currentlythereare

sixtypesofpatternsmentionedinSection2.6.2.1.

Step3:DevelopDistributedAgilePatternsCatalogue.

From the systematic literature review and semi-structured interviews, we

identified 15 patterns that were being used in distributed agile software

development. In our research we have classified an agile practice as a

distributedagilepatternifithasbeenrepeatedinmorethenatleast2articles

and has been used to solve a recursive problem. Table 3.4 presents an

overview of howmany times agile practices were used to solve an offshore

challengeinliterature,whichwefurtherclassifiedasdistributedagilepatterns.

110

Step4:Organiseanddocumentthecatalogue.

Based on the existing template mentioned in Section 2.6.2.1, we selected

Gamma’sDesignPatternstemplateinordertopreservefamiliarity,astheyare

perceived as the first pattern catalogue to be documented by the software

community.DetailofthisstephasbeendiscussedinSection4.2.

Thedistributedagilepatternswereorganisedintofourcategoriesbasedonthe

type of problem they solved. The four categories are management,

communication,coordinationandverificationpatterns.Detailofeachcategory

ispresentedinSection4.3.

Step5:MapDistributedAgilePatternsonTraditionalScrumLifecycle.

The identified15distributedagilepatternsweremappedontothetraditional

scrumlifecycleinordertohelppractitionersdecidedwhichdistributedpattern

canbeusedatdifferentstagesofthescrumwhichisshowninFigure4.2.

Step6:ValidateandEvaluatetheDistributedAgilePatternCatalogue.

Inordertovalidatethepatterncatalogueweusedreflectionworkshopandto

evaluate it we compared our solution to the existing solutions presented in

literature.DetailofthisstepispresentedinChapter5.

Step7:FinalisetheDistributedAgilePatternsCatalogue.

Based on the feedback given to us as part of the reflection workshop, we

modifiedourpatterncatalogue.Inordertoavoidconfusionforthereaderwe

presented theoriginal patterns inAppendix F and theRevised versionof the

catalogueinSection4.5.

111

According to the above discussion it can be seen that we have used an inductive

approach, as the researchmoves from specific to general.Aswe first identified and

designed a specific research problem and then developed a generic catalogue of

distributedagilepatternstobeusedbypractitionerswhilechoosingtodeveloptheir

projectsatoffshorelocations.

3.3.3ResearchStrategy

AsdefinedinTable3.1,researchstrategydeterminestheplanaresearcherintendsto

followinordertoanswertheidentifiedresearchquestions.Yin(2003)pointedoutthat

in order to select the correct research strategy, it is important to consider three

aspectsoftheresearch,whichare:

• Thetypeofresearchquestionsposed;

• Theextentofcontrolandinvestigatorhasoveractualbehaviouralevents;and

• Thedegreeoffocusoncontemporaryasopposedtohistoricalevents.

Therearesevenwaysaresearchercanachievethis.Wehaveselectedthreewaysto

answerourresearchquestionsmentionedinSection1.3,whichare:archivalresearch,

casestudyandactionresearch.

InordertoachievethatwestartfromFigure1.1Step1:ReviewPreviousLiterature,in

which we study cases from literature, this form of research is referred as archival

researchasresearchisconductedfromexistingmaterial.SystematicLiteratureReview

is a technique to identify, analyse and interpret relevant published primary studies

with reference to a specific research questions. It provides a summary of reported

evidenceavailable foragivenareaof interest. It isdifferent fromordinary literature

surveys as they are formally planned and methodically executed. Kitchenham

recommendedtouseSLRasareviewmethodologybecauseitallowedtheresearcher

to(Kitchenhametal.,2007):

• Systematicallysummariseexistingevidencefromliterature.

112

• Identifygapsinresearch.

• Provideaframeworktopositionfutureresearchactivities.

To identify challenges in offshore development we conducted the first Systematic

LiteratureReview.ThedetailsoftheSLRarementionedinSection2.3andthestudies

thatwereselectedasevidencearepresented inAppendixA.Basedonthe literature

review wemoved to the Step 2: Identify and Define Research Problem. The board

objectiveofthisstudywasdefinedastoanswerthefollowingquestion:

RQ:Whataretherecurringadaptationsofagilepracticesthatarebeingusedwithin

offshoresoftwaredevelopmentinordertoaddresstheidentifiedissues?

Tobemorespecific,thestudy’sfocuswasonthefollowingtwoquestions:

RQ1: What are the agile practices that are being commonly used to deal with

offshorechallenges?

RQ2: Are the challenges identified in RQ1 recurring in offshore software

development?

As mentioned earlier this type of research strategy involves Systematic Literature

Reviews. To identify patterns in offshore software development we conducted the

second Systematic Literature Review following Kitchenham and Charters guidelines,

which isStep3:CollectData fromLiteratureReviewand Interviews.Toconduct this

step we searched for papers that are written in English and that where available

online. The search strategy includes electronic databases and manual searches of

conferenceproceedings.Thefollowingelectronicdatabasesareused:

• IEEEXplore(www.ieeexplore.ieee.org/Xplore)

• ACMDigitalLibrary(www.portal.acm.org/dl.cfm)

• GoogleScholar(www.scholar.google.com)

• ElsevierScience(www.sciencedirect.com)

113

• AISeLibrary(www.aisel.aisnet.org)

• SpringerLink(www.springerlink.com)

• TaylorFrancisOnline(http://www.tandfonline.com)

Wealsosearchedthefollowingconferenceproceedingsforthepapersontheuseof

Agileinoffshoresoftwaredevelopment:1)AgileConferenceand2)AgileProcessesin

Software Engineering and Extreme Programming. The papers ranged from industrial

experience reports, theoretical,empiricalandexperimentalacademicpapers. Figure.

3.3,showsthereviewprocessandthenumberofpapersidentifiedateachstage.

Figure.3.3.TheSelectionProcessofPrimaryPapers.

WedesignedTable3.3basedonourkeyconceptsselectedinTable3.2.Instage1,we

selectedthedatabasesusingthesearchitemslistedinTable3.3.Category1hasmore

keywords and shows many variations of the same term “Global Software

Development”. All these search items were combined using the Boolean “AND”

operator,whichrequiresthatanarticlethatfocusesonbothAgileandGlobalSoftware

Development,willberetrieved.Hencewesearchedeverypossiblecombinationofthe

keywords fromCategory Type 1 AND Category Type 2. Our search excluded articles

114

that addressed editorials, prefaces, article reviews, discussion comments, news, and

summaries of tutorials, workshops, panels and poster sessions. The search strategy

resultedinatotalof6614“hits”.

Table3.3.SearchTermsusedinthisReview.

Type Category Keywords

1 GlobalSoftwareDevelopment GlobalSoftwareEngineering

GlobalSoftwareDevelopment

OffshoreSoftwareDevelopment

Offshoring

DistributedSoftwareDevelopment

DistributedDevelopment

2 UseofAgilePractices Agile

Agilepractices

Agilemethods

Scrum

XP

We used the following screening criteria to ensure that the papers addressed our

researchtopic:

1. Doesapaperaddressachallenge inapplyinganyAgilePractice indistributed

projects?

2. Does a paper discuss any real life experience of using Agile practices for

distributedprojects?

3. IstheiranyAgilePracticethathasbeenrepeatedlyadaptedandusedtosolve

issueswithdistributedprojects?

115

Inour studywealsocollectedsecondarydatabyconsidering“lesson learnt” reports

based on expert opinion that addressed how Agile practices are used in offshore

projects.These3pointsprovidedameasureoftheextenttowhichweareconfident

that a selectedpaper couldmakea valuable contribution tounderstand the current

useofAgilepracticesindistributedsettingsandtoidentifyrepeatingpracticesthatare

being used to solve offshore problems. Each of the 3 criteria was graded on a

dichotomous(“yes”or“no”)scale.

Weselected212papersoutof544articlesbycarryingoutaqualityassessmentbased

onthe3screeningcriteria.Weacceptedapaperthatsatisfiedall3criteriaandgraded

asall“yes”.Forexampleweexcludedpapersthatdidnotshowanagilepracticebeing

used to solve a repeatedly occurring problem. For example, if an organisation used

split pair programming teams but no other organisation used it for better code,we

didn’tincludethataspartofourcatalogue.Inourresearchwehaveclassifiedanagile

practiceasadistributedagilepattern if ithasbeenrepeated inmorethanat least2

articlesandhasbeenusedtosolvearecurringproblem.

In the Table 3.4, we have shown how many times an agile practice occurred in

literature for example synchronous communication practices occurred in over 200

paperswhile collective planning poker activity occurred in 10 papers. Based on the

frequencyofapracticeweidentifiedpatterns.

Table3.4.OccurrenceofAgilePracticesinLiterature

116

Wealso used case study strategy for our research as according to Yin, a case study

examines a phenomenon in its natural setting, to answer how and why questions

whentheresearcherhaslittlecontrolovertheevents.Thecasestudymethodcovers

both the phenomenon of interest and its content, resulting in producing a larger

numberofpotentiallyrelevantvariables.

According to Yin six sources of evidence should be used for data collection for case

study,whichareshowninTable3.5(Yin,2003).

Table3.5.SixSourcesforDataCollectionComparison(Yin,2003).

No. DataSource Advantage Limitation

1. Interviews • In-depthknowledge

andcanextract

requiredinformation.

• Biasduetopoorly

constructedquestions.

• Responseisbias.

• Inaccuratedata,dueto

poorrecallofeventsby

theresearcher.

2. Documents • Broadcoverage.

• Unobtrusive-not

createdasaresultof

thecasestudy.

• Biasedselectivityif

collectionisincomplete.

• Accessmaybe

deliberatelyblocked

• Reportingbiasesbased

ontheauthors’bias

reflection.

3. ArchivalRecords • Preciseand

quantitative.

• Broadcoverageof

data.

• Notcreatedasaresult

• Accessibilityblockeddue

toprivacyissues.

• Biasedasitisbasedon

theselectionofthe

researcher.

117

ofthecasestudy.

4. DirectObservation • Coverseventsinreal-

time.

• Focusedoncovering

thecontextofthe

event.

• Timeconsuming

• Addedcostbasedonthe

hoursneededbythe

humanresource.

• Eventsmaytakeplace

differentlyastheyare

beingobserved.

5. Participant

Observation

• Insightfulin

understanding

interpersonal

behaviourandmotives.

• Eventsarecoveredin

real-time.

• Eventsarefocusedon

context.

• Biasedasitisbasedon

theresearchers

manipulationofresults.

• Timeconsuming.

• Addedcostduetothe

hourshumanresource

spendontheresearch.

6. PhysicalArtefacts • Insightfulintocultural

features.

• Insightfulin

understanding

technicaloperations.

• Selectivity-asitdepends

ontheresearcherwhat

heselects.

• Dependsonthe

availabilityofthe

artefacts.

Eachsourceofdatahasitsadvantagesandlimitations.Forthisresearchwehaveused

interviewsandarchival records.According toEasterby-Smithet al. (2012) interviews

arethebestmethodofgatheringinformation.Therearethreetypesofinterviews:

118

Table3.6.TypeofInterviews(Easterby-Smithetal.,2012).

No. Type Definition

1. FullyStructured

Interview

Usequestionnairetopredefinethequestionsasstandardof

research.

2. Semi-

Structured

Interview

Theresearcherhasalistofthemesandquestionsthatcover

thephenomenonunderstudy.Howeverthesequestionscan

change based on the answers given by the interviewee in

order to get more clarification (Robson, 2002; Saunders,

2007).

3. Unstructured

Interview

Thisisusedtoexploreindepthageneralareaofinterestfor

theresearcher.Thebasicobjectiveistoputtheinterviewee

ateaseandallowthemtoexpressthemselves.

We conducted 20 semi-structured interviews to collect primary data, in which we

askednineopen-endedquestionscoveringdifferentaspectsofoffshoring inorderto

get expert opinion regarding the practices. According to Easterby-Smith semi-

structuredinterviewsareappropriatewhen(Easterby-Smithetal.2004):

• Theresearcherwantstounderstandwhatconstructsthe intervieweeusesas

basisforhisbeliefsandopinionaboutthephenomenonunderstudy.

• Aim is tounderstand the“respondent’sworld”, so that the researchermight

influenceitandchallengeit.

• Step by step logic is not clear, that is some information be confidential or

sensitiveandtheintervieweemightbereluctanttosharethetruesituation.

Jankowicz suggested that semi-structured interviews are a powerful data collection

technique when used in case study (Jankowicz, 2005). The reason for using semi-

structuredinterviewsinthisresearchisbecauseitprovidesflexibilitytotheresearcher

119

tomodify the questions in order to understand the phenomenon under study. The

sampleusedtoconductthesemi-structuredinterviewsispresentedinAppendixD.We

alsosignedconsentformfromtheorganisationsweinterviewedduetoconfidentiality

issues,whichisavailableinAppendixE.Thecompaniesweinterviewedwereselected

based on their experience in offshoring and as mentioned in Table 3.7 we further

divided them into three categories based on the organisational type, which are

startup, breakeven and profitable. Companies that are still in their early stages of

earning revenue and have not yet reached breakeven are categorized as startup;

companiesthathavereachedbreakevenbasedonfinancesasbreakevenandlastlythe

companiesthataregeneratingprofitasprofitable.Table3.7showsanoverviewofthe

organisationsthatwereselected.

Table3.7.DetailofCompaniesInterviewed.

Category Experienceinoffshoring

(years)

Offshore

Projects

No.Of

Companies

Startup

Breakeven

Profitable

1-2

>3

>5

3

8-9

>10

4

6

10

Basedonthecollecteddata,wemovedtowardsStep4:AnalysingDataCollectedfrom

Literatureand Interviewswhichhasbeendiscussed inSection3.3.2,basedonwhich

we identified 15 distributed agile patterns that is Step 5: Design and Develop

Distributed Agile Patterns Catalogue. We validated the catalogue using an action

research technique, which is Step 6: Validate and Evaluate the Distributed Agile

PatternsCatalogue,ofourresearchmethodology.

We conducted a reflection workshop based on Kerth’s “The keep/try reflection

workshop” for verification and validation of the catalogue. For this workshop we

invitedfourorganisationstotakepart(Kerth,2001).Thefocusofthisworkshopwasto

getfeedbackfromcompaniesinordertoobtaintheirviewsontheidentifiedpatterns.

Basedontheiranswers,anassessmentwasaimedforidentifyingthecompletenessof

120

the catalogue and the usefulness of the identified patterns in adopting agile for

developing offshore projects and overcoming offshore challenges. Detail of the

validationandevaluationprocesshasbeenpresentedinChapter5.

3.3.4Choice

The choice outlined in the research onion mentioned in Table 3.1 includes three

methods,whicharemonomethod,mixedmethodandmulti-method.Weselectedto

usemulti-methodapproachtoconductourresearchasweusedbothquantitativeand

qualitativemethods for determineour results. Themain differencebetweenmixed

method andmulti-method approach is that is provides the researcherwith awider

selectionofmethodstouse(Bryman,2012).

Inmulti-method researchers can divide their research into separate segments, with

each segment producing a specific dataset; each is dataset is then analysed using

techniquesderivedfromquantitativeorqualitativemethodologies(Felizer,2012).

AsmentionedinSection3.3.4wehaveusedbothquantitativeandqualitativemethods

forcollectingandanalysingthedata.InStep3andStep4ofourresearchmethodology

showed in Figure 1.1ResearchMethodology,we startedwith reviewing the existing

literature(Step1)fromwhichtheresearchquestionswereformulated(Step2)based

on which we conducted systematic literature review and interviewed practitioners

(Step3)andthenanalysedthecollecteddata(Step4).Table3.8showsanoverviewof

thequantitativeandqualitativemethodsusedinthisresearch.

Table3.8.OverviewoftheQuantitativeandQualitativeMethodsUsedinthis

Research.

No. MethodType UsedintheResearch

1. Quantitative

Methods

Step1:ReviewPreviousLiterature.

Step3:CollectDataFromLiteratureReviewandInterviews:

121

- SystematicLiteratureReview(SLR).

Step6:ValidateandEvaluatetheDistributedAgilePatterns

Catalogue:

- Forevaluation:Filter theSLRto identifysolutions

other than patterns and compare how the

Distributed Agile Patterns catalogue is a

comparativelyabetterandeasysolution.

2. Qualitative

Methods

Step3:CollectDataFromLiteratureReviewandInterviews:

- Semi-StructureInterviews.

Step 4: Analysing Data Collected from Literature and

Interview:

- ContentAnalysis(RelationalAnalysis).

Step 5: Design and Develop Distributed Agile Patterns

Catalogue:

- Filtering the studies identified in the SLR to

identify:

o Solutions for offshore software

developmentchallenges(FSD).

o Recurring agile solutions for adoption

practicesinoffshoring.

o Patternsinagileadoptioninoffshoring.

Step6:ValidateandEvaluatetheDistributedAgilePatterns

Catalogue:

- For validation: Kerth’s, “The keep/try reflection

workshop”.

- Evaluationofthecataloguewasdonebyreviewing

existing work done on designing solutions other

122

thenpatterns,toovercomeoffshoredevelopment

challenges

3.3.5TimeHorizon

TheTimeHorizonisdefinedasthetimeframewithinwhichtheintendedresearchisto

be completed in. There are two types of time horizons inwhich research is usually

conductedwithin,whicharecrosssectionalandthelongitudinal(Bryman,2012).For

thepurposeof this research the timehorizon is cross sectional as this researchwas

conductedaspartofaPhDThesisandwehadafixtimedurationfordatacollection.

HoweversincethedurationofthePhDwas4-yearswehadtheflexibilityondeciding

whenthedatacollectionshouldtakeplacebasedontheprogressoftheresearch.

Table 3.9 shows the time frame inwhich the researchmethodologywas conducted

duringthecourseofthefouryearsofPhDResearch.

Table3.9.TimeHorizonacrossFour-YearPhDResearch.

No. PhDYear ResearchMethodologyStepConducted

1. Year1(2013) Step1:ReviewPreviousLiterature.

Step2:IdentifyandDefineResearchProblem.

2. Year2(2014) Step3:CollectDataFromLiteratureandInterviews.

Step4:AnalysingDataCollectedfromLiteratureand

Interviews.

3. Year3(2015) Step5:DesignandDeveloptheDistributedAgilePatterns

Catalogue.

4. Year4(2016) Step6:ValidateandEvaluatetheDistributedAgilePatterns

Catalogue.

123

Step7:ModifytheCataloguetoImprovetheResults.

Step8:WriteupthePhDThesis.

3.3.6DataCollection

Thedatacollectionandanalysisapproachisdependentontheresearchmethodology

a researcher decides to use (Bryman, 2012) which is Step 3: Collect Data From

LiteratureReviewand Interviews,ofour researchmethodology in Figure1.1. There

arebasicallytwomainapproachesthroughwhichdataiscollectedwhichareprimary

andsecondarydatacollectiontechniques.

Inthisresearchwehaveusedbothprimaryandsecondarytechniquestocollectdata.

Weusedsemi-structureinterviewsastheprimarysourceofinformationasitallowed

us to discuss in detail the factors the participants considered to affect the

development process and how they had been adapting agile practices for their

offshore projects. The interviews were open ended, allowing us to probe for more

informationandgaveustheflexibilityof rephrasingquestionsandsimplifyaspecific

question if it was too complex for the participant to understand. The detail of the

interviewhasbeenpresented inSection3.3.3andthe listofquestionsaskedcanbe

foundinAppendixD.

Forsecondarydatawestudiedover200cases from literature to identifypatternsof

how practitionerswere adapting agilemethods for distributed agile projects and to

identify specific challenges in offshore development we conducted systematic

literaturereview,detailshavebeenpresentedinSection2.3andthestudiesthatwere

selectedasevidencearepresentedinAppendixA.

124

3.4ChapterSummary

Inthischapterwepresentedtheresearchmethodologyusedtoconductthisresearch.

We first gave an overview of Saunder’s research onion and then applied it on our

researchmethodologyasthishelpeduspresentourmethodologyinasystematicway.

Theresearchmethodologywaspresentedinsixstages,whichareresearchphilosophy,

researchapproach,researchstrategy,choice,timehorizonanddatacollection.

In thenext chapter,wehavepresentedourdistributedagilepatterns catalogueand

howpractitionerscanuseit.

125

Chapter4 DistributedAgilePatterns

4.1Introduction

In this section we present the distributed agile patterns that were identified from

systematicliteraturereviewandsemi-structuredinterviews.Wealsopresenthowthe

template for thedistributedagilepatterns is designedanddemonstrate theprocess

through which practitioners can choose which pattern is suitable. Further the

catalogue is divided into four categories such as management, communication,

collaborationandverification,basedonwhattypeofchallengethepatternsolves.The

distributedagilepatternsarethenmappedontothetraditionalscrumlifecycletohelp

practitioners choose patterns based on what functionality they want to perform.

Lastlythefulldistributedagilepatternscatalogueispresented.

4.2DesigningTemplateforDistributedAgilePatterns

Patterns are described using a standard format in order to provide structured

informationthatmakesthemeasiertounderstandandcompare.InTable4.1wehave

providedacomparisonbetweentheexistingdifferenttemplatesthatareusedforthe

patternsmentionedinChapter2(Robertson,1996;Fowler,1997;Gammaetal.,1997;

Buschmann et al. 1996; Brown et al. 1998) such as requirement, analysis, design,

architectural, anti-patterns and idioms. The purpose of this comparison is to

understandwhatarethekeycomponentsrequiredfordocumentingapattern.

Table4.1.ComparisonofExistingPatterns.

Requirement

Patterns

Analysis

Patterns

Design

Patterns

Architectural

Patterns

AntiPatterns Idioms

Name

Name

Name

Name

Name

Name

126

Context

Solution

Related

Patterns

Alsoknown

as

Evolution

Structural

Adjustment

Problem

Motivation

Context

Applicability

Requireme-

nts

Modelling

Consequen-

ces

Example

Knownuses

Intent

Alsoknown

as

Motivation

Applicability

Structure

Participants

Collaborat-

ion

Consequen-

ces

Implement-

ation

Sample

Code

Knownuses

Related

Problem

Category

Context

Solution

Rational

Consequence

Example

Knownuses

Related

Patterns

Problem

Context

Solution

Consequence

Design

Rational

Example

RelatedAnti

Patterns

Intent

Also

known

Motivati-

on

Solution

Sample

Code

Known

uses

127

Related

Patterns

Patterns

From the above table we can see that all the current templates cover detail

descriptionsofaproblemanditssolution.Asonlygraphicalnotationsaren’tsufficient

to capture the process of an end product, in order to reuse a solutionwe need to

recordall thedecisions that lead to formapattern.Similarlywecanseeallof them

have put in sample code or example section as they help in understanding how a

patterncanbeusedinpracticalscenarios.

In this research, the proposed catalogue is developed based on literature and

interviews and we have used Gamma’s pattern template in order to preserve

familiarity, as they are perceived as the first pattern catalogue documented by the

software community. A customised template was then developed to capture the

specific findings related todistributedagilepractices. Thedistributedagilepatterns

templatecontainsthefollowingsections:

• Pattern Name: As patterns represent generic knowledge it is vital to give a

goodname thatwouldmake it recognizableand reusable.Agoodnamealso

helpsinfacilitatingcommunicationamongpractitionersaboutthepattern.

• Intent: A short statement that highlights the issues and problems that are

requiredtobesolvedbyapplyingthepattern.

• AlsoknownAs:Thepattern’sotherwell-knownnames,ifanyarementionedin

thissection.

• Category: Based on the similarities of the patterns we grouped them into

differentcategoriestobeabletoprovideanabstractviewofallthepatterns.

128

• Motivation: Itconsistsofthedescriptionoftheproblemandwhythepattern

should be used in order to avoid the problem from recurring. It provides

scenariosthathelpunderstandtheabstractdescriptionofthepattern.

• Applicability:Underwhatconditionsthepatterncanbeapplied.

• Participants: The participants are those people that are required in applying

thepattern.

• Collaboration: How participants will coordinate with each other in order to

fulfiltheirresponsibilitiesthatarerequiredtocompletetheprojects.

• Consequences: Discuss the trade-offs of applying the patterns such as

advantagesanddifficultiesfacedwhenapplyingit.

• Knownuses:Examplesofrealscenariosfoundthatfollowthepatterninorder

toprovideclarityofhowthepatterncanbeused.

• RelatedPattern:Listofsimilarpatternsinordertoidentifywhichpatternscan

beusedtogethertoimproveaparticularsituation.

4.3SelectingtheRightPatternfromtheDistributedAgilePatternsCatalogue

Basedon the identifieddistributedagilepatternsandhowwehaveorganised them.

We have developed a process throughwhich practitioners can selectwhich pattern

wouldhelpthemwhilechoosingtodeveloptheirsoftwareoffshore.Followingarethe

stepsthepractitionershouldfollowinordertoselectadistributedagilepattern:

• To provide ease to the practitioners we have used names similar to agile

practices, forexample, ifthepractitionerwantstousetheagilepracticedaily

standup meeting, he can look for Pattern Name Local StandupMeeting for

129

distributeddevelopmentor formore clarificationhe can lookatAlso Known

As,whichisDailyScrummeetingordailymeeting.Anotheralternativestarting

pointcanbeselectingwhichpatternthepractitionerwantstousebasedonthe

Category the practitioner wants to solve. For example, if they are facing

management issues, they can start by looking at the patterns that solve

management problems such as distributed scrum of scrum, local standup

meeting, local sprint planning, local pair programming and asynchronous

retrospective.

• After shortlistingapattern thepractitioner, can furtherunderstandwhat isa

pattern does by reading the Intent, as it highlightswhat issues and how the

patternsolvesit.

• To understand in detailwhat problem a pattern solved andwhat is the best

wayofapplyingit,thepractitionershouldreadtheMotivationnext.

• Every pattern has some advantages and some limitations. In order to clearly

understand them the next section the practitioner should read is

Consequences.

• Tounderstandunderwhichconditionsapatternisapplicableandwhoshould

participate and how while applying a pattern, the practitioner should read

Applicability,ParticipantsandCollaborationsections.

• Togetmoreinformationonhowexistingorganisationsandpractitionershave

usedthispattern,thepractitionercanreadKnownUses.

• IfthepractitionerwantstofindpatternsthatarerelatedtheycanreadRelated

Patternssection.

Figure 4.1 shows the follow of how the practitioner should read a distributed agile

pattern inorder toselectapattern fromthedistributedagilepatternscatalogue for

130

theiroffshoreprojects.Apractitionercaneitherstartbyreadingapatternsnameorby

the category aswe have divided our pattern catalogue into four categories such as

management,communication,collaborationandverificationpatterns.Thecategories

helpthepractitionerindecidingwhichtypeofchallengetheywanttoovercome.

Figure4.1.ProcessofselectingpatternsfromtheDistributedAgilePatterncatalogue.

The distributed agile patterns are spread across the Scrum software development

lifecycleasshowninFigure4.2.Thepractitionercanpickandchosewhicheverpattern

hewouldliketoapplyandwhicheverScrumphase.Thepatternsnamesarewrittenin

redandtheblueboxunderthemshowsonwhichscrumpracticesthedistributedagile

patterncanbeapplied.

Figure4.2.DistributedAgilePatternsApplicationonTraditionalScrumLifecycle

131

4.4OrganisingtheDistributedAgilePatternsCatalogue

Distributed agile patterns vary in their granularity and level of abstraction. Because

there aremany distributed agile patterns, we have organised them in 4 categories,

whicharemanagement,communication,collaborationandverificationpatterns.This

classificationhelpsinlearningandidentifyingwhichpatternistobeusedinaspecific

scenario.We have classified distributed patterns based on the problem they solve.

Followingarethedefinitionofthe4categories:

• ManagementPatterns:As inoffshoringtheteamisdistributedoverdifferent

time zones, it isdifficult tomanageall thedistributed teammembersandas

theyareworkingondifferentmodulesoftheprojectitisdifficulttodetermine

the overall progress of the project. In order to handle this problem we use

management patterns as they consist of practices that help inmanaging the

onshore and offshore teammembers and their activities to effectively apply

agileinadistributedenvironment.

• Communication Patterns: Since the team is distributed geographically over

different time zones they have minimum overlapping working hours, which

makes it difficult tomaintain real time communication between the onshore

and offshore team members. Communication patterns focus on providing

solutions to how distributed team members can maintain an effective

communication channel in an agile setting using different online toolswhich

providebothsynchronousandasynchronousmethodforcommunication.

• CollaborationPatterns:Evenifthenatureoftheprojectisoffshoring,thereis

stillaneedtoconductsomecollectiveteamactivitiesinordertoimprovethe

coordinationamongtheonshoreandoffshore teammembers.Because if the

onshoreandoffshoreteammembersdon’tmeeteachotheritcreatesmistrust

and misunderstanding among the team members, which affects the overall

team’sproductivity. Inordertosolvethis issuecollaborationpatternsprovide

132

solutions regardingwhich activities theonshore andoffshore teammembers

shouldconducttogethertoimproveteamcoordinationandprojectprogress.

• Verification Patterns: As in agile we focus on building the right product

according to the satisfaction of the client. But as the team is distributed on

differentlocationsitisdifficulttosetastandardguidelineforallthedistributed

developmentsitesandhowtoshowprojectprogresstotheclient.Inorderto

solve thisproblemverificationpatterns focusesonhowefficiently the clients

can get a distributed project developed according to their requirements and

monitortheprogressofwhathasbeendeveloped.

Table4.2.CategoriesofDistributedAgilePatterns.

Category

Management

Patterns

Communication

Patterns

Collaboration

Patterns

Verification

Patterns

Pattern

Names

Distributed

ScrumofScrum

LocalStandup

meeting

LocalSprint

Planning

LocalPair

Programming

Asynchronous

Retrospective

GlobalScrumBoard

CentralCode

Repository

Asynchronous

InformationTransfer

Synchronous

Communication

Collaborative

PlanningPoker

Follow-the-sun

Collective

ProjectPlanning

Visit onshore-

offshore

ProjectCharter

Onshore

Review

Meeting

133

4.5FullDistributedAgilePatternsCatalogue

In this section we have presented our full finalised Distributed Agile Patterns

Catalogue.Inordertoavoidcausingconfusionforthereaderwepresentedtheoriginal

unrevisedpatternsinAppendixF.

4.5.1ManagementPatterns

Inthissectionwehavedescribedthedetailofeachmanagementpattern.

4.5.1.1 DistributedScrumofScrumPattern

In agile methodology, Scrum is an iterative and incremental project management

approachthatprovidesasimpleframeworkthat“inspectandadapt”(Hossain,Babar,

andPaik,2009).Weobservedthatinoffshoreprojectstheonshoreandoffshoreteam

practices separate scrums in order to develop the project. Based on this observed

practicewehavedesignedthefollowingpatterndetails:

PatternName

DistributedScrumofScrumPattern

Intent

To apply scrum, sub-teams are formed based on location. Each team has its

ownscrum.Scrumofscrummeetingsarearrangedtodiscusstheprogressof

theproject,whichisattendedbykeypeople.

AlsoKnownAs

ScrummeetingorMetaScrum

134

Category

Management category as this pattern helps the onshore and offshore team

manage their separate scrums and keep each other updated of the project

progress.

Motivation

The motivation of this pattern is to address the communication and co-

ordination, and knowledge transfer challenges. For example consider a team

that is divided into sub-teams based on location and they are working on

different tasks of a project. It is difficult to have both onshore and offshore

teamworkonthesamescrumastheybothworkondifferenttimezonessoin

ordertoworkonthesameproject,bothteamsworkonseparatescrums.

To coordinatework both teams arrange a scrum of scrummeeting,which is

attendedbykeypeoplefrombothteamstoupdateeachotheroftheprogress

oftheproject.

Applicability

UseDistributedScrumofScrumwhen:

• Teamisdistributedoverdifferenttimezones.

• Theoverlappingworkinghoursbetweentheonshoreandoffshoreteam

isless.

Participants

• Distributedonshoreandoffshoreagileteam.

• ScrumMastersofagilesub-teamsandProductowner.

Collaboration

• Keymembers fromonshoreandoffshore teamsdecide time forScrumof

Scrummeeting.

135

Consequences

The Distributed Scrum of Scrum pattern has the following benefits and

liabilities:

1. It prevents the onshore and offshore team from wasting time on

collaborating tasks with each other through online tools as both the

teamsareworkingon theirownscrumso theydon’thave towait for

eachothertocompletetasks.Thishelpsovercomethecommunication

andcoordinationchallenges

2. Itprovidescontroltobothonshoreandoffshoreteamtoworkontheir

scrum,whichavoids theoffshore team fromhaving to adjustworking

hours based on onshore teams availability. This helps overcome the

communicationandcoordinationchallenges.

3. It allows key people such as Scrum Masters and Product owners’ to

discuss the progress of the project without having the whole team

presentwhich keeps themeeting timeboxed andhelps in knowledge

transferamongtheteams.

4. Its limitation is that due to minimum collaboration between the

onshore and offshore team, both sub-teams don’t feel they are one

team.

5. SinceonlykeypeopleattendtheScrumofScrummeeting,itlimitsface-

to-face interaction of both onshore and offshore team, which affects

trustbuildingbetweenbothteams.

Knownuses

WhenCheckFreedecidedtomovetheirworktoanIndianoffshoreconsulting

firmtheyusedScrumofScrumtogatherandreviewtheoverallteamstatistics

andprogressoftheproject(Cottmeyer,2008).Similarly,multiplecasestudies

136

done on organisations using Scrum for distributed teams also used Scrumof

Scrumtocoordinateworkwithoffshoreteam(Hossainetal.,2009;Paasivaara

et al., 2009). Siemens also used Scrum of Scrum for two large distributed

projects in which the development teams were located in USA, Europe and

India.IntheirScrumofScrummeetingstheycoveredtechnicalandmanagerial

issuesthatoccurredinmultipleteams(Avritzeretal.,2010)

RelatedPatterns

Distributed Scrum of Scrum pattern is often used with Local Sprint Planning

PatternandAsynchronousRetrospectivemeetingPatternas theonshoreand

offshore teammembers areworking on different story cards and at the end

havetheirseparateretrospectivemeetingstodiscussthesprint

4.5.1.2 LocalStandupMeeting

Agilemethodologyfocusesonconductingadailystandupmeeting.Weobservedthat

inoffshoreprojectstheonshoreandoffshoreteamconducttheirownseparatedaily

standupmeetingsanduseonlinetoolssuchasWiki’stosharemeetingminuteswith

eachother.Basedon thisobservedpracticewehavedesigned the followingpattern

details:

PatternName

LocalStandupMeetingPattern

Intent

Todiscussdailyupdatesonworkdone,eachlocalteamwillconducttheirown

standupmeetings.

AlsoKnownAs

DailyScrummeetingordailymeeting

137

Category

Management category as this pattern helps the team members of both

onshoreandoffshoreteammanagetheirdailyactivitiesandupdateeachother

withtheworkdone.

Motivation

The motivation of this pattern is to address the communication and co-

ordination,andknowledge transferchallenges. Forexampleconsidera team

thatisdividedintosub-teamsthatarelocatedondifferenttimezones.Tohave

a collaborative daily standupmeeting is difficult and time consuming as the

offshore team either has to come early to work or stay late to attend the

meeting.Toavoidthis,theonshoreandoffshoreteamconductsseparatelocal

standupmeetingsinwhichtheyanswerthefollowingquestions:

o Whatdidyoudoyesterday?

o Whatareyoudoingtodotoday?

o Whatisgettinginyourway?

After conducting local standup meetings both onshore and offshore team

share,meetingminutesviaonlinetoolssuchasWiki’stokeepboththeteams

uptodatewiththeprogressoftheproject.

Applicability

Uselocalstandupmeetingwhen:

• Teamisdistributedoverdifferenttimezones.

• Theoverlappingworkinghoursbetweentheonshoreandoffshoreteam

isless.

Participants

• Distributedonshoreandoffshoreagileteam.

138

Collaboration

• Both onshore and offshore team share-meetingminuteswith each other

usingonlinetools.

Consequences

Thelocalstandupmeetingspatternhasthefollowingbenefitsandliabilities:

1. It prevents the offshore team from waiting for the onshore team’s

availabilitytoconductthedailystandupmeeting.Thishelpsovercomethe

communicationandcoordinationchallenges.

2. It allowsbothonshore andoffshore team flexibility to conduct their own

standup meeting at whichever time they want. This helps overcome the

communicationandcoordinationchallenges.

3. Itallowstheonshoreandoffshoreteamtotransferknowledgebysharing

meetingminuteswitheachother.

4. Itlimitstheonshoreandoffshoreteamfromreal-timecommunicationand

bothteamheavilyrelyonthemeetingminutessoanymistakecanleadto

misunderstandingintheprogressoftheproject.

Knownuses

OrganisationssuchasPulpCo(Paasivaaraetal.,2009)andWiproTechnologies

(Sureshchandraetal.,2008)uselocalstandupmeetingsforcommunicatingthe

progressoftheprojectwithteammembers.

RelatedPatterns

DailyStandupmeetingpattern isoftenusedwithGlobalScrumBoardPattern

as once the onshore and offshore team members have conducted their

meetingstheysharethemeetingminutesonasharedtoolsothatbothcansee

theprojectprogress.

139

4.5.1.3 LocalSprintPlanningMeetingPattern

Inagile,ascrumconsistsofmanysprints.Thedurationofasprintvariesfrom2weeks

to4weeksdependingonthesizeoftheproject.Atthestartofeverysprinttheteam

has a sprint-planningmeeting inwhich the team defines the goal of the sprint and

prepare the sprint backlog. When the team is divided and is working on different

modules of the project it has been observed that the onshore teammembers and

offshoreteammembersconducttheirownseparatesprintplanningmeetings.Based

onthisobservedpracticewehavedesignedthefollowingpatterndetails:

PatternName

LocalSprintPlanningMeetingPattern

Intent

Eachteamwillhavetheirownsprintplanningmeetings

AlsoKnownAs

SprintPlanningMeetingorIterationMeeting

Category

Management category as this pattern helps the onshore and offshore team

work on their separate module and conduct independent scrum and sprint

planningmeetings.

Motivation

The motivation of this pattern is to address the communication and co-

ordination,andknowledgetransferchallenges.Forexamplewhenaprojectis

distributedtoateamthatisdividedoverdifferenttimezones,andareworking

ondifferentmodulesoftheprojectandareconductingtheirownscrums. As

the onshore and offshore teams conduct their separate scrums, they also

conduct separate sprint planningmeetings to decide what they will develop

140

during a sprint. Both teams prepare their sprint backlogs, which are shared

usingonlinetools.

Applicability

UseLocalSprintPlanningMeetingpatternwhen:

• Team is distributed over different time zones and is working on

differentmodules/subsystemoftheproject.

Participants

• Distributedonshoreandoffshoreagileteam.

Collaboration

• Theonshoreteamandoffshoreteamsharesprintbacklogwitheachother

toshowtheworktheywillbedoingoverthenextsprint.

Consequences

TheLocalSprintPlanningMeetingpatternhasthefollowingbenefitsandliabilities:

1. It allows both teams to work independently without having to wait for the

onshore teamtobeavailable toconduct themeeting,whichhelpsovercome

thecommunicationandcoordinationchallenges.

2. Itprovidescontroltobothonshoreandoffshoreteamtoworkontheirscrum

and conduct their own sprint planning meetings, which avoids the offshore

team from having to adjust working hours based on the onshore team

availability. This helps overcome the communication and coordination

challenges.

3. Both teams can share their sprint backlog with each other, which provides

visibility of the project progress and helps overcome the knowledge sharing

challenges.

141

4. Asboththeteamsareworkingindependentlyitcancausetheteamstofeel,as

they are not part of one team, rather create an effect that they are two

separateteams.

Knownuses

WhenCheckFreedecidedtomovetheirworktoanIndianoffshoreconsulting

firm they used local sprint planning meetings to plan their sprint activities

(Cottmeyer,2008).

RelatedPatterns

Local SprintPlanningPatterns inoftenusedwithDistributedScrumof Scrum

Pattern and Global Scrum board Pattern as the meetings minutes of the

planningmeetingaresharedwithbothonshoreandoffshoreteammembers.

4.5.1.4 LocalPairProgrammingPattern

In agile, pair programming consists of two programmers that share a single

workstation that is they share one screen, keyboard and mouse. The programmer

usingthekeyboardisusuallycalledthe"driver",theother,iscalled“navigator”asheis

activitygivinghis remarksonthecodeandhelpingthedriver towrite thecode.The

programmers are expected to switch roles after every few minutes. It has been

observedthatwhentheteamisdividedondifferentlocations,theteammembersthat

are co-located form pairs as it is difficult to form pairs with other locations team

members due to the time difference. Based on this observed practice we have

designedthefollowingpatterndetails:

PatternName

LocalPairProgramming

Intent

Makepairprogrammingteamsfromthesamelocation.

142

AlsoKnownAs

PairProgrammingorPairedProgramming

Category

Management categoryas thispatternhelps the local teammembers to form

pairsandworkontheirstorycard.

Motivation

The motivation of this pattern is to address the communication and co-

ordination challenges. For examplewhena team is distributedoverdifferent

locationsbasedontimezones,itisdifficulttoformpairsbetweenthemdueto

thetimedifferenceinworkinghours.Soeachteamformspairsbasedontheir

locationastheyareco-locatedandcanworktogether.PairProgramminghelps

improvethequalityofcodeasinsteadofonepersonwritingthecodetheother

personischeckingthecode.

Applicability

UseLocalPairProgrammingpatternwhen:

• Team is distributedover different time zones and isworking on different

modules/subsystemoftheproject.

Participants

• Distributedonshoreandoffshoreagileteamandworkingondifferentstory

cards.

Collaboration

• The onshore team and offshore teammembers share a keyboardwith a

fellowteammemberfromtheirrespectivelocation.

Consequences

TheLocalPairProgrammingpatternhasthefollowingbenefitsandliabilities:

143

1. The offshore team members don’t have to wait for the availability of

onshore team members to start work, which helps overcome the

communicationandcoordinationchallenges.

2. Someorganisationsfeelit’sawastehavingtworesourcingworkingonthe

samething.

Knownuses

InacasestudyconductedbyMaruping(2010)onanorganisationthathadits

developmentcentersinIndia,U.SWestCoast,U.SMid-WestandU.SEastCoast

showedthatpairswheremadeonthebasesofphysicallocations.

RelatedPatterns

SinceinLocalPairprogrammingweareselectingteammembersfromthesame

location,weoftenuseitwithLocalSprintPlanningMeeting.

4.5.1.5 AsynchronousRetrospectiveMeetingsPattern

Inagile,whenateamisusingScrumattheendofeverysprintafterthesprintreview

meeting, a retrospectivemeeting is conducted which is attended by only the team

membersandthescrummaster. Inthismeetingtheteamdiscussesallthegoodand

badthingsthathappenedduringthesprintandhowtheycanimprovetheirwork.They

alsodiscussthefeedbackgivenbytheclient.Ithasbeenobservedthatwhentheteam

isdividedondifferenttimezones,teamsconducttheirownretrospectivemeeting,as

duetothetimedifferenceitisdifficulttohaveacollectiveretrospectiveattheendof

each sprint (Kamaruddin, 2012). Once both the onshore and offshore teams have

conducted their retrospective meeting they share the meetings minutes with each

other using online tools. Based on this observed practice we have designed the

followingpatterndetails:

144

PatternName

AsynchronousRetrospectiveMeetings

Intent

Teams conduct separate retrospectivemeetings based on location and share

the key information via email. The Scrum Masters discuss possible

improvementswiththeteambasedonthefeedbackfromtheclient.

AlsoKnownAs

RetrospectiveMeetingsorIterationRetrospective

Category

Management category as this pattern helps the onshore and offshore team

members to review their sprint and discuss their performance. The Scrum

Master advises the team on how they can improve their performance and

discussesthefeedbackoftheclient.

Motivation

The motivation of this pattern is to address the communication and co-

ordination, and knowledge transfer challenges. For examplewhen a team is

divided on different time zones and are working on different

modules/subsystemsofaprojectandconductingtheirownindependentScrum

andsprintsitisdifficulttohaveacollectiveretrospectivemeeting.Theonshore

andoffshoreteammembersconducttheirseparateretrospectivemeetingsto

discusswhatwentgoodandbadinthesprintandhowtheycanimprovetheir

work in the next sprint. The Scrummaster attends thesemeetings and gives

feedbackontheperformanceontheteamanddiscussestheremarksgivenin

thesprintreviewmeetingbytheclient.Oncebothteamshaveconductedtheir

retrospectivemeetingstheysharethemeetingminuteswitheachotherusing

anonlinetool.

145

Applicability

UseAsynchronousRetrospectiveMeetingswhen:

• Team is distributed over different time zones and is working on

differentmodules/subsystemoftheproject.

Participants

• Distributedonshoreandoffshoreagileteammembers.

• ScrumMaster

Collaboration

• Theonshore teamandoffshore teammemberssharemeetingminutesat

theendoftheirretrospectivemeetings.

Consequences

TheAsynchronousRetrospectiveMeetingspatternhasthefollowingbenefitsand

liabilities:

1. It allows onshore and offshore team members to conduct retrospective

meeting independentlyof eachother’s availability,whichhelpsovercome

thecommunicationandcoordinationchallenges.

2. It helps team members discuss their independent problems and doesn’t

makebothonshoreandoffshore teamtobepresent for themeetingand

cansharemeetingminutesusingonline-sharingtools.Thishelpsovercome

theknowledgetransferchallenges.

3. Sinceonshoreandoffshoreteammembersconductseparateretrospective

meetingstheydon’tunderstandeachother’sproblems.

Knownuses

ElasticPath,aVancouver,BritishColumbia-basedcompanydecidedtooffshore

theirworktoLuxsoft,anoutsourcingpartnerusedasynchronousretrospective

146

sessionstodiscussthesprintprogressandwellaswhatimprovementstheycan

make. Once all locations had conducted their retrospective meetings, they

postedcommentsandresultsonSharePoint,whichwerethenviewedbyScrum

Masterandtechnicalleadfortheirremarks(Vax,2008).

RelatedPatterns

We often used Distributed Scrum of Scrum Pattern with Asynchronous

RetrospectivemeetingPattern. It isalsooftenusedwithLocalSprintPlanning

Pattern as in order to review the progress of a sprint and the teamwe use

retrospective meeting. After all the distributed teams have conducted their

retrospectivemeetings they share themeetingminutes with each for which

theyuseGlobalScrumBoardPattern.

4.5.2CommunicationPatterns

Inthissectionwehavedescribedthedetailofeachcommunicationpattern.

4.5.2.1 GlobalScrumBoardPattern

Agile has many artefacts such as product backlog, sprint backlog, storyboard, task

board, team velocity and burndown charts which help the team in managing the

project.Ithasbeenobservedthatwhentheteamisdividedtodifferentlocationsthey

maintainaonlinerecordofalltheseartefactssothattheycansharethemwitheach

other using online tools such asWiki’s, Rally and Jira (Danait, 2005; Berczuk, 2007;

Cottmeyer, 2008). Based on this observed practice we have designed the following

patterndetails:

PatternName

GlobalScrumBoardPattern

Intent

An online-shared Scrum board, will be used by, both onshore and offshore

teamstoviewtheproductbacklog,storyboard,taskboard,burndowncharts

andotheragileartefactsusingonlinetools

147

AlsoKnownAs

ScrumBoardorAgileStoryBoard

Category

Communicationcategoryasthispatternhelpstheonshoreandoffshoreteam

communicatewitheachotherusinganonline tool tovieweachother’swork

andunderstandtheprogressoftheoverallproject.

Motivation

The motivation of this pattern is to address the trust, socio-cultural;

communication and co-ordination, and knowledge transfer challenges. For

examplewhenaproject isdistributedtoateamthat isdividedoverdifferent

timezones,andareworkingondifferentmodulesoftheproject,tosharetheir

worktheyuseanonlinetooltodisplayagileartefacts.Basedontheworkdone

by both teams it is easier to see the progress of the project and it helps

understandifthereisaproblemwithateam.

Applicability

UseGlobalScrumBoardpatternwhen:

• Teamisdistributedoverdifferenttimezones.

Participants

• Distributedonshoreandoffshoreagileteam.

Collaboration

• Theonshoreteamandoffshoreteamshareagileartefactswitheachother

toshowtheirprogress.

Consequences

TheGlobalScrumboardpatternhasthefollowingbenefitsandliabilities:

148

1. Itallowsthewholeteamtoseetherequirements,whichcreatesvisibilityofthe

projectandhelpsinovercomingtrustchallenges.Thescrumboardisdesigned

keepingthesocio-culturaldifferencesinmind.

2. It allows the onshore and offshore teams to understand the progress of the

project, which helps overcome the communication and coordination

challenges.

3. It increases the visualization of the work done by each team, which helps

overcomeknowledgetransferchallenges.

Knownuses

FAST,asearchcompanywithheadquarters inNorwaywhilebuildingasearch

applicationontopof theircoresearchplatformexperimentedwithcoupleof

onlinetoolstokeepbothteamsupdatedwiththeprogressoftheproject.They

tired XPlanner and Jira and settled for Jira, which is a web-based tool that

allowed the remote team members to view the backlog and update tasks

whenevertheywanted(Berczuk,2007).SimilarlyinastudydonebyCristalon

an organisation that has development centres across North America, South

AmericaandAsia concludedwith that theuseof a global scrumboard could

help improve the productivity of global agile teams (Cristal et al., 2008).

Similarly companies like Valtech (Danait, 2005), Telco (Ramesh et al., 2006),

BNP Paribas (Massol, 2004), Aginitys LLC (Armour, 2007) and SirsiDynix

(Sutherland et al. 2007) used online tools to share agile artefacts with their

offshoreteammembers.

RelatedPatterns

GlobalScrumboardpatternisoftenusedwithCentralCodeRepositoryPattern

astheteamsharesalltheagileartefactsandcodeusinganonlinetool.

149

4.5.2.2 CentralCodeRepositoryPattern

Inagile,whenateamisusingScrumandXP,theteammembersaredividedinpairsof

twoandareworkingondifferenttasksduringasprint.Whenataskiscompletedthe

teammemberscommittheircodetoasharerepositoryforcontinuousintegrationof

thecode. It isobservedthatevenwhentheteammembersaregeographicallyapart

they still use a share code repositorywhere they commit their code so that all the

teammembers can see the code as well as determine the progress of the project.

Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:

PatternName

CentralCodeRepository

Intent

Thewholeteamwillmaintainacentralcoderepositorysothatbothteamcan

seeeachother’scodeandseetheprogressoftheworkdone.

AlsoKnownAs

SourceCodeRepositoryorGlobalBuildRepository

Category

Communicationcategoryasthispatternhelpstheonshoreandoffshoreteam

members to write code and share it on a central code repository where all

teammemberscanseethecodeandedititifrequired.

Motivation

The motivation of this pattern is to address the communication and co-

ordination, and knowledge transfer challenges. For examplewhen a team is

divided on different time zones and are working on different

modules/subsystemsof aproject theyusea central code repository to share

theirworkwithallteammembers.TheycanuseonlinetoolssuchasGitHubfor

committing their codeandmaintainversionsof theproject (Räty,2013).This

150

helps the whole team to see the code and provides visibility of the project

progress.

Applicability

UseCentralCodeRepositorywhen:

• Team is distributed over different time zones and is working on

differentmodules/subsystemoftheproject.

Participants

• Distributedonshoreandoffshoreagileteammembers.

Collaboration

• The onshore team and offshore teammembers share a keyboardwith a

fellow team member from their respective location and once they have

finishedatasktheycommittheircodetoacentralcoderepository.

Consequences

TheCentralCodeRepositorypatternhasthefollowingbenefitsandliabilities:

1. It allowsonshoreandoffshore teammembers tovieweachother’s code,

whichhelpsovercomecommunicationandcoordinationchallenges.

2. Ithelps indeterminingtheprogressof theproject,whichhelpsovercome

knowledgetransferchallenges.

3. As all the team is committing to a central repository, if a team commits

codewitherrorsitcanaffectthewholebuildoftheproject.

Knownuses

WDSGlobalisaleadingglobalproviderofknowledge-basedservicestomobile

operators, manufacturers and application and sales channels. In 2004 they

combinedtheirdevelopments,whichwere located inUK,USAandSingapore.

151

They shared their codeona central code repository tominimizeduplications

andreducecostofmaintenance(Yap,2005).Manycompaniesusecentralcode

repositoryfortheirdistributedprojectssuchasExtolInternational(Kussmaulet

al., 2004), Valtech (Danait, 2005), Manco (Ramesh et al., 2006), Aginity LLC

(Armour,2007),SirsiDynix (Sutherlandetal.,2007),CEInformant (Bose,2008)

andABCBank(Modietal.,2013).

RelatedPatterns

CentralCodeRepositorypatternisoftenusedwithGlobalScrumBoardPattern.

4.5.2.3 AsynchronousInformationTransferPattern

Agile emphases on close face-to-face communication between the team members

rather than detailed documentation. When a team is distributed on different time

zones it has been observed that the teams adopted asynchronous tools for sharing

information with each other such as emails, wikis and SharePoint. Based on this

observedpracticewehavedesignedthefollowingpatterndetails:

PatternName

AsynchronousInformationTransfer

Intent

Duetothetimedifferencebetweentheonshoreandoffshoreteamuseonline

toolstoexchangeinformationwitheachother.Eachteamshouldresponseto

querieswithin12hours.

AlsoKnownAs

InformationTransferorKnowledgeSharing

Category

Communicationcategoryasthispatternhelpstheonshoreandoffshoreteam

memberstoanswereachother’squerieswithin12hours.

152

Motivation

The motivation of this pattern is to address the communication and co-

ordination,andknowledge transfer challenges. ForexampleWhena team is

dividedondifferenttimezonestheymayhavequeriesaboutworkbutdueto

the time difference they cannot get a direct reply at that time so they use

emailstocommunicatequeries,whicharethenansweredwithin12hoursmax.

Organisationshavesetstandardsforresponsetimeinordertoavoiddelaysin

work(Vax,2008).

Applicability

UseAsynchronousInformationTransferwhen:

• Teamisdistributedoverdifferenttimezones.

Participants

• Distributedonshoreandoffshoreagileteammembers.

Collaboration

• Theonshoreteamandoffshoreteammembersshareinformationandask

queriesusingasynchronoustools.

Consequences

The Asynchronous Information Transfer pattern has the following benefits and

liabilities:

1. It allows onshore and offshore team members to exchange information

when synchronous communication cannot be conducted due to working

hours time difference. This helps overcome the knowledge transfer

challenges.

153

2. Ithelpsteammembersfromwaitingforonshoreteammemberavailability

toaskaquery.Thishelpsovercomethecommunicationandcoordination

challenges.

3. If the team members don’t respond timely it can cause delays in the

project.

Knownuses

VTT Technical Research Centre of Finland and National University of Ireland

conducted a research on two organisations that were developing a system

together.Oneorganisationwasacustomerorganisation inU.Sand theother

organisationwasadevelopmentorganisationlocatedinIreland.Basedontheir

findingsthecompaniesusedasynchronoustoolsforcommunication.Theyused

wikisforstoringdocumentsandmeetingminutesandusedEmailsfordecisions

and queries (Korkala, 2010). Similarly Valtech used Twiki for asynchronous

communication(Danait,2005).

RelatedPatterns

Asynchronous Information Transfer pattern is often used with Global Scrum

BoardandSynchronousCommunicationPattern.

4.5.2.4 SynchronousCommunicationPattern

Agile emphases on close face-to-face communication between the team members

rather than detailed documentation. When a team is distributed on different time

zones it has been observed that the teams adopted synchronous tools for sharing

informationwitheachothersuchasvoice,videoconferencinganddocumentsharing

tools.Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:

PatternName

SynchronousCommunicationPattern

154

Intent

In order to discuss issues the teams uses synchronous tools for voice, video

conferencing,documentsharing,applicationsharingetc.

AlsoKnownAs

SynchronousKnowledgeTransfer

Category

Communicationcategoryasthispatternhelpstheonshoreandoffshoreteam

memberstoanswereachother’squerieswithin12hours.

Motivation

The motivation of this pattern is to address the trust, socio-cultural

communication and coordination, and knowledge transfer challenges. For

examplewhenateamisdividedondifferenttimezonestheymayhavequeries

whichtheycandiscusswiththeonshoreteamusingsynchronoustoolstoget

real-timeresponse(Vax,2008).

Applicability

UseSynchronousCommunicationPatternwhen:

• Teamisdistributedoverdifferenttimezones.

Participants

• Distributedonshoreandoffshoreagileteammembers.

Collaboration

• Theonshoreteamandoffshoreteammembersshareinformationandask

queriesusingsynchronoustools.

Consequences

TheSynchronousCommunicationpatternhasthefollowingbenefitsandliabilities:

155

1. It allows onshore and offshore team members to exchange information.

Thishelpsovercomeknowledgetransfer,communicationandcoordination

challenges.

2. Teammembers canask eachotherquestionswhichbuilds trust andhelp

understand each others socio-cultural differences, which helps overcome

trustandsocio-culturalchallenges.

3. Itassiststeammembersfromwaitingforonshoreteammemberavailability

toaskaquery.Thishelpsovercomethecommunicationandcoordination

challenges.

4. If the team members don’t respond timely it can cause delays in the

project.

Knownuses

CampusSoft is a UK based company that used synchronous communication

whentheymovedtoAgilewiththeiroffshoresuppliers inIndiaandRomania.

Theyusedvideoconferencingfacilitiesforplanningsessionsandlatershiftedto

WebExsessionsandGoToMeetingsothattheycouldsharedesktopswiththe

remoteteammembers.FordailyScrummeetingstheypreferredtouseSkype

callandmadeeveryonewearheadsetstomakethemeetingeasier.Forsprint

reviewmeetingstheyusedsharingdesktoptoolsaswellasconferencephones

sothatmembersfrombothendcouldtalkwitheachother(Summers,2008).

RelatedPatterns

SynchronousCommunicationpatternisoftenusedwithGlobalScrumBoard

andAsynchronousInformationTransferPattern.

4.5.3CollaborationPatterns

Inthissectionwehavedescribedthedetailofeachcollaborationpattern.

156

4.5.3.1 CollaborativePlanningPokerPattern

Anagileteamplaysplanningpokertoputpoint’sestimationoneachstorycard.The

productowneralsotakespartinthisactivity.Hetellstheteamtheintentandvalueof

a story card baseduponwhich the development teamassigns an estimation on the

card.Basedon thepointsassigned the teammemberswhoassigned the lowestand

highestestimationwill justify their reasons.The teamwillhaveabriefdiscussionon

eachstoryandassignanestimationuponwhichthewholeteamagreeson.

It has been observed that even when the team is distributed the planning poker

activityisconductedwhenbothteamsareco-locatedfortheprojectplanningactivity.

Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:

PatternName

CollaborativePlanningPokerPattern

Intent

Onshoreandoffshoreteammemberstakepartinthisactivity.

AlsoKnownAs

PlanningPokerorScrumPoker

Category

Collaborativecategoryasthispatternhelpstheonshoreandoffshoreteamto

discussthedurationofastorycard.

Motivation

The motivation of this pattern is to address the trust, socio-cultural,

communication and co-ordination, and knowledge transfer challenges. For

examplewhenaproject isdistributedtoateamthat isdividedoverdifferent

time zones, it is important that all the team members agree on the time

duration of a feature before they start developing the project. This helps

estimatethedurationoftheprojectcompletionaswellasitprovidesvisibility

157

ofprojectprogress.Forthispurposetheonshoreandoffshoreteammembers

playplanningpoker inordertocollectivelyagreeontheestimationofastory

card.Oncetheestimation isdecidedtheywrite itdownandapprovedbythe

productowner/clientandmoveontothenextstorycard,tillallthestorycards

areestimated.

Applicability

UsePlanningPokerpatternwhen:

• Team is distributed over different time zones andwill beworking on

differentstorycardsinasprint.

Participants

• Distributedonshoreandoffshoreagileteam.

• Productowner/Client.

Collaboration

• Theclientapprovestheestimationmadebytheteammembers.

Consequences

ThePlanningPokerpatternhasthefollowingbenefitsandliabilities:

1. Itallowstheonshoreandoffshoreteamstoagreeonastorycardestimation,

whichhelpstheteamestablishtheirteamvelocity.Sincemembersfromboth

locationsarepresentduringthisactivity,thishelpsovercometrustandsocio-

culturalchallenges.

2. It provides the product owner/client with estimation of project completion,

which helps overcome the communication and coordination, and knowledge

transferchallenges.

3. Ifallteammembersdon’tagreeonestimationonastorycarditcanleadtoa

longdiscussion,resultingtheplanningpokertoprolong.

158

Knownuses

UShardware has development centres across North America, South America

and Asia. When transitioning to distributed agile environment they used

planningpokeractivityforestimationoftheirstorycards(Wildtetal.,2010).

RelatedPatterns

Planning Poker Pattern is often used with Collective Project Planning as its

better to conduct this pattern when the whole team is co-located. The

estimatedstorycardsarethensharedontheGlobalScrumboardsothatwhole

teamcanviewthemduringtheproject.

4.5.3.2 Follow-the-SunPattern

Whenaagileteamisdistributedoverdifferenttimezones ithasbeenobservedthat

companiescutdownoncostbyincreasingdevelopmenttimebyadopting“followthe

sun”workflowwhichmeans itallows24hoursdevelopmentduetothedifference in

timezonesallowingacompany’semployeestododevelopment24hrsaday(Carmelet

al., 2001; Yap, 2005; Kroll, et al., 2012). Based on this observed practice we have

designedthefollowingpatterndetails:

PatternName

Follow-the-SunPattern

Intent

Onshore and offshore teamswillwork 9:00 a.m-5:00 p.m. according to their

owntimezones.

AlsoKnownAs

24-hoursDevelopmentPatterns

159

Category

Collaboration category as this pattern helps the onshore and offshore team

managetheirworkandhandofftheirworktotheotherteambeforetheyleave

fromwork.

Motivation

The motivation of this pattern is to address the communication and co-

ordination,andknowledge transferchallenges. Forexampleconsidera team

that is divided into sub-teams that are located on different time zones. To

adjust the working hours of the offshore team for both the onshore and

offshoreteamworktogetherisdifficultastheoffshoreteamhastocomeinthe

eveningandstaytillearlymorning.Thismakestheoffshoreteamfeeltheyare

lessimportantincomparisontotheonshoreteamanditaffectstheemployees’

sociallife.

In order to avoid that, the onshore and offshore team use “follow-the-sun”

approach.Forexampleanemployeeworksfrom9:00a.m.to5:00p.m.inthe

USA. At 5:00 p.m. she hands over the incomplete task to a colleague in

Australiawhoworks from9:00 a.m. to 5:00 p.m. basedonhis time zone.At

5:00p.m.accordingtohiscountry,hetransferstheupdatedtasktoacolleague

in Polandwhoworks on the updated task for the next eight-hours and then

forwardsittohiscolleagueintheUSA(Gupta,2009).

WhiletheemployeeintheUSAhadleftworktwoofhercolleaguesworkedon

her task aswhen shewill come to theoffice nextmorning a lot of thework

wouldhavebeendone.Thisworkscenariotakesadvantageofthegeographical

distances as it allows people from different time zones to work round-the-

clockinordertobuildsoftware(Gupta,2007).

Theworkdistributionamongtheteamcanbedoneintwoways.Firsteitherthe

3teamsdistributedondifferentgeographicallocationsworkonthesametask

andeachteamkeepsupdatedthetaskasmentionedintheabovescenarioor

160

secondlyamostefficientway is thatwedivideddifferentaspectof thesame

problemamongtheteamforexampleinFigure4.3wecanseehowaproblem

hasbeendistributedamong3teams(Gupta,2009):

Figure4.3.DistributionofWorkamongThreeDistributedTeams(Gupta,2009).

Applicability

Usefollow-the-sunpatternwhen:

• Teamisdistributedoverdifferenttimezones.

• Theonshoreandoffshoreteamsareworkingondifferenttasks.

Participants

• Distributedonshoreandoffshoreagileteam.

Collaboration

• Bothonshoreandoffshoreteamhandovertheirworktoeachotheratthe

endofeveryworkingdayusingonlinetools.

Consequences

Thefollow-the-sunpatternhasthefollowingbenefitsandliabilities:

1. Itallowscontinuesdevelopmentduringdifferentworkingshiftsacrossdifferent

time zones, which helps overcome the communication and coordination

challenges.

161

2. Itallowsbothonshoreandoffshoreteamtoworkaccordingtotheirtimezone

andsharetheirworkwithouthavingtoeithercomeearlytoworkorstaylate

tillearlymorning.Thishelpsovercometheknowledgetransferchallenges.

3. Itreducesthedevelopmentlifecycleortime-to-market(Denny,etal.,2008).

4. It limits theonshoreandoffshoreteamfromreal-timecommunicationas the

overlappingworkinghoursbetweendifferenttimezonescanbelessorzero.

Knownuses

Yahoo! used follow-the-sun approach when they offshored their Yahoo!

PodcastproductfromSunnyvale,CaliforniacampustoYahoo!Bangalore,India

Campus(Drummondetal.,2008).SimilarlyorganisationslikeWDSGlobal(Yap,

2005)andWiproTechnologies(Sureshchandra,etal.,2008)usefollow-the-sun

approach.

RelatedPatterns

Follow-the-sunPatternisoftenusedwithLocalStandupmeetingPatternand

DistributedScrumofScrumPatternasbothonshoreandoffshoreteam

membersareworkingseparately.

4.5.3.3 CollectiveProjectPlanningPattern

Agilefocusesonindividualsandinteractionsoverprocessesandtools.Whileplanning

fortheprojectthewholeteamispresent.Unlikethetraditionaldevelopmentwherea

projectmanagerhandsaprojectplantotheteam.Inagilethewholeteamtakespart

in the planning activity in order to determine when and how the project will be

developed.Ithasbeenobservedthateveniftheprojectisofadistributednatureitis

better to co-locate the team onshore and offshore team for the project planning

activity. Based on this observed practice we have designed the following pattern

details:

162

PatternName

CollectiveProjectPlanningPattern

Intent

Both the onshore team and the offshore team will collectively work in the

project-planningphase.Oncebothteamhaveengagedintheprojectplanning

activity,theteamwillpreparetheprojectbacklog.

AlsoKnownAs

ProjectPlanningorAgileProjectPlanning

Category

Collaborationcategoryasthispatternhelpstheonshoreandoffshoreteamto

worktogetherandcomeupwithaprojectplan.

Motivation

The motivation of this pattern is to address the trust, socio-cultural

communication and co-ordination, and knowledge transfer challenges. For

example consider a team that is divided into sub-teams that are located on

differenttimezonesandboththeteamscometoonelocationtodotheproject

planningactivity.Inthebeginningofanydistributedproject,theoffshoreteam

is invited to the onshore location so that they may work together and

understandeachother’srequirements.

Whiletheteamsareco-locatedtheyworkedonpreparingtheproductbacklog

andtheyspendat leastoneortwosprintstogetherbeforetheoffshoreteam

leaves and starts working on the project (Cottmeyer, 2008; Therrien, 2008).

This helps the onshore team bymaking the offshore team understand their

workingstyleandworkstandard.

Applicability

UseCollectiveProjectPlanningpatternwhen:

163

• Teamisdistributedoverdifferenttimezones.

Participants

• Distributedonshoreandoffshoreagileteam.

Collaboration

• Onshoreteamandoffshoreteamworktogethertomakeaproductbacklog.

Consequences

TheCollectiveProjectPlanningpatternhasthefollowingbenefitsandliabilities:

1. It allows the onshore and offshore teams to work together and understand

each other. This helps build trust among the team members and overcome

communicationandcoordinationchallenges.

2. Onshoreteamworkswiththeoffshoreteamandmakesthemunderstandwhat

typeofworktheywant.Thishelpsovercomethesocio-culturalandknowledge

transferchallenges.

3. Itaddsadditionalcostof travelandstayof theoffshoreteamat theonshore

location.

Knownuses

FAST,asearchcompanywithheadquarters inNorwaywhilebuildingasearch

applicationontopoftheircoresearchplatformusedcollectiveprojectplanning

to co-locate the team and make them work together in project planning

activities (Berczuk, 2007). Siemens also used collaborative planning for their

distributedprojects (Avritzeretal.,2010;Avritzeret.al,2007) inwhich team

membersfrommultiplesitesgot involvedintheearlystagesoftheproject in

ordertocreateanopencommunicationchannelandhighleveloftrustamong

thedistributedteammembers(Avritzeret.al,2010)

164

RelatedPatterns

CollectiveProjectPlanningPatternisoftenusedwithProjectCharterPatternas

itprovidesacentraldocument thatconsistsof thegoalandobjectivesof the

projectwrittenbytheclient.

4.5.3.4 VisitOnshore-OffshoreTeamPattern

Asagileemphasesoncloseface-to-facecommunicationbetweentheteammembersit

hasbeenobserved thatwhen the team isdividedondifferent timezones, the team

memberstravelquarterlyorannuallytovisiteachother.Thisactivityhelpsbuildtrust

among the team members and helps them understand each other’s cultural

differences (Ramesh,2006; Therrien, 2008; Summers, 2008;Paasivaaraet al., 2014).

Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:

PatternName

VisitOnshore-OffshoreTeamPattern

Intent

Bothonshoreandoffshoreteamsshouldquarterly/annualvisiteachotherin

ordertobuildtrust,exchangeculturalvaluesandimproveteamcoordination.

AlsoKnownAs

TravelOnshore-Offshore

Category

Collaboration category as this pattern helps the onshore and offshore team

members to co-locate and understand each other and build a good

relationship,whichimprovesteamcoordination.

Motivation

The motivation of this pattern is to address the trust, socio-cultural

communication and co-ordination, and knowledge transfer challenges. For

165

examplewhena team isdividedondifferent time zones theydon’t feel that

they are both part of one team and they don’t trust each other. They don’t

understandeachother’sculturalvaluesandworkethics.Inordertosolvethese

issuestheonshoreandoffshoreteamvisitseachothertodevelopthefeelingof

trust and understand each other’s cultural andworking values. During these

visitstheyattendtrainingtogetheraswellasengageintoinformalactivitiesto

better understand each other. This helps build a bond between the team

members,whichresultsingoodteamcoordination.

Applicability

UseVisitonshore-offshoreTeamwhen:

• Teamisdistributedoverdifferenttimezones.

Participants

• Distributedonshoreandoffshoreagileteammembers.

Collaboration

• Theonshoreteamandoffshoreteammembersvisiteachothertoimprove

teamcoordination.

Consequences

TheVisitonshore-offshoreTeampatternhasthefollowingbenefitsandliabilities:

1. Itallowsonshoreandoffshoreteammemberstoexchangeculturalvalues

with each other andwork ethics. This helps overcome socio-cultural and

communicationandcoordinationchallenges.

2. Ithelpsteammembersto feel theyarepartofoneteam,whichdevelops

trust among onshore and offshore team members. This helps overcome

trustandknowledgetransferchallenges.

3. Thetravellingaddsadditionalcosttotheprojectbudget.

166

Knownuses

EricssonisaSwedishmultinationalproviderofcommunicationstechnologyand

services.TobuildaXaaSplatformandasetofservicestheyusedagilesoftware

development methodologies. The development team was distributed over 5

sites located in3countries.Fourof thesiteswere located inEuropeandone

waslocatedinAsia.Theyconductedworkshops,whichwereattendedbyteam

members from different locations. The purpose of these workshops was to

createacommonvisionforthewholeorganisationbysettingcommonvalues

aswell also to improve the collaboration between the sites, thus build trust

(Paasivaaraetal.2014).

RelatedPatterns

Visit onshore-offshore Team pattern is often used with Collective Project

PlanningPatternasplanningisbetterdonewhenthewholeteamisco-located.

4.5.4VerificationPatterns

Inthissectionwehavedescribedthedetailofeachverificationpattern.

4.5.4.1 ProjectCharterPattern

In project management, project charter is a statement that defines the scope,

objectives and participants of a project. It is used to explain the roles and

responsibilities,outlineoftheprojectobjectivesandidentifymainstakeholders.Ithas

beenobservedthatwhilestartingadistributedprojectusingagilemanyorganisation

useprojectcharter toclarify thegoalsandobjectivesof theproject tobothonshore

andoffshore team (Galen,2009).Basedon thisobservedpracticewehavedesigned

thefollowingpatterndetails:

PatternName

ProjectCharterPattern

167

Intent

Beforestartingtheprojectplanningactivity,agileteamsuseprojectcharterin

ordertohaveacentraldocumentbetweentheonshoreandoffshoreteamthat

definestheproject.

AlsoKnownAs

ProjectDefinitionorProjectStatement

Category

Verification category as this pattern helps the onshore and offshore team to

have a central document clarifying the project goals and objectives,which is

writtenbytheproductowner/client.

Motivation

Themotivationofthispattern istoaddressthetrust,communicationandco-

ordination,andknowledgetransferchallenges.Forexamplewhenaprojectis

distributed to a team that is divided over different time zones, a central

documentiswrittenknownastheprojectcharter,whichclarifiestheonshore

andoffshoreteamthegoalsandobjectivesoftheproject.Italsoidentifiesthe

rolesandresponsibilitiesoftheonshoreandoffshoreteam.Thepurposeofthis

activityistohaveadocumentthathelpstheteamintheproject-planningtask.

Applicability

UseProjectCharterpatternwhen:

• Teamisdistributedoverdifferenttimezones.

Participants

• Distributedonshoreandoffshoreagileteam.

• Client.

168

Collaboration

• Theclientgivestheprojectchartertotheonshoreteamandoffshoreteam

toclarifythegoalsoftheproject.

Consequences

TheProjectCharterpatternhasthefollowingbenefitsandliabilities:

1. Itallowstheonshoreandoffshoreteamstounderstandtheproject.Thishelps

overcome communication and coordination, and knowledge transfer

challenges.

2. Since it isasingledocumentstating thegoalsandobjectivesof theproject it

helpsestablishtrustbetweentheonshoreandoffshoreteammembers.

3. It is intendedtoclearlysetthestagefortheprojectbyaligningtheteamand

settingsgoalsandexpectations.

Knownuses

IONATechnologiesusedProjectCharter fortheirdistributedprojects inorder

to have a central document that clarifies the goals of the project to both

onshore and offshore teammembers (Poole, 2004). Similarly in a case study

conducted by Brown (2011) on Agile-at-Scale Delivery it was observed that

organisationsuseprojectcharter.

RelatedPatterns

ProjectCharterpatternisoftenusedwithVisitonshore-offshoreTeampattern.

4.5.4.2 OnshoreReviewMeetingPattern

Inagile,at theendofeachsprint,asprintreviewmeeting isheld inwhichtheteam

meetswiththeclientsandshowsthemtheworktheyhavedonethroughademo.In

thismeetingtheclientgivesremarksabouttheworkandiftheyrequireanychanges

169

theytelltheteam.Ithasbeenobservedthatwhentheteamisdistributedondifferent

locations, then the team that is co-locatedwith client conducts the reviewmeeting.

Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:

PatternName

OnshoreReviewMeeting

Intent

Theonshoreteamwillpresentthedemoastheyarelocatedwheretheclient

is.

AlsoKnownAs

SprintReviewMeeting

Category

Verification category as this pattern helps the client see the progress of the

projectaswellastheycansuggestearlychanges.

Motivation

The motivation of this pattern is to address the trust, socio-cultural

communication and co-ordination, and knowledge transfer challenges. For

example consider a team that is divided into sub-teams that are located on

differenttimezonesandoneoftheteamislocatedinthesamecountryasthe

client. Inordertoshowtheprogressoftheproject it ismoreconvenientthat

theteam,whichislocatedneartheclient,presentsthedemoinordertohavea

face-to-facemeeting.Oncethemeetinghasendedtheonshoreteambriefsthe

offshoreteamstheremarksoftheclient.

Applicability

UseOnshoreReviewMeetingpatternwhen:

• Teamisdistributedoverdifferenttimezones.

• Theonshoreislocatedinthesamecountryastheclient.

170

Participants

• Distributedonshoreandoffshoreagileteam.

• Client

Collaboration

• Onshore team presents demo to the client and discusses the meeting

minuteswiththeoffshore.

Consequences

TheOnshoreReviewMeetingpatternhasthefollowingbenefitsandliabilities:

1. It allows the client tomeet the development team face-to-face and give

feedback. This helps overcome the communication and coordination

challenges.

2. Itallowsbothonshoreandclientstodiscusswhatchangestheywantand

how much time will be required based on the modification. This helps

overcometheknowledgetransferchallenges.

3. It limits the offshore team frommeeting the clientswhich can cause the

offshoreteamfromdiscussingthechangesandgivingtheirremarksonthe

clientsfeedback.

Knownuses

Wipro Technologies, a global service provider company used onshore review

meetings so that they could get quick feedback from the customer/business

user, which was then shared with the remote team over mail and/or

teleconference (Sureshchandra et al., 2008). Similarly when SirsiDynix, USA

outsourced their work to Starsoft, Ukraine they also used onshore review

meetingstoshowthedemooftheworkdone(Sutherlandetal.,2007)

171

RelatedPatterns

Onshore Review Meeting pattern is often used with Asynchronous

Retrospective Meetings Pattern because after the demo both onshore and

offshoreteammembersconducttheirseparateretrospectivemeetings.

4.6ChapterSummary

Thischapterpresentedthedistributedagilepatternscatalogue.Thechapterstartsby

discussingthetemplatesofexistingpatternsandthenpresentshowthetemplateof

distirbuted agile was designed. We then discuss how the pattern catalogue is

organised and can be used by the practitioners. At the end of the chapter we

presented the whole distributed agile patterns catalogue.

172

Chapter5 ValidationandEvaluationoftheDistributedAgile

PatternsCatalogue

5.1Introduction

In this section we have validated and evaluated the Distributed Agile Patterns

catalogue.Inordertovalidatethecatalogueweusedreflectionworkshoptechniqueas

proposed by Kerth (Kerth, 2001). For theworkshopwe invited 4 companies to take

part. From each company two representatives took part. Theworkshop lasted from

9:30 a.m.- 4:00 p.m., inwhich the cataloguewas presented to the participants and

thentheygavefeedbackonhowtoimprovethecatalogue.Basedontheirsuggestions

thepatterncataloguewasmodified.Forevaluationwecomparedthecataloguewith

othersolutionspresentedintheliteratureanddiscussedtheirlimitationsandhowour

patterncatalogueovercomesthoselimitation.

5.2RevisedDistributedAgilePatterns

Inordertoverifyandvalidatetheidentifieddistributedagilepatterns,weconducteda

reflection workshop based on Kerth’s “The keep/try reflection workshop” (Kerth,

2001).Thereasonforchoosingthismethodwastogetexpertopinionsonthepatterns

andfindoutifthepatternsactuallyexistbasedonthepractitionerspointofviewand

if they help practitioners in applying agile in offshore projects. To conduct this

workshopfourcompanieswereinvitedtotakepart;detailsareshowninTable5.1.

Table5.1.DetailsoftheCompanies.

Company Category Typeof

Business

HQ Loc.of

Business

Exp.

in

Agile

C1 Startup ITservices Pakistan Dubai,U.K 2years

173

C2 Breakeven Product-

based

Pakistan U.S.A,U.K 5years

C3 Breakeven Multinational

ITservice

provider

Pakistan Dubai 8years

C4 Profitable Software

solutions

U.S.A Pakistan 10years

Fromeachcompany,weinvitedtwoparticipantstotakepartintheworkshopsothat

wecanhaveamanagerialanddevelopmentpointofviewforourpatterns.Table5.2

showsthedetailsoftheparticipantsandtheirexperienceinagileanddistributedagile

practices(DAP):

Table5.2.DetailsoftheParticipantsAttendedtheWorkshop.

Company Participant

Name

JobTitle RoleinAgile Exp.in

Agile

(years)

Exp.inDAP

C1 P1 CEO Scrum

Master

2 2

P2 Developer Developer 2 1

C2 P3 CEO Product

Owner

5 5

P4 Senior

Developer

Developer 5 5

C3 P5 CEO Scrum

Master

8 8

P6 Developer Developer 5 4

C4 P7 Senior Developer 8 5

174

Developer

P8 Senior

Software

Engineer

Developer 8 4

TheworkshopwasconductedatC1’sboardroomand thedurationwas7hours.The

agendaoftheworkshopisshowninTable5.3below:

Table5.3.AgendaoftheReflectionWorkshop.

No. AgendaItems Time

1.

2.

3.

4.

5.

TeaandNetworking

Introductionofwhatisreflectionworkshop

anddiscussedhowwewillconductit

DiscussiononDistributedAgilePatterns

Lunch

Feedbackandrecommendation

9:30a.m.-10:00a.m.

10:00a.m.-11:00a.m.

11:00a.m.–2:00p.m.

2:00p.m.–3:00p.m.

3:00p.m.-4:00p.m.

Theworkshopwasstartedbyexplainingtotheparticipantswhatareflectionworkshop

is and what is expected from them at the end of the workshop. Based on Kerth

keep/try reflection workshop method, this workshop focused on capturing three

things on a flip chart, which was then displayed for the group to see and discuss.

(Kerth,2001).Thethreethingsare:

• Whatshouldwekeep?

• Wherearewehavingon-goingproblems?

• Whatdowewanttotryinthenexttimeperiod?

TheformatoftheflipchartlookslikeintheTable5.4below:

Table5.4.FlipChartFormatfortheReflectionWorkshop(Kerth,2001).

175

Keepthese

Trythese

Problems

The patterns catalogue was presented in the form of a document so that the

participants can have a copy and make notes during the presentation (Figure 5.1).

Since the documentwas new to the participants, the cataloguewas presented one

pattern at a time. The participants were then invited to discuss among themselves

beforemovingtothenextpattern.Thedocumentwaspresentedasshown inFigure

5.1 to help make the documentation on the flip chart easier while referring to a

pattern:

Figure.5.1.DocumentPresentedinReflectionWorkshoptotheParticipant

176

Asanexampletoshowhowwedocumentedthereflectionworkshop,Table5.5shows

thedetailofaflipchartofCompany3Participant5(C3P5).IntheKeepthese,section

we have mentioned all the patterns that C3P5 thinks should stay as they were

presented, that is he wants section 1.2-1.5 to remain the same. In the Problems

section,C3P5wantsSection2.2tobechanged,asaccordingtohimthepatternCentral

CodeRepositoryistoogeneric.

In the section Try these, C3P5 has given suggestions on how we can improve the

patterns, suchashewantsus tochange thenameofpattern1.1ScrumofScrum to

distributedScrumofScrumbecausetheScrumofScrumwordisusuallyusedinagile

for a Scrum inside a Scrum whereas in this pattern wemeant two separate scrum

workingindependently.

Table5.5.FlipChartofCompany3Participant5(C3P5).

Keepthese

• Keep1.2,1.3,1.4,1.5

• Keep2.2,2,3,2,4

• Keep3.1,3.2,3.4

• Keep4

Trythese

• 1.1: Try changing name of 1.1 to

distributed Scrum of Scrum as just

scrumofscrumisconfusing.

• 3.3:Trycomingupwithgenericset

of preferences and then let the

distributedteamdefineexactlyhow

theywanttocollaborate.

Problems

• 2.2: Need to change this pattern as it is too

generic, that is add details on what code

repositoryshouldbeused.

177

AsummaryoftheflipchartsbyallparticipantsisshowninTable5.6:

Table5.6.SummarisedFlipChartoftheCompanies.

Keepthese

• Keep1.2,1.3,1.4,1.5

• Keep2.2,2,3,2,4

• Keep3.1,3.2,3.4

Keep4

Trythese

• 1.1: Try changing name of 1.1 to

distributed Scrum of Scrum as just

scrumofscrumisconfusing.

• 1.1: Trymaking 1.2,1.3,1.4,1.5 part

of 1.1 as they are related to each

other.

• 3.3:Trycomingupwithgenericset

of preferences and then let the

distributedteamdefineexactlyhow

theywanttocollaborate.

• 4.2: Onshore review is good and

recommended, however in some

demos offshore team should also

be there especially if they are

visiting the onshore team. This

would boost their moral and help

themunderstandtheclientbetter.

• Toallpatterns,adddetailsonwhich

challenge they help overcome and

modifytheconsequencessectionto

highlight how a benefit can aid in

overcomingachallenge.

Problems

• 2.2: Need to change this pattern as it is too

generic, that is add details on what code

repositoryshouldbeused.

• 3.1:Whole team should be part of planning

poker,as itwillhelp theteamtounderstand

eachother’sculture.

• 3.2: Only applicable teams that are in the

time zonenext toeachother e.g. 5:00p.m is

9:00a.m.inanothercountry.

178

Table5.7.FeedbackontheChallengesDistributedAgilePatternsSolve.

PatternName Trust Socio-

Cultural

Communicationand

Coordination

Knowledge

Transfer

Agreed

DistributedScrumofScrum 80%

LocalStand-upMeeting 80%

Followthesun 50%

OnshoreReviewMeeting 75%

CollaborativeProject

Planning

100%

ProjectCharter

75%

CollaborativePlanningPoker

100%

GlobalScrumBoard

100%

LocalSprintPlanning 80%

LocalPairProgramming 80%

CentralCodeRepository 100%

AsynchronousRetrospective

Meeting

65%

AsynchronousInformation

Transfer

80%

SynchronousCommunication

100%

VisitOnshore-Offshore

Teams

100%

Afterreceivingfeedbackonthepresentedcatalogue,thediscussionwasthendirected

towards the usefulness of the patterns to help overcome the offshore challenges.

According to the results collected fromtheworkshop,Table5.7 showswhatpattern

helps solve which offshore challenge based on the feedback of the participants. As

showninTable5.7:

• 50% of the participants agreed that the follow the sun pattern helps in

improving communication and coordination of the team. However the other

half believe that by applying follow the sun pattern, the team has less

179

overlapping working hours which results in less real-time communication

amongtheteammembers.

• 75%of theparticipantsagreed thatproject charter patternwouldhelpsolve

thetrust,communicationandcoordinationandknowledgetransferissue.Asit

is a singledocument that is sharedbetween theonshoreandoffshore team,

definingthegoalandobjectiveoftheproject.However25%oftheparticipants

believedthatitisdifficulttoestablishtrustatthestartoftheprojectthrougha

document as to develop trust among the team members, they need to

communicatewitheachotherfrequentlythroughouttheproject.

• Similarly 80% of the participants agreed that distributed scrum of scrum

pattern helps solve communication and coordination as well as knowledge

transfer issue in offshore software development. As it allows each team to

conducttheirownscrumandattheendbothteamssharetheirworkwitheach

other hence providing synchronous exchange of communication and

information.

• Alltheparticipantsagreedthatvisitonshore-offshoreteampatternhelpsbuild

trust among the onshore and offshore team members. It also helps team

membersunderstandeachother’ssocio-culturaldifferencesandastheteamis

co-located, it will help in improving the team’s communication and

coordinationandknowledgetransfer.

5.3EvaluatingDistributedAgilePatterns

Inthissectionwewillevaluatethedistributedagilepatterns(DAP)approachwiththe

other existing approaches present in literature and discuss what advantages our

approachhasovertheexistingsolutionsthatwerementionedinSection2.4.

180

Table5.8.ExistingSolutionsinComparisontotheDAPCatalogue.

No. Type ExistingSolutionsforGlobalSoftwareDevelopment

1. Approach UsingAgilePracticestoSolveGlobalSoftware

DevelopmentProblems.

OffshoreChallenges

answeredinthis

approach

Beecham proposed to overcome the challenges of poor

communication, lack of control, low staff morale and

ambiguous requirements (Beecham et al., 2014). They

achieved this by identifying agile practices that solve the

identified challenges. As mentioned in Table 2.7 that the

solution presented did not provide details of how the

identifiedpracticeswillovercometheoffshorechallenges.

Furthertheyhavenotaddressedoffshorechallengessuchas

trust,socio-culturalandknowledgetransfer.

Limitation The limitation to their approach is that even though they

have considered the challenges of GSD, they have not

discussed in detail how practitioners can solve them. For

example for the challenge identified as “vague/missing

requirements” the solution they presentedwas a one line

answer, “ Product owner role; Planning game; Frequent

interactions; on-site customer.” Theydidn’t give anydetail

onhoworwhataffectthesepracticeswillhave.

2. Approach Ontology-BasedMulti-AgentSystemtoSupport

RequirementsTraceabilityinMulti-SiteSoftware

DevelopmentEnvironment.

OffshoreChallenges This approach, focuses on communication, coordination

181

answeredinthis

approach

and knowledge transfer challenges. They have used

software engineering ontology as a communication

framework to enable knowledge sharing and reuse. The

proposed framework supports automated requirements

traceability tasks. As mentioned in Table 2.7, Agent

Communication Language is used for requirement

traceability.

Thisapproachonlyfocusesonrequirementtraceabilityina

distributedenvironmentandtheydidnotconsideroffshore

challengessuchastrustandsocio-culturalissues.

Limitations Amajorlimitationtotheirapproachisthatitistootechnical

considering in agile the requirements/user stories are

writtenbytheproductowner.Asimplerequesttoupdatea

requirement using the Agent Communication Language

(ACL)lookslikebelow:

((action (agent-identifier

:name UserAgent@platform1

:addresses (sequence

http://192.168.0.4:7778/acc))

(UpdateRequirement

:name FR03

:resourceType Requirements)))

For a technical person it isn't a difficult piece of code, but

considering the fact that product owners do not have a

technical background. It is difficult to use this system.

Secondlytheyhaveonlyfocusedontherequirementsphase

thus providing us with an incomplete solution to the

challengesaffectingtheoffshoredevelopmentprocess

182

3. Approach ExperimentsforOffshoreProjecttoAddressCentrifugal

Forces.

OffshoreChallenges

answeredinthis

approach

Larman has suggested experiments to overcome offshore

challenges such as communication and coordination

(Larman et al., 2010). But they have just provided uswith

brief description of experiments that they think based on

their experience with Valtech should predict success for

otherorganisationsoffshoringtheirprojectsusingagile.For

exampleoneoftheirexperimentisto:

“Try..Outside-the-siteagilecoaches,inwhichtheystatethat

every organisation benefits by bringing in outside agile

coachingexpertstoactasviralagent.Thisisdoublytruefor

offshoreorganisationssteepedintraditionalcommand-and-

control managements and process culture. If the offshore

organisationismultinationalstartbylookingforin-company

coachesfromothernations.“

This approach focuses on providing agile experiments in

distributedenvironmentandtheydidnotconsideroffshore

challenges such as trust, socio-cultural and knowledge

transferissues.

Limitations Limitationof theirapproach is thattheyhavenotprovided

exampleonhowandwhyshouldpractitionersperformthat

experiment. They have not provided samples of

organisations doing that experiment and what results did

theyachievebydoingthatexperimentandwhatdifference

does it make if practitioners do not perform this

183

experiment.

4. Approach UnderstandingCollaborativePracticesinDistributedAgile

DevelopmentusingTheoreticalConcepts

OffshoreChallenges

answeredinthis

approach

Modi research presented a new way of solving the

collaboration challenge (Modi et al., 2013). They have

presented amodel representing the interrelationship with

common ground, boundary objects and awareness as

according to their proposed solution interlinking these

theoretical models within the globally distributed agile

setting, can lead to increasing awareness regarding the

project artefacts which in turn contributes to establishing

and negotiating common ground for joint collaborative

practicestobeheldatdifferentdistributedsites.

Thisapproachfocusesoncollaborationchallengesanddoes

not consider trust, socio-cultural and knowledge transfer

challenges.

Limitations Althoughthis researchpresentedanewwayofsolving the

collaborationchallenge; theyhaven’tpresentedanyresults

as their idea was presented as a research proposal. They

have justmentionedwhat researchmethodology theywill

useandwhat their expected resultswill bebasedon their

assumptions.

5. Approach Distributed Agile Patterns for Offshore Software

Development

OffshoreChallenges

answeredinthis

As part of this research we designed a catalogue of 15

distributed agile patterns. The focus of thesepatternswas

184

approach

to overcome offshore challenges such as trust, socio-

cultural, communication and coordination, and knowledge

transfer.Inchapter4wehavepresentedthecatalogue.

Strengths Comparedtotheabove-mentionedapproaches,ourpattern

cataloguecoversthemainchallengesofoffshoring;wehave

categorisedthecataloguebasedonwhattypeofproblemit

solves such asmanagement, communication, collaboration

and verification patterns. The pattern catalogue also

provides details of how practitioners can use the patterns

and in each pattern there is a section on known uses in

which examples are given on which companies have used

thepattern.

5.4ChapterSummary

This chapter presented the validation of the distributed agile patterns catalogue by

using Kerth’s (2001) keep/try reflection workshop method. For the workshop we

invitedfourcompaniestotakepartandwepresentedourpatternscataloguetothem.

Basedontheirfeedbackwemodifiedourpatternscatalogue.Inordertoevaluatethe

results of this research we compared our catalogue with other existing solution

present in literature such as ontology-based multi-agent system to support

requirementsandexperiments foroffshoreproject toaddresscentrifugal forces.For

the different approaches we identifiedwhat challenges they helped solve and then

discussedtheir limitationsandfurtherexplainedhowourpattercatalogueaddresses

theoffshorechallenges.

Innextchapteracasestudyhasbeenpresentedwhichshowshowthedistributedagile

patternscanbeusedintherequirementphase.

185

Chapter6 CaseStudytoShowApplicabilityofDistributedAgile

Patterns

6.1Introduction

InthissectionwepresentacasestudyonhowtheDistributedAgilePatternscatalogue

can be used for offshore software development to give an overview to the

practitionersonhowtoselectpatternsfromthecatalogue.Howeverweonlyfocuson

the requirement-engineering phase of the software development lifecycle. The

chapterstartsbypresentinganoverviewoftherequirementsengineeringprocessand

howrequirementsaregathered inagilesoftwaredevelopment.Wethenpresentthe

existingworkdoneonimprovingtherequirementsengineeringprocessandlastlywe

show how distributed agile patterns can be used to overcome the requirements

engineeringchallengesinoffshoredevelopmentthatwehighlightedinChapter2and

then we map the selected distributed agile patterns onto the requirements

engineeringlifecycletoshowhowthepatternsimproveeachstepofthelifecycleina

distributedproject.

6.2OverviewofRequirementsEngineeringProcess

Wiegersdefinedrequirementsassomething,whichasystemmusthaveorsatisfyor

perform which is being identified by the client side (Wiegers, 2007). Similarly Zave

stated that requirements engineering is the branch of software engineering that is

concerned with the real-world goals for, functions of and constraints on software

system (Zave, 1997). The process of requirements elicitation is one of the most

challengingandcriticaltasksinsoftwaredevelopment.AccordingtoJacobsthecostof

incorrect,misunderstoodandnotagreeduponrequirementsaffectsallofusinterms

of time,moneyand lostopportunities (Jacobs,2007). Fowlerargued thateverything

else in software development depends on the requirements, as without having a

stable set of requirements to startwith, the development team cannot start coding

186

(Fowler, 2005).Darke,Davis andAnthonyhavealsodone similarworkbyexplaining

how critical the requirement process is and how it directly impacts the success and

failureofaproject(Darke,1997;Davis,1989;Anthony,1992).

6.3RequirementsEngineeringProcessinTraditionalSoftwareDevelopment

vs.AgileMethodology

In traditional software development methodologies, the client would predefine all

their requirements to thedevelopment teambefore thestartof subsequentphases.

Theteamwouldthenanalysetherequirementsandfinaliseasoftwarerequirements

specification(SRS)document.Oncetheclienthasapprovedthedocument,theywould

start the development phase. Figure 6.1 shows the traditional requirements

engineeringprocess.Thisprocessofrequirementselicitationhasproblemssuchas;a

longtimeisspentinpreparingthisdocumentation,whichcausesissuesindealingwith

future requirements change requests from the client once the actual development

phase starts. Over decades of software development we have learnt that

requirementschangeis inevitableduringthedevelopmentstage,becauseneither

theclientnorthedevelopersare100%sureofalltherequirementsofthesystem

atthestartoftheproject.

Figure6.1.TraditionalRequirementsEngineeringProcess.

In agile software development, this problem is solved with the use of story cards,

which isa lighterprocess forthedefinitionofveryhigh-levelrequirementsand isan

artefactofmethodssuchasSCRUMandXP.Theycontainjustenoughinformationfor

187

the developer to be able to estimate howmuch effort and timewill be required to

developthemandcanhandlechangerequestswithlittleeffort.Thereisalsoanagile

requirements change management process to control changing requirements

throughout the software development lifecycle. Based on this process, new

requirementscanbeaddedandreprioritizedbasedontheclient’srequest.Figure6.2

illustratestheagilerequirementschangemanagementprocess:

Figure6.2.AgileRequirementsChangeManagementProcess.

6.4ApproachestoImproveRequirementsEngineeringProcessinAgile

Toolshavebeenmadetoeasetheprocessofdocumentingstorycards.Onesuchtool

isSoBA(Pateletal.,2008).Thetooladdressedissuesthatareremainingtobesolving

regardingstorycardbaseddevelopment,whichare:

i. Toexplorestorycardfortestdrivendevelopmentanddesignfortestability.

ii. Tostructurestorycardswithuserstoriesandacceptancetesting.

iii. Toaddressnon-functionalrequirementsandeffortestimationforstorycards.

iv. Toexpresstraditionalsoftwaredevelopmentbestpracticesasguidelineswitha

toolsupport.

v. Tocapturestorycardsandplantaskssupportingpair-wisedevelopment.

188

This model can capture user stories in five formats, which are face-to-face

communication, electronic discussions, knowledge and experience from similar

systems, graphical notations and voice. This tool consists of five stages, which they

havebasedonthetraditionalmodelforcollectionrequirement,whichare:capturing

user stories and refining them, develop story cards, structuring story cards, effort

estimationandprioritiesstorycards.

Figure 6.3 shows themethodology used in SoBA tool to document story cards and

whatstepsareperformedbeforeauserstorycangointodevelopmentphase.Thatis

the customer and the tem capture the user stories, which can be collected in five

different multi-media format such as face-to-face, electronic discussion, knowledge

systems, graphical notation and voice. Once the user stories are captured they are

refinedanddocumentedintostorycardswithindexing.Thenextstepsarestructuring

those cards and assigning effort estimation and putting the cards in prioritization

order.Oncethecardsarereadytheyaremovedtodesignanddevelopmentphaseof

theproject.

Figure6.3.StoryCardBasedMethodologyfollowedbySoBATool(Pateletal.,2008).

Khan conducteda systematic literature review to identify factors that generate risks

during the requirements engineering process in a global software development

189

environment.Basedontheirresearch,theyfound74factors,whichtheygroupedinto

8classifications,whichare(Khanetal.,2014):

i. CommunicationandDistance.

ii. Cultural,Background,Language,OrganisationalandTimeDifferences.

iii. KnowledgeManagementandAwareness.

iv. Management.

v. Tools,TechnologiesandStandards.

vi. Stakeholders.

vii. ProjectandProcess

viii. Requirements.

Theseclassificationscanfacilitatethepractitionersbyservingasachecklisttoconsider

while capturing requirements however since this studyhas only collecteddata from

literatureandhasnotvalidatedtheir findingsfrompractitioners,wecannotconsider

this as a standard classification nor we don’t know howmuch effect it has on the

requirementsprocessifthepractitionerusesit.

Workhasalsobeendoneonhowagilerequirementscanbeprioritisedinalarge-scale

outsourced system.Daneva conducted an empirical study that aimedprioritise agile

requirementsbutkeepingthefollowingpointsinmind(Danevaetal.,2013):

• Focusonnotonlycreatingvalue,

• But also accumulating it over time, while minimizing the risk for the

developmentteam.

According to their study the taskofprioritising requirementswas the jobofproduct

ownerortheclientandthecontextualfactorsaffectingtherequirementsprioritisation

processareasfollows:

• Theneedtoembracechange,

• Projectconstraints

• ProjectScope

190

• Thenumberofprojectstaff.

As every software project is subjected to the need of change in requirements and

every project has constraints, Daneva, focused on the affects of project scope and

number of staff working on the project as according to their study, the scope

determinesthecomplexityoftheprojectandthenumberofstaffisdirectlylinkedto

risk,aslargernumberofclientsoftenleadstocontradictioninrequirements.Theyalso

classifiedrequirementsintosixtypesofdependencies,whichare(Danevaetal.,2013):

i. Inter-domain dependencies are referred to dependencies that are concerned

withrequirements thatareoverlappingmultiplebusinessareassuchasclient

policiesandsettingupclientcomplaintmanagementsystem.

ii. Intra-domain dependencies are those dependencies caused due to the close

linksbetweentheprocessesandentities.

iii. Dependenciesdue todownstreamactivities,suchassequencing requirements

thatmaximisestheuseofavailablehumanresource.

iv. Team-baseddependenciesdealwithavoidingmultipleteamshavingtodothe

sameworkorondependentartefacts.

v. Dependencesamonguserstoriestheseareimposedbytheorderofactivitiesin

aspecificbusinessprocess.

vi. Dependenciesamongdelivery stories, theseare referred to thedependencies

causedbynon-functionalrequirements.

Aspartof their study theydesignedauserstorydeliveryprocess,which is shown in

Figure6.4.

191

Figure6.4.TheUserStoryDeliveryProcess(Danevaetal.,2013).

They also identified 10 characteristics practices that should be followed while

gatheringandprioritisinguserstories.Anoverviewofthepracticesisgivenbelow:

i. Maintain traceability between the user stories and delivery stories. In their

research they introduced the concept of delivery stories. A delivery story

consistsofthefollowing:

• Numberofusecases

• Requiredtimeforusecasesimplementationinpersondays

• NumberofGUIscreens

• RequiredtimeforGUIscreensimplementationinpersondays

• Businessrulesandvalidations

• Numberoftestscenarios

• Requiredtimefortestcasespreparationinpersondays

• Requiredtimefordatamodelsinpersondays

• Totaltimerequiredforsub-processimplementation

192

ii. Establish a dedicated Delivery Story Team. According to their study in larger

projects,weneedtohaveaseparateteamtohandletherequirementsprocess.

Asunlikesmallprojectswhichdonothaveanydetailedrequirements,inlarge

projectsthereisaneedtoadddetailinrequirementstomakeiteasierforthe

offshoreteammembersandclientstounderstandwhattheyhavetodo.

iii. Run series of workshops, as it helps build trust between the client and

developmentsites.

iv. EstablishaDomainOwner.Asa resultof their study, theyhave introduceda

newroleofDomainOwner,andtheyclassifieditasacriticalroleforacquiring

knowledgeaboutthecorebusinessprocessesandoperationalprocedures.

v. Understandthedependenciesofrequirementsbeforecarryingoutthedesign

process.

vi. TheProductOwnerroleshouldbeset-upattheclient’ssite.

vii. Set-up a requirement change analysis management process, as the

requirementsdochangeoverthesoftwaredevelopmentlifecycle.

viii. DirectlyasktheProductOwnertoconfirmanychangeintherequirements.

ix. Inordertoencouragetransparency,usestatusreports,whichshouldbeshared

withtheclientaftereverythreeweeks.

x. Trainingonthedomainshouldbegradualandtheteamshouldbepreparedfor

it.Mostofthetimetrainingsweresupportedbytheclient’sorganisation.

However,SoBAhelps indocumentingandmanaginguserstories itdoesnotconsider

the complexity added by distributed agile developments such as any change in the

requirementsneedstobecommunicatedoverdifferent locationsandduetocultural

193

and language differences, requirements can be misunderstood (Patel et al., 2008).

Similarly the work done by Daneva does facilitate the practitioners by providing us

with a checklist of 10 practices to considerwhile documenting and prioritising user

storiesbut theydidnotconsider theaffectofculturaldifferencesandhow language

affects the requirements process and they introduced two new concepts such as

dedicatedteamforrequirementsandDomainowner,whichaddadditionalcosttothe

development,whileasmentionedinSection2.2.1,themainreasonfororganisations

tochoosetooffshoretheirprojects,istocutdownoncost(Danevaetal.,2013).

6.5DistributedAgilePatternsusedtoOvercomeRequirementsEngineering

Challenges

Inthissectionwewilldiscusshowdistributedagilepatternscanbeusedtoovercome

the challenges we identified in Section 2.4. However we will focus only on the

requirements engineeringprocess. The selectionof patternswasdone following the

processidentifiedinFigure4.1.

Table6.1.UsingDistributedAgilePatternstoAddressRequirementsEngineering

ChallengesinAgileOffshoreDevelopment.

No. Requirements

ChallengeinAgile

Offshore

Development

DistributedAgile

Pattern

Solution

1. Requirement

Estimation

CollectivePlanning

Poker

By doing the planning poker

activitytogetherallteammembers

will get a better understanding of

eachothersskills.

2.

Objectiveandcore

ProjectCharter

Havingaprojectcharterdocument

194

functional

requirements

writtenat the startof theproject,

will give all the team members a

clear understanding of the

project’s objective and core

functionalrequirements.

3.

Misunderstanding

ofrequirements

CollectiveProject

Planning

Since thewhole teamwill be part

of the planning activity, the

chances of misunderstanding a

requirementwillbereduced.

Asynchronous

Information

Transfer

In case of any misunderstanding,

the team members can

communicate with each other

usingasynchronoustools.

Synchronous

Communication

For a real-time response to any

misunderstanding, the team

members can use synchronous

methodsforcommunication.

4.

Vague

requirements

VisitOnshore-

Offshore

To clarify vague requirements,

onshore team members should

visit offshore team members and

vice versa to discuss the

requirements in order to avoid

defects.

5.

Changesinthe

requirements

GlobalScrumBoard

Any change in the requirements,

will be updated on the global

195

scrumboard,whichisaccessibleby

allteammembersinreal-time.

6.

Inconsistencies

CentralCode

Repository

To avoid any inconsistency

between the work done and the

userstories,alltheteammembers

use a central code repository,

which is accessible by the whole

team.Allthecodeiscommitted in

thatrepository,enablingthewhole

teamtoseewhatworkisdoneand

whatisremaining.

7.

Bidirectional

traceabilityof

requirements

CentralCode

Repository

With the help of a central code

repository, we can map each

requirementwithitscode,allowing

traceabilityofalltherequirements

being developed at different

locations.

GlobalScrumBoard

Status of all requirements being

developedcanberecordedusinga

globalscrumboard,whichhelpsin

maintaining traceability of

requirements.

8.

Managing

requirements

LocalSprint

Planning

Each site can manage their

requirements and daily meetings

usinglocalsprintplanning.

196

6.6MappingDistributedAgilePatternsontheRequirementsEngineering

Lifecycle

Inthissectionwemapthedistributedagilepatternsontothetraditionalrequirements

engineering lifecycle, to show how these patterns facilitate the requirements

engineeringprocess.AsshowninFigure6.5thefourkeyfeaturesofthisprocessareas

following:

• Feasibility Study: In this process, we decide whether or not the proposed

system is worthwhile. By writing down the Project Charter document in the

beginningoftheproject,wecanachievethis.AsstatedintheProjectCharter

we define the aim, objectives and core functional requirements of the

proposedsystem.

• Requirements Elicitation and Analysis: The purpose of this process is to

identify theapplicationdomain; the services itwill provideandwhat are the

limitations. Three distributed agile patterns are applied in these phases.

Collaborative project planning helps the team to find out what the

requirements of the application to be developed. Local sprint planning helps

teammembersintheirrespectivelocationstodiscussindetailtheuserstories

allocated to them and determine the constrains associated with them.

CollaborativePlanningPoker,allowstheteammemberstodiscusstheservices

that the system will provide and estimate how much effort is required to

developthem.

• Requirements Specification:Oncetherequirementshavebeen identified,we

document them in the SRS document. As in agile software development,

requirementsaredocumentedusinguserstories, indistributedagilesoftware

development; we use a Global Scrum Board, where all the story cards are

placed.Henceanychangeormodificationintherequirementswillbeupdated

ontheGlobalScrumBoard,whichisaccessiblebyalltheteaminreal-time.

197

• Requirements Validation: In this process, the requirements are validated, by

reviewing them to make sure that the identified requirements are in

accordancewithwhat the clientwants. Four distributed agile patternsmake

sure that the correct requirements are identified. Central Code Repository

helps the client verify that the code being developed is according to

requirements. Asynchronous Information Transfer provides a platform to the

teammembersandtheclientstocommunicateandcoordinatetheprogressof

thesystembeingdevelopedandincaseofanyconfusion,theteamcaneither

use asynchronous or synchronous tools for communication, according to the

communicationstandardsdefinedusingSynchronousCommunicationPattern.

Forfurtherclarificationofrequirements,distributedagilepatternssuggestthat

bothonshoreandoffshoreteammembersshouldvisiteachother.

InFigure6.5wehavepresentedhowourdistributedagilepatternsmapontothefour

phases of traditional requirement engineering in order to provide an overview to

practitioners on which distributed agile pattern they can use while collecting

requirements for their offshore projects. For example in order to perfome the

requirementselicitationandanalysisphaseintherequirementengineeringprocessof

anoffshoreproject,thepractitionercanusecollaborativeprojectplanning,localsprint

planningandcollaborativeplanningpokerpatterns

Figure6.5.MappingDistributedAgilePatternsonTraditionalRequirements

EngineeringProcess.

198

6.7ChapterSummary

Thischapterpresentedacasestudytoshowhowthedistributedagilepatternscanbeusedin

offshoresoftwaredevelopment.Thefocusofthiscasestudywasontherequirementphaseof

the software development lifecycle so the chapter starts by giving an overview on the

requirementengineeringprocess.Thenweprovidedacomparisonbetweentherequirement

process in traditional software development vs. agilemethodology. Several approaches to

improve the requirementprocess in agilewere alsodiscussed in this chapter. Basedon the

offshore challenges identified in chapter 2we discussed how the distributed agile patterns

cataloguecanbeusedtoovercomethem.Lastlywemappedthedistributedagilepatternson

therequirementengineeringlifecycle.

The next chapter concludes the thesis, discussing the main achievements of the

research and proposing a set of recommendations for improvements in future

research.

199

Chapter7 ConclusionsandFutureWork

7.1Introduction

This research has studied the factors that effect software development in offshore

environment. Itaimedto identifyandaddressthefactorsthataffecttheadoptionof

agilepracticesinoffshoresoftwaredevelopment.Inordertoachievetheresearchaim

andobjectives, toanswer the researchquestionsand tomaximize thequalityof the

casestudyfindingtherewasaneedtochoosethemostappropriateresearchapproach

and strategy for the researcher to follow in collecting and analysing the data. The

selection of an appropriate methodology for this research came by following a

literaturereviewbasedontheresearchtopic,settingtheaimandobjectivesandafter

considerationofliteratureonresearchmethodologies.

Based on the nature of this research, the phenomenological research paradigm and

the use of both qualitative and quantitative philosophy were reasoned to be as

discussed in Section 3.3, the perfect means to undertake the research due to its

subjectivityandinordertogainin-depthunderstandingandtoidentifythefactorsthat

affect theadoptionofagilepractices inoffshoresoftwaredevelopment.Asadopting

agilepractices inoffshoresoftwaredevelopment isnota straightforwardprocess. In

this research we have conducted a systematic literature review and semi-structure

interview to identify agile practices that are being repeatedly used in offshore

developmenttosolverecurringproblems.Asaresult,weidentified15distributedagile

patterns,whichwerepresentedinSection4.5.Tovalidatethepatternscataloguewe

used a reflection workshop and for evaluation we compared our solution to other

existing solutions present in literature to overcome offshore challenges, which we

havepresentedinChapter5.

Inordertohelppractitionersunderstandhowthedistributedagilepatternscatalogue

canbeused at anydevelopmentphasewepresented a case study inChapter 6, on

200

how the catalogue can be used in the requirement phase of scrum based software

development.

7.2MeetingtheAimandObjectivesandAnsweringtheResearchQuestions

Themain researchquestionwasansweredbyachieving theaimof this study,which

was to address the issues between the onshore and offshore teams that are

developing software at offshore locations and to develop a solution by identifying

repeatingsolutions from literatureand interviewingprofessionals.Thisaimhasbeen

achievedbyaddressingtheresearchobjectivesasfollows:

The first objective was to review the relevant literature on offshore software

development.The literature includedstudies focusingonwhyorganisationschoseto

movestheirprojectstooffshorelocations,whataredifferenttypesofglobalsoftware

developmentbusinessmodels,whataretheadvantagesandlimitationsofchoosingto

develop software at different locations, how did organisation overcome offshore

softwaredevelopmentchallenges.

Thesecondobjectivewastoidentifykeychallengesthatoccurwhileoffshoresoftware

development and if any recurring agile practices are being used to overcome an

offshore challenges. We achieved this by conducted a SLR and semi-structured

interviewsaswewantedtoidentifypatterns.

Based on the data collected and analysis, we identified agile practices recurrently

being used to solve offshore software development challenges. Based on observed

recurringpracticeswedesignedourdistributedagilepatternscatalogue,whichisthe

thirdobjectiveofourresearch.

The fourth objective was to validate and evaluate the distributed agile patterns

catalogue, whichwe achieved by conducting reflectionworkshop and based on the

feedback we revised our patterns catalogue and for evaluation we compared our

201

patterns catalogue with other solutions such as using ontology-based multi-agent

approach, experiments for offshore projects designed by Larman et at. (2010), the

detail is presented in Section 5.3. The last objective was to write this thesis and

presentitintheviva.

7.3RecommendationforFutureWork

Futureworkhasbeenplannedforthisresearch,whichincludeswaysonhowwecan

improve and extend the research presented in this study. The following

recommendationsarisefromthepresentstudyforfutureacademicsandprofessional

researchthatwanttoworkinoffshoresoftwaredevelopmentandagilemethodology:

- Researchers could investigate and identify the factors that effect the

developmentofsoftwareindomesticoutsourcing,sharedservicesandinternal

offshoring as in this research we have only focused on identifying the

challengesinoffshoreoutsourcingbusinessmodel.

- Onemajordirection for futureworkwouldbe toapply this catalogue for the

developmentofanoffshoresoftwareprojectthatwanttoadoptagilepractices

andstudytheimpactofeachpatternondifferentdevelopmentstages.

- Designadecisionmakingtooltohelppractitionersenterthechallengetheyare

facing or what process they want to apply and get a list of recommended

distributedpatternsthatcouldbeusedtoovercomeit.Thepurposeofthetool

wouldbetoprovideeasetopractitioners,asgoingthroughallfifteenpatterns

canbetimeconsuming.

- Furtherresearch isneeded into identifyinghowdevelopmentofthecodecan

beimprovedandidentifiesthatisdesignasetofrulestobefollowedonhow

frequentthedevelopersneedtocommittheircodeandidentifypatternsfrom

202

howpractitionersaredevelopingtheircodeinordertoprovideaguidelineon

howtomanageandwritequalitycodeinoffshoresoftwaredevelopment.

- Researcherscancompareotherdevelopment lifecyclessuchasad-hoc, linear,

evolutionary,iterativeandincrementalapproachesasdefinedinAppendixB,to

identifypatternsforoffshoresoftwaredevelopmentandevaluatethemagainst

the distributed agile patterns catalogue to determine if they produce better

resultsornot.

- Finally researchers can explore designing solutions other then patterns and

evaluate their solutions with distributed agile patterns catalogue and

determineiftheirsolutionspresentbetterresultsthenourcatalogue.

7.4LimitationoftheStudy

AccordingtoYin(2003)everyresearchstudyislimitedbytheconstraintsplacedupon

theresearchandtheresearchenvironment,andthisresearchisnoexception.Inthis

researchwehavemadeeveryefforttoovercometheselimitationtoensurethatthis

studycouldbedeliveredsmoothly,butitisnotpossibletocontrolallthefactorsthat

werelikelytoaffecttheoutcomes.

Thelimitationsofthisresearchasarefollowing:

- Somecasesidentifiedinliterature,justmentionednamesofpracticesanddid

not provide details of how they are to be implemented or what the results

wereaftertheyimplementedanadaptedagilepractice.

- Another limitation was that researchers had identified offshore software

development challenges but had not considered the complexity add by

adoptingagilepractices,whichlimitedourdatafromliteratureandwehadto

203

reply on interviews to verify agile practices actually used in offshore

development.

- Afinallimitationwasthataswealsocollecteddatafrominterviews,thehuman

factor can not be ignored, that is since the organisation chose to remain

anonymous,somefactswerenotallowedtobemadepublicsuchaswhatwas

thenatureoftheprojectsbeingoffshored,howcriticalthedatabeingshared

to offshore locations was and what legal arrangements they had with the

offshore developers regarding sharing of information for the purpose of

research.

7.5ChapterSummary

This chapter has presented an overall conclusion for the thesis. The aim of the

research, the objectives, and the techniques that were used by the researcher to

achieve the study objectives were addressed; and in final conclusion, the chapter

outlinedpotentialfuturedirections,whichcouldbeadoptedasfurtherresearchwork.

204

References:

Abrahamsson,Pekka,JuhaniWarsta,MikkoT.Siponen,andJussiRonkainen(2003)."Newdirections

on agile methods: a comparative analysis." In Software Engineering, 2003. Proceedings. 25th

InternationalConferenceon,pp.244-254.IEEE.

Agerfalk, Par J., and Brian Fitzgerald (2008). "Outsourcing to an unknown workforce: Exploring

opensourcingasaglobalsourcingstrategy."MISquarterly32,no.2,385.

Alexander, Christopher (1977). A pattern language: towns, buildings, construction. Oxford

UniversityPress,1977.

Alnuem, Mohammed Abdullah, Arshad Ahmad, and Hashim Khan (2012). "Requirements

Understanding: A Challenge in Global Software Development, Industrial Surveys in Kingdom of

SaudiArabia."In2012IEEE36thAnnualComputerSoftwareandApplicationsConference,pp.297-

306.IEEE,2012.

Alzoubi, Yehia Ibrahim, Asif Qumer Gill, and Ahmed Al-Ani (2016). "Empirical studies of

geographically distributed agile development communication challenges: A systematic

review."Information&Management53,no.1(2016):22-37

Al-Zaidi, Areej, and Rizwan Qureshi (2017). "Global software development geographical distance

communicationchallenges."Int.ArabJ.Inf.Technol.14,no.2(2017):215-222.

AnthonyByrd.T,K.L.C.,RobertW.Zmud,(1992).ASynthesisofResearchonRequirementsAnalysis

andKnowledgeAcquisitionTechniques.MISQuarterly,1992.Vol.16(No.1):p.pp.117-138

Armour,PhillipG(2007)."Agile…andoffshore."CommunicationsoftheACM50,no.1(2007):13-

16.

Aron,Ravi,andJitendraV.Singh(2005)."Gettingoffshoringright."Harvardbusinessreview83,no.

12,135.

Aronsson,Cecilia.(2007)”Krigetomtalangerna”,VeckanAffärer,nr8,p44.

Avritzer, Alberto, Francois Bronsard, and GilbertoMatos (2010). "Improving Global Development

UsingAgile."InAgilityAcrossTimeandSpace,pp.133-148.SpringerBerlinHeidelberg,2010.

205

Avritzer,Alberto,WilliamHasling,andDanielPaulish(2007)."Process investigationsfortheglobal

studio project version 3.0." In Global Software Engineering, 2007. ICGSE 2007. Second IEEE

InternationalConferenceon,pp.247-251.IEEE,2007.

Babu,Mohan (2005).Offshoring IT services: a framework formanagingoutsourcedprojects. Tata

McGraw-HillEducation.

Beck,Kent,MikeBeedle,ArieVanBennekum,AlistairCockburn,WardCunningham,MartinFowler,

JamesGrenningetal.(2001)."Manifestoforagilesoftwaredevelopment”.

Beecham, Sarah, John Noll, and Ita Richardson (2014). "Using Agile Practices to Solve Global

SoftwareDevelopmentProblems--ACaseStudy." In2014 IEEE InternationalConferenceonGlobal

SoftwareEngineeeringWorkshops,pp.5-10.IEEE,2014.

Berczuk, Steve. "Back to basics: The role of agile principles in successwith an distributed scrum

team."InAgileConference(AGILE),2007,pp.382-388.IEEE,2007.

Berenbach,B. (2006). Impactoforganizational structureondistributed requirementsengineering

processes: lessons learned. InProceedingsof the2006 internationalworkshoponGlobalsoftware

developmentforthepractitioner(GSD'06).ACM,NewYork,NY,USA,15-19.

Beulen, Erik, Paul Van Fenema, and Wendy Currie (2005). "From Application Outsourcing to

Infrastructure Management:: Extending the Offshore Outsourcing Service Portfolio."European

ManagementJournal23,no.2,133-144.

Bhat, J.M., Gupta, M., Murthy, S.N. (2006). Overcoming Requirements Engineering Challenges:

LessonsfromOffshoreOutsourcing.IEEESoftw.23,5(September2006),38-44.

Bricout,V.,Heliot,D.,Cretoiu,A.,Yang,Y.,Simien,T.,andHvatum,L.,(2005).Patternsformanaging

distributedproductdevelopmentteams.Tech.rep.,SchlumbergerOilfieldServices.

Bird,C.,Nagappan,N.,Devanbu,P.,Gall,H.,andMurphy,B.(2009).Doesdistributeddevelopment

affectsoftwarequality?AnempiricalcasestudyofWindowsVista.InProceedingsofthe31st

InternationalConferenceonSoftwareEngineering(ICSE'09).IEEEComputerSociety,Washington,

DC,USA,518-528.

206

Braithwaite,Keith,andTimJoyce(2005)."XPexpanded:Distributedextremeprogramming."

InExtremeprogrammingandagileprocessesinsoftwareengineering,pp.180-188.SpringerBerlin

Heidelberg.

Bryman,Alan(2012).Socialresearchmethods(5thed.).Oxford:OxfordUniversityPress.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Sommerlad, P., & Stal, M.

(1996).Pattern-orientedsoftwarearchitecture,volume1:Asystemofpatterns.

Bosch, J., and Bosch-Sijtsema, P. (2010). From integration to composition: On the impact of

softwareproductlines,globaldevelopmentandecosystems.J.Syst.Softw.83,1(January2010),67-

76

Boon,S.,andHolmes, J. (1991).Thedynamicsof interpersonal trust:Resolvinguncertainty in the

face of risk.In R. Hinde and J. Groebel (Eds.). Cooperation and Prosocial Behavior. Cambridge

UniversityPress,Cambridge,UK.190–211.

Bose, Indranil (2008). "Lessons learned from distributed agile software projects: A case-based

analysis."CommunicationsoftheAssociationforInformationSystems23,no.1(2008):34.

Brown, W.J., Malveau, R.C., McCormick, H.W.S., Mowbray, T.J. (1988): AntiPatterns: Refactoring

Software,Architectures,andProjectsinCrisis.J.Wiley,1998.

Čavrak, I., Orlić, M., and Crnković, I. (2012). Collaboration patterns in distributed software

developmentprojects.InProceedingsofthe34thInternationalConferenceonSoftwareEngineering

(ICSE'12).IEEEPress,Piscataway,NJ,USA,1235-1244

Camacho,C.,Marczak,S.,andConte,T.(2013).OntheIdentificationofBestPracticesforImproving

the Efficiency of Testing Activities in Distributed Software Projects: Preliminary Findings from an

Empirical Study. InProceedingsof the2013 IEEE8th InternationalConferenceonGlobal Software

EngineeringWorkshops(ICGSEW'13).IEEEComputerSociety,Washington,DC,USA,1-4.

Carmel,Erran(1999).Globalsoftwareteams:collaboratingacrossbordersandtimezones.Prentice

HallPTR.

Carmel, Erran, and Ritu Agarwal (2001). "Tactical approaches for alleviating distance in global

softwaredevelopment."Software,IEEE18.2,22-29.

207

Carmel,Erran,andPaulTjia(2005.).Offshoringinformationtechnology:sourcingandoutsourcingto

aglobalworkforc.CambridgeUniversityPress.

Cataldo, M., Bass, M., Herbsleb, J.D., Bass, L. (2007). On Coordination Mechanisms in Global

Software Development. In Proceedings of the International Conference on Global Software

Engineering(ICGSE'07).IEEEComputerSociety,Washington,DC,USA,71-80.

Clark, Herbert H., and Susan E. Brennan (1991). "Grounding in communication." Perspectives on

sociallysharedcognition13,no.1991(1991):127-149.

Clerc, V. (2008). Towards architectural knowledge management practices for global software

development.InProceedingsofthe3rdinternationalworkshoponSharingandreusingarchitectural

knowledge(SHARK'08).ACM,NewYork,NY,USA,23-28.

Conchúir,EoinÓ.,Pär J.Ågerfalk,HelenaH.Olsson,andBrianFitzgerald (2009). "Global software

development:wherearethebenefits?."CommunicationsoftheACM52,no.8.127-131.

Conchúir,E.,Holmström,H.,Ågerfalk,P.J.andFitzgerald,B.(2006).ExploringtheAssumedBenefits

of Global Software Development. In Proceedings of the IEEE international conference on Global

SoftwareEngineering(ICGSE'06).IEEEComputerSociety,Washington,DC,USA,159-168.

Cordeiro, Lucas, Cassiano Becker, and Raimundo Barreto (2007). "Applying Scrum and

OrganizationalPatternstoMulti-siteSoftwareDevelopment."(2007):46-67.

Cottmeyer, Mike (2008). "The good and bad of Agile offshore development." In Agile, 2008.

AGILE'08.Conference,pp.362-367.IEEE,2008.

Cristal,Mauricio,DanielWildt, andRafael Prikladnicki (2008). "Usageof Scrumpracticeswithin a

globalcompany."InGlobalSoftwareEngineering,2008.ICGSE2008.IEEEInternationalConference

on,pp.222-226.IEEE,2008.

Damian, Daniela, and Deependra Moitra (2006). "Guest Editors' Introduction: Global Software

Development:HowFarHaveWeCome?."Software,IEEE23,no.5,17-19.

Damian, Daniela E., and Didar Zowghi (2003). "RE challenges inmulti-site software development

organisations."Requirementsengineering8,no.3(2003):149-160.

Danait, Ajay (2005). "Agile offshore techniques-a case study." In Agile Conference, 2005.

208

Proceedings,pp.214-217.IEEE,2005.

Daneva,Maya, Egbert VanDer Veen, ChintanAmrit, SmitaGhaisas, Klaas Sikkel, Ramesh Kumar,

NiravAjmeri,UdayRamteerthkar,andRoelWieringa. (2013). "Agile requirementsprioritization in

large-scale outsourced systemprojects: An empirical study." Journal of systemsand software 86,

no.5(2013):1333-1353.

Darke, Peta (1997). G.G.S., User viewpoint modelling: understanding and representing user

viewpointsduringrequirementsdefinition. InformationSystemsJournal,1997.Volume7(Issue3):

p.pages213-219.

Das,TarunK.,andBing-ShengTeng (1998). "Between trustandcontrol:developingconfidence in

partnercooperationinalliances."AcademyofManagementreview23,no.3,491-512.

Davenport, Thomas, H., and Prusak, Laurence, (1998). Working knowledge. Boston: Harvard

BusinessSchoolPress.

Davis, A.M (1989). Software Requirements: Analysis and Specification. 1989: Prentice Hall. 352

pages.

Denny, Nathan, Shivram Mani, Ravi Sheshu Nadella, Manish Swaminathan, and Jamie Samdal

(2008). "Hybrid offshoring: Composite personae and evolving collaboration technologies."

InformationResourcesManagementJournal(IRMJ)21,no.1(2008):89-104.

Dingsøyr,Torgeir, SridharNerur,VenuGopalBalijepally, andNilsBredeMoe (2012). "Adecadeof

agile methodologies: Towards explaining agile software development."Journal of Systems and

Software85,no.6,1213-1221.

Dourish, Paul, and Victoria Bellotti. (1992). Awareness and coordination in shared

workspaces.Proceedings of the 1992 ACM conference on Computer-supported cooperative work.

ACM.

Drummond, B., and John Francis Unson (2008). "Yahoo! Distributed Agile: Notes from theworld

over."InAgile,2008.AGILE'08.Conference,pp.315-321.IEEE,2008.

Dybå, Tore, and Torgeir Dingsøyr (2008). "Empirical studies of agile software development: A

systematicreview."Informationandsoftwaretechnology50,no.9,833-859.

209

Easterby-Smith, M., Thorpe R. and Lowe A. (2004) Management Research: An Introduction,2nd

Edition.SAGEPublicationsLtd.London.

Easterby-Smith,Mark, Richard Thorpe, and Paul R. Jackson (2012).Management research. Sage,

2012.

Ebert, Christof (2011).Global software and IT: A guide to distributed development, projects, and

outsourcing.Wiley-IEEEComputerSocietyPress

Elssamadisy,Amr,andDavidWest(2006)."Adoptingagilepractices:anincipientpatternlanguage."

InProceedingsofthe2006conferenceonPatternlanguagesofprograms,p.1.ACM,2006.

Flick, Uwe. (2011). Introducing research methodology: A beginner's guide to doing a research

project.London:Sage.

Fowler, Martin (1997). Analysis patterns: reusable object models. Addison-Wesley Professional,

1997.

Fowler, Martin. Daily Standup Patterns. Available at:

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

Fowler,Martin(2005).TheNewMethodology.2005.<http://www.martinfowler.com>.

Galen,Robert(2009)SCRUMProductOwnership–BalancingValuefromtheInsideOutRGCGLLC

2009.ISBN:978-0-578-01912-3

Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: elements of

reusableobject-orientedsoftware.PearsonEducation,1997.

Ghafoor,Fawad,IbrarAliShah,andNasirRashid(2017)."IssuesinAdoptingAgileMethodologiesin

GlobalandLocalSoftwareDevelopment:ASystematicLiteratureReviewProtocolwithPreliminary

Results."InternationalJournalofComputerApplications160,no.7.

Garner, C. Alan (2004). Offshoring in the service sector: Economic impact and policy

issues.EconomicReview-FederalReserveBankofKansasCity89,5-38.

GlobalWagesComparisonfromhttp://www.paywizard.co.uk/main/pay/global-wage-comparison

210

Goddard, W. & Melville, S. (2004). Research Methodology: An Introduction, (2nd ed.) Oxford:

BlackwellPublishing.

Grechanik,M.,Jones,J.A.,Orso,A.,andvanderHoek,A.(2010).Bridginggapsbetweendevelopers

andtestersinglobally-distributedsoftwaredevelopment.InProceedingsoftheFSE/SDPworkshop

onFutureofsoftwareengineeringresearch(FoSER'10).ACM,NewYork,NY,USA,149-154.

Gupta,Amar(2007)."Expandingthe24-hourworkplace."TheWallStreetJournal:15-16.

Gupta,Amar(2009)."Derivingmutualbenefitsfromoffshoreoutsourcing."Communicationsofthe

ACM52,no.6:122-126.

Gutwin, Carl, Saul Greenberg, and Mark Roseman (1996). "Workspace awareness in real-time

distributedgroupware:Framework,widgets,andevaluation."PeopleandComputers.281-298.

Hayes ,L.G (2003). “Everything you know about Offshore Outsourcing is Wrong”, Datamation

Magazine,Feb28,2003.

HendrikC.Jahn,AlexandraGazendamandAndréSchlieker(2011)Accenture:Thehigh-performance

insurer of the future, Accenture. [Available at:

http://nstore.accenture.com/Geneva/HP_Insurer_of_the_Future_report.pdf]

Herbsleb,JamesD.,AudrisMockus,ThomasA.Finholt,andRebeccaE.Grinter(2001)."Anempirical

study of global software development: distance and speed." In Proceedings of the 23rd

internationalconferenceonsoftwareengineering,pp.81-90.IEEEComputerSociety,2001.

Herbsleb, J.D. (2007).GlobalSoftwareEngineering:TheFutureofSocio-technicalCoordination. In

Future of Software Engineering (2007). IEEE Computer Society, Washington, DC, USA, 188-198.

DOI=http://dx.doi.org/10.1109/FOSE.2007.11.

Herbsleb, J.D. Paulish, D.J. and Bass, M. (2005). Global software development at siemens:

experience from nine projects. In Proceedings of the 27th international conference on Software

engineering(ICSE'05).ACM,NewYork,NY,USA,524-533.

Hitt, Michael A., R. Duane Ireland, and Robert E. Hoskisson (2002).Strategic Management:

CompetitivenessandGlobalization.South-WesternCollegePub.,Canada.

211

Hofner, Gerd, and V. S. Mani (2007). "TAPER: A generic framework for establishing an offshore

developmentcenter."InGlobalSoftwareEngineering,2007.ICGSE2007.SecondIEEEInternational

Conference,162-172.

Hofstede,Geert(1980).Culture'sconsequences.BeverlyHills,CA:Sage,1980.

Hofstede,Geert(1997)Cultureandorganizations--Softwareofthemind:McGraw-Hill,1997.

Holmström,Helena,BrianFitzgerald,PärJ.Ågerfalk,andEoinÓ.Conchúir."Agilepracticesreduce

distanceinglobalsoftwaredevelopment."InformationSystemsManagement23,no.3(2006):7-18.

Holmstrom,H.,Conchúir,E.Ó.,Agerfalk, J.,&Fitzgerald,B. (2006).Global softwaredevelopment

challenges:Acasestudyontemporal,geographicalandsocio-culturaldistance.InGlobalSoftware

Engineering,2006.ICGSE'06.InternationalConference),3-11.

Hossain,Emam,MuhammadAliBabar,andHye-youngPaik(2009)."Usingscruminglobalsoftware

development: a systematic literature review." InGlobal Software Engineering, 2009. ICGSE 2009.

FourthIEEEInternationalConferenceon,pp.175-184.Ieee,2009.

Humphrey,WattsS(1989).ManagingtheSoftwareProcess.Addison-WesleyProfessional.

Hussey,Jill,andRogerHusse(1997)y."Businessresearch."Hampshire:Palgrave(1997).

Hvatum, Lise B., and Rebecca Wirfs-Brock (2015). "Patterns to build the magic backlog." In

Proceedingsofthe20thEuropeanConferenceonPatternLanguagesofPrograms,p.12.ACM,2015.

Jaakkola, H., Heimbürger, A., and Linna, P. (2010). Knowledge-oriented software engineering

processinamulti-culturalcontext.SoftwareQualityControl18,2(June,2010).299-319.

Jacobs,D.,RequirementsEngineeringsoThingsDon'tGetUgly,inCompaniontotheproceedingsof

the29th InternationalConferenceonSoftwareEngineering.2007, IEEEComputerSociety.p.159-

160.

Jahns,Christopher,EviHartmann,andLydiaBals(2006)."Offshoring:Dimensionsanddiffusionofa

newbusinessconcept."JournalofPurchasingandSupplyManagement12.4,218-231.

212

Jan,SyedRoohullah,FaheemDad,NoumanAmin,AbdulHameed,andSyedSaadAliShah(2016).

"Issues in Global Software Development (Communication, Coordination and Trust) A Critical

Review."training6,no.7(2016):8.

Jankowicz,A.Devi(2005).Businessresearchprojects.CengageLearningEMEA,2005.

Javdani Gandomani, Taghi, Hazura Zulzalil, Abdul Azim Abdul Ghani, Abu Bakar Md Sultan, and

KhaironiYatimShairf (2014). "Exploring facilitatorsof transitionandadoptiontoagilemethods:a

groundedtheorystudy."JournalofSoftware9,no.7(2014):1666-1678.

Javidan,Mansour,GünterK.Stahl,FelixBrodbeck,andCelestePMWilderom(2005)."Cross-border

transfer of knowledge: Cultural lessons from Project GLOBE."The Academy of Management

Executive19,no.2,59-76.

Jensen,B.andZilmer,A.(2003).Cross-continentdevelopmentusingScrumandXP.Proceedingsof

XP.SpringerBerlin,,pp.146-153

Kanawattanachai,Prasert,andYoungjinYoo(2002)."Dynamicnatureoftrustinvirtualteams."The

JournalofStrategicInformationSystems11,no.3,187-213.

Kamaruddin,NinaKamarina,NoorHabibahArshad,andAzlinahMohamed(2012)."Chaosissueson

communication in Agile Global Software Development." In Business Engineering and Industrial

ApplicationsColloquium(BEIAC),2012IEEE,pp.394-398.IEEE,2012.

Kausar, Maryam and Adil Al-Yasiri (2015). “Distributed Agile Patterns for Offshore Software

Development”12thInternationalJointConferenceonComputerScienceandSoftwareEngineering

(JCSSE),IEEE2015

Kausar, Maryam and Adil Al-Yasiri (2016). Distributed Agile Patterns. [Available at:

http://stp872.edu.csesalford.com/distributedagilepatterns.html]

Kedia, Ben L. and Lahiri, Somnath, (2007), International outsourcing of services: A partnership

model.Memphis:JournalofInternationalManagement,13,22–37

Kerth, Norm (2001). "Project Retrospectives: A Handbook for Reviews."Dorset House Publishing

(2001).

213

Khan, Huma Hayat, Mohd Naz’ri binMahrin, and Suriayati bt Chuprat. "Factors generating risks

during requirement engineering process in global software development environment."

InternationalJournalofDigitalInformationandWirelessCommunications(IJDIWC)4,no.1(2014):

63-78.

Kircher, M., Jain, P., Corsaro, A. and Levine, D. (2001). Distributed Extreme Programming.

Proceedings of the International Conference on eXtreme Programming and Flexible Processes in

SoftwareEngineering,Sardinia,Italy,May20-23,2001.

Kitchenham, B.& Charters, S. (2007), Guidelines for performing Systematic Literature Reviews in

SoftwareEngineering,EBSE2007-001,KeeleUniversityandDurhamUniversityJointReport.

Kluckhohn,FlorenceR.,andFredL.Strodtbeck(1961)."Variationsinvalueorientations."(1961).

Kobayashi-Hillary, M. (2005). Outsourcing to India: The offshore advantage. Springer Science &

BusinessMedia.

Koehne, B., Shih, P.C., and Olson, J.S. (2012). Remote and alone: coping with being the remote

member on the team. In Proceedings of the ACM 2012 conference on Computer Supported

CooperativeWork(CSCW'12).ACM,NewYork,NY,USA,1257-1266.

Kommeren, R., and Parviainen, P. (2007). Philips experiences in global distributed software

development. Empir. Softw. Eng. 12, 6 (December, 2007), 647-660.

DOI=http://dx.doi.org/10.1007/s10664-007-9047-3.

Kontio, Jyrki, Magnus Hoglund, Jan Ryden, and Pekka Abrahamsson (2004). "Managing

commitments and risks: challenges in distributed agile development." InSoftware Engineering,

2004.ICSE2004.Proceedings.26thInternationalConferenceon,pp.732-733.IEEE

Korkala,Mikko,Minna Pikkarainen, and Kieran Conboy (2010). "Combining agile and traditional:

Customer communication indistributedenvironment." InAgilityAcrossTimeandSpace, pp.201-

216.SpringerBerlinHeidelberg,2010.

Kotlarsky,Julia,andIlanOshri(2005)."Socialties,knowledgesharingandsuccessfulcollaborationin

globallydistributedsystemdevelopmentprojects."EuropeanJournalofInformationSystems14,no.

1,37-48.

214

Krippendorff,Klaus.(2004).Contentanalysis:Anintroductiontoitsmethodology,ThousandOaks,

CA:SagePublications.

Kroll,Josiane,AlanR.Santos,RafaelPrikladnicki,EstevãoRicardoHess,RafaelA.Glanzner,Afonso

Sales, Jorge Luis Nicolas Audy, and Paulo Henrique Lemelle Fernandes (2012). "Follow-the-Sun

Software Development: A Controlled Experiment to Evaluate the Benefits of Adaptive and

PrescriptiveApproaches."InSEKE,pp.551-556.2012.

Kussmaul,Clifton,RogerJack,andBarrySponsler(2004)."Outsourcingandoffshoringwithagility:A

case study." In Extreme Programming and Agile Methods-XP/Agile Universe 2004, pp. 147-154.

SpringerBerlinHeidelberg,2004.

Lander,MariaCristina,RussellL.Purvis,GordonE.McCray,andWilliamLeigh(2004).Trust-building

mechanisms utilized in outsourced IS development projects: a case study.Information &

Management41,no.4.509-528.

Lanubile, Filippo, Fabio Calefato, and Christof Ebert (2013). Group Awareness in Global Software

Engineering.IEEESoftware.18-23.

Larman,Craig(2004).AgileandIterativeDevelopment:AManager'sGuide.Addison-Wesley.p.27.

ISBN978-0-13-111155-4

Larman, Craig (2010). Practices for Scaling Lean and Agile Development: Large. Addison-Wesley

Professional,2010.

Layman,L.,Williams,L.,Damian,D.and Bures,H. (2006.) Essential communication practices for

extreme programming in a glob- al software development team. Information and Software

Technology,vol.48,no.9,pp.781-794

Lee, SangM., and Suzanne J. Peterson (2001) . "Culture, entrepreneurial orientation, and global

competitiveness."Journalofworldbusiness35,no.4(2001):401-416.

Lescher, Christian (2010). "Patterns for global development: how to build one global team?."

Proceedingsofthe15thEuropeanConferenceonPatternLanguagesofPrograms.ACM,2010.

Liskin, O., Herrmann, C., Knauss, E., Kurpick, T., Rumpe, B., and Schneider, K. (2012). Supporting

AcceptanceTestinginDistributedSoftwareProjectswithIntegratedFeedbackSystems:Experiences

and Requirements. In Proceedings of the 2012 IEEE Seventh International Conference on Global

215

SoftwareEngineering(ICGSE'12).IEEEComputerSociety,Washington,DC,USA,84-93.

MacGregor,Eve,YvonneHsieh,andPhilippeKruchten(2005)."Culturalpatternsinsoftwareprocess

mishaps: incidents inglobalprojects." InACMSIGSOFTSoftwareEngineeringNotes,vol.30,no.4,

pp.1-5.ACM,2005.

Malik,Fareesa,andHammadMajeed(2010)."EffectofDevelopmentStrategiesandProjectTypes

onOffshoreSoftwareDevelopmentusingAgileParadigm–AStudy." In2010AgileConference,pp.

67-74.IEEE,2010.

Massol,Vincent(2004),Technicaltalkon“AgileOffshoreMethods”TheServerSide.com,Jan6,2004

Maruping,LikoebeM(2010)."ImplementingExtremeProgramminginDistributedSoftwareProject

Teams: Strategies and Challenges." In Agility Across Time and Space, pp. 11-30. Springer Berlin

Heidelberg,2010.

Massol,Vincent(2004)."“CaseStudy:DistributedAgileDevelopment."TheServerSide.com(2004).

Matloff,Norman(2005)."Offshoring:Whatcangowrong?."ITprofessional7,no.4,39-45.

May,Tim(2011).Socialresearch.McGraw-HillEducation(UK),2011.

Modi, Sunila, Pamela Abbott, and Steve Counsell (2013). "Negotiating common ground in

distributedagiledevelopment:Acasestudyperspective." InGlobalSoftwareEngineering (ICGSE),

2013IEEE8thInternationalConferenceon,pp.80-89.IEEE,2013.

Morgan, Robert M., and Shelby D. Hunt (1994). "The commitment-trust theory of relationship

marketing."thejournalofmarketing,20-38.

Mullick,N.,Bass,M.,Houda,Z.,Paulish,P.,andCataldo,M.(2006).SiemensGlobalStudioProject:

Experiences Adopting an Integrated GSD Infrastructure. In Proceedings of the IEEE international

conference on Global Software Engineering (ICGSE '06). IEEE Computer Society,Washington, DC,

USA,203-212.

Newman,Isadore.(1998).Qualitative-quantitativeresearchmethodology:Exploringtheinteractive

continuum.Carbondale:SouthernIllinoisUniversityPress.

216

Niazi, M., El-Attar, M., Usma, M., and Ikram, N. (2012). GlobReq: A framework for improving

requirements engineering in global software development projects: Preliminary results. In

proceedings of the 16th International Conference on Evaluation & Assessment in Software

Engineering(EASE2012).(May14-15,2012)166-170.

Nisar, Muhammad F., and Tahir Hameed (2004). "Agile methods handling offshore software

developmentissues."InMultitopicConference,2004.ProceedingsofINMIC2004.8thInternational,

pp.417-422.IEEE.

Noll, J., Richardson, I., & Beecham, S. (2014). Patternizing GSD Research: Maintainable Decision

SupportforGlobalSoftwareDevelopment.

OECD (2004).OECD information technologyoutlook:Organisation foreconomic co-operationand

development.RetrievedJanuary2009,fromhttp://www.oecd.org/dataoecd/22/18/37620123.pdf.

Oshri, Ilan, Julia Kotlarsky, and Leslie P. Willcocks.The Handbook of Global Outsourcing and

Offshoring3rdEdition.Springer,2015.

Ovaska, P., Rossi, M. and Marttiin, P. (2003). Architecture as a coordination tool in multi-site

softwaredevelopment.Softw.Process:Improve.Pract.8(2003)233–247.

Ozawa,H.,&Zhang,L.(2013).AdaptingAgileMethodologytoOvercomeSocialDifferencesin

ProjectMembers.InAgileConference(AGILE),2013(pp.82-87).IEEE.

Paasivaara,Maria,andCasperLassenius(2003)."Collaborationpracticesinglobalinter-

organizationalsoftwaredevelopmentprojects."SoftwareProcess:ImprovementandPractice8,no.

4(2003):183-199.

Paasivaara,Maria, Sandra Durasiewicz, and Casper Lassenius (2009). "Using scrum in distributed

agile development: A multiple case study." In Global Software Engineering, 2009. ICGSE 2009.

FourthIEEEInternationalConferenceon,pp.195-204.IEEE,2009.

Pakdeetrakulwong, Udsanee, Pornpit Wongthongtham, and Naveed Khan (2015). "An Ontology-

Based Multi-Agent System to Support Requirements Traceability in Multi-Site Software

Development Environment." In Proceedings of the ASWEC 2015 24th Australasian Software

EngineeringConference,pp.96-100.ACM,2015.

217

Patel,Chetankumar,andMuthuRamachandran(2008)."SoBA:AToolSupportforStoryCardBased

AgileSoftwareDevelopment."InSETP,pp.17-23.2008.

Pehmöller,Anneke,FrankSalger,andStefanWagner(2010)."Patternsfortestinginglobalsoftware

development." In Proceedings of the 13th International Conference on Quality Engineering in

SoftwareTechnology.2010.

Picot,Arnold,RalfReichwald,andRolfT.Wigand.(2003)."DiegrenzenloseUnternehmung.".

Pilatti, Leonardo, and Jorge Luis Nicolas Audy (2006). "Global Software Development Offshore

InsourcingOrganizations Characteristics: Lessons Learned from a Case Study." InGlobal Software

Engineering,2006.ICGSE'06.InternationalConference,249-250.

Prikladnicki, Rafael, Jorge Luis Nicolas Audy, Daniela Damian, and Toacy Cavalcante de Oliveira

(2007). "Distributed Software Development: Practices and challenges in different business

strategiesofoffshoringandonshoring."InGlobalSoftwareEngineering,2007.ICGSE2007.Second

IEEEInternationalConference,262-274.

Prikladnicki,Rafael,andJorgeLuisNicolasAudy(2012)."ManagingGlobalSoftwareEngineering:A

Comparative Analysis of Offshore Outsourcing and the Internal Offshoring of Software

Development."InformationSystemsManagement29,no.3:216-232.

Prikladnicki, Rafael, Sabrina Marczak, Erran Carmel, and Christof Ebert (2012). "Technologies to

SupportCollaborationacrossTimeZones."Software,IEEE29,no.3,10-13.

Poole,CharlesJ(2004)."Distributedproductdevelopmentusingextremeprogramming."InExtreme

ProgrammingandAgile Processes in Software Engineering, pp. 60-67. SpringerBerlinHeidelberg,

2004.

Qumer,Asif,BrianHenderson-sellers,andTomMcbride(2007)."Agileadoptionandimprovement

model."(2007).

Qumer,Asif,andBrianHenderson-Sellers(2008)."Anevaluationofthedegreeofagilityinsixagile

methodsanditsapplicabilityformethodengineering."Informationandsoftwaretechnology50,no.

4(2008):280-295.

Qumer,Asif,andBrianHenderson-Sellers(2008)."Aframeworktosupporttheevaluation,adoption

andimprovementofagilemethodsinpractice."JournalofSystemsandSoftware81,no.11(2008):

218

1899-1919.

Radlo, Mariusz-Jan (2016). "Offshoring and Outsourcing in Economic Theories." InOffshoring,

OutsourcingandProductionFragmentation,pp.41-97.PalgraveMacmillan,London,2016.

Radoff, Sandy (2006). “Improved Cross-Cultural Communication Increases Global Sourcing

Productivity”.UnitedStates:Accenture

Ramesh,Balasubramaniam,LanCao,KannanMohan,andPengXu(2006)."Candistributedsoftware

developmentbeagile?."CommunicationsoftheACM49,no.10(2006):41-46.

Räty, Petteri, Benjamin Behm, Kim-Karol Dikert,Maria Paasivaara, Casper Lassenius, and Daniela

Damian(2013)."CommunicationPracticesinaDistributedScrumProject."CoRR(2013).

Ring, P., and Van de Ven, A (2004). Developmental processes of cooperative interorganizational

relationships.Acad.Mgt.Rev.19,1.90–118.

Robertson, S. (1996). Requirements Patterns Via Events/Use Cases. InProceedings Pattern

LanguagesofProgramming.

Robinson,Marcia,andRaviKalakota (2004).Offshoreoutsourcing:Businessmodels,ROIandbest

practices.MivarPress.

Robson,C(2002).Realworldresearch:Aresourceforsocialscientistandpractitioners(2ndEdition,

BlackwellPublishers,Oxford.

Rousseau,DeniseM.,SimB.Sitkin,RonaldS.Burt,andColinCamerer(1998)."Notsodifferentafter

all:Across-disciplineviewoftrust."Academyofmanagementreview23,no.3,393-404.

Sabherwal,Rajiv(1999)."TheroleoftrustinoutsourcedISdevelopmentprojects.Communications

oftheACM42.2.80-86.

Sadagopan,S(2002),IndianITCompanies–DoyouknowWipro?,TimesofIndia,May13,2002

Sahay, Sundeep, Brian Nicholson, and Shenai Krishna (2003). Global IT outsourcing: software

developmentacrossborders.CambridgeUniversityPress.

219

Salger,Frank,JochenEnglert,andGregorEngels(2010)."TowardsSpecificationPatternsforGlobal

Software Development Projects-Experiences from the Industry." In Quality of Information and

Communications Technology (QUATIC), 2010 Seventh International Conference on the, pp. 73-78.

IEEE,2010.

Saunders,M.,PLewis(2007)-Researchmethodsforbusinessstudents,2007

Sarker,Suprateek,andSundeepSahay(2004).Implicationsofspaceandtimefordistributedwork:

an interpretive study of US–Norwegian systems development teams. European Journal of

InformationSystems13.1.3-20.

Sengupta, B., Chandra, S., and Sinha, V. (2006). A research agenda for distributed software

development.InProceedingsofthe28thinternationalconferenceonSoftwareengineering(2006).

ACM,NewYork,NY,USA,731-740.DOI=http://doi.acm.org/10.1145/1134285.1134402.

Shah,Hina,NancyJ.Nersessian,Mary JeanHarrold,andWendyNewstetter (2012)."Studyingthe

influence of culture in global software engineering: thinking in terms of cultural models." In

Proceedings of the 4th international conference on Intercultural Collaboration, pp. 77-86. ACM,

2012.

Simons,Matt(2002)."Internationallyagile."InformIT.

Smite, Darja, and Claes Wohlin (2011). "A whisper of evidence in global software engineering."

Software,IEEE28.4,15-18.

Šmite, Darja, Nils Brede Moe, and Pär J. Ågerfalk (2010). "Fundamentals of Agile Distributed

SoftwareDevelopment."InAgilityAcrossTimeandSpace,pp.3-7.SpringerBerlinHeidelberg.

Smits, H. and Pshigoda, G (2007). Implementing scrum in a distributed software development

organization.ProceedingsofAGILE2007,pp.371-375.

Summers,Mark(2008)."InsightsintoanAgileadventurewithoffshorepartners."InAgile,2008.

AGILE'08.Conference,pp.333-338.IEEE,2008.

Sureshchandra, Kalpana, and Jagadish Shrinivasavadhani (2008). "Adopting agile in distributed

development."InGlobalSoftwareEngineering,2008.ICGSE2008.IEEEInternationalConferenceon,

pp.217-221.IEEE,2008.

Sutherland,Jeff,AntonViktorov,JackBlount,andNikolaiPuntikov(2007)."Distributedscrum:Agile

projectmanagementwithoutsourceddevelopmentteams."InSystemSciences,2007.HICSS2007.

220

40thAnnualHawaiiInternationalConferenceon,pp.274a-274a.IEEE,2007.

Stack,Martin,andRicardDowning(2005)."Another lookatoffshoring:Which jobsareatriskand

why?."BusinessHorizons48,no.6,513-523.

Star,SusanLeigh,andJamesR.Griesemer(1989)."Institutionalecology,translations'andboundary

objects:AmateursandprofessionalsinBerkeley'sMuseumofVertebrateZoology,1907-39."Social

studiesofscience19,no.3(1989):387-420.

Taylor,PhilipS.,DesGreer,PaulSage,GerryColeman,KevinMcDaid,andFrankKeenan(2006)."Do

agile GSD experience reports help the practitioner?." In Proceedings of the 2006 international

workshoponGlobalsoftwaredevelopmentforthepractitioner,pp.87-93.ACM.

Tervonen, I.,Haapalahti, A.,Harjumaa, L., Simila, J. (2013).Outsourcing Software Testing:ACase

Study in the Oulu Area. In Proceedings of the 2013 13th International Conference on Quality

Software(QSIC'13).IEEEComputerSociety,Washington,DC,USA,65-74.

Tervonen,I.,Mustonen,T.(2009).OffshoringTestAutomation:ObservationsandLessonsLearned.

InProceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering

(ICGSE'09).IEEEComputerSociety,Washington,DC,USA,226-235.

Therrien,Elaine(2008)."OvercomingtheChallengesofBuildingaDistributedAgileOrganization."In

AGILE,pp.368-372.2008.

Trompenaars, Fons, and Charles Hampden-Turner (2004). Managing people across cultures.

Chichester:Capstone,2004.

Tylor, Edward Burnett (1871).Primitive culture: researches into the development of mythology,

philosophy,religion,art,andcustom.Vol.2.J.Murray,1871.

Välimäki, Antti, and Jukka Kääriäinen (2008). "Patterns for Distributed Scrum—A Case Study."

EnterpriseinteroperabilityIII.SpringerLondon,2008.85-97.

Välimäki,Antti,JukkaKääriäinen,andKaiKoskimies(2009)."GlobalSoftwareDevelopmentPatterns

forProjectManagement."InEuropeanConferenceonSoftwareProcessImprovement,pp.137-148.

SpringerBerlinHeidelberg,2009.

221

vanHeesch,Uwe(2015)."Collaborationpatternsforoffshoresoftwaredevelopment."Proceedings

ofthe20thEuropeanConferenceonPatternLanguagesofPrograms.ACM,2015

VanZoest,Anna(2004).OffshoringpracticesintheUK–WherearetheLimits?.InstituteforPublic

PolicyResearch..

Vashistha,Atul,andAvinashVashistha(2005).Theoffshorenation:theriseofservicesglobalization.

NewYork:TataMcGraw-HillPublishingCompanyLimited.

Vax, Michael, Stephen Michaud (2008). "Distributed Agile: Growing a Practice Together,"AGILE

Conference,pp.310-314,Agile2008.

von Campenhausen, C. (2005). "Offshoring rules–Auslagern von unterstützenden

Funktionen."ZeitschriftfürBetriebswirtschaft75,no.1,5-13.

Wiegers,K.(2007).ProcessImpact.2007.<http://www.processimpact.com>.

Wildt, Daniel, and Rafael Prikladnicki (2010). "Transitioning from Distributed and Traditional to

DistributedandAgile:AnExperienceReport."InAgilityAcrossTimeandSpace,pp.31-46.Springer

BerlinHeidelberg,2010.

Wipro(2012).Availableat:http://www.wipro.com/newsroom/Wipro-Project-for-BT-Recognized-as-

the-Offshoring-Project-of-the-Year-by-UKs-National-Outsourcing-Association

Yap, Monica (2005). "Follow the sun: distributed extreme programming development." In Agile

Conference,2005.Proceedings,pp.218-224.IEEE,2005.

Yeo,AlvinW(2001)."Global-softwaredevelopmentlifecycle:Anexploratorystudy."InProceedings

oftheSIGCHIconferenceonHumanfactorsincomputingsystems,pp.104-111.ACM

Yu, Liguo, Zhong Guan, and Srini Ramaswamy (2016). "The effect of time zone difference on

asynchronouscommunicationsinglobalsoftwaredevelopment."InternationalJournalofComputer

ApplicationsinTechnology53,no.3(2016):213-225.

Yin, R. K. (2003) Case Study Research Design and Methods, Thousand Oaks, 3rd Edition, Sage

Publications,Inc.

Yu,Xiaodan,andStaciePetter(2014)."Understandingagilesoftwaredevelopmentpracticesusing

222

sharedmentalmodelstheory."InformationandSoftwareTechnology56,no.8(2014):911-921.

Zahedi, Mansooreh,Mojtaba Shahin, andMuhammad Ali Babar (2016). "A systematic review of

knowledgesharingchallengesandpracticesinglobalsoftwaredevelopment."InternationalJournal

ofInformationManagement36,no.6(2016):995-1019.

Zave, Pamela (1997). "Classification of research efforts in requirements engineering." ACM

ComputingSurveys(CSUR)29,no.4(1997):315-321.

223

AppendixA:SelectedStudiesforOffshoreChallenges

SelectedStudiesforidentifyingthechallengesinoffshoresoftwaredevelopment:

[E1]. Avritzer,Alberto,andAdailtonLima."Anempiricalapproachfortheassessmentofschedulingriskina largegloballydistributed industrialsoftwareproject." InGlobalSoftwareEngineering,2009.ICGSE2009.FourthIEEEInternationalConferenceon,pp.341-346.IEEE,2009.

[E2]. Bannerman,PaulL.,EmamHossain,andRossJeffery(2012)."Scrumpracticemitigationofglobal

software development coordination challenges: a distinctive advantage?." In System Science(HICSS),201245thHawaiiInternationalConferenceon,pp.5309-5318.IEEE.

[E3]. Battin,RobertD.,RonCrocker,JoeKreidler,andK.Subramanian(2001)."Leveragingresourcesin

globalsoftwaredevelopment."Software,IEEE18,no.2(2001):70-77.[E4]. Boden,Alexander,BernhardNett,andVolkerWulf(2007)."Coordinationpractices indistributed

softwaredevelopmentof small enterprises." InGlobal Software Engineering, 2007. ICGSE2007.SecondIEEEInternationalConferenceon,pp.235-246.IEEE.

[E5]. Boon,S.,andHolmes,J.(1991).Thedynamicsofinterpersonaltrust:Resolvinguncertaintyinthe

face of risk.In R. Hinde and J. Groebel (Eds.). Cooperation and Prosocial Behavior. CambridgeUniversityPress,Cambridge,UK.190–211.

[E6]. Bosch, Jan, and Petra Bosch-Sijtsema (2010). "Coordination between global agile teams: From

processtoarchitecture."InAgilityAcrossTimeandSpace,pp.217-233.SpringerBerlinHeidelberg.[E7]. Carmel, Erran (1999).Global software teams: collaborating across borders and time zones.

PrenticeHallPTR.

[E8]. Carmel, Erran, and Ritu Agarwal (2001). "Tactical approaches for alleviating distance in global

softwaredevelopment."Software,IEEE18,no.2:22-29.

[E9]. Cataldo, Marcelo, Patrick A. Wagstrom, James D. Herbsleb, and Kathleen M. Carley (2006)."Identification of coordination requirements: implications for the Design of collaboration andawarenesstools."InProceedingsofthe200620thanniversaryconferenceonComputersupportedcooperativework,pp.353-362.ACM.

[E10]. Cataldo,Marcelo,CharlesShelton,YongjoonChoi,Yun-YinHuang,VyteshRamesh,DarpanSaini,

and Liang-Yun Wang (2009). "Camel: A tool for collaborative distributed software design." InGlobalSoftwareEngineering,2009. ICGSE2009.FourthIEEEInternationalConferenceon,pp.83-92.IEEE.

[E11]. Cusick,James,andAlpanaPrasad(2006)."Apracticalmanagementandengineeringapproachto

offshorecollaboration."Software,IEEE23,no.5:20-29.

[E12]. Damian, Daniela E., and Didar Zowghi (2003). "An insight into the interplay between culture,conflictanddistanceingloballydistributedrequirementsnegotiations."InSystemSciences,2003.Proceedingsofthe36thAnnualHawaiiInternationalConferenceon,pp.10-pp.IEEE.

[E13]. Das,TarunK.,andBing-ShengTeng(1998)."Betweentrustandcontrol:developingconfidencein

partnercooperationinalliances."AcademyofManagementreview23,no.3,491-512.[E14]. Davenport, Thomas, H., and Prusak, Laurence, (1998). Working knowledge. Boston: Harvard

BusinessSchoolPress.

224

[E15]. Desouza, Kevin C., Yukika Awazu, and Peter Baloh (2006). "Managing knowledge in globalsoftwaredevelopmentefforts:Issuesandpractices."IEEEsoftware23,no.5:30

[E16]. Dorairaj,Siva,JamesNoble,andPetraMalik(2011)."EffectivecommunicationindistributedAgilesoftware development teams." In Agile Processes in Software Engineering and ExtremeProgramming,pp.102-116.SpringerBerlinHeidelberg.

[E17]. Dourish, Paul, and Victoria Bellotti. (1992). Awareness and coordination in shared

workspaces.Proceedingsofthe1992ACMconferenceonComputer-supportedcooperativework.ACM.

[E18]. Ebert,Christof (2011).Globalsoftwareand IT:Aguidetodistributeddevelopment,projects,andoutsourcing.Wiley-IEEEComputerSocietyPress

[E19]. Evaristo, J. Roberto, Richard Scudder, Kevin C. Desouza, andOsam Sato (2004). "A dimensional

analysis of geographically distributed project teams: a case study." Journal of Engineering andtechnologyManagement21,no.3:175-189.

[E20]. Gotel,Olly,VidyaKulkarni,DesPhal,MoniphalSay,ChristelleScharff,andThanwadeeSunetnanta

(2009). "Evolving an Infrastructure for Engineering, Communication, Project Management andSocialization toFacilitateStudentGlobal SoftwareDevelopmentProjects." InProc.of the IndianSoftwareEngineeringConference(ISEC2009),Pune,India.

[E21]. Green, R., T. Mazzuchi, and S. Sarkani (2010). "Communication and quality in distributed agile

development:anempiricalcasestudy."ProceedinginWorldAcademyofScience,EngineeringandTechnology61:322-328.

[E22]. Grundy, John, John Hosking, and Rick Mugridge (1998). "Coordinating distributed software

development projects with integrated process modelling and enactment environments." Inwetice,p.39.IEEE.

[E23]. Gutwin, Carl, Saul Greenberg, and Mark Roseman (1996). "Workspace awareness in real-time

distributedgroupware:Framework,widgets,andevaluation."PeopleandComputers.281-298.[E24]. Herbsleb,JamesD.,DanielJ.Paulish,andMatthewBass(2005)."Globalsoftwaredevelopmentat

siemens:experiencefromnineprojects." InSoftwareEngineering,2005. ICSE2005.Proceedings.27thInternationalConference,524-533.

[E25]. Herbsleb, James D (2007). "Global software engineering: The future of socio-technical

coordination."In2007FutureofSoftwareEngineering,pp.188-198.IEEEComputerSociety.[E26]. Hofner,Gerd, andV. S.Mani (2007). "TAPER:A generic framework for establishing an offshore

development center." InGlobal Software Engineering, 2007. ICGSE 2007. Second IEEEInternationalConference,162-172.

[E27]. Hofstede, Geert, Michael Harris Bond, and Chung-leung Luk (1993). "Individual perceptions of

organizationalcultures:Amethodologicaltreatiseonlevelsofanalysis."OrganizationStudies14,no.4:483-503.

[E28]. Holmström,Helena,BrianFitzgerald,PärJ.Ågerfalk,andEoinÓ.Conchúir.(2006):"Agilepractices

reducedistanceinglobalsoftwaredevelopment."InformationSystemsManagement23,no.37-18.

225

[E29]. Hsieh, Yvonne (2006). "Culture and shared understanding in distributed requirementsengineering." InGlobal Software Engineering, 2006. ICGSE'06. International Conference on, pp.101-108.IEEE.

[E30]. Humphrey,WattsS(1989).ManagingtheSoftwareProcess.Addison-WesleyProfessional.

[E31]. Iacovou, Charalambos L., and Robbie Nakatsu (2008). "A risk profile of offshore-outsourceddevelopmentprojects."CommunicationsoftheACM51,no.6:89-94.

[E32]. Javidan, Mansour, Günter K. Stahl, Felix Brodbeck, and Celeste PM Wilderom (2005). "Cross-

bordertransferofknowledge:CulturallessonsfromProjectGLOBE."TheAcademyofManagementExecutive19,no.2,59-76.

[E33]. Kanawattanachai, Prasert, and Youngjin Yoo (2002). "Dynamic nature of trust in virtual

teams."TheJournalofStrategicInformationSystems11,no.3,187-213.[E34]. Kedia, Ben L. and Lahiri, Somnath, (2007), International outsourcing of services: A partnership

model.Memphis:JournalofInternationalManagement,13,22–37[E35]. Kobayashi-Hillary,Mark.(2005).OutsourcingtoIndia:theoffshoreadvantage.ISBN3-540-23943-

XSpringer-VerlagBerlinHeidelbergNewYork.[E36]. Korkala, Mikko, and Pekka Abrahamsson (2007). "Communication in distributed agile

development: A case study." In Software Engineering and Advanced Applications, 2007. 33rdEUROMICROConferenceon,pp.203-210.IEEE.

[E37]. Korkala, Mikko, and Frank Maurer (2014). "Waste identification as the means for improving

communication in globally distributed agile software development." Journal of Systems andSoftware95:122-140.

[E38]. Lander, Maria Cristina, Russell L. Purvis, Gordon E. McCray, and William Leigh (2004). Trust-

buildingmechanismsutilizedinoutsourcedISdevelopmentprojects:acasestudy.Information&Management41,no.4.509-528.

[E39]. Lanubile, Filippo, Daniela Damian, and Heather L. Oppenheimer (2003). "Global software

development: technical, organizational, and social challenges." ACM SIGSOFT SoftwareEngineeringNotes28,no.6:2-2.

[E40]. Lanubile,Filippo,FabioCalefato,andChristofEbert(2013).GroupAwareness inGlobalSoftware

Engineering.IEEESoftware.18-23.[E41]. Layman, Lucas, Laurie Williams, Daniela Damian, and Hynek Bures (2006). "Essential

communication practices for Extreme Programming in a global software development team."Informationandsoftwaretechnology48,no.9:781-794.

[E42]. Lee,Seiyoung,andHwan-SeungYong(2010)."Distributedagile:projectmanagement inaglobal

environment."EmpiricalSoftwareEngineering15,no.2:204-217.[E43]. Maruping, Likoebe M (2010). "Implementing Extreme Programming in Distributed Software

ProjectTeams:StrategiesandChallenges." InAgilityAcrossTimeandSpace,pp.11-30.SpringerBerlinHeidelberg.

[E44]. Matloff,Norman(2005)."Offshoring:Whatcangowrong?."ITprofessional7,no.4,39-45.[E45]. Morgan, RobertM., and Shelby D. Hunt (1994). "The commitment-trust theory of relationship

marketing."thejournalofmarketing,20-38.

226

[E46]. Paasivaara,Maria,SandraDurasiewicz,andCasperLassenius (2009)."Usingscrum indistributed

agile development: A multiple case study." InGlobal Software Engineering, 2009. ICGSE 2009.FourthIEEEInternationalConferenceon,pp.195-204.IEEE.

[E47]. Paasivaara,Maria, Casper Lassenius, Daniela Damian, Petteri Raty, and Adrian Schroter (2013).

"Teaching students global software engineering skills using distributed scrum." In SoftwareEngineering(ICSE),201335thInternationalConferenceon,pp.1128-1137.IEEE.

[E48]. Pilatti, Leonardo, and Jorge Luis Nicolas Audy (2006). "Global Software Development Offshore

InsourcingOrganizationsCharacteristics:LessonsLearnedfromaCaseStudy."InGlobalSoftwareEngineering,2006.ICGSE'06.InternationalConference,249-250.

[E49]. Prikladnicki,Rafael,andJorgeLuisNicolasAudy(2012)."ManagingGlobalSoftwareEngineering:A

Comparative Analysis of Offshore Outsourcing and the Internal Offshoring of SoftwareDevelopment."InformationSystemsManagement29,no.3:216-232.

[E50]. Qumer Gill, Asif, and Deborah Bunker (2013). "Towards the development of a cloud-based

communicationtechnologiesassessmenttool:Ananalysisofpractitioners'perspectives."VINE43,no.1:57-77.

[E51]. Radoff, Sandy (2006). “Improved Cross-Cultural Communication Increases Global Sourcing

Productivity”.UnitedStates:Accenture

[E52]. Ralyté, Jolita, Xavier Lamielle,NicolasArni-Bloch, andMichel Léonard (2008). "A framework forsupportingmanagementindistributedinformationsystemsdevelopment."InResearchChallengesinInformationScience,2008.RCIS2008.SecondInternationalConferenceon,pp.381-392.IEEE.

[E53]. Ramasubbu, Narayan, Mayuram S. Krishnan, and Prasad Kompalli (2005). "Leveraging global

resources:Aprocessmaturityframeworkformanagingdistributeddevelopment."Software,IEEE22,no.3:80-86.

[E54]. Ring,P., andVandeVen,A (2004).Developmentalprocessesof cooperative interorganizational

relationships.Acad.Mgt.Rev.19,1.90–118.[E55]. Robarts, JaneM (2008). "Practical considerations for distributed agile projects." InAgile, 2008.

AGILE'08.Conference,pp.327-332.IEEE.[E56]. Rousseau,DeniseM., SimB. Sitkin,Ronald S.Burt, andColinCamerer (1998). "Not sodifferent

afterall:Across-disciplineviewoftrust."Academyofmanagementreview23,no.3,393-404.[E57]. Sabherwal, Rajiv (1999). "The role of trust in outsourced IS development projects.

CommunicationsoftheACM42.2.80-86.

[E58]. Sahay, Sundeep, Brian Nicholson, and Shenai Krishna (2003). Global IT outsourcing: softwaredevelopmentacrossborders.CambridgeUniversityPress.

[E59]. Sarker,Suprateek,andSundeepSahay(2004).Implicationsofspaceandtimefordistributedwork:

an interpretive study of US–Norwegian systems development teams. European Journal ofInformationSystems13.1.3-20.

[E60]. Sindhgatta, Renuka, Bikram Sengupta, and Subhajit Datta (2011). "Coping with distance: an

empiricalstudyofcommunicationonthejazzplatform."InProceedingsoftheACMinternationalconference companion on Object oriented programming systems languages and applicationscompanion,pp.155-162.ACM.

227

[E61]. Taweel, Adel, Brendan Delaney, Theodoros N. Arvanitis, and Lei Zhao (2009). "Communication,knowledge and co-ordination management in globally distributed software development:Informedbyascientificsoftwareengineeringcasestudy." InGlobalSoftwareEngineering,2009.ICGSE2009.FourthIEEEInternationalConferenceon,pp.370-375.IEEE.

[E62]. Taxén,Lars(2006)."Anintegrationcentricapproachforthecoordinationofdistributedsoftware

developmentprojects."Informationandsoftwaretechnology48,no.9:767-780.

[E63]. Välimäki,Antti,and JukkaKääriäinen (2008). "Patterns forDistributedScrum—ACaseStudy." InEnterpriseinteroperabilityIII,pp.85-97.SpringerLondon.

[E64]. Vallon,Raoul,StefanStrobl,MarioBernhart,andThomasGrechenig (2013). Inter-organizational

Co-development with Scrum: Experiences and Lessons Learned from a Distributed CorporateDevelopmentEnvironment.SpringerBerlinHeidelberg.

[E65]. Yadav,Vanita,MonicaAdya,DhruvNath,andVaradharajanSridhar(2007)."Investigatingan'Agile-

Rigid'ApproachinGloballyDistributedRequirementsAnalysis."PACIS2007Proceedings:12.

[E66]. Yeo, Alvin W. "Global-software development lifecycle: An exploratory study. (2001)." InProceedingsoftheSIGCHIconferenceonHumanfactorsincomputingsystems,pp.104-111.ACM.

[E67]. Zieris,Franz,andStephanSalinger(2013)."Doingscrumratherthanbeingagile:acasestudyon

actualnearshoringpractices."InGlobalSoftwareEngineering(ICGSE),2013IEEE8thInternationalConferenceon,pp.144-153.IEEE.

228

AppendixB:OverviewofExistingSoftwareDevelopmentApproachesNo. SoftwareDevelopment

ApproachPhasesExecutionintheSoftwareDevelopment

Approach1. Ad-Hoc In this approach a developer writes code without

any formal software requirement specificationdocument.There isnodesignphase; thedeveloperdirectlygoestocodingphaseandfollowsabuildandfixapproach.

2. Linear This the traditional approach, in which the phasesare executed linearly. That is when one phase iscomplete,onlythencanthedevelopermovetothenext phase. For example, the team needs to firstcomplete thedesignphasebefore they cango intodevelopment phase and once a phase has beencompletedthedevelopmentteamcannotgobacktoit.

3. Evolutionary In evolutionary approach, the development teamcanmoveacrossanalysis,designandcodingphases,thus providing the developers the freedom to goback todesignphaseandcorrect adesignmistake.However the teamhas to stick to theobjectivesoftheprojectandcannotchangethem.

4. IterativeandIncremental Iterativeandincrementalapproachallowstheteamtorepeataphase,asmanytimestheyneedtoandallows them to move back and forth betweendifferentphasesbasedontheteams’requirement.

229

AppendixC:OverviewofBeechametal.(2014)GSDSolution

230

AppendixD:SampleQuestionsforSemi-StructuredInterviewsThedurationoftheinterviewis30-45minutes.Wehavedividedtheinterviewinto3section based on the type of questions. Section 1 consists of shorts question thatrequire direct answers. Section 2 consists of questions regarding the methodologyused for offshore project and section 3 consists of questions that require detailanswers,astheywilldeterminetheresultsfortheresearch.Section1:OrganisationInthissectionwewillbeaskingquestionsregardingtheorganisationinordertohaveageneraloverviewoftheexperienceoftheorganisationinoffshoringprojectsandagilemethodology.Asthisinformationwillhelpusunderstandwhetherorganisationswithdifferent experiences with agile and offshoring projects face similar problems withcommunicationandcoordinationissueamongtheonshoreandoffshoreteamsornot.

1. Whatisthenameandagegroupofthecompany?2. Whatistheorganisation’sexperiencewithagile?3. Howmanyyearshavetheydoneoffshoring?4. Howhastheirexperiencebeenwithoffshoring?5. Howmanyprojectshavetheydoneonoffshorelocations?

Section2:Methodology

In this sectionwe start by asking the followingquestion in order to get informationabout what methodology the organisation uses for developing offshore projects todetermineiftheyuseagilemethodologyornot.

1. What software development methodology does your organisation use foroffshoreprojects?

Based on their reply of the above question we will ask further questions s tounderstandhowtheorganisationusesagileandwhethertheyfaceanyissueswithit:

• Haveyouusedagilemethodologyforanyoffshoreproject?• Due to the difference in time do you feel you have to wait a lot for

feedback/work from theoffshore team?Does itmake itdifficult to completetheprojectontime?

• Howdoesyourorganisationmanagetimedifferentbetweentheteams?• Does the offshore and onshore teams use the same development

methodology?• Do you feel you have to repeat yourself a lotwhile communicatingwith the

offshoreteam?Doesthisslowdownthedevelopmentprocess?

231

Section3:ResearchInthissection,weaskdetaildescriptionofthefollowingquestionstounderstandiftheorganisation is facing or has faced communication and coordination issues whiledevelopingsoftwareoffshoreandiftheymanagedtoovercomeitornotandiftheyhavefacedanyotherchallengewhiledevelopingoffshoreprojects:

1. Howefficient is thecurrentmethodology inhandling thecommunicationandcoordinationofworkbetweentheonshoreandoffshoreteam.

2. Haveyoufacedanydifficultinthecurrentmethodology?Ifyeswhereyouabletosolvetheissue?

3. Inthecurrentmethodologydoyouthinkthere isneedforsomemodificationthatwouldhelpimprovetheoffshoringprojects?

232

AppendixE:ConsentFormandDataProcessingStatementBelowistheconsentanddataprocessingstatementform,theorganisationsweinterviewedsigned.

Interview consent and data processing statement Name: Maryam Kausar, email: m.kausar@edu.salford.ac.uk

If you consent to being interviewed and to any data gathered being processed asoutlined below, please print and sign your name, and date the form, in the spacesprovided.ProjectFacts:

• This project - ‘Agile and Beyond Agile Software Development Techniques forApplicationinOffshoreDevelopment”isbeingconductedbyaresearchteamattheUniversityofSalford.

• Alldatawillbetreatedaspersonalunderthe1998DataProtectionAct,andwill

bestoredsecurely.

• Interviewswillberecordedandtranscribedbytheresearchteam.

• A copy of your interview transcript will be provided, free of charge, uponrequest.

• Data collected may be processed manually and with the aid of computer

software.

• IhavetherighttowithdrawfromtheresearchatanystageintheresearchConsents:

• With respect to information resulting from the study being used in futurepublicationand/orreportsoutsidetheresearchteam,Iconsenttothefollowing:

Mynamemaybeidentified □YES □NOMywordsmaybequoted □YES □NO

• I am willing to cooperate in the future if a need for further information is

required □YES □NO

233

• I/myemployerconsenttoourinterviewsbeingrecordedbyrecordingdevices. □YES □NO

Pleaseprintyourname: ........................................................................Organisation: ........................................................................Signature: .................................................... Date:....................................................

234

AppendixF:UnrevisedDistributedAgilePatternCatalogueInthissectionwehavepresentedtheunreviseddistributedagilepatternsbeforetheywerevalidated.Asmostofthepatternswerenotchangedwehaveonlypresentedtheonesthatwerechangedafterthevalidationprocess.a)ManagementPatternsInthissectionwehavedescribedthedetailofeachmanagementpattern.1.ScrumofScrumPatternIn agile methodology, Scrum is an iterative and incremental project managementapproachthatprovidesasimpleframeworkthat“inspectandadapt”(Hossain,Babar,andPaik,2009).Weobservedthatinoffshoreprojectstheonshoreandoffshoreteampractices separate scrums in order to develop the project. Based on this observedpracticewehavedesignedthefollowingpatterndetails:PatternName

ScrumofScrumPatternIntent

To apply scrum, sub-teams are formed based on location. Each team has itsownscrum.Scrumofscrummeetingsarearrangedtodiscusstheprogressoftheproject,whichisattendedbykeypeople.

AlsoKnownAsScrummeetingorMetaScrum

CategoryManagement category as this pattern helps the onshore and offshore teammanage their separate scrums and keep each other updated of the projectprogress.

MotivationConsiderateamthatisdividedintosub-teamsbasedonlocationandtheyareworkingondifferenttasksofaproject.Itisdifficulttohavebothonshoreandoffshore teamworkon thesamescrumas theybothareworkingondifferenttime zones so in order to work on the same project, both teams work onseparatescrums.To coordinatework both teams arrange a scrum of scrummeeting,which isattendedbykeypeoplefrombothteamstoupdateeachotheroftheprogressoftheproject.

ApplicabilityUseScrumofScrumwhen:

• Teamisdistributedoverdifferenttimezones.• Theoverlappingworkinghoursbetweentheonshoreandoffshoreteam

isless.Participants

• Distributedonshoreandoffshoreagileteam.• ScrumMastersofagilesub-teamsandProductowner.

235

Collaboration• Keymembers fromonshoreandoffshore teamsdecide time forScrumof

Scrummeeting.Consequences

TheScrumofScrumpatternhasthefollowingbenefitsandliabilities:1. It prevents the onshore and offshore team from wasting time on

collaboratingtaskswitheachotherthroughonlinetoolsasboththeteamsareworkingontheirownscrumsotheydon’thavetowaitforeachothertocompletetasks.

2. It provides control to both onshore and offshore team to work on theirscrum,whichavoidstheoffshoreteamfromhavingtoadjustworkinghoursbasedononshoreteamsavailability.

3. ItallowskeypeoplesuchasScrumMastersandProductowners’todiscusstheprogressof theprojectwithouthaving thewhole teampresentwhichkeepsthemeetingtimeboxed.

4. Its limitation is that due tominimum collaboration between the onshoreandoffshoreteam,bothsub-teamsdon’tfeeltheyareoneteam.

5. SinceonlykeypeopleattendtheScrumofScrummeeting,itlimitsface-to-face interaction of both onshore and offshore team, which affects trustbuildingbetweenbothteams.

KnownusesWhenCheckFreedecidedtomovetheirworktoanIndianoffshoreconsultingfirmtheyusedScrumofScrumtogatherandreviewtheoverallteamstatisticsandprogressoftheproject(Cottmeyer,2008).Similarly,multiplecasestudiesdone on organisations using Scrum for distributed teams also used ScrumofScrumtocoordinatetheirworkwithoffshoreteam(Hossain,Babar,andPaik,2009;Paasivaara,Durasiewicz,andLassenius,2009).SiemensalsousedScrumof Scrum for two large distributed projects inwhich the development teamswerelocatedinUSA,EuropeandIndia.IntheirScrumofScrummeetingstheycovered technical and managerial issues that occurred in multiple teams(Avritzeretal.,2010)

RelatedPatternsScrumofScrumpattern isoftenusedwithLocalSprintPlanningPattern (andAsynchronousRetrospectivemeetingPatternastheonshoreandoffshoreteammembers are working on different story cards and at the end have theirseparateretrospectivemeetingstodiscussthesprint

2.LocalStandupMeetingAgilemethodologyfocusesonconductingadailystandupmeeting.WeobservedthatinoffshoreprojectstheonshoreandoffshoreteamconducttheirownseparatedailystandupmeetingsanduseonlinetoolssuchasWiki’stosharemeetingminuteswitheachother.Basedon thisobservedpracticewehavedesigned the followingpatterndetails:PatternName

LocalStandupMeetingPattern

236

IntentTodiscussdailyupdatesonworkdone,eachlocalteamwillconducttheirownstandupmeetings.

AlsoKnownAsDailyScrummeetingordailymeeting

Category

Management category as this pattern helps the team members of bothonshoreandoffshoreteammanagetheirdailyactivitiesandupdateeachotherwiththeworkdone.

MotivationConsider a team that is divided into sub-teams that are located on differenttimezones.Tohaveacollaborativedailystandupmeetingisdifficultandtimeconsumingastheoffshoreteameitherhastocomeearlytoworkorstaylatetoattend themeeting. To avoid this, the onshore and offshore team conductsseparatelocalstandupmeetingsinwhichtheyanswerthefollowingquestions:

o Whatdidyoudoyesterday?o Whatareyougoingtodotoday?o Whatisgettinginyourway?

AfterconductinglocalstandupmeetingsbothonshoreandoffshoreteamsharetheirmeetingminutesviaonlinetoolssuchasWiki’stokeepboththeteamsuptowiththeprogressoftheproject.

ApplicabilityUselocalstandupmeetingwhen:

• Teamisdistributedoverdifferenttimezones.• Theoverlappingworkinghoursbetweentheonshoreandoffshoreteam

isless.Participants

• Distributedonshoreandoffshoreagileteam.Collaboration

• Both onshore and offshore team sharemeetingminuteswith each otherusingonlinetools.

ConsequencesThelocalstandupmeetingspatternhasthefollowingbenefitsandliabilities:1. It prevents the offshore team from waiting for the onshore team’s

availabilitytoconductthedailystandupmeeting.2. It allowsbothonshore andoffshore team flexibility to conduct their own

standupmeetingatwhichevertimetheywant.3. Itlimitstheonshoreandoffshoreteamfromreal-timecommunicationand

bothteamheavilyrelyonthemeetingminutessoanymistakecanleadtomisunderstandingintheprogressoftheproject.

KnownusesOrganisations such as PulpCo (Paasivaara, Durasiewicz, and Lassenius, 2009)and Wipro Technologies (Sureshchandra et al., 2008) use local standupmeetingsforcommunicatingtheprogressoftheprojectwithteammembers.

237

RelatedPatternsDailyStandupmeetingpattern isoftenusedwithGlobalScrumBoardPatternas once the onshore and offshore team members have conducted theirmeetingstheysharethemeetingminutesonasharedtoolsothatbothcanseetheprojectprogress.

3.LocalSprintPlanningMeetingPatternInagile,ascrumconsistsofmanysprints.Thedurationofasprintvariesfrom2weeksto4weeksdependingonthesizeoftheproject.Atthestartofeverysprinttheteamhas a sprint-planningmeeting inwhich the team defines the goal of the sprint andprepare the sprint backlog. When the team is divided and is working on differentmodules of the project it has been observed that the onshore teammembers andoffshoreteammembersconducttheirownseparatesprintplanningmeetings.Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

LocalSprintPlanningMeetingPatternIntent

EachteamwillhavetheirownsprintplanningmeetingsAlsoKnownAs SprintPlanningMeetingorIterationMeetingCategory

Managementcategoryasthispatternhelpstheonshoreandoffshoreteamtowork on their separate module and conduct independent scrum and sprintplanningmeetings.

MotivationWhen a project is distributed to a team that is divided over different timezones,andareworkingondifferentmodulesoftheprojectandareconductingtheirownScrum. As theonshoreandoffshore teamconducts their separateScrum, they also conduct separate sprint planning meetings to decide whatthey will develop during a sprint. Both teams prepare their sprint backlogs,whicharesharedusingonlinetools.

ApplicabilityUseLocalSprintPlanningMeetingpatternwhen:

• Team is distributed over different time zones and is working ondifferentmodules/subsystemoftheproject.

Participants• Distributedonshoreandoffshoreagileteam.

Collaboration• Theonshoreteamandoffshoreteamsharesprintbacklogwitheachother

toshowtheworktheywillbedoingoverthenextsprint.Consequences

TheLocalSprintPlanningMeetingpatternhasthefollowingbenefitsandliabilities:1. Itallowsbothteamstoworkindependentlywithouthavingtowaitforthe

onshoreteamtobeavailabletoconductthemeeting.

238

2. It provides control to both onshore and offshore team to work on theirseparate scrum and conduct their own sprint planning meeting, whichavoids the offshore team from having to adjust working hours based ononshoreteamsavailability.

3. Bothteamscansharetheirsprintbacklogwitheachother,whichprovidesvisibilityoftheprojectprogress.

4. Asboththeteamsareworkingindependentlyitcancausetheteamstofeelas they are not part of one team and create an effect that they are twoseparateteams.

KnownusesWhenCheckFreedecidedtomovetheirworktoanIndianoffshoreconsultingfirm they used local sprint planning meetings to plan their sprint activities(Cottmeyer,2008).

RelatedPatternsLocalSprintPlanningPatterns inoftenusedwithScrumofScrumPatternandGlobalScrumboardPatternasthemeetingsminutesoftheplanningmeetingaresharedwithbothonshoreandoffshoreteammembers.

4LocalPairProgrammingPatternIn agile, pair programming consists of two programmers that share a singleworkstation that is they share one screen, keyboard and mouse. The programmerusingthekeyboardisusuallycalledthe"driver",theother,iscalled“navigator”asheisactivitygivinghis remarksonthecodeandhelpingthedriver towrite thecode.Theprogrammers are expected to switch roles after every few minutes. It has beenobservedthatwhentheteamisdividedondifferentlocations,theteammembersthatare co-located form pairs as it is difficult to form pairs with other locations teammembers due to the time difference. Based on this observed practice we havedesignedthefollowingpatterndetails:PatternName

LocalPairProgrammingIntent

Makepairprogrammingteamsfromthesamelocation.AlsoKnownAs PairProgrammingorPairedProgrammingCategory

Management categoryas thispatternhelps the local teammembers to formpairsandworkontheirstorycard.

MotivationWhenateamisdistributedoverdifferent locationsbasedontimezones, it isdifficult to form pairs between them due to the time difference in workinghours.Soeachteamformspairsbasedontheirlocationastheyareco-locatedandcanworktogether.PairProgramminghelpsimprovethequalityofcodeasinsteadofonepersonwritingthecodetheotherpersonischeckingthecode.

ApplicabilityUseLocalPairProgrammingpatternwhen:

239

• Team is distributedover different time zones and isworking on differentmodules/subsystemoftheproject

Participants• Distributedonshoreandoffshoreagileteamandworkingondifferentstory

cards.Collaboration

• The onshore team and offshore teammembers share a keyboardwith afellowteammemberfromtheirrespectivelocation.

ConsequencesTheLocalPairProgrammingpatternhasthefollowingbenefits:

1. The offshore team members don’t have to wait for the availability ofonshoreteammemberstostartwork.

2. Someorganisations feel it’s awasteof having two resourcingworkingonthesamething.

KnownusesInacasestudyconductedbyMaruping(2010)onanorganisationthathaditsdevelopmentcentersinIndia,U.SWestCoast,U.SMid-WestandU.SEastCoastshowedthatpairswheremadeonthebasesofphysicallocations.

RelatedPatternsSinceinLocalPairprogrammingweareselectingteammembersfromthesamelocation,weoftenuseitwithLocalSprintPlanningMeeting.

5AsynchronousRetrospectivemeetingsPatternInagile,whenateamisusingScrumattheendofeverysprintafterthesprintreviewmeeting, a retrospectivemeeting is conducted which is attended by only the teammembersandthescrummaster. Inthismeetingtheteamdiscussesallthegoodandbadthingsthathappenedduringthesprintandhowtheycanimprovetheirwork.Theyalsodiscussthefeedbackgivenbytheclient.Ithasbeenobservedthatwhentheteamisdividedondifferenttimezones,teamsconducttheirownretrospectivemeeting,asdue to the timedifference it isdifficult tohaveacollective retrospectivemeetingattheendofeachsprint(Kamaruddin,2012).Onceboththeonshoreandoffshoreteamshave conducted their retrospective meeting they share the meetings minutes witheachotherusingonlinetools.Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

AsynchronousRetrospectivemeetingsIntent

Teams conduct separate retrospectivemeetings based on location and sharethe key information via online tools. The Scrum Masters discuss possibleimprovementswiththeteambasedonthefeedbackfromtheclient.

AlsoKnownAs RetrospectivemeetingsorIterationRetrospectiveCategory

Management category as this pattern helps the onshore and offshore teammembers to review their sprint and discuss their performance. The Scrum

240

Master advises the team on how they can improve their performance anddiscussesthefeedbackoftheclient.

MotivationWhenateam isdividedondifferent timezonesandareworkingondifferentmodules/subsystemsofaprojectandconductingtheirownindependentScrumandsprintsitisdifficulttohaveacollectiveretrospectivemeeting.Theonshoreandoffshoreteammembersconducttheirseparateretrospectivemeetingstodiscusswhatwentgoodandbadinthesprintandhowtheycanimprovetheirwork in the next sprint. The Scrummaster attends thesemeetings and givesfeedbackontheperformanceontheteamanddiscussestheremarksgiveninthesprintreviewmeetingbytheclient.Oncebothteamshaveconductedtheirretrospectivemeetingstheysharethemeetingminuteswitheachotherusinganonlinetool.

ApplicabilityUseAsynchronousRetrospectivemeetingswhen:

• Team is distributed over different time zones and is working ondifferentmodules/subsystemoftheproject.

Participants• Distributedonshoreandoffshoreagileteammembers.• ScrumMaster

Collaboration• Theonshore teamandoffshore teammemberssharemeetingminutesat

theendoftheirretrospectivemeetings.Consequences

TheAsynchronousRetrospectivemeetingspatternhas the followingbenefitsandliabilities:

1. It allows onshore and offshore team members to conduct retrospectivemeetingindependentlyofeachother’savailability.

2. It helps team members discuss their independent problems and doesn’tmakebothonshoreandoffshoreteamtobepresentforthemeeting.

3. Sinceonshoreandoffshoreteammembersconductseparateretrospectivemeetingstheydon’tunderstandeachother’sproblems.

KnownusesElasticPath,aVancouver,BritishColumbia-basedcompanydecidedtooffshoretheirworktoLuxsoft,anoutsourcingpartnerusedasynchronousretrospectivesessionstodiscussthesprintprogressandwellaswhatimprovementstheycanmake. Once all locations had conducted their retrospective meetings, theypostedcommentsandresultsonSharePoint,whichwerethenviewedbyScrumMasterandtechnicalleadfortheirremarks(Vax,2008).

RelatedPatternsWe often used Scrum of Scrum Pattern with Asynchronous Retrospectivemeeting Pattern. It is also often used with Local Sprint Planning Pattern(explainedin8.3)asinordertoreviewtheprogressofasprintandtheteamweuseretrospectivemeeting.Afterallthedistributedteamshaveconductedtheirretrospectivemeetings they share themeetingminutes with each for whichtheyuseGlobalScrumBoardPattern.

241

b)CommunicationPatternsInthissectionwehavedescribedthedetailofeachcommunicationpattern.1.GlobalScrumBoardPatternAgile has many artefacts such as product backlog, sprint backlog, storyboard, taskboard, team velocity and burndown charts which help the team in managing theproject.Ithasbeenobservedthatwhentheteamisdividedtodifferentlocationstheymaintainaonlinerecordofalltheseartefactssothattheycansharethemwitheachother using online tools such asWiki’s, Rally and Jira (Danait, 2005; Beruzuk, 2007;Cottmeyer, 2008). Based on this observed practice we have designed the followingpatterndetails:PatternName

GlobalScrumBoardPatternIntent

An online-shared Scrum board, will be used by, both onshore and offshoreteam to view theproduct backlog, storyboard, task board, burndown chartsandotheragileartefactsusingonlinetools.

AlsoKnownAs ScrumBoardorAgileStoryBoardCategory

Communicationcategoryasthispatternhelpstheonshoreandoffshoreteamcommunicatewitheachotherusinganonline tool tovieweachother’sworkandunderstandtheprogressoftheoverallproject.

MotivationWhen a project is distributed to a team that is divided over different timezones,andareworkingondifferentmodulesoftheproject,tosharetheirworktheyuseanonline tool todisplayagileartefacts.Basedon theworkdonebyboth teams it is easier to see the progress of the project and it helpsunderstandifthereisaproblemwithateamornot.

ApplicabilityUseGlobalScrumBoardpatternwhen:

• Teamisdistributedoverdifferenttimezones.Participants

• Distributedonshoreandoffshoreagileteam.Collaboration

• Theonshoreteamandoffshoreteamshareagileartifactswitheachothertoshowtheirprogress.

ConsequencesTheGlobalScrumboardpatternhasthefollowingbenefits:1. It allows the onshore and offshore teams to understand the progress of the

project.2. Itincreasesthevisualizationoftheworkdonebyeachteam.

242

KnownusesFAST,asearchcompanywithheadquarters inNorwaywhilebuildingasearchapplicationon topof theircoresearchplatformexperimentedwithcoupleofonlinetoolstokeepbothteamsupdatedwiththeprogressoftheproject.Theytired XPlanner and Jira and settled for Jira, which is a web-based tool thatallowed the remote team members to view the backlog and update taskswhenevertheywanted(Berzuk,2007).SimilarlyinastudydonebyCristaletal.(2008)onanorganisationthathasdevelopmentcentersacrossNorthAmerica,SouthAmericaandAsiaconcludedwith that theuseofaglobal scrumboardcan help improve the productivity of global agile teams. Similarly companieslikeValtech (Danait,2005),Telco (Rameshetal., 2006),BNPParibas (Massol,2004),AginityLLC(Armour,2007)andSirsiDynix(Sutherlandetal.2007)usedonlinetoolstoshareagileartefactswiththeiroffshoreteammembers.

RelatedPatternsGlobalScrumboardpatternisoftenusedwithCentralCodeRepositoryPatternastheteamsharesalltheagileartefactsandcodeusinganonlinetool.

2.CentralCodeRepositoryPatternInagile,whenateamisusingScrumandXP,theteammembersaredividedinpairsoftwoandareworkingondifferenttasksduringasprint.Whenataskiscompletedtheteammemberscommittheircodetoasharerepositoryforcontinuousintegrationofthecode. It isobservedthatevenwhentheteammembersaregeographicallyapartthey still use a share code repositorywhere they commit their code so that all theteammembers can see the code as well as determine the progress of the project.Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

CentralCodeRepositoryIntent

Thewholeteamwillmaintainacentralcoderepositorysothatbothteamcanseeeachother’scodeandseetheprogressoftheworkdone.

AlsoKnownAs SourceCodeRepositoryorGlobalBuildRepositoryCategory

Communicationcategoryasthispatternhelpstheonshoreandoffshoreteammembers to write code and share it on a central code repository where allteammemberscanseethecodeandedititifrequired.

MotivationWhenateam isdividedondifferent timezonesandareworkingondifferentmodules/subsystemsof aproject theyuse a central code repository to sharetheirworkwithallteammembers.TheycanuseonlinetoolssuchasGitHubforcommitting their codeandmaintainversionsof theproject (Räty,2013).Thishelps the whole team to see the code and provides visibility of the projectprogress.

ApplicabilityUseCentralCodeRepositorywhen:

243

• Team is distributed over different time zones and is working ondifferentmodules/subsystemoftheproject.

Participants• Distributedonshoreandoffshoreagileteammembers.

Collaboration• The onshore team and offshore teammembers share a keyboardwith a

fellow team member from their respective location and once they havefinishedatasktheycommittheircodetoacentralcoderepository.

ConsequencesTheCentralCodeRepositorypatternhasthefollowingbenefits:

1. Itallowsonshoreandoffshoreteammemberstovieweachother’scode.2. Ithelpsindeterminingtheprogressoftheproject.3. As all the team is committing to a central repository, if a team commits

codewitherrorsitcanaffectthewholebuildoftheproject.Knownuses

WDSGlobalisaleadingglobalproviderofknowledge-basedservicestomobileoperators, manufacturers and application and sales channels. In 2004 theycombinedtheirdevelopments,whichwere located inUK,USAandSingapore.They shared their codeona central code repository tominimizeduplicationsandreducecostofmaintenance(Yap,2005).ManycompaniesusecentralcoderepositoryfortheirdistributedprojectssuchasExtolInternational(Kussmauletal., 2004), Valtech (Danait, 2005),Manco (Ramesh et al., 2006), Aginity LLC(Armour,2007),SirsiDynix(Sutherlandetal.,2007),CEInformant(Bose,2008)andABCBank(Modietal.,2013).

RelatedPatternsCentralCodeRepositorypatternisoftenusedwithGlobalScrumBoardPattern.

3.AsynchronousInformationTransferPatternAgile emphases on close face-to-face communication between the team membersrather than detailed documentation. When a team is distributed on different timezones it has been observed that the teams adopted asynchronous tools for sharinginformationwitheachothersuchasemails,wikis,SharePoint.Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

AsynchronousInformationTransferIntent

Duetothetimedifferencebetweentheonshoreandoffshoreteamuseonlinetoolstoexchangeinformationwitheachother.Eachteamshouldresponsetoquerieswithin12hours.

AlsoKnownAs InformationTransferorKnowledgeSharingCategory

Communicationcategoryasthispatternhelpstheonshoreandoffshoreteammemberstoanswereachother’squerieswithin12hours.

244

MotivationWhenateamisdividedondifferenttimezonestheymayhavequeriesaboutworkbutduetothetimedifferencetheycannotgetadirectreplyatthattimeso theyuseemails to communicatequeries,whichare thenansweredwithin12hoursmax.Organisationshave set standards for response time inorder toavoiddelaysinwork(Vax,2008).

ApplicabilityUseAsynchronousInformationTransferwhen:

• Teamisdistributedoverdifferenttimezones.Participants

• Distributedonshoreandoffshoreagileteammembers.Collaboration

• Theonshoreteamandoffshoreteammembersshare informationandaskqueriesusingasynchronoustools.

ConsequencesTheAsynchronousInformationTransferpatternhasthefollowingbenefits:

1. It allows onshore and offshore team members to exchange informationwhen synchronous communication cannot be conducted due to workinghourstimedifference.

2. Ithelpsteammembersfromwaitingforonshoreteammemberavailabilitytoaskaquery.

3. If the team members don’t respond timely it can cause delays in theproject.

KnownusesVTT Technical Research Centre of Finland and National University of Irelandconducted a research on two organisations that were developing a systemtogether.Oneorganisationwasacustomerorganisation inU.Sand theotherorganisationwasadevelopmentorganisationlocatedinIreland.Basedontheirfindingsthecompaniesusedasynchronoustoolsforcommunication.TheyusedwikisforstoringdocumentsandmeetingminutesandusedEmailsfordecisionsand queries (Korkala, 2010). Similarly Valtech used Twiki for asynchronouscommunication(Danait,2005).

RelatedPatternsAsynchronous Information Transfer pattern is often used with Global ScrumBoardandSynchronousCommunicationPattern.

4.SynchronousCommunicationPatternAgile emphases on close face-to-face communication between the team membersrather than detailed documentation. When a team is distributed on different timezones it has been observed that the teams adopted asynchronous tools for sharinginformationwitheachothersuchasemails,wikis,SharePoint.Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

SynchronousCommunicationPattern

245

IntentIn order to discuss issues the teams uses synchronous tools for voice, videoconferencing,documentsharing,applicationsharingetc.

AlsoKnownAs SynchronousKnowledgeTransferCategory

Communicationcategoryasthispatternhelpstheonshoreandoffshoreteammemberstoanswereachother’squerieswithin12hours.

MotivationWhenateamisdividedondifferenttimezonestheymayhavequeriesaboutworkbutduetothetimedifferencetheycannotgetadirectreplyatthattimeso theyuseemails to communicatequeries,whichare thenansweredwithin12hoursmax.Organisationshave set standards for response time inorder toavoiddelaysinwork(Vax,2008).

ApplicabilityUseSynchronousCommunicationPatternwhen:

• Teamisdistributedoverdifferenttimezones.Participants

• Distributedonshoreandoffshoreagileteammembers.Collaboration

• Theonshoreteamandoffshoreteammembersshare informationandaskqueriesusingasynchronoustools.

ConsequencesTheSynchronousCommunicationpatternhasthefollowingbenefits:

1. Itallowsonshoreandoffshoreteammemberstoexchangeinformationwhensynchronouscommunicationcannotbeconductedduetoworkinghourstimedifference.

2. It helps team members from waiting for onshore team memberavailabilitytoaskaquery.

3. If the teammembers don’t respond timely it can cause delays in theproject.

KnownusesCampusSoft is a UK based company that used synchronous communicationwhentheymovedtoAgilewiththeiroffshoresuppliers inIndiaandRomania.TheyusedvideoconferencingfacilitiesforplanningsessionsandlatershiftedtoWebExsessionsandGoToMeetingsothattheycouldsharedesktopswiththeremoteteammembers.FordailyScrummeetingstheypreferredtouseSkypecallandmadeeveryonewearheadsetstomakethemeetingeasier.Forsprintreviewmeetingstheyusedsharingdesktoptoolsaswellasconferencephonessothatmembersfrombothendcouldtalkwitheachother(Summers,2008).

RelatedPatternsSynchronousCommunicationpatternisoftenusedwithGlobalScrumBoardandAsynchronousInformationTransferPattern

c)CollaborationPatternsInthissectionwehavedescribedthedetailofeachcollaborationpattern.

246

1.CollaborativePlanningPokerPatternAnagile teamplaysplanningpoker toputpointsestimationoneachstorycard.Theproductowneralsotakespartinthisactivity.Hetellstheteamtheintentandvalueofa story card baseduponwhich the development teamassigns an estimation on thecard.Basedon thepointsassigned the teammemberswhoassigned the lowestandhighestestimationwill justify their reasons.The teamwillhaveabriefdiscussiononeachstoryandassignanestimationuponwhichthewholeteamagreeson.It has been observed that even when the team is distributed the planning pokeractivityisconductedwhenbothteamsareco-locatedfortheprojectplanningactivity.Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

CollaborativePlanningPokerPatternIntent

OnlyKeypeoplewillholdthisactivityfromonshoreandoffshoreteam.AlsoKnownAs PlanningPokerorScrumPokerCategory

Collaborativecategoryasthispatternhelpstheonshoreandoffshoreteamtodiscussthedurationofastorycard.

MotivationWhen a project is distributed to a team that is divided over different timezones,itisimportantthatalltheteammembersagreeonthetimedurationofa feature before they start developing the project. This helps estimate theduration of the project completion as well as it provides visibility of projectprogress. For this purpose the onshore and offshore team members playplanningpokerinordertocollectivelyagreeontheestimationofastorycard.Oncetheestimationisdecidedtheywriteitdownandapprovedbytheproductowner/client andmove on to the next story card, till all the story cards areestimated.

ApplicabilityUsePlanningPokerpatternwhen:

• Team is distributed over different time zones andwill beworking ondifferentstorycardsinasprint.

Participants• Distributedonshoreandoffshoreagileteam.• Productowner/Client.

Collaboration• Theclientapprovestheestimationmadebytheteammembers.

ConsequencesThePlanningPokerpatternhasthefollowingbenefits:

1. It allows the onshore and offshore teams to agree on a story cardestimation,whichhelpstheteamestablishtheirteamvelocity.

2. Itprovidestheproductowner/clientwithestimationofprojectcompletion

247

3. Ifallteammembersdon’tagreeonestimationonastorycarditcanleadtoalongdiscussion,resultingtheplanningpokertoprolong.

KnownusesUShardware has development centers across North America, South Americaand Asia. When transitioning to distributed agile environment they usedplanningpokeractivity forestimationof their story cards (Wildt, Prikladnicki,2010).

RelatedPatternsPlanning Poker Pattern is often used with Collective Project Planning as itsbetter to conduct this pattern when the whole team is co-located. TheestimatedstorycardsarethensharedontheGlobalScrumboardsothatwholeteamcanviewthemduringtheproject.

2.Follow-the-sunPatternWhenaagileteamisdistributedoverdifferenttimezones ithasbeenobservedthatcompaniescutdownoncostbyincreasingdevelopmenttimebyadopting“followthesun”workflowwhichmeans itallows24hoursdevelopmentduetothedifference intimezonesallowingacompany’semployeestododevelopment24hrsaday(Carmel,Agarwal2001;Yap,2005;Kroll,etal.,2012 ).Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

Follow-the-sunPatternIntent

Onshoreandoffshoreteamswillwork9a.m-5p.maccordingtotheirowntimezones.

AlsoKnownAs24hoursdevelopmentPatterns

CategoryCollaboration category as this pattern helps the onshore and offshore teammanagetheirworkandhandofftheirworktotheotherteambeforetheyleavefromwork.

MotivationConsider a team that is divided into sub-teams that are located on differenttime zones. To adjust the working hours of the offshore team for both theonshoreandoffshoreteamworktogetherisdifficultastheoffshoreteamhasto come in the evening and stay till earlymorning. Thismakes the offshoreteam feel they are less important in comparison to the onshore team and itaffectstheemployees’sociallife.In order to avoid that, the onshore and offshore team “follow-the-sun”approach.Forexampleanemployeeworksfrom9a.m.to5p.m.intheUSA.At5 p.m. she hands over the incomplete task to a colleague in Australia whoworksfrom9a.m.to5p.m.basedonhistimezone.At5p.m.accordingtohiscountry,hetransferstheupdatedtasktoacolleagueinPolandwhoworkson

248

theupdatedtaskforthenexteight-hoursandthenforwardsittohiscolleagueintheUSA(Gupta,2009).

WhiletheemployeeintheUSAhadleftworktwoofhercolleaguesworkedonher task aswhen shewill come to theoffice nextmorning a lot of theworkwouldhavebeendone.Thisworkscenariotakesadvantageofthegeographicaldistances as it allows people from different time zones to work round-the-clockinordertobuildsoftware(Gupta,2007).

Theworkdistributionamongtheteamcanbedoneintwoways.Firsteitherthe3teamsdistributedondifferentgeographicallocationsworkonthesametaskandeachteamkeepsupdatedthetaskasmentionedintheabovescenarioorsecondlyamostefficientway is thatwedivideddifferentaspectof thesameproblemamongtheteamforexample inFigure3wecanseehowaproblemhasbeendistributedamong3teams(Gupta,2009):

Figure7.3.1.Distributionofworkamong3distributedteams.

ApplicabilityUsefollow-the-sunpatternwhen:

• Teamisdistributedoverdifferenttimezones.• Theonshoreandoffshoreteamsareworkingondifferenttasks.

Participants• Distributedonshoreandoffshoreagileteam.

Collaboration• Bothonshoreandoffshoreteamhandovertheirworktoeachotheratthe

endofeveryworkingdayusingonlinetools.Consequences

Thefollow-the-sunpatternhasthefollowingbenefitsandliabilities:1. It allows continues development during different working shifts across

differenttimezones.2. Itallowsbothonshoreandoffshoreteamtoworkaccording to their time

zone without having to either come early to work or stay late till earlymorning.

3. It reduces the development life cycle or time-to-market (Denny, et al.,2008).

4. It limits theonshoreandoffshore team from real-timecommunicationastheoverlappingworkinghoursbetweendifferenttimezonescanbelessorzero.

249

KnownusesYahoo! used follow-the-sun approach when they offshored their Yahoo!PodcastproductfromSunnyvale,CaliforniacampustoYahoo!Bangalore,IndiaCampus (Drummond, Unson, 2008). Similarly organisations like WDSGlobal(Yap,2005) and Wipro Technologies (Sureshchandra, et al.,2008) use follow-sun-approach.

RelatedPatternsFollow-the-sunPatternisoftenusedwithLocalStandupmeetingPatternandScrumofScrumPatternasbothonshoreandoffshoreteammembersareworkingseparately.

3.CollectiveProjectPlanningPatternAgilefocusesonindividualsandinteractionsoverprocessesandtools.Whileplanningfortheprojectthewholeteamispresent.Unlikethetraditionaldevelopmentwhereaprojectmanagerhandsaprojectplantotheteam.Inagilethewholeteamtakespartin the planning activity in order to determine when and how the project will bedeveloped.Ithasbeenobservedthateveniftheprojectisofadistributednatureitisbetter to co-locate the team onshore and offshore team for the project planningactivity. Based on this observed practice we have designed the following patterndetails:PatternName

CollectiveProjectPlanningPatternIntent

Both the onshore team and the offshore team will collectively work in theproject-planningphase.Oncebothteamhaveengagedintheprojectplanningactivity,theteamwillpreparetheprojectbacklog.

AlsoKnownAs ProjectPlanningorAgileProjectPlanningCategory

Coordinationcategoryasthispatternhelpstheonshoreandoffshoreteamtoworktogetherandcomeupwithaprojectplan.

MotivationConsider a team that is divided into sub-teams that are located on differenttimezonesandboththeteamscometoonelocationtodotheprojectplanningactivity.Inthebeginningofanydistributedproject,theoffshoreteamisinvitedtotheonshorelocationsothattheymayworktogetherandunderstandeachother’srequirements.Whiletheteamsareco-locatedtheyworkedonpreparingtheproductbacklogandtheyspendat leastoneortwosprintstogetherbeforetheoffshoreteamleavesandstartsworkingontheproject(Cottmeyer,2008;Therrien,2008).Thishelpstheonshoreteambymakingtheoffshoreteamunderstandtheirworkingstyleandworkstandard.

ApplicabilityUseCollectiveProjectPlanningpatternwhen:

250

• Teamisdistributedoverdifferenttimezones.Participants

• Distributedonshoreandoffshoreagileteam.Collaboration

• Onshoreteamandoffshoreteamworktogethertomakeaproductbacklog.Consequences

TheCollectiveProjectPlanningpatternhasthefollowingbenefitsandliabilities:1. It allows the onshore and offshore teams to work together and understand

eachother.2. Onshoreteamworkswiththeoffshoreteamandmakesthemunderstandwhat

typeofworktheywant.3. Itaddsadditionalcostof travelandstayof theoffshoreteamat theonshore

location.Knownuses

FAST,asearchcompanywithheadquarters inNorwaywhilebuildingasearchapplicationontopoftheircoresearchplatformusedcollectiveprojectplanningto co-locate the team and make them work together in project planningactivities (Berczuk, 2007). Siemens also used collaborative planning for theirdistributedprojects(Avritzer,Paulish,2010;Avritzeret.al,2007)inwhichteammembersfrommultiplesitesgot involvedintheearlystagesoftheproject inordertocreateanopencommunicationchannelandhighleveloftrustamongthedistributedteammembers(Avritzeret.al,2010)

RelatedPatternsCollectiveProjectPlanningPatternisoftenusedwithProjectCharterPatternasitprovidesacentraldocument thatconsistsof thegoalandobjectivesof theprojectwrittenbytheclient.

4.Visitonshore-offshoreTeamPatternAsagileemphasesoncloseface-to-facecommunicationbetweentheteammembersithasbeenobserved thatwhen the team isdividedondifferent timezones, the teammemberstravelquarterlyorannuallytovisiteachother.Thisactivityhelpsbuildtrustamong the team members and helps them understand each other’s culturaldifferences (Ramesh, 2006; Therrien, 2008; Summers, 2008;Paasivaaraet al., 2014).Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

Visitonshore-offshoreTeamPatternIntent

Bothonshoreandoffshoreteamsshouldquarterly/annualvisiteachotherinordertobuildtrust,exchangeculturalvaluesandimproveteamcoordination.

AlsoKnownAs Travelonshore-offshoreCategory

Collaboration category as this pattern helps the onshore and offshore teammemberstoco-locateandunderstandeachotherandbuildagoodrelationship,whichimprovesteamcoordination.

251

MotivationWhena team isdividedondifferent timezones theydon’t feel that theyarebothpartofoneteamandtheydon’ttrusteachother.Theydon’tunderstandeachother’sculturalvaluesandworkethics.Inordertosolvetheseissuestheonshoreandoffshoreteamvisitseachothertodevelopthefeelingoftrustandunderstandeachother’s cultural andworkingvalues.During thesevisits theyattend training together as well as engage into informal activities to betterunderstandeachother. Thishelpsbuildabondbetween the teammembers,whichresultsingoodteamcoordination.

ApplicabilityUseVisitonshore-offshoreTeamwhen:

• Teamisdistributedoverdifferenttimezones.Participants

• Distributedonshoreandoffshoreagileteammembers.Collaboration

• Theonshoreteamandoffshoreteammembersvisiteachothertoimproveteamcoordination.

ConsequencesTheVisitonshore-offshoreTeampatternhasthefollowingbenefits:

1. Itallowsonshoreandoffshoreteammemberstoexchangeculturalvalueswitheachotherandworkethics.

2. Ithelpsteammembersto feel theyarepartofoneteam,whichdevelopstrustamongonshoreandoffshoreteammembers.

3. Thetravellingaddsadditionalcosttotheprojectbudget.Knownuses

EricssonisaSwedishmultinationalproviderofcommunicationstechnologyandservices.TobuildaXaaSplatformandasetofservicestheyusedagilesoftwaredevelopment methodologies. The development team was distributed over 5sites located in3countries.Fourof thesiteswere located inEuropeandonewaslocatedinAsia.Theyconductedworkshops,whichwereattendedbyteammembers from different locations. The purpose of these workshops was tocreateacommonvisionforthewholeorganisationbysettingcommonvaluesaswell also to improve the collaboration between the sites, thus build trust(Paasivaaraetal.2014).

RelatedPatternsVisit onshore-offshore Team pattern is often used with Collective ProjectPlanningPatternasplanningisbetterdonewhenthewholeteamisco-located.

d)VerificationPatternsInthissectionwehavedescribedthedetailofeachverificationpattern.1. ProjectCharterPattern

In project management, project charter is a statement that defines the scope,objectives and participants of a project. It is used to explain the roles andresponsibilities,outlineoftheprojectobjectivesandidentifymainstakeholders.Ithas

252

beenobservedthatwhilestartingadistributedprojectusingagilemanyorganisationuseprojectcharter toclarify thegoalsandobjectivesof theproject tobothonshoreandoffshore team (Galen,2009).Basedon thisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

ProjectCharterPatternIntent

Beforestartingtheprojectplanningactivity,agileteamsuseprojectcharterinordertohaveacentraldocumentbetweentheonshoreandoffshoreteamthatdefinestheproject.

AlsoKnownAs ProjectDefinitionorProjectStatementCategory

Verification category as this pattern helps the onshore and offshore team tohave a central document clarifying the project goals and objectives,which iswrittenbytheproductowner/client.

MotivationWhen a project is distributed to a team that is divided over different timezones, a central document is written known as the project charter, whichclarifiestheonshoreandoffshoreteamthegoalsandobjectivesoftheproject.It also identifies the roles and responsibilities of the onshore and offshoreteam.Thepurposeofthisactivityistohaveadocumentthathelpstheteamintheproject-planningtask.

ApplicabilityUseProjectCharterpatternwhen:

• Teamisdistributedoverdifferenttimezones.Participants

• Distributedonshoreandoffshoreagileteam.• Client.

Collaboration• Theclientgivestheprojectchartertotheonshoreteamandoffshoreteam

toclarifythegoalsoftheproject.Consequences

TheProjectCharterpatternhasthefollowingbenefits:1. Itallowstheonshoreandoffshoreteamstounderstandtheproject.2. It is intendedtoclearlysetthestagefortheprojectbyaligningtheteamand

settingsgoalsandexpectations.Knownuses

IONATechnologiesusedProjectCharter fortheirdistributedprojects inorderto have a central document that clarifies the goals of the project to bothonshore and offshore teammembers (Poole, 2004). Similarly in a case studyconducted by Brown (2011) on Agile-at-Scale Delivery it was observed thatorganisationsuseprojectcharter.

RelatedPatternsProjectCharterpatternisoftenusedwithVisitonshore-offshoreTeampattern.

253

2.OnshoreReviewMeetingPatternInagile,at theendofeachsprint,asprintreviewmeeting isheld inwhichtheteammeetswiththeclientsandshowsthemtheworktheyhavedonethroughademo.Inthismeetingtheclientgivesremarksabouttheworkandiftheyrequireanychangestheytelltheteam.Ithasbeenobservedthatwhentheteamisdistributedondifferentlocations,thentheteamthatisco-locatedwithclientconductsthereviewmeeting.Basedonthisobservedpracticewehavedesignedthefollowingpatterndetails:PatternName

OnshoreReviewMeetingIntent

The onshore team will present the demo as they are located where theclientis.

AlsoKnownAs SprintReviewMeetingCategory

Verification category as this pattern helps the client see the progress of theprojectaswellastheycansuggestearlychanges.

MotivationConsider a team that is divided into sub-teams that are located on differenttimezonesandoneoftheteamislocatedinthesamecountryastheclient.Inordertoshowtheprogressoftheprojectitismoreconvenientthattheteam,whichislocatedneartheclient,presentsthedemoinordertohaveaface-to-face meeting. Once the meeting has ended the onshore team briefs theoffshoreteamstheremarksoftheclient.

ApplicabilityUseOnshoreReviewMeetingpatternwhen:

• Teamisdistributedoverdifferenttimezones.• Theonshoreislocatedinthesamecountryastheclient.

Participants• Distributedonshoreandoffshoreagileteam.• Client

Collaboration• Onshore team presents demo to the client and discusses the meeting

minuteswiththeoffshore.Consequences

TheOnshoreReviewMeetingpatternhasthefollowingbenefitsandliabilities:1. It allows the client to meet the development team face-to-face and give

feedback.2. Itallowsbothonshoreandclientstodiscusswhatchangestheywantandhow

muchtimewillberequiredbasedonthemodification.3. It limits the offshore team from meeting the clients which can cause the

offshore team from discussing the changes and giving their remarks on theclientsfeedback.

254

KnownusesWipro Technologies, a global service provider company used onshore reviewmeetings so that they could get quick feedback from the customer/businessuser, which was then shared with the remote team over mail and/orteleconference (Sureshchandra et al., 2008). Similarly when SirsiDynix, USAoutsourced their work to Starsoft, Ukraine they also used onshore reviewmeetingstoshowthedemooftheworkdone(Sutherlandetal.,2007)

RelatedPatternsOnshore Review Meeting pattern is often used with AsynchronousRetrospective Meetings Pattern because after the demo both onshore andoffshore team members conduct their separate retrospective meetings.

255

256