Veranderende IT audit aanpak bij agile software-ontwikkeling
April 2015Agile Manifesto: http://www.agilemanifesto.org
“Individuals and interactions over processes and tools; Working software over comprehensive documentation;
Customer collaboration over contract negotiation; and Responding to change over following a plan.”
Afstudeer verslag, Finale versie 1.0
Student: Michel Sijben Studentnummer: 10910549
Voorwoord
Voor u ligt mijn scriptie waarin ik beschrijf hoe de aanpak van project audits verandert in een agile project omgeving met als referentie Scrum. Deze scriptie vormt de afronding van de post-doctorale opleiding Amsterdam IT Audit Programme (AITAP) aan de Amsterdam Business School.
Mijn werkzaamheden als IT auditor op het gebied van projecten en mijn interesse in de
grootschalige uitrol van Scrum software-ontwikkeling binnen mijn eigen werkgever ING Bank, zijn de componenten geweest die samen hebben geleid tot dit onderzoek.
Deze scriptie is mede mogelijk gemaakt door mijn werkgever Corporate Audit Services (CAS) ING Bank. Graag wil ik mijn collegae van CAS die mij ondersteund en uitgedaagd hebben tijdens mijn onderzoek, hartelijk bedanken. In het bijzonder wil ik Linda Post, Global Head of IT Audit ING Bank, bedanken voor haar ondersteuning, bijdrage, begrip en de vrijheid die ik gekregen heb gedurende deze drukke periode naast mijn werk.
Ik wil tevens de programma directeur van de AITAP opleiding, Lex van der Drift, bedanken voor zijn steun maar ook zijn “challenging role” gedurende mijn onderzoeksperiode.
Gedurende deze periode heb ik verder een buitengewone goede samenwerking en ondersteuning gehad van mijn scriptie begeleider vanuit de Amsterdam Business School, Han Boer. Ik wil Han dan ook bijzonder bedanken voor zijn inspanningen, ideeën en goede begeleiding met betrekking tot mijn onderzoek en scriptie.
Tot slot wil ik nog iedereen bedanken die mij ondersteund heeft gedurende deze post doctorale IT audit opleiding.
Samenvatting
De aanleiding van dit onderzoek is dat veel grootschalige IT (software ontwikkel) projecten in het algemeen bloot worden gesteld aan verschillende project-faalfactoren en daarmee mogelijk vertraging oplopen. Ondanks het feit dat er verschillende software-ontwikkelmethoden zijn die software-ontwikkeltrajecten in goede banen zouden moeten leiden, resulteren ze in de praktijk toch regelmatig in projectfalen. Als reactie op de mogelijke tekortkomingen in traditionele software ontwikkelmethoden is een verandering waarneembaar bij software-ontwikkeling binnen meerdere sectoren: het toepassen van agile software ontwikkelmethoden, zoals Scrum. Aangezien er in toenemende mate dergelijke ontwikkelmethoden worden gebruikt, is het van belang dat een IT auditor zijn instrumentarium evalueert in hoeverre deze nog past in een veranderde omgeving. Dit onderzoek is gestart met de literatuur analyse van de mogelijke project-faalfactoren bij
organisaties. Op basis van literatuur wordt geconcludeerd dat de belangrijkste drie faalfactoren voor software ontwikkel projecten als volgt kunnen worden benoemd:
Grootte en complexiteit;
Tekortkomingen in projectmanagement; en
Planningsproblemen.
Uit een analyse van de project faalfactoren in verschillende omgevingen blijkt dat de sector in principe niet bepalend is voor het op kunnen treden van de onderkende faalfactoren. Bij de overheid kunnen echter de effecten van sommige project faalfactoren worden versterkt door met name de complexiteit van de project omgeving en de diffuse politieke besluitvorming.
Op basis van zowel literatuur, eigen analyse als praktijkinterviews kan worden geconcludeerd dat Scrum, als een veel voorkomende implementatie van een agile ontwikkelmethode, bovengenoemde faalfactoren voor het belangrijkste deel ondervangt. Dit wordt bereikt door de opzet van de Agile software ontwikkelmethode (met name Scrum): nauwe interactie tussen alle betrokken partijen, transparantie en veel iteraties. Het werd echter eveneens duidelijk dat bij de toepassing van Scrum nieuwe faalfactoren ontstaan. Op basis van hetzelfde onderzoek (literatuur, eigen analyse en praktijkinterviews) blijkt dat deze nieuwe faalfactoren bestaan uit het ontbreken van effectieve project management meetmethoden voor Scrum, de complexiteit in aansturing/governance van grote Scrum projecten en het ontbreken van methodische/inhoudelijke structuur (minimale IT vereisten ten aanzien van beheersingsfunctionaliteit).
Een IT auditor moet meegaan met de verandering om toegevoegde waarde te kunnen blijven leveren aan zijn opdrachtgevers. Ook in een Scrum projectomgeving moet hij/zij in staat zijn om effectief te oordelen en ter zake doende adviezen uit te brengen. Dit onderzoek heeft geresulteerd in een handreiking in de vorm van een controleraamwerk voor een Scrum omgeving. Het
voorgestelde raamwerk is als volgt opgebouwd:
1. AGIT: de belangrijkste aspecten voor beheersing en performance management van Scrum software ontwikkelmethoden;
2. Governance: de in de theorie en de praktijk gevonden nieuwe faalfactoren voor Scrum software ontwikkelmethoden; en
3. IT Foundation: de technische controles/randvoorwaarden die mogelijk over het hoofd worden gezien, maar cruciaal zijn voor implementatie en onderhoud van het systeem.
De toepassing van het raamwerk leidt er niet toe dat het werk van de IT auditor intrinsiek zal veranderen. De beheersingsdoelstellingen die de basis vormen voor zijn/haar oordeelsvorming en advisering, worden wel anders. Door het voorgestelde raamwerk te gebruiken krijgt de IT auditor concrete handvatten om een Scrum omgeving te analyseren en te beoordelen, rekening houdend met inherente zwakheden van de Scrum software ontwikkelmethoden.
Inhoudsopgave
Hoofdstuk 1. Inleiding & onderzoek ... 7
1.1 Aanleiding ... 7 1.2 Probleemstelling en onderzoeksvragen ... 7 1.3 Methode ... 8 1.4 Opbouw verslag ... 8 Hoofdstuk 2. Software-ontwikkeling ... 9 2.1 Inleiding ... 9 2.2 Achtergrond ... 9 2.3 Software ontwikkelmethoden ... 9 2.3.1 Traditionele software-ontwikkeling ... 9 2.3.2 Agile software-ontwikkeling ... 11
2.4 Verschillen tussen traditionele- en agile software ontwikkelmethoden... 12
2.5 Trends in het gebruik van software ontwikkelmethoden ... 13
2.6 Samenvatting ... 14
Hoofdstuk 3. Het succes of falen van IT projecten ... 15
3.1 Inleiding ... 15
3.2 Falende ICT Projecten ... 15
3.2.1 Wat is een project? ... 15
3.3 IT project faalfactoren ... 16
3.4 Succes factoren bij software ontwikkel projecten ... 17
3.5 Project faalfactoren vs succes factoren ... 18
3.6 Agile software ontwikkelmethoden en project faalfactoren ... 19
3.6.1 Theoretisch onderzoek ... 19
3.6.2 Agile in de praktijk ... 20
3.6.2.1 Inleiding ... 20
3.6.2.2 Vragenlijst ... 22
3.6.2.3 Resultaten interviews ... 22
3.6.2.4 Samenvattende conclusies van interviews ... 28
3.7 Samenvatting ... 30
Hoofdstuk 4. Analyse verandering in audit aanpak bij agile software ontwikkeling ... 31
4.1 Inleiding ... 31
4.2 COBIT ... 31
4.3 AGIT Model ... 32
4.4 AGIT + ... 35
Hoofdstuk 5. Controle Raamwerk AGIT+ ... 37
5.1 Inleiding ... 37
5.2 Bouwstenen ... 37
5.3 AGIT+ Controle raamwerk ... 38
5.3.1 “In scope” analyse ... 38
5.3.2 “Out of Scope” analyse ... 39
5.4 Analyse toegevoegde waarde controleraamwerk ... 39
5.4.1 Profiel voorwaarden ... 40
5.4.2 Chief Information Officer ... 40
5.4.3 Conclusie ... 41
5.5 Samenvatting ... 41
Hoofdstuk 6. Conclusies en aanbevelingen ... 42
6.1 Inleiding ... 42
6.2 Conclusies ... 42
6.3 Aanbevelingen ... 45
6.4 Andere onderwerpen voor een mogelijk vervolgonderzoek ... 45
Literatuurlijst ... 47
Bijlage I: Visualisatie van software ontwikkel problematiek ... 49
Bijlage II: Twaalf Principes achter het Agile Manifesto ... 50
Bijlage III: Succes factoren gedefinieerd in McCleod & MacDonell model ... 51
Bijlage IV: Samenvattende gespreksverslagen ... 54
Hoofdstuk 1. Inleiding & onderzoek 1.1 Aanleiding
Uit onder andere recent parlementair onderzoek van de Commissie Elias (Elias, 2014), wordt duidelijk dat veel grootschalige IT projecten bloot staan aan projectrisico’s die uitmonden in (1) het niet (tijdig) halen en/of niet binnen budget blijven van project doelstellingen (Elias, 2014) en/of (2) het niet voldoen aan de verwachte project specificaties.
Deze project risico’s gelden niet alleen voor IT projecten binnen overheid, maar lijken ook van toepassing te zijn bij andere sectoren. Ondanks dat IT projecten (inclusief software-ontwikkeling) worden uitbesteed aan gerenommeerde marktpartijen met een volwassen procesbenadering en een professionele projectaanpak, worden project doelstellingen ook in andere sectoren dikwijls niet of maar deels behaald (Schönfeld, 2012). Dit geldt ook voor de financiële sector, waar ik zelf sinds 2006 werkzaam in ben. In bijlage I wordt een korte, ludieke visualisatie gegeven van het generieke
probleem bij software-ontwikkeling.
Vragen die zich hierbij aandienen zijn “Waardoor gaan zoveel projecten mis?” of “Wat zijn nou faalfactoren?” of “Zijn de bijkomende problemen sector afhankelijk of generiek van toepassing”? Door de jaren heen worden als reactie op de falende software-ontwikkeling, de methoden verfijnd of wordt een nieuwe weg in geslagen. Bij de trend van het toepassen van ‘moderne’ (agile) software ontwikkelmethoden zoals Scrum, ontstaat de vraag of deze methoden meer weerstand bieden tegen belangrijke IT project faalfactoren en/of er geen nieuwe faalfactoren ontstaan.
Aangezien van de IT auditor wordt verwacht een objectief beeld te kunnen geven over de
effectiviteit van een project omgeving, ligt het voor de hand dat de IT auditor mee beweegt in deze veranderende omgeving. Welke methoden en/of instrumenten zijn nodig voor de IT auditor om een grondige analyse te kunnen geven en bij te kunnen dragen aan het terugdringen van de invloed van project faalfactoren in een agile omgeving?
1.2 Probleemstelling en onderzoeksvragen
Bovenstaande probleemstellingen kunnen worden samengevat in de volgende hoofd-onderzoeksvraag:
Hoofdonderzoeksvraag:
Hoe ondervangen de opkomende software ontwikkelmethoden (zoals bijvoorbeeld Scrum) de effecten van onderkende project faalfactoren en hoe kan de IT auditor hierbij ondersteunen?
De bovenstaande hoofdonderzoeksvraag kan worden opgesplitst in de volgende sub onderzoeksvragen:
1. Wat is het onderscheid tussen de traditionele software ontwikkelmethoden en de nieuwe op agile gebaseerde software ontwikkelmethoden zoals Scrum?
2. Wat zijn de voornaamste IT project faalfactoren bij software-ontwikkeling? 3. In hoeverre zijn IT project risico’s en/of faalfactoren sector afhankelijk?
4. Hoe ondervangen agile software-ontwikkelingsmethoden (waaronder Scrum) de belangrijkste IT project faalfactoren en /of ontstaan nieuwe faalfactoren?
5. Wat verandert er in de aanpak en/of instrumentarium van de IT auditor bij toepassing van agile (waaronder Scrum) project methoden om de faalkans te mitigeren?
6. Zullen de projectverantwoordelijken (programma managers en projectleiders) alsook projectopdrachtgevers de veranderende aanpak en/of instrumentarium van de IT auditor, om reden van faalkansvermindering, van toegevoegde waarde vinden?
1.3 Methode
De onderzoeksvragen 1 en 2 worden met name via literatuur onderzoek beantwoord. Onderzoeksvragen 3 en 4 worden op basis van literatuur onderzoek en/of interviews verder uitgediept. De uitwerking van onderzoeksvraag 5 en 6 is gebaseerd op interviews en een validatie van de veranderende aanpak van IT auditors bij project opdrachtgevers. Hierbij wordt het resultaat van de literatuurstudie voorgelegd aan in de praktijk werkzame professionals.
1.4 Opbouw verslag
Het eerste hoofdstuk beschrijft de aanleiding, probleemstelling en onderzoeksvragen. Hoofdstuk 2 beschrijft hoe klassieke (waterval)methoden en de nieuwe op agile gebaseerde software
ontwikkelmethoden van elkaar verschillen. Hoofdstuk 3 beschrijft de voornaamste IT project faalfactoren, inclusief een samenvattend verslag van de bijbehorende interviews. Hoofdstuk 4 geeft een analyse welke modellen toegepast kunnen worden bij de veranderende aanpak van de IT auditor bij toepassing van de agile methoden, in dit geval Scrum. Hoofdstuk 5 beschrijft de uitkomst van de analyse in de vorm een controleraamwerk ten aanzien agile software ontwikkelmethoden zoals Scrum en daarnaast hoe belanghebbenden de bijdrage van een IT auditor toelaten, ervaren en waarderen bij het verminderen van IT faalfactoren voor (‘moderne’) software-ontwikkeling. De antwoorden op de onderzoeksvragen en de conclusie ten aanzien van de probleemstelling worden, samen met aanbevelingen en discussie, opgenomen in hoofdstuk 6.
Hoofdstuk 2. Software-ontwikkeling 2.1 Inleiding
Het doel van dit hoofdstuk is om de achtergronden te schetsen van verschillende software ontwikkelmethoden, waarom welke methoden door wie worden gebruikt en de laatste trends binnen software ontwikkelmethoden.
2.2 Achtergrond
De opkomst van een nieuw Informatie Technologie (IT) tijdperk gebaseerd op mobiele-, sociale-, cloud-, en big data/analyse platformen heeft impact op bedrijfsmodellen en de gelieerde processen. Door deze ontwikkeling worden er continu nieuwe toepassingen ontwikkeld. Verwacht wordt dat de IT-sector aan de vooravond staat van wederom een enorme groeigolf (Rabobank, 2014). Het
bijhouden van zulke nieuwe trends leidt tot nieuwe uitdagingen op het gebied van software-ontwikkeling. Software ontwikkelaars moeten oude legacy systemen zien te transformeren en afstemmen op sterk veranderende business requirements. Deze omgeving van software-ontwikkeling vereist flexibiliteit, snelheid en wendbaarheid (agility) om aan de vraag te kunnen voldoen (Cohen, 2004). De vraag is of traditionele software ontwikkelmethoden daar nog in voldoende mate in kunnen voorzien.
2.3 Software ontwikkelmethoden
Sinds het begin van software-ontwikkeling, ontstaan in 1968 (Northover, 2008), gebruiken professionals verschillende methoden en technieken om software te ontwikkelen. Een software ontwikkelmethode refereert naar een framework dat wordt gebruikt om te plannen, managen en beheersen van het ontwikkelproces van een informatie systeem (Sommerville, 2010). Software-ontwikkeling staat ook bekend als Software Development Life Cycle (SDLC). Doel van deze SDLC’s is om een software product efficiënt te kunnen ontwikkelen en tevens een hoog kwalitatief software product af te leveren (Cohen, 2004). Bekende SLDC’s die als relatief succesvol zijn te benoemen zijn bijvoorbeeld: Waterval methode, spiraal methode, Rational Application Development (RAD), agile software development en rapid prototyping. Elk model kent haar eigen sterktes en zwaktes (Bassil, 2012). De waterval methode is een van de eerste SDLC’s en is daarnaast een van de meest
toegepaste methoden. Hierdoor zijn vele methoden gebaseerd op de waterval methode (Larman, 2003). Sinds “de markt” nieuwe eisen stelt aan flexibiliteit en snelheid in software-ontwikkeling, zoals ook besproken in de inleidende paragraaf (1.1), is de agile software-ontwikkeling in opkomst (Misra, 2012).
In dit hoofdstuk wordt gefocust op methoden van software-ontwikkeling en wordt onderscheid gemaakt tussen de twee belangrijkste categorieën van software-ontwikkeling: “traditioneel” en “agile methoden”.
In de volgende paragraaf wordt kort stil gestaan bij de verschillen tussen beide genoemde methoden. Het doel hiervan is een vergelijkende studie tussen deze twee methoden.
2.3.1 Traditionele software-ontwikkeling
Als eerste wordt stil gestaan bij software ontwikkelmethoden die bekend staan als traditionele / klassieke ontwikkeling. Voorbeelden van traditionele software ontwikkelmethoden zijn de spiraal methode, V-model en waterval methode. De traditionele methoden zijn in principe gebaseerd op de
klassieke watervalmethode (Fransson, 2005; Larman 2003). De waterval methode wordt hieronder meer in detail uitgewerkt en kan als volgt worden gevisualiseerd in figuur 2.1:
Figuur 2.1: Waterval methode
De waterval methode onderkent de volgende 5 meest genoemde fasen (Bassil, 2012):
1. Analysefase (o.a. definitiestudies en analyserapporten): deze fase resulteert in een volledige en overkoepelende beschrijving van hoe de software zich zou moeten gedragen.
2. Ontwerpfase (o.a. functionele en technische ontwerpen): dit is de fase van planning en het oplossen van problemen en het daarmee daadwerkelijk ontwerpen van een software product.
3. Implementatiefase (o.a. geprogrammeerde software taal): dit is de fase waar de echte software code is geschreven en gecompileerd naar een applicatie, database file en ondersteunende software. Dit is de fase waar de productie omgeving daadwerkelijk gecreëerd wordt.
4. Testfase (o.a. testen op fouten van geprogrammeerde software taal): Hierin wordt getest of de software voldoet aan de initieel opgestelde eisen en verwachtingen. Daarnaast wordt deze fase gebruikt om gemaakte fouten in het ontwerp eruit te halen en te verbeteren. 5. Integratiefase en beheer fase (o.a. ingebruikname door gebruikers en onderhoud): dit is de
fase van het in gebruik nemen van de software. Deze onderhoudsfase houdt ook in dat er nieuwe wijzigingen kunnen worden doorgevoerd via een (regulier) change management proces. Dit heeft als doel verdere fouten te verbeteren en/of nieuwe requirements te implementeren in het ontwerp.
De software-ontwikkeling verloopt via een “waterval”, waarbij het ene proces het andere opvolgt. Deze opvolging van processen vindt in principe pas plaats als de voorgaande fase is afgerond. De traditionele software ontwikkelmethoden streven naar heldere specificaties (requirements) en een volledig projectplan aan het begin van het project waar in principe niet van wordt afgeweken gedurende het project (Bassil, 2012). Software-ontwikkeling volgens de waterval methode gaat ervan uit, dat de tijd die aan de eerste fasen wordt gespendeerd tot een betere efficiency leidt verder in het proces. Immers een ontwerpfout leidt tot een niet werkend product waardoor tijd moet worden besteed aan herstelwerkzaamheden (Bassil, 2012).
Traditionele software-ontwikkeling benadrukt tevens het belang van documentatie, zoals requirements, ontwerp documentatie, handleidingen en source code. De reden hiervoor is dat teamleden gedurende het project het team kunnen verlaten met het gevaar dat kennis verloren gaat. Verder levert de traditionele ontwikkeling een gestructureerde aanpak van
software-ontwikkeling, het model is lineair gericht, de fasering is eenvoudig te begrijpen en geeft duidelijke mijlpaalproducten (Bassil, 2012).
De traditionele ontwikkelmethode is een solide, goed begrepen model dat hoort bij een stabiel, herhaalbaar project. De software-eisen zijn stabiel en gefixeerd. Het ontwikkeltraject is precies te voorspellen. Problemen ontstaan indien er veranderingen optreden in de requirements gedurende het project. Het fundament van een traditionele ontwikkelmethode zijn namelijk de requirements waarop trapsgewijs wordt gebouwd (Bassil, 2012). Er is weinig tot geen speelruimte voor
veranderingen in de uitgangspunten. Elke fase wordt immers afgesloten met een "contract" voor de volgende fase. Indien de eisen veranderen moeten er dus stappen “teruggezet” worden wat een tijdrovende zaak is. Een ander probleem met de watervalmethode is dat het opstellen van het functionele ontwerp en het technisch ontwerp een zodanig groot deel van de looptijd van het project in beslag nemen dat de gehele looptijd om tot een werkende applicatie te komen lang kan zijn, waardoor de kans groot is dat requirements achterhaald zijn (Bassil, 2012; Osorio, 2011).
2.3.2 Agile software-ontwikkeling
Takeuchi en Nonaka (1986) kunnen worden gezien als de grondleggers van Scrum. Zij beschreven een product ontwikkelraamwerk dat vergeleken wordt met de manier waarop een rugbyteam als groep de achterlijn van de tegenstander probeert te bereiken. Samenwerking,
aanpassingsvermogen, snelheid en zelfsturing zijn kenmerken van multidisciplinaire teams die overeenkomen met zo’n rugbyteam. Scrum is gebaseerd op best practices vanuit de Japanse industrie, waaronder de Lean Management-principes. In 1995 is Scrum verder geformaliseerd (Takeuchi & Nonaka, 1986).
Agile software-ontwikkeling staat internationaal ook wel bekend als Agile Software Development (ASD). ASD is een verzameling van software ontwikkelmethoden die zijn ontstaan uit ontevredenheid over de resultaten van sommige traditionele software ontwikkelmethoden onder bepaalde
omstandigheden. Voorbeelden van agile methoden zijn: Crystal Clear, Extreme Programming, Lean Software development en Scrum. Scrum en XP zijn hiervan de meest toegepaste methoden (Mahnic & Zabkar, 2008). Ook hier geldt dat de ene methodologie verschillende sterktes en zwaktes kent. Tevens is er sprake van verschillende focus gebieden op verschillende fasen/aspecten van de Software Development Life Cycle (SDLC) (Misra, et al 2012).
De basis van de agile methode is iteratief software-ontwikkeling (Larman, 2005). Volgens Larman is iteratieve software-ontwikkeling een ontwikkeling die al voor 1960 zijn oorsprong kent. Om een beeld van de ontwikkeling te geven wordt ingegaan op het iteratief ontwikkelen van software zoals deze is voortgekomen uit de traditionele aanpak.
Iteratieve software-ontwikkeling is een methode om software te bouwen. De levenscyclus van software bestaat uit een aaneenschakeling van iteraties, waarbij elke iteratie een miniproject is waarin met betrekking tot een afgebakende functionaliteit een groot aantal fasen uit de levenscyclus van software wordt doorlopen, zoals requirements analyse, ontwerp, ontwikkeling en testen. De doelstelling van één iteratie is dat de afgebakende functionaliteit compleet en fout vrij wordt opgeleverd en beschikbaar is voor de eindgebruiker. Elke iteratie beoogd een hoge mate van kwaliteit code op te leveren en elke iteratie is niet een prototype maar een onderdeel van het te ontwikkelen systeem (Misra, 2012).
Een iteratie kan ook als doel hebben om functionaliteit te verwijderen of performance te verbeteren.
Het begrip agile software-ontwikkeling is geformaliseerd in 2001 door 17 vooraanstaande ontwikkelaars die de toen bestaande ‘afgeslankte’ methodieken gecombineerd hebben tot een ‘agile’ methodiek (Misra, 2012). De term ‘agile’ betekent onder meer ‘alert’, ‘levendig’ en
‘behendig’. Dit verwijst naar de snelle, flexibele wijze waarop ingespeeld wordt op veranderingen tijdens het ontwikkelproces. De groep heeft een Agile Manifesto opgesteld voor agile ontwikkeling. Het manifesto heeft 12 principes beschreven om helder te maken waar agile software-ontwikkeling aan voldoet (Williams, L., 2012), zie ook bijlage II.
Een agile aanpak hanteert een regelmatige oplevering van software om in te kunnen spelen op de veranderende requirements. Agile gebruikt timeboxen waarbij elke iteratie een gelijke duur heeft. Daarnaast is bij agile de opdrachtgever permanent vertegenwoordigd in het project.
2.4 Verschillen tussen traditionele- en agile software ontwikkelmethoden
Zoals hierboven beschreven kan onderscheid worden gemaakt tussen twee grote stromingen binnen de software-ontwikkeling: 1. traditionele software-ontwikkeling en 2. agile software-ontwikkeling. Traditionele benaderingen vertrouwen op een lineaire of incrementele levenscyclus. Deze methoden zijn plan gedreven en worden gekenmerkt door een ontwerp en “plan van aanpak” (Boehm & Turner, 2004). In dit soort projecten, worden de eisen duidelijk gespecificeerd en wordt weinig verandering verwacht. Hiermee is het relatief voorspelbaar. Waarmee gepoogd kan worden het project zo optimaal mogelijk te plannen. Deze benaderingen zijn meestal echter minder flexibel en richten zich op de naleving van het plan als een maatstaf voor succes. Derhalve zijn zij enigszins beschrijvend van karakter en relatief zwaar op het proces en documentatie. Projectmanagers blijven echter deze traditionele methoden toe passen op projecten waarvoor zij niet altijd geschikt zijn (Cohen, 2004).
Aan de andere kant van het spectrum zijn agile werkwijzen ontwikkeld om te reageren op de dynamische aspecten en mogelijke tekortkomingen van de traditionele methoden. Organisaties hebben korte levertijd cycli om te kunnen omgaan met onzekerheid en snelle veranderingen in de klantwensen. Agile benaderingen zijn gebaseerd op een iteratieve levenscyclus en zijn ontworpen om verandering te accepteren en omarmen. Ze zijn waarde-gedreven in plaats van plan gedreven en gebruik de kennis die aanwezig is tussen teamleden in plaats van zware documentatie. In de agile methoden is er geen grote, vooraf bepaalde, eenmalige planning. Deze is vervangen door een iteratieve en adaptieve reeks van just-in-time taken die elk alleen wordt uitgevoerd wanneer dat nodig is en wanneer daarvoor gevraagd wordt door de “klant” samen met het team. Dit zorgt voor flexibiliteit en aanpasbaarheid aan het project en empowerment van het projectteam om
gemakkelijker om te gaan met veranderverzoeken. De methode is gericht op meer intermenselijke communicatie, zowel binnen het team als met de klanten. Een nadeel is echter dat deze methode moeilijker is bij grote complexe projecten.
Onderzoeksvraag 1:
Wat is het onderscheid tussen de traditionele software ontwikkelmethoden en de nieuwe op agile gebaseerde software ontwikkelmethoden zoals Scrum?
Op basis van bovenstaande beschrijvingen en literatuur kunnen de verschillen worden gedestilleerd tussen de karakteristieken van traditionele- en agile software ontwikkelmethoden (Jiang, 2008, Cohen, 2004, Aslam, 2011, Boehm & Turner, 2004):
Tabel 2.1: Verschillenanalyse Traditionele en Agile software ontwikkelmethode
Karakteristieken Traditionele methode Agile methode
Oorsprong Gebaseerd op Systems development life cycle (jaren ’60): gestructureerde benadering, plangericht
Komt voort uit rapid prototyping, zonder complete vooraf opgestelde definities, flexibel, iteratief ontwikkelmethode (jaren 90) met multidisciplinair ontwikkel team, mensgericht.
Primaire doel Hoge kwaliteit/ product werkzaam volgens specificaties
Snel toegevoegde waarde
Specificaties Vroeg in project bekend,
gedocumenteerd en stabiel tijdens project
Spontaan (emergent), snel wijzigend, niet volledig vooraf
uitgewerkt/gedocumenteerd Grootte Grotere teams, projecten en
programma’s
Kleiner team, project
Architectuur Ontworpen voor huidige en toekomstige specificaties
Ontworpen voor huidige specificaties
Planning & Control Gedocumenteerd/specifiek plan, kwantitatieve controle
Gestandaardiseerd aanpak, lijst met requirements, kwalitatieve controle Klanten Klant is nodig voor contract Toegewijde klanten, met veel kennis,
meewerkend in team, on-site Ontwikkelaars Plan georiënteerd, precieze skills naar
(externe) kennis
Flexibel, veel kennis, toegewijd, meewerkend
Kosten verandering Kostbaar Niet kostbaar Risico’s Bekend/begrepen risico, verminderde
impact.
Onbekende risico’s, grote impact
2.5 Trends in het gebruik van software ontwikkelmethoden
Uit de literatuur blijkt dat agile software ontwikkelmethoden in toenemende mate worden toegepast (Sutherland et al, 2011). Hierdoor is het mede voor IT auditors van belang om deze ontwikkelingen te volgen. Door de snelle opmars van agile ontwikkelmethoden nemen ook de misverstanden over agile toe en daarmee bestaat het risico dat de daadwerkelijke filosofie en beoogde doelen van de agile ontwikkelmethode onduidelijk zijn en de methode niet echt begrepen
wordt. Aangezien de agile ontwikkelmethoden nog niet heel lang worden gebruikt komt pas nu de vraag naar onderzoek over de kwaliteit en naar de valkuilen. Hetgeen voor dit onderzoek betekent dat slechts uit een beperkt arsenaal van publicaties kan worden geput.
Eind 2008 is bekend geworden dat de Nederlandse overheid heeft besloten om agile
ontwikkelmethoden toe te passen bij de IT projecten (Algemene Rekenkamer, 2008). Dit is nogmaals bekrachtigd door Commissie Elias in 2014 (Elias, 2014). Het besluit betekent dat alle grote IT
projecten van de overheid per projectfase worden beoordeeld op het resultaat van de afgeronde fase en op de gereedheid van de volgende fase. De overheid kan door het gebruik van iteraties sneller zien of het beoogde resultaat bereikt wordt (Algemene Rekenkamer, 2008).
Zoals al eerder beschreven zijn er verschillende varianten van agile methoden met ieder hun eigen specifieke eigenschappen. Scrum en Extreme Programming (XP) zijn de meest populaire vormen van agile software-ontwikkeling (Mahnic & Zabkar, 2008). XP focust zich als methode meer op de software-ontwikkeling. Scrum focust zich op zowel het (project) management gedeelte als op de uitvoering/inhoudelijkheid van software-ontwikkeling (Cohen, 2004).
Dit onderzoek is erop gericht om een bijdrage te kunnen leveren, als IT auditor, aan het succesvol afronden van software ontwikkel projecten. Projecten hebben zowel management als
uitvoeringsaspecten in zich. De verdere focus van het onderzoek ligt dan ook op Scrum.
2.6 Samenvatting
Dit onderzoek richt zich op software ontwikkeling. Om inzicht te geven in de verschillende methodes, werd in dit hoofdstuk de verschillende software ontwikkel methoden beschreven, de belangrijkste verschillen tussen de meest toegepaste methoden en de ontwikkelingen daarbinnen. In het volgende hoofdstuk zal worden stilgestaan, bij de mogelijke faalfactoren voor (software
Hoofdstuk 3. Het succes of falen van IT projecten 3.1 Inleiding
In dit hoofdstuk wordt een theoretisch onderzoek beschreven naar de mogelijke faal- en succesfactoren voor software ontwikkel projecten. Tevens wordt onderzocht in hoeverre IT
faalfactoren sector afhankelijk zijn. Het hoofdstuk sluit af met een praktijk onderzoek waar in wordt onderzocht in hoeverre agile software ontwikkelmethoden, in dit geval de Scrum methode, de bekende faalfactoren kan beheersen en/of er nieuwe faalfactoren ontstaan.
3.2 Falende ICT Projecten
In hoofdstuk 2 worden de verschillen tussen de voornaamste software ontwikkelmethoden beschreven. Naast deze software ontwikkelmethoden, die zouden kunnen bijdragen aan het succesvol afronden van projecten, zijn er proces- en project methodieken welke bijdragen aan het efficiënter en effectiever opleveren van projecten. Dit is bijvoorbeeld project management methodiek zoals Prince 2 en proces volwassenheidsmodel CMMI. Deze methoden (Prince 2 en CMMI) zijn niet specifiek voor software-ontwikkeling ontwikkeld, maar indien ze toegepast worden voor software-ontwikkeling zijn ze van origine meer gebaseerd op de traditionele software ontwikkel modellen, waarbij een duidelijke vooraf opgestelde structuur wordt gekozen en op voorhand wordt vastgelegd wat, wanneer en hoe opgeleverd moet worden (Fijneman, 2006). Ondanks de toepassing van verschillende project, proces en software ontwikkelmethoden, zijn eindgebruikers/
opdrachtgevers in veel gevallen niet tevreden met de resultaten met het software product of gaat het over het budget of wordt het te laat opgeleverd.
Onlangs presenteerde de Commissie Elias (Elias, 2014) haar eind rapport “Parlementair onderzoek naar ICT-projecten bij de overheid”. Hierin wordt gesteld dat bij de overheid 1 a 5 miljard euro per jaar wordt verspild aan ICT mislukkingen (daarbij zijn de totale uitgaven niet genoemd). Dezelfde commissie concludeert dat bij de overheid slechts 7% van de grote ICT-projecten (van meer dan 10 miljoen dollar) succesvol wordt afgerond; de overige 93% slaagt niet (direct). Hiervan “faalt” namelijk 36 procentpunt en is 57 procentpunt “betwist”. Met “betwist” wordt hier bedoeld dat die projecten niet binnen de afgesproken tijd en/of kosten zijn gerealiseerd. “Falen” betekent hier dat het systeem dat werd ontwikkeld nooit in gebruik is genomen (Elias, 2014). Er kan worden gesteld dat 16% van alle ICT projecten succesvol wordt afgerond (binnen budget en verwachte
functionaliteiten), 52,7% wordt gechallenged (afgerond en geïmplementeerd maar wel met budget over runs, omissies /fouten in functionaliteit) en 31% wordt geannuleerd (Yeo, 2002).
3.2.1 Wat is een project?
Het woord project wordt in de hedendaagse bedrijfsvoering veel gebruikt. De meeste definities zijn opgebouwd uit de componenten “tijdelijke organisatie”, “begrensd in tijd, geld en resources”, “een unieke gespecificeerde scope en kwalitatieve en kwantitatieve maatstaven” (Cicmil, 1997). Een project is dus een tijdelijke organisatie met als doel het opleveren van een uniek product of dienst volgens aangeleverde specificaties, met begrensde tijd, geld en resources en beoordeeld op kwantitatieve en kwalitatieve eigenschappen. Met name in de bouw wordt al lang gebruik gemaakt van projecten. Indien sprake is van een ICT-project, is een project dat tot doel heeft een ICT-Systeem te ontwikkelen en / of in te voeren. Onder ontwikkelen wordt verstaan de specificatie, aanschaf en (zelf) bouw of verbouw van het systeem (Cicmil, 1997).
3.3 IT project faalfactoren
Zoals beschreven in de achtergrond van dit hoofdstuk worden IT projecten vaak niet succesvol afgerond. In deze paragraaf wordt stilgestaan bij welke factoren van invloed zijn op het falen van IT projecten.
Er wordt allereerst een overzicht gegeven van IT project faalfactoren in algemene zin (niet
toegespitst op software-ontwikkeling), aangezien de literatuur weinig beschrijft over IT faalfactoren gelinkt aan software-ontwikkeling. Dit geeft echter ook een overkoepelend beeld wat er van belang is bij generieke IT projecten. Daarna wordt nog een verdere verdieping gegeven naar faalfactoren over software-ontwikkelingsprojecten.
Op basis van verschillende literatuur onderzoeken naar generieke IT project faalfactoren, kan een top 8 worden gegeven van belangrijkste faalfactoren (Martijnse, 2007; Cicmil, 1997; Ives, 2005). Aangezien dit een clustering is van resultaten uit verschillende onderzoeken is gekozen voor deze top 8, als weergegeven in tabel 3.1
Tabel 3.1: IT project faalfactoren algemeen
# Generiek Project Faal Factor Toelichting/specificatie
1 Grootte en complexiteit project Projecten zijn te groot en te complex
2 Projectmanagement Gebrekkig projectmanagement, Slechte administratie, Negeren van wijzigende eisen, Slechte monitoring en sturing tijdens het project, Onvoldoende
gebruikersinbreng
3 Planning Te krappe en onrealistische planningen, slecht bewaken van planning, project leden niet betrokken in
planningsfase.
4 Technologie Onderschatten technische complexiteit en technische integratie issues, Onbekendheid met nieuwe technologie en onvoorziene problemen hiermee.
5 Communicatie Gebrek aan communicatie in en rond het project
6 Opdrachtgever Doelstellingen niet (duidelijk) gedefinieerd, Geen ondersteuning van opdrachtgever, Onrealistische verwachtingen in tijd en oplossing (ICT wordt gezien als ‘Quick fix’), Onvolledige en wijzigende specificaties, Onvoorziene inflatie van de projectwaarde, het project heeft geen toegevoegde waarde meer.
7 Extern Wijzigende wet en regelgeving
8 Resourcing Projectleden niet fulltime op hetzelfde project, Resourcing problemen en slechte leveranciersrelatie
Concluderend zijn er verschillende factoren die kunnen leiden tot projectfalen. Tabel 3.1 geeft een goed overzicht van project faalfactoren. Projecten zijn complexe systemen die worden gepland op basis van onderling afhankelijke aannames. Indien in de loop van het project aannames niet kloppen of onvoorziene problemen ontstaan, kan dit het complexe geheel van afhankelijkheden uit balans
brengen. Project falen ontstaat in de meeste gevallen door de samenloop van factoren die zich in de loop van de tijd voordoen.
Aangezien de wetenschappelijke literatuur relatief beperkt is toegespitst op projectfalen bij software-ontwikkeling, is het literatuur onderzoek in de volgende paragraaf uitgebreid naar succes factoren bij software ontwikkel projecten. Hier is in de literatuur meer over beschreven.
3.4 Succes factoren bij software ontwikkel projecten
Om zo volledig mogelijk naar de probleemstelling te kijken worden naast de faalfactoren de succes factoren met betrekking tot software-ontwikkeling in het onderzoek betrokken. De succes- en faalfactoren zijn met elkaar geconfronteerd om vast te stellen of deze (aan beide zijden) niet conflicterend zijn, maar mogelijk aanvullend zijn (redenerend dat een omgekeerde succesfactor een faalfactor is).
Net als bij generiek IT project faalfactoren, zijn er ook verschillende onderzoeken beschikbaar die ingaan op de succesfactoren voor IT software ontwikkel projecten. Veel literatuur onderzoeken geven een top 7 of top 10 van succesfactoren (Arias, 2012; Sheffield , 2012).
In dit onderzoek wordt om twee redenen gekozen voor het model van McCleod & MacDonell (2011): 1. Het betreft een geaggregeerd onderzoek dat bestaat uit een analyse van 4 andere grote
onderzoeken: Lyytinen & Hirschheim (1987), Poulymenakou &Holmes (1996), Butler & Fitzgerald (2001), Scott & Vessey (2002);
2. Het geeft een heldere en simpele categorisering van succesfactoren die tevens aansluiten bij de verder te onderzoeken software ontwikkelmethode Scrum.
De categorieën van succes factoren zijn als volgt geaggregeerd: 1. Mensgericht
2. Ontwikkel proces 3. Project
4. Context van de organisatie en/of project
Figuur 3.1: Framework van factoren die software ontwikkel projecten beïnvloeden
De categorieën hebben tevens een belangrijke overlap met de drie belangrijkste facetten binnen de agile software ontwikkelmethode Scrum (zie ook hoofdstuk 2):
1. Software-ontwikkeling: inhoud van de software-ontwikkeling;
2. Project: bij agile methode Scrum staat naast inhoud ook de project ontwikkeling zelf centraal;
3. Mens: de mens factor is de bepalende factor bij Scrum (e.g. communicatie) aangezien er weinig vereisten zijn rondom documentatie/akkoorden etc. Het komt aan op juiste communicatie.
In bijlage III wordt bovenstaande model verder in detail uitgewerkt en een diepere verdeling gegeven van succes factoren bij software-ontwikkeling.
3.5 Project faalfactoren vs succes factoren
In dit onderzoek is geanalyseerd of de faalfactoren zoals gedefinieerd in tabel 3.1 (omgekeerd) te matchen zijn met de succes factoren zoals staat weergegeven in figuur 3.1 (en bijlage III). Op basis van die analyse kan ook worden geconcludeerd dat de faalfactoren die in het algemeen de
reciproque zijn van factoren die gelden aansluiten op de succes factoren voor software-ontwikkeling. In het onderstaande schema staan de succes en faalfactoren gematched weergegeven:
Tabel 3.2: Matchen van IT project faalfactoren met succes factoren Software-ontwikkeling: # Generieke IT Project Faal Factor Referentie naar Software Ontwikkel
succes factor (zie ook bijlage III): 1 Grootte en complexiteit project P1.1.a: project complexity 2 Projectmanagement SO2.2.b: Project management
3 Planning SO.2.a: Project planning
4 Technologie P.4.: Technology
5 Communicatie M3.6.a.: Communication
6 Opdrachtgever M.3. Top Management
7 Extern O4.1,2: Environment
8 Resourcing P.3. Resourcing
Onderzoeksvraag 2 :
Wat zijn de voornaamste IT project faalfactoren bij software-ontwikkeling?
Concluderend kan worden gesteld, dat op basis van bovenstaande matching de generieke faalfactoren, die beschreven zijn voor IT projecten, aansluiten met faalfactoren, die van invloed kunnen zijn op software ontwikkel projecten.
Nu het vanuit de theorie helder is wat bekende IT project faalfactoren zijn bij software-ontwikkeling is de volgende stap het vanuit de theorie en praktijk onderzoeken in hoeverre de project
faalfactoren ook van toepassing zijn voor agile software ontwikkelmethoden, zoals Scrum software-ontwikkeling. Dit wordt in de volgende paragraaf beschreven.
1 P: Project 2 SO: Software-ontwikkeling 3 M: Mens 4 O: Omgeving
3.6 Agile software ontwikkelmethoden en project faalfactoren 3.6.1 Theoretisch onderzoek
Uit analyse van literatuur blijkt dat er nog relatief weinig literatuur beschikbaar is over:
1. Wat de voornaamste faal-/succesfactoren zijn voor agile software ontwikkelmethoden (zoals Scrum);
2. Hoe deze methode omgaat met omgaat met bekende IT faalfactoren.
De volgende samenhangende elementen met betrekking tot agile software-ontwikkeling zijn alsnog uit de relatief beperkte literatuur analyse ontleend:
Een (empirisch) onderzoek (Lalsing, 2012) toont aan dat project grootte binnen de agile benadering medebepalend is voor de mate van succes van het project. De menselijke factor wordt door een grotere groep complexer en leidt tot verslechtering van het succes van agile software ontwikkel trajecten (Lalsing, 2012). Dit was meetbaar gemaakt door te kijken naar mate van re-work, doorlooptijd en kosten (Lalsing, 2012).
Bovenstaand punt wordt bevestigd in een ander onderzoek (Sheffield , 2012) dat beschrijft dat de project grootte alsook de project omgeving van invloed zou moeten zijn op de toegepaste software ontwikkelmethode, maar dat dit in de praktijk dikwijls niet gebeurt. Met andere woorden, project managers passen traditionele methoden toe in situaties waar deze methode niet het meest optimaal zou zijn en vice versa (agile methode waar een traditionele methode beter zou zijn). De “one- size-fits-all approach” voor
software-ontwikkeling bestaat niet en zou leiden tot grotere project risico’s en daarmee het falen van projecten. Voorafgaand aan een project zal bepaald moeten worden welke krachten er spelen in het betreffende project en welke methodologie toegepast zou moeten worden.
In het verlengde van het in het eerste punt aangehaalde onderzoek is ook beschreven dat bij complexere Scrum projecten (met veel personen en/of meerdere teams) het een grote uitdaging is om de governance/ overkoepelende aansturing op orde te hebben. Er zijn vele afhankelijkheden die moeilijk te beheersen zijn. De top 6 van meest genoemde problemen zijn (Vlietland, Van Vliet, 2014):
Tabel 3.3: Problemen bij Scrum coördinatie
# Problemen bij Scrum coördinatie Percentage van totaal
1 Gebrek aan coördinatie in de keten 24%
2 Mismatch in de backlog prioriteit tussen teams 23%
3 Alignement tussen teams 20%
4 Gebrek aan IT automatisering in de keten 14% 5 Onvoorspelbaarheid in oplevering tussen de teams 11% 6 Gebrek van informatie zichtbaarheid in de keten 7%
Aanvullend op de constatering dat overkoepelende aansturing van grotere project omgevingen bij de toepassing van Scrum een aandachtspunt is vanwege de afhankelijkheden, kan worden
geconcludeerd dat uit literatuur analyse nog niet naar voren komt in hoeverre er andere faalfactoren zijn in een agile omgeving.
Aangezien in de theorie relatief weinig beschreven is over de faalfactoren met betrekking tot agile ontwikkelmethoden/ Scrum, is dit onderdeel van de interviews met professionals. De resultaten hiervan worden in de volgende paragraaf beschreven.
3.6.2 Agile in de praktijk 3.6.2.1 Inleiding
Tot nu toe heeft de weergegeven analyse zich gefocust op een theoretische aanpak waarbij is onderzocht wat software-ontwikkeling is (agile vs traditioneel), wat bekende IT project faal- en succesfactoren zijn en hoe agile methoden, zoals Scrum, bestand zijn tegen project faalfactoren en/of hoe zij deze risico’s mitigeert. Dit vraagstuk wordt nu verder in de praktijk door middel van interviews getoetst en aangevuld. De interviews vinden gestructureerd plaats door middel van open vragen.
Bij het selecteren van personen voor de interviews was het streven om een representatieve
diversiteit aan te spreken, rekening houdend met de beperking dat de toepassing van agile software ontwikkelmethoden, zoals Scrum, in Nederland pas recent is opgestart5. Er is gesproken met mensen met die voldoen aan de volgende voorwaarden (gesprekken zijn schematisch uitgewerkt in bijlage IV):
Verantwoordelijkheid bij Scrum implementatie bij zowel ING Bank Commercial Banking (CB) als bij ABN AMRO, eind verantwoordelijken bij Scrum projecten (Product owners bij ING CB);
Onafhankelijke partijen als 1. Scrum Coach (Cap Gemini) en 2. oplossing manager (Atos) en 3. deskundige op software ontwikkel projecten bij overheid (KPMG).
Als laatste is ook gesproken met de CIO van ING Bank NL, welke in een ander organisatie onderdeel van ING Bank verantwoordelijk is voor Scrum implementatie dan de eerder genoemde ING CB mensen. Dit gesprek was validerend van aard en zal worden toegelicht in hoofdstuk 5.4.2/5.4.3. Het volgende interview schema is van toepassing met daarbij de gesproken persoon, rol, in welke organisatie, datum van gesprek en toelichting voor selectie:
Tabel 3.4: Interview schema en toelichting selectie
Naam Rol Bedrijf Datum Toelichting voor selectie Bastian Ahrend Business
Manager & CBS Risk manager
ING Bank 3-2-2015 Medeverantwoordelijk voor implementatie van Scrum methode binnen OIB CB ING Bank. Kan veel vertellen over de methodologie, implementatie, voor- nadelen en overkoepelende
aansturing/governance. Hans Pothuizen Lijn Manager
Mobiel Bankieren
ABN AMRO 9-2-2015 Verantwoordelijk voor succesvolle implementatie van Scrum methode binnen een afdeling van ABN AMRO. Kan veel vertellen over de
methodologie, implementatie, voor- nadelen en overkoepelende aansturing.
5 In een vergadering (16-2-2015) van Nederlandse Vereniging van Banken (NVB) met IT audit hoofden is geconcludeerd dat met name ABN
Naam Rol Bedrijf Datum Toelichting voor selectie
Jasper Lamers Trainer Scrum Cap Gemini 10-2-2015 Ervaren trainer van Scrum methode. Langdurige ervaring bij zowel overheden als Rabobank en ING Bank. Kan achtergrond geven over
onderscheid tussen sectoren (bijvoorbeeld overheid en financiële sector).
Dick van der Sar Solution Manager
Atos 11-2-2015 Solution delivery expert met brede ervaring in software ontwikkel trajecten bij zowel overheden als private bedrijven. Kan veel
achtergrond geven over onderscheid tussen overheid en financiële sector, overkoepelede aansturing, Scrum zelf en implementatie.
Inge Lammers Senior Product Owner/klant ING Interactive Payment Channels
18-2-2015 Product owner is uiteindelijk de klant /opdrachtgever van het ontwikkel team. Zij bepalen mede of software ontwikkel producten worden goedgekeurd/geaccepteerd. Kan vanuit klant perspectief voor en nadelen beschrijven van Scrum met externe leverancier als ontwikkelaar. Jan-Willem Jonker Senior Product Owner/klant ING CB SL (Security Layer)
18-2-2015 Product owner is uiteindelijk de klant /opdrachtgever van het ontwikkel team. Zij bepalen mede of software ontwikkel producten worden goedgekeurd/geaccepteerd. Kan vanuit klant perspectief voor en nadelen beschrijven van Scrum met interne ontwikkelaar.
Ronald Koorn Partner IT Advisory
KPMG Advisory
20-2-2015 Partner KPMG en veel ervaring op het gebied van advies en assurance IT projecten m.b.t. software-ontwikkeling. Focus op
overheid/semioverheid en IT service providers. Kan veel achtergrond geven over IT project faalfactoren en onderscheid tussen overheid en financiële sector en agile methoden, waaronder Scrum.
Peter Jacobs CIO ING Bank NL
ING Bank 23-2-2015 CIO ING Bank NL en verantwoordelijk voor succesvolle en brede
implementatie Scrum. Met brede ervaring is opdrachtgever/IT manager geschikt voor validatie van handreiking tot controledoelstelling programma.
3.6.2.2 Vragenlijst
Het is een open interview met de volgende leidraad: het begint met de aanleiding van het onderzoek (projectfalen), een inleiding over de uitkomsten van het literatuur onderzoek over faal factoren, hoe agile methoden hieruit voort komen en als laatste hoe de invulling van de rol en/of het
instrumentarium van de IT auditor zou moeten/kunnen mee veranderen met de opkomst van agile software ontwikkelmethoden, zoals Scrum, en daarmee op een effectieve en verantwoorde wijze te kunnen blijven auditen.
De volgende vragen vormden de kern voor het gesprek: 1. Wat is uw rol en/of verantwoordelijkheid?
2. In hoeverre zijn IT projecten (als in software-ontwikkeling) en haar bijkomende risico’s sector afhankelijk (als voorbeeld vergelijken we overheid en financiële sector)?
3. Wat zijn naar uw idee de voornaamste IT project faal & succes factoren?
4. In hoeverre zijn IT project faal & succes factoren verschillend voor software-ontwikkeling en andere ICT projecten?
5. Hoe ondervangen agile systeemontwikkelingsmethoden (waaronder Scrum) de belangrijkste IT project faalfactoren?
6. Welke agile ontwikkelmethode wordt het meest toegepast binnen uw organisatie/afdeling? 7. Wat zijn de sterktes/voor- en/of risico’s /nadelen van Scrum?
8. Wat zou de rol van IT auditor moeten/kunnen zijn bij Scrum? Waar zou zijn/haar aandacht naar moeten uitgaan?
3.6.2.3 Resultaten interviews
1. Wat is uw rol en/of verantwoordelijkheid?
De rollen en verantwoordelijkheden zijn verschillend en zijn gekozen bij alle relevant onderdelen in dit onderzoek. De reden dat voor elke geïnterviewden is gesproken is reeds in detail toegelicht in tabel 3.4.
2. In hoeverre zijn IT projecten (als in software-ontwikkeling) en haar bijkomende risico’s sector afhankelijk (als voorbeeld vergelijken we overheid en financiële sector).
In feite gaf iedere geïnterviewde aan dat er veel overlap zit tussen software ontwikkel projecten bij overheden en financiële instellingen. Het is beide IT, het gaat om informatie voorziening en de gehanteerde methoden en technieken zijn in principe ook gelijk. Daarnaast zijn het in beide omgevingen complexe projecten en worden uitgevoerd met veel afhankelijkheden naar andere partijen (zoals andere banken, overheden, toezichthouders). Elk van deze partijen kunnen ook nog sub-partijen hebben, wat het nog complexer maakt. Er zijn veel gelijkwaardige partijen in de ketens die verstrengeld zijn met elkaar en elkaars informatie nodig hebben aangezien het gaat om dezelfde klanten; burgers en bedrijven. Daarnaast kennen beide type organisaties ook relatief veel
bureaucratie en de daarbij horende uitdagingen. Als laatste overeenkomst kennen banken evenals overheden dat “alle Nederlanders” klanten zijn. Iedereen heeft een “burger service nummer” en iedereen bankiert. Het betreft voor beide type organisaties gevoelige en confidentiële informatie. Sommige geïnterviewden gaven aan dat een mogelijk belangrijk verschil is dat bij financiële
instellingen de besluitvorming minder complex is dan bij overheden. In een financiële instelling kan makkelijker een besluit worden genomen door een uiteindelijk verantwoordelijk persoon, terwijl een overheid omgeving altijd te maken heeft diffuse politiek.
Nog een belangrijk verschil dat werd genoemd als verschil in de aanloop van projecten: de overheid is verplicht aan te besteden. Dit heeft een implicatie: de overheid moet vereisten (bijv. functioneel ontwerp) beschrijven waar de leveranciers op kunnen bieden met offertes. Leveranciers moeten dan starten met het uitwerken van documentatie. Dit proces mondt in veel gevallen uit in een
traditionele ontwikkelmethode met de daarbij horende faalfactoren. Tegenwoordig zijn er echter voor overheden ook alternatieven in de vorm van “best value procurement”. Dit gaat ervan uit dat opdrachtgever (in dit geval de overheid) niet de best wetende partij is voor het bepalen van
functionele vereisten. Deze methode is meer op doelstelling gericht in plaats vanuit detaillering van eisen en wensen. De benadering is gelinkt aan het agile gedachtegoed. Als eerste wordt een globale benadering gekozen en daarna gezamenlijk (opdrachtgever en leverancier) verder gedetailleerd. Dit is een toenemende tendens bij overheden.
Laatst genoemde verschil is de financiering van projecten. Commerciële partijen kunnen een business case opzetten met een bepaalde terugverdientijd. De overheid kent partijen die kunnen afschrijven (over meerdere jaren) en andere (die op kas basis werken) niet.
Ondanks deze verschillen, zijn de project methoden zelf/aanpak vergelijkbaar bij beide sectoren.
3. Wat zijn naar uw idee de voornaamste algemene IT project faal & succes factoren?
De geïnterviewden gaven hier verschillende oorzaken voor falen of succes. De volgende elementen zijn meerdere malen genoemd:
Project en technologie complexiteit;
Requirements;
Project Management;
Communicatie & afstand; en
Externe factoren.
3.1 Project en technologie complexiteit: meerdere geïnterviewden gaven aan dat complexiteit en grootte van het project een grote invloed heeft op de mate van succes van een project. Hoe groter het project hoe moelijker het is om het met succes af te ronden. Dit wordt volgens de
geïnterviewden professionals o.a. veroorzaakt door afhankelijkheden binnen en buiten het project en de algemene toename van de complexiteit. Afhankelijkheden spelen zich af op twee te
onderkennen niveaus: 1. project niveau en 2. technologie niveau. Het project niveau heeft betrekking op complexer wordende samenwerking tussen personen/project teams. Technologie heeft betrekking op complexiteit integratie van verschillende technische omgevingen (keten afhankelijkheden en integratie van architecturen).
3.2 Requirements: Een andere veel genoemde faalfactor is onduidelijk opgestelde en wijzigende technische- en functionele eisen (requirements) in het project. Vaak worden requirements opgesteld die achteraf niet volledig goed doordacht waren. Dit kan veel tijd- en geld verlies met zich
meebrengen. Het kan ook zijn dat er vanaf verschillende kanten verschillende eisen worden gegeven die tegengesteld zijn. Er kunnen plotselinge wijzigingen komen, omdat er andere partijen in de markt zijn die een bepaalde functionaliteit hebben. Als laatste kan het zijn dat er teveel eisen zijn gesteld, waardoor de looptijd erg lang wordt en dat ten tijde van oplevering de buitenwereld is veranderd.
3.3 Project Management: er werd in een aantal interviews genoemd dat slechte inschattingen van tijd, budget en capaciteit een belangrijke oorzaak was. Dit was gerelateerd aan matig project management/ verwachtingsmanagement. Hieraan gerelateerd is een genoemde oorzaak: project managen op eind datum. Dit levert persoonlijke druk op voor mensen waardoor mensen soms (niet effectieve) shortcuts nemen, wat mogelijk leidt tot kwaliteitsverlies en/of andere risico’s.
3.4 Communicatie & afstand: Een ander veel genoemde faalfactor is slechte communicatie tussen de betrokken stakeholders. Er is vaak grote afstand tussen de stakeholders (bijvoorbeeld
opdrachtgevers en ontwikkelaars). Resultaat is dat er slechte communicatie en samenwerking plaatsvindt tussen de partijen. Men is door de toegenomen afstand tussen de partijen in continue overdrachtsfase: veel overdrachtsmomenten met mogelijk kennis verlies. Er zijn dan compensatie maatregelen nodig voor de afstand (documentatie, reviews/goedkeuringen). Daarnaast is door de afstand geen mogelijkheid tot eind product verantwoordelijkheid, maar juist functionele
verantwoordelijkheid. Dit leidt tot nog meer tot afstand. Hierdoor vindt standaardisatie plaats op het proces (met vele methoden als CMMI, ITIL, Prince2). Cultuurverschillen wordt overigens ook genoemd als mogelijke factor in het creëren van afstand/slechte communicatie. Als laatste wordt in dit kader ook nog de onkunde/onwetendheid van betrokken bestuurders m.b.t. Scrum genoemd, als een van belangrijkste stakeholders. De bestuurder heeft teveel afstand en heeft niet genoeg feeling wanneer en/of hoe in te grijpen/aan te sturen.
3.5 Externe factoren: Een andere factor die genoemd is de externe factor: de relatie met de leveranciers en/of gebruikers. Indien er sprake is van een externe leverancier en hier slecht mee samen gewerkt kan worden door afstand/cultuur/ communicatie problemen, leidt dit tot een mogelijke faalfactor. Bij eindgebruikers kan er sprake zijn van een lage acceptatie graad bij verandering. Hoe dichter het project bij de eindgebruikers kant komt, des te gevoeliger het wordt om te falen. Er is te weinig acceptatie van software bij gebruikers i.v.m. verschillende belangen per gebruiker. Daarnaast kan het zijn dat door toedoen van bepaalde externe beslissingen resources moeten worden verminderd, terwijl de eisen ten aanzien van de uitkomst voor de projecten hetzelfde blijven. Dit resulteert in een verhoging van persoonlijke werkdruk/kwaliteitsimpact.
4. In hoeverre zijn IT project faal & succes factoren verschillend voor software-ontwikkeling en andere ICT projecten?
Alle geïnterviewden gaven aan dat de genoemde project faalfactoren in principe gelijk zijn voor zowel software-ontwikkeling als voor generieke ICT projecten.
5. Hoe ondervangen agile software-ontwikkelingsmethoden (waaronder Scrum) de belangrijkste IT project faalfactoren?
Merendeel van de geïnterviewden zegt dat agile software ontwikkelmethoden, zoals Scrum, is ontstaan als reactie op de tekortkomingen (en daarmee de faalfactoren) van de methoden die ervoor werden toegepast. Agile software ontwikkelmethoden zoals Scrum ondervangen daardoor van nature al veel project risico’s. Dit is vooral te danken aan de expliciete transparantie van Scrum. Het is volledig inzichtelijk voor de betrokken stakeholders wie wat doet. Niemand kan
tekortkomingen verbergen door het dagelijkse overleg/gemaakte afspraken. Afstanden tussen stakeholders zijn verkleind door de directe communicatie. De ontwikkel cycli zijn kort en hebben
tevens tot gevolg dat er overzichtelijke requirements zijn om te implementeren. Daarnaast is het meteen inzichtelijk voor product owners hoe de software eruit ziet en hoe het functioneert.
6. Welke agile ontwikkelmethode wordt het meest toegepast binnen uw organisatie/afdeling?
Hierop zeggen alle geïnterviewden: Scrum. Dit betekent niet dat alle projecten nu met Scrum manier worden uitgevoerd. Bij ING bijvoorbeeld loopt de ene afdeling verder voorop in de implementatie en toepassing van Scrum. Binnen Commercial banking is het project management ongeveer 9 maanden actief gericht op de toepassing van Scrum in de volle breedte. In Domestic Bank NL werkt men reeds 4 jaar met de Scrum methode. Beide afdelingen hebben gekozen voor een top-down approach volgens een big-bang principe. Bij ABN Amro is de uitrol nog niet heel breed uitgemeten, maar zij tuigen wel de organisatie op voor een bredere uitrol (op basis van een belangrijke succesvolle implementatie van Scrum). ABN Amro kiest voor een meer bottom-up benadering, waarbij de afdelingen zelf verantwoordelijk worden voor de invulling van deze aanpak. Vanuit de agile coach van Cap Gemini, werd duidelijk dat een andere grote Nederlandse bank ook nog maar beperkt is begonnen met Scrum ontwikkel aanpak. Hetgeen ze tot nu toe hebben gedaan was bottom-up approach. In de praktijk leidt implementatie van Scrum ook tot veel weerstanden (tegen verandering).
Bij overheden is er nog maar in beperkte mate sprake van agile / Scrum toepassing; hetgeen, volgens de geïnterviewde consultants, vooral zit in de verplichtingen tot aanbestedingen. Er zijn echter kenteringen waarneembaar (zoals ook al kort toegelicht bij interview vraag 2 ).
7. Wat zijn de sterktes/voor- en/of risico’s /nadelen van Scrum?
Voordelen van Scrum:
Veel geïnterviewden noemden in het algemeen dat agile software ontwikkelmethoden, en in dit geval ook Scrum, is ontstaan als gevolg van de risico’s en zwaktes van traditionele methoden. Genoemd werden:
Transparantie;
Empowerment met energie.
Transparantie: Meer specifiek werd door veel geïnterviewden gezegd dat agile software
ontwikkelmethoden en in dit geval Scrum, een transparante methode is. Transparantie ontstaat door het teamwork, het kort cyclisch werken. Dit resulteert in heldere communicatie in het team met de nauw betrokken stakeholders (opdrachtgever en ontwikkelaar). Door de nauwe
samenwerking tussen de partijen legt het mogelijke problemen/bottlenecks bloot waarbij niemand zich kan verbergen voor het niet goed opleveren van het afgesproken werk. Het levert daardoor snelle levertijden en werkende software vanaf het begin. Er wordt gezamenlijk (business en IT) iets opgeleverd.
Empowerment met energie: Scrum is een manier van werken waarbij het team vooral veel
empowerment ontvangt. Het is een mensgerichte methode en past bij de nieuwe tijdsgeest en heeft een hoog lerend vermogen. Het team wordt in staat gesteld er gezamenlijk voor te gaan en brengt veel positieve energie. Tevens zijn de teams stabiel (over de tijd) en multidisciplinair, waarbij professionals elkaar kunnen opvolgen indien iemand (tijdelijk) weg valt. Mensen gaan dan ook meer ownership ontwikkelen. Mensen voelen zich empowered en nemen daardoor daadwerkelijk
ownership bij het ontwikkelen en onderhouden van software. In het verleden was er een plan van de opdrachtgever, die eerst goedgekeurd moest worden en daarna de ontwikkelaar werd gevraagd het “uit te voeren”. Dit werkt minder motiverend.
Er ontstaat een nieuwe uitdaging in het geval van samenwerking met een derde (externe leverancier) die betrokken is in een Scrum project (bijvoorbeeld verantwoordelijk voor software-ontwikkeling). Dan ontstaat er alsnog een split van verantwoordelijkheden en gaan de echte Scrum effecten gedeeltelijk verloren, aldus de geïnterviewden.
Nadelen van Scrum:
Als zwakke elementen van de Scrum methode worden genoemd:
Geen structuur;
Complexiteit;
Lastige IT controleerbaarheid;
Organisatorisch; en
Skill set team.
Geen structuur: De geïnterviewden noemen dat er geen structuur is en daarnaast is er geen punt op de horizon bij Scrum toepassing. Indien er geen houvast is, of geen duidelijke randvoorwaarden (bijvoorbeeld een architectuur/data model) dan kan er iets worden gebouwd dat op zichzelf goed werkt, maar mogelijk in een latere fase niet meer optimaal en/of met problemen/onveilig
functioneert. Daarnaast stelt Scrum zelf geen inhoudelijke (kwaliteitsgerichte) systeemeisen, hierdoor kunnen belangrijke minimale beheersingseisen over het hoofd worden gezien. Scrum zegt dus niets over risico beheersing. Er is een backlog (scrum term voor de te implementeren
systeemeisen), maar geen minimale systeem eisen/risico beheersing. Scrum is daarmee te “light-weight” volgens sommigen en daarmee tot op een bepaalde hoogte risicovol.
Complexiteit: Complexiteit kan boven het hoofd groeien in een Scrum traject. Er komt daardoor meer en meer op de backlog. Elke eis van de backlog eindigt in een bepaalde fase. De een is nog in user story, ander is in ontwikkeling, weer een ander is in test fase of inmiddels fout bevonden etc. De vraag is hoe komt het allemaal bij elkaar. Men kan het overzicht makkelijk kwijt raken. Zeker in grotere projecten gebeurt dit. Mensen kunnen dan afhaken en vervallen mogelijk weer in waterval methode. Naast deze technische complexiteit, geldt dat ook voor de organisatorisch complexiteit. Hoe meer projecten hoe moeilijker te organiseren. Scrum zelf voorziet eigenlijk niet in het
organiseren van meerdere projecten, althans in beperkte mate. Hierdoor moeten er dan
overkoepelende constructies worden bedacht en geïmplementeerd als compensatie, die echter in de praktijk weer veel afdoen aan de Scrum gedachte. Er komen bijvoorbeeld weer veel
afstemmingen/overdrachtsmomenten. Daarnaast gaat politiek spelen bij grote projecten. Daarom wordt er vaak een project om Scrum heen gezet (gemanaged via bijvoorbeeld Prince2). Scrum en politiek is namelijk niet te combineren. Prince2 is vooral gekoppeld aan de waterval methode. Prince2 vraagt namelijk formele aspecten zoals ook gedefinieerd in waterval. Prince2 combineren met Scrum kan wel, maar vraagt aanpassingen.
Lastige IT controleerbaarheid: Scrum biedt veel vrijheid, wat een risico met zich meebrengt, zeker in een overheid/financiële wereld waar sprake is van veel gevoelige data/vertrouwen. Bij vragen als:
“hoe waarborg je nou beveiliging, integriteit, beschikbaarheid, audit trail” zijn de antwoorden moeilijk te bewijzen (evidencen). Scrum stelt weinig eisen t.a.v. documentatie. Niet functionele eisen worden pas laat in het proces helder. Het gaat bij dit soort kwaliteitsaspecten over het grotere geheel van een te ontwikkelen applicatie en in de omgeving. Het risico is dat alles tussentijds op groen staat, maar de vraag blijft of het op het einde wel goed komt. Aangezien de interactie met andere projecten soms moeilijk is, is dit een risico/nadeel. Andere IT testen als penetratie testen, integratie testen, stress testen of een gedegen audit op de juiste en volledige verwerking is moeilijk uitvoerbaar (of pas echt op het einde). Dit heeft vooral impact op niet functionele (kwaliteits)eisen. Aantoonbaar “beheerst zijn (in control)” is een nieuwe uitdaging voor Scrum. In het verlengde van deze controleerbaarheid wordt, ook voor management zelf, de meetbaarheid van prestaties van Scrum project als een uitdaging genoemd.
Organisatorisch: De geïnterviewden noemen vaak dat Scrum bij de organisatie moet passen. Het heeft in ieder geval een duidelijk weerslag op de cultuur in de organisatie. Niet alleen bij de teams, maar ook bij senior management. Afhankelijk hoe het geïmplementeerd wordt, kan de weerstand in de organisatie langer of korter duren. Sommigen zullen nooit kunnen wennen aan de relatieve onzekerheid (bijvoorbeeld dat het niet bekend is hoe de ontwikkeling zal gaan) die deze methode met zich mee brengt. Het kan dus gevolgen hebben voor de samenstelling in de organisatie. Dit geldt overigens niet alleen op team niveau maar ook op senior management niveau. Senior management weet mogelijk niet wat de effecten zijn bij implementatie van Scrum. Het vergt een cultuur
verandering op alle lagen. Senior management weet niet precies meer wat er, wanneer door de professionals gedurende het jaar opgeleverd zal worden. Het vergt ander leiderschap. Een
bijkomend risico is dat door het ontbreken van voldoende support van senior management voor de agile software ontwikkelmethoden, in dit geval Scrum, geen echte empowerment is in de
organisatie. Dit kan veroorzaakt worden doordat senior management onvoldoende bewust is voor de gevolgen voor de aansturing van de organisatie en de gevolgen voor de teams zelf
Skill set team: de geïnterviewden gaven aan dat het in de praktijk moeilijk is om een multidisciplinair team op te stellen. Daarnaast verschillen duidelijk ambitie en kennis niveau van de mensen. Dit leidt tot afhankelijkheid van kennis en kunde van enkele teamleden. Het bekende voordeel van een proces aanpak als CMMI/Prince2 en het gebruik van templates, is dat de projectverantwoordelijke niets vergeet en/of geen afhankelijkheid is naar de kennis. Deze houvast ontbreekt bij Scrum. De hiervoor aangedragen oplossing is ervaring en kennis. Ervaring is nodig om het succesvol te maken. Als er een te grote afhankelijkheid ontstaat van ervaring en kennis, ontstaat er een risico.
8. Wat zou de rol van IT auditor moeten/kunnen zijn bij Scrum? Waar zou zijn/haar aandacht naar moeten uitgaan?
De volgende onderwerpen waar een IT auditors aan kan bijdragen werden genoemd:
Proces en inhoud;
Complexiteit; en
“Wat Scrum mist”.
Proces en inhoud: Meerdere geïnterviewden zeiden dat door de beperkte documentatie een project audit moeilijker is geworden. Er is relatief weinig documentatie/bewijs om audit objecten te
Scrum team proces draait. In het proces zitten namelijk de controles verwerkt. Audit zou kunnen beoordelen of de (1) proces controles werken (volgt men de spelregels van het spel) en (2) de ontwikkelaars voldoen aan de afgesproken normen. Qua proces controles zijn de belangrijkste elementen: planning, stand-up sessions, demo, retrospect, communicatie, wordt er continu geleverd (burn-down ratio) documentatie, skills van mensen. Qua normen zou o.a. gecontroleerd moeten worden of ontwikkelaars zich houden aan de belangrijke mijlpalen in het project, wat is er opgeleverd en wat waren de acceptatie criteria, hoe is kwaliteit, hoe zijn de niet functionele requirements geïmplementeerd en getest, hoe worden wijzigingen/afwijkingen geaccepteerd van deze criteria, hoe worden risico’s afgetekend , automatisering in de vorm van ontwikkeling en operationele zaken, test resultaten etc.
Complexiteit: een aantal geïnterviewden gaven aan dat complexiteit een probleem kan zijn bij Scrum. Dit zou dan ook een aandachtspunt moeten zijn voor audits. Hoe ziet de overkoepelende structuur eruit, die alle projecten goed moet laten samen komen. Hoe worden afhankelijkheden gemanaged en wordt voorkomen dat er conflicten op organisatorisch- en technisch niveau ontstaan. Wat Scrum mist: enkele geïnterviewden gaven aan dat de auditor juist zou moeten auditen wat Scrum mist: hoe is de juiste balans tussen vrijheid en toepassen van standaarden/”best practices” binnen deze vrijheid. Als analogie: er kan een huis worden gebouwd met een bouwtekening op een Scrum manier. Het kan zonder bouwtekening, maar zonder bouwtekening is er geen beeld hoe het huis eruit komt te zien en zijn risico’s groot om te mislukken (in termen van verwachtingen/ geld / tijd). Audit zou kunnen controleren of Scrum projecten aan de juiste minimale technische vereisten voldoen (e.g. scope, architectuur). Daarnaast is dan een belangrijke vraag: hoe is management zelf in controle over het proces.
3.6.2.4 Samenvattende conclusies van interviews
Bovenstaande interviews hebben twee onderzoeksvragen geadresseerd.
Onderzoeksvraag 3:
In hoeverre zijn IT project risico’s en/of faalfactoren sector afhankelijk?
Voor veel overheidscases geldt dat ze openbaar zijn en daarmee ook beschikbaar in literatuur. De vraag is of conclusies die hieruit getrokken kunnen worden ook gelden voor andere sectoren. Bij een analyse in welke mate dat faalfactoren bij software-ontwikkeling sector afhankelijk zijn, kan er gekeken worden naar overeenkomsten/verschillen in aanpak/methode/randvoorwaarden van ICT projecten binnen de verschillende sectoren. Indien daar veel overeenkomsten worden gevonden kan de aanname worden gedaan dat ook de faalfactoren van vergelijkbare aard zijn.
De analyse op de onderzoeksvraag is in eerste instantie gericht geweest op wat er al aan inzicht in de literatuur te vinden is. In de literatuur wordt echter maar beperkt ingegaan op sector afhankelijkheid bij projectfalen. Wat te vinden is, is dat blijkt dat veel grote projecten (>10 mio Euro) vooral bij overheid plaatsvinden en dat de meest complexe IT projecten bij de overheid zitten (Martijnse, 2007). Ondanks dit gegeven blijkt ook dat de private sector met dezelfde uitdagingen kampt (Schönfeld, 2012).
