Traditionele projectrisico’s beheersen met agile/lean

Iedereen kent de cijfers: ict-projecten hebben een beschamend laag percentage projecten dat succesvol is. Te veel in scope of te complex, te weinig gebruikersbetrokkenheid, onrealistische deadlines, wijzigende doelen… Veel factoren die succes in de weg staan. Die factoren zijn zo complex en verspreid, daar is geen 'silver bullet' voor. Toch mogen we ons als professionals afvragen in hoeverre we onze projecten zodanig inrichten dat we actief sturen op het voorkomen van die overbekende risico’s. Mijn ervaring is dat wanneer je de agile-methode toepast op projecten, je op een adequate manier kunt sturen op het voorkomen van de meeste faalfactoren van traditioneel ingerichte projecten. Daar bovenop kun je met de lean-aanpak het ontwikkelproces als geheel ook nog eens aanzienlijk verbeteren. Allereerst zal ik deze methodes uitleggen.

De agile-aanpak is voortgekomen uit de iteratieve ontwikkelmethodes uit de midden jaren ’90, zoals RAD en DSDM. Agile is niet één methode maar meer een beweging bestaande uit methodes, waarvan scrum, XP en DSDM/Atern de bekendste zijn. Deze methoden hebben elkaar gevonden in een manifest, het Agile Manifesto. Wat ze met elkaar gemeen hebben is dat ze iteratief, kortcyclisch, getimeboxed werken en er sprake is van nauwe klantinteractie en het nastreven van hoge waarde voor de klant. Uitgangspunten zijn onder meer het kunnen inspelen op veranderingen gedurende het traject, een samenwerkingsgerichte aanpak en het waarderen van menselijke interacties boven processen en tools.

Bij het toepassen van de lean-aanpak op softwareontwikkeling ontstaat een soortgelijk waardepatroon als bij de agile-aanpak. Alle verspilling (dat wat primair geen waarde toevoegt voor de klant, zoals wachttijd en onnodige proceshandelingen) wordt geëlimineerd, het proces is erop gericht om fouten te voorkomen (‘zero defects’), waarmee de doorlooptijd van de waardecreatie wordt zo kort mogelijk gehouden. Binnen lean wordt, net zoals bij agile, gewerkt met zelfsturende teams die beslissingen mogen en durven nemen (‘empower the team’). Daarnaast staat continue verbetering van het proces centraal: alles is erop gericht om het proces steeds te optimaliseren.

Hoewel dergelijke projecten zeker ook hun problemen hebben, de typische werkwijze rekent wel af met de faalfactoren uit de watervalmethode. Hieronder worden vier van die bekende factoren besproken: harde deadlines, frequent wijzigende specificaties, omgaan met complexiteit en het betrekken van gebruikers in het proces. Ik zal toelichten op welke manier de agile- en lean-aanpak deze factoren beheerst.

Harde deadlines
Volgens de traditionele software-ontwikkelmethode SDM (‘waterval’) bepalen we eerst de scope en dan de planning. De deadline is daarmee het gevolg van de gewenste scope. In het geval dat de deadline in het gedrang is, is de meest simpele manier om de deadline te halen dus het beperken van  de scope. Echter, prioritering gebeurt maar weinig in de traditionele aanpak en als het gebeurt dan op een grof, releasematig niveau. In de eerste release 'moet' een bepaalde functionaliteit gerealiseerd zijn, anders is het niet waardevol. Maar wist je dat uit diverse onderzoeken naar voren komt dat nog geen 35 procent van de gerealiseerde functionaliteit vaak tot regelmatig gebruikt wordt? Dat betekent dus dat er 65 procent te veel functionaliteit ontwikkeld wordt. Een release mag dus best een onsje minder zijn!

De agile-aanpak tackelt deze problematiek adequaat: alle requirements op de product backlog worden geprioriteerd en bij de start van de iteratie worden de op te pakken functionaliteiten ook nog eens onderling geprioriteerd. Daarmee wordt geborgd dat alleen de meest waardevolle software het eerst wordt gerealiseerd. Die keuze wordt door de klant gemaakt, waarbij het ict-team uiteraard adviseert op technische mogelijkheden en efficiëntie. Binnen de lean-aanpak wordt ‘overproductie’ als een vorm van verspilling gezien. Maak dus alleen wat je daadwerkelijk ook gaat verkopen. In softwaretermen is dat: ontwikkel alleen die requirements die je daadwerkelijk ook in productie gaat gebruiken.

Daarnaast kent de agile-aanpak iteratieve, 'potentieel productierijpe' opleveringen. Het team streeft er dus naar om iedere iteratie naar productie te brengen. Iedere iteratie heeft dezelfde hoge kwaliteitseisen zoals minimale dekkingsgraad van de unittest, te hanteren codeerstandaarden op te leveren handleidingen en bijvoorbeeld een acceptatietest. In veel organisaties betekent dit dat de releasekalender van de beheerafdeling veelal de beperking is om in productie te gaan. Op de agile-/lean-manier kun je dus actief je deadline managen door de scope te prioriteren en tijdig afspraken te maken na hoeveel iteraties het systeem live gaat.

Wijzigende specificaties
Omdat bij de watervalaanpak de scope als leidend wordt beschouwd en de planning hierop gebaseerd is, worden wijzigende specificaties hierin zoveel mogelijk tegen gehouden. De leverancier wordt immers gehouden aan het opgestelde contract waarin de scope nadrukkelijk is opgenomen. Het rework op de eenmaal afgestemde scope is duur omdat er naderhand activiteiten met terugwerkende kracht moeten worden uitgevoerd. En dat terwijl gedurende het project het product juist steeds tastbaarder wordt! Maar, om met lean software development-goeroe Mary Poppendieck te spreken: 'If you have requirements churn, you are specifying too early. If you have test-and-fix cycles, you are testing too late.'. De details van een requirement moeten dus veel later dan traditioneel gebruikelijk uitgewerkt worden, anders bestaat de kans dat de wens nog verandert. En herstel dus duurder wordt.

De agile-aanpak rekent hiermee af door de requirements op te delen in kleine, volledige brokken; de iteratieve werkwijze. Deze requirements zijn ruw uitgewerkt, ze zijn op inhoud afgestemd met de klant en bevatten acceptatiecriteria. Maar ontwerp- en implementatiebeslissingen zijn nog niet genomen want dat gebeurt pas in de iteratie. Doordat de requirements in de iteratie door alle disciplines integraal worden opgepakt, worden eventuele fouten snel ontdekt. Rework op requirements is dus niet duur want de investering vooraf is beperkt. En tijdens de iteraties zijn alle disciplines bij keuzes betrokken waardoor de kans geminimaliseerd wordt dat er later geconstateerd wordt dat er nog iets hersteld moet worden. Hiermee wordt ook het lean-principe ‘wachten’ geminimaliseerd: het team heeft relatief requirements ‘in bewerking’. Weliswaar staan de requirements op de backlog te wachten, maar eenmaal opgepakt worden ze binnen de iteratie verwerkt.

Het managen van complexiteit
Traditioneel maken architecten een uitgebreide analyse van het te ontwikkelen systeem in relatie tot haar omgeving. Een valkuil hierbij is dat de hoeveelheid analyse dermate groot is dat er vrijwel niet aan het systeem begonnen kan worden. In de hoofden van de analytici wordt het systeem dermate complex dat beslissingen nog maar zeer moeizaam genomen worden omdat ze vrijwel overal effect op hebben.

Agile-projecten gaan pragmatischer met dit dilemma om; op basis van werkende software en aan de hand van tastbare testresultaten. De analyse vindt dus niet uitsluitend in hoofden plaats maar ook aan de hand van werkende software. Door middel van een prototype, een proof-of-concept of een intelligente stub of driver kan de impact op de ict-architectuur veel sneller en vaak beter beoordeeld worden. Echte, tastbare resultaten zijn een veel betere voorspelling van de haalbaarheid en kwaliteit dan een papieren analyse.

Het reduceren van complexiteit wordt binnen lean beheerst aan de hand van de principes ‘niet geschikte handelingen’ (inappropriate processing) en ‘onnodige bewegingen’ (unnecessary motion). Het gaat daarbij om het reduceren van handelingen. Zowel in technische zin (gebruik van de juiste tools) als in procesmatige zin (zorg ervoor dat een taak snel tot het eindresultaat komt). Voor softwareontwikkeling houdt dit in, gebruik alleen de beste tools en voorkom het meerdere malen overdragen van een taak.

Betrekken van gebruikers bij de ontwikkeling
Tijdens de acceptatietest gaat het nog wel eens mis, de eindgebruikers constateren dat het systeem niet aansluit bij hun wensen, laat staan hun werkwijzen. Ze spreken hun ongenoegen uit en geven een duidelijke no go. Niet verwonderlijk als je bedenkt dat ze maanden eerder geïnterviewd zijn en tussentijds amper betrokken zijn bij beslissingen. Hun stem is dus gedurende het traject amper gehoord terwijl zij wel dagelijks met het systeem moeten werken.

Hoe anders gaat de agile-aanpak met gebruikers om. Niet alleen worden zij in de opstartfase van het project geïnterviewd, ook tijdens het iteratieve proces hebben zij een belangrijke rol. Zo wordt er iedere iteratie een acceptatietest door hen uitgevoerd, op basis van een door henzelf opgesteld acceptatietestscript. Uiteraard stemmen zij de inhoud van deze testgevallen af met het team, zodat je zeker weet dat het systeem aan die criteria kan gaan voldoen. Immers, vooraf borgen van kwaliteit is effectiever dan achteraf constateren dat de test niet geslaagd is. Dan is rework immers onvermijdelijk. Feitelijk bestaat de acceptatietest op deze manier uit een tweetal aspecten: een informele acceptatietest waarin de gebruikers veel feedback aan het team geven en waarbij ze zorgen dat het team conform hun wensen wordt gebouwd en daarnaast is er ook een formele acceptatietest, na de demo voeren de gebruikers hun acceptatietest op het systeem uit. Maar die is niet bedoeld om nog fouten te constateren. Het is meer de bevestiging dat het goede systeem ontwikkeld is.

Zijn Agile en Lean dan de silver bullets? Helaas niet. Ook deze projecten hebben bepaalde faalfactoren, zoals de invulling van de actieve klantrol. Maar uiteindelijk is een methode ook niet meer dan een manier om een bepaald type fouten te voorkomen. De agile-/lean-aanpak pakt de actuele problemen bij de kop en nivelleert ze adequaat. Wijzigende specificaties zijn niet langer meer een onvermijdelijk kwaad want variatie hierin is meegenomen in de projectopzet. Onmogelijke deadlines zijn niet langer meer een molensteen om de nek van het project, maar worden proactief beheerst door iteratieve opleveringen. Complexiteit staat niet langer meer synoniem voor uitgebreide analyses, maar wordt gereduceerd door middel van kleine voortgangsmetingen. En gebruikers dragen hun steentje bij aan de ontwikkeling, waardoor de acceptatie veel voorspoediger verloopt en het systeem meerwaarde voor hen krijgt. Mijn ervaring is dat deze projecten voorspelbaar verlopen, een hogere kwaliteit leveren en meer waarde voor de business opleveren. Dit zouden meer organisaties moeten doen!