Uitdagingen bij scrum implementatie. Een overzicht …€¦ · Uitdagingen, resultaten en relevante...
Transcript of Uitdagingen bij scrum implementatie. Een overzicht …€¦ · Uitdagingen, resultaten en relevante...
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
1
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
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
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
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
2
& 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
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
3
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
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
4
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
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
5
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.
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
6
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
nieuwe medewerkers
Halverwege implementatie
een extra managementlaag
met veel bemoeienis
Consultant voor de
eerste helft
implementatie + boeken
klein Chaotische situatie, net een mislukte
poging achter de rug om een planmatige
methode te implementeren
Niet op het werken volgens scrum:
twee jaar uitgeprobeerd. Wel op
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 +
scrummaster training
Weinig, maar scrummaster
had wel veel invloed
Naast cursussen niet middel Geen flexibele ontwikkel ervaring en
geen ervaring met zelfmanagement
Nee, pilot project, maar wel veel druk
op uitkomst project
7 Ja Veel vrijheid voor teams Nieuwe medewerkers
met scrum ervaring
groot Al een tussenvorm van planmatig en
flexibel werken geïmplementeerd.
Nee, eerst pilot Daarna langzaam
uitgerold
8 Nee Weinig projectmanager was
ook teamlid
klein De helft van het team had scrum en pair
programming ervaring
Nee, langzaam kennisgemaakt in
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 bottom-
up uitgedacht
Nee groot Een aantal medewerkers hadden ervaring
met scrum
Nee, eerst uitproberen, bottom-up
verspreiding over organisatie
* klein: 5-30 medewerkers, middel: 30-250 medewerkers en groot: > 250 medewerkers.
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
7
Tabel 3. Overzicht van uitdagingen en resultaten tien scrum implementaties.
Uitdagingen tijdens implementatie Resultaten eind 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.
Verbetering van zichtbaarheid proces, communicatie,
oplevertijd, klantrelatie, meer vertrouwen en kennisoverdracht
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.
Backlog werkt niet, beslissingen worden vergeten, slechte tools,
sterk gefragmenteerd team, slechte communicatie.
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.
Er moesten veel uitdagingen door het team overwonnen
worden, uiteindelijk bleek scrum effectiever dan planmatig
werken.
4 Medewerkers niet voldoende competenties, onrealistische verwachtingen vanuit het management, onduidelijke
verschuivende machtsstructuren, geen geschikte ruimtes, te veel documentatie geëist vanuit organisatie.
Medewerkers niet creatief en proactief, geen innovatie,
onduidelijke machtsstructuren, documentatie eisen niet gehaald.
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
Veel ging mis, maar na vier jaar is tevredenheid en
communicatie, medewerkers verbeterd en overuren
teruggedrongen. Communicatie teams onderling afgenomen.
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
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.
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
8
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
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
9
§ 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.
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
10
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.
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
11
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), 1869-
1890.
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.
Uitdagingen, resultaten en relevante factoren in scrum implementatie casestudies – Herm van Veen
12
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.