Agile Under Pressure: Derk-Jan de Grood spreekt op Scrum Gathering Brussels 2026

Op 8 en 9 oktober komt de internationale Agile-community samen tijdens Scrum Gathering® Brussels 2026. Op vrijdag 9 oktober staat ook onze InnSpirator Derk-Jan de Grood op het programma. In zijn talk Agile Under Pressure: Product Ownership in Operations gaat hij in op een uitdaging die hij bij veel organisaties tegenkomt: hoe combineer je development en operations als gepland werk en onverwachte problemen continu om dezelfde capaciteit vragen?

Een sprint kun je plannen. Een productie-incident niet.

Dat verschil klinkt eenvoudig, maar heeft grote gevolgen voor de manier waarop teams hun werk organiseren. Zeker nu development en operations steeds vaker samenkomen binnen DevOps-teams.

Tijdens zijn sessie in Brussel laat Derk-Jan zien waarom operationeel werk om een andere manier van plannen en prioriteren vraagt. Ook bespreekt hij wat dit betekent voor de rol van de Product Owner wanneer urgentie, risico en langetermijnverbetering tegelijkertijd aandacht vragen.

Development en operations hebben een andere dynamiek

Development en operations werken aan dezelfde systemen en uiteindelijk voor dezelfde organisatie. Toch kijken ze vanuit een andere verantwoordelijkheid naar hun werk.

Development is gericht op verandering. Teams bouwen nieuwe functionaliteiten, verbeteren bestaande producten en vertalen ideeën uit de organisatie naar software. Een groot deel van dat werk kan vooraf worden besproken, verfijnd en geprioriteerd. Dat past goed bij een werkwijze als Scrum.

Operations heeft een andere verantwoordelijkheid. Daar draait het om het betrouwbaar, veilig en beschikbaar houden van systemen die al in productie staan. Het werk wordt daardoor veel sterker beïnvloed door wat er op dat moment gebeurt. Een incident, securityprobleem of onverwacht verzoek kan niet altijd wachten tot de volgende sprint.

Volgens Derk-Jan ontstaat hier een verschil dat binnen DevOps soms wordt onderschat. Development is gebaat bij verandering, terwijl operations verantwoordelijk is voor stabiliteit. Dat betekent niet dat de twee elkaar tegenwerken. Het betekent wel dat ze vanuit verschillende belangen naar hetzelfde systeem kijken.

Derk-Jan zag dat verschil duidelijk terug bij teams die hij begeleidde. Bij sommige teams ging 80 tot 90 procent van de beschikbare tijd op aan operationeel werk, terwijl de manier van plannen nog grotendeels was ingericht rondom development.

Dan is de vraag niet alleen hoe je development en operations beter laat samenwerken. Je moet ook kijken of je beide soorten werk wel op dezelfde manier moet proberen te plannen.

Waarom Scrum niet altijd aansluit op operationeel werk

Een sprint geeft een team focus. Je spreekt af wat belangrijk is en probeert daar gedurende de sprint zo min mogelijk van af te wijken. Bij operationeel werk is dat niet altijd realistisch.

Als een bedrijfskritisch systeem uitvalt, kun je moeilijk zeggen dat het incident over negen dagen wordt opgepakt omdat de huidige sprint al vol zit. Tegelijkertijd kan een team ook niet iedere verstoring onbeperkt voorrang geven. Dan blijft er uiteindelijk geen tijd meer over voor gepland werk en structurele verbetering.

Derk-Jan onderscheidt daarom vier soorten werk die binnen operations om capaciteit vragen: incidenten, kleine verzoeken, geplande changes en verbetering van het team en de technische omgeving.

Die categorieën hebben ieder een andere dynamiek. Een incident vraagt vaak direct aandacht, terwijl een structurele verbetering misschien pas over enkele maanden zichtbaar resultaat oplevert. Toch moeten ze uit dezelfde beschikbare capaciteit komen.

Precies daar wordt Product Ownership in operations interessant.

Een druk team is niet automatisch een team dat vooruitkomt

Een operations-team kan de hele week hard werken en aan het einde van die week toch nauwelijks structureel zijn opgeschoten.

Dat gebeurt wanneer incidenten en kleine verzoeken bijna alle beschikbare tijd innemen. Het team lost veel problemen op en levert daarmee zichtbaar werk, maar komt niet toe aan verbeteringen die ervoor kunnen zorgen dat dezelfde problemen minder vaak terugkomen. Zo kan een vicieuze cirkel ontstaan. Hoe meer incidenten er zijn, hoe minder tijd er beschikbaar is voor verbetering. En hoe minder tijd een team investeert in verbetering, hoe groter de kans dat dezelfde problemen blijven terugkomen.

Om die cirkel te doorbreken moet verbeterwerk volgens Derk-Jan niet worden behandeld als iets wat je doet wanneer er toevallig tijd overblijft.

Je moet er bewust ruimte voor reserveren.

Werken met capacity buckets

Tijdens Agile Under Pressure introduceert Derk-Jan een praktisch bucketmodel om beperkte capaciteit zichtbaar te maken.

In plaats van alle werkzaamheden met elkaar te laten concurreren, verdeelt een team zijn beschikbare capaciteit over verschillende soorten werk. Er is ruimte voor incidenten, kleine verzoeken, geplande changes en structurele verbetering. Het doel daarvan is niet om vooraf exact te voorspellen hoeveel incidenten er volgende week ontstaan. Dat kan immers niet. Het model maakt vooral duidelijk dat capaciteit eindig is.

Wanneer de beschikbare ruimte binnen een categorie op is en er komt nieuw werk bij, moet er een keuze worden gemaakt. Krijgt het nieuwe verzoek daadwerkelijk voorrang? Welk ander werk schuift daardoor op? En welk risico accepteert de organisatie met die keuze? Daarmee verandert een discussie over capaciteit in een gesprek over prioriteiten.

Ook voor stakeholders wordt duidelijker wat de consequenties van een nieuw verzoek zijn. Iets toevoegen aan de ene kant betekent vrijwel altijd dat iets anders later gebeurt.

Minder incidenten begint met tijd maken voor verbetering

Vooral de capaciteit voor verbetering speelt een belangrijke rol in Derk-Jans aanpak. Wanneer een team tijd kan besteden aan automatisering, kwaliteit, technische schuld en het verwijderen van structurele oorzaken, kan het aantal incidenten afnemen. Daardoor komt weer capaciteit vrij die opnieuw kan worden geïnvesteerd in verbetering of nieuwe waarde.

Zo kan een positieve beweging ontstaan: minder incidenten zorgen voor meer ruimte, en meer ruimte maakt verdere verbetering mogelijk. Onder druk gebeurt vaak precies het tegenovergestelde. Verbeterwerk wordt uitgesteld omdat een incident op dat moment urgenter voelt. Een keer is dat logisch. Wanneer het structureel gebeurt, houdt een team zijn eigen reactieve werkwijze in stand.

De uitdaging zit daarom niet alleen in het verdelen van capaciteit. Het gaat ook om het beschermen van de ruimte die nodig is om op langere termijn beter te worden.

Wat betekent dit voor de Product Owner in operations?

Daarmee verandert ook de rol van de Product Owner. Bij productontwikkeling ligt veel nadruk op klantwaarde, nieuwe mogelijkheden en de volgorde waarin functionaliteiten worden gebouwd. Een Product Owner die ook met operationeel werk te maken heeft, moet daarnaast rekening houden met risico, beschikbaarheid, betrouwbaarheid en urgentie. Dat vraagt om andere afwegingen.

Een stakeholder kan een verzoek als urgent bestempelen, maar hoe groot is de daadwerkelijke impact als het een week later wordt uitgevoerd? Een technische verbetering levert vandaag misschien geen zichtbare nieuwe functionaliteit op, maar kan wel voorkomen dat een systeem volgende maand uitvalt.

De Product Owner moet die verschillende vormen van waarde tegen elkaar kunnen afwegen. En misschien nog belangrijker: kunnen uitleggen waarom bepaalde capaciteit bewust niet aan het meest zichtbare of luidste verzoek wordt besteed. Product Ownership in operations gaat daarmee verder dan het ordenen van een backlog. Het gaat over keuzes maken wanneer er meer belangrijk werk ligt dan een team aankan.

Agile Under Pressure tijdens Scrum Gathering Brussels 2026

Tijdens Scrum Gathering® Brussels 2026 brengt Derk-Jan deze inzichten samen in zijn talk Agile Under Pressure: Product Ownership in Operations. In 30 minuten gaat hij in op de verschillende dynamieken van development en operations, de vier soorten operationeel werk, het werken met capacity buckets en de rol van de Product Owner wanneer urgentie en langetermijnverbetering met elkaar botsen.

De sessie is bedoeld voor Product Owners, Scrum Masters, Agile coaches, team leads, transformation leads, operations-professionals en management die te maken hebben met teams waarin change en run samenkomen. Voor ons bij InnSpire is het mooi om Derk-Jan met dit onderwerp op het podium in Brussel te zien. Het sluit aan bij hoe wij naar Agile werken kijken. Niet een framework volgen omdat het zo beschreven staat, maar begrijpen wat er binnen een organisatie gebeurt en daar de werkwijze op aanpassen.

Want juist wanneer de druk oploopt en de planning niet meer aansluit op de werkelijkheid, wordt zichtbaar hoe wendbaar een team daadwerkelijk is.

Derk-Jan zien in Brussel?

Scrum Gathering® Brussels 2026 vindt plaats op 8 en 9 oktober 2026. Derk-Jan spreekt op vrijdag 9 oktober met Agile Under Pressure: Product Ownership in Operations.

Bekijk Scrum Gathering® Brussels 2026 en het programma: https://www.rsgbrussels26.com/

Lees Derk-Jans eigen artikel over de aanleiding voor zijn talk: https://djdegrood.wordpress.com/2026/09/18/doing-devops-and-struggling-to-combine-change-and-run/

Meer verdieping over development en operations: https://bits-chips.com/article/development-and-operation-different-goals-and-ways-to-plan-work/