Niet elk Scrum-team is agile: Fake Agile

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 lukt het organisaties in de praktijk steeds weer om Scrum te introduceren en de teams daardoor allesbehalve agile te maken. Men spreekt dan vaak van “Zombie Scrum”.

Wat is “Fake Agile”?

“Fake Agile” verwijst naar teams die officieel weliswaar met agile frameworks en methoden werken, maar zonder daadwerkelijke leercycli met klanten te hebben. Fake Agile betekent dus dat men ofwel a) helemaal geen iteratieve incrementen aan klanten levert of b) de directe feedback van klanten op het increment niet gebruikt voor de kortetermijnprioritering.

Wat zijn de oorzaken van Fake Agile?

Redenen voor “Fake Agile” zijn er vele. De meest voorkomende oorzaken in de praktijk voor Fake Agile zijn naar mijn ervaring de volgende:

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

Pff, moeten we in 2026 nog veel zeggen over Story Points? Ik denk dat we allemaal genoeg ervaring hebben opgedaan met hoe erg een focus op Velocity en Story Points de klantwaarde 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

“When a measure becomes a target, it ceases to be a good measure.”

Nep Agile Oorzaak #3: De dogmadictatuur

Ingenieurs houden ervan als er vaste regels zijn voor alles. Dat maakt processen planbaar.

Hoe zou het dus zijn als we onze werkwijzen ook volledig met regels vastleggen - 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