Macht: wanneer gezag de plechtigheid overneemt

Elke agile ceremonie gaat uit van gelijke voorwaarden. Machtsverhoudingen ontstaan juist 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 statistiek 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, omdat het benoemen ervan de eerste stap is om ze te weigeren.

De snelheidsratel

Laten we beginnen met het meest treffende argument van allemaal: de persoon die story points heeft bedacht, heeft zich ervan gedistantieerd. „Ik zeg graag dat ik story points misschien wel heb bedacht, en als dat zo is, spijt het me nu,” schreef Ron Jeffries in 2019. Hij was duidelijk: „Ik denk dat het schadelijk is om teams met elkaar 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, ligt de bewijslast bij iedereen die deze nog steeds als scorebord gebruikt.

De snelheidsratel is de manier waarop die schade ontstaat. Snelheid is bedoeld als een interne zelfkalibratie van het team: het voortschrijdend gemiddelde van voltooide punten, dat wordt gebruikt om te voorspellen hoe lang het zal duren om de backlog af te werken. Zodra dit de ruimte verlaat als productiviteitsdoelstelling, verandert het in een ratel: 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 zij op de enige manier die de prikkel toestaat. Zij blazen de cijfers op. Een story die vorig kwartaal een 3 was, is dit kwartaal een 5; het aantal stijgt, en er wordt niets sneller opgeleverd. Zelfs Mike Cohn, de autoriteit op het gebied van pro-punten, 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 op het gebied 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 de inspanning meten, niet de geleverde waarde. De regel is dus eenvoudig en verdedigbaar: maak prognoses op basis van velocity, maar beoordeel er nooit op. 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 verantwoordingsplicht wekt. Het ‘witwassen’ van schattingen is het stilletjes 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 tijdens 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 cijfer noemt waarmee de deadline haalbaar is, waarna de planning een schijnvertoning wordt met een vooraf bepaald 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 correctie is die van Mike Cohn, en deze dateert van vóór onze eigen term: schatting scheiden van toezegging. 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’-effect. Wanneer de omvang, de tijd en de kosten allemaal vooraf vastliggen en het werk louter 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 „witten” van schattingen vormt daar het kloppende hart van. In ons hoofdstuk story points versus uren wordt uitgelegd waarom de omrekening de oorzaak van het probleem is, en niet de oplossing.

Feedbackbank

De derde vertekening is de meest verontrustende, omdat deze de ceremonie die het veiligst klinkt, verandert in een risico. Feedbackbankieren is wanneer eerlijke feedback achteraf wordt opgeslagen en later stilletjes tegen u wordt gebruikt: bij een functioneringsgesprek, een bonusbeoordeling of een informeel gesprek over of u wel bij de organisatie past. Het retrospectieve gesprek 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 u recht in het hart. Een ingenieur beschreef hoe zijn feedback uit de retrospectieve tijdens een jaarlijkse beoordeling weer boven water kwam als bewijs dat hij „te veel klaagt“. Een ander verwoordde het mechanisme in klare taal: het management spaart alle klachten op om ze tijdens uw jaarlijkse bonusbeoordeling boven water te halen. Voor dit afschrikkende effect is zelfs geen kwade opzet nodig. De persoon die bevorderingen goedkeurt, hoeft in de vergaderzaal geen woord te zeggen. Alleen al zijn aanwezigheid volstaat om eerlijke inbreng te verdoezelen en iedereen te leren dat het verstandig is om te doen alsof men tevreden is. In ons hoofdstuk Waarom retrospectieven mislukken wordt besproken hoe u de sessie zo kunt opzetten dat eerlijkheid geen nadelige gevolgen meer heeft voor de loopbaan.

Op dit punt 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 was: 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 retro die doet alsof dat wel het geval is, is schijnvertoning met een juridisch risico. De Scrum Guide beschrijft de retrospective als het moment waarop het team zichzelf evalueert. Waarom maakt de manager die in de ruimte aanwezig is dan aantekeningen?

Vertrouw niet op een held

Er schuilt een risicomechanisme in de oplossing zelf. Deze verstoringen worden doorgaans in toom gehouden doordat iemand in een leidinggevende functie (een teamleider, een EM met ruggengraat) het team persoonlijk beschermt: hij of zij weigert de velocity 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 openhartigheid van uw ceremonies afhangt van de bereidheid van één manager om de druk op zich te nemen, beschikt u niet over veilige ceremonies. U hebt dan 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 een vaststaand gegeven. 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 gecontroleerde 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 eigen kring. 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 puntentotalen.

Kan retrospective feedback tijdens een functioneringsgesprek tegen mij worden gebruikt?

Het komt voor, en die angst is gerechtvaardigd. Deelnemers melden dat eerlijke feedback uit een retro-sessie maanden later weer naar boven komt in de vorm van een opmerking dat zij te veel klagen. Dat is ‘feedback banking’, en dat 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, noem 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 dwingende ervaring 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 leidt tot het ‘witwassen’ van schattingen.
• Sprintplanning (de bijeenkomst): waarbij een schatting bedoeld is als een prognose die het team zelf in handen heeft, 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’.