Ik werk ruim twintig jaar met Scrum, waarvan een groot deel als Professional Scrum Trainer. In die tijd heb ik transformaties zien slagen en — vaker — zien doodbloeden. Wat ik nu weet, had ik graag eerder geweten. Een deel ervan gaat lijnrecht in tegen wat ik zelf jarenlang heb verkondigd.

1. Het framework is nooit het probleem

In mijn eerste jaren dacht ik dat mensen Scrum niet goed genoeg begrepen. Dus legde ik het beter uit. Nog een keer, met betere voorbeelden.

Dat hielp zelden. Scrum is klein genoeg om in een middag uit te leggen; er staat niets ingewikkelds in. Als het niet werkt, komt dat vrijwel nooit doordat men de events niet snapt. Het komt doordat de organisatie eromheen ander gedrag beloont dan Scrum veronderstelt.

Een team dat elke sprint zelf mag kiezen wat het oppakt, maar waarvan de manager afgerekend wordt op een jaarplanning, gaat verliezen van die manager. Terecht. Dan is er geen trainingsprobleem maar een systeemprobleem, en daar helpt geen enkele uitleg tegen.

2. Meer proces is bijna altijd het verkeerde antwoord

Als het stroef loopt, is de reflex een extra overleg. Een refinement erbij, een afstemming tussen teams, een wekelijkse status.

Vrijwel altijd is het omgekeerde nodig. Stroefheid komt meestal doordat er te veel tegelijk loopt en te veel mensen op elkaar wachten. Daar helpt minder werk in omloop tegen, geen extra vergadering waarin dat wachten wordt besproken.

Mijn vuistregel: bij twijfel iets weghalen in plaats van erbij zetten. Dat is oncomfortabel, omdat weghalen als nalatigheid voelt en toevoegen als daadkracht.

3. De Product Owner is de zwakste schakel — en zelden door eigen toedoen

Dit is de rol waar het in mijn ervaring het vaakst misgaat. Niet omdat de mensen het niet kunnen, maar omdat ze de bevoegdheid niet hebben.

Een Product Owner hoort te kiezen, en kiezen betekent nee zeggen tegen iemand die dat vervelend vindt. Wie dat mandaat niet heeft, wordt een doorgeefluik: hij verzamelt wensen, zet ze op volgorde van wie het hardst roept, en heet dan backlogbeheerder.

Ik vraag tegenwoordig in de eerste week: wie kan deze beslissing terugdraaien? Zijn dat er drie, dan weet ik genoeg. De rest van het traject gaat dan niet over backlogtechniek maar over het organiseren van eigenaarschap.

4. Ik heb te lang geloofd dat cijfers het gesprek zouden openen

Hier had ik het mis, en het kostte me jaren om dat toe te geven. Ik dacht dat organisaties beter zouden sturen zodra ze betere cijfers hadden. Dus bouwde ik inzicht, dashboards, overzichten.

Wat er gebeurde: de cijfers werden gebruikt om te bevestigen wat men al vond. Of erger, om teams te vergelijken. Een goede meting in een omgeving waarin het niet veilig is om tegenvallers te melden, levert alleen maar nettere rapportages op.

Ik begin nu andersom. Eerst kijken of het eerlijke gesprek gevoerd kan worden, dan pas meten. Cijfers versterken de cultuur die er al is; ze vervangen hem niet. Dat is ook waarom ik velocity niet op een managementdashboard wil en waarom psychologische veiligheid voor mij geen zachte randvoorwaarde is.

5. Scrum Masters worden te vaak vergaderaars

De rol is bedoeld om het systeem te veranderen. In de praktijk zie ik hem verschrompelen tot het faciliteren van vier vergaderingen en het bijhouden van een bord.

Dat is deels de schuld van ons vak. We hebben zoveel nadruk gelegd op de events dat mensen denken dat de rol daaróver gaat. De moeilijkste taak van een Scrum Master ligt buiten het team: bij de manager die om een jaarplanning vraagt, bij de afdeling die drie weken doet over een goedkeuring.

Dat is ongemakkelijk werk, en het vraagt lef en politiek gevoel. Wie dat niet doet, houdt een goed georganiseerd team over dat nog steeds tegen dezelfde muur loopt.

6. Ontsporen gaat langzaam, niet plotseling

Niemand besluit om te stoppen met Agile werken. Het verdwijnt in stapjes die elk verdedigbaar zijn: deze sprint even geen retrospective vanwege de drukte, deze release zonder de gebruikelijke controles, deze keer de planning van bovenaf omdat het moet.

Na een jaar staat alles er nog — de events, de rollen, de borden — maar er zit niets meer achter. Dat noemen we dan "Agile in naam", en het is de meest voorkomende eindtoestand van een transformatie.

Wat mij betreft is dat het beste argument om afspraken hard te maken. Niet uit dogmatisme, maar omdat de eerste uitzondering altijd redelijk klinkt en de tiende niemand meer opvalt.

7. Het gaat over mensen, en dat wist ik niet toen ik begon

Ik kom uit de techniek. Ik ben begonnen als developer, en ik dacht dat het slim organiseren van werk het grootste deel van het probleem was.

Dat is het niet. De meeste vastgelopen teams die ik tegenkom hebben geen procesprobleem maar een gespreksprobleem: iets wat niet gezegd wordt, een conflict dat wordt vermeden, een verwachting die nooit is uitgesproken.

Daarom ben ik me gaan opleiden tot professioneel coach. Niet als aanvulling op mijn Agile-werk maar omdat ik er zonder niet verder kwam. Dat is ook waarom ik de coachingsroute serieus heb genomen in plaats van mezelf coach te noemen: ik had de vaardigheid werkelijk nodig.

Wat ik nu anders doe

Twintig jaar geleden begon ik een opdracht met uitleggen hoe Scrum werkt. Nu begin ik met kijken hoe besluiten in deze organisatie genomen worden, wie waarop wordt afgerekend, en waar het werk blijft liggen.

Het framework komt later wel. Meestal blijkt dan dat er maar een paar dingen echt veranderd hoeven worden — en dat die paar dingen niets met Scrum te maken hebben.