Scrum

In de IT-wereld wordt al lange tijd gebruik gemaakt van een nieuwe methode van ontwikkelen en samenwerken in multidisciplinaire teams bij de ontwikkeling van nieuwe software. Inmiddels is deze methode ook overgewaaid naar andere vakgebieden. Toch merk ik dat veel mensen er nog nooit van gehoord hebben. Vandaar dat ik er eens iets over wilde schrijven.

Ik heb zelf het voorrecht gehad om in een Scrumteam te mogen werken, als schrijver van de softwarehandleiding. Ik vond het een verademing. Er wordt veel meer verantwoordelijkheid bij de ontwikkelaars neergelegd. Het ‘wat’ en ‘waarom’ wordt van tevoren bepaald, maar het ‘hoe’ wordt door het team zelf ingevuld. Ook kan er door deze manier van werken veel beter wordt ingespeeld op nieuwe inzichten tijdens het project. 

Er is al heel veel geschreven over Scrum en ik zou jullie kunnen verwijzen naar allerlei andere bronnen, maar ik wil het hier toch graag in mijn eigen woorden en in de door mij gewenste volgorde uitleggen. 

Waarom Scrum?

Je kent wel die verhalen over grote ICT-projecten die volkomen de mist in gaan? Die zes keer zo lang duren als van tevoren verwacht? Waarbij uiteindelijk iets wordt opgeleverd dat niet blijkt te werken? Of dat niet voldoet aan de verwachtingen van de klant? Die hebben dus niet volgens Scrum gewerkt. Of ze zeggen dat ze dit hebben gedaan, maar hebben toch hun eigen ‘variant’ bedacht, want dat gebeurt ook nogal eens. 

Bij de ontwikkeling van software wordt gaandeweg het project meestal pas duidelijk hoe een applicatie echt zou moeten werken. Wat er dan gebeurt is dat plannen flink moeten worden bijgesteld, er meestal méér wordt ontwikkeld dan van tevoren is bedacht en het project wordt dus ook duurder. Ondertussen heeft de klant nog weinig idee van wat er nu uiteindelijk gebouwd gaat worden, omdat er nog maar weinig getoond kan worden. 

Wat is Scrum?

Scrum is een methode om software in kleine delen op te bouwen, in korte perioden van één tot vier weken (meestal twee). Aan het eind van de periode laat het team zien wat er gebouwd is en krijgt het feedback daarop van de stakeholders, de belanghebbenden, zoals (vertegenwoordigers van) klanten. Aan de hand daarvan kan er worden bijgestuurd en worden bepaald wat er tijdens de volgende periode wordt gebouwd. Zo’n periode wordt een ‘sprint’ genoemd.

Met Scrum werk je dus niet aan een volledig van tevoren uitgewerkt plan. De belanghebbenden bekijken en beoordelen het product iedere twee weken, dus als er iets misgaat dan is er hooguit twee weken aan werk weggegooid. 

Wat wordt er gebouwd?

Voor het product dat ontwikkeld moet worden is door de product owner (leg ik straks uit) een globale lijst gemaakt van features die ontwikkeld moeten worden en er is een globale prioritering aan gegeven. Dit wordt de ‘Product Backlog’ genoemd. Alleen de top van die lijst is veel preciezer geprioriteerd. 

Die items zijn omschreven als ‘user-stories’, in de volgende vorm:

“Als (gebruiker), wil ik (feature), zodat ik (reden waarom/achterliggende behoefte)”. 

Bijvoorbeeld:

“Als manager, wil ik een overzicht van alle lopende projecten, zodat ik kan zien waar onze medewerkers momenteel mee bezig zijn.”

“Als onderhoudsmonteur, wil ik mijn uren direct op een werkbon kunnen vastleggen, zodat ik alles maar op één plaats hoef in te voeren.”

Het is daarbij belangrijk dat alleen het ‘wat’ en ‘waarom’ worden beschreven en niet het ‘hoe’. Dat is aan het scrumteam zelf om te bepalen.

Het Scrumteam

Het scrumteam bestaat uit vijf tot negen personen met verschillende specialismen, bijvoorbeeld ontwikkelaars, interface designers, testers, handleiding-/copywriters, etc. Daarnaast is er een scrum master (deze bewaakt en faciliteert het scrumproces), en een product owner. Deze laatste zorgt voor de ontwikkeling van de juiste onderdelen volgens de wensen van de klant. 

De planningsessie: bepalen hoeveel er wordt ontwikkeld in een sprint

Voor iedere nieuwe sprint, bepaalt de scrum master samen met de product owner of de top van de lijst nog steeds klopt qua prioritering. Ook wordt er gekeken of alle user stories zijn gemaakt voor de items die hoog in de prioriteitenlijst staan en dus (afhankelijk van hoeveel tijd er is) ontwikkeld zoude kunnen worden tijdens de komende sprint.  

Tijdens de planningsessie, die de start inluidt van een nieuwe sprint, worden de user stories van boven naar beneden behandeld door het ontwikkelteam. De product owner is erbij om verduidelijking te geven waar nodig.

Definition of done

Per user story wordt bepaald op basis van welke criteria je kunt zeggen deze voltooid is. Dat heet de ‘definition of done’. Het kan ook zijn dat er met een algemene definitie wordt gewerkt die in principe voor alle items geldt.

Om een user story te kunnen voltooien moet deze vaak worden opgeknipt in verschillende taken die uitgevoerd worden door verschillende leden van het team, zoals het ontwerpen, ontwikkelen, testen en opnemen in een (online) handleiding.

Story points toekennen

Zodra alle teamleden exact weten wat de bedoeling van een user story is moet IEDER teamlid aangeven hoe snel hij/zij verwacht dat de user story gebouwd en getest (en gedocumenteerd) kan worden. 

Dat gaat door een aantal punten toe te kennen: 1, 2, 3, 5, 8, 13, 20, 40, 100. Deze punten zijn niet direct gekoppeld aan een tijdseenheid, maar zijn bedoeld om een verhouding aan te geven tussen de te ontwikkelen onderdelen. Omdat men dit vaak lastig vindt wordt er wel eens voor gekozen om het puntenaantal 3 bijvoorbeeld te koppelen aan 8 uren. Beter is het om een redelijk eenvoudige user story te selecteren en daar het aantal van 3 story points aan te koppelen. De leden van het team hebben dan een referentiepunt voor het geven van punten aan de andere user stories.
Als er 100 punten worden gegeven aan een user story is dit een teken dat de story niet te overzien is en moet worden opgeknipt in kleinere stukken. Ook bij 40 punten wordt er vaak voor gekozen om de story op te knippen. 

De Sprint backlog

De Sprint backlog bestaat uit de items die je tijdens die sprint gaat doen. Welke items dit zijn wordt vastgesteld tijdens de planningsessie. 

Aan het begin van de planningsessie wordt vastgesteld wat het totale aantal punten is dat tijdens deze spint kan worden gerealiseerd. Daarbij wordt bijvoorbeeld rekening gehouden met vakanties, ziekte en andere projecten waarin mensen betrokken zijn, etc.  

Zoals gezegd maakt ieder teamlid een inschatting van de benodigde capaciteit. Als teamleden hierover verschillen van mening, wordt er gevraagd of de betreffende personen hun keuze toe willen lichten. Zo kunnen teamleden van elkaar leren waar mogelijke problemen liggen of waar slimmere oplossingen kunnen worden gekozen. 

Uiteindelijk komt het team zo tot een gezamenlijke inschatting per user story en worden er net zo lang user stories toegevoegd uit de product backlog aan de sprint backlog, totdat het totale aantal punten is bereikt dat gedurende deze twee weken door het team kan worden uitgevoerd. Dit is  wat er de komende sprint gedaan zal worden, oftewel, de ‘sprint backlog’.

Het Scrumboard

De items die voor deze sprint geselecteerd zijn komen op het Scrumboard te hangen. Er wordt vaak met een fysiek bord gewerkt. Dit is in het kader van transparantie, zodat iedere belangstellende kan kijken hoe de huidige sprint loopt.

Het Scrumbord bestaat uit drie kolommen: 

• To Do: deze bevat alle items van deze sprint die nog niet door iemand zijn opgepakt.
• Doing / Busy: deze bevat alle items waar op dit moment aan gewerkt wordt. 
• Done: deze bevat alle items die voltooid zijn voor deze sprint.

De stand-up, de demo en de retrospective

Iedere ochtend is er een bijeenkomst (de ‘Stand-up‘), waarbij iedereen staand rondom het Scrumbord, kort wordt besproken: wat het teamlid gisteren heeft gedaan, wat hij/zij die dag verwacht te gaan doen en of hij/zij daarbij hulp nodig heeft van iemand anders. Als dat zo is dan wordt dit buiten de ‘Stand-up’ verder besproken met alleen de betrokken personen erbij. 

Op de laatste dag van de sprint geeft het team een presentatie aan betrokkenen en andere geïnteresseerden om te laten zien wat er gebouwd is, hoe het eruit ziet en hoe het functioneert. Dit wordt de ‘Review‘ of ook wel de ‘Product demo‘ genoemd. Het team krijgt feedback van de betrokkenen en geïnteresseerden en kan op basis daarvan nieuwe user stories toevoegen aan de product backlog, die in de volgende sprint (of later) worden opgepakt.

Na de review vindt de Retrospective plaats. Daar zitten alleen de teamleden bij en zij bespreken onderling hoe het proces is verlopen, wat er goed ging en wat er beter moet. Van de verbeterpunten worden één of twee punten geselecteerd waar bij de volgende sprint extra op zal worden gelet.

Overleg met stakeholders

Tijdens of na de retrospective heeft de product owner vaak een nabespreking met de stakeholders, waarin zij samen een nog beter beeld proberen te krijgen van het uiteindelijke product. Welke punten moeten prioriteit krijgen en welke zijn minder belangrijk of blijken inmiddels zelfs niet meer nodig te zijn. 

Op die manier blijf je als ontwikkelende partij heel dicht bij de verwachtingen van de klant, en werk je aan een product waarvoor de onderdelen die voor de klant het belangrijkst zijn, het eerst worden ontwikkeld. 

Je kunt zo veel gemakkelijker bijsturen. En als er een keer iets wordt opgeleverd dat niet is zoals de betrokkenen het voor ogen hadden, dan zijn er hooguit twee weken aan werk weggegooid. Meer niet. Scrum behoort danook tot de Agile-ontwikkelmethoden.

Scrum wordt al lang niet meer alleen toegepast in de IT-wereld. In het onderstaande filmpje worden voorbeelden gegeven van het ontwikkelen van een auto en een brug. Het wordt ook door onderwijskundig ontwerpers gebruikt en door allerlei andere multidisciplinaire teams. 

Op deze pagina vind je meer uitleg over alle onderdelen van scrum, ook een aantal die ik nog niet genoemd heb: Wat is Scrum? (Improvement Services)

In het onderstaande filmpje wordt alles nog eens kort uitgelegd:

Het filmpje is afkomstig van deze pagina, dat de belangrijkste onderdelen ook nog eens op een rij zet: Wat is Scrum (De Scrumcompany)

En op Frankwatching vond ik een drieluik over Scrum waarbij de schrijver ook zijn eigen ervaringen heeft toegevoegd. 

Ik ben benieuwd naar wat je eigen ervaringen zijn met scrum, en als die negatief zijn, waarin verschilde jullie aanpak dan ten opzichte van wat ik hierboven heb beschreven?