Voorwoord Sinds een aantal jaar coach ik teams bij bedrijven en help ik de teams met het verbeteren van hun productiviteit en de kwaliteit van de software. De coaching bestaat vaak uit training van programmeertechnieken, maar vaak ook uit het helpen bij het beheren van projecten. Als een team niet goed presteert, blijkt dat in veruit de meeste gevallen niet aan de kundigheid van het team te liggen, maar aan de manier waarop projecten worden beheerd en hoe de taken binnen het project worden verdeeld. Als een team nog niet bekend is met moderne Agile-projectmethoden, leg ik de principes uit. Meestal zijn alle betrokkenen snel enthousiast als we Scrum introduceren binnen de organisatie. Scrum heeft eenvoudige regels waarvan iedereen snel begrijpt dat ze de productiviteit en de kwaliteit kunnen verbeteren. Iedere keer dat ik een bedrijf help met het implementeren van Scrum, worden mij dezelfde vragen gesteld. Over het algemeen gaan deze vragen niet direct over Scrum zelf, maar vooral over het invullen van details die niet specifiek door Scrum worden behandeld. ‘Waarom schatten we user story’s in storypoints en niet in uren?’, ‘Moeten bugs nu wel of niet op de productbacklog worden opgenomen?’, ‘Wat doe ik met ad-hoctaken die tussendoor moeten worden uitgevoerd?’, ‘Start de nieuwe Sprint direct na het einde van de vorige Sprint of is er nog tijd om opruimwerkzaamheden te doen?’, ‘Hoe kunnen we de meeste informatie uit een evaluatie halen?’, ‘Wat is de beste contractvorm met mijn klanten als we Scrum gebruiken?’ enzovoort. Het blijkt dat deze vragen in bijna geen enkel boek over Scrum duidelijk worden beantwoord. Daarmee was het idee voor dit boek geboren. Het duurde nog een paar jaar voordat ik de tijd vond om het boek ook daadwerkelijk te schrijven, maar na de inmiddels zo bekende bloed, zweet en tranen ligt het er dan eindelijk. Ik hoop dat uw vragen in dit boek zo veel mogelijk worden beantwoord en dat u net zo enthousiast over Scrum wordt als ik dat in de afgelopen jaren ben geworden.
vii
SUCCES MET SCRUM!
Tweede druk Drie jaar na het verschijnen van dit boek heb ik veel nieuwe ervaringen opgedaan op het gebied van Scrum-coaching en -training. Vooral de laatste twee jaar merk ik een enorme interesse in Scrum vanuit bedrijfstakken die niet softwaregerelateerd zijn. Het is verbazend (of misschien juist niet) hoe goed Scrum ook werkt in deze branches. In deze tweede druk heb ik geprobeerd het boek daarom minder technisch te maken en minder te focussen op specifieke softwareprojecten. Hoewel sommige voorbeelden nog steeds uit de softwarehoek komen, omdat daar nu eenmaal mijn expertise ligt, probeer ik dit boek toegankelijker te maken voor niet-technische lezers.
viii
Inhoud
1: Inleiding Voor wie is dit boek? Hoe kunt u dit boek gebruiken? Taalgebruik Hij of zij
1 3 5 5 5
2: Wat is Scrum? Korte geschiedenis Agile-principes Populaire Agile-methodieken Vergelijking met watervalmethoden Wat is Scrum niet?
7 7 9 16 20 24
3: Scrum in theorie Het Scrum-proces Het project starten Productvisie (product vision statement) De productbacklog Het opleverplan (release planning) De mensen, rollen en verantwoordelijkheden De Sprint
27 27 29 29 31 43 45 52
4: Starten met de Scrum-methodiek Introduceren van Scrum binnen het bedrijf Het project kiezen Een Scrum-team samenstellen Huisvesting van het Scrum-team
63 64 65 66 81
ix
SUCCES MET SCRUM!
5: Het Scrum-project starten De productvisie opstellen De Definition of Done opstellen De productbacklog opstellen Opleveringen plannen
x
85 85 88 92 112
6: Sprints uitvoeren De Sprint-planning Het Sprint-doel Story readiness Teamsnelheid (velocity) De Sprint-backlog De Sprint uitvoeren De Sprint-reviewvergadering De Sprint-evaluatie (retrospective) Verschillende methoden voor evaluatie Een Sprint afbreken Een Sprint-nul uitvoeren (Sprint zero) Een oplever-Sprint uitvoeren (hardening Sprint)
121 121 122 122 123 124 128 138 140 142 149 150 151
7: Projectdocumentatie bijhouden Hoeveel documentatie? De productvisie De productbacklog De Sprint-backlog Technische documentatie Functionele documentatie Blokkades en procesverbeteringen Beslissingsdocumenten Andere documentatie
157 157 158 158 162 163 164 165 165 166
8: Opschalen naar meerdere Scrum-teams Communicatieproblemen Teams op meerdere locaties Organisatiestructuur Scaled Agile Framework (SAFe)
169 170 172 173 174
Inhoud
Disciplined Agile Delivery (DAD) Large Scale Scrum (LeSS) Welk framework kiezen? Opschaling algemeen
182 191 202 203
9: Hoe ‘verkoop’ ik Scrum binnen mijn bedrijf? Inleiding Argumenten tegen Scrum Verkoopargumenten Het Scrum-introductieproject Aandachtspunten voor de introductie
213 213 214 222 227 231
10: Hoe ‘verkoop’ ik Scrum aan mijn klanten? Agile-principes uitleggen Verkoopargumenten Contracten en Agile-methoden Contractvormen Conclusie
235 236 238 240 241 259
11: Wat te doen als Scrum niet werkt? Scrum lijkt eenvoudig, maar is lastig Scrum is slechts gereedschap Scrum is niet altijd het juiste gereedschap Situaties die de implementatie van Scrum hinderen Scrumbut Alleen onderdelen van Scrum gebruiken Als zelforganisatie zijn werk niet kan doen Scrum-teams met tegenstrijdige belangen
263 264 265 266 267 275 277 277 278
Literatuur
281
Index
288
1
Inleiding Misschien bent u geïnteresseerd in Scrum omdat u in een bedrijf werkt waar Scrum wordt gebruikt en wilt u meer te weten komen over de methodiek? Misschien werkt u in een bedrijf dat Scrum nog niet gebruikt, maar het wil gaan gebruiken? Misschien wilt u software laten ontwikkelen door een softwarebedrijf dat zegt Scrum te gebruiken en wilt u weten wat dat inhoudt? In ieder geval hebt u interesse in Scrum, anders zou u dit niet lezen. In dit boek wil ik u meenemen in de wereld van projectbeheer door middel van de Scrum-methodiek. Scrum is oorspronkelijk ontwikkeld in de wereld van de software ontwikkeling en is daarin een van de meest succesvolle methodieken van de afgelopen decennia. Tegenwoordig wordt Scrum steeds vaker succesvol gebruikt buiten de IT-wereld. Het blijkt dat veel projecten in andere branches zich prima lenen voor Scrum. De meeste mensen die iets met softwareontwikkeling te maken hebben gehad, hebben wel eens gehoord van de zogenoemde ‘projectmanagementdriehoek’ of ‘IJzeren driehoek’ (Iron Triangle). Deze driehoek geeft de relatie weer tussen de verschillende elementen van het projectbeheer: te ontwikkelen product, beschikbare middelen (zoals budget en mensen), de (doorloop)tijd van het project en de opgeleverde kwaliteit. De punten van de driehoek stellen de randvoorwaarden van het project voor. Deze randvoorwaarden zijn vaak tegenstrijdig. Als de beschikbare tijd voor het afronden van het project korter wordt gemaakt, heeft dat meestal tot gevolg dat de kosten (budget) zullen stijgen of dat de opgeleverde functionaliteit minder zal zijn. Als het beschikbare budget wordt verkleind, wordt daarmee automatisch de opgeleverde functionaliteit minder, maar kan het misschien wel eerder worden opgeleverd. De oppervlakte van de driehoek geeft de kwaliteit van het opgeleverde product weer. Deze driehoek gaat in principe op voor veel typen projecten.
De IJzeren driehoek.
SUCCES MET SCRUM!
Het is van belang te beseffen dat het vastleggen van twee van de drie punten in de driehoek automatisch ook het derde punt van de driehoek vastlegt. Veelal bepaalt de klant (de opdrachtgever van het project) al twee van de drie punten. De klant wil dat het project tegen een vaste prijs wordt uitgevoerd, maar het moet ook over drie maanden klaar zijn. Het kost vaak veel moeite om uit te leggen dat daarmee de hoeveelheid functionaliteit die kan worden geïmplementeerd ook vast ligt. Als we praten over projectbeheer en projectbeheersing hebben we in feite altijd met deze vier factoren te maken. Een klant wil het liefst vaak vooraf bepalen wat hij krijgt, wanneer en tegen welke prijs. We zullen zien dat dit in de praktijk bijna niet mogelijk is. De Scrum-methodiek probeert met deze tegenstrijdigheden zo goed mogelijk om te gaan. Scrum is een Agile-methodiek. Agile (lenig) is een groep van projectmethodieken die alle dezelfde uitgangspunten hanteren en waarvan de Scrummethodiek een van de oudste en bekendste is. Iedere Agile-methodiek, bijvoorbeeld eXtreme Programming (XP), Crystal Clear, Lean, Kanban enzovoort, focust op andere aspecten van het projectbeheer. Sommige (zoals eXtreme Programming) richten zich voornamelijk op het technische aspect van softwareontwikkeling, terwijl andere (zoals Scrum) proberen het projectbeheer in goede banen te leiden. Soms zijn verschillende methodieken goed te combineren omdat ze elkaar aanvullen. Doordat er zo veel verschillende methodieken zijn, is het vaak lastig voor iemand de voor- en nadelen van iedere techniek te overzien en te kiezen voor één bepaalde methodiek. In mijn visie hebben alle methodieken bestaansrecht en het hangt vaak af van verschillende factoren, waaronder persoonlijke voorkeur, welke voor een bepaalde organisatie de beste methodiek is. In mijn ervaring is Scrum een methodiek die alle betrokkenen aanspreekt, omdat de basisregels zeer eenvoudig zijn. U hoeft niet technisch onderlegd te zijn om Scrum te begrijpen en in te zien waarom het tot betere resultaten leidt dan andere methoden. Bij het introduceren van een nieuwe methodiek binnen een bedrijf zijn veel partijen betrokken. Voor Scrum geldt dat in hoge mate. Scrum heeft niet alleen invloed op de technische afdelingen, maar ook op andere afdelingen binnen de organisatie en zelfs daarbuiten. Scrum draait om communicatie en communicatie is niet iets wat alleen binnen de technische afdelingen plaatsvindt. Juist de communicatie tussen verschillende afdelingen onder2
1 Inleiding
ling, communicatie tussen de opdrachtgever en het productieteam, communicatie tussen de projectmedewerkers en de eindgebruikers enzovoort, is van belang voor het slagen van het project. Om Scrum succesvol te laten zijn, is het van belang dat alle partijen begrijpen wat Scrum inhoudt.
Voor wie is dit boek? Tijdens de coachingstrajecten die ik doe, merk ik vaak dat bedrijven al een beetje zijn voorbereid op Agile. Dit gebeurt meestal door een van de vele artikelen op internet of een boek over Scrum te lezen. Omdat Scrum zeer weinig regels kent die ook nog eens eenvoudig zijn, proberen de bedrijven direct de methodiek uit. De eerste stappen gaan dan vaak heel soepel, maar na een tijdje ontstaan de praktijkvragen. Helaas gaan de meeste boeken over Scrum als methodiek alleen. Daarin wordt heel netjes verteld hoe je Scrum moet doen. De betere boeken behandelen veel theorie en praktijkvoorbeelden over wat er goed of fout ging tijdens het introduceren van Scrum. Bij alle Agile-methodieken zit het venijn in de details. De grote lijnen zijn erg eenvoudig, maar vaak worden de details onderschat. Ik zie bijvoorbeeld bedrijven die de dagelijkse Scrum-vergadering (daily standup) met een korrel zout nemen en die de vergadering doen wanneer het toevallig uitkomt. Dit lijkt op het eerste gezicht niet zo’n probleem. De dagelijkse Scrum-vergadering is immers bedoeld voor het team om aan elkaar te vertellen wat de voortgang is (zoals we uitgebreid zullen zien in hoofdstuk 3 en 6). Deze vergadering heeft ook nog een aantal subdoelen die minder belangrijk lijken, maar in de praktijk net zo belangrijk zijn. De vergadering is openbaar en managers (van alle lagen van de organisatie) worden van harte uitgenodigd de vergadering bij te wonen. Het bijwonen van de vergadering door een manager geeft signalen af van betrokkenheid en interesse. Dit is belangrijk voor het zelfvertrouwen van het Scrum-team. Door de dagelijkse Scrum-vergadering niet iedere dag of steeds op een ander tijdstip te houden, kunnen managers deze niet eenvoudig in hun drukke schema inpassen, waardoor ze de kans missen om direct betrokken te raken bij de projecten in het bedrijf. Dit voorbeeld geeft aan dat juist de details erg belangrijk zijn voor het succesvol introduceren van Scrum in een bedrijf. In dit boek richt ik me vooral op de praktijkvragen die mij regelmatig worden gesteld en waarop 3
SUCCES MET SCRUM!
het antwoord lastig is te vinden op internet. Natuurlijk behandel ik de theorie van Scrum omdat zonder theorie geen praktijk mogelijk is. Scrum laat een groot aantal details van de invulling aan de gebruikers van Scrum zelf over. Daarom maken we in de praktijk regelmatig gebruik van technieken die zijn ‘geleend’ uit andere methodieken, maar die prima passen in de structuur die Scrum ons biedt. De onderdelen die ik in dit boek behandel zijn soms ‘verplichte’ Scrum-onderdelen, maar vaak ook handvatten om met bepaalde situaties om te gaan die niet door Scrum tot in detail worden ingevuld. Dit boek is bedoeld voor iedereen die wil starten met Scrum of al is gestart en tegen dagelijkse praktijkproblemen aanloopt. I
I
I
I
I
I
Softwareontwikkelaars: mensen met een technische achtergrond die willen overstappen op de Scrum-methodiek of die de methodiek al gebruiken en met meerdere Scrum-teams willen gaan werken. Teammedewerkers: personen in een andere branche dan softwareontwikkeling die hun projecten met behulp van Scrum willen beheren. Managers: personen in een leidinggevende positie die willen leren hoe ze hun team het best van dienst kunnen zijn, maar ook hoe ze de Scrummethodiek het best kunnen ‘verkopen’ binnen hun organisatie. Verkopers en accountmanagers: personen die binnen de organisatie verantwoordelijk zijn voor de verkoop van softwareprojecten en die willen weten hoe je potentiële klanten ervan kunt overtuigen dat het gebruik van de Scrum-methodiek uiteindelijk ook beter voor de klant is. Directie: beslissingsnemers binnen een organisatie die willen weten wat Scrum inhoudt en hoe ze hun organisatie kunnen omvormen naar een Agile-organisatie. Opdrachtgevers: personen die (maatwerk)software afnemen bij een bedrijf dat de Scrum-methodiek gebruikt en die willen weten wat de voordelen daarvan zijn vanuit het standpunt van de opdrachtgever.
De eerste hoofdstukken behandelen de Scrum-methodiek zelf in theorie en praktijk. Nu Scrum volwassen is geworden, maar nooit ophoudt te veranderen, willen ook grotere organisaties (met meer dan duizend werknemers) Scrum gaan gebruiken. Het boek zou niet compleet zijn als het opschalen naar meerdere Scrum-teams niet zou worden behandeld. Maar net zo belangrijk is het ‘verkopen’ van de Scrum-methodiek aan uw klanten of binnen uw eigen bedrijf. Als niet iedereen het nut van Scrum inziet, is het overstappen naar Scrum bij voorbaat gedoemd te mislukken. 4
1 Inleiding
Hoe kunt u dit boek gebruiken? Het gebruik van dit boek hangt af van uw huidige ervaring en kennis van Scrum. Hebt u in de praktijk nog niet veel ervaring met de Scrum-methodiek, dan raad ik u aan het boek van voor naar achter te lezen. De hoofdstukken volgen elkaar logisch op en latere hoofdstukken bouwen verder op eerder opgedane kennis. Hebt u al enige ervaring met Scrum, dan kunt u de volgorde van lezen zelf bepalen en kunt u het boek meer als naslagwerk gebruiken. Vooral hoofdstuk 8, Opschalen naar meerdere Scrum-teams, hoofdstuk 9, Hoe verkoop ik Scrum binnen mijn bedrijf?, hoofdstuk 10, Hoe verkoop ik Scrum aan mijn klanten? en hoofdstuk 11, Wat te doen als Scrum niet werkt? zijn hoofdstukken die uitstekend afzonderlijk gelezen kunnen worden.
Taalgebruik Ik heb ervoor gekozen dit boek te schrijven in het Nederlands. Hoewel veel mensen tegenwoordig de Engelse taal goed machtig zijn, lezen ze toch liever in hun eigen taal. Het probleem dat optreedt is de vertaling van veelgebruikte Engelstalige woorden. Een woord vertalen dat iedereen dagelijks in het Engels gebruikt levert meestal meer onduidelijkheid dan duidelijkheid op. Daarnaast is het overgrote deel van de informatie op internet te vinden in het Engels. Ik heb geprobeerd die woorden, waar een eenduidige Nederlandse vertaling voor is, te vertalen en daarbij tussen haakjes de originele Engelse term op te nemen. Hierdoor weet u welke term er wordt bedoeld mocht u de Engelse term al kennen en kunt u eenvoudiger additionele informatie op internet opzoeken.
Hij of zij In dit boek gebruik ik regelmatig de derde persoon om iemand in een team aan te duiden. Omdat het nogal omslachtig is overal hij of zij te gebruiken, heb ik het meestal over hij. In de ICT-wereld waarin ik veel bedrijven coach zijn helaas nog steeds niet veel vrouwen werkzaam, maar de vrouwen die ik heb meegemaakt zijn minstens net zo goed in hun vak als de mannen en overal waar hij wordt gebruikt, kan ook zij worden gelezen.
5