Scrum (projectmanagementmethode)

Scrum is een raamwerk waarbinnen teams hun aanpak continu kunnen blijven verbeteren. Van alle Agile raamwerken is Scrum verreweg de populairste, daarom worden de termen Scrum en Agile vaak ten onrechte als synoniem gezien. Scrum is Agile omdat het toegevoegde waarde centraal zet, een iteratieve opzet kent en uit gaat van empirisme. Kenmerkend voor Scrum is dat het grote vraagstukken opknipt in kleine projectjes met een vaste lengte. Zo'n projectje heet in Scrum een Sprint. Scrum is een term die afkomstig is uit de rugbysport. Bij een scrum steken beide rugbyteams de koppen bij elkaar. In het Scrum framework steek je ook dagelijks de koppen bij elkaar. Dat heet dan de Daily Scrum.

Scrum wordt vaak gebruikt bij software of producten waarvan de klant of gebruiker nog niet goed weet wat hij wil en waarbij men al doende leert om de eisen en wensen beter te beschrijven en in bruikbare software of producten om te zetten. Vaak weet men pas wat men wil als men het prototype ziet en dan worden alsnog de eisen aangepast. Scrum heeft de flexibiliteit om met laat-wijzigende eisen en wensen om te gaan. Scrum valt onder de agile-softwareontwikkeling.

Geschiedenis

Scrum werd geïntroduceerd in een onderzoek door Ikujiro Nonaka en Hirotaka Takeuchi, dat begin 1986 in het tijdschrift Harvard Business Review gepubliceerd is. In dit onderzoek wordt beschreven dat projecten met kleine multidisciplinaire teams historisch gezien het beste resultaat leveren. Naar aanleiding van dit onderzoek ontwikkelde Jeff Sutherland in 1993 de scrumwerkwijze, terwijl Ken Schwaber een eigen benadering bij zijn bedrijf toepaste. Samen werkten ze dit verder uit en in 1995 formaliseerde Ken Schwaber scrum als softwareontwikkelmethode. Scrum is ontwikkeld in de Verenigde Staten en wordt veelal gebruikt in deels Engelstalige projecten, vandaar de Engelse terminologie.

Scrummethode

Doelstellingen

• In korte sprints binnen korte tijd werkende software of producten opleveren, waardoor snel duidelijk wordt of men goed bezig is. Dit beperkt de risico's van langdurige projecten waarin gebruikers of klanten soms pas na een jaar het resultaat kunnen zien en uitproberen.
• Snel duidelijkheid over de voortgang.
• Korte lijnen, snelle communicatie en teamwerk.
• Grotere betrokkenheid teamleden, concentratie op overzichtelijk deel van project.

Theorie

Scrum is gebaseerd op de theorie van empirische procesbesturing oftewel het empirisme. Empirisme gaat ervan uit dat kennis ontstaat uit ervaring en het nemen van beslissingen op basis van wat bekend is. Scrum gebruikt een herhalende en incrementele aanpak om voorspelbaarheid te optimaliseren en risico’s te beheersen.
Drie pijlers vormen het fundament van elke implementatie van empirische procesbesturing:
transparantie, inspectie en aanpassing

Uitgangspunten

Scrum heeft de volgende uitgangspunten:

• Toewijding: de leden moeten zich er vol voor inzetten; het is geen deeltijdklus.
• Focus: men moet zich focussen op wat er in de sprints gedaan moet worden.
• Openheid: men moet elkaar goed op de hoogte houden van de voortgang en mogelijke problemen. (transparantie)
• Respect: men moet mensen met een andere achtergrond en deskundigheid respecteren.
• Lef: men moet lef hebben om zaken te benoemen, vragen te stellen en met nieuwe oplossingen te komen.

Werkwijze

Scrum werkt met multidisciplinaire teams, die bij voorkeur in dezelfde ruimte werken, zodat er gemakkelijk kan worden overlegd. Het team wordt begeleid door een scrummaster, die een faciliterende rol heeft. De klant, opdrachtgever of een vertegenwoordiger hiervan wordt product owner of producteigenaar genoemd. Hij of zij specificeert de gewenste resultaten, meestal in de vorm van user stories. Deze user stories worden bijgehouden in een lijst, de product backlog of werkvoorraad. De producteigenaar sorteert de werkvoorraad op prioriteit. De belangrijkste user stories komen daarbij bovenaan te staan.

Er wordt gewerkt in sprints of iteraties. Die duren meestal een week tot een maand, met een tijdsduur van twee weken als meest gebruikelijke tijdsduur. Sprints zijn time boxed. Oftewel: van tevoren staat vast hoe lang een sprint hoogstens duurt en wanneer deze is afgelopen. Aan het begin van een sprint worden de user stories voor die sprint bepaald en vastgelegd in de sprint backlog. Zodoende kan een sprint ook nooit langer duren dan de afgesproken tijd.

Sprints resulteren in zo tastbaar mogelijke resultaten. Voor softwareontwikkeling kan dat betrekking hebben op bruikbare code, inclusief integratie, tests en documentatie, en liefst toepasbaar voor de klant of eindgebruiker.

Aan het eind van een sprint vindt een sprint review plaats, waarbij het resultaat wordt getoond aan de product owner. Daarnaast vindt een evaluatie binnen het team plaats.

Rollen

Bij scrum kent men drie hoofdrollen. Deze zijn:

Product owner

De product owner oftewel producteigenaar is de opdrachtgever of klant. Hij/zij heeft het meeste belang bij de software of het product dat gemaakt wordt. Hij of zij zorgt ervoor dat de rekening betaald wordt. Zij beheert ook de product backlog en bepaalt wat er moet gebeuren en in welke volgorde. In principe wordt begonnen met het belangrijkste, waar het meeste voordeel mee te behalen is, wat boven aan de product backlog staat.

Ontwikkelteam / expertteam

Het ontwikkelteam is multidisciplinair samengesteld en is verantwoordelijk voor het afleveren van de software of het product aan het einde van elke sprint. Het team bestaat meestal uit drie tot negen personen. Het team organiseert zichzelf. Zij doen de analyse, ontwerp, ontwikkeling, test en documentatie en zorgen dat er aan het eind van de sprint een kant-en-klaar product of werkende software is, dat in principe in productie genomen kan worden.

Scrummaster

De scrummaster begeleidt en helpt het team door ervoor te zorgen dat het juiste scrumproces gevolgd wordt. Hij verzorgt ook eventuele trainingen. De scrummaster regelt alle vergaderingen. Ook regelt hij de voorzieningen zoals een werkruimte, hardware en software. De scrummaster zorgt ervoor dat het team niet lastig gevallen wordt door derden die met extra eisen tussendoor komen of die bijvoorbeeld tijdelijk mensen nodig hebben uit het team. De scrummaster is geen projectmanager. Hij regelt bijvoorbeeld niet de personele zaken zoals selectie, beoordeling en beloning van de mensen. Dit bevordert de openheid en samenwerking.

Scrumrituelen

Daily scrum

De daily scrum of stand-up: iedereen staat!

Elke dag is er de daily scrum (soms ten onrechte stand-up genoemd, maar deze term is geen Scrum). Deze vergadering heeft de volgende regels:

• Alle leden van het ontwikkelteam hebben zich voor de vergadering voorbereid.
• De vergadering start precies op tijd, ook als niet iedereen aanwezig is.
• De vergadering is elke dag op precies dezelfde tijd en plaats, meestal 9.00 uur in de projectkamer.
• De vergadering duurt hoogstens vijftien minuten, korter mag ook.
• De vergadering wordt meestal staande gehouden (stand up).
• Bezoekers zijn welkom maar normaal gesproken spreken alleen de leden van het ontwikkelteam.
• Normaal gesproken houdt men een rondje waarbij elk teamlid drie vragen beantwoordt:
  • Wat heb je gedaan?
  • Wat ga je doen?
  • Zie je ook problemen en uitdagingen (de zogenaamde impediments), heb je hulp nodig, zijn er dingen die voor andere teamleden van belang zijn?
• Het beantwoorden van deze drie vragen moet kort en bondig zijn. Inhoudelijke informatie moet dan buiten de vergadering worden besproken.

De vergadering mag hoogstens vijftien minuten duren dus grotere problemen worden buiten de vergadering verder besproken. De vergadering is net lang genoeg om een kopje koffie, al staande, op te drinken.

Backlog refinement

De user stories die op de backlog staan moeten gemaakt worden en verder uitgewerkt. Daarom is het belangrijk om goed te begrijpen van de producteigenaar en via hem van de rest van de organisatie, wat hij nu precies wil.

Zaken die in eerste instantie nog vaag zijn, zoals een "gebruikersinterface ontwikkelen", of "managementrapportages", kunnen mogelijk ook opgesplitst worden in kleinere beter behapbare onderdelen, zoals "gebruikersinterfaces voor verschillende groepen gebruikers", "financiële overzichten" en "commerciële overzichten".

Dit maakt het mogelijk om na te denken over de beste oplossing, zodat ook ingeschat kan worden hoeveel tijd het kost om dat te maken. Hierdoor wordt het ook mogelijk om acceptatiecriteria vast te leggen zodat er acceptatietests gemaakt kunnen worden. Mogelijk moet er zelfs nog aanvullend onderzoek gedaan worden in de vorm van zogenaamde spikes. Binnen de watervalmethode zou dit de analysefase genoemd worden. Bij scrum heeft men dit overleg vrijwel wekelijks, gedurende het gehele project.

Dit proces is niet het belangrijkste scrumproces, maar is in de loop van de tijd toegevoegd om te zorgen dat de zaken op de back-log voldoende kwaliteit hebben (duidelijk genoeg zijn), om in de komende sprint opgenomen te worden.

Scrum of scrums

Als er meerdere scrumteams zijn, is er ook een overleg tussen deze teams nodig. Het gaat dan om de punten waarop men met elkaar te maken heeft, zoals interfaces. Dit overleg wordt normaal gesproken aansluitend op de daily scrum gehouden.

• Elk team stuurt een vertegenwoordiger.

De agenda is ongeveer hetzelfde als bij de dagelijkse scrum, namelijk:

• Wat hebben jullie gedaan sinds de vorige bijeenkomst?
• Wat gaan jullie nu doen?
• Gaat alles goed of hebben jullie problemen of vertraging?
• Zijn er zaken die voor ons van belang zijn, waar we last van zouden kunnen hebben?
• Als er afspraken niet nagekomen zijn wordt hierop gereageerd door het team.

Sprintplanning

Aan het begin van de sprint is er een sprintplanningsoverleg. In principe worden de bovenste, belangrijkste user-stories van de product backlog in de sprint opgenomen. Het is cruciaal dat het ontwikkelteam de user-stories kiest die worden opgenomen, omdat de teamleden degenen zijn die zich engageren om de onderliggende taken uit te voeren. Daarom bepaalt ook het team hoeveel werk kan worden opgenomen in de betreffende sprint en is het team tevens verantwoordelijk voor de inschatting van de hoeveelheid werk per user story. Voor dit inschatten is plan poker een veel gebruikte methode. Het ontwikkelteam moet ook bevestigen dat alles duidelijk is. Taken worden dan vervolgens verder binnen het ontwikkelteam verdeeld.

Sprint review

In de sprint review wordt het product getoond dat af is. Eventueel wordt ook aangegeven wat niet gelukt is om af te krijgen deze sprint. De sprint review duurt hoogstens vier uur. Het hele sprint team is aanwezig plus eventueel andere geïnteresseerden. Na afloop een borrel is een goede gewoonte.

Evaluatie (retrospective)

De evaluatie is bedoeld om te leren van wat goed en fout ging met als doel om als team nog beter te worden. Alle teamleden zijn dan ook aanwezig. Het overleg duurt hooguit drie uur per maand en wordt geleid door de scrummaster. Men maakt een rondje en iedereen zegt wat goed en fout ging. Men kan ook zeggen wat het meeste opviel of wat het moeilijkste was. Het is niet de bedoeling om mensen de schuld te geven van een vertraging. De bedoeling is hieruit lering te trekken voor komende sprints.

Een van de belangrijkste voorwaarden van een retrospective is tegelijk een van de grootste uitdagingen voor de moderator: het scheppen van een oplossingsgericht klimaat waarin deelnemers zich vrij kunnen uitspreken én gezonde onderlinge verstandhoudingen opgebouwd worden.

Hulpmiddelen (artifacts)

Product backlog

De product backlog is een overzicht van de dingen die nog gedaan moeten worden. Dit wordt in andere software-ontwikkelmethoden wel de requirements genoemd: de eisen en wensen. Het bestaat uit alles wat van belang is om mee te nemen in de sprint zoals eigenschappen, fouten uit vorige releases, niet-functionele eisen zoals navigatie, kleur, "look en feel", snelheidseisen. De product owner is de eigenaar van deze lijst en bepaalt de volgorde. In principe staan de belangrijkste bovenaan, maar ook een andere volgorde is mogelijk. Hierbij spelen zaken zoals risico, waarde voor de organisatie, datum waarop iets nodig is en wettelijke eisen. De zaken op de lijst zijn normaal gesproken in de vorm van een user story. Hierin staat WAT er gemaakt moet worden WAAROM en voor WIE. Iedereen kan er dingen aan toevoegen, maar de product owner is en blijft verantwoordelijk. Er staan ook ruwe schattingen bij van de waarde voor de organisatie en van de ontwikkelkosten. Voor het inschatten van de ontwikkeltijd kan gebruikgemaakt worden van wat binnen scrum planning poker genoemd wordt.

Sprint backlog

Een scrum task board.

In de sprint backlog staat wat er deze sprint wordt gedaan. De sprint backlog wordt samengesteld uit de bovenste onderwerpen van de product backlog. Het ontwikkelteam bepaalt wat ze kunnen doen gebaseerd op hun snelheid in de vorige sprints.

Gebruikelijk is dat de items op de sprint backlog geschreven worden op post-its. Er zijn dan drie kolommen, "to do", "in progress", "done". Soms met een vierde kolom "testing". Zodoende is voor iedereen duidelijk hoe het ermee staat.

Het ontwikkelteam bepaalt zelf wie wat doet, of eigenlijk kiezen de leden zelf wat ze (kunnen en willen) oppakken van de todo-lijst. Dit bevordert dat het team zich ermee verbonden voelt, dat ze zich er voor willen inzetten en dat het hun product wordt.

Er kunnen na de start geen onderwerpen meer toegevoegd worden aan de sprint, behalve door het ontwikkelteam zelf. Nadat de sprint klaar is wordt de product backlog nog eens tegen het licht gehouden en kunnen prioriteiten en dus de volgorde wijzigen.

Acceptatiecriteria (definition of done)

In de definition of done staat wat er is afgesproken over hoe men de software of het product oplevert. Eisen over documentatie (Engelstalig), testen (getest door gebruikers en de afdeling beheer, met welke apparaten en webbrowsers), locatie (op de acceptatieomgeving) etcetera.

Verbetering (increment)

De "verbetering" (increment) is een lijst van alle gerealiseerde verbeteringen en veranderingen aan het product. Deze lijst wordt aan het eind van elke sprint bijgewerkt. Hierop staan alleen items die voldoen aan de definition of done. Dit overzicht moet in een vorm zijn die bruikbaar is voor de klant of product owner. De lijst kan nodig zijn om verdere investeringen in het project te verdedigen en om aan buitenstaanders, klanten, handelaren en de overheid duidelijk te maken wat men tot nu toe bereikt heeft. Of deze lijst gebruikt en gepubliceerd wordt, ligt aan de producteigenaar. Op basis van Engelse terminologie wordt dit ook wel aangeduid als PSI of potentially shippable product.

Burn down

Dit is een voorbeeld van een burn down chart van een voltooide sprint. Men ziet wat er af is en wat er nog gedaan moet worden.

De burn down chart van de sprint hangt meestal aan de wand in de projectkamer. Op die manier is voor iedereen direct duidelijk hoeveel er nog gedaan moet worden. Doordat hij dagelijks wordt bijgewerkt is direct duidelijk hoe het ervoor staat. Er zijn ook andere typen burn down chart in gebruik, bijvoorbeeld de release burn down chart waarop staat hoeveel er nog gedaan moet worden voor de volgende release van het product (ervan uitgaande dat een release in meerdere sprints gerealiseerd wordt). Ook bestaat er een alternative release burn down chart, deze doet in principe hetzelfde, maar geeft extra de wijzigingen aan door het meer/minder werk, veroorzaakt door het voortschrijdende inzicht.

Scrum op grote schaal

Wanneer een product groter en complexer wordt, kan besloten worden om met meerdere teams aan hetzelfde product te gaan werken. Om dit synchroon te kunnen doen is extra coördinatie nodig en alleen een Scrum of scrums is dan niet meer genoeg. Hiervoor zijn verschillende methoden ontwikkeld:

Scaled agile framework (SAFe)

SAFe is een methode om met verschillende Scrumteams gezamenlijk aan een product te werk en in een cadans van meerdere (meestal vijf) sprints een gezamenlijke oplevering te doen. Deze vijf sprints worden samen de Agile Release Train (ART) genoemd. Het op te leveren product wordt de PSI genoemd (Potentially Shippable Product). Aan het begin van de ART wordt een gezamenlijk doel vastgesteld en de teams bepalen wat er wel en niet in hun sprints opgenomen kan worden om dit doel te bereiken. De ART heeft een overkoepelende Scrum Master die de Release Train Engineer (RTE) wordt genoemd. Deze RTE onderhoudt nauw contact met de Scrum Masters en eventueel de Product Owners. Soms wordt de laatste sprint in de ART gebruikt voor verificatie, om de laatste afstemmingen te doen, onvoorzien onderhoud, demo's met de gebruikers en de volgende ART te plannen. Wanneer er tijd over is kan nog aan experimenten worden gedaan. Om voor extra begeleiding te zorgen wordt een Lean Center of Excellence (LACE) opgezet. Dit is een kennis- communicatie- en analysecentrum.

Large-Scale Scrum (LeSS)

LeSS heeft vergeleken met SAFe minder sturing van bovenaf. Er zijn meerdere teams die samen elke sprint met elkaar samenwerken. De teams hebben gezamenlijk één backlog en slechts één Product Owner. Hierdoor wordt er meer verantwoordelijkheid bij de teams neergelegd dan bij SAFe. Aan het eind van de sprint volgt een gezamenlijke sprint review. Er wordt zowel een gezamenlijke retrospective als een overkoepelende retrospective gehouden. Wanneer er meer dan acht teams betrokken zijn worden de teams geclusterd met per cluster wel een eigen backlog. Dit wordt Less-Huge genoemd.

Begrippen

De volgende begrippen worden gebruikt in scrum en/of zijn bruikbaar om het geheel te begrijpen.

Scrumteam (scrum team)

Het hele team, bestaande uit de producteigenaar, scrummaster en het ontwikkelteam.

Producteigenaar (product owner)

De verantwoordelijke voor de product backlog, waarmee de prioriteiten van de belanghebbenden naar voren komen zodat het werk van het ontwikkelteam waarde heeft voor de organisatie.

Scrummaster

De verantwoordelijke voor het scrumproces, de persoon die ervoor zorgt dat alles goed loopt en men maximaal profiteert van de voordelen van scrum.

Ontwikkelteam

Een groep van specialisten verantwoordelijk voor het ontwikkelwerk en de realisatie van een in principe kant-en-klaar product, productuitbreiding of software.

Sprint burn down chart

Een grafiek waarmee de dagelijkse voortgang van de sprint wordt weergegeven.

Release burn down chart

Een grafiek waarmee wordt aangegeven wat er al van de product backlog klaar is en wat er nog gedaan moet worden.

Product backlog

Een lijst met op een hoog niveau de eisen en wensen voor het product.

Sprint backlog

Een lijst met taken die tijdens de sprint moeten worden uitgevoerd, inclusief een plan voor het opleveren van het product increment.

Sprint

Een periode van een tot vier weken waarin men aan een aantal zaken van de product backlog werkt. Dit is een time box.

Spike

Een korte periode waarin in een time box een onderzoek gedaan wordt. Bijvoorbeeld om een prototype te maken of te testen of iets mogelijk is.

Lichtkogel (tracer bullet)

Een lichtkogel is een spike waarmee men probeert te onderzoeken wat de mogelijkheden zijn van de gekozen projectarchitectuur, technologie en best practice. Het resultaat is een stukje programmatuur. Het is misschien de ontwikkeling van een klein onderdeel, maar het is geen wegwerpprogrammatuur. Het kan in het verdere proces gebruikt worden. Het is een proof of concept en ook een "prototype", bedoeld om inzicht te krijgen in de nieuwe architectuur, technologie en werkwijze. De naam komt uit het leger, daar gebruikt men lichtspoormunitie om het spoor van de kogels te volgen en eventueel de richting te corrigeren.

Taken

Aan het begin van de sprint worden de stories van de product backlog uiteengerafeld tot taken. Aan een taak hangt een planning in uren. Een taak mag volgens de theorie hoogstens twaalf uur zijn, maar meestal spreekt men af dat taken niet langer dan een dag duren.

Definition of done (DoD)

De afvinkcriteria waaraan iets moet voldoen om klaar te zijn. Deze criteria worden door het development team samen bepaald. In veel gevallen is bijvoorbeeld een eis dat alle regressietests succesvol zijn afgesloten.

Definition of ready (DoR)

De afvinkcriteria waaraan iets moet voldoen voordat het op de sprintbacklog opgenomen mag worden. De story moet dus voldoende gespecificeerd zijn.

Velocity

De snelheid van het team, wat het team kan doen in één sprint. De snelheid kan worden berekend op grond van de gerealiseerde snelheid in vorige sprints, gemeten in storypunten, met behulp van een burn down chart. Dit is een richtlijn voor het team en omgeving om goed in te kunnen schatten hoeveel men kan doen en wat men kan verwachten.

Impediment

(obstakel) Alles wat in de weg staat van een doelmatig proces.

Sashimi

Een rapport waarin is aangegeven dat iets "klaar" is. Vernoemd naar het gelijknamige gerecht.

Minimum viable product (MVP)

Is een product met genoeg functionaliteit om voldoende waarde te hebben om vroeg aansluitende klanten aan te trekken en om terugkoppeling te krijgen voor de verdere ontwikkeling.

Abnormal termination

(abort). Indien nodig kan de product owner (producteigenaar) een sprint voortijdig stoppen. De product owner kan dit doen met input van het team, scrummaster of management. Het kan bijvoorbeeld zo zijn dat het management de sprint wil stoppen omdat externe omstandigheden het doel van de sprint niet meer nuttig maken. Als een sprint op deze manier gestopt wordt is het vervolg dat men in een vergadering uitlegt waarom dit nodig was, tevens is er dan weer een nieuwe "sprintplanningsvergadering" om de volgende sprint te plannen.

Scrumbut

Een scrumbut is een uitzondering op de "echte" scrumwerkwijze, waarbij het team scrum heeft aangepast aan hun eigen behoefte.

Pair programming

Het in tweetallen werken aan een programma of probleem. Dit is een intensieve samenwerking waarmee men van elkaar leert en samen iets probeert op te lossen wat te moeilijk is voor een persoon omdat kennis of vaardigheden ontbreken. Men kan hierbij gebruikmaken van elkaars expertise.

Refactoring

Het opnieuw maken, ontwikkelen of programmeren van een bepaald onderdeel om het beter (onderhoudbaar) te maken.

Storypoint

Worden gebruikt in planning om de omvang van een klus (story) aan te geven. Door een bekende korte klus 1 of 2 punten te geven kunnen grote klussen ingeschat worden als bijvoorbeeld driemaal zo lang of tienmaal zo lang.

Timeboxing

Een methode waarbij men een afgesproken tijd (time box) neemt om iets te doen. Zodoende kan iets ook niet uitlopen. Men kan bijvoorbeeld voor het testen afspreken dat men drie dagen neemt om te zoeken naar fouten. Of men kan afspreken om per gebruiker twee dagen training te geven. Vergaderingen kunnen een begintijdstip en een eindtijdstip hebben.

Triangulation

Een planningsmethode waarbij men vanuit verschillende gezichtspunten tot goede schattingen hoopt te komen. Voornamelijk door met elkaar te praten over waarom men denkt dat iets een bepaalde tijd gaat duren.

Andere Agile-methoden

• Extreme programming
• Agile Unified Process
• Crystal (softwareontwikkeling)
• Dynamic systems development method
• Test-driven development

Externe links

• Scrum gidsen in diverse talen

Bronnen, noten en/of referenties