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!
Het artikel beschrijft uitgebreid hoe Agile projecten kunnen bijdragen tot een effectieve manier van softwareontwikkeling. Een van de kritieke succesfactoren van de Agile aanpak is echter wel dat er mandaat is bij het project team en dat het team voldoende business vertegenwoordiging heeft. Met lean wordt terecht gedoeld op het focussen op alleen die features die echt waarde leveren voor de business. Bij de Agile aanpak wordt dat vanzelf geregeld omdat de volgorde waarin features worden gebouwd typisch op volgorde van belangrijkheid gebaseerd is.
Dat is allemaal erg mooi. Maar hoe houd je dat allemaal in de gaten? Features die op volgorde worden gezet, aanpassingen daarop gedurende het project en niet te vergeten ook nog de issues die het gevolg zijn van de broodnodige feedback.
Kortom een goede Agile projectmanagement ondersteuning is daarbij geen overbodige luxe. Wij gebruiken hiervoor een complete suite die het gehele Agile ontwikkel proces vanaf scoping & sizing van de requirements, sprintplanning, project management tot en met het managen van de feedback kan verzorgen. In combinatie met het OutSystems Agile ontwikkelplatform kan zelfs een aanzienlijke kostenbesparing en kortere doorlooptijd van het project behaald worden. In de meest recente release van het platform is applicatie ontwikkeling zelfs gecombineerd met Business Proces Technologie. Hiermee worden twee traditioneel gescheiden werelden, BPM en Applicatie ontwikkeling, naadloos ineen geschoven.
Goede samenvatting van een Agile proces in een project. Naar aanleiding van het verhaal en de reactie hierboven heb ik nog wel een aantal aandachtsgebieden. Hoe verhouden Lean en Agile zich, hoe om te gaan met Architectuur, Hoe om te gaan met fixed budget, etc etc. Het voert nu te ver in een reactie om daar allemaal antwoord op te geven, dat zijn stuk voor stuk artikelen op zichzelf. De belangrijkste is echter dat de focus van Agile en haar resultaten op het proces en de werkwijze worden verhaald, en er vooral wordt uitgelegd HOE het concreet werkt.
De methodiek en het proces is echter binnen Agile ondergeschikt aan de focus op “hoe willen mensen eigenlijk werken’, en ‘wat motiveert mensen om de juiste dingen te doen’. Dit zijn de basiselementen WAAROM Agile is ontstaan. De teams die in waterval werkten aan de deelproducten VOELDEN zich niet gecommiteerd aan het eindresultaat. De doelstelling is dan ook vooral geweest om te zorgen dat mensen weer het verschil kunnen maken in een project. Het Agile manifest richt zich daarom op ‘mensen en interactie’ boven ‘processen en tools’.
Om projecten succesvoller te laten zijn is de focus daarom op het inrichten van een structuur die optimaal ruimte biedt voor een nieuwe cultuur en nieuwe verantwoordelijkheid. Zoals hierboven in de reactie van Ruud wordt beschreven zijn er allerhande tools en suites die je kunnen ondersteunen. De focus dient te zijn op de mensen in de teams en hoe ze opgelijnd staan om het business doel te verwezenlijken. Tools pas je toe zodra ze waarde kunnen toevoegen en de effectiviteit niet in de weg zitten. Effectiviteit OVER Efficiency. In willekeurig welk project maken de mensen het verschil. Agile processen zijn erop gericht om dat verschil maken maxiaal mogelijk te maken binnen de risico-management en verwachtingsmanagementprofielen van het project.
Overigens wordt in het artikel van Anko en de reacties nog niet gesproken over Lean. De verbinding tussen Agile en Lean is verwarrend. Agile is een software development principe, dat een aantal van de lean principes in zich heeft. Lean zegt niets over hoe je software development moet doen, is een business raamwerk dat verbetering in je organisatie nastreeft. Alle onderliggende principes (eliminate waste, just in time, add nothing but value, see the whole etc) worden gebruikt om die verbeteringsprocessen richting te geven.
Lean is zorgen dat je bedrijf verbetert, Agile gaat over het inrichten van je ICT zodat het business aligned is en zich richt op het enablen van de business. Er zitten vervolgens lean principes in die zorgen dat verbetering gelijk geborgd is. Agile bevat best practices op basis van de ICT ervaring van de afgelopen 10/20 jaar (het aantal jaar is arbitrair, uiteraard)
Agile heeft de naam om een freestyle, laissez faire methodiek te zijn. Het tegengestelde is waar. Goede Agile projecten houden zich aan duidelijke regels, richtlijnen, een helder tijdschema, kwaliteitscriteria en duidelijke oplevermomenten. Deze zaken worden continu gemeten en geëvalueerd. In dat opzicht is een watervalproject meer laissez faire dan Agile. Het niet consequent toepassen van de Agile regels heeft tot gevolg dat Agile niet echte van de grond komt. Bepalend voor het succes van een Agile project is de projectleider / coach die zorgt dat het proces juist verloopt. Dit is vergelijkbaar bij een watervalproject. Het succes van waterval is ook sterk afhankelijk van de kwaliteiten en capaciteiten van de projectleider. Voordeel van Agile is echter wel dat wijzigen makkelijker kunnen worden doorgevoerd en dat het project sneller kan worden bijgestuurd. Bij waterval zie je het resultaat pas op het einde. Bij Agile krijg je in iedere iteratie feedback over de het resultaat. Een projectleider kan zich in een watervalproject tot het einde verstoppen tot hij door de mand valt. Bij Agile zie je veel eerder de kwaliteit van de projectleiding. Succes of falen van projecten is mensenwerk. Een slecht team wordt geen goed team door hier een andere methodiek voor te gebruiken. Net als in traditionele projecten haal je het meeste succes met gedreven en enthousiaste experts. Agile is leuk en trekt daardoor gedreven experts aan. Ik geloof sterk in de werking van deze methodiek voor projectsucces, echter wordt de meting enigszins vertekend doordat een gedreven methodiek succesvolle mensen aantrekt die zorgen voor projectsucces.
Agile leent zich minder voor ontwikkeling van omvangrijke toepassingen. Bij Agile is ook de onderhoudbaarheid een groter probleem dan bij traditionele ontwikkelmethodieken. Agile leent zich niet goed voor een beheersituatie waarin regelmatig veranderingen op het gemaakte product doorgevoerd worden. Agile is een vorm van “disposable ICT”. Het is goed te gebruiken, maar niet langdurig. Voor je kiest voor een Agile aanpak moet je dus wel eerst kijken wat voor ICT oplossing je nodig hebt. Als dat een onderhoudbare oplossing moet zijn kan je beter kiezen voor een watervalmethodiek in combinatie met incrementeel ontwikkelen. Dan profiteer je van “best of both worlds”.
@Andre: waarop baseer je al die aannames?
Ik vermoed dat jij vermoedt dat Agile beperkte documentatie oplevert. Maar dat is een misvatting: Agile steekt veel minder energie in documentatie-als-tussenproduct-van-het-ontwikkelproces. Agile levert wel documenten op die *daadwerkelijk* door de klant gebruikt gaan worden.
Een voorbeeld: als het een beheereis is dat er een ontwerpdocument wordt opgeleverd dan zal een agile team dat ook doen. Alleen niet voordat de software ontwikkeld wordt, maar als onderdeel van de oplevering bij de iteratie, het voldoet daarmee aan de zgn ‘Definition of Done’. Je kunt dus iedere onderhoudsbaareis opnemen in die Definition en daarmee is de Agile aanpak dus geen vorm van ‘disposable ICT’ (vreselijke term trouwens).
Anko,
Ik nog wat vragen:
Zijn er al meetresultaten over de productiviteit per functiepunt, het aantal defects en gewenste wijzigingen in productie? Wordt de onderhoudbaarheid van de programmatuur gemeten?
Een veel voorkomende valkuil bij agile software ontwikkeling is die van de ontbrekende of onvoldoende betrokken klantrol of ‘product owner’. Hierdoor is een team agile bezig met zichzelf, hetgeen een aantal prima practices brengt maar er is niemand om agile (ofwel flexibel) mee om te gaan. Terecht wordt in het artikel aangehaald dat één van de belangrijkste factoren de betrokkenheid is vanuit de klant.
Dit illustreert meteen waarom agile moeilijk is voor productontwikkelaars. Wie is dan je klant? Hoe bepaal je de requirements van een groep mensen? Agile (praktisch vaak onder de noemer SCRUM en sprint-gebaseerd) ontwikkelen geeft dan wellicht onnodige overhead die met bijvoorbeeld een Lean (vaak gerefereerd als Kanban) benadering geëlimineerd kan worden.
Soms wordt gedacht dat agile niet geschikt zou zijn voor de grotere systemen: er zou te weinig aandacht zijn voor architectuur, onderhoudbaarheid, documentatie. Net zoals documentatie kunnen ook onderhouds-/architectuureisen meegenomen worden in definition of done of als Backlog items. Leveren die eisen dan ‘value’ op? Jazeker, want gemiddeld 70% van de kosten van een systeem zitten in onderhoud, dus features voor een goede architectuur mogen op de Backlog zeker niet ontbreken. Daarbij helpt Agile nog door alle features en dus ook de architectuur features daadwerkelijk te bouwen en te testen. Dit biedt dus een extra mogelijkheid om robuuste systemen te ontwikkelen.
@Rob: die cijfers zullen er vast zijn, maar ik heb ze niet. Probeer Google eens.
@Andre: Ik heb bij 2 productontwikkelaars ook agile gewerkt en in beide gevallen werkten we met een ProductManager. Hij is de “customer proxy”; diegene die de klantstem vertegenwoordigt.