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?

In de praktijk lukt het organisaties helaas steeds weer om Scrum in te voeren 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. 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?

Er zijn veel redenen voor “Fake Agile”. De meest voorkomende oorzaken van Fake Agile in de praktijk 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

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

“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 zijn als we onze werkmethoden 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