Als continuous delivery niet kan: hoe teams toch de Developer Experience verbeteren

Continuous delivery geldt in moderne softwareontwikkeling vaak als de heilige graal. Het idee om meerdere keren per dag waarde bij klanten te leveren, direct feedback op te halen en snel te itereren, is aantrekkelijk. Maar voor veel softwareteams—zeker in hardware‑intensieve, gereguleerde of legacy‑zware domeinen—is volledige continuous delivery (CD) simpelweg niet haalbaar.

Een recent paper van Eriks Klotins, Magnus Ahlgren, Nicolas Martin Vivald en Even‑Andre Karlsson (2025), “When Continuous Delivery Is Not an Option”, laat zien hoe complexe organisaties met deze realiteit omgaan. Zij tonen aan dat, ook als volledige end‑to‑end continuous software engineering (CSE) wordt geblokkeerd door technische, organisatorische of marktfactoren, teams intern toch betekenisvolle verbeteringen kunnen realiseren. Voor DevEx-, AgileEx- en OpsEx‑teams zijn deze inzichten zeer bruikbaar.

In dit artikel vatten we de belangrijkste bevindingen van het paper samen en schetsen we praktische stappen waarmee softwareteams de developer experience en productiviteit kunnen verbeteren—zelfs als zij niet continu kunnen deployen.

Het onderzoek beschrijft vier grote organisaties in industriële automatisering, toeleverancier van auto‑onderdelen, retail e‑commerce en software voor chemische supply chains. De auteurs zien een vast patroon: zelfs als teams gemotiveerd zijn om continuous delivery te adopteren, maken beperkingen het vaak onmogelijk.

Enkele veelvoorkomende beperkingen:

• Regelgeving en veiligheidseisen: bijv. veiligheidskritische industriële systemen kunnen niet frequent worden uitgerold zonder uitgebreide verificatie.

• Hardwarekoppeling: ingebedde software in voertuigen of machines kan niet dagelijks worden geüpdatet.

• Afhankelijkheden in de toeleveringsketen: software werkt vaak samen met externe systemen of partners buiten de invloedssfeer van de organisatie.

• Organisatorische traagheid: legacy‑systemen, meerdere silo’s en uitbestede teams vertragen adoptie.

Tegelijkertijd zijn interne verbeteringen—zoals automatisering van builds, tests en integratie‑pipelines—gewoonlijk wel haalbaar. Dit onderscheid tussen interne capaciteiten en externe beperkingen is essentieel om te begrijpen hoe ‘continuous engineering’ er in de praktijk uit kan zien.

Het paper stelt een geactualiseerd gereedheidsmodel voor waarmee organisaties kunnen beoordelen welke aspecten van continuous engineering haalbaar zijn. Het scheidt interne randvoorwaarden (cultuur, processen, tooling) van externe randvoorwaarden (marktvraag, regulatoire afstemming, ecosysteemafhankelijkheden) en benadrukt twee afzonderlijke feedbacklussen:

1. Interne delivery‑lus: verbeteren hoe het team software bouwt, test en integreert.

2. Externe product‑gebruikslus: verbeteren hoe het eindproduct wordt geleverd, gebruikt en iteratief wordt bijgesteld in de echte wereld.

De kern: volledige continuous delivery wordt vaak door externe factoren geblokkeerd, maar interne lussen kunnen nog steeds aanzienlijke waarde opleveren.

Een korte blik op de vier onderzochte organisaties:

• Leverancier van industriële automatisering: veiligheidskritische hardware‑softwareproducten. Continuous delivery naar klanten is niet haalbaar. De focus ligt intern op automatisering op componentniveau.

• Toeleverancier van auto‑onderdelen: lange productlevenscycli (25+ jaar), ingebedde software. Interne CI/CD is mogelijk; uitrol in het veld blijft beperkt.

• Wereldwijde e‑commerce‑retailer: meer controle over softwarelevering, maar beperkt door partnersystemen en legacy‑integraties. Gedeeltelijke continuous delivery is bij sommige teams mogelijk.

• Chemie- en supply‑chainbedrijf: software is niet kern, grotendeels uitbesteed, organisatorische gereedheid is laag. Volledige continuous engineering is gestokt.

De boodschap: volledige end‑to‑end continuous delivery is vaak onrealistisch, maar interne verbeteringen—automatisering, modularisatie, testen, telemetrie—blijven uitvoerbaar en waardevol.

Ook als u niet continu naar productie kunt deployen, is er genoeg dat u kunt doen om de developer experience, operationele efficiëntie en productkwaliteit te verbeteren.

Stel realistische doelen voor continuous engineering op basis van de beperkingen in uw organisatie. In plaats van te streven naar dagelijkse deployment, richt u zich op volwassenheidsniveaus die in uw omgeving haalbaar zijn. Gebruik het gereedheidsmodel om te bepalen waar uw team staat en wat uw doel is.

Interne lussen vallen vaak binnen de invloedssfeer van uw team. Focus op:

• CI/CD‑automatisering: build-, test- en integratie‑pipelines.

• Modulaire architectuur: services loskoppelen voor eenvoudiger testen en uitrollen.

• Testautomatisering & testdekking: defecten vroeg afvangen.

• Metrics verzamelen: buildtijden, merge latency, defect‑injectieratio’s.

Breng afhankelijkheden in uw ecosysteem in beeld—leveranciers, hardware, regelgeving, klantverwachtingen—en pas uw leveringsverwachtingen daar op aan.

Als frequente deploys niet mogelijk zijn:

• Meet verbeteringen in staging‑/sandboxomgevingen.

• Volg de afname van build‑ en test cycle time.

• Meet het aantal handmatige release‑stappen dat verdwijnt, opgeloste integratie‑pijnpunten in code en verbeteringen in testdekking.

• Gebruik deze als proxy’s voor winst in developer experience.

Benadruk de voordelen die uw team zelf kan beïnvloeden: snellere interne feedback, minder handwerk en hogere codekwaliteit. Kader voortgang niet uitsluitend als ‘we moeten dagelijks naar productie deployen’.

Ook als continuous delivery nu niet haalbaar is, bereidt u zich voor op de toekomst door:

• modulaire, geïnstrumenteerde en losgekoppelde systemen te bouwen.

• mogelijkheden voor telemetrie en versiebeheer toe te voegen.

• te plannen voor OTA‑updates of snellere release‑cycli zodra externe beperkingen afnemen.

Voor teams die focussen op developer experience (DevEx), agile experience (AgileEx) en operational experience (OpsEx):

• DevEx‑tools en -strategie: Investeer in automatisering, pipelines en infrastructuur die de dagelijkse workflow van ontwikkelaars verbetert.

• Meten van developer experience: Volg buildtijden, test‑flakiness en merge latency. Dit zijn meetbare verbeteringen waarop u gericht kunt sturen.

• AgileEx‑praktijken: Ook als productie‑deployments beperkt zijn, blijven frequente integratie, incrementele feature‑ontwikkeling en interne feedbacklussen de agile‑principes ondersteunen.

• OpsEx‑metrics: Focus op stabiliteit, traceability, instrumentation en supportability van bestaande systemen.

Het gereedheidsmodel biedt een kader om uw DevEx/DevOps‑verbeteringen te koppelen aan wat vandaag haalbaar is, en om incrementele stappen te plannen richting ambitieuzere doelen voor continuous engineering.

Volledige continuous delivery kan worden geblokkeerd door hardware, regelgeving, organisatie of markt—maar dat betekent niet dat uw team geen voordeel kan halen uit continuous engineering. Door te focussen op interne verbeteringen, externe beperkingen in kaart te brengen en metrics rond developer experience af te stemmen op realistische doelen, kunnen softwareteams meetbare vooruitgang boeken.

Het paper herinnert ons eraan dat continuous engineering een spectrum is, en dat zelfs gedeeltelijke adoptie waarde oplevert. Voor teams in complexe domeinen is het zaak te verbeteren wat u kunt beïnvloeden, impact te meten en u voor te bereiden op toekomstige kansen zodra beperkingen afnemen.