2. De rollen en het ritme van scrum
Agile zegt waar je heen wilt. Scrum zegt hoe je maandagochtend begint. Het is veruit de meest gebruikte invulling van het agile gedachtegoed, en het bestaat uit een handvol afspraken die je in een middag kunt uitleggen. Drie rollen, drie artefacten, vijf events. Wie die elf begrippen kent, kent scrum; wie ze ook werkelijk aanhoudt, heeft een team dat loopt.
Na dit hoofdstuk:
- Weet je wat scrum is, waar het vandaan komt en waarom het een raamwerk heet en geen methode.
- Ken je de drie pijlers transparantie, inspectie en aanpassing.
- Ken je de drie rollen, de drie artefacten en de vijf events, en kun je ze uit elkaar houden.
- Kun je uitleggen wat een Definition of Done is en waarom een team er een nodig heeft.
- Herken je de drie valkuilen waaraan je scrum-op-papier herkent.
Een raamwerk, geen methode
Scrum is een lichtgewicht raamwerk waarmee teams complexe producten ontwikkelen in korte, herhalende cycli. Het woord komt uit de rugbysport: een scrum is het moment waarop het hele team samen optrekt om de bal vooruit te krijgen. Jeff Sutherland en Ken Schwaber legden de aanpak in 1995 vast in de eerste Scrum Guide.
Het verschil tussen een raamwerk en een methode is belangrijk, ook op het examen. Scrum schrijft niet voor wat je bouwt, welke techniek je gebruikt of hoe je test. Het geeft je een ritme, een rolverdeling en een paar terugkerende momenten. De inhoud vul je zelf in, samen met je team en je opdrachtgever.
Onder scrum liggen drie pijlers die je in elke sprint terugziet. Transparantie: alles wat het werk beïnvloedt is zichtbaar voor iedereen die ermee te maken heeft, dus geen schaduwlijstjes. Inspectie: je bekijkt regelmatig wat je hebt gemaakt en hoe het loopt, niet één keer per kwartaal maar elke dag en elke sprint. Aanpassing: wat je bij die inspectie ziet, gebruik je om bij te sturen. Een afwijking is geen probleem, het is informatie. Samen vormen ze het empirische proces waar scrum op rust: je leert door te doen.
De drie rollen
Een scrum-team telt drie rollen. Niet meer, niet minder.
De Product Owner is de stem van de klant en de business binnen het team. Hij of zij bepaalt wat er gebouwd wordt en in welke volgorde, beheert de Product Backlog en zorgt dat het team weet waarom iets waardevol is. Eén persoon, geen commissie, anders verlies je daadkracht. Een Product Owner kiest wat waardevol is en laat het hoe aan het team over. En een Product Owner zonder mandaat is een doorgeefluik dat elke sprint vertraagt.
De Scrum Master is geen projectleider en geen baas, maar de coach van het team. De Scrum Master zorgt dat scrum goed wordt toegepast, ruimt obstakels op die het team tegenhouden en beschermt het team tegen verstoringen van buitenaf. Deelt geen taken uit en stelt geen deadlines.
Het Development Team doet het werk. Doorgaans drie tot negen personen, multidisciplinair: alle vaardigheden die nodig zijn om een werkend stuk product op te leveren zitten in het team. Geen aparte testers erbuiten, geen ontwerpers die later instappen. Het team is zelforganiserend, wat precies betekent dat het zelf bepaalt hoe het werk gedaan wordt. Het wat komt van de Product Owner via de backlog.
De drie artefacten
Artefacten zijn de tastbare informatiedragers waar het team mee werkt. Ze maken zichtbaar wat er moet gebeuren, wat er nu gebeurt en wat er is opgeleverd.
De Product Backlog is de complete, geprioriteerde lijst van alles wat ooit aan het product gedaan moet worden: functionaliteit, verbeteringen, bugfixes, technische taken. Bovenaan staat wat het belangrijkst is. De lijst is nooit af en verandert zodra je meer leert. De Product Owner is eigenaar.
De Sprint Backlog is het deel van de Product Backlog dat het team in de huidige sprint oppakt, plus een plan om die items op te leveren. Dit is het werkdocument van het Development Team zelf. Tijdens de sprint blijft hij actueel: items worden gesplitst, opnieuw geschat of bijgewerkt, zolang het sprintdoel maar overeind blijft.
Het Increment is het werkende stuk product dat aan het eind van de sprint klaar is. Echt werkend, getest en potentieel inzetbaar. Geen halffabricaat dat bijna klaar is. Elke sprint levert minstens één Increment op.
De vijf events
Scrum kent vijf vaste momenten. De eerste is de container waarbinnen de andere vier vallen.
De Sprint zelf duurt één tot vier weken en heeft binnen een team altijd dezelfde lengte; twee weken is het gangbaarst. Sprint Planning opent de sprint: de Product Owner licht de prioriteiten toe, het Development Team bepaalt hoeveel werk haalbaar is, en er ligt aan het eind een sprintdoel en een Sprint Backlog. De Daily Stand-up duurt maximaal vijftien minuten, elke werkdag op hetzelfde moment: wat heb ik gisteren gedaan, wat ga ik vandaag doen, waar loop ik tegenaan. Signaleren, niet oplossen. In de Sprint Review laat het team aan het eind van de sprint zien wat er gemaakt is; stakeholders geven feedback en die feedback gaat terug naar de Product Backlog. Geen PowerPoint maar een werksessie. En in de Sprint Retrospective, direct na de Review, kijkt het team naar zichzelf: wat ging goed, wat kan beter, welke concrete actie nemen we mee naar de volgende sprint.
Zo loopt de cyclus: uit de Product Backlog haalt het team tijdens de Sprint Planning de bovenste items. Die vormen de Sprint Backlog, die de hele sprint van het team zelf blijft. Aan het eind staat er een Increment dat aan de Definition of Done voldoet. In de Review komt daar feedback op, en die feedback belandt weer in de Product Backlog. Daarna begint het opnieuw.
De Definition of Done
De Definition of Done is een gezamenlijke afspraak van het team over wanneer werk echt af is. Denk aan: de code is getest, de documentatie is bijgewerkt, een collega heeft het nagekeken, en het staat op de acceptatieomgeving. Hij geldt voor alles wat het team oplevert, niet per item. Hang hem zichtbaar op, of pin hem bovenaan in je digitale board. Discussies over "is dit nu af?" verdwijnen dan vanzelf, en het Increment betekent voor iedereen hetzelfde.
Bij een verzekeraar werkt een team van zeven mensen aan een schadeportaal. De Definition of Done stond nergens, en bij elke Review ontstond dezelfde discussie: de Product Owner vond drie van de zeven items niet af, het team vond van wel. In de Retrospective van sprint 6 schreven ze er samen één op, met vier punten: getest door iemand anders dan de bouwer, foutmeldingen in het Nederlands, werkt op mobiel, en de handleiding is bijgewerkt. In sprint 7 nam het team vier items minder mee, want ineens bleek hoeveel werk er na het bouwen nog bij kwam. Vanaf sprint 9 lag de velocity weer op het oude niveau, maar leverde het team nu spullen op die de Product Owner zonder discussie accepteerde.
Drie valkuilen
Theorie is één ding, een scrum-team werkend krijgen is een ander. Drie valkuilen komen overal terug.
Een onduidelijk sprintdoel. Het team werkt aan losse items zonder gezamenlijk verhaal. Vraag een teamlid waar deze sprint over gaat en je krijgt een opsomming van tickets. Een sprintdoel hoort in één zin uit te leggen wat de sprint waardevol maakt.
De Scrum Master als projectleider. Zodra de Scrum Master taken uitdeelt, deadlines stelt of in de stand-up de status opneemt, is het team niet meer zelforganiserend. De Scrum Master neemt belemmeringen weg en bewaakt het proces, meer niet.
De sprint oprekken. "Eén weekje langer, dan halen we het wel." Daarmee verlies je het hele ritme én de betekenis van je velocity. Een sprint is een vaste timebox. Wat niet af is, gaat terug naar de Product Backlog en komt mogelijk volgende sprint terug.
De meest voorkomende fout is de Daily Stand-up gebruiken als statusvergadering voor de manager. Test het zo: praat iedereen tegen dezelfde persoon, of praten teamleden tegen elkaar? Bij het eerste is het een rapportage geworden, en dan kun je hem net zo goed afschaffen.
Een ontwikkelteam bij een groothandel merkt in de Retrospective dat de Daily Stand-ups uitlopen tot een half uur. Twee mensen bespreken elke ochtend hetzelfde technische probleem terwijl de andere vijf staan te wachten. De actie voor de volgende sprint: één teamlid neemt de rol van timekeeper en kapt elke discussie die langer duurt dan twee minuten af met "parkeren, na de stand-up". Twee sprints later zit de stand-up structureel op twaalf minuten, en blijven er gemiddeld twee mensen tien minuten napraten. Dat is precies wat de bedoeling was: het gesprek verdween niet, maar de andere vijf staan er niet meer bij.
Meerdere teams
Scrum is gemaakt voor één team. Werken er meerdere teams aan hetzelfde product, dan kom je raamwerken tegen als SAFe, LeSS en Nexus. Die bouwen voort op de scrum-basis en voegen coördinatie tussen teams toe. Voor het Foundation-examen is het genoeg dat je weet dat ze bestaan en waarvoor ze dienen; de principes eronder blijven hetzelfde.
Pak een team waar je bij betrokken bent, ook als daar geen scrum gedaan wordt.
- Kun je in één zin opschrijven wat het team de komende twee weken oplevert?
- Wie vervult de rol van Product Owner, wie die van Scrum Master? Zijn die rollen echt belegd, of doet iemand ze erbij?
- Welke van de vijf events worden structureel gehouden en welke worden geregeld overgeslagen? De Retrospective is de eerste die sneuvelt.
- Bestaat er een Definition of Done? Kan iedereen hem opnoemen?
Bespreek je antwoorden met een collega uit hetzelfde team. De kans is groot dat jullie beelden verschillen, en juist daar zit de winst.
Samenvatting
- Scrum is een raamwerk, geen methode: het geeft ritme, rollen en momenten, niet de inhoud.
- De drie pijlers zijn transparantie, inspectie en aanpassing.
- De drie rollen: Product Owner (wat en in welke volgorde), Scrum Master (coach en obstakels), Development Team (drie tot negen mensen, zelforganiserend).
- De drie artefacten: Product Backlog (alles wat ooit moet), Sprint Backlog (wat nu moet, van het team zelf) en Increment (wat af is).
- De vijf events: de Sprint als container, Sprint Planning, Daily Stand-up van maximaal vijftien minuten, Sprint Review en Sprint Retrospective.
- De Definition of Done is de gezamenlijke afspraak over wanneer werk af is, en geldt voor alles wat het team oplevert.
- Drie valkuilen: geen helder sprintdoel, een Scrum Master die stuurt, en een sprint die wordt opgerekt.
Halverwege de sprint vraagt een manager het Development Team om er even een klein extra verzoek bij te doen. Wat hoort de Scrum Master te doen?
Wie is eigenaar van de Sprint Backlog?
Aan het eind van de sprint is een item gebouwd, maar nog niet getest, terwijl testen in de Definition of Done staat. Wat gebeurt er met dat item?