Fake Agile: Is elk Scrum-team agile?
Nee, helaas is niet elk Scrum-team echt agile.
Ik zal het uitleggen: Een Scrum-team wordt gedefinieerd door te werken volgens het Scrum-raamwerk: Het heeft dus sprints, bepaalde rollen en rituelen. En aangezien het doel van het Scrum framework is om teams te helpen op een agile manier te werken, zou Scrum automatisch elk team agile moeten maken, toch?
Helaas slagen organisaties er in de praktijk altijd in om Scrum te introduceren en hun teams allesbehalve agile te maken. Dit wordt vaak "Zombie Scrum" genoemd.
Wat is "Fake Agile"?
"Fake Agile" verwijst naar teams die officieel werken met agile frameworks en methoden zonder dat er daadwerkelijke leerlussen met klanten zijn. Fake Agile betekent dus dat ofwel a) incrementen niet iteratief worden opgeleverd aan klanten in de eerste plaats of b) directe feedback van klanten op het increment niet wordt gebruikt voor prioritering op korte termijn.
Wat zijn de oorzaken van Fake Agile?
Er zijn veel redenen voor "Fake Agile". Mijn ervaring leert dat de meest voorkomende oorzaken van valse Agile in de praktijk de volgende zijn:
Nep Agile Oorzaak #1: geen feedback van klanten
Als een agile team geen directe feedback krijgt van gebruikers, kan het niet op een agile manier werken. In de praktijk worden klantverzoeken vaak geformuleerd door het management en via producteigenaren doorgegeven aan teams – Echte feedbacklussen met klanten verdwijnen of bestaan niet eens.
Een agile team heeft direct klantcontact nodig!
Nep Agile Want #2: Focus op snelheid en verhaalpunten
Oef, moeten we nog veel meer zeggen over story points in 2025? Ik denk dat we allemaal genoeg hebben ervaren hoezeer een focus op snelheid en story points het voordeel voor de klant in de weg staat.
Een voorbeeld: Wat gebeurt er als een functie na de eerste iteratie formeel klaar is, maar het klantvoordeel nog niet bereikt is? Als het klantvoordeel belangrijk voor ons is, dan werken we eraan totdat het klantvoordeel daadwerkelijk is bereikt. Uiteindelijk kan het 3 iteraties duren, maar de klant is nu tenminste tevreden.
Maar wacht, nu komt mijn manager ineens om de hoek kijken en klaagt dat mijn team minder story points heeft gerealiseerd in de laatste sprint. Het zou dus beter zijn geweest voor mijn snelheid als we de niet-waardevolle functie gewoon hadden verlaten en direct aan de volgende functie hadden gewerkt, zodat we meer story points konden creëren.
Wat een onzin, toch? Als we dit proces nog een paar maanden herhalen, hebben we een product met veel functies die weinig voordeel opleveren voor de klant.
Het hoeft dus niet te verbazen dat zowel klanten als ontwikkelteams ongelukkig worden en vertrekken.
In meer algemene termen gaat dit over een nu welbekende wet: Wet van Goodhardt
"Als een maatregel een doel wordt, is het geen goede maatregel meer."
Nep Agile Oorzaak #3: De dogmadictatuur
Ingenieurs houden ervan als er vaste regels zijn voor alles. Dat maakt processen planbaar.
Dus hoe zou het zijn als we ook onze werkmethoden volledig zouden kunnen definiëren met regels – Zou dat niet geweldig zijn? Nee, dat zou het niet zijn.
Alleen al met Scrum en zijn vele regels en richtlijnen voelt agile werken voor veel teams al als werken volgens rigide richtlijnen. Zo zou het niet moeten zijn. Dus maak het niet nog erger door nog meer regels en richtlijnen aan agile werken toe te voegen.
In de beste agile teams die ik ken, voelt het werk menselijk, levendig, spontaan en samenwerkend. En toegegeven, in de meeste agile teams is dat niet zo.
Agile-teams moeten op zijn minst voldoende vrijheid hebben om flexibel te kunnen samenwerken met klanten. Als regels en processen dit verhinderen, moeten de regels en processen onder de loep worden genomen.
In deze post heb ik al specifiek geschreven over de stappen die nodig zijn om Scrum teams te beschermen tegen Zombie Scrum: Zombie Scrum oplossen
Nep Agile bestaat echt: hoe bescherm je jezelf?
Niets beschermt je volledig tegen valse behendigheid. Maar er is één ding dat je zo goed mogelijk kan beschermen: Een effectief proces gericht op voortdurende verbetering.
Dit begint natuurlijk met goede retrospectives waarin teamleden openlijk hun mening kunnen delen en effectief maatregelen voor verbetering kunnen afleiden en implementeren.
Zolang dit proces werkt, gaat het potentieel voor echte wendbaarheid in je team niet verloren.
Als je je agile retrospectives naar een hoger niveau wilt tillen, raad ik je –natuurlijk – Echometer aan, onze tool voor retrospectives. Je kunt het hier gratis uitproberen: Probeer Echometer