Als je de meeste managers vraagt naar "psychologische veiligheid" of "visie" (lees meer: Psychologische veiligheid) van hun agile softwareontwikkelingsteams, zijn ze het erover eens dat deze dingen belangrijk zijn, maar... Wanneer de klant urgentie signaleert of de deadline nadert, worden al deze "zachtere" variabelen meestal op een laag pitje gezet. Managers zijn vooral bezorgd over een voorspelbaar functionerende agile opleveringsstroom van hun agile team.

Als je een kijkje neemt op onze Echometer blog (naar onze blog), weet je dat onze inhoud zich meestal richt op het verbeteren van de zachte vaardigheden van teams en organisaties. Deze worden vaak onderschat door beleidsmakers. Maar niet door Scrum Masters en Agile Coaches.

Wat ik denk dat Scrum Masters en Agile Coaches weer onderschatten is de focus op het verbeteren van de opleveringsflow – eigenlijk wat managers willen. In de post van vandaag beschrijf ik een eenvoudige techniek om de waarschijnlijkheid van op tijd en binnen budget opleveren keer op keer aanzienlijk te vergroten.

Stap 1 in relatie tot je Agile Leveringsstroom

Ik heb het over het bewaken van de Agile leveringsstroom van je taken. Als je maar een paar dingen goed doet, zul je veel voorspelbaardere resultaten kunnen leveren. Zelfs je spreidingsdiagrammen van cyclustijden of je Monte Carlo simulatie voor het berekenen van projectschattingen zouden eindelijk geldige voorspellingen kunnen opleveren in plaats van er helemaal naast te zitten (lees meer: 9 Agile meetmethoden voor besluitvormers).

Het eerste symptoom dat moet worden bestreden is dat er taken zijn die er slechts een paar dagen over doen om van "Gepland" naar "Voltooid" te komen, en dan zijn er taken die er meer dan een maand over doen. Om dit tegen te gaan, moet je ervoor zorgen dat een taak altijd de kleinst mogelijke leverbare versie van de gewenste functie bevat. Zonder toeters en bellen die niet nodig zijn voor de kernvraag van de klant. In principe een MVT, Minimum Viable Task. Dit betekent niet dat het elke taak klein maakt. Maar het zou je moeten helpen een stadium te bereiken waarin taken hooguit een paar weken duren, in plaats van maanden.

Tweede stap in relatie tot je Agile Delivery Flow: WIP in plaats van Snelheid

Veel Scrum Masters of Kanban coaches geloven dat een geldige meting van snelheid e.d. afhangt van de "juiste dimensionering" van taken of werkitems, waarbij alle werkitems ongeveer even groot zijn. Alleen dan zijn story points (die nodig zijn om snelheid te meten) bruikbaar voor het meten van snelheid, omdat ze meer lijken op een vergelijkbare tijdseenheid. 

Maar dit is verkeerd: taken hoeven niet eens even groot te zijn. Je moet dit niet aannemen, want het is gewoon te moeilijk om schattingen van Story Points te controleren. Het enige dat je kunt controleren is hoeveel nieuwe taken je start.

Doe dus het volgende om voorspelbaar te worden: Monitor de snelheid van "nieuwe taken gestart" vergeleken met de snelheid van "taken voltooid". Deze twee moeten in evenwicht zijn. Met andere woorden, het percentage "binnenkomende" en "uitgaande" taken moet zo dicht mogelijk bij elkaar liggen, idealiter zelfs hetzelfde.

Een voorbeeld: Typisch gedrag in softwareontwikkelingsteams is dat zodra een taak is geblokkeerd, er een nieuw werkitem wordt gestart. Dit leidt ertoe dat veel taken openstaan maar niet worden voltooid, waardoor het veel ingewikkelder wordt om ze allemaal weer te deblokkeren. 

Als je er in plaats daarvan voor zorgt dat er voor elke taak die je begint ook een afgeronde taak is, zul je beter in staat zijn om de weinige gerichte taken in het Dagelijkse te deblokkeren. Je algehele prestaties zullen beter voorspelbaar zijn – en het team zal gelukkiger zijn omdat je manager en je klanten gelukkiger zullen zijn.

Enkele "positieve symptomen" van een gezonde Agile Delivery Flow

In de praktijk zou dit leiden tot het volgende gedrag:

• • We beginnen niet aan nieuwe taken als er nog veel dingen in uitvoering zijn. 

• • We richten ons op het afmaken van wat we zijn begonnen voordat we aan nieuwe dingen beginnen.

• • De leeftijd van de taken gaat nooit verder dan een paar weken.

• • Als er geen goede reden is, werken we altijd aan de oudste taak.

WIP (work-in-progress) limieten helpen hier ook bij, hoewel ze vaak niet genoeg zijn. Zodra het team leert om zich te richten op het afmaken van taken in plaats van op het starten van nieuwe taken, zul je beter zijn dan de meeste teams.

Als je de Agile Delivery Flow op de juiste manier gebruikt

Duidelijke verwachtingen scheppen: Op deze manier heb je nog steeds niet in de hand of een taak twee of drie dagen duurt. Maar je zorgt er tenminste voor dat je team niet aan zoveel taken werkt dat taken van 2-3 dagen uiteindelijk een maand duren.

Hoeveel beter zou je team zijn als je wist dat in principe aan alle leveringsverplichtingen binnen een paar weken zou worden voldaan? Dit veronderstelt natuurlijk dat je alle dingen implementeert die hierboven zijn genoemd: Het instellen van MVT's, een strikte WIP-limiet en een toezegging om taken niet opnieuw te starten totdat een andere taak is afgerond.

Stap 3: Aan de slag met het verbeteren van de Agile Delivery Flow

In theorie weet je wat je moet doen. Wat is nu de beste manier om praktisch aan de slag te gaan? Door bewustzijn en "veranderingsbereidheid" te creëren in het team. In het beste geval door zelfreflectie.

Je moet transparant zijn over deze cijfers en ze regelmatig controleren om te zien of de verhouding tussen begonnen en voltooide taken in balans is. Het kan deel uitmaken van je retrospectief om wat dieper in te gaan en na te denken over waarom de cijfers in de laatste cyclus niet in balans waren. 

Ik kan je aanraden om het gedrag dat ik noemde met onze agile retrospective tool Echometer te bespreken in je retrospective (lees meer: 7 Retrospectieve hulpmiddelen in vergelijking). Je zou dit zelfs onderdeel kunnen maken van je werkafspraken of regelmatige Health Check's om het bewustzijn te vergroten door de vragen regelmatig te stellen.

De volgende vragen zijn onze retrospectieve sjabloon voor "agile delivery" (lees meer: 22 leuke sjablonen voor agile retrospectives). We beginnen met een paar Health Check stellingen en vragen het team of ze het ermee eens of oneens zijn. Daarna volgen een paar open vragen: