Uitdagingen bij scrum implementatie. Een overzicht van reeds uitgevoerde casestudies

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

Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen

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

Systemen zijn goed te specificeren,

Systemen kunnen opgebouwd worden

aannames

voorspelbaar en de bouw er van moet

door kleine teams vanuit principes van

zorgvuldig gepland worden

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

Mechanisch (bureaucratisch met veel

Organisch (flexibel en participatief)

structuur

formalisatie)

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


& 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


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


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


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

(Hosbond & Nielsen, 2008)

telefoonmaatschappij 5

Scrum implementatie bij Healthwise

(Long & Starr, 2008)

6

Scrum implementatie bij anoniem ICT bedrijf, onderzoek

(Moe, Dingsøyr, & Dyba, 2010)

vanuit teamoriëntatie perspectief 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

Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen Tabel 2. Overzicht kenmerken situaties tien scrum implementaties.

1

Training

Management bemoeienis

Externe bronnen

Omvang* Start situatie

Tijdsdruk

Nee

Veel ruimte voor teams

Nee

groot

Nee, experiment van een half jaar

Ervaring met flexibele patterns, veel van scrum was niet nieuw

2

3

Nee, ook niet voor

Halverwege implementatie

Consultant voor de

nieuwe medewerkers

een extra managementlaag

Ja

klein

Chaotische situatie, net een mislukte

Niet op het werken volgens scrum:

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

Weinig visie, wel veel eisen

Cursus voor

groot

Al wat experimenten met scrum gedaan

Nee, eerst een experiment uitgevoerd

middel

Geen eerder ervaring met flexibel werken Ja, er moesten snel resultaten geboekt

scrummaster 4

Gecertificeerde

Sterk gecontroleerd

Naast cursussen niet

programma’s

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

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

Ja

Veel vrijheid voor teams

Al een tussenvorm van planmatig en

Nee, eerst pilot Daarna langzaam

flexibel werken geïmplementeerd.

uitgerold

De helft van het team had scrum en pair

Nee, langzaam kennisgemaakt in

programming ervaring

project van 9 maanden

7

Nieuwe medewerkers

middel

groot

met scrum ervaring 8

Nee

Weinig projectmanager was

klein

ook teamlid 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 bottom-

Nee

groot

Een aantal medewerkers hadden ervaring

Nee, eerst uitproberen, bottom-up

met scrum

verspreiding over organisatie

up uitgedacht * klein: 5-30 medewerkers, middel: 30-250 medewerkers en groot: > 250 medewerkers.

6

Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen Tabel 3. Overzicht van uitdagingen en resultaten tien scrum implementaties.

1

2

Uitdagingen tijdens implementatie

Resultaten eind implementatie

Scrummaster heeft moeite om 15 minuten bijeenkomsten productief te houden, backlog is te ingewikkeld,

Verbetering van zichtbaarheid proces, communicatie,

backlog verandert tijdens sprint, op maat maken methode kost veel tijd.

oplevertijd, klantrelatie, meer vertrouwen en kennisoverdracht

Samenwerken verschillende scrums lastig, geen product eigenaar, gebrek begrip verificatie en validatie,

Backlog werkt niet, beslissingen worden vergeten, slechte tools,

beslissingen worden vergeten, verkeerde tools, medewerkers snappen scrum niet, lang uitgeweid over theorie,

sterk gefragmenteerd team, slechte communicatie.

scrummasters begrijpen cultuur niet, in sprintretrospectives niks gedeeld, organisatiestructuur sluit niet aan. 3

4

5

Te veel aandacht voor het proces, te weinig aandacht voor proces, geen duidelijke verwachtingen vanuit het

Er moesten veel uitdagingen door het team overwonnen

management, te veel bug fixing, het inpassen van onderzoek werkzaamheden in sprint, te gespecialiseerd team,

worden, uiteindelijk bleek scrum effectiever dan planmatig

individualistische leden, te volle sprint, moeilijk voortgang bij te houden, te veel management bemoeienis.

werken.

Medewerkers niet voldoende competenties, onrealistische verwachtingen vanuit het management, onduidelijke

Medewerkers niet creatief en proactief, geen innovatie,

verschuivende machtsstructuren, geen geschikte ruimtes, te veel documentatie geëist vanuit organisatie.

onduidelijke machtsstructuren, documentatie eisen niet gehaald.

Scrummasters ook product eigenaar, scrummasters eisen te veel, veel discussie over het proces, medewerkers

Veel ging mis, maar na vier jaar is tevredenheid en

vertrekken omdat ze niet zo transparant willen werken, communicatie tussen teams wordt slechter

communicatie, medewerkers verbeterd en overuren teruggedrongen. Communicatie teams onderling afgenomen.

6

7

Moeilijk modules van andere organisatie te integreren, moeilijk om backlog rond te krijgen, iedereen zwijgt

Pilot project liep uit de hand, moeite met teamoriëntatie, slechte

tijdens meetings, medewerkers volgen eigen plan, iedereen werkt alleen, team ontdekt fouten niet

onderlinge communicatie. Stijging klanttevredenheid.

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

Planning en het bijhouden van voortgang wordt gezamenlijk

andere partijen, beoogde levertijd niet gehaald, scrum sluit niet aan bij organisatiestructuur, andere afdelingen

proces, verbetering communicatie, betere levertijden.

werken anders, bijdragen aan algemene roadmap lastig, coördinatie teams erg lastig, te veel tijdens één sprint.

7


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

Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen § 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


Bibliografie Boehm, B. (2002). Get ready for agile methods, with care. Computer (35), 64-69. Boehm, B., & Turner, R. (2005). Management challenges to implementing Agile processes in traditional development organizations. IEEE Software , 30-39. 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. 240-248). IEEE. Fitzgerald, B., Hertnett, G., & Conboy, K. (2006). Customising agile methods to software practices at Intel Shannon. European Journal of Information Systems , 15 (2), 200-213. Fitzgerald, B., Russo, N. L., & O'Kane, T. (2003). Software development method tailering at motorola. Communications of the ACM , 4 (64), 64-70. 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 , 21-31. 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, 2009. ICGSE 2009. Fourth IEEE International Conference (pp. 175-184). IEEE. Livermore, J. (2008). Factors that significantly impact the implementaion of an agile software development methodology. Journal of Software , 3 (4), 31-36. Long, K., & Starr, D. (2008). Agile 2008 Conference. Agile supports improved culture and quality for healthwise (pp. 283-288). IEEE. 10


Mann, C., & Maurer, F. (2005). A case study on the impact of Scrum on overtime and Customer satisfaction. In Agile Conference, 2005, Proceedings (pp. 70-79). IEEE. Marchenko, A., & Abrahamson, P. (2008). Agile 2008 Conference. Scrum in a multiproject environment: an ethnographically-inspired case studie on the adoption challenges (pp. 15-26). IEEE. Misra, S. C. (2012). Agile Software Development Practices: Evolution, Principles, and Criticisms. International Journal of Quality & Reliability Management, 29 (9), 972 - 980. 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), 18691890. 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), 480-491. Nerur, S., Mahapatra, R., & Mangalara, G. (2005, mei). Challenges of Migrating to Agile Methodlogies. Communications of the ACM, 73-78. Rising, L., & Janoff, N. S. (2000). The Scrum software development process for small teams. Software, IEEE, 17 (4), 26-32. Salo, O., & Abrahamsen, P. (2008). Agile methods in European Embedded Development Organizations: a survey study of Extreme programming and srum. IET Software, 2, 58-64. 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. 191-195). IEEE. Scotland, K., & Boutin, A. (2008). Integrating scrum with the process framework at yahoo! Europe. Agile 2008 Conference (pp. 191-195). IEEE.

11


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. 1415-1420). IEEE. Steltzer, D., & Mellis, W. (1998). Succes factors of organizational change in software process improvement. Software Process: Improvements an Practice, 4 (4), 227-250. Sutherland, J., Viktorov, A., Blount, J., & Punktikov, N. (2007). Distributed scrum: agile project management with outsourced development teams. System sciences , 247-274. Swart, N. (2001). Lessen uit de veranderkunde toegepast in ICT projecten. Management en Informatie (6), 45-51. Takeuchi, H., & Nonaka, I. (1986). The new product development game. Harvard Business Review , 64 (1), 137-146. Versionone. (2011). State of the agile. Atlanta: Versionone.

12

Uitdagingen bij scrum implementatie. Een overzicht van reeds uitgevoerde casestudies

Recommend Documents