Macht: wanneer gezag de plechtigheid overneemt

Elke agile ceremonie gaat uit van gelijke voorwaarden. Machtsverhoudingen ontstaan wanneer die gelijke voorwaarden ontbreken.

Planning poker voorkomt het anker-effect alleen als niemand aan tafel de kaarten terzijde kan schuiven. Een retrospective is alleen veilig als eerlijkheid geen nadelige gevolgen heeft. Velocity is alleen een prognose als niemand boven het team deze beoordeelt. Verwijder die aannames – voeg een manager toe die promoties goedkeurt, een maatstaf die naar boven wordt doorgegeven, een schatting die verhardt tot een belofte – en de ceremonie presteert niet alleen ondermaats. Ze keert zich om. Ze begint tegen de mensen te werken voor wie ze bedoeld was. In dit hoofdstuk worden de drie meest treffende manieren genoemd waarop dit gebeurt, want het benoemen ervan is de eerste stap om ze te weigeren.

De snelheidsratel

Laten we beginnen met de meest opvallende opmerking van allemaal: degene die story points heeft bedacht, heeft zich ervan gedistantieerd. „Ik zeg graag dat ik story points misschien wel heb uitgevonden, en als dat zo is, spijt het me nu,” schreef Ron Jeffries in 2019 — en meer specifiek: „Ik denk dat het schadelijk is om teams te vergelijken op basis van de kwaliteit van hun schattingen of hun velocity.” Wanneer de uitvinder van de eenheid u vertelt dat de eenheid wordt gebruikt om teams schade te berokkenen, verschuift de bewijslast naar iedereen die deze nog steeds als scorebord gebruikt.

De snelheidsratel is de manier waarop die schade ontstaat. Snelheid is bedoeld als de interne zelfkalibratie van een team — het voortschrijdend gemiddelde van voltooide punten, dat wordt gebruikt om te voorspellen hoe lang het zal duren om een backlog af te werken. Zodra het de ruimte verlaat als productiviteitsdoelstelling, wordt het een ratchet: het cijfer van de vorige sprint vormt de ondergrens voor deze sprint, en de enige richting waarin het mag bewegen is omhoog. Teams zijn niet dom, dus reageren ze op de enige manier die de prikkel toestaat — ze blazen de cijfers op. Een story die vorig kwartaal een 3 was, is dit kwartaal een 5; het aantal stijgt, maar er wordt niet sneller geleverd. Zelfs Mike Cohn, de autoriteit op het gebied van pro-points, erkent dit mechanisme: de geringste suggestie dat velociteiten zullen worden vergeleken, leidt tot een geleidelijke, consistente punteninflatie.

De sterkste onderbouwing om ‘velocity’ binnen de juiste context te houden, is DORA. Tien jaar onderzoek naar de factoren die de prestaties van softwarelevering voorspellen, heeft vier meetgrootheden opgeleverd — implementatiefrequentie, doorlooptijd, percentage mislukte wijzigingen en hersteltijd — en velocity is bewust niet opgenomen in deze lijst, omdat story points niet vergelijkbaar zijn tussen teams en een maatstaf zijn voor de inspanning, niet voor de geleverde waarde. De regel is dus eenvoudig en verdedigbaar: maak prognoses op basis van velocity, maar beoordeel nooit op basis daarvan. Als iemand buiten het team vraagt: „Is uw velocity goed?”, ligt de oplossing stroomopwaarts van het getal — het eerlijke antwoord is: „Wat probeert u nu eigenlijk te meten?” Ons hoofdstuk over velocity laat zien hoe u dit eerlijk kunt houden, en velocity en capaciteitsplanning laat zien hoe u het kunt gebruiken voor het enige waarvoor het geschikt is.

Het witwassen van offertes

De tweede vertekening is subtieler, omdat deze de schijn van verantwoordelijkheid wekt. Schattingswitwassen is het stille omzetten van een schatting — een gok, gemaakt op basis van de minimale informatie waarover u ooit zult beschikken — in een toezegging, en het team vervolgens hieraan houden alsof zij een contract hebben ondertekend. De schatting wordt in de planningsvergadering ingebracht; er wordt een deadline vastgesteld; en wanneer de deadline wordt overschreden, is het de schuld van de ontwikkelaar omdat hij „zijn schatting niet heeft gehaald“.

De betrokkenen beschrijven de gehele ‘witwascyclus’ zonder dat daar om gevraagd hoeft te worden: schattingen worden op magische wijze toezeggingen, en als u het streefcijfer niet haalt, is dat uw eigen verantwoordelijkheid. Schattingen worden terzijde geschoven – „dat kan niet kloppen, doe het nog eens“ – totdat het team een willekeurig cijfer noemt waarmee de deadline haalbaar wordt; op dat moment is de planning een schijnvertoning met een vooraf vaststaand antwoord. Er is zelfs een veelzeggende asymmetrie in de taal: zeg „dit duurt tien dagen” en een manager zal aandringen: „weet u zeker dat het geen negen dagen kan zijn?”; zeg „dit is tien punten” en, om redenen die niemand echt kan verdedigen, treedt datzelfde instinct niet in werking. Storypoints waren deels bedoeld als bescherming tegen precies die druk — en het ‘witwassen’ van schattingen is de druk die deze bescherming tenietdoet door de punten direct weer om te zetten in een datum.

De gangbare oplossing is die van Mike Cohn, en deze dateert van vóór onze eigen term: schatting en toezegging gescheiden houden. Een schatting is een waarschijnlijkheidsverdeling; een toezegging is een besluit dat het team neemt over wat het met zekerheid kan opleveren. Houd deze twee uit elkaar, en spreek dit hardop uit. Geef een bandbreedte aan en benoem de aannames die daaraan ten grondslag liggen. En let op het ‘compounding’-scenario: wanneer de omvang, de tijd en de kosten allemaal vooraf vastliggen en het werk slechts in sprints van twee weken wordt verpakt, hebt u geen agile met schattingen, maar waterval in een ander jasje. Dave West van Forrester noemde dat „water-scrum-fall”, en het „witwassen van schattingen” vormt daar het kloppende hart van. In ons hoofdstuk story points versus uren wordt uitgelegd waarom de omrekening juist de oorzaak van mislukkingen is, en niet de oplossing.

Feedbackverwerking

De derde vertekening is de meest duistere, omdat deze de ceremonie die het veiligst klinkt, verandert in een risico. Feedback banking is het fenomeen waarbij eerlijke feedback uit retrospectives wordt opgeslagen en later stilletjes tegen u wordt gebruikt — tijdens een functioneringsgesprek, bij de vaststelling van een bonus of in een informeel gesprek over uw ‘geschiktheid’. De retrospective wordt gepresenteerd als een veilige ruimte om openhartig te zijn. Feedback banking is het besef dat openhartigheid een afrekeningsdatum heeft.

De ervaringen zijn concreet en raken de spier. Een ingenieur beschreef hoe zijn of haar eerdere feedback tijdens een jaarlijkse beoordeling weer naar voren kwam als bewijs dat hij of zij „te veel klaagt”. Een ander vatte het mechanisme duidelijk samen: het management spaart alle klachten op om ze tijdens uw jaarlijkse bonusbeoordeling boven water te halen. Voor dit afschrikkende effect is zelfs geen kwaadwilligheid nodig — de persoon die over promoties beslist, hoeft in de vergaderruimte geen woord te zeggen. Alleen al zijn aanwezigheid is voldoende om eerlijke inbreng vaag te maken en iedereen te leren dat het verstandig is om te doen alsof men tevreden is. Ons hoofdstuk waarom retrospectives mislukken gaat over het zo ontwerpen van de sessie dat eerlijkheid geen nadelige gevolgen meer heeft voor de loopbaan.

Hier houdt de literatuur over veiligheid op met vage uitspraken. Uit het onderzoek van Amy Edmondson naar psychologische veiligheid en uit Project Aristotle van Google — een tweejarig onderzoek onder 180 teams — bleek dat psychologische veiligheid de sterkste van de vijf geïdentificeerde factoren is: de factor waarop de andere vier berusten. Een team dat heeft geleerd dat zijn feedback wordt ‘opgeslagen’, beschikt per definitie niet over psychologische veiligheid, en de retrospective die doet alsof dat wel het geval is, is schijnvertoning waaraan een juridisch risico kleeft. De Scrum Guide beschrijft de retrospective als een moment waarop het team zichzelf evalueert — dus waarom zit de manager dan in de kamer aantekeningen te maken?

Vertrouw niet op een held

Er schuilt een risico in deze oplossing. Deze verstoringen worden doorgaans in bedwang gehouden doordat iemand in een leidinggevende functie — een teamleider, een EM met ruggengraat — het team persoonlijk beschermt: hij weigert de voortgang naar boven door te geven, herformuleert schattingen als prognoses en zorgt ervoor dat de inhoud van de retro binnen de groep blijft. Het werkt, maar alleen zolang die persoon aanblijft. Een beschermer is geen systeem. Als de eerlijkheid van uw ceremonies afhangt van de bereidheid van één manager om de druk op zich te nemen, dan hebt u geen veilige ceremonies – u hebt een tijdelijk welwillende situatie, en het schijnvertoning hervat zich op de dag dat die persoon vertrekt.

Dat is het verschil tussen ‘macht’ als een vorm van falen en ‘macht’ als iets vaststaands. Het hoofdstuk over psychologische veiligheid gaat over het creëren van openhartigheid die niet afhankelijk is van wie er in de kamer aanwezig is, en de Hoofdrichtlijn behandelt de norm die ervoor zorgt dat dit standhoudt. Wanneer de vastgelegde ceremonie uiteindelijk niets anders oplevert dan geregisseerde schijn, bent u aangekomen bij de doorvoervacuum — de vierde modus, en degene waarin het opslaan van feedback de meest onopvallende schade aanricht.

Veelgestelde vragen

Hoe kan ik voorkomen dat het management ‘velocity’ tegen mijn team gebruikt?

Houd het cijfer binnen de groep. Velocity is een input voor prognoses, geen prestatiemaatstaf — het DORA-onderzoek laat dit bewust buiten beschouwing omdat de scores niet tussen teams onderling vergelijkbaar zijn. Als een manager buiten het team vraagt of uw velocity goed is, is het eerlijke antwoord een tegenvraag: wat probeert u eigenlijk te meten? Rapporteer resultaten en opleveringen, niet het totaal aantal punten.

Kan retrospective feedback tijdens een functioneringsgesprek tegen mij worden gebruikt?

Het komt voor, en de angst is gerechtvaardigd — deelnemers melden dat eerlijke feedback uit de retro-sessie maanden later weer opduikt in de vorm van een opmerking dat zij te veel klagen. Dat is ‘feedback banking’, en het is de reden waarom anonimiteit, het uitsluiten van leidinggevenden en de ‘Vegas-regel’ bestaan. Een retro waarbij openhartigheid een risico voor de carrière vormt, is psychologisch niet veilig, en geen enkele faciliteringstechniek kan dit verhelpen. Pas de machtsverhoudingen aan, niet de bewoordingen.

Hoe kan ik voorkomen dat schattingen als deadlines gaan gelden?

Maak een duidelijk onderscheid tussen schatten en toezeggingen doen, hardop en bewust. Een schatting is een waarschijnlijkheid; een toezegging is een belofte; wanneer u het ene in het andere omzet en het team vervolgens daaraan houdt, wordt het vertrouwen geschonden. Geef een bandbreedte aan, benoem de aannames en laat nooit toe dat een gok die tijdens een planningsvergadering is gedaan, wordt aangehaald als een datum waarvoor het team zich heeft verbonden.

Moet mijn manager de retrospectieve bijwonen of de stand-up leiden?

Over het algemeen niet. De Scrum Guide beschrijft de retrospectieve als een moment waarop het team zichzelf evalueert, en de dagelijkse vergadering als de onderlinge afstemming tussen de ontwikkelaars. De aanwezigheid van een gezagsdrager in de ruimte hoeft geen woord te zeggen om de openhartigheid te ondermijnen — de persoon die promoties goedkeurt, werkt per definitie remmend. Deel de actiepunten naar boven toe, niet de zitplaatsen.

Aanbevolen lectuur

• De leegte van het doorzetten — waar opgestapelde feedback en machteloosheid samenkomen.
• Voorstelling: de ceremonie die u voor het publiek opvoert — het theater dat de Macht tot een dwangmaatregel maakt.
• Snelheid: waarvoor dient deze en hoe berekent u deze? — gebruik deze waarde voor prognoses, nooit voor beoordelingen.
• Story points versus uren — waarom deze omrekening bijdraagt aan het ‘verdoezelen’ van schattingen.
• Sprintplanning (de bijeenkomst) — waarbij een schatting bedoeld is als een prognose waar het team zelf verantwoordelijk voor is, en niet als een toezegging.
• Hoe creëert u een psychologisch veilige omgeving — openhartigheid die niet afhangt van wie er in de ruimte aanwezig is.
• Woordenlijst Agile Theatre — uitleg van de begrippen ‘estimate laundering’, ‘feedback banking’ en ‘velocity ratchet’.