Agile in de praktijk: waarom bijna niemand Scrum volgens het boekje gebruikt
Veel organisaties claimen dat ze Scrum gebruiken, terwijl ze eigenlijk bedoelen: “We werken in blokken van twee weken, vergaderen vaak en houden onze taken bij op een Jira-bord.” Maar Scrum is geen agenda-indeling en Agile is geen hippe naam voor traditioneel projectmanagement. Waar Agile een brede filosofie is van flexibiliteit en eigenaarschap, is Scrum slechts één specifiek hulpmiddel om dat te bereiken.
De harde realiteit is dat vrijwel geen enkele organisatie Scrum volgens het boekje gebruikt. Dat hoeft ook niet, maar het wordt wél een probleem als we massaal doen alsof. Waarom strandt de theorie zo snel in de praktijk, en hoe voorkom je dat jouw organisatie blijft hangen in dit ‘Scrum-theater’?
De botsing met de realiteit
De verklaring is simpel: Scrum is ontworpen voor een ideale wereld, maar organisaties zijn complex.
Het framework is bewust licht opgezet en gaat uit van autonome teams. Totdat Scrum botst met de gemiddelde corporate realiteit. Denk maar eens aan jaarlijkse budgetcycli, complexe leverancierscontracten, stuurgroepen en stakeholders die én wendbaarheid én een waterdichte roadmap eisen, allemaal tegelijkertijd.
In zo’n omgeving hebben Product Owners zelden echt mandaat en zijn developers vaak afhankelijk van vijf andere teams voordat ze iets kunnen opleveren. Het logische resultaat is een hybride deliverymodel met een Scrum-naamkaartje. Dat kan prima werken, mits het een bewuste strategische keuze is en geen toevallig compromis. Want als die keuze niet bewust is, glijd je ongemerkt af naar de grootste valkuil van Agile.
Het risico: Scrum-theater
Het gevaar zit hem namelijk niet in het aanpassen van het framework, maar in het ontkenningsgedrag dat daarna ontstaat. Dat is het moment dat het ‘Scrum-theater’ begint. Alles krijgt de juiste naam, maar behoudt de oude, rigide functie:
- De sprint wordt een platte deadlinebak.
- De Daily Scrum verandert in een dagelijks verantwoordingsmoment aan de manager.
- De Product Owner degradeert tot een stemloze backlog-beheerder of wordt juist de oude, vertrouwde projectmanager die ook de leiding heeft over het gehele scrumteam.
- De retrospective wordt een herhalend klaaguurtje over problemen die niemand aan tafel mag oplossen.
Teams voelen deze schijnveiligheid feilloos aan. Je verbetert de delivery niet; je plakt alleen een hippe sticker op je oude systeem. Hoe trek je die sticker er weer af? Door te kiezen voor een bittere, maar noodzakelijke pil.
Wees eerlijk, verbeter daarna
Echte vooruitgang begint met radicale eerlijkheid over je werkwijze. Je hebt grofweg twee smaken:
- Gebruik je Scrum? Doe het dan met discipline. Geef de Product Owner het juiste mandaat, bewaak het sprintdoel en behandel retrospectives als een motor voor verandering.
- Gebruik je een hybride model? Zeg dat dan gewoon hardop en richt het fatsoenlijk in. Maak besluitvorming helder, breng afhankelijkheden in kaart en definieer hoe prioriteiten écht worden bepaald.
Die duidelijkheid helpt iedereen. Teams stoppen met doen alsof ze besluiten mogen nemen, en managers zien sneller waar ze drempels moeten wegdragen. Maar om die duidelijkheid te kunnen scheppen, moet iedereen wel eerst op hetzelfde niveau zitten.
De taal van delivery
Bij Seventrees nemen we dit serieus. We werken niet alleen agile bij Seventrees. We zorgen er ook voor dat elke medewerker de PSPO1-certificering behaalt. Niet omdat zo’n papiertje je ineens agile maakt, maar omdat we dezelfde taal moeten spreken over wat er daadwerkelijk op de werkvloer gebeurt. Pas als je de theorie écht begrijpt, weet je wanneer je er (bewust) van mag afwijken.
Het einddoel is immers nooit het framework zelf, maar betere delivery: sneller resultaat met minder overhead. Stop dus met de vraag of je Scrum wel volgens het boekje gebruikt. Stel liever de échte vraag:
Helpt jullie huidige manier van werken teams om daadwerkelijk waarde te leveren of steken jullie oude gewoontes vooral in een nieuw jasje?
