Skip to main content

Themes

Digital / IT Transformation
Leading Change

Contents

    Introductie in agile projecten

    Interview met Liesbeth Westenberg en Joost Koedijk

    Interview: Hans Donkers, hoofdredacteur Compact

    In dit artikel hebben we ter introductie van het onderwerp Liesbeth Westenberg en Joost Koedijk een aantal vragen voorgelegd over de populariteit en toepassing van agile methoden. Steeds meer organisaties laten de traditionele watervalmethoden achter zich en gebruiken agile methoden en met name Scrum voor softwareontwikkeltrajecten. Wat is nu de kern van agile en hoe is dit toepasbaar? Een introductie in een vraaggesprek.

    Wat is agile?

    Agile staat voor het incrementeel ontwikkelen van software in korte overzichtelijke perioden (één tot vier weken), gericht op het opleveren van werkende software aan het eind van iedere periode. Er wordt gewerkt in multidisciplinaire teams, waarbij de opdrachtgever (product owner) een belangrijke rol speelt. Agile softwareontwikkeling staat tegenover de traditionele ‘waterval’-methoden, die bestaan uit vaste fasen (informatieanalyse, functioneel ontwerp, technisch ontwerp, bouw, test, oplevering) en waarbij pas na afronding van een fase kan worden overgegaan naar de volgende fase.

    De methoden die onder de noemer agile vallen (zoals Scrum), bestaan al langer dan de term agile. De term is ontstaan bij het opstellen van het ‘Agile Manifesto’, dat wordt gezien als de geboorte van het concept. Het Agile Manifesto is opgesteld in 2001 tijdens een informele bijeenkomst van zeventien softwareontwikkelaars in de Amerikaanse staat Utah.

    C-2014-3-Westenberg-01

    Figuur 1. Agile Manifesto (bron: http://agilemanifesto.org/iso/nl/).

    Wat zijn eigenlijk de problemen met traditionele softwareontwikkelmethoden?

    Traditionele softwareontwikkelmethoden zijn vaak log en bureaucratisch. Door het gebrek aan flexibiliteit kan niet gemakkelijk worden omgegaan met voortschrijdend inzicht of bijgestelde doelstellingen. Daarnaast is door de vaak lange tijd tussen ontwerp en oplevering de betrokkenheid van organisatie en gebruikers gedurende een groot deel van het project minder, waardoor de software minder vaak voldoet aan hun eisen.

    Daarbij is de lange looptijd van projecten haast een uitnodiging om aan het begin van het traject om alle denkbare systeemfuncties te vragen. De lange wachttijd neemt het zicht op (nog) latere uitbreidingen weg. Ook raakt de verbinding tussen wens en kosten uit beeld, waardoor geen mechanisme ontstaat dat omvang en complexiteit gaat beperken.

    Doordat het watervalproject grotendeels buiten het zicht van de organisatie plaatsvindt, wordt pas aan het einde van het traject, in de testfase, de status inzichtelijk. Dan pas blijkt de software niet (geheel) te werken, blijken performanceproblemen of sluit de software niet aan bij de wensen. In die fase blijkt sowieso al veel effort nodig om kleine misverstanden aan het begin van het project recht te trekken.

    Wij hebben in de afgelopen jaren grote projecten fout zien lopen. Wij denken dat bij veel van deze projecten een agile werkwijze had kunnen helpen, omdat een project dan veel beter bij te sturen is. Maar wij weten ook dat agile geen ‘silver bullet’ is. Ook agile projecten kunnen uit de hand lopen. Wat we bijvoorbeeld zien is dat organisaties na de laatste sprint er steeds weer sprints aan vastplakken om de software ‘helemaal’ af te krijgen. Organisaties moeten ermee om leren gaan dat software nooit helemaal af is. Het is verstandig om na een (finale) release de software een tijdje te gebruiken en daarna in een beheersituatie incrementeel de software te verbeteren.

    Waarom worden gewenste resultaten niet met traditionele methoden behaald?

    Traditionele projectmanagementmethoden proberen vooraf alle gewenste functionaliteiten te documenteren met het doel risico’s te reduceren. Dit resulteert in een intensieve ontwerpfase en een nog langer ontwikkel- en testtraject zonder dat er tussentijds werkende software wordt opgeleverd. Het eindresultaat is alleen zichtbaar aan het eind van het project, wat het risico met zich meedraagt dat niet alles wordt opgeleverd of dat de eindoplossing afwijkt van de initieel gestelde eisen van de business.

    C-2014-3-Westenberg-02-klein

    Figuur 2. Vergelijking van waterval- en agile methoden. [Klik op de afbeelding voor een grotere afbeelding]

    Wat betekent agile in jullie praktijk?

    Agile in onze praktijk is tweeledig. Aan de ene kant ontwikkelen wij zelf software voor onze klanten. Dit doen wij al jaren op een agile manier. Wij hebben bij de start van onze dienstverlening op dit gebied (in 1997) eerst volgens RAD-achtige methoden gewerkt, later zijn we overgegaan op DSDM en de laatste jaren gebruiken we Scrum als raamwerk voor onze softwareontwikkelactiviteiten.

    Aan de andere kant zien we dat veel klanten afscheid nemen van de traditionele ontwikkelmethoden en agile adopteren. Wij ondersteunen onze klanten hierbij door bijvoorbeeld agile awarenesstrainingen te geven, maar ook door advisering over de inrichting van de agile werkwijze, de inrichting van de ‘ontwikkelstraat’ en het nieuwste buzzword ‘DevOps’. Door het automatiseren van ontwikkeltaken en kwaliteitsmaatregelen, en door het dagelijks daarover rapporteren in toegankelijke dashboards, worden de kwaliteit en de efficiëntie van het werk transparant. Gebruik van deze informatie kan tot aantoonbare grote efficiencywinst leiden!

    Waarom is agile zo in opkomst?

    De verwachtingen die gebruikers (consumenten, medewerkers) van de aangeboden digitale oplossing hebben, worden steeds hoger. Daarnaast bepaalt IT steeds vaker het concurrentieel of innovatief vermogen van een onderneming. De IT-oplossing moet sneller, flexibeler en beter beheersbaar zijn en zo met een korte time-to-market waarde opleveren voor gebruikers en organisatie.

    Te veel IT-projecten falen in het opleveren van voldoende waarde (business value) in de gestelde tijd of zijn zelfs niet in staat werkende software op te leveren. Door software incrementeel te ontwikkelen wordt het mogelijk vroeg en regelmatig business value op te leveren. Het opdelen van functionaliteit in kleinere delen (te realiseren in één tot vier weken) en het na iedere periode opleveren van werkende software heeft de volgende voordelen:

    • In een vroeg stadium kan het resultaat van het project worden geëvalueerd.
    • Complexiteit kan worden opgesplitst in kleinere, beter beheersbare delen.
    • Tijd en kosten staan vast; dit resulteert in tijdige opleveringen.
    • Flexibiliteit in specificaties tijdens de ontwikkeling zorgt ervoor dat het juiste product wordt ontwikkeld.
    • De focus ligt op het opleveren van business value. Functionaliteit met de meeste business value wordt als eerste ontwikkeld en opgeleverd.

    En wat is Scrum dan?

    Scrum is tegenwoordig de meest gebruikte agile methode. Scrum is een procesraamwerk dat sinds de jaren negentig wordt gebruikt om complexe productontwikkeling te managen. Scrum is geen proces of techniek voor het bouwen van producten; het is een raamwerk waarbinnen verschillende processen en technieken kunnen worden ingezet. Scrum maakt de effectiviteit van de gebruikte processen en technieken inzichtelijk zodat de werkwijze én het product steeds kunnen worden verbeterd. Er zijn uitgebreide en beknopte beschrijvingen van Scrum beschikbaar. Kijk hiervoor bijvoorbeeld op https://www.scrum.org/Scrum-Guide.

    C-2014-3-Westenberg-03-klein

    Figuur 3. Overzicht Scrum-proces. [Klik op de afbeelding voor een grotere afbeelding]

    Is het mogelijk om een pakketimplementatie agile aan te pakken?

    Het is zeker mogelijk om een pakketimplementatie agile aan te pakken. In de praktijk worden de releases die traditioneel worden gedefinieerd bij pakketimplementatie opgedeeld in iteraties. Binnen deze iteraties worden dan ontwerp, configuratie én test uitgevoerd. Dit biedt ruimte voor voortschrijdend inzicht over zowel de functionaliteit als de wijze van inrichting. Het is aan te raden om gebruik te maken van visualisatie door middel van prototyping.

    Omdat bij pakketimplementaties in de inrichting complexe afhankelijkheden kunnen voorkomen (maar wij zien dit ook wel bij architecturen waar veel koppelingen tussen systemen gemaakt moeten worden), is het verstandig een goed high-level design op te stellen. In onze praktijk zien wij dat het soms moeilijk is om te bepalen hoeveel detail nodig is in dit high-level design, maar het streven moet zijn: ‘just enough’.

    Maar is een agile project dan niet moeilijk te beheersen?

    Het is een misverstand dat agile projecten onbeheerst en chaotisch zijn, dat ontwikkelaars onbegrensde vrijheid hebben en bouwen wat ze zelf willen. Maar ook een agile project moet goed worden ingericht en daar gaat best veel werk in zitten. Er zijn veel technieken beschikbaar binnen agile methoden om dit te organiseren. Een belangrijke techniek bij Scrum is de ‘Definition of Done’: een lijst met procesmaatregelen en acceptatiecriteria waar een oplevering aan moet voldoen voordat het ‘klaar’ is. Daarnaast zijn er veel mogelijkheden voor het bijhouden van metrieken. Deze metrieken kunnen worden gebruikt in de evaluatie van een iteratie (retrospective) om de werkwijze de volgende iteratie verder te verbeteren en voorspelbaarder te maken.

    Hoe zien jullie de toekomst van agile methoden?

    Wij denken dat er een verdere professionaliseringsslag komt waarbij met name het meten van kwaliteit en de verkorting van time-to-market verbeteren door de aansluiting van ontwikkeling op beheer (en vice versa). Dit laatste wordt ook wel DevOps genoemd. Hierdoor gaan we uiteindelijk toe naar een situatie waarin ‘continuous delivery’ gemeengoed wordt. IT-organisaties zullen zich hierop moeten voorbereiden, maar ook software- en pakketleveranciers moeten dit met hun producten mogelijk gaan maken.

    Westenberg

     Ir. L.H. Westenberg CISA is senior manager bij KPMG Advisory N.V.

    westenberg.liesbeth@kpmg.nl

    KoedijkJ

     Drs. J.M.A. Koedijk CISA CISM is partner bij KPMG Advisory N.V.

    koedijk.joost@kpmg.nl

    Verified by MonsterInsights