Uitdagingen bij scrum implementatie. Een overzicht van reeds uitgevoerde casestudies.

Transcriptie

1 Uitdagingen bij scrum implementatie. Een overzicht van reeds uitgevoerde casestudies. Herm van Veen Strategisch Organiseren, Master BCO Vrije Universiteit Amsterdam Faculteit sociale wetenschappen Afdeling organisatie wetenschappen

2 Inleiding Steeds meer IT bedrijven overwegen de overstap van een planmatige software ontwikkelmethode naar een meer flexibele methode (Misra S. C., 2012; Salo & Abrahamsen, 2008). Flexibele ontwikkelmethodes verschillen onder anderen van traditionele ontwikkelmethodes in de manier waarop zij met veranderingen omgaan en de manier waarop teams samenwerken (Nerur, Mahapatra, & Mangalara, 2005; Misra, Kumar, & Kumar, 2009). Nerur et al. (2005) geven een overzicht van de verschillen, samengevat in figuur 1: Figuur 1. Verschillen tussen flexibele en planmatige software ontwikkelmethodes naar Nerur et al., 2005 Planmatig (traditioneel) Flexibel (Agile) Fundamentele aannames Systemen zijn goed te specificeren, voorspelbaar en de bouw er van moet zorgvuldig gepland worden Systemen kunnen opgebouwd worden door kleine teams vanuit principes van continu testen, feedback verzamelen en verbeteren Controle Proces georiënteerd Mens georiënteerd Managementstijl Hiërarchisch en vanuit controle Leiderschap en samenwerking Kennis management Expliciet Impliciet Rollen Gespecialiseerd individueel werk Zelforganiserende teams met aanmoediging van taakwisseling Communicatie Formeel Informeel Klantenrol Belangrijk Cruciaal Project cycli Geleid door taken of activiteiten Geleid door productfuncties Ontwikkel model Levenscyclus (Waterfall/Spiral) Evolutionair-lever model Gewenste organisatie structuur Mechanisch (bureaucratisch met veel formalisatie) Organisch (flexibel en participatief) Technologie Geen restricties Object georiënteerde technologie Boehm (2002) stelt dat er voor beide soorten methodes situaties zijn waarin zij het beste tot uiting komen. Flexibele methoden zijn geschikt voor projecten waar de uitkomst onduidelijk is, er snel ingespeeld moet kunnen worden op tussentijdse veranderingen en klanten in staat zijn waardevolle input te leveren. Volgens Boehm (2002) hebben steeds meer IT projecten deze karakteristieken. De markt vraagt om korte levertijden en de eisen aan software veranderen voortdurend, ook tijdens het ontwikkelproces (Rising & Janoff, 2000; Long & Starr, 2008; Scotland 1

3 & Boutin, 2008). Met planmatige methodes lukt het organisaties niet hier op in te spelen (Nerur, Mahapatra, & Mangalara, 2005). Het is daarom voor veel organisaties noodzaak meer flexibele methodes te implementeren. Eén van de meest gebruikte flexibele software ontwikkelmethodes is scrum. Volgens een survey van Versionone (2011) onder meer dan 6000 gebruikers van flexibele software methodes, wordt scrum in 66% van de gevallen gebruikt. Casestudies laten zien dat zowel kleine, middelgrote en grote organisatie als Yahoo, Microsoft, Intel en Nokia, gebruik maken van de scrum methode (Marchenko & Abrahamson, 2008; Rising & Janoff, 2000; Fitzgerald, Hertnett, & Conboy, 2006; Scotland & Boutin, 2008). De scrum methode werkt met drie rollen: de scrum master, het (zelf organiserende) ontwikkelteam en de product eigenaar (Schwaber, 1995). Als de software ontwikkeld wordt voor een klant, neemt de klant deel in het projectteam als producteigenaar. In het ontwikkelteam nemen medewerkers met verschillende functies plaats (ontwerpers, ontwikkelaars, testers, etc.). Het ontwikkelteam ontdekt gaandeweg hoe het product er uit komt te zien en wat daar allemaal voor nodig is. Een scrum project wordt opgedeeld in drie tot vier weken durende iteraties die sprints worden genoemd. Voorafgaand aan elke sprint komen het ontwikkelteam en de product eigenaar bij elkaar om te bespreken welke functies het product moet bevatten. Dan bepaald het ontwikkelteam zelf wat zij in de komende sprint af kunnen krijgen. De voortgang van deze lijst met actiepunten wordt voor iedereen zichtbaar bijgehouden op een sprint backlog en een burndown chart. Op deze manier behoudt het ontwikkelteam het overzicht. Elke ochtend komt het ontwikkelteam 15 minuten bij elkaar met de scrum master. Hier wordt de voortgang besproken en kunnen teamleden reageren op problemen die anderen tegenkomen. Een sprint wordt afgesloten met een bijeenkomst waarin de resultaten worden getoond aan de producteigenaar. Het ontwikkelteam presenteert een zo concreet mogelijk product waar de product eigenaar op kan reageren. Daarna worden de wensen voor de volgende sprint vast gesteld. Na de bijeenkomst met het ontwikkelteam, de producteigenaar en de scrum master, komt het ontwikkelteam bij elkaar. Het ontwikkelteam evalueert het proces van de sprint en stelt leer- en actiepunten voor de volgende sprint op. (Srinivasan & Lundqvist, 2009; Rising & Janoff, 2000; Schwaber, 1995). Cardozo et al. laten in een review van 28 casestudies naar scrum implementaties zien dat (afdelingen van) organisaties betere resultaten kunnen behalen met het werken volgens de scrum methode dan dat zij behaalden met planmatige methoden. Van de 28 casestudies meten veertien studies een productiviteitsstijging, zes studies rapporteren een kwaliteitsstijging, vijf studies noemen een stijging van de klant tevredenheid en eveneens vijf studies spreken van een stijging van de team motivatie. In totaal beschrijft 75% van de door Cardozo et al. onderzochte rapporten een verbetering. Dezelfde casestudies noemen echter ook allerlei uitdagingen die organisaties 2

4 tegenkomen bij het implementeren van de scrum methode. Figuur 1 laat een aantal verschillen zien tussen planmatige en flexibele ontwikkelmethoden en de overstap hiertussen blijkt in de praktijk zowel voor medewerkers, managers als klanten niet altijd gemakkelijk (Srinivasan & Lundqvist, 2009; Marchenko & Abrahamson, 2008; Hosbond & Nielsen, 2008; Mann & Maurer, 2005; Moe, Dingsøyr, & Dyba, 2010). Onderzoek van Boehm en Turner (2005) en onderzoek van Nerur et al. (2005) geeft een overzicht van uitdagingen die organisaties tegen komen bij implementaties van flexibele software ontwikkelmethodes, maar een overzicht van de uitdagingen die organisaties specifiek tegenkomen bij scrum implementaties ontbreekt. Bovendien geven zowel Boehm en Turner als Nerur et al. niet aan waar de uitdagingen die zij beschrijven vandaan komen en is in hun papers dus niet terug te vinden wanneer deze uitdagingen voorkomen. Dit literatuur review stelt de vraag: welke uitdagingen, resultaten en relevante factoren beschrijven casestudies naar scrum implementaties? Een dergelijk overzicht helpt organisaties in te schatten welke uitdagingen zij kunnen verwachten bij een scrum implementatie. Daarnaast biedt een overzicht van uitdagingen richtlijnen voor toekomstig onderzoek naar scrum implementaties. Moe et al. (2010) laten zien dat er veel onderzoek is gedaan naar scrum implementaties, maar dat een verklaring van deze uitdagingen met wetenschappelijke theorieën ontbreekt. Het belang hiervan is tweeledig: het scherpt veranderkundige theorieën aan en helpt organisaties niet alleen te begrijpen welke uitdagingen zij kunnen verwachten, maar ook te begrijpen wat zij daar aan kunnen doen. Om de aanbevelingen van Moe et al. (2010) op te volgen en uitdagingen bij scrum implementaties te verklaren, is het allereerst belangrijk te weten welke uitdagingen er voorkomen en wanneer. Theorie Nerur et al. (2005) noemen vier categorieën uitdagingen bij implementaties van flexibele ontwikkelmethoden: management en organisatie, mensen, processen en technologie. De categorie management en organisatie bevat uitdagingen op het gebied van organisatiecultuur, structuur, beloningssystemen en management stijl. De categorie mensen bevat uitdagingen op het gebied van competenties en klantrelaties. In de categorie proces staan veranderingen naar een mensgericht proces, korte iteraties, het managen van grote projecten en het selecteren van de juiste flexibele ontwikkelmethode. In de categorie technologie staan de geschiktheid van de huidige technologie en het leren gebruiken hiervan. Boehm en Turner (2005) noemen drie categorieën uitdagingen bij implementaties van flexibele ontwikkelmethoden: ontwikkel proces conflicten, business proces conflicten en mensen conflicten. In de eerste categorie beschrijven zij uitdagingen die ontstaan door variatie in methodes binnen de ontwikkeling van één product, het toepassen van een nieuwe ontwikkelmethode op een 3

5 proces dat al jaren op eenzelfde manier plaatsvindt en het voldoen aan eisen die vanuit de organisatie staan voorgeschreven. In de categorie Business proces conflicten vallen uitdagingen op het gebied van medewerker competenties en uitdagingen die ontstaat door standaarden voor het meten van de voortgang en volwassenheid van een proces waar aan voldaan moet worden. Bij mensen conflicten wordt de houding van het management genoemd, logistieke uitdagingen, het veranderen van teams en veranderkundige uitdagingen. Het lijkt lastig om een goede indeling te maken van de uitdagingen bij de implementaties van flexibele ontwikkelmethoden. Bij de indeling van Nerur et al. is het niet duidelijk waarom proces een aparte categorie is. Proces uitdagingen zijn van toepassing op een groep mensen. Het is daarmee eigenlijk dezelfde categorie als mensen, maar dan op een ander niveau. Dit geldt ook voor de cultuur uitdagingen (dat gaat over groepen mensen), maar cultuur uitdagingen vallen bij Nerur et al. onder management en organisationeel. Dit lijkt niet consistent. Bij Boehm en Turner is het niet duidelijk waarom logistieke uitdagingen onder mensen conflicten valt. Bovendien is de derde uitdaging in deze categorie, veranderkundige uitdagingen, erg breed en daardoor nietszeggend. Het vertoont overlap met de houding van het management, maar ook met competenties van medewerkers (bijvoorbeeld om in een team te kunnen werken). Uitdagingen op het gebied van medewerker competenties valt onder business processen. Boehm zou hiervoor gekozen kunnen hebben omdat zijn paper aan het management gericht is. Vanuit dat perspectief is het een business conflict dat de HRM afdeling op moet lossen. Maar er is ook wat voor te zeggen om het in te delen bij mensen conflicten. De indeling van zowel Boehm en Turner als de indeling van Nerur et al. lijken een poging om de uitdagingen bij scrum implementaties voor het management in te delen. Alsof er wordt verteld aan welke knoppen er gedraaid moet worden. Dit resulteert in beide gevallen in een indeling die deels overlapt en niet consistent is. Dit onderzoek zal daarom zoeken naar een nieuwe indeling met minder overlap en meer consistentie. Methode Dit onderzoek kijkt naar tien scrum implementatie casestudies. Om tot tien artikelen te komen is binnen Google Scholar gezocht op casestudy scrum implementation. Daarnaast is gezocht op literature review scrum. Dat leverde een lijst met ruim 30 casestudies op. De casestudies moesten aan twee criteria voldoen: het moest niet gaan over scrum met distributed teams. De uitdagingen die komen kijken bij het implementeren van scrum bij distributed teams wijken namelijk sterk af van de uitdagingen bij teams op één locatie (Sutherland, Viktorov, Blount, & Punktikov, 2007). Bovendien geven Hossain, Babar en Paik (2009) een overzicht van de specifieke uitdagingen bij scrum implementaties bij distributed teams en is het niet nodig om dat 4

6 werk opnieuw te doen. Als tweede criteria moesten de casestudies uitdagingen, resultaten en voldoende relevantie factoren beschrijven. Tabel 1 geeft de tien artikelen weer die aan deze twee criteria voldoen. Tabel 1. Gebruikte casestudies Case Referentie 1 Scrum implementatie bij AG Communication Systems (Rising & Janoff, 2000) 2 Scrum implementatie bij GameDevCo (Srinivasan & Lundqvist, 2009) 3 Scrum implementatie met meerdere projecten bij Nokia (Marchenko & Abrahamson, 2008) 4 Scrum implementatie (mislukt) bij onderdeel telefoonmaatschappij (Hosbond & Nielsen, 2008) 5 Scrum implementatie bij Healthwise (Long & Starr, 2008) 6 Scrum implementatie bij anoniem ICT bedrijf, onderzoek vanuit teamoriëntatie perspectief (Moe, Dingsøyr, & Dyba, 2010) 7 Scrum implementatie bij meerdere afdelingen Yahoo! Europa (Scotland & Boutin, 2008) 8 Scrum implementatie bij Petrosleuth (Mann & Maurer, 2005) 9 Scrum implementatie bij Yahoo! Music (Cloke, 2007) 10 Scrum implementatie bij Motorola (Fitzgerald, Russo, & O'Kane, 2003) Resultaten Tabel 2 geeft een overzicht van de relevante factoren van de verschillende organisaties. Livermore (2008) vindt in een onderzoek naar factoren die de implementatie van flexibele ontwikkelmethodes beïnvloeden vier significante factoren: training in de nieuwe methodologie, management bemoeienis, toegang tot externe bronnen en de omvang van het bedrijf. Een uitgedachte implementatie strategie, het gebruik van modellen en templates, het soort software dat ontwikkelt wordt en het herplaatsen van een team, hebben volgens Livermore geen significante invloed. Deze vier factoren zijn gebruikt in dit onderzoek en zijn terug te vinden in tabel 2. Daarnaast zijn ook de startpositie van het bedrijf en de tijd die voor de implementatie werd uitgetrokken in de tabel opgenomen. Vanuit veranderkundig onderzoek is bekend dat de omvang van de kloof die overbrugt moet worden en tijdsdruk belangrijke factoren zijn voor het wel of niet slagen van een implementatie (Steltzer & Mellis, 1998). Er zijn meer factoren die van invloed kunnen zijn op de implementatie van scrum, zoals bijvoorbeeld de manier van communiceren of de betrokkenheid van medewerkers (Steltzer & Mellis, 1998). Deze factoren zijn echter onvoldoende terug gevonden in de gebruikte casestudies om ze in de tabel op te nemen. 5

7 Tabel 2. Overzicht kenmerken situaties tien scrum implementaties. Training Management bemoeienis Externe bronnen Omvang* Start situatie Tijdsdruk 1 Nee Veel ruimte voor teams Nee groot Ervaring met flexibele patterns, veel van scrum was niet nieuw Nee, experiment van een half jaar 2 Nee, ook niet voor Halverwege implementatie Consultant voor de klein Chaotische situatie, net een mislukte Niet op het werken volgens scrum: nieuwe medewerkers een extra managementlaag eerste helft poging achter de rug om een planmatige twee jaar uitgeprobeerd. Wel op met veel bemoeienis implementatie + boeken methode te implementeren constant blijven presteren 3 Ja Weinig visie, wel veel eisen Cursus voor scrummaster groot Al wat experimenten met scrum gedaan Nee, eerst een experiment uitgevoerd 4 Gecertificeerde programma s Sterk gecontroleerd Naast cursussen niet middel Geen eerder ervaring met flexibel werken Ja, er moesten snel resultaten geboekt worden 5 Ja Weinig Jeff Sutherland adviseert middel Eerdere pogingen flexibel werken mislukt Nee, in fases geïmplementeerd 6 Ja, twee dagen cursus + Weinig, maar scrummaster Naast cursussen niet middel Geen flexibele ontwikkel ervaring en Nee, pilot project, maar wel veel druk scrummaster training had wel veel invloed geen ervaring met zelfmanagement op uitkomst project 7 Ja Veel vrijheid voor teams Nieuwe medewerkers groot Al een tussenvorm van planmatig en Nee, eerst pilot Daarna langzaam met scrum ervaring flexibel werken geïmplementeerd. uitgerold 8 Nee Weinig projectmanager was klein De helft van het team had scrum en pair Nee, langzaam kennisgemaakt in ook teamlid programming ervaring project van 9 maanden 9 Ja, scrum masterclass Veel ruimte voor teams Niet naast masterclass middel Geen ervaring met flexibel werken Nee, eerst uitproberen 10 Nee Weinig, proces werd bottomup uitgedacht Nee groot Een aantal medewerkers hadden ervaring met scrum Nee, eerst uitproberen, bottom-up verspreiding over organisatie * klein: 5-30 medewerkers, middel: medewerkers en groot: > 250 medewerkers. 6

8 Tabel 3. Overzicht van uitdagingen en resultaten tien scrum implementaties. Uitdagingen tijdens implementatie 1 Scrummaster heeft moeite om 15 minuten bijeenkomsten productief te houden, backlog is te ingewikkeld, backlog verandert tijdens sprint, op maat maken methode kost veel tijd. 2 Samenwerken verschillende scrums lastig, geen product eigenaar, gebrek begrip verificatie en validatie, beslissingen worden vergeten, verkeerde tools, medewerkers snappen scrum niet, lang uitgeweid over theorie, scrummasters begrijpen cultuur niet, in sprintretrospectives niks gedeeld, organisatiestructuur sluit niet aan. 3 Te veel aandacht voor het proces, te weinig aandacht voor proces, geen duidelijke verwachtingen vanuit het management, te veel bug fixing, het inpassen van onderzoek werkzaamheden in sprint, te gespecialiseerd team, individualistische leden, te volle sprint, moeilijk voortgang bij te houden, te veel management bemoeienis. 4 Medewerkers niet voldoende competenties, onrealistische verwachtingen vanuit het management, onduidelijke verschuivende machtsstructuren, geen geschikte ruimtes, te veel documentatie geëist vanuit organisatie. 5 Scrummasters ook product eigenaar, scrummasters eisen te veel, veel discussie over het proces, medewerkers vertrekken omdat ze niet zo transparant willen werken, communicatie tussen teams wordt slechter 6 Moeilijk modules van andere organisatie te integreren, moeilijk om backlog rond te krijgen, iedereen zwijgt tijdens meetings, medewerkers volgen eigen plan, iedereen werkt alleen, team ontdekt fouten niet Resultaten eind implementatie Verbetering van zichtbaarheid proces, communicatie, oplevertijd, klantrelatie, meer vertrouwen en kennisoverdracht Backlog werkt niet, beslissingen worden vergeten, slechte tools, sterk gefragmenteerd team, slechte communicatie. Er moesten veel uitdagingen door het team overwonnen worden, uiteindelijk bleek scrum effectiever dan planmatig werken. Medewerkers niet creatief en proactief, geen innovatie, onduidelijke machtsstructuren, documentatie eisen niet gehaald. Veel ging mis, maar na vier jaar is tevredenheid en communicatie, medewerkers verbeterd en overuren teruggedrongen. Communicatie teams onderling afgenomen. Pilot project liep uit de hand, moeite met teamoriëntatie, slechte onderlinge communicatie. Stijging klanttevredenheid. 7 Lastig samenwerken met teams uit andere landen met ander proces, disciplines niet gemengd in organisatie. Betere samenwerking en overzicht proces. Daarna succesvol uitgerold, geen concrete resultaten daarvan bekend. 8 Steeds aanpassingen maken, tools niet geschikt, wisselingen in teams, klanten niet klaar voor hun rol Overwerk afgenomen, stijging klanttevredenheid. 9 Burn down chart bijhouden vraagt nodige oefening Betere focus en prioritering, beter in spelen op snel veranderende eisen en sneller kunnen leveren. 10 Rol testers lastig, te lange sprint, moeilijk 15 minuten bijeenkomsten productief te houden, afhankelijk van andere partijen, beoogde levertijd niet gehaald, scrum sluit niet aan bij organisatiestructuur, andere afdelingen werken anders, bijdragen aan algemene roadmap lastig, coördinatie teams erg lastig, te veel tijdens één sprint. Planning en het bijhouden van voortgang wordt gezamenlijk proces, verbetering communicatie, betere levertijden. 7

9 Discussie en Conclusie Dit onderzoek stelt op basis van de gevonden uitdagingen, resultaten en relevantie factoren een nieuwe categorisering voor van uitdagingen bij scrum implementaties. Tabel 3 laat zien dat de uitdagingen die organisaties tegen komen bij scrum implementaties divers zijn en niet altijd tot dezelfde resultaten leiden. Bij organisatie 2 staan bijvoorbeeld veel uitdagingen beschreven, maar aan het einde van de implementatie blijkt scrum effectiever dan de planmatige methode waar de organisatie eerder mee werkte. Daar staat organisatie 4 tegenover, waar deels dezelfde uitdagingen worden genoemd, maar waar de implementatie niet tot de gewenste resultaten leidt. Tabel 2 biedt een aantal mogelijke verklaring. Bij organisatie 4 is meer tijdsdruk en meer controle vanuit het management. Het is niet het doel van dit onderzoek om verklaringen te bieden, maar deze verschillen bieden wel een uitgangspunt voor een ander perspectief voor de categorisering van de uitdagingen. Uitdagingen lijken voor sommige organisaties onoverkomelijk terwijl ze bij andere organisaties worden ontvangen als een logisch onderdeel van het leerproces. Dit onderzoek stelt voor uitdagingen te benoemen als gebreken. Op verschillende gebieden kan er gebrek zijn, maar dit kan worden opgevangen door andere gebieden Wanneer er echter ook op andere gebieden een gebrek is, gaat dit uiteindelijk ten koste van het resultaat. Een voorbeeld hiervan is het gebrek aan ervaring met het werken van scrum bij organisatie 3. Dit kan worden opgevangen door het lerend vermogen van een team, maar wanneer het aan ruimte voor het team en het gebruiken van externe bronnen ontbreekt, is het lastig de gewenste resultaten te bereiken. Figuur 2 geeft de categorisering van de gevonden uitdagingen weer vanuit dit perspectief van gebreken. Figuur 2. Gebreken die organisaties tegen kunnen komen bij scrum implementaties. 1. Gebrek aan competenties/ervaring scrummaster heeft moeite om daily meetings productief te houden backlog is te ingewikkeld, moeilijk af te krijgen backlog verandert tijdens sprint teveel in één sprint, te lange sprints gebrek begrip verificatie en validatie medewerkers snappen scrum niet scrummasters begrijpen cultuur niet beslissingen worden vergeten te gespecialiseerd team, rol testers lastig, geen product owner eerst te veel aandacht en later te weinig aandacht voor het proces van de scrummaster klanten niet klaar voor hun rol 2. Gebrek aan integratie/aansluiting andere partijen samenwerken verschillende scrums lastig organisatiestructuur sluit niet aan 8

10 te veel bug fixing het inpassen van onderzoek werkzaamheden in sprint onduidelijke verschuivende machtsstructuren communicatie tussen teams wordt slechter moeilijk modules van andere organisatie te integreren lastig samenwerken met teams uit andere landen met ander proces disciplines niet gemengd in organisatie, scrum sluit niet aan bij organisatiestructuur afhankelijk van andere partijen 3. Gebrek aan vrijheid/ruimte geen duidelijke verwachtingen vanuit het management te veel management bemoeienis. onrealistische verwachtingen vanuit het management te veel documentatie geëist vanuit organisatie scrummasters eisen te veel 4. Gebrek aan geschikte faciliteiten verkeerde tools, tools niet geschikt moeilijk voortgang bij te houden geen geschikte ruimtes 5. Gebrek aan lerend vermogen lang uitgewijd over theorie op maat maken methode kost veel tijd team ontdekt fouten niet 6. Gebrek aan teamoriëntatie in sprintretrospectives niks gedeeld individualistische leden medewerkers vertrekken omdat ze niet zo transparant willen werken iedereen zwijgt tijdens meetings medewerkers volgen eigen plan iedereen werkt alleen, Toekomstig onderzoek kan zich in lijn met Moe et al. (2010) richten op het verklaren van het ontstaan van gebreken bij scrum implementaties en op het beschrijven van de relaties tussen de verschillende gebreken. Het overzicht dat dit literatuur review biedt, laat zien dat organisaties in staat zijn gebreken op te vangen en geeft een aanzet tot verder onderzoek naar de voorwaarden voor dit vermogen. 9

11 Bibliografie Boehm, B. (2002). Get ready for agile methods, with care. Computer (35), Boehm, B., & Turner, R. (2005). Management challenges to implementing Agile processes in traditional development organizations. IEEE Software, Cardozo, E., Neto, J. B., Barza, A., Franca, A., & Silva, d. F. (2010). 14yh International Conference on Evaluation and Sassessment in Software Engineering (EASE). Scrum and productivity in software projects: A systematic literature review, (pp. 1-4). Cloke, G. (2007). Get your agile freak on! Agile adoption at Yahoo! Music. agile conference (pp ). IEEE. Fitzgerald, B., Hertnett, G., & Conboy, K. (2006). Customising agile methods to software practices at Intel Shannon. European Journal of Information Systems, 15 (2), Fitzgerald, B., Russo, N. L., & O'Kane, T. (2003). Software development method tailering at motorola. Communications of the ACM, 4 (64), Hosbond, J., & Nielsen, P. (2008). Misfit or Misuse? Lessons from implementation of Scrum in radical product innovation. Agile Processes in Software engineering and Extreme Programming, Hossain, E., Babar, M. A., & Paik, H. (2009). Using scrum in global software development: a systematic literature review. Global software engineering. Hossain, E., Babar, M. A., & Paik, H. Y. (2009). Using scrum in global software development: a systematic literature review. In Global Software Engineering, ICGSE Fourth IEEE International Conference (pp ). IEEE. Livermore, J. (2008). Factors that significantly impact the implementaion of an agile software development methodology. Journal of Software, 3 (4), Long, K., & Starr, D. (2008). Agile 2008 Conference. Agile supports improved culture and quality for healthwise (pp ). IEEE. 10

12 Mann, C., & Maurer, F. (2005). A case study on the impact of Scrum on overtime and Customer satisfaction. In Agile Conference, 2005, Proceedings (pp ). IEEE. Marchenko, A., & Abrahamson, P. (2008). Agile 2008 Conference. Scrum in a multiproject environment: an ethnographically-inspired case studie on the adoption challenges (pp ). IEEE. Misra, S. C. (2012). Agile Software Development Practices: Evolution, Principles, and Criticisms. International Journal of Quality & Reliability Management, 29 (9), Misra, S. C., Kumar, V., & Kumar, U. (2009). Identifying some important success factors in adopting agile software development practices. Journal of Systems and Software, 82 (11), Moe, N. B., Dingsøyr, T., & Dyba. (2010). A teamwork model for understanding an agile team: a case stydy of a scrum project. Information and Software Technology, 52 (5), Nerur, S., Mahapatra, R., & Mangalara, G. (2005, mei). Challenges of Migrating to Agile Methodlogies. Communications of the ACM, Rising, L., & Janoff, N. S. (2000). The Scrum software development process for small teams. Software, IEEE, 17 (4), Salo, O., & Abrahamsen, P. (2008). Agile methods in European Embedded Development Organizations: a survey study of Extreme programming and srum. IET Software, 2, Schwaber, K. (1995). Scrum development process in Proceedings of the workshop on Business Object Design and Implementation. OOPSLA '95, (pp. 1-23). Scotland, K., & Boutin, A. (2008). Integrating scrum with the process framework at yahoo! Europe. Agile 2008 Conference (pp ). IEEE. Scotland, K., & Boutin, A. (2008). Integrating scrum with the process framework at yahoo! Europe. Agile 2008 Conference (pp ). IEEE. 11

13 Srinivasan, J., & Lundqvist, K. (2009). Using Agile methods in software product development: A case study. Information Technology: New generations. ITNG'09. Sixth International Conference (pp ). IEEE. Steltzer, D., & Mellis, W. (1998). Succes factors of organizational change in software process improvement. Software Process: Improvements an Practice, 4 (4), Sutherland, J., Viktorov, A., Blount, J., & Punktikov, N. (2007). Distributed scrum: agile project management with outsourced development teams. System sciences, Swart, N. (2001). Lessen uit de veranderkunde toegepast in ICT projecten. Management en Informatie (6), Takeuchi, H., & Nonaka, I. (1986). The new product development game. Harvard Business Review, 64 (1), Versionone. (2011). State of the agile. Atlanta: Versionone. 12