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 maken? 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 volkomen goede ceremonie kan er nog steeds één te veel zijn. Het is de enige vorm die u met rekenwerk kunt vaststellen.

De vergaderbelasting, eerlijk berekend

Tel het dus maar op — de hele stapel, niet alleen de dagelijkse taken. 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 verdeeld over tien dagen. Reken het maar eens uit en u komt uit op ruim een werkdag per ontwikkelaar, elke sprint, nog voordat er ook maar één regel code is geschreven — en praktijkmensen berekenen dit in manuren, omdat dat de eenheid is die het management begrijpt: een stand-up van vijftien minuten voor een team van twaalf is geen vijftien minuten, maar drie manuren, elke dag, die verloren gaan. Tel daar vervolgens het deel bij op dat de agenda nooit laat zien – het afbouwen vóór elk van die onderbrekingen en het weer op gang komen erna – en een vijfde van de werkweek is een conservatieve schatting, wat precies de overhead is die beoefenaars 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 besluit, een botsing die is voorkomen of een obstakel dat is weggenomen als gevolg van een ceremonie, betaalt deze last voor niets. De overhead is alleen te rechtvaardigen wanneer het rendement concreet benoembaar is.

De contextwisseling is de echte 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 weer 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 moment kost slechts een fractie van die onderbreking. 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 korte sprints

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 sprintduur, dan verdubbelen de planningssessies, de evaluaties en de retrospectieven — maar u halveert het werk dat daartussen moet worden verricht niet, waardoor de verhouding tussen ceremonies 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 duur van de sprint, de frequentie van de stand-up-bijeenkomsten en de frequentie van de retrospectieven hoeven niet synchroon te lopen. Een team dat wekelijkse retrospectieven zinloos vindt, kan de retrospective om de twee of drie sprints houden zonder iets te verliezen — reflectie heeft zijn eigen natuurlijke ritme, en door het proces te versnellen voordat het team lessen heeft opgedaan, 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 alle rituelen uitvoert, maar de onderliggende technische discipline verwaarloost — waardoor het de volledige ‘vergaderbelasting’ betaalt zonder enig voordeel op het gebied van oplevering te behalen, omdat 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 Overload Power: een plan waarvan de omvang, de tijd en de kosten vooraf vastliggen en dat vervolgens in sprints wordt verpakt — waardoor 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 veel gehoord wordt en voor de helft klopt. Praktijkmensen wijzen er graag op dat veel vooraanstaande engineeringorganisaties 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 precies de standaardhoeveelheid is. Overbelasting is het gevolg wanneer u het draaiboek klakkeloos kopieert in plaats van de behoefte in te schatten. De laatste modus, de follow-through void, is wat u krijgt wanneer zelfs op de juiste omvang afgestemde ceremonies niets veranderen.

Veelgestelde vragen

Hoeveel vergaderingen zijn er te veel in Scrum?

Er is geen vast getal — de toetssteen is de verhouding en het rendement. Tel de totale tijd die aan terugkerende bijeenkomsten wordt besteed op als percentage van de werkweek van het team; als dit percentage boven de 20% ligt 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 op terug te blikken. Pas de frequentie aan: houd de retrospective om de twee of drie sprints als de wekelijkse terugblik te weinig oplevert, en schakel de statusupdate over naar asynchroon, zodat de dagelijkse update niet de hele ochtend in beslag neemt.

Waarom lijken grote techbedrijven 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 de bijeenkomst af te stemmen op de daadwerkelijke behoefte aan coördinatie. Een klein team dat op één locatie werkt, heeft minder behoefte aan afstemming 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: tot welke beslissing of afstemming leidt deze? Schrap of voeg de bijeenkomsten samen waarvoor geen antwoord is, verplaats statusrapportages naar de tools waarin deze informatie al is 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 uitvoeren van het werk.

Aanbevolen lectuur

• Voorstelling: de ceremonie die u voor het publiek opvoert — de ceremonie die weinig kost om in stand te houden, omdat niemand er iets van verwacht.
• De leegte na de plechtigheid — wanneer zelfs een plechtigheid van de juiste omvang 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 — de vier geïntroduceerde faalmodi, gedefinieerd.