Waarom agile transformaties stranden op de laag waar niemand coacht
Veel organisaties zitten in dezelfde vreemde situatie. De handboeken zijn keurig gevolgd. Er zijn stand-ups, er is een backlog, er zijn retrospectives, er hangen post-its. Op papier is de organisatie agile.
En toch duurt het nog steeds maanden voordat een idee live staat. Besluiten laten op zich wachten. De afstand tussen business en IT is niet kleiner geworden, eerder groter.
De meeste verklaringen die je hiervoor hoort, wijzen naar de teams. Ze zouden de methode niet goed genoeg toepassen, meer training nodig hebben, of hun mindset moeten veranderen. In mijn ervaring klopt die verklaring bijna nooit. De teams zijn zelden het probleem. Ze zijn de plek waar het probleem zichtbaar wordt.
Een organisatie is namelijk geen stapel afdelingen die je los van elkaar kunt verbeteren. Het is een socio-technisch systeem: de manier waarop mensen samenwerken en sturen hangt vast aan de manier waarop de systemen, de architectuur en de pijplijnen gebouwd zijn. Je kunt die twee helften niet apart afstellen. Als de sturing niet aansluit op de techniek, of als de technische basis de beloofde snelheid niet kan dragen, loopt de machine vast — hoe goed de ceremonies ook worden uitgevoerd.
Om dat bespreekbaar te maken gebruik ik een model dat ik de socio-technische machine noem. Vier lagen, die alleen samen werken.
De vier lagen
Ik beschrijf ze hier van boven naar beneden, omdat dat de volgorde is waarin bestuurders ernaar kijken. Gebouwd wordt de machine juist andersom: van onderen af.
Strategische coaching — coach het systeem, niet alleen het team
Hier zit de besturing: hoe werk wordt gefinancierd, geprioriteerd en begrensd. Dit is de laag die het vaakst wordt overgeslagen, en tegelijk de laag waar de meeste vertraging vandaan komt. Een team kan een probleem dat in de organisatiestructuur of het financieringsmodel zit niet zelf oplossen, hoe volwassen het ook is.
Waar ik naar kijk:
- Financier waardestromen, geen projecten. Traditioneel portfoliomanagement financiert tijdelijke projecten met steeds wisselende teams. Wendbaar management financiert stabiele, multidisciplinaire teams en brengt het werk naar hen toe. Dat scheelt niet alleen opstartverlies; het is het verschil tussen kennis die zich opbouwt en kennis die elke keer opnieuw wordt weggegooid.
- Stuur op uitkomst, niet op opgeleverde features. Een lijst van vijftig features is een plan, geen doel. Wat je wilt weten is wat er voor de klant verandert.
- Begrens onderhanden werk, ook op portfolioniveau. Teams die hun werk in uitvoering beperken leveren sneller op. Voor initiatieven op portfolioniveau geldt precies hetzelfde, en daar wordt het bijna nooit gedaan. Alles tegelijk starten is de duurste manier om alles te vertragen.
- Een methode is een steiger, geen gebouw. Scrum, Kanban, SAFe — het zijn hulpmiddelen om flow te bereiken. Ik pas ze aan op de context, en ik laat ze los waar ze niet passen.
Agile product en strategie — de koers
Zodra de kaders staan, moet per product de richting worden bepaald. Dat is werk van business, product en engineering samen.
- Organiseer teams op cognitieve belasting. Team Topologies geeft hier de bruikbaarste taal voor: teams die direct op een klantervaring zitten, ondersteund door platformteams die complexiteit wegnemen en aanbieden als een dienst die makkelijk te gebruiken is. Het doel is niet een mooi organogram maar zo min mogelijk afhankelijkheden per stap.
- Formuleer ideeën als hypothese. We denken dat deze verandering voor deze gebruikers tot dit gedrag leidt, en dat meten we zo. Niet omdat het wetenschappelijk moet, maar omdat het het gesprek verplaatst van wie het hardst roept naar wat we straks weten.
- Valideer voor je breed uitrolt. Grote of risicovolle wijzigingen eerst op een klein deel van de gebruikers. Investeren in testinfrastructuur verlaagt de kosten per experiment, en daarmee stijgt het aantal dingen dat een organisatie per jaar kan leren.
DevOps en continuous delivery — de motor
Een goede productstrategie is waardeloos als de software daarna maanden op de plank ligt.
- Trunk-based development. Meerdere keren per dag samenvoegen naar de hoofdlijn, in plaats van langlopende branches die eindigen in een pijnlijke integratie.
- Ontkoppel deployment van release. Met feature toggles en canary releases zet je code continu en geruisloos in productie, terwijl je de functionaliteit pas aanzet wanneer het uitkomt en voor wie je kiest. Dat verkleint de schade als er iets misgaat.
- Automatiseer het terugdraaien. Richt monitoring zo in dat de pijplijn binnen seconden terugvalt op de vorige stabiele versie zodra kritieke drempels worden overschreden.
- Gebruik de DORA-metrieken als kompas. Deployment frequency, lead time for changes, change failure rate en failed deployment recovery time. Vier getallen die snelheid en stabiliteit tegen elkaar in balans houden, zodat je niet het ene kunt kopen met het andere.
XP en engineering excellence — de basis
Zonder solide technische basis zakt de rest in elkaar. Ligt de code in de knoop, dan vertraagt elk proces dat je eroverheen legt uiteindelijk mee.
- Test-driven development. Tests schrijven vóór de productiecode. Dat levert een vangnet tegen regressie op, en het dwingt tot een modulaire opzet, omdat code die lastig te testen is meestal ook lastig te veranderen is.
- Pair- en mob-programming. Twee of meer engineers tegelijk aan hetzelfde werk. Management ziet dat soms als verlies van capaciteit; in de praktijk vervangt het de wachttijd op reviews door directe kennisdeling. Het is wel intensief, en het vraagt een team waarin mensen zich veilig genoeg voelen om hardop te zeggen het niet te weten.
- Doorlopend refactoren. Laat de code bij elke wijziging iets schoner achter dan je hem aantrof. Dat is wat voorkomt dat technische schuld zich opstapelt tot het punt waarop alleen een dure herbouw nog helpt.
Waar de machine knelt
Transformaties mislukken zelden door gebrek aan goede wil. Ze mislukken omdat de lagen niet op elkaar aansluiten. Drie knelpunten die ik telkens terugzie.
De wachtrij voor de governance
Een team bouwt en test een belangrijke wijziging in twee dagen, met kleine stappen en een goed ingerichte pijplijn. Daarna staat die wijziging negen dagen stil, wachtend op een handmatige beoordeling.
De verleiding is om de governance dan als de tegenstander te zien. Dat is een denkfout, en in een gereguleerde omgeving een gevaarlijke. De controle is er niet voor niets. Wat niet deugt, is dat hij handmatig is uitgevoerd.
Ik heb dit opgelost door de pijplijn te koppelen aan het change management-proces zelf. Beveiligings- en compliancecontroles verplaatsen naar het moment van committen, en het bewijs daarvan automatisch vastleggen. De doorlooptijd ging omlaag én het auditspoor werd beter dan het handmatig ooit was geweest — juist omdat een machine niets vergeet vast te leggen. Beheersing en snelheid zijn hier geen tegenpolen. Ze versterken elkaar zodra je de controle automatiseert in plaats van hem te omzeilen. Meer weten CI/CD, branch protection en ITIL change management: DevOps in de praktijk met GitLab (deel 3 van 3)
Het gevecht tussen deadline en kwaliteit
Product wil een datum. Engineering zegt dat de architectuur het niet aankan zonder eerst opruimen. Onder tijdsdruk wint de datum. De feature komt op tijd, de schuld stijgt, en de doorlooptijd van álles wat erna komt gaat omhoog. Het voelt persoonlijk, want de business snapt de techniek niet en IT is altijd traag.
Wat hier werkelijk gebeurt, is dat het gevolg ergens anders landt dan het besluit. Product is eigenaar van de datum, engineering van de nasleep. Wie de rekening betaalt, heeft de keuze niet gemaakt.
Ik stop daarom met de morele discussie. We moeten het goed doen wint het nooit van een datum. In plaats daarvan zet ik het opruimwerk op hetzelfde bord als de features en druk ik de schuld uit in levertijd: als we dit niet doen, stijgt onze lead time en gaat onze change failure rate omhoog. Zodra beide kanten naar dezelfde cijfers kijken, verdwijnt het gevecht en ontstaat een gezamenlijk besluit. Meestal blijkt dan dat geen van beide partijen wilde wat de ander dacht.
De ceremonies zonder motor
Er is fors geïnvesteerd in agile trainingen. Iedereen doet stand-ups, plant sprints en vult het ticketsysteem netjes in. En er wordt nog steeds één keer per kwartaal naar productie gebracht, in een weekend, met een kamer vol mensen die klaarzitten voor als het misgaat.
Scrum zonder technische kwaliteit is een lege huls. Wil je vaker leveren, dan is meer procesdiscipline niet het antwoord. Dan moet er geïnvesteerd worden in testautomatisering, in gefaseerde uitrol en in geautomatiseerd terugdraaien. Pas als engineers erop durven vertrouwen dat het vangnet er is, verdwijnt de angst — en pas dan gaat de frequentie omhoog.
Twee dingen die in geen enkel handboek staan
Een cijfer dat je niet veilig eerlijk kunt invullen, is slechter dan geen cijfer.
Ik heb metingen geïntroduceerd die niets in beweging brachten. De getallen kwamen gepolijst terug. Teamleden waren bang dat een lage score op hen terug zou slaan; leiders vermeden toezeggingen waarop ze konden worden afgerekend. Wat overbleef was een nulmeting waar niemand in geloofde, en dat is erger dan niets meten — je denkt nu dat je weet waar je staat.
Wat het doorbrak was niet een betere meetmethode. Het was leiders die hardop, in het bijzijn van hun teams, benoemden waar ze zich wel en niet aan wilden committeren en waarom. En een assessment waarin teams ook hun leiders scoorden, zodat het een gesprek werd in twee richtingen in plaats van een inspectie. Sindsdien controleer ik op veiligheid vóórdat ik een metriek introduceer, niet erna.
Zonder eigenaarschap geen verandering.
Agile adoptie is niet iets van de teams. Als alleen zij veranderen en het systeem eromheen blijft belonen wat het altijd beloonde, is het binnen twee kwartalen weggezakt. Het draagvlak zit in wat managers vragen en hoe ze reageren op slecht nieuws. Daar gaat dus het grootste deel van mijn energie naartoe — niet naar de teams.
Er is geen gouden pad
Er bestaat geen blauwdruk die overal werkt. Zelfs binnen één organisatie niet. Zoom uit naar een bedrijf met duizenden medewerkers en je ziet zelden een homogene massa: afdelingen die volledig cloud-native werken met autonome teams, naast afdelingen die zware verouderde systemen beheren waar elke release inherent ingewikkelder is.
Daarom geloof ik niet in opgelegde papieren normen. Wie belooft dat elk team binnen zes maanden op volwassenheidsniveau 4 zit, verkoopt een illusie. Ik heb liever een eerlijke, betrouwbare 2,5 op een schaal van 4 — waarbij we precies weten waar de pijn zit en wat we eraan doen — dan een gepolijste 4 op een slide. Zo’n 4 veronderstelt bijvoorbeeld volledige continuous delivery, en dat is voor een team met verouderde systemen simpelweg nog niet haalbaar. Een score die niet klopt, kost je bovendien het enige wat een meting waard maakt: dat mensen erin geloven.
Je moet de organisatie ontmoeten waar ze werkelijk staat, team voor team, en samen zoeken naar de kleinste verandering die de meeste flow oplevert.
Hoe ik werk
Ik ben begonnen als analist-programmeur en heb me via consultancy, projectleiding, architectuur en programmamanagement naar coaching bewogen, niet andersom. Ik heb de rollen gedaan van de mensen die ik nu begeleid: de engineer die vastloopt op een deployment, de productmanager die zijn roadmap moet verdedigen, de directeur die verantwoordelijk is voor het budget. Dat is de reden dat de gesprekken landen — niet mijn certificaten.
Verder houd ik mijn handen aan de tools. In mijn eigen lab bouw en breek ik wat ik adviseer: pijplijnen, clusters, identity, failover tussen clouds. Ik wil kunnen uitleggen hoe iets werkt, niet alleen hoe het zou moeten werken.
En ik werk vanaf dag één toe naar mijn eigen vertrek. Ik co-faciliteer met mensen uit de organisatie zelf, de spullen staan in hun tooling en niet in mijn map, en de agenda komt uit een zelfevaluatie die de teams zelf uitvoeren. Als ik weg ben, staat het mechanisme er nog.
Tot slot
Grote technologische veranderingen — een migratie naar de cloud, de stap naar een productgestuurde DevOps-organisatie, het opnieuw inrichten van de besturing — lopen zelden vast op techniek alleen, en ook zelden op mensen alleen. Ze lopen vast op de naad ertussen.
Als je vermoedt dat dat bij jou speelt, praat ik daar graag over door met je. Zonder verplichtingen en zonder deck.
Bertrand de Neve
Disclaimer
Dit artikel is uitsluitend bedoeld voor informatieve en educatieve doeleinden. Het beschrijft persoonlijke ervaringen en werkwijzen uit eigen opdrachten en uit een eigen onderzoeks- en leeromgeving. Het is geen onderzoeksrapport, geen benchmarkstudie en geen leveranciersadvies.
De beschreven voorbeelden zijn geanonimiseerd en losgemaakt van hun oorspronkelijke context. Genoemde uitkomsten — waaronder volwassenheidsscores, doorlooptijden en de effecten van interventies — zijn momentopnamen uit specifieke organisaties, met hun eigen techniek, geschiedenis en cultuur. Ze zijn niet zonder meer generaliseerbaar en niet bedoeld als norm of streefwaarde. Een schaalverdeling van een volwassenheidsmeting ontleent haar betekenis bovendien volledig aan de definities die een organisatie er zelf aan geeft; dezelfde score betekent elders iets anders.
Het model van de socio-technische machine is een eigen werkmodel om het gesprek te structureren, geen gestandaardiseerd of gecertificeerd raamwerk. Verwijzingen naar methoden, frameworks, metrieksets en praktijken — waaronder Scrum, Kanban, SAFe, Extreme Programming, Team Topologies, ITIL en de DORA-metrieken — zijn feitelijk bedoeld en impliceren geen aanbeveling of afkeuring. Namen en merken zijn eigendom van hun respectieve rechthebbenden. Frameworks en hun publicaties worden periodiek herzien; raadpleeg bij toepassing altijd de meest recente officiële bronnen.
Waar dit artikel spreekt over het automatiseren van controles in de keten van change management, security en compliance geldt een belangrijke nuance: automatisering verplaatst de uitvoering van een controle, niet de verantwoordelijkheid ervoor. Welke controles in uw situatie vereist zijn, en hoe u de werking daarvan moet kunnen aantonen, hangt af van uw sector, uw toezichthouder en uw eigen beheersingskader. De auteur is architect en transformatiecoach, geen jurist, accountant of auditor. Voor toepassing in een gereguleerde omgeving wordt professioneel en, waar relevant, juridisch of audit-advies aanbevolen.
Aan de inhoud van dit artikel kunnen geen rechten worden ontleend. De auteur aanvaardt geen aansprakelijkheid voor directe of indirecte schade die voortvloeit uit het gebruik van de beschreven informatie, modellen of werkwijzen.
Dit artikel is tot stand gekomen met assistentie van een AI-systeem. De onderliggende ervaring, de inhoudelijke keuzes, de conclusies en de eindredactie zijn volledig van de auteur.