Hoe bouw je een sterke DevOps-organisatie?

Een vraag die elke IT-manager zou moeten stellen

Stel je voor: je bent twee jaar geleden gestart met een digitale transformatie. Er zijn agile coaches ingehuurd. De teams werken in sprints. Er is een CI/CD-pipeline. En toch: de deployment frequency is nauwelijks veranderd. Kritieke releases gaan nog altijd gepaard met nachtdiensten. Engineers vertrekken sneller dan ze worden aangenomen. En het management vraagt zich af wat er mis is gegaan.

Hier is het antwoord dat de meeste organisaties niet willen horen: er is niets mis gegaan. Er is iets blijven liggen. Teams werken agile, maar de architectuur is monolithisch. Er is een pipeline, maar operations zit nog altijd in een aparte silo. Er zijn retrospectives, maar de uitkomsten verdwijnen in een backlog die niemand prioriteert. De transformatie is gestart, maar nooit voltooid.

“Wij begeleiden al jaren teams in verschillende branches. Het patroon dat wij keer op keer zien is niet dat mensen het verkeerd doen. Het is dat ze halverwege stoppen.”

— Cris Cadinu & Armand La Rose, trainers Agile Fanatics

We nemen je mee langs drie principes die in de literatuur bekend staan als de Three Ways. Elk principe legt een andere laag van hetzelfde probleem bloot. Samen vormen ze de verklaring voor waarom sommige Tech-organisaties structureel excelleren en de meeste dat niet doen.

Wie vertelt dit verhaal?

Cris Cadinu en Armand La Rose zijn trainers bij Agile Fanatics. Ze begeleiden teams bij grote Nederlandse organisaties, waaronder ING, Defensie en Rabobank, op het snijvlak van technologie, structuur en samenwerking. Wat je in dit artikel leest, is de neerslag van wat zij in de praktijk hebben zien werken, en hebben zien mislukken.

Agile Fanatics werkt vanuit een overtuiging die teruggaat op meer dan tien jaar aan aanwijzingen uit onderzoek en praktijk. In veel organisaties zit de bottleneck vooral in structuren, prioritering en samenwerking. Organisaties zijn in hoge mate maakbaar—maar binnen context, kaders en volwassenheid.

Voor wie is dit?

Dit artikel is geschreven voor Tech-leiders en IT-managers die technologie serieus nemen als concurrentiefactor. Niet voor engineers die al weten wat DevOps is, maar voor de mensen die de condities moeten scheppen waaronder engineers hun beste werk kunnen doen. Als jij degene bent die beslist over structuur, budget en prioriteiten: dit is voor jou.

En misschien herken je de situatie die we aan het begin beschreven. Dat is geen toeval. Het is het meest voorkomende patroon dat wij zien. Het goede nieuws: het is oplosbaar.

Waarom veel DevOps-transformaties mislukken

De meeste organisaties die aan een Tech-transformatie beginnen, doen dat met de beste bedoelingen en een realistisch budget. Ze implementeren agile-werkwijzen, organiseren hun CI/CD, huren specialisten in. Twee jaar later zijn de resultaten teleurstellend. Niet rampzalig. Gewoon: teleurstellend.

Wat er dan is gebeurd, is bijna altijd hetzelfde. De transformatie is gestart op het niveau van de teams, maar de organisatiestructuur, de architectuur en de leiderschapscultuur zijn niet meebewogen. Teams werken agile, maar moeten voor iedere release wachten op een aparte operations-afdeling. Er is een pipeline, maar feedback komt nooit terug bij de mensen die de code schrijven. Er zijn retrospectives, maar de uitkomsten verdwijnen in een backlog die niemand prioriteert.

“Een gedeeltelijke implementatie van DevOps is soms gevaarlijker dan geen implementatie. Je hebt de overhead van de nieuwe werkwijze zonder de voordelen ervan.”

— Matthias Patzak & Sophie Seiwald-Højer, All Hands on Tech

De Three Ways van DevOps

De patronen zijn gecodificeerd in het DevOps Handbook en empirisch bevestigd door meer dan tien jaar onderzoek van het DORA-programma: een van de meest omvangrijke meerjarige onderzoeksprogramma’s naar software delivery performance. Ze staan bekend als de Three Ways: Flow, Feedback en Continual Learning and Experimentation. Het zijn drie lagen van hetzelfde systeem. En dat systeem werkt alleen als alle drie aanwezig zijn. Deze principes zijn de kern van dit artikel.

Flow: hoe werk sneller naar productie stroomt

Van idee naar gebruiker, zonder oponthoud

De les van de productielijn

Om te begrijpen wat flow betekent in een Tech-organisatie, moet je terug naar een Japanse autofabriek in de jaren vijftig. Toyota ontdekte iets dat destijds radicaal was: de prestatie van een organisatie wordt niet bepaald door de som van individuele inspanningen, maar door de kwaliteit van het systeem waarbinnen mensen werken.

Het cruciale inzicht was dat lokale optimalisatie, een afdeling die haar eigen werk zo efficiënt mogelijk doet, het systeem als geheel kan verslechteren. Een productiestap die razendsnel werkt maar output aflevert die de volgende stap niet aankan, creëert opstoppingen. Grote batches die lang worden vastgehouden voor een grote release, stapelen risico op. De enige zinvolle optimalisatievraag is: hoe snel en betrouwbaar stroomt waarde van begin naar einde?

Dat principe: flow boven lokale optimalisatie, is de kern van wat we nu Lean noemen. En het is ook de kern van The First Way in DevOps: maximaliseer de snelheid en betrouwbaarheid van de stroom werk van ontwikkeling naar productie. Elimineer alles wat die stroom vertraagt of verstoort: grote batches, handoffs tussen silo’s, goedkeuringsloops, wachtrijen.

Conway’s Wet als ontwerpwapen

Flow in software is echter fundamenteel anders dan flow op een productielijn, omdat software wordt gebouwd door mensen van wie de onderlinge communicatiestructuur de architectuur van het systeem bepaalt. In 1967 observeerde Melvin Conway iets simpels maar verstrekkends: organisaties produceren systemen die hun eigen communicatiestructuur weerspiegelen. Drie teams aan één systeem? Dan krijg je een systeem met drie componenten, met alle koppelingen en coördinatiepijn die daarbij hoort.

Conway’s Wet is een ontwerpinstrument. Als je wilt dat je software modulair, snel deploybaar en goed onderhoudbaar is, moet je jouw teams zo structureren dat hun grenzen die eigenschappen mogelijk maken. Architectuurbeslissingen zijn organisatiebeslissingen. En omgekeerd.

Dit is precies wat Matthew Skelton en Manuel Pais uitwerken in Team Topologies: een model voor organisatieontwerp dat Conway’s Wet serieus neemt. Het fundament is het Stream-aligned team, een duurzame, multidisciplinaire groep die volledig eigenaar is van één Value-stream, van idee tot productie-deployment. Een permanent team met diep domeinbegrip, volledige verantwoordelijkheid en de autonomie om zelfstandig te deployen. Duurzaam ingericht, niet tijdelijk ingezet.

Drie ondersteunende teamtypen maken die autonomie mogelijk zonder dat elk team het wiel opnieuw uitvindt. 

• Het Platform team levert self-service infrastructuur als intern product, zodat Stream-aligned teams niet hoeven te wachten op gedeelde resources. 
• Het Enabling team brengt tijdelijk specialistische kennis rond testautomatisering, security of observability, en werkt expliciet aan zijn eigen overbodigheid. 
• Het Complicated subsystem team beheert technisch hoogcomplexe onderdelen via heldere interfaces, zodat de complexiteit ervan niet lekt naar teams die zich op klantwaarde moeten richten.

“The goal of the First Way is to make work visible, reduce batch sizes, and eliminate rework. The result is a smooth, fast flow of value to the customer.”

— Gene Kim et al., The DevOps Handbook

Wat de data zegt over flow

Het DORA-programma (DevOps Research and Assessment) heeft de afgelopen tien jaar gegevens verzameld van tienduizenden teams wereldwijd. De throughput-metrics die zij hanteren zijn de meest gevalideerde maatstaven voor flow die beschikbaar zijn: lead time for changes (hoe lang duurt het van een commit tot een productie-deployment?), deployment frequency (hoe vaak deployt een team naar productie?) en failed deployment recovery time (hoe snel herstelt een team na een mislukte deployment?).
Gebruik deze metrics op service-niveau en over tijd; niet om individuen af te rekenen.

De spreiding tussen toppresteerders en achterblijvers is niet marginaal: het is een ander paradigma. Toppresterende teams meten lead time in uren en deployen meerdere keren per dag. Achterblijvende teams meten lead time in weken of maanden en deployen maandelijks of minder. En hier weerleggen de data een van de hardnekkigste misvattingen in de sector: teams die het vaakst deployen hebben óók de laagste fail-percentages. Frequente, kleine releases zijn minder riskant dan zeldzame, grote releases. Wie maandelijks deployt om risico te beperken, stapelt juist risico op.

CASE: ING Bank, Financiële dienstverlening

ING begon in 2015 met het vervangen van haar traditionele IT-hiërarchie door autonome, multidisciplinaire squads gegroepeerd in tribes, met gedeelde platforms en chapters voor vakinhoudelijke ontwikkeling. Een belangrijk element was het vergroten van end-to-end ownership (incl. run/monitoring/incident-respons) binnen teams.
Het gevolg was dat de architectuur moest volgen. Monolithische systemen werden opgeknipt in onafhankelijk deploybare services, niet omdat het technisch mooi was, maar omdat de teamstructuur het vereiste. Conway’s Wet werkte in hun voordeel: de modulaire organisatie produceerde modulaire software, en die modulaire software maakte snelle, veilige deployments mogelijk.

De transformatie slaagde omdat zij niet stopte bij de teamindeling. Architectuur, budgettering en leiderschapsontwikkeling werden gelijktijdig aangepast, een consequentie die de meeste vergelijkbare programma’s missen.

Feedback: waarom snelle signalen cruciaal zijn in DevOps

Snel weten wat er misgaat, voor de klant het weet

Flow zonder feedback is blind vliegen

The Second Way gaat over het creëren van snelle, directe feedbackloops op elk niveau van de waardeketen: van de productie-omgeving terug naar de engineer die de code schreef, van de klantervaring terug naar het team dat de feature bouwde, van het incident terug naar het architectuurbesluit dat het veroorzaakte.

Gene Kim en Steven Spear introduceren in ‘Wiring the Winning Organization’ het concept van amplification: het vermogen van een organisatie om zwakke signalen op te pikken vóórdat ze grote problemen worden. Toyota legde de productielijn stil bij elk defect, om te leren. Een kleine verstoring die direct zichtbaar is, kost minuten. Dezelfde verstoring die pas zichtbaar wordt in productie, bij de klant, kost uren of dagen en beschadigt klantvertrouwen.

Amplification vereist twee dingen die in de meeste organisaties ontbreken: technische zichtbaarheid en psychologische veiligheid. Technische zichtbaarheid betekent dat je weet wat er in je systemen gebeurt (monitoring, alerting, observability) en dat die informatie terechtkomt bij de mensen die er iets mee kunnen doen. Psychologische veiligheid betekent dat mensen problemen durven aan te kaarten zonder angst voor consequenties. Zonder beide is amplification onmogelijk.

De organisatie als feedbackmachine

Feedback is ook de reden waarom platform engineering zo bepalend is voor de prestaties van een Tech-organisatie. Het DORA 2025-rapport toont aan dat negentig procent van de onderzochte organisaties platform engineering heeft ingevoerd, maar dat de kwaliteit van dat platform sterk uiteenloopt. Organisaties die hun interne platform behandelen als een echt product, met gebruikersfeedback, developer experience-scores en expliciete roadmaps, presteren significant beter op alle delivery metrics.

Dit is geen toeval. Een kwalitatief platform verkort niet alleen de lead time. Het creëert ook een feedbackloop tussen de teams die de infrastructuur bouwen en de teams die er dagelijks op werken. Die feedback maakt het platform beter, wat de autonomie van productteams vergroot, wat de deployment frequency verhoogt, wat meer feedback genereert. Het is een versterkende cyclus, maar alleen als de loop gesloten is.

“High performers aren’t high performers because they have fewer problems. They’re high performers because they find and fix problems faster.”

— Gene Kim et al., The DevOps Handbook

Wat de data zegt over feedback

DORA gebruikt instability-metrics als proxy voor hoe snel je fouten opspoort en corrigeert: change fail rate (welk percentage van deployments vereist directe interventie?) en rework rate (welk deel van de deployments is ongepland, als gevolg van een productie-incident?). Hoge scores op deze metrics wijzen op een organisatie die problemen pas ontdekt nadat ze al in productie zitten, een systeem zonder effectieve feedbackloops.

De data onthult ook iets dat minder voor de hand liggend is. Organisaties die structureel lage change fail rates hebben, bereiken dat niet door vaker te testen vóór een release. Ze bereiken het door kleine, frequente releases te doen die elk zo weinig verandering bevatten dat de impact van een fout beperkt en voorspelbaar is. Feedback werkt niet alleen als reparatiemechanisme: het werkt als preventie.

CASE: Eurofins, Milieu & Laboratoriumdiensten

Eurofins is een internationaal laboratoriumnetwerk dat wereldwijd analytische diensten levert voor milieu, voeding en farmaceutische producten. Snelheid en betrouwbaarheid van data zijn er bedrijfskritisch: klanten nemen op basis van testresultaten beslissingen over veiligheid en compliance.

Bij een DevOps-traject bij Eurofins werd het team ingericht met end-to-end verantwoordelijkheid: van ontwikkeling tot en met monitoring in productie. Feedback was een bewuste ontwerpbeslissing, vanaf dag één ingebouwd in de werkwijze. Het team zat wekelijks met de klant om feedbackloops bewust kort te houden: wat werkte, wat niet, wat moest anders. Die cadans dwong het team om kleine, toetsbare stukken op te leveren in plaats van grote releases die lang op validatie wachtten.

De technische keuzes versterkten die aanpak. Een modulaire architectuur zorgde ervoor dat wijzigingen in één onderdeel geen risico vormden voor de rest van de applicatie. Monitoring over de gehele applicatie maakte problemen direct zichtbaar, bij het team dat de code had geschreven. De regel dat elke dag code werd ingecheckt via kleine pull requests, en dat pair programming de norm was, hield de batch size klein en de kwaliteit hoog.

Het resultaat was meerdere releases per week, in een sector waar wekelijkse of maandelijkse cycli nog de norm zijn. Niet omdat het team uitzonderlijk snel werkte, maar omdat het systeem zo was ingericht dat feedback snel terugvloeide naar de plek waar er iets mee gedaan kon worden.

Continual Learning: waarom lerende tech-organisaties winnen

De organisatie die leert, wint altijd op de lange termijn

Slowification: leren als structurele investering

Flow zorgt ervoor dat werk snel door het systeem beweegt. Feedback zorgt ervoor dat problemen snel zichtbaar worden. Maar wat doe je met die problemen? The Third Way gaat over de capaciteit van een organisatie om structureel te leren, van fouten, van successen, van experimenten, en die kennis te vertalen naar betere systemen en praktijken.

Kim en Spear beschrijven dit als slowification: het creëren van gestructureerde ruimte om te leren vóórdat problemen de productieomgeving raken. Drills, blameless postmortems, chaos engineering, staging-omgevingen: allemaal vormen van bewust gesloten leerloops die de productieketen beschermen. De NASA oefende maandenlang elke stap van de maanlandingsprocedure in simulatoren vóór Apollo 11 vertrok. Google en Amazon voerden disaster readiness-drills uit lang vóórdat hun platforms de schaal bereikten waar storingen catastrofaal zouden zijn.

In softwareorganisaties betekent dit: investeer in omgevingen waar je veilig kunt falen. Behandel elk incident niet als bewijs van incompetentie maar als leerkans. Maak postmortems verplicht en blameless. En misschien wel het meest onderschatte element: bouw een cultuur waarin mensen problemen durven aan te kaarten zonder angst voor consequenties. Zonder psychologische veiligheid is er geen eerlijk leren, hoe goed de technische infrastructuur ook is.

Van project-led naar product-led: leren institutionaliseren

Leren is niet iets wat je als programma inricht en na een half jaar evalueert. Het is een capaciteit die vraagt om een fundamenteel andere organisatievorm. Matthias Patzak beschrijft in ‘All Hands on Tech’ hoe de meeste organisaties vastlopen in de overgang van project-led naar product-led.

In een project-led organisatie worden teams tijdelijk gevormd voor een project en daarna ontbonden. Kennis verdampt. Lessen worden niet geïnstitutionaliseerd. Het volgende team begint opnieuw. In een product-led organisatie zijn teams duurzaam, zijn ze eigenaar van een domein, en bouwen ze over jaren diep begrip op van gebruikersbehoeften en technische context. Leren heeft een plek om te landen.

Kritische ontwikkelcapaciteit houden product-led organisaties bewust in huis. Dat is een leerkundige keuze: kennis die buiten de organisatie zit, creëert een feedbackvacuum. Als de partij die de code schrijft een andere is dan de partij die de gevolgen ervaart, blijft er alleen een keten van schuld over.

AI vergroot de rekensom

Er is één ontwikkeling die de urgentie van The Third Way radicaal heeft vergroot: kunstmatige intelligentie. Negentig procent van de technologieprofessionals gebruikt AI inmiddels als onderdeel van hun dagelijkse werk. Meer dan tachtig procent rapporteert hogere individuele productiviteit. Maar de centrale bevinding van het DORA 2025-onderzoek is ongemakkelijk helder.

“AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.”

— DORA, State of AI-Assisted Software Development 2025

AI genereert code sneller dan mensen dat kunnen. Maar als de organisatie die code niet snel, betrouwbaar en veilig kan deployen, testen en monitoren — als er geen goede feedbackloops zijn, geen leercultuur, geen kwalitatief platform — dan versnelt AI alleen maar de aanvoer van problemen. De bottleneck verschuift van ‘we kunnen niet snel genoeg schrijven’ naar ‘we kunnen niet snel genoeg verwerken’. En die laatste bottleneck is organisatorisch van aard, niet technisch.

DORA identificeert zeven randvoorwaarden voor effectieve AI-adoptie: o.a. een helder AI-beleid, een gezond data-ecosysteem, een kwalitatief intern platform, en een cultuur van kritisch denken over AI-output. Geen van deze randvoorwaarden is nieuw. Ze zijn allemaal uitlopers van The Third Way. Een lerende organisatie absorbeert AI als gereedschap. Een niet-lerende organisatie wordt er door overspoeld.

Dertig procent van de respondenten in het DORA 2025-onderzoek vertrouwt AI-gegenereerde code onvoldoende zonder uitgebreide validatie. Dat is een teken van volwassenheid. De organisaties die het meest profiteren van AI, zijn niet de organisaties die het meest vertrouwen hebben in de output. Het zijn de organisaties die de beste structuren hebben om de output te toetsen, te verbeteren en te leren van wat er fout gaat.

CASE: Adidas, Consumer Goods & Retail

Adidas maakte de strategische keuze om softwareontwikkeling volledig in-house te brengen, een beslissing die primair door een leerargument werd gedragen. Outsourcen betekent een feedbackvacuum creëren: de kennis over klantgedrag, technical debt en architecturale keuzes zit dan buiten de organisatie.

Door Team Topologies als leidend principe te hanteren, bouwde Adidas een structuur waarin stream-aligned teams diep domeinbegrip konden opbouwen. Enabling teams brachten tijdelijk specialistische kennis en werkten expliciet aan hun eigen overbodigheid, een directe institutionalisering van het principe dat leren moet worden doorgegeven, niet beheerd.

De platform-teams werden beoordeeld op of productteams sneller en zelfstandiger werden, niet op of het platform technisch foutloos was. Die verschuiving in maatstaf is de kern van The Third Way: succes is niet wat je bouwt, maar wat anderen door jouw werk beter kunnen doen.

Waarom veel organisaties denken dat ze al DevOps doen

Op dit punt in het gesprek zeggen de meeste managers een variant van hetzelfde: wij doen dit al, wij hebben Agile teams, wij hebben een pipeline. Wij doen aan DevOps.

Wij begrijpen die reactie. En wij nemen haar serieus. Want in de meeste gevallen klopt het ook: er zijn elementen van de Three Ways aanwezig. Maar aanwezig is niet hetzelfde als volledig ingericht. Een team dat Agile werkt maar wacht op een aparte operations-afdeling voor elke deployment, heeft flow op teamniveau maar niet op systeemniveau. Een team dat monitoring heeft maar nooit een blameless postmortem houdt, heeft technische zichtbaarheid maar geen leercultuur.

De vraag is niet of je aan DevOps doet. De vraag is of alle drie de principes consequent zijn doorgevoerd, op alle niveaus van de organisatie, en of de architectuur, de teamstructuur en de cultuur met elkaar in lijn zijn. Dat is een hogere lat dan de meeste organisaties zichzelf opleggen. En het is precies het verschil dat de data laat zien tussen toppresteerders en de rest.

“De enige manier om een Tech-organisatie echt te veranderen, is om drie onderling afhankelijke principes allemaal en tegelijk in te richten. Elk principe op zichzelf levert suboptimale resultaten. Alle drie samen veranderen de organisatie structureel.”

— Cris Cadinu, Agile Fanatics

Hoe je een sterke DevOps-organisatie bouwt

De Three Ways zijn een manier van denken over hoe organisaties werken, en een diagnose-instrument voor waarom ze vastlopen. Flow zonder feedback is blind. Feedback zonder leren is verspilling. En alle drie verliezen hun kracht als de organisatiestructuur, de architectuur en de cultuur er niet op zijn ingericht.

Dat vraagt iets van leiders dat verder gaat dan het goedkeuren van een transformatieprogramma. Het vraagt de bereidheid om de organisatie te ontwerpen als systeem: te erkennen dat teamstructuur architectuur bepaalt, dat meten van de verkeerde dingen de verkeerde dingen produceert, en dat leren alleen mogelijk is als falen veilig is.

De theorie is coherent. De data, meer dan tien jaar DORA-onderzoek én peer-reviewed onderzoek uit o.a. Accelerate, is overtuigend. Samen geven ze een stevig empirisch fundament. De cases zijn divers genoeg, van een Japanse autofabriek tot een Nederlandse bank, van Milieudienst tot een groot Duits Sportkledingmerk, om te laten zien dat dit breed toepasbaar is, ver buiten Silicon Valley.

“Successful organizations flow from leaders who create the conditions in which many others thrive.”

— Gene Kim & Steven J. Spear, Wiring the Winning Organization

Organisaties die vandaag niet investeren in hun organisatorische bedrading lopen het risico dat elke volgende technologiegolf, inclusief generatieve tooling, hen verder achter doet lopen in plaats van vooruit te helpen. De theorie en de data zijn beschikbaar. De vraag is of leiders bereid zijn te handelen naar wat die theorie en data zeggen.

Dit artikel is inhoudelijk gebaseerd op peer-reviewed onderzoek en de volgende publicaties:

• All Hands on Tech — Patzak & Seiwald-Højer (2024)
• Accelerate: The Science of Lean Software and DevOps — Forsgren, Humble, Kim (IT Revolution Press, 2018)
• The DevOps Handbook — Kim, Humble, Debois, Willis (IT Revolution Press, 2016; herziene editie 2021)
• Wiring the Winning Organization — Kim & Spear (IT Revolution Press, 2023)
• Team Topologies — Skelton & Pais (IT Revolution Press, 2019) · teamtopologies.com
• State of AI-Assisted Software Development 2025 — DORA (Google Cloud, 2025)