108 5.9 Scrum Deel I van de beschrijving van Scrum is geschreven door Jeroen Venneman en gereviseerd en geautoriseerd door Eelco Rustenburg, co-auteur van het boek De Kracht van Scrum, en Theo Gerrits, expert voor Computable en ervaren consultant op het gebied van Agile Adopties op basis van Scrum. DEEL I 5.9.1 Definitie project Scrum geeft geen definitie van een project. Het is een iteratief en incrementeel raamwerk dat is gericht op continue verbetering en het kort-cyclisch opleveren van kwaliteitsproducten met maximale waarde voor de klant. Er wordt een projectaanpak gebruikt waarbij het product stukje bij beetje in overzichtelijke incrementen wordt opgeleverd. De incrementen zijn niet in een keer compleet en perfect. Ze worden in iteraties verfijnd of verbeterd. 5.9.2 Kern van de methode Continue verbetering, uitgaande van mogelijkheden in plaats van onmogelijkheden. Gericht op softwareontwikkeling in de ICT. 5.9.3 Historie Takeuchi en Nonaka 11 kunnen worden gezien als de grondleggers van Scrum. Zij beschreven een productontwikkelraamwerk dat vergeleken wordt met de manier waarop een rugbyteam als groep de achterlijn van de tegenstander probeert te bereiken. Samenwerking, aanpassingsvermogen, snelheid en zelfsturing zijn kenmerken van multidisciplinaire teams die overeenkomen met zo n rugbyteam. Scrum is gebaseerd op best practices vanuit de Japanse industrie, waaronder ook de Lean Management-principes. Vervolgens hebben Jim Coplien, Mike Beedle, Ken Schwaber en Jeff Sutherland Scrum verder vormgegeven. In 1995 is Scrum door Schwaber en Sutherland geformaliseerd. 5.9.4 Scope Scrum is één van de lichtste Agile-methoden en daarmee minder voorschrijvend dan bijvoorbeeld Atern. Scrum is ook meer een raamwerk dan een methode en nodigt uit tot verdere invulling. In eerste instantie is het bij de implementatie van Scrum niet nodig om alle bestaande functies en artefacten te vervangen. Hiermee kan het raamwerk juist verder worden ingevuld. Door het raamwerk toe te passen wordt wel een herstructurering in gang gezet. De nieuwe structuur die dan ontstaat vormt de basis voor continue verbetering. 11 Takeuchi, H., Nonaka, I., The New New Product Development Game. In: Harvard Business Review, 1986.
5 Projectmanagementmethoden 109 De traditionele muren tussen de diverse disciplines worden afgebroken door de vorming van multidisciplinaire teams. Ontwikkelaars, testers, analisten, architecten en database administrators zijn voorbeelden van disciplines die in zo n multidisciplinair team te vinden zijn. Door de samenvoeging van alle disciplines in een team verminderen de documentoverdrachten, wachttijden en communicatieproblemen. 5.9.5 Uitgangspunten Scrum onderkent de volgende kernwaarden: Commitment: het team moet zich kunnen en willen committeren tot realistische en uitdagende doelen. Er is vrijheid en zelfsturing nodig om binnen kaders te doen wat nodig is om deze doelen te bereiken. Elementen in Scrum die hieraan bijdragen: - in de sprintplanningsmeeting wordt door het team zelf een inschatting gegeven van de zwaarte van het werk en wordt samen bepaald wat realistisch en uitdagend is om in een sprint op te pakken; - in de daily scrum wordt samen het doel voor de dag bepaald en wordt de persoonlijke bijdrage hieraan uitgesproken tegenover het team. Focus: gericht blijven op het gemeenschappelijke doel en optimaal samenwerken om dit te bereiken. Elementen in Scrum die hieraan bijdragen: - werken in sprints met een sprintdoel en met een tijdsduur van maximaal een maand; - daily scrums; - formulering van de werklijst of backlog items in het doelgerichte user story format: As a <role> I want < a feature> so that < my goal is achieved>. Openheid: openheid stimuleert communicatie, de mogelijkheid om bij te kunnen sturen, de mogelijkheid om elkaar te helpen en het verkrijgen van vertrouwen. Openheid is nodig om Scrum te laten werken. Elementen in Scrum die hieraan bijdragen: - de product backlog (geprioriteerde werklijst van het team) is zichtbaar voor iedereen; - de daily scrum maakt transparant waaraan het team werkt; - de sprint review meeting waarin het resultaat van de sprint aan de belanghebbenden wordt getoond; - dagelijkse trendlijnen (burn-down) van bijvoorbeeld de productiviteit (velocity) van het team, zowel binnen een sprint als voor de hele product backlog. Respect: respect voor elkaars sterktes en zwaktes is nodig voor werkelijke teamgeest. Elkaar stimuleren en helpen om de teamdoelstellingen te bereiken in plaats van elkaar de schuld geven als het tegen zit. Durf: de durf hebben om schattingen en commitment te geven, beslissingen te nemen, transparant te zijn en open te communiceren. Het vereist durf om je kwetsbaar op te stellen en op een creatieve manier te werken met zelfsturing, vrijheid en teamverantwoordelijkheid. Vertrouwen hebben en krijgen is hierbij noodzakelijk, zowel voor het team als voor de omgeving.
110 5.9.6 Beschrijving Raamwerk Het Scrumraamwerk bestaat uit een verzameling Scrumteams met hun bijbehorende rollen, timeboxes, artefacten en regels 12 : Scrumteams zijn zelforganiserend, multidisciplinair en werken iteratief en incrementeel. Scrum beschrijft de volgende drie rollen: de product owner, de Scrummaster en het team. Onderdelen van Scrum die binnen timeboxes uitgevoerd worden zijn: de releaseplanning, sprintplanning, sprint, daily scrum, sprint review en retrospective. De vier primaire artefacten binnen Scrum zijn: de product backlog, sprint backlog, release burn-down chart en de sprint burn-down chart. De regels zorgen voor de verbinding tussen de rollen, timeboxes en artefacten. Detailbeschrijving In Sprint READY Sprint backlog Daily Preparing New Product backlog xxxxxx xxxx xxx Sprint Vaste sprint lengte 1-4 weken Done Werkende software met maximale klantwaarde Figuur 5.9.1 Scrumaanpak De product backlog, helemaal links in figuur 5.9.1, is de werklijst. Deze lijst wordt gevuld met de eisen en wensen van alle belanghebbenden van het te realiseren product. De product owner verzorgt de prioritering van de backlog items. Deze prioritering vindt plaats op basis van een businesscase per item. Hierin worden risico s, afhankelijkheden en zwaarte meegenomen. Voor deze zwaarte is een realistische inschatting nodig die alleen kan worden gegeven door degenen die hiermee aan de slag moeten, het team. Samen met het multidisciplinaire team worden de items op de lijst klaargemaakt voor een sprint. De items moeten namelijk voldoende uitgewerkt zijn zodat ze binnen een sprint kunnen worden omgezet in werkende software. De eisen waaraan de items op dat moment moeten voldoen, worden vastgelegd in de Definition of Ready. Meer informatie over Definition of Ready is te vinden in een blog van Serge Beaumont 13. 12 Schwaber, K. & J. Sutherland (2010). De Scrum Guide, scrum.org. (http://www.scrum.org/scrumguides/). 13 http://blog.xebia.com/2009/06/19/the-definition-of-ready.
5 Projectmanagementmethoden 111 Een van de middelen om tot ready backlog items/user stories te komen, inclusief een inschatting van de benodigde inspanning, is Planning Poker 14. Met Planning Poker geven de teamleden onafhankelijk van elkaar een inschatting. Ieder heeft een verzameling kaarten met getallen die gebaseerd zijn op de Fibonacci-reeks. Na een toelichting van de user story door de product owner kunnen er vragen worden gesteld om meer duidelijkheid te krijgen. Er is een zekere duidelijkheid nodig om een relatieve schatting te kunnen geven. Relatief ten opzichte van een duidelijke (simpele) user story die vooraf met elkaar is besproken en een gezamenlijk vastgesteld, willekeurig gewicht heeft gekregen. Dit gewicht dient als referentie voor de relatieve inschatting en wordt uitgedrukt in punten. Deze punten worden in de praktijk vaak storypunten of complexiteitspunten genoemd. Het uitdrukken in punten helpt mee om te voorkomen dat er in dagen of uren geschat gaat worden. Het tijdsaspect komt namelijk pas naar voren bij de realisatie van de user stories. De schatting is relatief omdat hiermee snel inzicht ontstaat in de verhoudingen tussen de brokken werk op de product backlog. Er wordt geen tijd gestoken in de verfijning van de schattingen om vooraf meer zekerheid te krijgen. In plaats daarvan wordt eerder begonnen met de realisatie van user stories en worden planningen nauwkeuriger op basis van de praktijkervaring in de uitvoering van de sprints. Als tijdens de Planning Poker iedereen voldoende duidelijkheid heeft om een schatting te kunnen geven, worden de kaarten met de getallen naar beneden op tafel gelegd en vervolgens tegelijkertijd omgedraaid (net zoals de call bij poker). Er volgt een discussie over de verschillen en er komen aanvullende vragen. Vervolgens worden de kaarten opnieuw gebruikt totdat er consensus over de schatting is. De Scrummaster faciliteert dit proces. Hij is de bewaker van het Scrumproces, beschermt het team, coacht het team om zelfsturend te worden en creëert transparantie naar de omgeving. Bij de aanvang van een sprint wordt in de sprintplanningsmeeting door het team bepaald welke items er kunnen worden opgepakt uit de lijst van geprioriteerde en ingeschatte ready user stories. Deze verzameling items wordt verder uitgewerkt in taken en vormt de sprint backlog. Het team geeft haar commitment om dit te gaan realiseren in de huidige sprint. De hoeveelheid storypunten die in een sprint verwerkt kunnen worden, wordt de velocity genoemd, de snelheid/productiviteit van het team. Een sprint is een vaste tijdsperiode waarin het multidisciplinaire team werkende software gaat opleveren. Gedurende elke sprint wordt het eindproduct verder uitgebreid en/of verfijnd. Sprints hebben een vaste lengte (tussen de één en vier weken) waardoor er een regelmatige heartbeat ontstaat waarin de opleveringen plaatsvinden. De regelmatige opleveringen zorgen voor een ritme voor het team en verbeteren de voorspelbaarheid voor de omgeving. 14 Planning Poker wordt niet beschreven in het brondocument. Zie daarvoor www.planningpoker.com.
112 Elke sprint heeft een doel. Deze wordt duidelijk gemaakt aan het team en bevordert de focus. Het doel kan op verschillende manieren bereikt worden. Het is de verantwoordelijkheid van het team om een zo optimaal mogelijke manier te vinden en deze toe te passen. De omvang/scope van een sprint is bij aanvang vastgesteld. Gedurende de sprint vinden hierin geen wijzigingen plaats. Wijzigingen in de overige items van de product backlog zijn wel toegestaan. Deze wijzigingen vinden alleen plaats via de product owner. Aangezien er met korte sprints wordt gewerkt, is het over het algemeen acceptabel dat een wijziging pas in een volgende sprint wordt gerealiseerd. In het uitzonderlijke geval dat uitstel onacceptabel is, moet de lopende sprint onderbroken worden en start er een nieuwe sprint. In de sprintplanningsmeeting wordt door het team een opdeling in taken gemaakt die gedurende de sprint uitgevoerd zullen worden. De user stories en bijbehorende taken worden hierbij op een Scrumboard geplaatst (zie figuur 5.9.2). Dit visuele Scrumboard geeft ten allen tijde de status van de sprint weer. User Story To Do In Progress Done A B C E Figuur 5.9.2 Scrumboard De taken zullen samen met de bijbehorende stories visueel over het bord van de kolom To do via de kolom In progress naar de kolom Done verschuiven. Done betekent idealiter dat iets klaar is om in productie genomen te worden. Maar het haalbare eindresultaat van een sprint verschilt per organisatie en zelfs per project. De definitie van het eindresultaat van een sprint wordt vastgelegd in de Definition of Done. Het Scrumboard is een herkenbaar middel in de ruimtes waar volgens Scrum wordt gewerkt. Dagelijks wordt het bord bijgewerkt en wordt de status tijdens de daily scrum (ook wel be-
5 Projectmanagementmethoden 113 kend als daily stand-up) besproken. Dit is het dagelijkse afstemmingsmoment van circa 15 minuten voor het team waarin het doelgericht samenwerken wordt benadrukt. Er worden drie vragen behandeld: Wat heb je tussen de vorige en deze daily scrum bereikt? Wat ga je tot de volgende daily scrum bereiken? Wat zijn jouw belemmeringen (impediments ) daarbij. Impediments worden vaak op een aparte lijst bijgehouden, de impediments-lijst. Aan het eind van de sprint vindt er een sprintreview (ook wel bekend als demo) plaats voor het team en de belanghebbenden. Hierin worden de daadwerkelijk, volledig afgeronde resultaten van de sprint getoond. Ook vindt er aan het eind van elke sprint een retrospectief plaats. Hierin evalueert het team de zaken die goed gaan en de zaken die verbeterd kunnen worden. Er worden vervolgens acties opgesteld om de belangrijkste verbeteringen door te voeren. Op deze manier ontstaat een continue verbetercyclus. Gedurende een sprint wordt de voortgang van het team inzichtelijk gemaakt aan de hand van een sprint burn-down chart. Dit is een grafiek met op de horizontale as de dagen in de sprint en op de verticale as het aantal storypunten in de sprint. Elke dag wordt aangegeven hoeveel punten er verbrand zijn. De punten van een user story gelden hierbij als verbrand als alle bijbehorende taken op Done staan. Een soortgelijke burn-down kan gemaakt worden op basis van uren in plaats van storypunten als alle taken in uren zijn geschat. Dit laatste wordt vaak bij startende teams gedaan, maar mag nooit als vervanger van de burn-down op storypunten gaan dienen. De focus moet liggen op het resultaat, wat echt gerealiseerd is, niet op hoeveel uren er besteed zijn. Naast de sprint burn-down is er ook een Release of Product burn-down. Deze bevat op de horizontale as sprints en op de verticale as het totaal aantal storypunten bij aanvang van het project. Na elke sprint wordt deze burn-down bijgewerkt waardoor inzicht ontstaat in het benodigde aantal sprints om de gehele backlog weg te werken. Ook kan in deze burn-down inzichtelijk worden gemaakt welke wijzigingen of aanvullingen er op de product backlog plaatsvinden. Zo kan bij de toevoeging van een nieuwe functionaliteit duidelijk worden gemaakt hoeveel sprints er extra nodig zullen zijn of welke functionaliteit gaat afvallen. In de meeste gevallen zal het resultaat van een sprint niet elke keer in productie genomen worden. In een releaseplanningsmeeting bij aanvang van het project worden de releases gedefinieerd op basis van een verzameling incrementen. De verzameling incrementen worden als deelproduct met toegevoegde waarde in productie genomen. Het releaseplan kan na elke sprint worden bijgesteld en is een belangrijk middel in de afstemming met de omgeving van het project.
114 Ik werk sinds een aantal maanden bij bol.com. In mijn vorige baan werkte ik vaak met de watervalmethodiek. Bij waterval bedenk en ontwerp je eerst de volledige oplossing en ga je daarna de oplossing pas implementeren. Dat is een beetje de omgekeerde wereld van Scrum. Scrum heeft voor bol.com veel voordelen. Je kunt met Scrum veel beter inspelen op wijzigende marktomstandigheden of veranderingen binnen het bedrijf, zeker omdat we binnen bol.com elke vier weken een release naar productie opleveren. Je bent veel flexibeler in projectimplementaties. Dat is heel belangrijk als je heel snel moet kunnen inspelen op wat de markt vraagt. Je moet wel een stukje controle loslaten als projectmanager. En dat is wel even wennen. Eduard de Sonnaville Projectmanager, bol.com 5.9.7 Beschikbaarheid Scrum is een open methode. Er is inmiddels veel geschreven over Scrum en er is dan ook via vele kanalen informatie beschikbaar. Door de eenvoud en resultaatgerichtheid van de methode is deze populair bij teams en opdrachtgevers. Bij teams vanwege de focus op waarde en de relatieve vrijheid die samenhangt met het zelfcommitment dat men heeft, bij opdrachtgevers vanwege de snelle feedback en de hoge mate van sturing op basis van waarde, kwaliteit en risico. Een aandachtspunt bij de implementatie van Scrum is dat door de openheid wel Scrum in name only kan ontstaan. Hierbij worden slechts enkele elementen van Scrum toegepast, of wordt het geheel alleen als proces gevolgd, zonder de feedbackmechanismen en empirische leervermogens te benutten. Scrum vereist de discipline van het team om maximale transparantie over voortgang en kwaliteit te geven en om steeds de optimale weg te zoeken. De bekende Nokia-test van Bas Vodde kan gebruikt worden om te controleren of de basis wordt toegepast. Deze test is te vinden op: http://jeffsutherland.com/basvodde2006_nokia_agile.pdf 5.9.8 Toepassingsgebied Scrum is een productontwikkelraamwerk dat vooral wordt toegepast binnen software development. Daar heeft het ook zijn bekendheid gekregen. Maar de methodiek is evengoed buiten de ICT toepasbaar. Scrum wordt zowel binnen multinationals als kleinere bedrijven toegepast, voor allerlei soorten projecten: complex en niet complex, nieuwbouw en legacy, front-end en backend. Scrum is door zijn transparantie en eenvoud goed te combineren met andere methoden, zoals PRINCE2, CMM, ITIL, PMBOK Guide. Vaak zorgt Scrum dan voor een vermindering van het aantal rollen, overdrachtsmomenten en procedures, waardoor de genoemde methoden effectiever hun toegevoegde waarde kunnen leveren en qua aanpak lichter worden.
5 Projectmanagementmethoden 115 5.9.9 Beheer van de methode De methode is vastgelegd in: Schwaber, K.& M. Beedle. (2002). Agile Software Development with Scrum. Pearson International Edition. ISBN 9780132074896 Dit boek is gebruikt als brondocument bij de vergelijking met andere methoden. Literatuur Schwaber, K. & J. Sutherland. (2010), De Scrum Guide, scrum.org ttp://www.scrum.org/ scrumguides/). Solingen, R. van en E, Rustenburg. (2010). De kracht van Scrum. Pearson Education Benelux. Takeuchi, H. & I. Nonaka. The New New Product Development Game. In: Harvard Business Review, 1986. Voor een overzicht van diverse Agile-boeken: http://www.noop.nl/2010/08/top-100-agile-books.html Beheerder van de methode De belangrijkste Scrumgebruikersgroepen in Nederland zijn NLScrum (http://www.meetup.com/nlscrum/) AgileHolland (http://agileholland.com/) voor individuele leden Agile Consortium (www.agileconsortium.nl) voor organisaties. Opleidingen Opleidingen worden verzorgd door Certified Scrum Trainers. Informatie hierover is te vinden op: http://www.scrumalliance.org/pages/scrum_certification. http://www.scrum.org/assessments. DEEL II 5.9.10 Onderscheidende kenmerken Categorie Aanpak Projectopzet Besluitvorming Zichtbare resultaten Bewaking en beheersing Kwaliteit Beschikbaarheid Kenmerk Multidisciplinair team met focus op maximale klantwaarde. Heart beat van sprints gevoed vanuit een geprioriteerde product backlog. Zelfsturende teams, prioritering door product owner. Aan het eind van elke sprint. Product backlog, burn-down charts. Resultaat is in elke sprint expliciet, bijsturing is na elke sprint mogelijk Niet onderhandelbaar. Open methode, boeken en opleidingen ruim beschikbaar.
116 5.9.11 Sterke kanten en valkuilen bij het gebruik van de methode Sterke kanten Focus op klantwaarde. Kunnen omgaan met verandering Zelfsturing. Continue verbetering, uitgaan van mogelijkheden in plaats van onmogelijkheden. Valkuilen Te vroeg starten, er moet voldoende ready zijn. Niet alle belanghebbenden zijn betrokken. Niet kunnen omgaan met de vrijheid vanwege onvoldoende discipline en verantwoordelijkheidsgevoel. Directief sturend management gericht op voorkomen van veranderen in plaats van het benodigde faciliterende management. 5.9.12 Scrum vergeleken Door het brondocument Agile Software Development with Scrum te scoren volgens het PM- Vergelijkingsmodel, komen we tot de volgende scores van Scrum: Contextmanagement Scrum Besturing 3 2 Doel / resultaat Contextanalyse 1 0 Plannen Team Meten en Bewaken Leiderschap Interne communicatie Risico Fig. 5.9.3 De score van Scrum op de verschillende aspecten van projectmanagement Scrum scoort vooral hoog op meten en bewaken, risico en interne communicatie. Bij Scrum wordt op een wezenlijk andere manier beheerst dan bij de meer traditionele methode. Dit komt ook door het timeboxen dat net als bij Atern gebruikt wordt (zie ook paragraaf 8.11). In hoofdstuk 8 hebben we de sprint van Scrum opgenomen en ook de waarden die Scrum formuleert voor een succesvol team. Dit zijn elementen die breed toepasbaar kunnen zijn in allerlei soorten projecten.