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, etc. De agile-methode kan veel faalfactoren voorkomen en met de lean-aanpak wordt het ontwikkelproces verbeterd. Onze experts van het topic Development aan het woord.
Anko Tijman, partner agile testen, Ordina
Er zijn 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.
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.
Zijn agile en lean 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.
André Weber, manager outsourcing testen, Capgemini
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'.
André Boonzaaijer, cto, Sogyo
Een veel voorkomende valkuil bij agile-softwareontwikkeling is die van de ontbrekende of onvoldoende betrokken klantrol of producteigenaar. Hierdoor is een team agile bezig met zichzelf, hetgeen een aantal prima practices brengt, maar er is niemand om agile mee om te gaan. Eén van de belangrijkste factoren is de betrokkenheid 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-benadering (vaak gerefereerd als kanban) geëlimineerd kan worden.
Theo Gerrits, senior business consultant, Xebia
Soms wordt gedacht dat agile niet geschikt zou zijn voor de grotere systemen: er zou te weinig aandacht zijn voor architectuur, onderhoudbaarheid en documentatie. Net zoals documentatie kunnen ook onderhouds-/architectuureisen meegenomen worden in definition of done of als backlog-items. Leveren die eisen dan waarde op? Jazeker, want gemiddeld 70 procent van de kosten van een systeem zit 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 architectuurfeatures, daadwerkelijk te bouwen en te testen. Dit biedt dus een extra mogelijkheid om robuuste systemen te ontwikkelen.
Christiaan Heidema, software architect, Sogeti Nederland
Veel ict-projecten falen door een te lange doorlooptijd. In de traditionele projecten moeten de requirements in een vrij vroeg stadium bekend en vastgelegd zijn. De lange doorlooptijd leidt vaak tot gewijzigde requirements gedurende het project. Agile-software biedt goede mogelijkheden deze wijzigingen het hoofd te bieden. Detaillering vindt veel later binnen het project plaats. De kans van slagen van het project wordt aanmerkelijk verhoogd. Naast requirements blijft ook focus op beheerdocumentatie noodzakelijk. Het projectsucces wordt in feite pas bepaald, niet na de implementatie, maar na een bepaalde tijd van exploitatie en integratie binnen de beheerorganisatie.
Ruud Hochstenbach, technical partner manager, OutSystems Benelux
Een van de kritieke succesfactoren van de agile-aanpak is dat er mandaat is bij het projectteam en dat het team voldoende businessvertegenwoordiging 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-projectmanagementondersteuning is daarbij geen overbodige luxe.
Robbrecht van Amerongen, projectmanager, expertisemanager projectmanagement en software engineering, Amis Services
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 echt 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 wijzigingen 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 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.
Experts gezocht
Computable heeft op al zijn 26 topics een expertpanel. Wij zoeken echter altijd meer experts, op al onze topics, maar voor de komende tijd zoeken wij specifiek naar experts voor de topics Netwerken, Business Intelligence, ERP, Outsourcing en CRM.
Ben jij expert op een van deze vakgebieden of een ander Computable-topic en wil je als vraagbaak van de redactie dienen, stuur dan een e-mail met je gegevens (naam, functie, bedrijf, werkzaamheden) naar experts@computable.nl.
