Macht: wanneer gezag de plechtigheid overneemt

Elke agile ceremonie gaat uit van een gelijk speelveld. Machtsverhoudingen ontstaan wanneer dat niet het geval is.

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 het meest doorslaggevende argument: 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 schattingen of 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 ‘velocity-ratchet’ is de manier waarop die schade ontstaat. Velocity 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 ratelmechanisme: 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 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 van software-oplevering voorspellen, heeft vier kernindicatoren opgeleverd (implementatiefrequentie, doorlooptijd, percentage mislukte wijzigingen en hersteltijd), en ‘velocity’ staat daar niet tussen; story points zijn niet vergelijkbaar tussen teams en meten de inspanning, niet 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 eerlijk kunt blijven, en in het gedeelte over velocity- en capaciteitsplanning wordt uitgelegd 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. Het ‘witwassen’ van schattingen is het stille omzetten van een schatting (een gok, gemaakt op basis van de minimale informatie waarover u ooit zult beschikken) in een toezegging, waarna het team hieraan wordt gehouden alsof het een contract heeft 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 hen 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; 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: maak een onderscheid tussen het maken van een schatting en het aangaan van een verbintenis. Een schatting is een waarschijnlijkheidsverdeling; een verbintenis is een besluit dat het team neemt over wat het met zekerheid kan opleveren. Houd deze twee zaken uit elkaar, en spreek ze 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 wordt verpakt in sprints van twee weken, dan 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 over story points versus uren wordt uitgelegd waarom de omrekening juist de oorzaak van mislukkingen is, en niet de oplossing.

Feedbackbank

De derde vertekening is de meest verontrustende, omdat deze zelfs de ceremonie die het veiligst klinkt, tot een risico maakt. Feedbackbankieren is wanneer eerlijke retrospective 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 het bedrijf past. De terugkoppeling wordt gepresenteerd als een veilige ruimte om openhartig te zijn. Feedbackbankieren is het besef dat openhartigheid een vervaldatum heeft.

De ervaringen zijn concreet en raken u recht in het hart. 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. Degene die promoties goedkeurt, hoeft in de vergaderruimte geen woord te zeggen. Alleen al zijn of haar aanwezigheid is voldoende om eerlijke inbreng te vertroebelen en iedereen te leren dat het verstandig is om te doen alsof men tevreden is. In ons hoofdstuk ‘Waarom retrospectieven mislukken’ bespreken we hoe de sessie zo kan worden opgezet 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 Google’s Project Aristotle – 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 met een juridisch risico. De Scrum Guide beschrijft de retrospective als het moment waarop het team zichzelf evalueert. Waarom maakt de manager in de ruimte dan aantekeningen?

Vertrouw niet op een held

Er schuilt een risico in de oplossing zelf. 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 ‘velocity’ door te geven aan het hoger management, 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 openheid 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 er dan een die tijdelijk welwillend is, 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 gecontroleerde schijn, bent u aangekomen bij de leegte van de opvolging: de vierde modus, en degene waarin het opsparen 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 hoort niet bij de leveringsstatistieken van DORA, en punten zijn sowieso niet tussen teams onderling vergelijkbaar. 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 die 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 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 het maken van een schatting en het aangaan van een verbintenis, hardop en bewust. Een schatting is een waarschijnlijkheid; een toezegging is een belofte; wanneer het ene in het andere wordt omgezet en het team vervolgens hieraan wordt gehouden, 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 Standup 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. Degene die promoties goedkeurt, is per definitie een intimiderende factor. Deel de actiepunten naar boven toe, niet de zitplaatsen.

Aanbevolen lectuur

• De leemte in de opvolging: waar opgestapelde feedback en machteloosheid samenkomen.
• Voorstelling: de plechtigheid die u voor het publiek opvoert: het theater dat de Macht tot een vorm van dwang maakt.
• Snelheid: waarvoor deze dient en hoe u deze berekent: gebruik het getal voor prognoses, nooit voor beoordelingen.
• Storypoints versus uren: waarom deze omrekening bijdraagt aan het ‘schoonwassen’ 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 termen ‘estimate laundering’, ‘feedback banking’ en ‘velocity ratchet’.