thumb|Scrummethode Scrum is een raamwerk waarbinnen teams hun aanpak van een project of probleem stapsgewijs kunnen bijsturen. Kenmerkend voor Scrum is dat het grote vraagstukken opknipt in kleine projectjes met een vaste lengte. Zo'n projectje heet in Scrum een Sprint.

Van alle Agile-raamwerken is Scrum verreweg de populairste, daarom worden de termen Scrum en Agile vaak ten onrechte als synoniem gezien. Scrum is een implementatie van Agile, wat blijkt uit het centraal zetten van toegevoegde waarde, een iteratieve opzet en empirie als uitgangspunt.

Scrum is een term die afkomstig is uit de rugbysport. Zoals in rugby steken teams in het Scrum-framework dagelijks de koppen bij elkaar, in 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 is ontwikkeld in de Verenigde Staten en wordt veelal gebruikt in deels Engelstalige projecten, vandaar de Engelse terminologie. De term werd zijdelings geïntroduceerd in het artikel The New New Product Development Game van Ikujiro Nonaka en Hirotaka Takeuchi, dat begin 1986 in het tijdschrift Harvard Business Review gepubliceerd is. Het zette een flexibele aanpak van productontwikkeling tegenover een klassiek sequentiële werkwijze zonder veel interactie.

Sterk geschematiseerd omvatte de klassieke werkwijze zes ontwikkelingsfasen: conceptontwikkeling, haalbaarheidsonderzoek, productontwerp, doorontwikkeling van het prototype, voorserieproductie en definitieve productie. Een voorbeeld is de Phased Project Planning (PPP) van de NASA. Een variant is dat er wat overlap is tussen twee opvolgende fasen, zoals destijds bij Fuji-Xerox. Nonaka en Takeuchi bepleitten echter een veelomvattende interactie waarbij de conceptontwikkelaars en alle volgende afdelingen tot in de laatste fase betrokken bleven, weliswaar in afnemende mate. Dit werd gepraktiseerd bij Honda en Canon. De teams kregen vanaf het begin veel vrijheid, waarbij het doel meer geschetst dan gespecificeerd werd. Het gevolg was een proces met de volgende kenmerken:

Ingebouwde instabiliteit Zelforganiserende projectteams Overlappende ontwikkelingsfasen Multilearning, de teams en deelnemers leerden van elkaar Subtiele procesbeheersing Inzichten werden doorgegeven in de organisatie

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.

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 userstory's. Deze userstory's worden bijgehouden in een lijst, de product backlog of werkvoorraad. De producteigenaar sorteert de werkvoorraad op prioriteit. De belangrijkste userstory's 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 userstory's 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 sprintreview 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 lastiggevallen 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 thumb|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 userstory's 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 backlog 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 userstory. 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.

Sprintreview In de sprintreview wordt het product getoond dat af is. Eventueel wordt ook aangegeven wat niet gelukt is om af te krijgen deze sprint. De sprintreview 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)