Hoe verbeter je DevOps cultuur binnen teams?

Veel organisaties hebben DevOps ingevoerd: er staat een CI/CD-pijplijn, teams heten cross-functioneel en de releases volgen elkaar sneller op. Toch blijft het wringen. Ontwikkelaars wijzen naar beheer als er een storing is, beheerders remmen nieuwe releases af en fouten worden liever verzwegen dan besproken. De techniek is er, maar de cultuur niet.

DevOps-cultuur is de manier waarop ontwikkelaars, beheerders en andere IT-professionals samenwerken aan één gedeelde uitkomst: software die snel, betrouwbaar en veilig waarde levert. Het gaat om gedeeld eigenaarschap over de hele levenscyclus van een toepassing, om snelle feedback en om de bereidheid om te leren van wat misgaat. Een DevOps-cultuur is dus geen gereedschapskist, maar een set gewoonten en overtuigingen.

Je verbetert die cultuur door tegelijk aan drie dingen te werken. Ten eerste: maak samenwerking structureel door teams te bouwen rond een product of dienst, met gezamenlijke verantwoordelijkheid voor bouwen én draaien. Ten tweede: verkort de feedbackloops, zodat teams snel zien wat het effect is van hun werk en er veilig over kunnen praten. Ten derde: laat leiders het gewenste gedrag voordoen en de belemmeringen wegnemen die teams zelf niet kunnen oplossen. Zonder deze drie blijft DevOps een technisch project dat op weerstand stuit.

Wat is DevOps cultuur precies en waarin verschilt die van DevOps-tooling?

Het woord DevOps is een samentrekking van Development en Operations. In de kern is DevOps een verzameling praktijken die de samenwerking en communicatie tussen ontwikkelaars, beheerders en ondersteunende medewerkers benadrukt, gedurende de hele levenscyclus van toepassingen en diensten. Dat is dus in de eerste plaats een samenwerkingsvraag, pas daarna een technische vraag.

De lesstof van de EXIN-certificeringen maakt dit onderscheid helder. In de DevOps Professional Courseware worden drie fundamentele principes genoemd: continuous integration (code vaak samenvoegen), continuous deployment (zo vaak mogelijk uitleveren) en continuous feedback (feedback zoeken van belanghebbenden in alle fasen). Die praktijken worden afgeleid uit de zogeheten Three Ways, waarvan de eerste gaat over werk snel laten stromen van ontwikkeling naar beheer. Tooling ondersteunt dat, maar de bereidheid om samen te werken en feedback te accepteren is cultuur.

Een handig onderscheid: tooling zie je in een schermafbeelding, cultuur zie je in een vergadering. Hoe reageert het team als een release mislukt? Wie wordt gebeld als er een storing is? Wordt de beheerder betrokken bij het ontwerp of pas bij de overdracht? De antwoorden op die vragen vertellen meer over je DevOps-cultuur dan de lijst met gebruikte tools.

Waaraan herken je een zwakke DevOps cultuur?

Een zwakke DevOps-cultuur is vaak eerder te voelen dan te meten. Toch zijn er duidelijke signalen. Overdrachtsmomenten stapelen zich op: een team bouwt, een ander team test, een derde zet in productie, en niemand voelt zich eigenaar van het geheel. Bij incidenten wordt gezocht naar een schuldige in plaats van naar een oorzaak. Releases worden uitgesteld omdat niemand ze vertrouwt. En verbetervoorstellen van beheerders komen zelden op de agenda van ontwikkelteams.

Een tweede signaal zijn tegengestelde prikkels. Ontwikkelaars worden beoordeeld op nieuwe functionaliteit, beheerders op stabiliteit. Zolang die doelen niet gelijk lopen, is samenwerking tegen de stroom in roeien. In DevOps Paradox bespreken ervaren DevOps-deskundigen in interviews met Viktor Farcic onder meer hoe je DevOps introduceert in chaotische organisaties en hoe je prikkels tussen teams op één lijn brengt. Juist dat laatste is in de praktijk een cultuurvraag, geen technische.

Een derde signaal is dat DevOps vooral als automatiseringsproject wordt gezien. Jan Heunks waarschuwt in zijn brede Nederlandstalige beschrijving van DevOps voor precies deze versmalling: de kracht van DevOps zit in optimale communicatie, betere samenwerking en nauwere integratie tussen development, operations en alle overige belanghebbenden. Automatisering is daarbij middel, geen doel.

Hoe verbeter je de DevOps cultuur stap voor stap?

Cultuur verander je niet met een memo. Wel kun je gericht aan de voorwaarden werken waaronder ander gedrag ontstaat. Onderstaand stappenplan is een praktische route die teams en managers samen kunnen doorlopen.

1. Maak het gedeelde doel concreet. Formuleer met ontwikkelaars én beheerders wat 'waarde leveren' voor jullie product betekent: bijvoorbeeld hoe snel een wijziging veilig in productie moet kunnen komen en hoe snel een storing hersteld moet zijn. Eén doel vervangt de tegengestelde prikkels.
2. Leg de waardestroom bloot. Teken samen de route van idee tot productie en markeer elke overdracht, wachtrij en goedkeuringsstap. Dit maakt zichtbaar waar samenwerking nu stokt en geeft een gezamenlijke agenda.
3. Geef teams gezamenlijk eigenaarschap over bouwen en draaien. Wie de software bouwt, voelt de gevolgen van slechte beheerbaarheid als hij ook de storingen afhandelt. Dat is de snelste manier om empathie tussen disciplines te laten groeien.
4. Verkort de feedbackloops. Automatiseer testen, integreer code vaak en zorg dat productiegegevens zichtbaar zijn voor het hele team. Snelle, feitelijke feedback maakt gesprekken over kwaliteit minder persoonlijk en meer inhoudelijk.
5. Voer blamevrije incidentevaluaties in. Bespreek na een incident wat er gebeurde en waarom het systeem het toeliet, niet wie een fout maakte. Zo leren teams openlijk over fouten praten.
6. Werk in kleine verbeterstappen. Kies elke iteratie één belemmering uit de waardestroom en los die op. Kleine, zichtbare successen bouwen het vertrouwen op dat grote programma's zelden opleveren.
7. Laat leiders zichtbaar meedoen. Managers die zelf incidentevaluaties bijwonen, belemmeringen buiten het team wegnemen en fouten van zichzelf benoemen, geven het signaal dat het nieuwe gedrag veilig is.

Deze stappen werken alleen in samenhang. Wie alleen automatiseert (stap 4) zonder eigenaarschap (stap 3) krijgt snellere overdrachten, geen betere samenwerking. Wie alleen aan veiligheid werkt (stap 5) zonder concrete doelen (stap 1) krijgt prettige gesprekken zonder richting.

Hoe organiseer je teams zodat DevOps samenwerking vanzelf ontstaat?

Cultuur volgt structuur meer dan we vaak toegeven. Als ontwikkelaars en beheerders in aparte afdelingen zitten met aparte managers en aparte doelen, kun je samenwerking prediken tot je een ons weegt. De teamindeling bepaalt welke gesprekken dagelijks plaatsvinden en welke nooit.

Matthew Skelton en Manuel Pais beschrijven in Team Topologies vier fundamentele teamtypen en drie interactiepatronen voor IT-organisaties. Hun model behandelt teams als de fundamentele eenheid van levering, waarbij teamstructuren en communicatiepaden meegroeien met de technische en organisatorische volwassenheid. Zij beschrijven ook welke teampatronen je beter kunt vermijden bij moderne softwaresystemen. Voor een DevOps-cultuur is de kernles: ontwerp de teams zo dat de gewenste samenwerking de kortste weg is.

Voor wie teams dagelijks begeleidt, zoals Scrum Masters en Agile Coaches, is er een aanvullende spanning: hoe stuur je een team naar eigenaarschap en zelfsturing zonder het aan zijn lot over te laten? Francisca Dalstra behandelt precies dat evenwicht tussen directief leiderschap en teamautonomie. Dat is in DevOps-teams een dagelijks dilemma, bijvoorbeeld wanneer een team zelf productieverantwoordelijkheid krijgt.

Hoe bouw je psychologische veiligheid en een leercultuur in DevOps teams?

DevOps draait om snel leren van feedback. Maar leren van fouten kan alleen als fouten benoemd mogen worden. Psychologische veiligheid, de ervaring dat je in een team openlijk kunt zeggen wat je denkt zonder daarvoor afgestraft te worden, is daarom geen zacht randverschijnsel maar een harde voorwaarde voor werkende feedbackloops. Een team dat incidenten verzwijgt, leert niets van zijn productieomgeving.

Sara Leysen beschrijft in De teamleider als cultuurmaker hoe een teamleider een cultuur creëert waarin elk teamlid de veiligheid ervaart om open te spreken en waarin iedereen wordt gestimuleerd om eigenaarschap en leiderschap op te nemen. Haar uitgangspunt is dat de aanpak van de leider ertoe doet, maar ook het vertrouwen van de leider in zichzelf. Voor een DevOps-teamleider betekent dit: eerst zelf leren om een mislukte release zonder verwijt te bespreken, dan pas verwachten dat het team dat doet.

Daniel Coyle laat in De bedrijfscultuur-code zien dat een sterke cultuur niet spontaan ontstaat, maar bewust wordt opgebouwd door leiders met concrete vaardigheden. Hij bestudeerde daarvoor zeer succesvolle organisaties, van Pixar tot grote multinationals. Zijn boek is nuttig voor wie merkt dat 'we moeten meer samenwerken' als oproep niets oplevert en op zoek is naar concrete stappen.

Wie meer wil weten over hoe de grondleggers van DevOps leren en feedback in de praktijk brengen, leest het artikel over The DevOps Handbook. Het beschrijft hoe de principes rond feedback, leren en experimenteren en het integreren van beveiliging praktisch worden ingevuld, en hoe je een DevOps-transformatie start.

Hoe maak je kwaliteit en beveiliging onderdeel van de DevOps cultuur?

Een veelvoorkomende misvatting is dat DevOps snelheid boven kwaliteit stelt. Het omgekeerde is waar: alleen teams die kwaliteit inbouwen in hun manier van werken kunnen blijven versnellen. Als testen en beveiliging aparte stappen aan het einde blijven, worden ze weer overdrachtsmomenten en dus bronnen van wrijving tussen disciplines.

Rik Marselis, Berend van Veenendaal, Dennis Geurts en Wouter Ruigrok beschrijven in Quality for DevOps teams hoe teams quality engineering integreren in hun DevOps-cultuur, onder meer door optimaal gebruik te maken van een CI/CD-pijplijn. Het boek bouwt op TMAP, een kennisbasis voor kwaliteitszorg in IT-levering die op ruim 25 jaar praktijkervaring rust. Kwaliteit wordt daarmee een gedeelde teamverantwoordelijkheid, niet het domein van een aparte testafdeling.

Testautomatisering is daarbij een cruciaal instrument: door het toenemende tempo in softwareontwikkeling is handmatig testen niet meer toereikend. Jos van Rooyen, Danny Greefhorst en Marcel Mersie benaderen testautomatisering nadrukkelijk niet alleen technisch, maar via mensen, organisatie, proces, data en technologie. Die brede blik voorkomt dat automatisering een speeltje van enkele specialisten wordt.

Hetzelfde geldt voor beveiliging. Het DevOps Secure Software Development Framework, ontwikkeld door ISACA en Antwerp Management School als antwoord op de snelle verspreiding van DevOps en Agile, biedt methoden en controles om veilig ontwikkelen in te bedden in de manier van werken. Beveiliging wordt dan een gedeelde zorg van het team in plaats van een poortwachter aan het einde.

Welke rol speelt leiderschap bij een betere DevOps cultuur?

Teams kunnen veel zelf, maar niet alles. Tegengestelde afdelingsdoelen, goedkeuringsprocedures die releases weken vertragen, of een beoordelingssysteem dat individuele prestaties beloont boven teamresultaat: dat zijn belemmeringen die alleen leiders kunnen wegnemen. Wie de DevOps-cultuur wil verbeteren, moet dus ook naar de laag boven het team kijken.

Jaap Boonstra concludeert in Leiders in cultuurverandering op basis van onderzoek bij zestien succesvolle Nederlandse organisaties dat er geen beste manier bestaat om cultuur te veranderen. Succesvolle leiders kiezen bewust een passende aanpak op basis van context en doel. Zij staan midden in de verandering, zijn zichtbaar, maken problemen bespreekbaar en geven het goede voorbeeld. Boonstra benadrukt ook het belang van ritme en ruimte: tijd nemen. Dat is een nuchtere waarschuwing voor wie een DevOps-cultuur in één kwartaal wil omzetten.

Een verwant perspectief komt uit de Lean-traditie. Toyota's aanpak bestaat uit voortdurend verbeteren en respect voor mensen, en juist dat tweede deel is altijd moeilijk te begrijpen geweest. Michael en Freddy Ballé maken het in hun roman Respectvol leiderschap tastbaar via een CEO van een softwarebedrijf dat slecht werk levert en van een klant de kans krijgt om het om te draaien, als ze bereid is om te leren. Voor IT-leiders is dat een herkenbaar leerproces.

Tijdens het event De essentie van cultuur werd cultuur beschreven als een collectieve optelsom van overtuigingen en gedragingen, met het pleidooi om gefocust te veranderen op specifiek gedrag in plaats van cultuur als geheel. Voor DevOps betekent dat: kies één concreet gedrag, bijvoorbeeld hoe je met incidenten omgaat, en werk daaraan tot het normaal is.

Wat zijn de grootste valkuilen bij het verbeteren van DevOps cultuur?

Tooling verwarren met cultuur. Een pijplijn installeren is een middag werk; ontwikkelaars en beheerders leren om samen verantwoordelijkheid te dragen kost maanden. Organisaties die het eerste doen en het tweede verwachten, raken teleurgesteld.

Een DevOps-afdeling oprichten. Wie een apart DevOps-team tussen ontwikkeling en beheer plaatst, voegt een derde silo toe aan de twee bestaande. De samenwerking die je wilde, verdwijnt achter nog een overdracht.

Snelheid zonder kwaliteit. Teams die vaker uitleveren zonder testen en monitoring in te bouwen, creëren meer incidenten en daarmee meer wantrouwen tussen disciplines. Kwaliteit is de voorwaarde voor snelheid, niet het slachtoffer ervan.

Tegengestelde prikkels laten bestaan. Zolang ontwikkelaars op nieuwe functies en beheerders op stabiliteit worden beoordeeld, is elke oproep tot samenwerking hypocriet. Beoordelingscriteria zijn cultuurinstrumenten.

Te veel tegelijk veranderen. Cultuur verandert door herhaald nieuw gedrag dat normaal wordt. Wie tien dingen tegelijk aanpakt, krijgt tien halve gewoonten. Kies één gedrag, houd vol, en breid dan uit.

Vergeten dat de rest van de organisatie ook bestaat. Een DevOps-team dat snel kan uitleveren, maar wacht op een wijzigingsadviesraad die eens per maand vergadert, heeft weinig aan zijn cultuur. In grotere organisaties moet het bestaande beheerkader meegroeien. Abhinav Krishna Kaiser beschrijft hoe ITIL-processen zich hebben gevoegd naar de DevOps-manier van werken en hoe organisaties van een project- naar een productgestuurd model bewegen.

Welk boek past bij welke rol: beginner, manager of specialist?

De vraag hoe je een DevOps-cultuur verbetert, wordt door verschillende mensen vanuit verschillende posities gesteld. Het antwoord, en de meest passende literatuur, verschilt per rol.

Wie net begint met DevOps heeft eerst een gedeelde taal nodig. De DevOps Foundation Courseware biedt die gestructureerd, met nadruk op de culturele kant. Het Nederlandstalige DevOps …… in beweging geeft de bredere bedrijfskundige context. Wie vooral wil begrijpen wat DevOps van een team vraagt, leest daarnaast De teamleider als cultuurmaker voor de menselijke kant.

Managers en teamleads die een transformatie moeten leiden, halen het meest uit DevOps for Managers voor de organisatorische keuzes, Team Topologies voor het teamontwerp en Leiders in cultuurverandering voor de veranderaanpak. Wie werkt op het Microsoft-platform, vindt in het boek van Wouter de Kort een combinatie van tooling en de culturele problemen die teams tegenkomen bij het invoeren van DevOps.

Specialisten in testen en beveiliging richten zich op Quality for DevOps teams, Testautomatisering wendbaar organiseren en Realizing DevSecOps. Hun opgave is niet alleen technisch: zij moeten hun vakgebied van poortwachter aan het einde omvormen tot gedeelde teamverantwoordelijkheid.

Ervaren DevOps-professionals die de volgende stap zoeken, kijken naar platformdenken. Camille Fournier en Ian Nowland beschrijven in Platform Engineering wat het betekent om een intern platform als product te benaderen en welke technische en bestuurlijke barrières daarbij opduiken. Dat is de logische vervolgvraag zodra meerdere DevOps-teams naast elkaar werken.

Samenvatting: zo verbeter je de DevOps cultuur in je team

Een DevOps-cultuur is de manier waarop ontwikkelaars, beheerders en andere IT-professionals samen verantwoordelijkheid dragen voor software die snel, betrouwbaar en veilig waarde levert. Je verbetert die cultuur niet met tooling alleen, maar door structuur, gedrag en leiderschap tegelijk aan te pakken.

Concreet betekent dat: formuleer één gedeeld doel dat tegengestelde prikkels vervangt, organiseer teams rond producten met gezamenlijk eigenaarschap over bouwen en draaien, verkort de feedbackloops met automatisering en zichtbare productiegegevens, maak fouten bespreekbaar via blamevrije evaluaties, bouw kwaliteit en beveiliging in de manier van werken, en laat leiders zichtbaar voordoen wat je van teams verwacht. Werk in kleine stappen en neem de tijd: cultuur verandert doordat nieuw gedrag normaal wordt.

Veelgestelde vragen over DevOps cultuur

Wat is het verschil tussen DevOps en een DevOps-cultuur?
DevOps is een verzameling praktijken en technieken, zoals continuous integration en continuous deployment. De DevOps-cultuur is de manier waarop mensen samenwerken en met feedback en fouten omgaan. Zonder die cultuur blijven de praktijken technische trucs die op weerstand stuiten.

Hoe lang duurt het om een DevOps-cultuur te veranderen?
Reken in maanden tot jaren, niet in weken. Cultuur verandert doordat nieuw gedrag herhaald wordt tot het normaal is. Kleine, zichtbare verbeterstappen werken beter dan grote programma's. Boonstra wijst in zijn onderzoek nadrukkelijk op het belang van ritme en ruimte.

Moet je een apart DevOps-team oprichten?
Meestal niet. Een apart DevOps-team tussen ontwikkeling en beheer voegt een derde silo toe. Beter is om bestaande teams gezamenlijke verantwoordelijkheid voor bouwen en draaien te geven. Team Topologies beschrijft welke teampatronen wel en niet werken.

Waarom is psychologische veiligheid belangrijk voor DevOps?
DevOps draait om snel leren van feedback uit productie. Dat kan alleen als fouten en incidenten openlijk besproken worden. Waar mensen bang zijn voor verwijten, verdwijnen problemen uit het zicht en leert het team niets.

Hoe krijg je beheerders mee die bang zijn voor snellere releases?
Betrek ze vroeg in het ontwerp, maak kwaliteit en monitoring onderdeel van elke release en laat zien dat kleinere, frequentere wijzigingen minder risico geven dan grote. Vertrouwen groeit door aantoonbaar stabiele releases, niet door beloften.

Wat kan een manager concreet doen?
Tegengestelde afdelingsdoelen gelijkrichten, trage goedkeuringsprocedures vereenvoudigen, incidentevaluaties bijwonen zonder schuldigen te zoeken en eigen fouten benoemen. Belemmeringen buiten het team wegnemen is het belangrijkste dat een manager kan bijdragen.

Hoe meet je of de DevOps-cultuur verbetert?
Kijk naar gedrag en uitkomsten samen: hoe vaak wordt uitgeleverd, hoe snel wordt een storing hersteld, hoeveel overdrachten zitten er nog in de waardestroom, en worden incidenten open besproken? Let op het watermeloeneffect: groene cijfers van buiten, rood van binnen.

Conclusie

De DevOps-cultuur in een team verbeter je niet door nog een tool te installeren, maar door de voorwaarden te scheppen waaronder ontwikkelaars en beheerders elkaar dagelijks nodig hebben en durven vertrouwen. Geef ze één doel, één product en één gedeelde verantwoordelijkheid voor wat er in productie gebeurt. Maak feedback snel en feiten zichtbaar, zodat gesprekken over kwaliteit inhoudelijk worden in plaats van persoonlijk. Bespreek fouten zonder schuldigen, zodat het team leert in plaats van verbergt. En doe als leider voor wat je van het team verwacht.

Begin klein. Kies deze week één belemmering in de waardestroom, of één incident dat nog nooit goed is nabesproken, en pak dat samen aan. Verdiep je ondertussen in de manier van denken achter DevOps met een boek dat past bij jouw rol: van de basis in de DevOps Foundation Courseware tot het teamontwerp in Team Topologies en de menselijke kant in De teamleider als cultuurmaker. Cultuur verandert door wat je herhaalt. Kies dus bewust wat je vanaf morgen herhaalt.

Verantwoording

Het doel van deze pagina is om vakkennis (m.n. boeken) aan te bevelen die het beste passen bij deze vraag. Managementboek verdiept zich al meer dan 30 jaar in vakliteratuur en gebruikt nu ook AI om de opgebouwde kennis op een relevante en persoonlijke manier uit te serveren. Je kan ook jouw vraag stellen op managementboek.nl/oplossing en wij voegen deze binnen 1 dag toe.