Leestijd
In zijn invloedrijke werk Flow: The Psychology of Optimal Experience stelt Mihaly Csíkszentmihalyi (1990) dat mensen hun hoogste productiviteit bereiken wanneer ze volledig opgaan in een staat van flow: diepe concentratie en volledige focus op de taak die voor hen ligt.
Die staat, vaak omschreven als “in the zone” zijn, hangt sterk samen met motivatie en echte betrokkenheid bij het werk. Dit idee van flow sluit direct aan bij de Scrum-waarde focus. Het onderliggende principe is dat mensen binnen een Agile team de ruimte krijgen om zich te concentreren op hun werk, zodat ze de commitments kunnen waarmaken die ze zijn aangegaan. Met andere woorden: voorspelbaar kunnen leveren.
Binnen frameworks zoals SAFe zie je die commitments terug in Team PI Objectives en de kleinere Iteration Goals die daar stap voor stap naartoe leiden. In niet-geschaalde omgevingen vervult het Sprint Goal een vergelijkbare rol.
De praktijk voor veel developers, testers en andere teamleden ziet er vaak heel anders uit. Tijdens een sprint of iteratie worden ze regelmatig in allerlei gesprekken en taken getrokken. Dat leidt tot context switching en dat heeft een stevige impact op productiviteit.
De kosten zitten niet alleen in de tijd die nodig is om mentaal weer op een nieuwe prioriteit in te schakelen. Er komt ook cognitieve belasting bij kijken: de vorige taak tijdelijk parkeren, bestanden en tools afsluiten, de nieuwe context begrijpen en de juiste omgeving weer klaarzetten.
Uit ervaringen van developers blijkt dat zelfs korte, losstaande gesprekken kunnen leiden tot aanzienlijke opstarttijd voordat iemand weer terug is in die cruciale staat van flow. Mik Kersten beschrijft dit in Project to Product (2018) treffend als thrashing: voortdurend schakelen dat productiviteit en voorspelbaarheid ondermijnt. Zo zien we toegewijde professionals hun dag beginnen met een duidelijke focus, om vervolgens steeds opnieuw te worden afgeleid. Daardoor lukt het niet om het werk dat ze gepland hadden echt af te maken.
Wanneer ik train of coach, zeg ik vaak dat de drie gevaarlijkste woorden voor productiviteit in elke organisatie zijn:
“Kun je even…?”
Vaak gevolgd door:
“Het kost maar een paar minuten.”
Dat doet het zelden. Dit soort verzoeken worden soms liefkozend JFDI’s genoemd: Just F… Do It. Voor wie de afkorting niet kent: het betekent zoiets als “doe het gewoon even”.
In mijn ogen zijn JFDI’s de meest sluipende vorm van een interne denial-of-service-aanval. De service die wordt ontzegd, is het vermogen van het team, en uiteindelijk van de organisatie, om een continue stroom van commitments aan klanten te leveren binnen voorspelbare tijdlijnen.
De optelsom van constante verstoring wordt op verschillende manieren zichtbaar.
Frequent context switching breekt de kwetsbare staat van flow af. Het werk raakt gefragmenteerd en de efficiëntie van zowel individu als team neemt af. Hoe meer tijd mensen besteden aan schakelen tussen taken, hoe minder tijd er overblijft voor diep, gefocust werk dat echte waarde oplevert.
Het resultaat is minder afgerond werk, minder kwaliteit en minder zichtbare voortgang.
Wanneer development teams niet beschermd worden tegen een voortdurende stroom aan onderbrekingen, wordt betrouwbaar voorspellen en leveren extreem lastig.
Die verminderde voorspelbaarheid beschadigt het vertrouwen van stakeholders en maakt effectieve roadmapplanning moeilijk. Als teams niet voorspelbaar kunnen leveren, is je roadmap weinig meer dan een mooie wensenlijst.
In geschaalde omgevingen, waar veel teams afhankelijkheden van elkaar hebben, kan dit een kettingreactie veroorzaken. Het gebrek aan voorspelbaarheid bij één team kan de levering van volledige value streams in gevaar brengen.
Om deze interne DoS effectief tegen te gaan en een omgeving te creëren waarin gefocust werk en voorspelbare levering mogelijk zijn, kun je verschillende strategieën toepassen.
Geef Scrum Masters en Product Owners de ruimte om op te treden als poortwachters. Zij moeten de urgentie en impact van elk “klein” verzoek zorgvuldig kunnen bevragen.
Een simpele, maar krachtige reactie is:
“Kan dit wachten tot het huidige iteration goal is gehaald?”
Of:
“Kan dit misschien mee in de volgende PI?”
Of nog scherper:
“Wat moeten we minder prioriteit geven om hiervoor ruimte te maken?”
Maak de bestaande teamcommitments zichtbaar op fysieke of digitale borden. Vraag degene die met het verzoek komt om aan te geven welk bestaand werk moet wijken. Dat maakt de werkelijke kosten van ogenschijnlijk kleine onderbrekingen zichtbaar.
Leg daarnaast vast hoeveel capaciteit er daadwerkelijk opgaat aan ongeplande JFDI’s en rapporteer dit in iteratierapportages. Zo ontstaat een datagedreven gesprek over de impact en de noodzaak om het gedrag te veranderen.
Supportwerk en kleine, urgente klantverzoeken horen in veel organisaties bij de realiteit. Behandel ze daarom niet steeds als onverwachte verstoringen. Reserveer proactief een buffer in de teamcapaciteit per iteratie of PI, op basis van historische data.
Daarmee erken je deze vraag transparant in de planning en bescherm je tegelijkertijd de capaciteit die nodig is voor geplande commitments. Als de buffer niet volledig wordt gebruikt, kan het team extra gepland werk oppakken. Dat is een veel beter scenario dan structureel commitments missen.
Als stories steeds doorschuiven naar de volgende sprint of iteratie, is dat een duidelijk waarschuwingssignaal.
Zelfs het meest gefocuste development team heeft moeite om efficiënt waarde te leveren wanneer de continuous delivery pipeline een bottleneck is. Een traag en omslachtig deploymentproces, met hoge transactiekosten, doet veel voordelen van snelle ontwikkeling en snelle fixes teniet. Investeren in het verbeteren van de delivery pipeline en het verkorten van cycle time is daarom geen technische luxe. Het is een belangrijke systeemverbetering.
Voor organisaties die met externe klanten werken, kunnen duidelijke service level agreements rondom responstijden voor supportverzoeken waardevol zijn. Zulke afspraken helpen verwachtingen te managen en noodzakelijk supportwerk beter te plannen, zonder dat geplande developmentactiviteiten steeds volledig worden verstoord.
Stimuleer een cultuur waarin werk wordt afgerond voordat nieuw werk wordt opgepakt. Het is veel efficiënter om een set gerelateerde stories of een feature af te maken voordat je overschakelt naar een heel ander deel van het systeem. Actieve Work in Progress-limieten op teamborden helpen dit principe zichtbaar te maken. Ze voorkomen dat teams zichzelf overbelasten en tegelijkertijd aan te veel dingen werken.
Stop starten. Start finishen.
Richt op het Agile bord een aparte swimlane in voor écht urgente items met hoge prioriteit die onmiddellijke aandacht vragen. Die visuele scheiding maakt duidelijk wanneer het doorbreken van WIP-limieten echt nodig is. Tegelijk geeft het transparantie over de impact van uitzonderingen op de totale flow.
Wanneer de hoeveelheid ongepland werk structureel groter is dan de gereserveerde buffer, moet er een volwassen gesprek plaatsvinden over het eventueel verkleinen van geplande scope. Doe je dat niet, dan leidt het vaak tot gemiste deadlines en gefrustreerde teams. Herzie daarom regelmatig de capaciteit die je reserveert voor ongepland werk tijdens de voorbereiding op volgende increments. Zo ontstaat een realistischer beeld van de werkelijke capaciteit van het team.
Onbeheerde onderbrekingen en de JFDI-mentaliteit creëren een vijandige omgeving voor teams en individuen. Ze ondermijnen het vermogen om flow te bereiken en voorspelbaar te leveren. Door gecontroleerde intake voor nieuw werk in te richten en de bovenstaande maatregelen consequent toe te passen, kunnen organisaties een cultuur van focus opbouwen. Zo krijgen development teams de ruimte om zich te concentreren op waardelevering en ontstaat er een betrouwbaardere, consistentere stroom van hoogwaardige producten en diensten naar klanten.
Csíkszentmihalyi, M. (1990). Flow: The Psychology of Optimal Experience. New York: Harper & Row.
Kersten, M. (2018). Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. Portland, OR: IT Revolution Press.
Artikel delen
De keynote van Sukie Kang en drie uitverkochte workshops op het Product Owner Event kwamen neer op één idee: een businesscase is een weddenschap. Zes lessen over bandbreedtes, bewijs en opnieuw beslissen.
Vandaag, 25 augustus, is een belangrijke dag voor de miljoenen SAFe-gecertificeerde professionals wereldwijd. Scaled Agile heeft een gratis upgrade naar
AI-adoptie blijft bij veel Nederlandse organisaties hangen door een gebrek aan kennis, ervaring en eigenaarschap. Volgens onderzoek van InSpark noemt
Verandering hoeft niet zwaar of ingewikkeld te zijn. Met de juiste focus, energie en begeleiding ontstaat er ruimte, richting en resultaat.
Wij denken graag met je mee.
