Scrum is nog helemaal niet dood

Mijn LinkedIn-feed weet het zeker: agile is dood, Scrum is dood, en de Product Owner mag zijn spullen pakken, want AI regelt het voortaan. Het klinkt lekker. Het past bij het gevoel dat alles op zijn kop staat.

Vorige week deed ik mee aan een hackathon. Een team van mensen, ieder met een stel agents, één halve dag, een product bouwen. Geen procesboek, geen ceremonie, geen bord met kolommen. Het opvallende was dat we toch begonnen met een plan en een doel. Een lijstje met to-do’s waar ieder werk van pakte. We lieten om de zoveel tijd zien wat we gemaakt hadden. En aan het eind keken we terug op hoe we hadden samengewerkt.

Niemand zei “Scrum”. We deden het gewoon, omdat het onder druk het eerste is waar je naar grijpt. Niet omdat het in een guide staat. Omdat het praktisch is.

De woorden verdwijnen, de principes niet

Dat is het misverstand achter al die grafstenen op LinkedIn. Wat sterft, zijn de woorden en de rituelen: het verplichte kaartjes-schuiven, de ceremonie om de ceremonie, de veertien dagen die “een sprint” heten omdat dat nu eenmaal zo hoort. Laten we eerlijk zijn: dat is de Scrum die dure consultants kwamen opleggen — de rituelen plichtmatig afgevinkt, en juist losgelaten waar ze pijn deden. Geen wonder dat het woord voor velen besmet raakte. Prima dat dat verdwijnt. Onder die woorden zit alleen een klein aantal principes die niets met mode te maken hebben, en alles met hoe mensen samen iets afkrijgen.

Begin met een gedeeld beeld van wat je maakt. Knip het op in stukken en werk van boven naar beneden. Voeg regelmatig samen en kijk of het werkt. Laat het aan echte gebruikers zien. Kijk terug op hoe je het deed. Dat is geen methodologie, dat is gezond verstand dat toevallig een naam heeft gekregen.

En juist nu de agents het typen overnemen, worden die principes niet minder belangrijk. Ze worden belangrijker. Want zoals ik in een vorige blog schreef, verdwijnt de typesnelheid als natuurlijke rem — en dan heb je iets anders nodig dat je op één lijn houdt. Eigenlijk is dat waar dit over gaat.

Begin met een gedeeld beeld, of ontwerp met overtuiging het verkeerde ding

Het duurde bij ons even voor we begonnen, en dat kwam niet door de techniek. Het kostte tijd om een gezamenlijk beeld te krijgen van het probleem dat we oplosten. Voor wie bouwen we dit? Wat telt voor die gebruiker? Hoe ziet dat er dan uit?

Vervelend, dat oponthoud, tot je bedenkt wat het alternatief is. Zonder die scherpte hadden vier mensen en een leger agents in razend tempo vier verschillende producten gebouwd. De onboarding, bijvoorbeeld, zag er totaal anders uit zodra we het eens waren over wie hem doorloopt. Was dat beeld er niet geweest, dan hadden we met veel energie en overtuiging het verkeerde ding gemaakt (en dat sneller dan ooit). Het is precies wat collega Michiel Kooiman het automatiseren van aannames noemt: met AI bouw je verkeerde aannames alleen maar sneller in.

Dit is het werk dat geen agent voor je doet. Een model bouwt wat je vraagt; het bepaalt niet óf het de moeite waard is. Dat oordeel — wat willen we, voor wie, en waarom dit en niet dat — is waar de waarde zit. Het is het fundament waarop al het andere rust.

De Product Owner is niet dood — hij is developer geworden

Dus nee, de rol die dat beeld bewaakt verdwijnt niet. Hij verandert van vorm.

Na de eerste fase zag je dat die pet rouleerde. Omdat we allemaal aan hetzelfde ding bouwden, pakte nu eens de een, dan weer de ander de taak om de losse delen op elkaar te laten aansluiten, niet met macht of een mandaat, maar met dialoog en voorbeelden. Het was geen aparte functionaris meer die op afstand prioriteiten roept. Het was iemand die meebouwde, meedacht over de techniek en tussendoor stuurde op samenhang. En dat die pet kon rouleren zonder in chaos te ontaarden, kwam door het gedeelde beeld van de eerste fase: als het doel eenmaal scherp en gedeeld is, hoeft niemand de richting met gezag af te dwingen. Dan bewaakt de visie zichzelf.

Vaak met niet meer dan een paar woorden. “Dat is mooi, daar meer van.” En: “Dit weet ik nog niet.” Dat laatste is genoeg om de agents een andere variant te laten proberen. Want het bouwen kost bijna niets meer, dus het duurste dat je kunt doen is de verkeerde dingen bouwen, netjes en snel.

En dat is wat me stoort aan de bewering “we hebben geen Product Owner meer nodig”. Het omgekeerde is waar. Toen bouwen de bottleneck was, kon je je een zwak product-oordeel veroorloven; er ging toch tijd overheen. Nu bouwen goedkoop is, wordt dat oordeel — wat is waardevol, wat niet — precies het schaarse goed. Je hebt die rol niet minder nodig. Je hebt hem harder nodig dan ooit.

Wie bewaakt hóe je samenwerkt?

Er was ook een rol die we lieten liggen: die van de man of vrouw die niet op de inhoud let, maar op de samenwerking zelf. Deels door de korte tijd, maar het bleef wel voelbaar.

Contact en korte demo’s waren er genoeg, dus helemaal blind waren we niet. Alleen: “ik loop vast” bleef een mededeling, geen startsein om te helpen. En niemand bewaakte het regelmatig samenvoegen, oftewel continuous integration (Kent Beck schreef het in 1999 op in Extreme Programming Explained — het idee is dus ruim een kwart eeuw oud). En als je sprint is gekrompen tot één dag, is “aan het eind samenvoegen” helemaal geen optie meer.

De teams die wél tot een product kwamen, organiseerden die bewaking. Pairen met z’n tweeën liep stroef; een team dat met z’n allen (mob programming) om één scherm ging zitten, hield vanzelf één ritme aan. En de teams die vooraf afspraken waar hun onderdelen elkaar raken (interface-first), hadden merkbaar minder ruis tussen de developers.

Het patroon is steeds hetzelfde: waar iemand bewaakte hóe het werk samenkwam, kwam het samen. Waar niemand dat deed, dreef het uit elkaar, vriendelijk en in hoog tempo.

Spreek af wat “goed” is

Eén afspraak misten we volledig: wat betekent “af”? Er was geen gedeelde lat voor kwaliteit. En dat is precies waarom de senioren aan het eind zeiden: leuk voor de demo, maar dit brengen we zo nooit naar productie.

Hier ligt een verrassend simpele winst, en meteen een nieuwe gewoonte voor het tijdperk van agents. Schrijf één bestandje — noem het quality.md — waarin je afspreekt wat kwaliteit voor dit product betekent en hoe je dat aantoont. Je deelt het met je teamleden, zodat iedereen dezelfde lat hanteert. Maar je geeft het óók aan je agents, die er vervolgens zelf tegen toetsen. Eén document dat mensen op één lijn houdt én machines stuurt.

En het sluit mooi aan op de andere bestandjes waarmee je grip houdt op je agents: de rol en grenzen die je vastlegt, de intentie die je vooraf bepaalt. Kleine, leesbare afspraken, gedeeld door mens en machine.

Scrum is dood. En dit werkt wel.

Vind je “Scrum” een besmet woord? Gooi het weg. Doe dan wel dit:

1. Begin met een gedeeld beeld van het probleem — voor wie, en wat telt. Wijs desnoods iemand aan die dat scherp formuleert en bewaakt.
2. Maak een lijstje van wat je wilt doen en deel het. Werk van boven naar beneden: het belangrijkste eerst.
3. Werk elke dag aan één concreet doel — en krijg dat af. Doe niet alles tegelijk; maak zaken echt klaar voor je iets nieuws begint.
4. Spreek af wat “goed” is en hoe je dat aantoont. Een lijstje met kwaliteitseisen, gedeeld met je mensen én je agents.
5. Voeg regelmatig samen en kijk of het werkt. Het werkende geheel is je bewijs, niet de losse stukken.
6. Laat het om de zoveel tijd aan echte gebruikers zien en vraag of dit is wat ze verwachten.
7. Kijk om naar elkaar en de samenwerking — en kijk daar periodiek op terug om het beter te maken.

Het komt je vast ergens bekend voor.

De bottom line

Wat sterft is niet Scrum. Het is de karikatuur ervan: proces als ritueel, agile als aftekenlijstje. Goede riedels, weg ermee. De kern blijft staan — een gedeeld doel, werk in behapbare stukken, regelmatig samenvoegen, aan gebruikers tonen, terugkijken op je samenwerking. Dat is geen relikwie uit het tijdperk van trage teams. Het is het steigerwerk dat je juist nu nodig hebt.

Want de agents hebben één ding weggenomen: bouwen is niet langer het moeilijke deel. En alles wat daardoor overblijft — weten wát je wilt, het eens worden, bewaken dat het samenkomt, afspreken wanneer het goed genoeg is — is exact waar Scrum altijd al over ging.

De Product Owner is niet overbodig geworden. Hij is onmisbaar geworden: nu bouwen bijna niets meer kost, is de duurste fout die je kunt maken de verkeerde dingen bouwen — en bepalen wat wél de moeite waard is, doet geen agent voor je. En dat proces dat volgens je tijdlijn dood is? Dat deed je vorige week nog, zonder het door te hebben.

‍