“En, jullie hebben hier zeker wel een heel goed gevoel over?“, zo vroeg de trainer tijdens de agile sessie.
Nou nee, dat had ik niet. We hadden zojuist in de derde sprint onze doelen gehaald. Dat wil zeggen: we hadden het aantal legohuizen gebouwd waar we ons aan gecommitteerd hadden. Maar de huizen waren steeds slechter geworden, ze vielen bijna uit elkaar.
De oefening om een stad te bouwen was bedoeld om de groep het gevoel te geven hoe je de hoeveelheid werk inschat en daarna samenwerkt om dat werk ook te verzetten. Maar er was een probleem: we zagen al meteen dat er niet genoeg materiaal voorhanden was om de klus te klaren. “Ach jawel” zei de trainer.
Sprint 1
De eerste sprint ging alles prima. We hadden een realistische inschatting van het werk. De eisen waren dat het ‘uniforme’ huizen waren (een kleur, even hoog etc) en daarom pasten we het tweede huis nog binnen de sprint aan. Resultaat: we hadden binnen een sprint zowel een standaard ontwikkeld als de productie gehaald.
Sprint 2
Maar die standaard was in sprint 2 al niet meer te halen. We kregen de huizen nog wel in een kleur, maar we moesten smokkelen met de hoogte en gaan smokkelen met de legosteentjes: de huizen waren lang niet meer zo stevig als de set uit sprint 1. Wel was onze productie een stuk omhoog gegaan.
Sprint 3
In sprint 3 gingen in overleg met de trainer (de klant) de kwaliteitseisen nog verder omlaag. De huizen hoefden nu niet meer in dezelfde kleur. Maar dat was niet genoeg. We moesten nog meer kleine stukjes aan elkaar plakken en we verborgen een gat achter papier. De huizen waren tijdens het bouwen verschillende keren ingestort maar we haalden onze deadline. Onze productie was weer omhoog gegaan; na drie sprints stond de volledige stad. Maar aan de achterkant zagen de huizen er in sprint 3 nogal krakkemikkig uit:
Ik had medelijden met de toekomstige bewoners. Gegarandeerd dat een aantal een dak op hun hoofd zouden gaan krijgen.
Wat kunnen we hieruit leren?
Dat ‘agile’ niet automatisch garant staat voor goede producten. Voor de opdrachtgever waren hier namelijk maar twee criteria doorslaggevend:
- De vooraf gestelde kwantiteit
- De snelheid van werken
Agile en ontwerp
Maar is dat dan agile werken? Natuurlijk niet. Het had ook helemaal anders kunnen gaan.
In het begin was er al een inschatting gegeven dat het materiaal niet toereikend was. We hadden de opdracht ook anders kunnen in gaan vullen: bijvoorbeeld door meer flats te bouwen i.p.v. losstaande huizen. Daarmee was de échte doelstelling (mensen fatsoenlijk huisvesten zonder dat ze verongelukken) beter gehaald.
Of we hadden meer tijd moeten nemen om een type woonhuis te ontwikkelen met minder materiaal: een fatsoenlijk Minimal Viable Product dus. Daarmee waren we in het begin langzamer geweest, maar op het einde sneller met een betere kwaliteit.
Beide opties waren hier uitgesloten omdat:
- De opdrachtgever vooraf de vorm al in zijn hoofd had. En daar bleef hij aan vasthouden toen het project onder druk kwam te staan. Niet de kwantiteits-maar de kwaliteitseisen gingen omlaag.
- Er was geen tijd om te prototypen voordat het product de markt opging.
- En was er ook geen tijd om het ontwerp gaandeweg te verbeteren: we konden niet testen .
Kortom: de opdrachtgever hield totaal geen rekening met de beslissende rol die ontwerp binnen agile speelt om een goed product te maken.
Zo zie je maar, software blijft mensenwerk, welke procedure je ook maar toepast. Wat dat betreft was het voor mij een erg verhelderende training.