De kracht van Scrum (samenvatting)

Wat is Scrum? Dat wordt erg leuk uitgelegd in het boekje "De kracht van Scrum", dat is geschreven in roman-vorm. Ik heb het boekje gelezen ter voorbereiding op een Lean-Scrum training die ik heb verzorgd bij een ICT productie- en beheerafdeling van een zakelijk dienstverlener. De auteurs, Rini van Sollingen en Eelco Restenburg, geven voorafgaand aan het verhaal aan dat Scrum is ontstaan in de Software-industrie en dat het gebaseerd is op de ontwikkelingen rondom Lean Management. Voor een groot deel is Scrum "oude wijn in nieuwe zakken". Net zoals bij Lean, staat bij Scrum de klant centraal. Voor de klant wil jouw team waarde creëren op een snelle en efficiënte wijze. Daarom is het plannen van het werk dat gedaan moet worden voor de klant een belangrijk onderdeel van Scrum, niet alleen een deadline-planning maar ook een capaciteitsplanning. Natuurlijk staat werkplezier ook centraal binnen Scrum. Geen klant wordt naar tevredenheid en op een efficiente wijze geholpen wanneer die klant niet bediend wordt door bekwaam gemotiveerde medewerkers. Medewerkers bepalen daarom zelf hoe ze het werk willen doen, net zoals bij Lean. Zelfsturende teams hoort bij Scrum.


Gedonder met oplevering van een product aan de klant 
Het verhaal start in New York. Mart Verhulst, CTO bij een softwareproductiebedrijf, is op bezoek geweest bij LogiStrux, een klant. Een ontevreden klant, want de afspraak om de toegezegde software op te leveren is al een paar keer niet nagekomen. Ook nu moest Mart weer melden dat de releasedatum niet gehaald kan worden en drie maanden verschoven moet worden. Ze leveren dus niet op tijd, ook niet binnen budget en een boze klant. Vervolgens mist Mart ook nog eens zijn vliegtuig, zodat hij nog een nacht extra in New York moet verblijven. Aan de hotelbar ontmoet Mart een Fin genaamd Pekka. Die heeft een lezing gehouden over het toepassen van Scrum in de Finse industrie op een Agile Conference. (Agile is lenig/ wendbaar. Het betreft een filosofie die nagenoeg gelijk is aan Lean). Pekka legt Mart uit dat je met Scrum sneller kan leveren, maar dat het vergroten van je flexibiliteit de kern is. Lenig software ontwikkelen.


Lenig software ontwikkelen: klein en snel i.p.v. groot en langzaam
De essentie van Scrum is dat je altijd openstaat om op basis van nieuwe inzichten van je klant, of je eigen organisatie, je prioriteiten en dus ook je product aan te passen. Door via een korte voorspelbare ontwikkelcyclus (Sprints genaamd) van bijvoorbeeld 2 weken steeds weer toe te werken naar een werkend 'klein' product, in plaats van bijvoorbeeld na anderhalf jaar in 1 keer een niet-werkend 'heel groot' product op te leveren. Net als bij Lean wil men bij Scrum 'het klein houden', zodat je snel en lenig bent. Toyota wilde bijvoorbeeld niet 10.000 auto's van hetzelfde model achter elkaar bouwen, maar 1 auto van het ene model kunnen produceren en dan weer 1 auto van een ander model kunnen produceren. (Een seriegrootte van 1 is het ideaal) Omdat je dan op de klantvraag kan reageren. Omdat je dan flexibel bent. Ook in de bouwwereld wil men de projecten "kleiner maken". Projecten zijn dan beter te managen, de doorlooptijd wordt korter en je krijgt sneller feedback van klanten zodat je sneller kan verbeteren. Klik hier voor het artikel over lean bouwen. Bij Scrum wil men ook veel en snel feedback van de klant op dat 'kleine' opgeleverde product, zodat je kan verbeteren en dezelfde fouten niet nog eens maakt in de rest van de producten. Echt samenwerken met de klant is daarom essentieel, legt Pekka aan Mart uit.

De klant/ product owner
De klant moet gedurende de sprint veelvuldig contact hebben met de ontwikkelaars/ het team. De ontwikkelaars moeten namelijk steeds aan de klant kunnen vragen wat die wil. En dan wordt aan de klant niet een technische specificatie gevraagd (bijvoorbeeld, wil je hier een knop of daar?), maar een functionele specificatie (bijvoorbeeld, wat wil je ermee doen?). De klant moet dus ook tijd investeren, geeft Pekka aan. Als die dat niet wil, dan moet de klant zich afvragen of het softwareproduct wel belangrijk voor hem is. Als dat niet echt belangrijk is, moet je het niet doen! Wanneer je een generiek product maakt (niet specifiek voor 1 klant), kan iemand van de eigen organisatie de klantrol op zich nemen. In Scrum-termen heet zo iemand dan 'Product owner'. Volgens Pekka bepaalt een product owner het "waarom & wat". Het team bepaalt "het hoe". Een product owner is verantwoordelijk de beschrijving van wat er gemaakt moet worden, de zogenaamde product backlog. De product backlog is ook geprioriteerd. Datgene wat voor de klant de meeste waarde toevoegt ligt boven op de stapel, datgene wat daarna het meest belangrijk is ligt als tweede etc. 

Product backlog en sprint backlog
Op de product backlog staat dus in volgorde van waarde voor de klant wat er gedaan moet worden. (het wat, waarom en voor wie) De product backlog kan opgesteld worden op basis van user stories. Een user story is een gebruikersverhaal waarin beschreven staat wat de klant waarom wil. Als een team weer aan een nieuwe productieperiode gaat beginnen, een sprint, moet de product backlog vertaald worden naar een sprint backlog. (het hoe) Het productieteam schat per item op de product backlog in, hoeveel uur werk het is. Aangezien je weet hoelang je productieperiode/ sprint is (bijvoorbeeld 2 weken) en aangezien je weet hoeveel productiecapaciteit je in die periode hebt (ontwikkelaars), kun je berekenen welke items op de product backlog je op kan nemen in de sprint backlog (productieplanning). Zo'n sprint backlog staat vervolgens vast, legt Pekka uit. Daar mag je tijdens een sprint niets fundamenteel meer aan veranderen, zeker niks meer bijzetten. 

Het team en de scrum master
Het team bepaalt vervolgens hoe het product, dat op de sprint backlog staat, geproduceerd gaat worden. Niet een projectmanager (want die is er niet bij Scrum), niet een product owner, niet een manager. Nee, het team bepaalt hoe er gewerkt gaat worden. Je hebt wel iemand nodig die het project ondersteunt en "de olie vormt in de productiemotor". Bij Scrum noemen we zo iemand de 'Scrum master', geeft Pekka aan. Pekka leidt ook gecertificeerde Scrum masters op! :)


Het Scrum proces
Ontwikkelaars zijn slimme, eigenwijze professionals. Laat ze zelf bepalen hoe ze iets produceren. Scrum is een aanpak die ontwikkeld is om kenniswerkers optimaal te laten leren binnen hun proces. Opgelegde werkprocessen zorgen voor verlamming van de team-verantwoordelijkheid en dus ook van hun commitment. Het zelf-managen door het team zit grotendeels verankerd in het scrum proces. De momenten van overleg/ discussie staan ingepland, daarbuiten wordt doelgericht gewerkt aan het product. Bovendien werkt Scrum met kleine teams, zeven mensen plus/ minus twee. Dan kunnen de teamleden bij elkaar in 1 ruimte zitten en zijn de communicatielijnen kort.  

Sprint planning
Een sprint (productierun) begint met een Sprint Planning Meeting. De product owner presenteert de product backlog aan de teamleden. Die vertalen het vervolgens naar een sprint backlog met concrete onafhankelijke taken, zogenaamde work items. Een work item is bijvoorbeeld 2 tot 4 uur werk. Teamleden schatten met elkaar in hoeveel tijd een work item gaat vergen. Daarvoor zou je Planning Poker kunnen gebruiken. Er moet in ieder geval een soort voorcalculatie van het werk gemaakt worden.

Het meest essentiële van de Sprint planning is dat het team een opdeling van het werk maakt (in work items) die volgens hen haalbaar is. Ze zullen daarom nooit met een planning werken die op voorhand al niet haalbaar is. Het team plant dus zelf! Pekka helpt de medewerkers van LogiStrux daar de eerste keer bij. De planning en de voortgang van het werk wordt vervolgens zichtbaar gemaakt op het Scrum-bord. Het Scrum-bord van het Scrum-team is een communicatiehulpmiddel. Middels het zichtbaar maken van de planning (voorcalculatie) en de voortgang (nacalculatie) op het bord is voor iedereen in 1 oogopslag te zien hoe de vlag erbij hangt. De voortgang kan ook zichtbaar gemaakt worden middels burn-down charts. Op een burn-down chart laat je visueel zien hoe snel je uren aan het " verbranden bent", in combinatie met de hoeveelheid werk die je daaruit wilde laten komen. Uiteraard is het wat mij betreft wenselijk om ook de doelstellingen van het team en de prestatie indicatoren zichtbaar te maken op het Scrum bord. Onderlinge afstemming binnen het team en eventueel tussen teams vindt vervolgens plaats bij het scrum-bord. Bijvoorbeeld middels een daily scrum.


Daily scrum of stand-up meeting
De Scrum master zorgt ervoor dat er aan het begin van elke dag een meeting wordt gehouden om het werk van het team af te stemmen. Deze meeting duurt zo'n 15 minuten en elk teamlid geeft aan 1. wat die heeft bereikt, 2. wat die gaat doen en 3. tegen welke problemen hij aanloopt. Zo'n meeting bevordert de communicatie tussen de teamleden. Teamleden praten zo met elkaar op een gestructureerde manier, met focus op vooruitgang en met communicatie naar elkaar toe over hun individuele obstakels. 

Sprint Retrospective
"Als de sprint voorbij is, gaan we die evalueren", legt Pekka uit aan het Scrumteam van LogiStrux. Dat gebeurt op de laatste dag van de sprint tijdens de Sprint Retrospective. Daarin wordt geëvalueerd of alle werk items klaar zijn. Maar wanneer is iets klaar? Daarvoor wordt de Definition of done gebruikt (DoD). De DoD is een checklist met criteria die aangeven wanneer het product af is. Die criteria kunnen bijvoorbeeld zijn: 1. getest, 2. voldoet aan codestandaard, 3. manual aangepast etc. Tevens wordt geëvalueerd hoe het team gefunctioneerd heeft en kijkt het team hoe het zichzelf kan verbeteren! Men benoemt zaken die goed gaan, en bespreekt zaken die beter kunnen in volgende sprints. Het team verbetert dus hun eigen proces, en dat vraagt openheid en onderling respect, geeft Pekka aan. Het gaat nooit om het individu, maar om het proces. Voor de toekomst kan het team een SMART doelstelling formuleren, bijvoorbeeld "in de volgende sprint gaan we de doorlooptijd met 50% verkorten of de velocity verdubbelen" . 

End of sprint meeting
Ten slotte, in de end-of-sprint meeting wordt een live-demonstratie van het product gegeven en wordt getoetst of het voldoet aan de Definition of done. De demo is bedoeld om de voortgang te bewijzen aan de hand van echt werkende software. Aan het eind van de demo verleent de product owner decharge aan het team, zodat ze een nieuwe Sprint op kunnen gaan starten. 


Joe Justice (mooie naam) legt in bovenstaande TED-talk uit hoe een team met Agile, Lean en Scrum de doorlooptijd van het ontwikkelen van een nieuwe auto drastische kon verkorten.

Hoe liep het af met LogiStrux en Pekka?
En hoe liep het af met LogiStrux en Pekka? Nou, Pekka was een externe. Dus die ging na enkele maanden weer bij LogiStrux weg. Zijn taak zat er op. De Scrum teams binnen LogiStrux konden zichzelf redden. Wil je meer weten? Lees dan het boekje van Rini van Solingen en Eelco Rustenburg. En neem ook gerust contact met mij op!

Gosse Korte: LinkedIN


Zoektermen: "Lean scrum", scrum+lean, lean+agile+scrum, "scrum agile", scrum+lean, lean+scrum, "scrum lean", "agile scrum", "gosse korte", "gj korte"

Reacties

Charlotte zei…
Scrum passen wij al een tijdje toe binnen ons bedrijf. Wij stellen dan ook onze klant centraal.

Populaire posts van deze blog

GAP-model of Servqual-model: klantverwachting overtreffen

Strategie slaat terug! Mintzberg, Ahlstrand, Lampel

Lean Management: doorlooptijd en bewerkingstijd