Waarom lopen agile trajecten uit

Zekerheid betekent investeren in details, maar dat is niet acceptabel

Wil je een planning met grote zekerheid halen, dan heb je een paar opties. Je kunt heel veel ruimte voor uitloop inplannen, maar dat is eigenlijk nooit een reële optie. Veel gebruikelijker is het plannen in meer detail. Een voorbeeld hiervan is het plannen van de renovatie van de Velsertunnel. Daarvoor is 2 jaar gestoken in de planning en het verfijnen daarvan, waarbij het belangrijkste werk in 10 weken is uitgevoerd. Maar zonder enige uitloop!

In IT-projecten is een dergelijke inspanning meestal niet acceptabel, omdat er onvoldoende noodzaak is voor een hoge mate van zekerheid óf omdat de requirements in IT-projecten niet altijd zo strak vooraf vastliggen. Agile werken lost dit gedeeltelijk op door iteratief te plannen, zonder vaste scope en met een beperkte planningshorizon: formeel is er alleen commitment op de volgende sprint. Daarna is er weinig zekerheid wat er wanneer af is.

Puristen geven vaak aan dat het “oud denken” is om toch op een iets hoger niveau te plannen en ook te sturen. Wat kun je doen om toch meer voorspelbaarheid in agile trajecten te krijgen? In verschillende “Agile at Scale” frameworks, waaronder SAFe®, wordt hier een invulling aan gegeven, zoals met het Portfolio Backlog, PI Planning en de Architectural Runway. Het verschil met waterval is, dat deze invulling ook continu wordt herijkt (wendbaarheid!), terwijl er wel inzicht over een langere periode wordt gecreëerd.

De kosten van incrementeel werken lijken klein, maar zijn dat niet altijd

In agile is het uitgangspunt dat het relatief goedkoop is om incrementeel aan te passen. De vraag is of dit uitgangspunt altijd correct is. Vergelijk je het met het bouwen van een huis, dan begrijpt iedereen dat ingrijpende wijzigingen grote gevolgen hebben. De fundering aanpassen ná het neerzetten van de muren betekent vaak afbreken en opnieuw beginnen, of grote kosten.

Voor fundamentele of architectuurwijzigingen in de IT, geldt helaas hetzelfde. Dat incrementeel aanpassen goedkoop is, gaat dan ook alleen op voor kleine uitbreidingen. Vergelijk dit met het plaatsen van een dakkapel of een nieuwe keuken. Dit zijn vastomlijnde verbeteringen met beperkte afhankelijkheden.

Voor grote nieuwbouwprojecten in de IT ligt het daarom niet voor de hand om deze aanname te doen. Hier helpt agile niet als het dogmatisch wordt toegepast en zal het uitloop tot gevolg hebben. Er is wel degelijk een meerwaarde van vooraf nadenken over dingen die later lastig aan te passen zijn. De kunst is om te bepalen welke dingen dat zijn. Een goede technisch architect heeft een track-record met beslissingen die achteraf juist blijken te zijn. Het begin van de oplossing voor dit probleem is het betrekken van zo’n architect.

De organisatie is in een agile transitie en nog niet volwassen

Door de invoering van agile zijn veel traditionele rollen, die stuurden op samenhang en controle, weggevallen (projectmanagement, risicomanagement). In scrum is daar weinig aandacht voor (want: gebaseerd op 1 of weinig teams). Agile at Scale methodieken brengen die rollen, al dan niet gedeeltelijk, weer terug. Dit gebeurt dan regelmatig onder protest van agile puristen.

Ook is in een lerende omgeving, die nog niet ervaren is in werken op deze nieuwe manier, de volwassenheid niet altijd aanwezig die nodig is om de wat abstractere tactisch/strategische thema’s goed te adresseren. De sprint van vandaag en de volgende sprint, lukken nog wel. Een hele release van 5+ sprints over meerdere teams uitplannen, is veel lastiger en daarom loopt het uiteindelijk vaak niet zoals gepland.

Agile at Scale frameworks helpen hierbij wel met een blend van agile en traditionele methodieken. De SAFe® PI-planning vervangt bijvoorbeeld de “ouderwetse” releaseplanning, maar dat is pas vaak de volgende fase in de agile implementatie. Vaak wordt, nog voordat de transitie is afgerond, alweer gestart met het volgende initiatief, zoals DevOps. En dit gebeurt hoe dan ook, of de organisatie er nu klaar voor is of niet. 

Zelfsturende teams mag je niet sturen

Een belangrijke pijler van agile teams is dat ze “zelfsturend” moeten zijn. Dat gaat in een relatief kleine omgeving vaak nog prima. Als de omvang groter wordt, dan wordt het inefficiënt om alle teams zelf de onderlinge coördinatie te laten doen. Dit leidt dan tot te veel bilaterale afstemming. Ook zal een goed lopend team dat weinig klantwaarde toevoegt zichzelf niet zo snel opheffen.

Wanneer agile te dogmatisch wordt toegepast, wordt alle verantwoordelijkheid bij de individuele teams neergelegd. Dit heeft als gevolg dat, door gebrek aan sturing op het geheel, het voortbrengingsproces stagneert. Er zijn twee dingen die je kunt doen om dit te voorkomen.

Ten eerste is het ook voor zelfsturende teams nodig om kaders en richting mee te krijgen. Dit zowel in de vorm van een lange termijn visie, het doel en de weg ernaartoe, als ook in de vorm van het faciliteren van efficiënte afstemming, het proces, de manier waarop wordt samengewerkt). Ten tweede moet de sturing passen bij de volwassenheid van de organisatie, dus situationeel leiderschap. Dat wil zeggen: directief en faciliterend als dat nodig is, maar alleen als het kan. De leiderschapsstijl is goed te koppelen aan de fasen van teamontwikkeling (zie ook de figuur).

Waar brengt ons dit?

De belangrijkste oorzaak van uitloop is een dogmatische invulling van agile. Dat is een vreemde tegenstelling, gegeven het feit dat agile letterlijk wendbaarheid betekent en bedoeld is om juist pragmatisch om te gaan met verandering. Dus waarom niet ook pragmatisch omgaan met het agile gedachtengoed? Dat wil zeggen: rekening houden met de specifieke situatie en het gezond verstand gebruiken. Het gebruiken van de nuance en subtiliteit van een horlogemaker en niet die van een smid.

Meer weten over agile?

Ben je door dit artikel getriggerd en wil je eens met ons van gedachten wisselen over wat jou bezighoudt op agile gebied? Neem dan contact met ons op.

Wil je weten of jouw organisatie agile geschikt is of niet, bestel dan ons boekje Agile: Geschikt/Ongeschikt of neem contact met ons op. We gaan graag met je in gesprek over wat jou bezighoudt op agile gebied.