Overbelasting: wanneer er te veel formaliteiten zijn

De kosten van een ceremonie bestaan niet alleen uit die vijftien minuten op de agenda. Het zijn die vijftien minuten, plus de twintig minuten die u vooraf nodig hebt om tot rust te komen en de twintig minuten die u achteraf nodig hebt om weer op gang te komen, vermenigvuldigd met het aantal aanwezigen in de zaal.

Overbelasting is de faalmodus die zich in het volle zicht verbergt, omdat elke afzonderlijke ceremonie op het eerste gezicht onbeduidend lijkt. Een stand-up van een kwartier, een uur planning, een uur retro. Wie zou daar bezwaar tegen kunnen hebben? Het probleem is dat ze niet één voor één plaatsvinden. Ze stapelen zich op, in een vast ritme, bovenop een werkdag waarin echt diepgaand werk in de tussenruimtes moet worden ingepast. In tegenstelling tot de andere drie vormen gaat het bij overbelasting niet om een vastgeroeste of uitgeholde ceremonie; zelfs een prima ceremonie kan er nog steeds één te veel zijn. Het is de enige vorm die u met rekenwerk kunt vaststellen.

De vergaderbelasting, eerlijk berekend

Reken het dus maar eens uit: de volledige stapel, niet alleen de dagelijkse stand-up. Een sprint van twee weken omvat doorgaans twee tot vier uur sprintplanning, een uur of twee aan evaluatie, een uur of twee aan retrospectieve, een of twee verfijningssessies en een dagelijkse stand-up van vijftien minuten, wat neerkomt op nog eens tweeënhalf uur verspreid over tien dagen. Tel dit bij elkaar op en u komt uit op bijna een volledige werkdag per ontwikkelaar, elke sprint, nog voordat er ook maar één regel code is geschreven. Beoefenaars berekenen dit in manuren, omdat dat de eenheid is die het management begrijpt: een stand-up van vijftien minuten voor een team van twaalf personen is geen vijftien minuten, maar drie manuren die elke dag verloren gaan. Tel daar vervolgens het deel bij op dat de agenda nooit laat zien (het afronden van de werkzaamheden vóór elk van die onderbrekingen en het weer op gang komen daarna), en een vijfde van de werkweek is een voorzichtige schatting – precies de overhead die professionals steeds weer rapporteren.

Dat is niet per definitie verkeerd. Coördinatie heeft daadwerkelijke waarde, en drie goed besteedde manuren kunnen verderop in het proces veel meer besparen. Maar het is een last, en de terechte vraag bij elke last is wat u ervoor terugkrijgt. Een team dat niet kan wijzen op een genomen beslissing, een botsing die is voorkomen of een obstakel dat is weggenomen als gevolg van een ceremonie, betaalt de last voor niets. De overhead is alleen te rechtvaardigen wanneer het rendement concreet benoembaar is.

De contextwisseling is pas echt de kostenpost

De kalender onderschat de kosten echter, omdat de vergadering zelf het goedkope deel is. Het dure deel is de contextwisseling aan beide kanten. Een ontwikkelaar die diep in een probleem zit, teleporteert niet heen en weer naar de stand-up. Hij komt even boven water, verliest het mentale model dat hij had opgebouwd en besteedt de eerste tijd daarna aan het opnieuw opbouwen ervan. Beoefenaars beschrijven de ochtendstand-up als een middel om de dag op gang te brengen: het werk begint pas echt als deze voorbij is, dus het hele uur voorafgaand aan de stand-up wordt als verloren beschouwd. De vijftien minuten zijn de catalogusprijs; de contextwisseling is de rekening.

Daarom is wanneer een bijeenkomst plaatsvindt net zo belangrijk als hoe lang deze duurt. Een stand-up halverwege de ochtend onderbreekt de werkstroom van een maker tweemaal; dezelfde stand-up op een natuurlijk tijdstip kost slechts een fractie daarvan. En dit is het sterkste argument om de status volledig los te koppelen van de synchrone klok: als de eigenlijke taak van de dagelijkse stand-up het weergeven van de status is – informatie die de tools al bevatten – dan verwijdert een asynchrone stand-up de onderbreking zonder dat de informatie verloren gaat, en zorgt een korte live-synchronisatie een paar keer per week voor de menselijke coördinatie die de asynchrone thread niet kan bieden. Ons hoofdstuk hoe u een dagelijkse stand-up organiseert behandelt het beschermen van de werkdag van de maker, ongeacht het ritme dat u kiest.

Cadansbelasting: de valkuil van de korte sprint

Dan is er nog de factor waarmee niemand rekening houdt: de duur van de sprint. Elke ceremonie die „één keer per sprint“ plaatsvindt, vindt bij een sprint van één week twee keer zo vaak plaats als bij een sprint van twee weken. Halveert u de sprint, dan verdubbelen de planningssessies, de evaluaties en de retrospectieven, maar het werk dat daartussen moet worden verricht, wordt niet gehalveerd, waardoor de verhouding tussen ceremonie en werk enorm toeneemt. Teams die sprints van één week doen, omschrijven dit ronduit als slecht: elke week een planningssessie en een retro, waarbij de reflectie vaak weinig oplevert omdat een week niet lang genoeg is om iets nieuws te hebben geleerd.

De oplossing is om cadans niet langer als één enkele variabele te beschouwen. De lengte van sprints, de frequentie van stand-upvergaderingen en de frequentie van retrospectieven hoeven niet synchroon te lopen. Een team dat wekelijkse retrospectieven zinloos vindt, kan de retrospective om de twee of drie sprints houden zonder dat dit ten koste gaat van de kwaliteit. Reflectie heeft zijn eigen natuurlijke ritme, en door dit te versnellen voordat het team voldoende lessen heeft verzameld, creëert men alleen maar de ‘afvink-retrospectieve’ uit het hoofdstuk Prestaties. Stem elke ceremonie af op het interval waarin deze daadwerkelijk iets oplevert.

Wanneer de modus „Overload” de andere modi versterkt

Overbelasting komt zelden op zichzelf voor. In “Flaccid Scrum” van Martin Fowler wordt de situatie beschreven waarin een team weliswaar alle rituelen uitvoert, maar de onderliggende technische discipline verwaarloost, waardoor het de volledige ‘vergaderlast’ draagt zonder enig voordeel te behalen op het gebied van oplevering, aangezien de knelpunt nooit de coördinatie was. En ‘water-scrum-fall’, het patroon dat Dave West van Forrester zo heeft genoemd, is een versterking van overbelasting Power: een plan waarvan de omvang, de tijd en de kosten vooraf vastliggen en dat vervolgens in sprints wordt verpakt, zodat het team zowel de ceremoniële overhead van agile als de starheid van waterval draagt, met het slechtste van beide.

Het is de moeite waard om ook het tegenargument serieus te nemen, omdat het populair is en voor de helft klopt. Praktijkmensen wijzen er graag op dat veel vooraanstaande technische organisaties de ‘ceremonie-stack’ nauwelijks toepassen: ingenieurs leiden projecten, teams kiezen hun eigen methode en ‘continuous delivery’ levert snellere feedback op dan welke wekelijkse vergadering dan ook. Ga zorgvuldig om met die opmerking: „regels gelden niet voor ons“ is geen strategie, en een groot, verspreid team heeft daadwerkelijk meer afstemming nodig dan een klein team dat op één locatie werkt. De echte les is niet de ceremonies overslaan; het is de ceremonie afstemmen op de coördinatie die het werk daadwerkelijk vereist, wat voor sommige teams veel minder is dan het standaarddraaiboek veronderstelt, en voor andere teams precies de standaardhoeveelheid is. Overbelasting is het gevolg wanneer u het draaiboek klakkeloos kopieert in plaats van de behoefte op maat te bepalen. De laatste modus, de follow-through void, is wat u krijgt wanneer zelfs op de juiste schaal afgestemde ceremonies niets veranderen.

Veelgestelde vragen

Hoeveel vergaderingen zijn er te veel in Scrum?

Er is geen vast getal. De toets is de verhouding en het rendement. Bereken het percentage dat de terugkerende bijeenkomsten in beslag nemen van de werkweek van het team; als dit percentage hoger is dan 20% en het team niet kan aangeven wat er daardoor is veranderd, bent u overbelast. Een vergadering verdient zijn plaats door een besluit of afstemming op te leveren die het werk daadwerkelijk nodig heeft, niet door op de standaardlijst te staan.

Zijn sprints van één week te kort voor alle ceremonies?

Vaak wel, ja. Als er elke week zowel een planning als een retrospective plaatsvindt, loopt de verhouding tussen ceremonie en daadwerkelijk werk sterk op, en ervaren teams hebben vaak niet zo snel iets nieuws om over na te denken. Pas de frequentie aan: houd de retrospective om de twee of drie sprints als de wekelijkse reflectie te weinig oplevert, en maak de statusupdate asynchroon, zodat de dagelijkse update niet de hele ochtend in beslag neemt.

Waarom lijken grote technologiebedrijven scrum-bijeenkomsten over te slaan?

Veel topteams werken inderdaad op een meer flexibele manier: ingenieurs leiden projecten, teams kiezen hun eigen werkwijze, en CI/CD in combinatie met feature flags zorgen voor snellere feedback dan een wekelijkse bijeenkomst dat zou kunnen. Maar de les is niet dat regels niet op ons van toepassing zijn; het gaat erom dat u de bijeenkomst afstemt op de werkelijke behoefte aan coördinatie. Een klein team dat op één locatie werkt, heeft minder afstemming nodig dan een groot, verspreid team, en het blindelings kopiëren van een van beide uitersten is op zich al een fout.

Hoe kan ik de overhead van agile vergaderingen verminderen zonder dat dit ten koste gaat van de coördinatie?

Beoordeel elke terugkerende bijeenkomst aan de hand van één vraag: welke beslissing of afstemming levert dit op? Schrap of voeg de bijeenkomsten samen waarvoor geen antwoord is, verplaats statusrapportages naar de tools waarin deze gegevens al zijn opgenomen, en beperk de omvang van de overige vergaderingen tot de kleinste groep die er daadwerkelijk bij aanwezig moet zijn. Het doel is om minder tijd te besteden aan afstemming en meer tijd aan het eigenlijke werk.

Aanbevolen lectuur

• Voorstelling: de ceremonie die u voor het publiek organiseert. De ceremonie die weinig kost om in stand te houden, omdat niemand er iets van verwacht.
• De leegte van het niet-volgen. Wanneer zelfs een plechtigheid op gepaste schaal niets verandert.
• Asynchrone en stand-ups op afstand. De status loskoppelen van de synchrone klok.
• Sprintplanningsvergadering. De planning zo strak mogelijk uitvoeren, zodat het uur er goed aan besteed is.
• Agile-ceremonies: de complete gids. Waar elke ceremonie voor dient, zodat u kunt bepalen welke ceremonies daadwerkelijk nodig zijn voor het werk.
• Woordenlijst Agile Theatre. Een toelichting op de vier geïntroduceerde faalwijzen.