Scrum is dood: en dat werd tijd


Onlangs hoorde ik het weer: “Team, we hebben tweehonderd items op de ‘backlog’ en nog een maand om ze weg te werken…”.

Vervolgens een Product Owner die aan hetzelfde team vraagt: “hoe gaan we dit oplossen?”. Ik zei niets — het was niet mijn team — maar mijn antwoord was simpel: “je pakt er twintig en rondt die in twee weken af”. Maar dat schrijft Scrum niet voor. Sterker nog, Scrum brengt je juist snel in deze situatie. Scrum-adepten zullen dat steevast ontkennen, door hun ongeremde drang en bijna religieuze toewijding naar abstractie. Toch staat dit team — na vier maanden — 200 tickets achter.


Scrum: van belofte naar probleem

Inmiddels alweer jaren geleden — rond 2011 — volgde ik de Scrum-Master-cursus. Toen waren Scrum en Agile nog nieuwe termen. Waterval werd nog als een legitieme projectmanagementmethode aangeleerd. Maar als ik om mij heen kijk, blijft het kernprobleem van productontwikkeling hetzelfde: op tijd shippen lukt bijna nooit. En Scrum is daar een oorzaak van.

Met behulp van AI zou je denken dat sneller een product in de markt zetten inmiddels een feit is. Maar als ik om me heen kijk: iedereen gebruikt het, maar teams zijn niet sneller. Terwijl je met vibe-coding minimaal drie keer zo snel zou moeten kunnen leveren. Zo is het in ieder geval voor mij. Het is bijna een grap geworden. Vraag aan ieder teamlid: “wanneer is het af?” en je krijgt per rol een ander antwoord:

• De CEO: “Ik verwacht Q2”.
• De Product Owner: “Over drie sprints”.
• De designer: “Na de tweede kitchen review”.
• De developer: “32 storypoints in totaal, schat ik”.

Niemand spreekt écht dezelfde taal. Niemand noemt een datum. En daarom is niemand écht verantwoordelijk. Iedereen kan in dit scenario naar anderen wijzen en ontkennen dat zij een harde commitment hebben gegeven. Vergelijk dit met de gemiddelde freelancer: als ik een product bij hen bestel, krijg ik geheid een concrete datum. Waarom is dat?

 Scrum is het framework van abstracties geworden. We praten niet meer in weken, maar in sprints. Niet over features, maar over “epics” en “user stories”. Niet over uren, maar over “storypoints”. Wie is verantwoordelijk? “Het team”.

De vraag vanuit de PO aan het team “hoe gaan we dit oplossen?” is in deze opzet heel logisch — zij beheren immers de backlog — maar ‘het team’ is verantwoordelijk. Alle rituelen zijn hierop afgestemd: de stand-ups, de refinement-sessies, de retrospectives en de demo’s. Samen bepalen wat we gaan doen en samen proberen we verantwoordelijkheid te nemen. Een democratie waarin het team samen het beste eindresultaat behaalt.

Productontwikkeling is geen democratie

Het geheim zal ik hier verklappen: productontwikkeling is geen democratie. Het begint bij de vraag: “wie is écht verantwoordelijk?”. Of nog beter: “wie maken we verantwoordelijk?”. Die duidelijkheid is cruciaal. Waarom hebben de meeste freelancers hun individuele projecten op tijd af? Omdat het overduidelijk is wie verantwoordelijk is, en voor welk resultaat ze betaald worden. Waarom zijn goede founders zo belangrijk in startups? Zij zijn verantwoordelijk en zijn heel duidelijk in wat er af moet voor een bepaalde deadline. (Degenen die dat niet doen, zijn snel klaar.)

Wat werkt dan wél?
 In mijn projecten doen we geen stand-ups meer. Geen retrospectives. Geen refinements. We hebben het over features en deadlines. Over uren. En we voeren inhoudelijke discussies. We gebruiken Demo-Driven Development. De structuur is simpel: op maandag bepalen we wat we vrijdag gaan demo’en. Voor maandag 12 uur ‘committen’ individuen zich op specifieke onderdelen. Is er iets onduidelijk? Dan lossen we dat na de lunch op. Elke dag is er een check-in op Slack: gaat het goed? Vragen of hulp nodig? Iedereen kan op elk moment een meeting inschieten. Het voordeel: er zijn geen andere meetings, dus die tijd is er.

Leiderschap in plaats van rituelen

Elke week weet ik of we op schema liggen, want alles is opgedeeld in volle weken tot de deadline. Als we een demo-deadline missen, lopen we achter. Als iemand consistent deadlines mist, wordt diegene vervangen. Als motivatie of visie ontbreekt, geeft één persoon de mensen weer focus. Die persoon bewaakt het product, de visie, de deadline, het budget, enzovoort. In de filmindustrie noemen ze dat een regisseur. Product Owner is daarvoor te mager. Product Director is veel toepasselijker.

In een wereld waarin het maken van een proof-of-concept (technische toetsing van een idee) of een MVP (markttoets) een fluitje van een cent is geworden — met tools als Replit en Lovable — is het werk eindelijk gereduceerd tot het schaalbaar en met oog voor detail toepassen van ideeën. Als je dan vastzit aan een agile-methodiek die je overspoelt met abstracties, zijn zelfs die tools nutteloos. Je moet namelijk wel weten wat je moet prompten om tot een goed resultaat te komen.

Let bij de volgende stand-up maar op de volgende dingen: zijn teamleden concreet? Spreken ze in uren of dagen? Herhalen ze simpelweg de items van de dag ervoor? Krijg je beter zicht op waar het team mee bezig is en wat de status van het product is? Zijn we klaar binnen de afgesproken tijd? Een ‘nee’ op één van die vragen is voor mij vaak al een red flag. Dan is duidelijk leiderschap nodig om het project — én het product — weer recht te trekken. Leg de verantwoordelijkheid bij individuen die je hebt ingehuurd, en laat hen bepalen hoe ze het doen, binnen duidelijke kaders. Daarvoor heb je deze professionals immers aangenomen.

Natuurlijk kan dit binnen Scrum. Maar het hele framework introduceert onnodige abstracties. Het is al moeilijk genoeg om een product te bouwen — laat staan erover te praten als ‘normale’ mensen. Leg de verantwoordelijkheid bij een handjevol mensen, en je komt geheid verder dan het gemiddelde team dat zich aan Scrum-rituelen houdt. Wees helder in visie en verwachtingen, en je zult zien dat mensen veel makkelijker het doel volgen.

Demo-Driven Development: focus in actie

Demo-Driven Development is zeker niet het eindstation. Maar wat het binnen mijn teams deed, was adembenemend om te zien. De productiviteit ging omhoog, net als de oplossingsgerichtheid. Niemand werd afgeleid door andermans problemen. Geen (onnodige) meetings meer. Iedere minuut werd besteed aan hun ambacht en aan het product. Scrum, in de traditionele zin, heeft dit voor mij nooit bereikt. En daarmee is het wat mij betreft dood voor productontwikkeling.

Slotgedachte: kies, focus, lever
. Het gaat dus nooit écht over die tweehonderd backlog-items uit de inleiding. Het gaat over het feit dat niemand de leiding neemt en bepaalt welke twintig er worden opgepakt binnen de beschikbare tijd. Vraag jezelf: wat kan er wel? En creëer daarop focus. Zonder focus en visie kunnen je teamleden misschien wel gebruikmaken van AI, maar nooit weten hoe ze het optimaal inzetten in de juiste context. Perfect wordt het nooit. Maar als je met focus en visie shipt, dan kom je verdomd dichtbij.

Over de auteur: Arthur Stobbelaar is Co-founder en Technical Director bij Alpha Tango.