Als de eisen aan een systeem vooraf bekend zijn, dus écht niet zullen wijzigen gedurende het traject, heeft agile werken dan wel zin? Want, zo is vaak de door mij gehoorde redenatie, wendbaarheid of exploratief werken is dan immers niet nodig. Dit is naar mijn mening maar een halve waarheid en in deze blog wil ik graag mijn zienswijze delen waarom de agile manier van werken ook bij vaste eisen heel productief kan zijn.
Agile werken brengt de mogelijkheid tot wendbaarheid, zeker, maar het is voor mij veel meer dan enkel een methodiek waarmee we werken als we de eisen vooraf niet goed kennen of het is toegestaan eisen gedurende het traject te wijzigen zonder dat de leverancier meteen met meerwerk en contractbreuk dreigt.
Stel we hebben een project waarbij echt, echt, echt, de eisen niet zullen wijzigen. Bijvoorbeeld u wilt een rekenmachine app maken met 20 vastgestelde rekenfuncties. Of u wilt een legacy systeem één op één gaan overzetten naar een modern platform om de stabiliteit te verhogen en kosten te besparen.
Een waterval aanpak gaat nu als volgt: werk de eisen in detail uit, maak een architectuur van het geheel, maak er een high-level en vervolgens detail ontwerp van en dit pakket landt bij de programmeurs. Deze bouwen en integreren dit. Daarna testen we het gemaakte. Vervolgens komt de acceptatietest door de gebruikers en als ook productie akkoord is kan het live.
Het agile alternatief hiervan is anders: we nemen steeds een paar eisen van de stapel en doen hiervoor alle bovengenoemde stapjes, dus van architectuur tot accepteren of zelfs live. In de agile methodiek Scrum gebeurt dat in een periode van 1 tot 4 weken genaamd een sprint. Daarna evalueren we en passen eventueel onze werkwijze aan.
Flexibiliteit door het nu wijzigen van requirements is in deze blog dus geen issue. Maar brengt de agile aanpak ons hier toch extra zaken? Ik noem een paar punten.
Als het resultaat van het gedane werk al bruikbaar is, dan heeft dit zelfs na één of een gering aantal sprints al potentiele waarde. Wellicht wilt u met een rekenmachine met nog maar 4 functies al de markt op, om de concurrent voor te zijn of al een eerste klantenbestand op te bouwen met een gratis versie. Of u kunt het eerste deel van het oude systeem al uitfaseren en verhoogt hiermee al wat aan de stabiliteit of verlaagt een deel van de kosten. En u kunt daarbij testen hoe de klanten en gebruikers reageren op het deelproduct. O nee, dat heeft natuurlijk geen zin, want we zouden toch niets wijzigen aan de eisen!
Is dit waar? Is de door ons bedachte scherm lay-out wel handig, snappen ze de tooltips, werkt het handig? En vindt operations dat alles ook naar hun normen is? Al na één sprint leren we deze lessen, kunnen we bijsturen in ons maakproces. Bij waterval komen dit soort zaken pas aan het einde naar boven, nadat alles al gebouwd is. Wijzigingen kunnen dan heel wat extra kosten. Of u laat het maar zitten, maar het systeem is dan heel wat minder bruikbaar in de praktijk, en dat is schadelijk.
Zijn technologie keuzes ook goed? Bij agile werken leren we dat al vanaf de eerste sprint, maar bij waterval pas in de implementatiefase, na uitgave van een flink deel van de looptijd en het budget. Of misschien zelfs pas helemaal aan het einde. Ik heb het in mijn eigen praktijk meegemaakt dat pas bij acceptatie bleek dat het systeem dat “af” was, zwaar onvoldoende performde. In de bouwomgeving waar men testte ging het nog prima. Gevolg: ingrijpende architectuur aanpassingen, herbouw, 2 jaar uitloop en zwaar teleurgestelde klanten en management. Deze vervanging van dit legacy systeem had precies dezelfde eisen, toch ging het flink mis!
En planmatig? Klanten willen graag weten hoeveel iets gaat kosten en wanneer het af is. De organisatie moet gereed staan op het juiste moment en geld bijvragen kan vaak wel, maar niet keer op keer. Bij de waterval methode staan heel veel trajecten op 96% gereed, omdat het venijn in de staart zit. Bijvoorbeeld bij de integratie, het testen of als de gebruikers en productie het systeem eindelijk zien. Projecten lopen dan alsnog 50 tot 200% uit. Als we agile werken en na de eerste sprint 5% opgeleverd hebben, dan kunnen we voorspellen dat het hele systeem na 19 sprints af is, alhoewel op basis van N=1. Zijn we wat verder in het traject dan wordt de schatting steeds nauwkeuriger. Zelfs als we het in de laatste sprints heel bont maken, wat op zich heel vreemd is, lopen we hooguit een paar sprints uit. Deze voorspelbaarheid is erg prettig voor onder andere bestuurders.
Zal men ook bouwen wat in de eisen staat? Een waterval traject doet mij denken aan mijn verjaarsfeestjes van vroeger waar een kind een ander een verhaaltje influistert, dat zo van kind op kind wordt doorgegeven. Het is hilarisch wat er aan het eind uitkomt! Die vervorming en dat kennisverlies zit ook in fasering van waterval. Wat doen we daar dan tegen? Documenteren! Maar … ook documenten worden vaak slecht begrepen en sowieso kost al dat schrijven tijd. Agile teams werken continu samen in plaats en tijd en kennen dat effect niet.
Ten slotte: kwaliteit. Een agile team zal middelen gebruiken om het nieuwe en reeds gebouwde elke sprint steeds weer (automatisch) te testen. Hierdoor heeft het product steeds een hoge kwaliteit. Bij waterval zit integreren en testen éénmalig aan het einde. Naar mijn ervaring is men dan ook al vaak flink door het budget heen. Soms is er dan geen andere oplossing dan het maar ‘over de muur’ te gooien, met alle gevolgen van dien voor operations of erger, de klant of gebruiker.
Mijn conclusie: Agile werken kent veel meer voordelen dan het flexibel kunnen schuiven met eisen en exploratief kunnen werken. Al vanaf het begin worden resultaten opgeleverd en wordt toegevoegde waarde geleverd voor de gebruiker en klanten. Planningen worden beter en betrouwbaarder. Risico’s worden kleiner, behapbaarder en zijn eenvoudiger te managen. Er is continue aandacht voor kwaliteit en het totaal is doorgaans goedkoper door minder (documentatie) overhead en rework.
Ook in situaties waarin, of wordt verondersteld dat, eisen vaststaan kan een agile werkmethode uitstekend worden toegepast!