Hoofdstuk 1: Wat Scrum is en hoe het werkt

In dit hoofdstuk:

Scrum en Agile

Drie rollen in Scrum

Twee lijsten en vier meetings

Scrum is een manier om in teams heel effectief werk te verrichten. Werk dat te complex is om op de automatische piloot te kunnen doen. En dat geldt voor heel veel van onze werkzaamheden. Scrum stuurt constant op effectiviteit van werk. Scrum is ontstaan bij het ontwikkelen van software, maar is ook in andere situaties zeer bruikbaar.

Scrum en Agile

Scrum is in 1995 ontworpen door Jeff Sutherland en Ken Schwaber. Zij onderzochten welke principes ten grondslag liggen aan projecten die zeer succesvol zijn geweest. Die principes zijn tevens de basis voor Scrum. Scrum geeft een klein aantal krachtige regels mee die vastigheid bieden in situaties waar geen simpele oplossing voorhanden is. Situaties waarin de creativiteit, betrokkenheid en samenwerking van teams nodig is om snel tot een steeds betere oplossing te komen. Bijna al ons werk dus.

Scrum benadrukt het feit dat nieuwe inzichten altijd optreden zodra je eenmaal aan de slag bent, en dat je als team wendbaar wilt zijn om de beste inzichten in je voordeel te kunnen gebruiken. Scrum is de meest populaire Agile methode. Agile is het gedachtegoed waarbij de nadruk ligt op wendbaarheid, vastgelegd in het ‘Agile Manifesto’.

Scrum heeft maar een paar regels, die allemaal zo op een paar bladzijden passen. (Waarom dan een heel boek?) Scrum kent twee lijsten, drie rollen en vier bijeenkomsten. Dat is alles! Scrum is simpel. Net zo simpel als schaken. Makkelijk uit te leggen, best moeilijk om te winnen. Da’s logisch.

Scrum is bewust klein gehouden. Dat maakt allereerst dat het breed toepasbaar is. Bovendien is het ook eenvoudig te onthouden, maar misschien wel het belangrijkste: het zorgt ervoor dat je altijd zelf moet blijven nadenken. Immers, Scrum schrijft zo weinig voor dat je zelf moet kiezen hoe je Scrum toepast in een specifieke situatie. Dat is tegelijkertijd misschien ook wel het grootste nadeel: Scrum is niet het antwoord op al je problemen, het schrijft niet voor wat je in iedere situatie moet doen. Scrum is dan ook geen ‘methode’ die stap voor stap voorschrijft wat te doen. Scrum is een raamwerk. Een raamwerk dat je helpt snel te ontdekken wat je moet doen.

Als je de principes of regels van Scrum goed volgt, krijg je heel snel heel veel inzicht en word je met de neus op de feiten gedrukt. Scrum is het ultieme proces om alle mogelijkheden én onmogelijkheden zichtbaar te maken, om daarmee het beste uit teams naar boven te halen. De Scrum regels schrijven voor dat je alles transparant en zichtbaar maakt, van werkvoorraad tot afspraken, van resultaten tot samenwerking, van planning tot voortgang.

Scrum ‘dwingt’ teams om de belangrijkste zaken eerst op te pakken, en dat gebaseerd op concrete zichtbare doelen, waar mensen wat aan hebben. Scrum zorgt er bovendien voor dat je dit lang kunt volhouden, door een vast ritme en een hele duidelijke nadruk op kwaliteit.

Hoe werkt Scrum?

Scrum werkt met iteraties. Een iteratie is een korte periode van een paar weken die tot een resultaat leidt (meestal een product) dat ook écht af is. Zo’n iteratie wordt een sprint genoemd. Iedere sprint levert iets echts op. In Scrum termen zeggen we dat een iteratie als resultaat heeft: ‘A potentially shippable product increment.’ Oftewel: een deel van de oplossing dat (hoe klein ook) al goed genoeg is om uitgeleverd en gebruikt te worden. Ja, je leest het goed: uitgeleverd aan klanten, gebruikers. Echte mensen. En dus is het gedocumenteerd, getest, geïntegreerd enzovoort. Niets hoeft meer gedaan te worden. Het bevat misschien nog niet voldoende functionaliteit om daadwerkelijk uit te leveren, maar het zou kunnen.

Een sprint levert iets echts op; dat betekent dat als je software ontwikkelt, je productierijpe software oplevert. Mocht je met Scrum een nieuwe fiets bouwen, dan levert iedere sprint een fiets of fietsonderdelen op. Niet alleen maar ontwerpen of documentatie. Scrum dwingt je om zaken af te maken zodat je feedback krijgt op echte producten. Dat is natuurlijk ultiem risicomanagement.

Gebruik liever korte dan lange sprints. Hoe korter de sprint, hoe eerder waarde wordt geleverd, en hoe sneller je leert en kunt bijsturen op feedback. De oorspronkelijke Scrum literatuur spreekt over sprints van maximaal één maand. Tegenwoordig gebruiken de meeste teams sprints van twee à drie weken, maar ook één week is niet ongebruikelijk. Korte sprints geven je de mogelijkheid om vaak bij te sturen, eerder op feedback te reageren en sneller beter te worden.

Drie rollen

De Product Owner is de eerste van de drie rollen in Scrum. De Product Owner is verantwoordelijk voor het ‘wat’ en vertegenwoordigt alle belanghebbenden. Wat gaan we maken? Hoeveel mag het kosten? En wanneer is het klaar? Hij of zij is degene die bepaalt of iets daadwerkelijk voldoende functionaliteit bevat om in productie te kunnen worden genomen.

Om dit alles goed te kunnen bepalen is het essentieel dat de Product Owner ook het ‘waarom’ kan verwoorden. Immers, waarde zit zelden in het ‘wat’ alleen. De Product Owner vertegenwoordigt alle belanghebbenden, die we in Scrum meestal stakeholders noemen. Met de kennis van al die stakeholders, en van hun belangen, sorteert de Product Owner de Product Backlog. Dat is de primaire verantwoordelijkheid van de Product Owner: zorgen dat er een goede Product Backlog is en deze prioriteren op waarde.

Het eigenlijke werk wordt gedaan door het team, ook wel Development Team genoemd. De mensen die het werk ook daadwerkelijk doen. Een Development Team, en dus ook ieder teamlid, is volledig toegewijd. Het team werkt samen om de doelen die door de Product Owner zijn gesteld te halen, sprint na sprint. Het team bepaalt zelf hoe ze dat doen, en dus ook wie wat doet, en geeft zelf schattingen af. Niemand vertelt het team hoe ze de gestelde doelen moet behalen, en dus ook niet hoe lang ze over een bepaalde taak of feature mogen doen. Eigen verantwoordelijkheid voor je eigen werk. Deze vorm van zelfsturing is een belangrijke motivatie waardoor iedereen in een team zo enthousiast is over Scrum.

Mag het team dan zelf bepalen hoe lang het duurt voordat het product klaar is? Nee, natuurlijk niet. Dat bepaalt de Product Owner, die immers beslist welke features in welke volgorde worden opgepakt. Als de schattingen van het team tegenvallen, is er altijd een discussie om te kijken of het anders kan, en zal iedereen naar een oplossing zoeken. Wel is het product increment ‘af’ aan het einde van elke sprint. De Product Owner kan dus na elke sprint beslissen om het wel of niet uit te leveren, oftewel te releasen. Releasen wordt daarmee een tactische of strategische afweging, maar geen operationele. Het product is namelijk altijd ‘releasable’.

De Scrum Master is ervoor om te zorgen dat Scrum goed wordt toegepast. Oftewel: de Scrum Master zorgt ervoor dat de spelregels in acht worden genomen. De Scrum Master is als olie in de machine, en zorgt ervoor dat alles zo soepel mogelijk draait. Belemmeringen die het team ondervindt worden door hem of haar uit de weg geruimd. Ook legt de Scrum Master Scrum en de consequenties van het gebruik ervan aan alle betrokkenen uit. Dus ook aan het management. Hij of zij is proactief naar buiten toe en faciliterend voor het team en de Product Owner. Zo kan een Scrum Master helpen bij het organiseren van de bijeenkomsten, zaken regelen voor het team en de Product Owner bijstaan bij het formuleren van de eisen en wensen.

Iedereen in Scrum is volledig toegewijd. Niet alleen in gedachten, maar ook in levenden lijve, vijf dagen per week. In Scrum werk je aan één project tegelijk. Via één Product Backlog, die wordt beheerd door één Product Owner. Dat geeft veel duidelijkheid: met z’n allen aan één ding tegelijk werken dat de meeste waarde heeft én dat ook nog eens echt afmaken.

In Scrum werk je met een vast team, genaamd het Scrum team. Dit Scrum team bestaat uit de Product Owner, de Scrum Master en het Development Team. Met zijn allen werk je aan een en hetzelfde doel: zo snel mogelijk een (deel)product maken dat de meeste waarde toevoegt en mensen blij maakt. Je zult begrijpen dat als zo’n team lekker samenwerkt en steeds beter wordt, je het dan ook liever niet uit elkaar haalt.

De terminologie in Scrum is soms verwarrend. Met ‘Scrum team’ wordt iedereen bedoeld: Product Owner, Scrum Master en Development Team. Dit Development Team wordt ook in het kort vaak ‘team’ genoemd. Als we in dit boek ergens ‘team’ gebruiken dan bedoelen we het Development Team. Als we het over iedereen hebben dan gebruiken we de expliciete term: Scrum team.

Is dit alles? Is er geen projectmanager meer? Nee dus. Scrum is fundamenteel anders in de zin dat we liever iemand hebben die eigenaar wordt van het product, dan manager van het project. Subtiel verschil misschien, maar fundamenteel. Alle traditionele werkzaamheden van een projectmanager bestaan nog, maar zijn verdeeld over de drie rollen.

Twee lijsten

Alle wensen en eisen die het product beschrijven worden bijgehouden op een lijst: de Product Backlog. Deze lijst wordt door de Product Owner beheerd, en is altijd gesorteerd op waarde voor de business, en voorzien van schattingen door het team. Voortgang van de realisatie van het product of de release wordt door de Product Owner bijgehouden in een Release Burndown Chart.

Bij iedere sprint wordt het bovenste deel van de Product Backlog verplaatst naar de Sprint Backlog die door het team in kleinere delen wordt gesplitst om het werk gedurende de sprint te kunnen verdelen en de voortgang te kunnen volgen. Hierbij houdt het team ook een Sprint Burndown Chart bij.

Dus twee Burndown Charts? Yep, één per sprint van het team, één per release voor de Product Owner.

Vier meetings

Er zijn vier meetings in iedere sprint. Het zijn allemaal ‘timeboxen’. Oftewel: van tevoren is een maximale hoeveelheid tijd voor de meeting gereserveerd, daar wordt nooit overheen gegaan. Eerder klaar zijn is mooi. Als vuistregel duurt een meeting niet langer dan twee uur voor een sprint van twee weken.

De eerste meeting aan het begin van een sprint is de Sprint Planning. Die bestaat uit twee delen: het eerste deel dient om te bepalen welke items in deze sprint worden opgepakt en wat er opgeleverd kan worden. Het tweede deel is ervoor om te kijken hoe het werk kan worden opgesplitst en om te bepalen wat er door het team kan worden opgeleverd aan het eind van de sprint.

Aan het begin van iedere dag houdt het team een werkoverleg, kort en staand. Tijdens deze Daily Scrum praat het team over de invulling van de dag, en hoe er wordt samengewerkt. Het is geen rapportage aan wie dan ook. Wel is de meeting openbaar zodat iedereen kan meeluisteren.

Aan het eind van de sprint wordt het werk door het team aan de Product Owner en de stakeholders getoond, met als doel om feedback te krijgen. Deze meeting wordt vaak de ‘demo’ genoemd, maar dat doet de meeting tekort. De demo is het middel, het doel is feedback. De meeting heet dan ook Sprint Review.

Uiteindelijk trekt het team zich terug voor een laatste meeting: de Sprint Retrospective. Hier kijkt het team terug naar de afgelopen periode, en kijkt hoe ze zichzelf kan verbeteren. Het benoemt de zaken die goed gaan, en bespreekt de zaken die beter kunnen. Het team onderzoekt de oorzaken en oplossingen, en maakt afspraken over te ondernemen acties.

Zo, dat was het! Vragen?