Een iteratieve waterval is niet agile

De afgelopen twee jaar is me een zorgwekkende trend opgevallen – en wel bij teams over de hele wereld.

Het is de neiging om een iteratief watervalprocces te creëren en dat vervolgens "agile" te noemen.

Een iteratieve waterval

In een Sprint probeert iemand (misschien een Business Analyst samen met de [Product Owner](/nl/product-owner/ "Product Owner)), uit te vinden wat er ontwikkeld moet worden.

Omdat men agile wil zijn, wordt er met User Stories gewerkt. Maar in plaats van de User Stories als placeholder voor latere gesprekken te behandelen, wordt elke User Story een klein specificatiedocument van drie tot vijf pagina's – en ik heb zeker nog langere gezien.

Deze mini-specificaties/User Stories documenteren bijna alles wat je er maar over kunt bedenken.

Omdat je een hele Sprint nodig hebt om dat allemaal uit te zoeken en te documenteren, wordt een tweede Sprint gewijd aan het design van de User Interface voor de User Story. Soms probeert het team een beetje agiler te zijn (tenminste in gedachten) en begint het al met het designwerk kort voordat de mini-specificatie voor een User Story volledig geschreven is.

Veel teamleden zien dit als gevaarlijk, omdat de specificaties nog niet volledig vastgelegd zijn. Maar ach, dan komt op dit punt de agiliteit om de hoek kijken.

De programmeurs krijgen vervolgens twee documenten in handen gedrukt. Het ene laat duidelijk zien hoe de User Story er uiteindelijk uit moet zien, en het andere levert alle relevante details over het gedrag van de Story.

Je kunt pas beginnen met programmeren als deze twee artefacten klaar zijn. In sommige organisaties zijn het de programmeurs die deze werkwijze afdwingen. Ze hebben de instelling om alles te ontwikkelen wat je wilt – maar je kunt ze maar beter aan het begin van de Sprint precies vertellen wat er nodig is.

Sommige organisaties gaan zelfs nog een stap verder en laten de testers een iteratie achter de programmeurs aan werken. Dit gebeurt kennelijk omdat de User Stories van een team groter worden wanneer elke Story een mini-specificatie en een volledig UI-design moet hebben voordat er code geschreven kan worden.

Gelukkig is het de meeste teams duidelijk dat programmeurs en testers in dezelfde Iteratie moeten samenwerken, maar ze breiden deze theorie niet uit naar een heel samenwerkend team.

Dat leidt tot het volgende proces

Een eerste iteratie wordt gewijd aan de analyse. Een tweede iteratie (die eventueel licht overlapt met de eerste) wordt gewijd aan User Experience Design en de derde iteratie is bedoeld voor het coderen en testen. Dat is niet agile. Het zou de eerste stap van een organisatie kunnen zijn om agile te worden. Maar het is niet agile.

Het is een iteratieve waterval.

Bij traditionele ontwikkeling met waterval rondt een team de volledige analyse voor het hele project helemaal aan het begin af. Daarna wordt het volledige ontwerp voor het project aangepakt. Vervolgens wordt de code voor het hele project geschreven. En tot slot worden alle tests voor het project uitgevoerd.

In het zojuist beschreven iteratieve watervalprocces doet het team het in feite op dezelfde manier, maar wordt elke story als een eigen klein project behandeld. Eerst wordt de volledige analyse voor de story afgerond, dan het ontwerp voor die story, vervolgens wordt alle code geschreven en alles getest. Dit is een iteratief watervalprocces, geen agile proces.

In een agile proces zou idealiter al het werk op precies hetzelfde moment worden afgerond. Het team zou dus tegelijkertijd klaar zijn met de analyse van het probleem, het ontwerp voor de oplossing, de code en de tests voor die oplossing. Alle vier disciplines (en andere die ik in dit voorbeeld niet heb behandeld) zouden dus op exact hetzelfde moment klaar zijn.

Het is een beetje naïef om te geloven dat je dit voor 100% kunt bereiken. (Soms lukt het wel.) Het kan echter een doel zijn waar een team naartoe werkt.

Een team zou altijd moeten proberen om zoveel mogelijk werk tegelijkertijd te doen. Alle overwegingen die je vooraf maakt (analyse, ontwerp etc.) zouden zo laat mogelijk moeten plaatsvinden, niet al te gedetailleerd zijn en het tegelijkertijd mogelijk maken dat het werk tijdens de iteratie kan worden afgerond.

Als je je User Stories als kleine specificatiedocumenten behandelt, stop daar dan mee. Begin in plaats daarvan elke story te zien als een placeholder voor een gesprek. Je kunt de stories gerust voorzien van wat aantekeningen over dingen die je bij de volgende bespreking niet wilt vergeten. Deze aantekeningen zouden echter optioneel moeten zijn en geen noodzakelijke stap in een sequentieel proces. Dat behoudt de agiliteit en voorkomt dat het proces een waterval wordt.

Deze tekst is afkomstig uit de blog van Mike Cohn en is door ons vertaald naar het Nederlands.

Stakeholdermanagement

=> Leer de belangrijkste tips & tricks van Roman Pichler over Stakeholdermanagement

Definition of Done: simpel en toch complex

=> Ontdek hoe de Definition of Done je helpt bij agile werken.

Hoe verloopt een Sprint Review?

=> Hier vind je een voorbeeldagenda voor de Sprint Review