Recensie De 10 mythes van agile werken.

In 2020 heb ik een virtuele wereldtrip gemaakt langs verschillende PMI chapters met een webinar met als titel Some Agile Myths Busted. De meeste mythes in dit boek kon ik dan ook direct plaatsen. Een paar had ik nog niet op mijn netvlies of ontkrachte ik zelf op een andere wijze. Ook gebruikte ik zelf nog een paar andere mythes. Dit boekje De 10 mythes van agile werken – en hoe daar mee om te gaan, geschreven door Harry Valkink en Giovanni Dhondt, biedt een mooi overzicht van de meest voorkomen mythes rond agile werken.

De auteurs putten uit hun jarenlange ervaring bij ING met agile werken. In de tekst wordt veelvuldig gerefereerd aan squads waarvoor je ook agile teams kan lezen en tribes die je kan zien als een team van teams (in andere agile raamwerken heten die dan bijvoorbeeld Agile Release Train of Nexus).

De volgende agile mythes worden uitgebreid beschreven waarbij ze zijn gerangschikt onder de noemers succesvol leveren en succesvol verbeteren:

Squads kunnen onafhankelijk opereren. Aan de hand van doelafhankelijkheid, resultaatafhankelijkheid en middelenafhankelijkheid wordt de mythe ontkracht en wordt aangegeven hoe afhankelijkheden zoveel mogelijk te voorkomen zijn en welke coördinatiemechanismen gehanteerd kunnen worden.
De Product Owner bepaalt de prioriteit. Een product owner handelt niet alleen. Hoe organiseer je alignment in een organisatie en communicatie over prioriteiten binnen en tussen tribes.
Design ontstaat incrementeel. Als je met meerdere teams aan dezelfde architectuur werkt ontkom je niet aan een overkoepelende architectuur. Hierbij kan rekening gehouden worden met ‘loosely coupled’ architectuur, standaard platforms, principes en richtlijnen en regie en ondersteuning door de architect.
Alle expertise zit in squads. Sommige kennis is extreem schaars en dat vraagt een andere manier van werken dan wanneer de kennis wijd en zijd verspreid is. Wellicht was hier een beschouwing van Team Topologies op zijn plaats geweest.
Er is geen planning nodig. Middels de agile plannings-ui wordt uitgelegd dat er zes verschillende planningshorizonnen zijn (dagelijks, sprint, release, product, portfolio, en strategie). Maak je een planning om alles te kunnen realiseren of is een beperkte subset voldoende. Een verwijzing naar het principe maximaliseren van de hoeveelheid werk die je niet doet en het onderzoek van de Standish Group dat 60% van opgeleverde functionaliteit niet of nauwelijks gebruikt wordt had hier ook gepast.
Teams halen altijd het maximale uit zichzelf. Een groep mensen maakt nog geen team. Bij het samenstellen moet rekening gehouden worden dat de mensen gemotiveerd zijn, kunnen omgaan met onzekerheden en vriendelijk en open zijn en vertrouwen in elkaar hebben.
Het meten van prestaties is niet meer nodig. Als je niet meet weet je ook niet of je je verbetert. Verschillende metrieken passeren de revue: proces (storypoints, velocity, voorspelbaarheid en sprint burn down), kwaliteit (first time right %, dekkingsgraad testen, fouten in productie), resultaat (NPV/storypoint, adoptiegraad, NPS).
Een Agile coach moet zich alleen focussen op de methode. Het focusgebied van de agile coach is in het begin van de coaching journey vooral gericht op de methode maar verschuift steeds meer naar het resultaat.
Business cases en budgetten doen er niet meer toe. Het gaat niet alleen om het hebben van capaciteit maar ook het inzicht in de businesswaarde of klantwaarde. Een businesscase op hoofdlijnen kan daarbij helpen. Dit hoofdstukje had wat mij betreft wat uitgebreider gemogen. Naast menscapaciteit kunnen er ook investeringen noodzakelijk zijn. Daarnaast kan de business case ook gebruikt worden om verschillende scenario’s naast elkaar te zetten. 0 scenario: niets doen, brons: het minimale (agile?), goud: met vele toeters en bellen (veelal niet nodig). Ook het beschrijven van een MVP in de businesscase is waardevol. Verder wordt het als een nadeel gezien dat bij WSJF lange termijn projecten niet van de grond komen. Een oplossing hierbij is het 3 horizons model of growth van McKinsey waarbij een stukje capaciteit wordt toegewezen aan lange termijn initiatieven.
Agile is the only way. Hoe complex (spaghetti structuur) zijn je legacy systemen? Kunnen squads en tribes end-to-end werken? Willen de teams en het management agile werken? Hoe complex is het probleem? Is het werk in zinvolle stukken onder te verdelen? Wat zijn de gevolgen wanneer er fouten worden gemaakt? Past de cultuur van de organisatie bij agile werken?
(Bonusmythe) Agile werkt alleen als je fysiek bij elkaar zit. Covid 19 heeft laten zien dat al thuiswerkend er toch prima resultaten geboekt kunnen worden. Agile (autonomie, prioriteiten, architectuur, motivatie) ondersteunt werken op afstand. Het vraagt uiteraard wel een aantal aanpassingen in de manier van agile werken zoals coaching, het motiveren van teams, het afstemmen met experts en het meten om objectief zicht te houden op wat er gebeurt.

Conclusie. Een vlotlezend boekje dat je behulpzaam kan zijn tijdens je eigen agile transitie. Het helpt je om een aantal veel voorkomende agile misverstanden te voorkomen.

Bestellen De 10 mythes van agile werken: managementboek.nl, bol.com