Agile Delivery Flow: Altijd op tijd leveren in 3 stappen

Als je de meeste managers vraagt naar de “psychologische veiligheid” of de “visie” (meer hierover: Psychologische veiligheid ) van hun agile software development teams, 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 typisch opgeschort. De managers zijn vooral bezig met een voorspelbaar functionerende agile delivery flow van hun agile team.

Als je een kijkje neemt op onze Echometer blog ( naar onze blog ) hebt gesnuffeld, weet je dat onze content zich meer richt op het verbeteren van de “soft skills” van teams en organisaties. Deze worden vaak onderschat door besluitvormers. Maar niet door Scrum Masters en Agile Coaches.

Wat Scrum Masters en Agile Coaches volgens mij dan weer onderschatten, is de focus op het verbeteren van de Delivery Flow - in feite wat managers willen. In de huidige post beschrijf ik een eenvoudige techniek om de kans om keer op keer op tijd en binnen budget te leveren 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 het voor een valide meting van Velocity etc. aankomt op het “right sizing” van Tasks resp. Workitems, waarbij alle Workitems ongeveer dezelfde grootte hebben. Alleen dan zijn Story Points (die nodig zijn voor het meten van de Velocity) bruikbaar voor het meten van de Velocity, 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: Bewaak de snelheid van “nieuw begonnen taken” in vergelijking met de snelheid van “voltooide taken”. Deze twee zouden in evenwicht moeten zijn. Met andere woorden: De “ingangs-” en de “uitgangssnelheid” van taken zouden zo dicht mogelijk bij elkaar moeten liggen, idealiter zelfs overeenkomen.

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 begonnen taak ook een voltooide taak is, zal het in de Daily beter lukken om de weinige gefocuste taken te deblokkeren. Jullie prestaties zullen over het algemeen beter te berekenen zijn - en het team zal tevredener zijn, omdat jullie leidinggevende en jullie klanten tevredener zijn.

Enkele “positieve symptomen” van een gezonde agile 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. Hoe kun je nu het beste praktisch aan de slag? Door het bewustzijn en de “veranderingsbereidheid” in het team te creëren. 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.

Bij de volgende vragen gaat het om onze retrospectieve template voor de “agile Delivery” (meer hierover: 26 leuke sjablonen voor agile retrospectieven ). 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:

Agile levering retrospectief

Health Check Onderdelen

Wanneer heeft onze manier van werken geleid tot een suboptimale workflow? (bijv. onduidelijke, ongepaste of niet opgevolgde richtlijnen)

Zoals je je kunt voorstellen, impliceert het laatste punt van de Health Check (controleren van de oorzaak) al een potentiële maatregel, iets dat je voor een tot twee agile sprints kunt uitproberen om te zien of het jullie zou kunnen helpen: De beperking van het aantal taken met de status “Work in Progress”.

De basis leggen: Afspraken vastleggen voor teamwork

Heb je het gevoel dat je team nog niet klaar is voor dit soort reflectie? In dat geval moet je eerst reflecteren op “goed werk” in het algemeen en vervolgens enkele basisregels, zogenaamde werkafspraken resp. Working Agreements, vastleggen. De volgende workshop-template kan jullie daarbij helpen. Je kunt deze uitvoeren als een speciale vorm van retrospectieve aan het begin van een project of als een extra workshop.

Eerst moet je een gevoel krijgen van hoe eens je team zich impliciet voelt - zie hiervoor het Health Check Item. Dan moet je dit met een paar open vragen praktisch controleren. Elk teamlid moet de zin (zie verdere vragen) met zo veel mogelijk antwoorden beëindigen die hem/haar te binnen schieten:

Team verplichtingen terugblik

Health Check Onderdelen

Omgaan met conflicten: “Als ik merk dat er een conflict ontstaat in ons team, dan …

Nadat jullie de antwoorden hebben verzameld, moeten jullie natuurlijk proberen patronen te vinden en concrete afspraken te maken over hoe jullie in de toekomst willen samenwerken - ten minste tijdelijk als experiment.

Een interessant, creatief alternatief

Als deze retrospectieve methoden je te “droog” lijken, is er nog een andere retrospectieve methode die zich richt op het reflecteren van de kwaliteit van de output van je team ( Fun 54 Retrospectieve Methoden vind je hier ): De ‘Drie Kleine Varkens’ Terugblik. Het is een eenvoudig alternatief om te beginnen met reflecteren en het verbeteren van je prestaties, gebaseerd op het sprookje van de drie biggetjes die huizen bouwden van verschillende materialen.

Conclusie - Agile Delivery Flow

Het maakt niet uit hoe je begint, het belangrijkste is om op de eerste plaats te beginnen. De teams die hun Agile Delivery Flow actief in de gaten houden, zijn de betere teams.

Overigens zijn veel van de ideeën die je hier vindt ook goed samengevat in de podcast “Agile Bites”, die ik ten zeerste kan aanbevelen (Naar de podcast: Agile hapjes). 

Veel plezier met het ontwikkelen van je team!