Agile software ontwikkeling: scrum
Iemand die wel eens projectmanager is geweest, weet hoe moeilijk het kan zijn het team op het rechte pad te houden als het gaat om ontwikkelen en je doelen aan het einde van de periode te bereiken. Bij mij is dat niet anders. Nu met Dunamare hebben wij het ambitieuze doel een prototype aan het einde van januari te hebben van een game die nog gebouwd moet gaan worden. Of we het gaan halen? Ik heb geen flauw idee. Wel weet ik dat één man op Game in the City mij de gouden tip heeft gegeven om de ontwikkeling zo optimaal mogelijk te laten verlopen. Het heet scrum en vind zijn oorsprong in de rugby.
Scrum is een zogeheten Agile software development principe. Kenmerkende eigenschappen van verschillende Agile principes zijn zelfdisciplinaire groepen, regelmatige meetings tussen alle betrokken partijen (lees: dagelijks), werken in ‘timeboxes’ (vastgestelde perioden van werk, ook wel iteraties genoemd) en het flexibel kunnen aanpassen van randvoorwaarden gedurende het project.
Het concept
Scrum is ontwikkelt om in korte zogeheten Sprints van tussen de 15 en 30 dagen (te kiezen door het team) een gebruiksklaar stuk software af te leveren. Prioriteiten en doelen worden tijdens een sprint planning meeting bepaald, en komen uit een ‘Product Backlog’ (een lijst met dingen die gedaan moeten worden voor het project). Zie het als een soort moscow model om te bepalen wat echt nodig is en wat je graag zou willen zien als team.
Het team bepaald aan de hand van de Product Backlog wat er in de komende Sprint te behalen valt. Dit is belangrijk, omdat het einddoel niet meer gewijzigd dient te worden tot aan het einde van de Sprint.
Scrum kan op verschillende manieren uitgevoerd worden, met whiteboards en speciale software als populairste manieren.
De Sprint
Doordat iedere iteratie van een scrum (de periode van de Sprint, bijvoorbeeld 3 weken) een op zichzelf staand project is, geeft dat een enorme flexibiliteit. Aan het einde van iedere iteratie kan bekeken worden hoe het ging (reflectie) en kunnen einddoelen bijgesteld worden. Wispelturige opdrachtgevers kunnen op deze manier in een later stadium van je project ontbrekende features aanvragen, zonder in tijdnood te komen als team. Daarnaast kan een product wellicht al heel snel op de markt gebracht worden, omdat het doel van een Sprint is om bruikbare stukken code (potentially shippable) af te leveren voor het product.
Voor iedere Sprint wordt een Sprint Backlog opgesteld. Dit is simpelweg een lijst met gedetailleerd omschreven taken die gedaan dienen te worden tijdens die Sprint. Deze taken komen uit het Product Backlog, die op haar beurt op een iets globale manier de functies beschrijft van het gehele product. Vergelijk het met het Functioneel Ontwerp (simpelweg opsommen wat het moet kunnen) en het Technisch Ontwerp (zo gedetailleerd mogelijk omschrijven wat de functies van iets zijn en hoe ze te maken).
Aan het einde van een Sprint is het de bedoeling dat het team de software met de nieuwe functies van deze iteratie demonstreren aan de opdrachtgever.
Anders dan bij vele andere software ontwikkeling principes, kent in een scrum omgeving niemand een taak toe aan iemand, ook niet de facilitator. Ieder lid van het team bepaald zelf welke taken hij gaat uitvoeren. Het team is daarmee zelforganiserend. Dit is heel belangrijk! Jij als facilitator kunt niet bepalen wanneer een programmeur klaar zou moeten zijn met een bepaalde taak, of dat de designer best wel wat meer werk zou kunnen verrichten (tenzij hij uit z’n neus zit te vreten natuurlijk). Kortom: je motiveert het team en bewaakt het proces.
Het team
Wie zitten er in een Scrum Team? En wat doen die mensen? Deze opsomming is gebaseerd op een typische verdeling bij een CMD project, in bedrijfssituaties komen hier nog managers, analisten, klanten, ‘product owners’, aandeelhouders en dergelijke bij. Iets wat ik hier buiten beschouwing laat.
De facilitator (projectmanager)
In een scrum omgeving is de projectmanager meer een regelaar. Een facilitator zorgt ervoor dat de hardware, software, documenten en tools er zijn zodat het team zijn werk optimaal kan doen. Waar bij andere methoden de projectmanager nog actief taken liep uit te delen aan de mensen die onder hem of haar staan, is het team bij scrum zelforganiserend. De facilitator houdt zich dus meer met de faciliteiten bezig dan met de mensen in zijn team. Verder zorgt de facilitator ervoor dat de scrum methode uitgevoerd wordt zoals bedoeld is (meetings niet langer dan 15 minuten, geen veranderingen in de Sprint Backlog, etc.).
Het team (de programmeurs, designers, etc.)
Deze club mensen heeft de verantwoordelijkheid om de Sprint tot een goed einde te brengen. Dit betekent dat na x weken het product verrijkt is met ontwikkelde en geteste functies zoals beschreven in de Sprint Backlog. Een team bestaat vaak uit 5 tot 9 mensen met verschillende expertises als designers, modellers, programmeurs en testers.
De gebruikers
Het product wordt voor iemand gebouwd (als niemand het zou gebruiken, zou het dan gemaakt worden?). Het is belangrijk te weten dat de gebruikers geen actieve rol binnen scrum vervullen. Er kan enkel ‘rekening mee worden gehouden’. Zij voeren belangrijke feedback aan voor het team over de ontwikkelde software en zorgen voor een zekere kwaliteitsborging.
De uitvoering
Bij scrum draait alles om Sprints. Het hiernaast afgebeelde schema uitgelegd per onderdeel:
- Product Backlog
- Sprint Planning
- Sprint Backlog
- Sprint
- Scrum meeting
- Shippable code
- Retrospect
Een lijst met functieomschrijvingen van een product.
Een planning wordt gemaakt voor een nieuwe sprint, en bepaald de inhoud van de Sprint Backlog.
Hierin staat tot in detail beschreven wat de functies zijn die aan het einde van de Sprint af moeten zijn.
Een periode van werk die ligt tussen de 15 en 30 dagen.
Dagelijkse bijeenkomsten van het hele team om voortgang in kaart te brengen en obstakels duidelijk te maken.
Het doel van iedere Sprint: bruikbare, geteste functies afleveren voor het product.
Een reflectiesessie met iedereen uit het team om te bekijken wat goed en wat niet goed ging in de afgelopen Sprint.
Na de reflectie begint de cyclus weer van voren door in een Sprint planning na te gaan welke onderdelen uit de Product Backlog deze keer zullen worden gerealiseerd tot bruikbare functies.
De dagelijkse meeting
Iedere dag komt het hele team bij elkaar om te bespreken hoe het gaat en waar we staan in ontwikkeling. Deze meetings worden geleid door de facilitator, beginnen op een vast tijdstip aan het begin van de dag, en duren niet langer dan 20 minuten.
Tijdens de meeting beantwoord ieder lid van de groep drie vragen, en richt de antwoorden naar de groep, en niet naar de facilitator!
- Wat heb ik sinds de laatste scrum meeting gedaan?
- Wat ga ik tot aan de volgende scrum meeting doen?
- Zijn er nog problemen waar ik tegenaan loop?
Door dagelijke meetings te houden met iedereen is snel duidelijk hoe ver de ontwikkelingen zijn. Als alles goed gaat zal dat snel genoeg blijken uit de gesprekken. Aan de andere kant, als er problemen optreden zullen ze niet onopgemerkt blijven en kan er door de facilitator snel op ingesprongen worden.
Het is aan te bevelen discussies tussen één of twee teamleden, of die langer dan een paar minuten duren, buiten de meeting te plannen. Houd de meetings staand, mensen houden meestal niet van meer dan 15 minuten te staan. Zo houd je meetings kort en bondig.
De reflectie
Aan het einde van iedere Sprint wordt een reflectie ingepland. Deze duren doorgaans een uur en het hele team is hierbij betrokken. Het doel hiervan is om voor het team duidelijk te maken wat er goed en wat er fout ging. Tevens is er ruimte om te bespreken wat meegenomen kan worden in de volgende Sprint planning aan functies die het team tijdens deze Sprint vonden ontbreken.
Het kan soms moeilijk zijn om de focus te houden op het onderwerp, omdat emoties hoog kunnen oplopen. Om dit op te kunnen vangen zou je als facilitator kunnen stellen dat iedereen 2 of 3 plus- en 2 of 3 minpunten meeneemt naar de reflectie. Op deze manier houd je het binnen het kader.
Bijhouden van het proces
Een vaak gezien statement van een projectgroep is “we zijn voor 75% klaar”. Dit soort vage percentages hebben projectmanagers en opdrachtgevers vaak een hekel aan. Ze kunnen er niets mee. Hoe zwaar gaan de laatste 5% worden? Bij scrum heb je een soort binaire zekerheid: aan het einde van een Sprint heb je bruikbare software afgeleverd, of je hebt het niet. Er is geen middenweg, en dat geeft duidelijkheid.
Om tijdens een Sprint toch een idee te krijgen hoe ver de ontwikkelingen zijn, gebruikt men vaak een burndown chart. Deze dagelijks bij te werken weergave laat per dag zien hoeveel uur er nog resterend zijn om het einddoel te behalen. De chart dient bij de dagelijkse meeting aanwezig te zijn en verder toegankelijk te zijn op ieder moment, door iedereen.
Stel een project wordt in het begin op 200 uur aan werk geschat, en de Sprints duren 14 dagen. In een ideale situatie betekent dit dat er per dag ongeveer 20 uur aan werk wordt verzet.
Mochten dingen niet zo ideaal gaan als geplant, dan kan dit aan de burndown chart worden afgelezen, en kan het team snel ingrijpen.
Ter aanvulling op dit schema wordt vaak gewerkt met een visuele Sprint Backlog, waarbij de schematische indeling kan verschillen. Bij het Dunamare project gaan wij het volgende hanteren:
In dit systeem wordt gewerkt met taken op post-it notes. Op die manier kan een taak gemakkelijk door het proces heen bewegen. Wanneer een taak gereed is voor een volgende stap, wordt hij verplaatst en weer opgeplakt.
Links komen alle taken te staan, hoe klein ook. Hierbij worden ze per categorie ingedeeld, zodat iedere groep kan zien waar ze heen moeten voor nieuwe taken.
In het midden, het grootste stuk, staan alle taken die op dit moment in behandeling zijn. De cijfers aan de kant staan voor het aantal uren resterend voor een taak. Een taak kan maximaal 16 uren (2 hele werkdagen) in beslag nemen. Is een taak omvangrijker dan dat, dan is hij niet goed genoeg in stukken gehakt. Het is dus belangrijk om taken op te breken zodat ze behapbaar zijn en het einde altijd snel in zicht is.
Is een taak eenmaal klaar, dan verhuist hij naar Done. Daar komt hij weer bij de respectivelijke groep te staan om door anderen opgemerkt te worden.
Waarom scrum werkt
Scrum is een principe dat, na enige bestudering, makkelijk te implementeren is. De middelen om het te organiseren zijn in elke omgeving te vinden. Hoewel gespecialiseerde software voor scrum geschreven is, volstaat een whiteboard heel prima met wat post-it notes erop. Sterker nog, het wordt aangeraden een fysieke vorm te kiezen, sinds dit het groepsproces ten goede komt.
Scrum zorgt ervoor dat stress op een laag niveau blijft. In traditionele omgevingen zie je vaak dat de spanningen en onduidelijkheden zich opstapelen naarmate men verder komt. Bij scrum worden die stressfactoren tot een minimum beperkt door o.a. de dagelijkse ontmoetingen en de snelle cyclus van een Sprint. Hierdoor weet het team constant hoe de ontwikkelingen gaan en kunnen problemen snel opgelost worden.
Een veel gedachte fout bij het scrum principe is dat men denkt dat het succes ligt in de korte iteraties van Sprints. Het gaat bij scrum in essentie om de samenwerking tussen partijen. Als designers niet samenwerken met programmeurs om een klus te klaren, zal nooit het doel behaald worden. Een snelle opvolging van Sprints, de dagelijkse meetings en de reflecties zorgen er alleen maar voor dat die samenwerking zo optimaal mogelijk is. Scrum zorgt met deze constante ‘awareness’ ook voor verantwoordelijkheid. Als iemand heeft aangegeven een model af te hebben in 12 uur, en dat vervolgens niet heeft, kan een programmeur in de problemen komen omdat die het model in het spel wilde verwerken. Door dit soort problemen in de dagelijkse meeting te bespreken, komen obstakels snel aan het licht en door de persoon er direct op aan te spreken zorgt de groep er zelf voor de planning te handhaven.
Tips
- Ga je voor het eerst een scrum opzetten, zorg dan dat je klein begint. Stel niet gelijk te hogen eisen aan je teamleden, geef ze tijd om te wennen aan het nieuwe werkprincipe.
- Sommige groepen of organisaties zijn er aan gewend om 10 weken of een half jaar aaneen te werken. Dan kunnen miniprojectjes van een paar weken op weerstand rekenen. Probeer dan eerst Sprints van een maand, en kijk of dat werkt. Houd het echter wel consistent, en ga niet halverwege overschakelen op 14 dagen Sprints als het goed lijkt te gaan. Dit breekt het ritme.
Zie ook de volgende websites voor meer informatie over scrum:
