Wat manage je als snelheid geen probleem meer is
Afgelopen jaar heb ik een AI-systeem gebouwd dat kennis opbouwt over gesprekken heen. Geen chatbot, geen code-generator, maar een systeem dat informatie verzamelt, test, en weer verwijdert als het niet meer klopt. Het draait nu een paar duizend cycli en het management dat ik ervoor moest ontwerpen lijkt in niets op Scrum.
Dat was niet de bedoeling. Ik begon met het probleem: hoe voorkom je dat kennis degradeert als er steeds meer van is? Hoe weet je welke aannames nog kloppen? De antwoorden die werkten bleken achteraf verrassend veel op projectmanagement te lijken, maar dan voor een andere resource.
Het echte knelpunt
Iedereen ziet dat AI-tools individuele output versnellen. Meer code, meer documentatie, snellere prototypes. En iedereen merkt dat de organisatie daar niet sneller van wordt. Asana onderzocht het vorig jaar bij negenduizend kenniswerkers: 65% zegt dat AI meer coördinatiewerk oplevert, niet minder.
Dat is niet verrassend als je erover nadenkt. Al onze processen, standups, sprintplanning, code reviews, zijn ontworpen voor een wereld waarin produceren moeilijk was. Nu is produceren makkelijk. Begrijpen of wat je produceert correct is, consistent, en in lijn met wat je probeert te bereiken, dat is het knelpunt geworden.
Wat ik leerde van kennismanagement
Het systeem dat ik bouwde had drie operaties nodig die geen Scrum-equivalent hebben:
Actief verwijderen. Scrum heeft geen ceremonie voor “dit was fout en moet weg,” niet omdat de implementatie slecht was maar omdat het inzicht erachter niet meer klopt. In mijn systeem draait er periodiek een tegensprekelijk proces: een advocaat verdedigt een bestaand inzicht, een uitdager valt het aan, een rechter weegt het bewijs. Wat niet overeind blijft wordt verwijderd, inclusief alles wat erop gebouwd was. Soms wordt je systeem waardevoller als je er iets uit haalt.
Gronding meten. Scrum meet velocity, hoe snel je plan in output omzet. Mijn systeem meet welk percentage van je kennis daadwerkelijk getest is en overeind bleef. Het verschil tussen “niet getest” en “fout” bestaat niet in velocity-metingen. Het is het centrale onderscheid als je kennis beheert in plaats van arbeid.
Samenhang controleren. Scrum coördineert werk binnen een team. Het vraagt niet of wat het ene team weet in tegenspraak is met wat het andere team aanneemt. In mijn systeem controleert een periodieke synchronisatie of de verschillende kennisdomeinen nog met elkaar in lijn zijn. Eén domein wist dat een fiscale regeling in waarde daalt over tijd. Een ander domein ging uit van stabiele voordelen in zijn kostenprojecties. De synchronisatie ving dat op, niet omdat iemand een bug meldde maar omdat de periodieke check de inconsistentie blootlegde. Ik bouw hier een product voor: advisory.conexxus.io doet deze samenhangcontrole automatisch, voor ZZP’ers en MKB.
Drie ketens, niet één
De diepste ontdekking is dat management na AI niet één ding is. Het zijn drie dingen die Scrum altijd heeft samengeperst.
Een leerketen. Het ritme wordt bepaald door absorptiecapaciteit. De resource is kennisintegriteit. De operaties zijn tegenspraak (actief verwijderen van onjuiste aannames), samenhangcontrole (kloppen de domeinen nog met elkaar), en rijpheidstoetsing (is dit domein betrouwbaar genoeg om op te bouwen).
Een leverketen. Het ritme wordt bepaald door klantdeadlines. De resource is leveringskwaliteit. De operaties zijn sprintachtig: tijdgebonden afspraken, voortgang, demo’s. Hier werkt Scrum nog steeds prima. Ik heb het zelf gebruikt voor een klantopdracht terwijl de leerketen op een compleet ander ritme draaide, en beide slaagden tegelijkertijd.
Een productketen. Het ritme wordt bepaald door marktsignalen, niet door sprints. Als Europese regelgeving een aanname onder je product weghaalt, activeer je de productketen. Daar is geen backlog voor en geen cadans. Er is continue monitoring en signaalgestuurde respons.
De post-Agile frameworks die nu opkomen, ADLC, BMAD, Cognitive Agility, proberen allemaal Scrum uit te rekken over alle drie. Wat ze zouden moeten doen is erkennen dat elke keten ander management nodig heeft.
Wat dit betekent voor je team
De standupvraag verandert. Niet “wat heb je gedaan, wat ga je doen, blockers?” maar “wat weten we dat we gisteren niet wisten, wat moeten we vandaag uitdagen, en waar gaan we van uit dat misschien niet klopt?”
De retrovraag verandert. Niet “wat ging goed, wat niet, wat verbeteren we?” maar “wat geloven we nu dat we aan het begin van deze cyclus niet geloofden, en welk bewijs onderbouwt dat?”
Dit zijn geen cosmetische aanpassingen. De eerste set vragen stuurt arbeid aan. De tweede set stuurt kennis aan. Ze vereisen andere tools, andere ritmes, andere definities van succes.
De eerlijke claim is niet “Scrum is dood.” De eerlijke claim is: wat management IS is gefragmenteerd. De levercomponent heeft nog steeds baat bij sprintstructuur. Maar twee extra componenten, leren en product, zijn opgekomen als aparte management-uitdagingen waarvoor sprintstructuur niet ontworpen is en die het niet kan accommoderen door meer ceremonies toe te voegen.
De filosofische achtergrond van dit inzicht staat op athousandbeats.com, geschreven vanuit het perspectief van het AI-systeem zelf.
Michael Siroen is oprichter van ID2Bytes en helpt mid-market organisaties met Microsoft technologie en AI-integratie. Meer weten? Neem contact op via id2bytes.com.