Op zoek naar adaptabiliteit voor de IT-auditor

Handvatten voor het onderzoeken van agile softwareontwikkelingsprocessen

17 april 2019 José Luis Sanchez Mejia
PDF
In dit artikel:

Sinds de publicatie van het agile-manifest in 2001 passen steeds meer organisaties agile-methoden toe voor softwareontwikkeling. De kort-cyclische processen die centraal staan in de agile-methoden, maken het mogelijk om tijdens softwareontwikkeling veranderende requirements snel door te voeren. Op deze wijze kunnen organisaties sneller op de veranderende wensen van hun klanten reageren. De agile-methoden staan organisaties daarnaast toe om softwareproducten effectiever, efficiënter en sneller op te leveren.

Voor het auditen van agile-softwareontwikkelingsprocessen bestaan nog geen richtlijnen of referentiekaders in het IT-auditing vakgebied. De opkomst van de agile-methoden heeft dus een nieuw werkveld voor de IT-auditor gecreëerd, een werkveld waarin de IT-auditor worstelt met zijn conventionele aanpak en op zoek is naar handvatten. In dit artikel worden handvatten aangereikt voor het onderzoeken van agile-softwareontwikkelingsprocessen.

Allereerst behandel ik enkele elementen van de agile-methoden. Daarna behandel ik de toepassing van de agile-methoden in de financiële sector. Vervolgens verhelder ik enkele key-risico’s die zich in agile-softwareontwikkelingsprocessen voordoen. Ook doe ik een aanzet voor de bijbehorende controle-elementen. In de laatste paragraaf behandel ik de rol van de IT-auditor en de instrumenten waarmee hij agile-onderzoekscontexten kan analyseren.

Op basis van deze inzichten zal een IT-auditor beter geëquipeerd zijn om agile-softwareontwikkelingsprocessen te onderzoeken.

De agile-methoden

In de jaren 70 publiceerde Royce een artikel waarin hij zijn ervaringen met het managen van grote softwareontwikkelingen beschrijft. Dat artikel is later de basis geworden voor de traditionele wijze van softwareontwikkeling conform de watervalmethode.[ROYC70] In de jaren na deze publicatie hebben veel onderzoekers kritiek geuit op de watervalmethode. Onder meer op de ongeschiktheid van de watervalmethode om veranderingen tijdens een softwareontwikkelingsproject tijdig door te voeren. In dynamische markten – waar business-requirements snel veranderen – kan het toepassen van de watervalmethode daarom leiden tot lange doorlooptijden, budgetoverschrijdingen en klantontevredenheid. [KTAT09, BOCI03] De agile-methode is daarentegen een softwareontwikkelingsmethode die geschikter is voor dynamische markten. Deze methode werkt met kort-cyclische processen waarmee veranderingen sneller verwerkt kunnen worden.

Standish group onderzocht wereldwijd in de periode 2011-2015 meer dan 10.000 verschillende softwareontwikkelingsprojecten. De agile-methode toont een hoger slagingspercentage voor kleine, middelgrote en grote softwareprojecten, zie figuur. [STAN15]

 

Agile Manifesto documentatie

In 2001 publiceerden twintig softwareontwikkelaars het agile-manifest. Dat manifest is later de basis geworden voor de agile-methoden. In dat manifest geven de ontwikkelaars aan dat ze de nadelen van de traditionele ontwikkelmethoden vermijden, door de nadruk te leggen op:

  • Mensen, interactie en hun onderlinge samenwerking zijn belangrijker dan processen en tools.
  • Werkende softwarefunctionaliteit is belangrijker dan volledige
  • Samenwerking met de klant levert meer op dan onderhandelingen over het contract.
  • Inspelen op verandering is belangrijker dan het volgen van een plan.

Bovenstaande uitgangspunten zijn later in de twaalf principes voor agile-softwareontwikkeling uitgewerkt (zie tabel 1). [AGI01]

Tabel 1: De twaalf agile principes.

Definitie

De agile-methode kan als volgt gedefinieerd worden: ‘A software development method is said to be an agile software development method when a method is people focused, communications-oriented, flexible (ready to adapt to expected or unexpected change at any time), speedy (encourages rapid and iterative development of the product in small releases), lean (focuses on shortening timeframe, costs and on improved quality), responsive (reacts appropriately to expected and unexpected changes), and learning (focuses on improvement during and after product development).’ [QUME08]

Het scrumraamwerk

Scrum is de bekendste en meest toegepaste verschijningsvorm van de agile-methoden, zie figuur 1. [VERS18]

Figuur 1: Verschijningsvormen van Agile methoden.

Scrum kan beschreven worden als een iteratief, incrementeel procesraamwerk voor het managen van softwareontwikkeling (zie figuur 2). Het procesraamwerk bestaat uit scrumrollen, ceremonies en artefacten. Hieronder worden enkele elementen van scrum belicht. Scrum hanteert kort-cyclische processen waarmee een klein stuk software met businesswaarde wordt opgeleverd. Deze kort-cyclische processen staan bekend als sprints of iteraties en duren een tot vier weken.

Figuur 2: Scrum-ontwikkelingsproces.

Multidisciplinair team en face-to-facecommunicatie

In scrum staat werken in kleine multidisciplinaire teams centraal. Voordat een IT-organisatie softwareproducten gaat ontwikkelen, dient deze een team samen te stellen. De leden van het scrumteam beschikken over een eigen specialisatie, maar zijn cross-functioneel inzetbaar vanwege hun brede skill set. Scrum bevordert de face-to-face-communicatie omdat de leden fulltime in teamverband samenwerken.

Tabel 2 toont de rollen die in een scrumteam vervuld worden.

Tabel 2: Rollen in scrum.

High level planning

Na de teamsamenstelling start de analyse en planning van het op te leveren softwareproduct. Het scrumteam analyseert het softwareproduct en deelt dit op in high-level features. De productowner vertegenwoordigt de klant en speelt een belangrijke rol bij de communicatie en analyse van de features. De productowner is tevens verantwoordelijk voor de prioritering van de features in de productbacklog. De productbacklog is de enige lijst met requirements waarmee het softwareproduct wordt gebouwd, verbeterd of veranderd. Na de prioritering levert het team een releaseplanning op.

Sprint: een incrementele en iteratieve benadering

Tijdens team meetings (refinement meetings) verfijnt het scrumteam de high-level features in stories. Een story is een korte beschrijving van een requirement met duidelijke acceptatiecriteria. Wanneer de stories gereed zijn voor ontwikkeling worden deze toegevoegd aan de sprintbacklog. De sprintbacklog vormt een overzicht van de stories die het team in de volgende sprint gaat realiseren. Vervolgens verdelen de teamleden de taken en worden de stories ingepland. Daarna start een sprint. Een sprint is een, zich herhalende, periode van maximaal vier weken waarin het team een feature analyseert, ontwerpt, bouwt, test en oplevert (incrementele benadering). Tijdens de sprint bespreekt het team dagelijks de voortgang en belemmeringen. Hiervoor worden dagelijkse meetings gehouden (daily stand-ups). Wanneer de eerste versie van de feature gereed is, wordt deze tijdens de sprint review meeting aan de klant getoond. De klant geeft vervolgens feedback en het team voert verbeteringen door (iteratieve benadering). Aan het einde van de sprint voert het team een reflectiemeeting uit (retrospective meeting). Tijdens deze meeting draagt het scrumteam verbeterpunten aan en voert het verbeteringen door. Verder mag het team tijdens de sprint de stories uit de backlog niet wijzigen. Dat gebeurt na de sprint,  de gewijzigde stories komen dan opnieuw in de productbacklog terecht. [GERR13]

Empirische procesbesturing waarborgt kwaliteit

Scrum benadert softwareontwikkeling vanuit het empirische procesbesturingsperspectief.  Volgens dit perspectief kan een IT-organisatie een softwareproduct opleveren door te steunen op het team en zijn ervaring. Het team doet tijdens de softwareontwikkeling ervaring op, leidt kennis af van deze ervaring en voert constant verbeteringen door. Deze verbeteringen worden zowel in het softwareproduct als in het softwareontwikkelingsproces doorgevoerd. In scrum vormen onderstaande pijlers het fundament van de empirische procesbesturing:

  • Transparantie: alle belangrijke aspecten van het scrumproces dienen zichtbaar te zijn voor de stakeholders. Transparantie is belangrijk om te kunnen leren.
    Hoe? Door visualisering van de werkvoorraad, de voortgang en geïdentificeerde problemen. Dit bevordert transparantie en informatie-uitwisseling. De volgende artefacten en ceremonies bevorderen transparantie: geprojecteerde projectvisie, productbacklog, release planning, burndowncharts, sprintreviews en dagelijks meetings (daily standups).
  • Inspectie: teamleden dienen frequent de scrumartefacten en de voortgang ten opzichte van het doel te bewaken om fouten en problemen te detecteren.
    Hoe? Het scrumteam kan fouten en problemen detecteren tijdens de sprintreviews wanneer zij het softwareproduct aan de klant demonstreren.
  • Adaptatie: als het team vaststelt dat een proces buiten de acceptabele limieten valt en dat het resulterende softwareproduct onacceptabel zal zijn, dient het team het proces of het onderhanden werk gelijk te verbeteren.
    Hoe? De teamleden kunnen bijvoorbeeld tijdens de dagelijkse meetings hun issues en belemmeringen uiten. De scrum master is vervolgens verantwoordelijk om deze belemmeringen weg te nemen. Daarnaast leidt het team op basis van de retrospectieve meetings leerpunten af en voert verbeteracties door. [SCHW17]

De toepassing van de Agile-methoden in de financiële sector

De financiële sector transformeert en innoveert

In 2017 voerde TNO een onderzoek uit naar de verbondenheid van ICT en innovatiekracht in de Nederlandse marktsectoren. Uit deze onderzoeksresultaten blijkt dat de financiële sector bovengemiddeld scoort op innovatiekracht en verbondenheid met ICT. De Nederlandse financiële sector ondergaat een digitale transformatie en de komende jaren zullen investeringen in innovatieve ICT-technologieën toenemen. In de bankensector wordt deze digitale transformatie ook bereikt door investeringen in de toepassing van de agile-methoden. In deze sector worden de agile-methoden organisatiebreed toegepast. [BAKK17]

ICT in de financiële sector

In de financiële sector worden ICT-technologieën, gericht op data en communicatie, breed toegepast. Denk bijvoorbeeld aan kunstmatige intelligentie en big data. Daarnaast investeren financiële instellingen aanzienlijk in blockchaintechnologie ten behoeve van de transformatie naar de nieuwe peer-to-peer diensten. [BAKK17]

 

Transformatie door differentiatie klantgerichte toepassingen

De komende jaren zullen financiële dienstverleners ernaar streven hun transformatiedoelen door middel van differentiatie te behalen. Zij zullen hun standaardproducten en dienstverlening onderscheidend proberen te positioneren via digitale kanalen. Het aanbieden van p2p-fintech diensten en p2p-kredietplatforms zijn voorbeelden van differentiatiemogelijkheden. Het ontwikkelen van klantgerichte toepassingen die het leven van de klanten makkelijker maken, is ook een vorm van differentiatie. Goede voorbeelden van klantgerichte toepassingen zijn de peer-to-peer betalingsdiensten via mobiele apparaten en betalingen via wearables. Softwareontwikkelingsprojecten die klantgerichte toepassingen, digitale kanalen en ondersteunende platforms mogelijk maken, zullen hierdoor een groter deel van de bedrijfskosten vormen. Voor de ontwikkeling van klantgerichte toepassingen wordt in de bankensector ook de agile-methode toegepast.

Meer aandacht voor beheersing van softwareontwikkelingsprocessen

Vanwege de toename van softwareontwikkelingsprojecten die klantgerichte toepassingen opleveren, zullen financiële dienstverleners meer aandacht besteden aan hun softwareontwikkelingsprocessen. Organisaties kunnen IT-audits inzetten om meer zekerheid over de beheersing van hun softwareontwikkelingsprocessen te verkrijgen. Tijdens deze IT-audits kan de IT-auditor gevraagd worden om de beheersing van softwareontwikkelingsprocessen onder de loep te nemen. Een IT-auditor werpt allereerst licht op de risico’s als fundament van zijn onderzoeksaanpak. Daarnaast test de IT-auditor de maatregelen die de key-risico’s mitigeren en trekt een conclusie. Zijn conclusie verschaft het management een bepaalde mate van zekerheid over de beheersing van de softwareontwikkelingsprocessen. Deze rol van de IT-auditor als degene die naar het management rapporteert en zekerheid verschaft, staat ook bekend als de traditionele rol van de IT-auditor. [ANWA15] In agile-contexten kan de vervulling van deze traditionele rol een negatieve uitwerking hebben op het scrumteam. Zie verderop in dit artikel, in de paragraaf ‘De meerwaarde van de IT-auditor als spiegelaar’. Allereerst worden in de volgende paragraaf de key-risico’s behandeld die zich in agile-softwareontwikkelingsprocessen voordoen.

Key-risico’s in agile-contexten

In agile-softwareontwikkelingsprocessen kunnen zich risico’s voordoen die agile-specifiek zijn. Tijdens zijn onderzoek kan de IT-auditor deze risico’s vanuit de volgende invalshoeken beoordelen: organisatorisch, procesmatig, technologisch en menselijk. Hieronder worden enkele key-risico’s behandeld, zie figuur 3. Een IT-auditor kan deze inzichten als referentiekader hanteren tijdens zijn onderzoek naar de beheersing van agile-softwareontwikkelingsprocessen.

Figuur 3: Key-risico’s in agile-contexten.

Organisatorische factor

Organisatie niet gereed voor agile-scrum

Scrumpraktijken zijn concrete activiteiten en technieken die het team toepast om software conform de agile-principes te ontwikkelen. Voordat het team deze scrumpraktijken toepast, dient een organisatie een readyness assessment uit te voeren. De organisatie krijgt hiermee zicht op de belemmeringen, de gebreken en middelen die nodig zijn om de agile-scrumpraktijken succesvol uit te voeren. De organisatie dient vervolgens de significante belemmeringen weg te nemen voordat het team kan starten. In de praktijk komt het voor dat organisaties onvoldoende beoordelen of de (omringende) organisatie en het team gereed zijn om scrumpraktijken toe te passen. Dan komen barrières pas aan het licht tijdens de uitvoering van de scrumpraktijken en daalt de motivatie en de prestatie van het team.

Procesfactoren

Onvoldoende informatie over de voortgang, kwaliteit en risico’s (transparantie)

Tijdens de sprint is informatie over de voortgang en de kwaliteit van de ontwikkeling essentieel voor een effectieve evaluatie, validatie en verbetering van de teamprestatie. Het team dient zelf de meeteenheden te definiëren om de kwaliteit en de voortgang te bewaken. Goede meeteenheden voor het meten van de kwaliteit zijn onder andere: het aantal operationele verstoringen na inproductiename, frequentie van rework-activiteiten en omvang van reparatiewerkzaamheden. Om de voortgang te bewaken kan het team verder gebruik maken van burndown-charts 1 en velocity-charts 2. Het scrum-team dient de informatie over voortgang, kwaliteit en risico’s zichtbaar te maken in hun werkruimte. Deze informatie kan ook door middel van een (registratie-)tooling uitgewisseld worden. In de praktijk ervaart het scrumteam uitdagingen met het definiëren en registreren van de meeteenheden om de kwaliteit en de voortgang te bewaken. Dan is de informatie over de kwaliteit en voortgang niet toereikend voor een effectieve evaluatie.

Onvoldoende evaluaties (Inspectie en Adaptatie)

Een belangrijk hulpmiddel voor het uitvoeren van evaluatie is het gebruik van de definitie van ‘klaar’ (Definition of Done).  Het team stelt tijdens de kick-off meeting vast welke definitie zij zullen hanteren om de afronding en de kwaliteit van hun werk te beoordelen. Deze definitie van ‘klaar’ dient zichtbaar te zijn en gedeeld te worden door iedereen die het werk uitvoert en controleert. In de praktijk komt het vaak voor dat het team de definitie van ‘klaar’ niet op verschillende niveaus formuleert (story-, sprint-, en releaseniveau). Ook past het team deze definitie niet consistent toe.

Daarnaast dient het scrumteam de ceremonies consistent uit te voeren ten behoeve van de evaluaties. Deze ceremonies (waaronder dagelijkse meetings, sprint reviews en reflectiemeetings) zijn van belang voor de iteratieve feedback- en leercyclus. In de realiteit komt het vaak voor dat het scrumteam deze ceremonies niet consistent of onvoldoende uitvoert. Dan wordt het feedback- en leerproces onvoldoende gevoed en blijven verbeteringen in het proces achterwege.

Onvoldoende documentatie voor beheer en onderhoud

In scrum softwareprojecten hebben teamleden de neiging documentatie en controlevastlegging te vermijden ten behoeve van snelheid en efficiëntie. De documentatie van de broncode en functionaliteiten zijn dan niet toereikend om het softwareproduct in de toekomst goed te kunnen onderhouden en te beheren. Scrumteams dienen de documentatie niet te vermijden, maar te minimaliseren tot het niveau waarmee de beveiliging, compliance ten opzichte van regelgeving en de kwaliteit van het softwareproduct nog gewaarborgd kan worden. Het team kan voor de documentatie en informatie-uitwisseling ook gebruik maken van tools. Figuur 4 geeft de tools weer die het meest in agile softwareprojecten worden toegepast. [VERS18]

Figuur 4: Tools in agile softwareprojecten.

Onvoldoende rolvastheid en zuivere vervulling van rollen

In de agile-scrumtheorie bestaan enkele rollen die duidelijk gedefinieerd en uitgeschreven zijn. In de praktijk voegen organisaties meer waterval-rollen toe aan de projectteams. Zo worden bijvoorbeeld projectmanagers aangesteld die tevens als scrummasters gaan fungeren. Dit zijn rollen die afbreuk doen aan de kracht van de agile-methoden. De zuivere vervulling van de agile-rollen is een andere significante randvoorwaarde in agile-scrumprojecten. De gedragingen, bevoegdheden en verantwoordelijkheden van de teamleden dienen consistent te zijn met de rollen die zij moeten vervullen conform het agile-denken.

Gebrek aan visie en onduidelijke doelstelling

In agile-scrumprojecten behoren alle teamleden en stakeholders een helder begrip van de visie en hun projectdoelstelling te hebben. De communicatie van een eenduidige projectdoelstelling creëert namelijk de basis voor een werkkader. Ook zorgt een duidelijke projectdoelstelling ervoor dat alle neuzen dezelfde kant op wijzen tijdens het gehele softwareontwikkelingsproces. De teamleden hebben immers goed zicht op hoe zij zullen inspelen op de businessbehoefte. In grotere organisaties, waar verschillende scrumteams met elkaar samenwerken, is begrip van elkaars doel en een gedeelde visie eveneens belangrijk. In de praktijk hebben de teamleden niet altijd een helder beeld van de algemene visie en hun projectdoelstelling. Dit kan leiden tot het nastreven van individuele doelstellingen, hetgeen een negatief effect heeft op de teamsamenwerking en de softwareoplevering. [MOET10]

Technologische factoren

Onvoldoende test- en verificatiewerkzaamheden

De test-driven developmenttechniek is een praktijk die in agile-projecten wordt toegepast. Deze techniek stimuleert ontwikkelaars om functionele tests te schrijven voordat ze gaan coderen. Op deze manier krijgen ontwikkelaars een beter begrip van de functionaliteiten en kunnen ze de oorzaken van fouten sneller achterhalen. Het toepassen van de test-driven developmenttechniek leidt tot efficiëntievoordelen. Dit in de vorm van lagere debugging-werkzaamheden en minder werkinspanning. Het structureel toepassen ervan vereist echter goed begrip van de requirements, intensieve samenwerking met de klant en discipline. In agile-contexten is de verankering van de test-driven developmenttechniek uitdagend omdat ontwikkelaars de neiging hebben om terug te vallen op traditionele ontwikkeltechnieken. [CAOL08] Andere verificatiepraktijken waarmee het team de interne kwaliteit van de code kan waarborgen, zijn: pair programming 3, automated testing, code-standaarden, code-eigenaarschap, refactoring en continuous integration. In de praktijk komt het voor dat het team onvoldoende verificatie- en testwerkzaamheden uitvoert (onder andere gebruikersacceptatietests, productie-acceptatietests, systeemintegratietests en regressietests).

Mensfactoren (soft controls)

Hiërarchische cultuur niet in lijn met agile mindset

De organisatiecultuur van het team dient gericht te zijn op het continu valideren, evalueren en verbeteren van teamprestaties. In agile-settings dient de IT-organisatie hiërarchie te vermijden. Met andere woorden: het management dient zijn macht niet te gebruiken om het team op operationeel niveau en taakniveau aan te sturen. Ook binnen het team dient hiërarchie en machtsafstand vermeden te worden. In scrumprojecten hebben alle teamleden het recht om hun mening te uiten en om beslissingen te nemen, onafhankelijk van hun positie of salarisschaal. In de praktijk komt het voor dat de teamleden beslissingen aan hogergeplaatsten overlaten, hetgeen tot vertragingen kan leiden tijdens de iteraties. [TANN14]

Top-down managementbenadering en signalen van wantrouwen

Kenmerkend voor de top-downbenadering is dat vanuit het management wordt aangegeven wat én hoe het projectteam onderin dient te opereren. Het management controleert daarnaast periodiek het team om zekerheid over het behalen van de projectdoelstelling te verkrijgen. De agile-methoden zijn daarentegen gebaseerd op een bottom-up managementbenadering. Kenmerkend voor de bottom-upbenadering is dat het management een autonoom werkkader voor het team creëert. Het team kan binnen dit werkkader zelfstandig opereren en zelfcontrole uitvoeren. Het management is alleen ondersteunend, richtinggevend en bemoeit zich niet met de operationele uitvoering. Bovendien voert het management geen controle uit op het team, maar heeft juist vertrouwen in het team. In scrumprojecten komt het vaak voor dat het management zijn top-downbenadering niet loslaat. Indien het management in agile-settings zijn top-downbenadering krampachtig overeind houdt, kan dit een negatief effect hebben op het vertrouwen, de intrinsieke motivatie en de teamprestatie. [NERU05, GRUN09, RYAN00]

Het team is onvoldoende zelforganiserend en autonoom

Het vormen en inbedden van zelforganiserende teams is een andere significante randvoorwaarde in agile-werkomgevingen. Het team kan op verschillende manieren zelforganiserend zijn. Allereerst bepaalt het team zelf hoe het zijn doelstellingen gaat behalen (implementatiestrategie). Daarnaast heeft het team de bevoegdheid om zijn leden te selecteren en te ontslaan (zelfselectie, zelfreinigend vermogen). Ook bewaakt het team zelf de kwaliteit en de voortgang van zijn oplevering en stuurt het zelf bij (zelfcontrole en zelfsturing). In werkelijkheid ondervinden teams uitdagingen met het verkrijgen van voldoende mandaat en autonomie om zelforganiserend te zijn.

Onvoldoende skills, werkervaring, kennis en capaciteit

Een hoge mate van autonomie in een scrumteam vereist hooggekwalificeerde teamleden. De leden dienen over de juiste competenties te beschikken om overzicht te kunnen houden en om het projectdoel niet uit het oog te verliezen. De IT-organisatie dient tijdens de teamsamenstelling rekening te houden met een aantal kerncompetenties. Het team moet bijvoorbeeld over de juiste programmering en technische expertise beschikken om het softwareproduct te bouwen. Ook dient het team kennis en praktijkervaring te hebben met het scrumraamwerk. Verder moet het team over effectieve sociale en communicatieve vaardigheden beschikken om met de klant en de stakeholders te interacteren. Daarnaast moet het team de businessprocessen, de verkoopproducten en de organisatie goed begrijpen. De voorgaande beschreven competenties zijn cruciaal voor het succes van een scrumproject. [GOHJ13] In de realiteit ervaren organisaties uitdagingen met het vinden van de juiste competenties voor hun scrumteams. Andere risico’s die zich in agile-werkomgevingen voordoen, hebben te maken met de onbeschikbaarheid van de klant tijdens de iteraties. Verder is het wegtrekken van teamleden ten behoeve van reguliere werkzaamheden een ander capaciteitsrisico. [CHOW08].

Voedingsbodem voor intrinsieke motivatie niet aanwezig

Een andere belangrijke randvoorwaarde in scrumprojecten betreft de intrinsieke motivatie van de teamleden. Een agile-setting dient een veilige en transparante werkomgeving te bieden waarin de teamleden fouten mogen maken, continu leren en een band met elkaar creëren. Zo’n omgeving in combinatie met voldoende autonomie heeft een positieve invloed op de intrinsieke motivatie en de prestatie van de teamleden en hoort gestimuleerd te worden. [RYAN00]

Elementen van beheersingsmaatregelen

Nadat de IT-auditor zijn risicobeoordeling heeft verricht, kan hij de beheersingsmaatregelen identificeren die zijn key-risico’s in zijn onderzoekscontext mitigeren. In figuur 5 worden elementen van beheersingsmaatregelen getoond. Deze figuur vormt een handvat waarmee de IT-auditor de te testen maatregelen kan identificeren. In agile-contexten zal de IT-auditor meer de nadruk leggen op de werking van de kwaliteitscontroles, ceremonies en artefacten die bijdragen aan de empirische procesbesturing (transparantie, inspectie en adaptatie). Verder zal hij tijdens zijn onderzoek meer focussen op de soft controls die uit de agile-principes zijn afgeleid.

Figuur 5: Elementen van beheersingsmaatregelen.

De implementatie van de controle-elementen varieert per organisatiecontext en is afhankelijk van de ‘zuivere’ toepassing van de agile-methode.  Figuur 5 vormt geen norm, maar eerder een handvat waarmee de te testen maatregelen geïdentificeerd kunnen worden. Tijdens de selectie van de maatregelen is de risicobeoordeling van de IT-auditor leidend.

Technieken en meetinstrumenten

In scrumtrajecten zijn veel traditionele (mijlpaal)producten niet meer beschikbaar. Volledig gedocumenteerde requirements, functionele ontwerpen en rapportages zijn bijvoorbeeld niet meer aanwezig. In agile-werkomgevingen waar gebruik wordt gemaakt van tooling voor de vastlegging van validatiemomenten en documentatie, kan de IT-auditor hier informatie uit putten. In agile-settings waar geen tooling wordt gebruikt, zal de IT-auditor minder gebruik kunnen maken van de inspectietechniek voor het testen van de controls. In deze settings zal de IT-auditor meer de observatietechniek en de semigestructureerde interviewtechniek gebruiken. Tijdens het observeren zal de IT-auditor invloed uitoefenen op zijn onderzoeksobject. Deze invloed kan beperkt worden door periodiek aanwezig te zijn. Het bijwonen van meerdere iteraties in verschillende tijdsperiodes is daarnaast waardevol om een beter beeld te krijgen van de iteratieprocessen. In agile-contexten kan de IT-auditor ook meetinstrumenten inzetten om licht te werpen op de soft controls. Vanuit de sociologie en psychologie hebben onderzoekers instrumenten ontwikkeld voor het meten van soft controls. Tabel 3 toont enkele instrumenten die de IT-auditor kan hanteren.

Tabel 3: Enkele meetinstrumenten voor soft controls.

De meerwaarde van de IT-auditor als ‘spiegelaar’

In agile-contexten creëert het management een autonoom werkkader voor het scrumteam. Het team kan binnen dit werkkader zelfstandig opereren, zelf beslissingen nemen en zelfcontrole uitvoeren. Het team is gemotiveerd om de projectdoelstelling op zijn manier te behalen. Het management heeft daarnaast vertrouwen in het team en voert geen managementcontrole uit. Op het moment dat het management in een agile-setting een IT-auditor betrekt en deze in opdracht van het management het team gaat controleren (traditionele IT-audit rol), kunnen fricties ontstaan in het scrumteam. Ten eerste: doordat het management een auditor de opdracht geeft om het team te controleren, geeft het signalen van wantrouwen af. Deze signalen kunnen de vertrouwensband die het management met het scrumteam heeft gecreëerd, negatief beïnvloeden. [GRUN09] Ten tweede: het opleggen van een controle door het management kan een negatief effect hebben op de intrinsieke motivatie van het team. [RYAN00] Ten derde: een audit in opdracht van het topmanagement is een manifestatie van de top-down managementbenadering, terwijl scrumprojecten juist een bottom-up managementbenadering vereisen. Kortom, op het moment dat een IT-auditor in opdracht van het management een scrumteam gaat controleren en een oordeel gaat geven, kan afbreuk gedaan worden aan de soft controls die ingebed zijn in een agile-context (onder andere bottom-up benadering, vertrouwen en intrinsieke motivatie).

In agile-projecten kan een IT-auditor meerwaarde leveren door zijn traditionele rol los te laten. Hij dient zijn rol zo aan te passen dat er geen negatieve invloed is op de soft controls, zoals bottom-up benadering, vertrouwen en intrinsieke motivatie. In agile-contexten kan de IT-auditor dit bereiken door de rol van ‘spiegelaar’ aan te nemen. Met andere woorden: hij voert zijn onderzoek in opdracht van het scrumteam uit. Hij werpt daarnaast licht op de agile-specifieke risico’s, rapporteert zijn bevindingen naar het team, laat het team zien wat hij heeft waargenomen en geeft het team de ruimte om met elkaar in discussie te gaan. Zijn doelstelling is om de feitelijke bevindingen over de beheersing van de softwareontwikkelingsprocessen bij het team terug te leggen, zodat het team kan blijven leren.  Kortom, een IT-auditor dient zijn rol zo passend mogelijk te maken binnen de kaders van de bottom-up managementbenadering.

Conclusie

Dit artikel heeft handvatten aangereikt voor het onderzoeken van agile-softwareontwikkelingsprocessen. Een risicobeoordeling vormt het fundament van de onderzoeksaanpak van de IT-auditor. In agile-settings kan de IT-auditor de risico’s vanuit verschillende invalshoeken beoordelen: organisatorisch, procesmatig, technologisch en mensfactoren. Op basis van zijn risicobeoordeling stelt de IT-auditor vervolgens de maatregelen voor zijn testwerk vast. In agile- contexten zal de IT-auditor meer de nadruk leggen op de werking van de kwaliteitscontroles, ceremonies en artefacten die bijdragen aan de empirische procesbesturing (transparantie, inspectie en adaptie). Verder zal hij zich tijdens zijn onderzoek meer focussen op de soft controls die uit de agile- principes zijn afgeleid. Daarnaast zal een IT-auditor in agile-onderzoekscontexten meer gebruik maken van de observatie- en de interviewtechniek. Voor het onderzoeken van de soft controls kan de IT-auditor ook meetinstrumenten vanuit de sociologie en psychologie gebruiken.

De traditionele rol van de IT-auditor, waarmee hij in opdracht van het management het scrumteam controleert, kan een negatief effect hebben op het scrumteam. In agile-contexten kan een IT-auditor meerwaarde leveren door zijn traditionele rol aan te passen. In agile-contexten kan de rol van de IT-auditor veranderen naar de rol van ‘spiegelaar’. In deze rol voert hij een onderzoek uit in opdracht van het scrumteam. Met andere woorden: hij neemt de beheersing van de agile-processen onder de loep. Hij werpt daarnaast licht op de risico’s, rapporteert zijn bevindingen naar het team en geeft het team de ruimte om met elkaar in discussie te gaan. Zijn doelstelling is om de feitelijke bevindingen aan het team terug te geven, zodat het team kan blijven leren. Kortom, een IT-auditor kan meerwaarde leveren door zijn rol binnen de kaders van de bottom-up managementbenadering vorm te geven.

Literatuur

Agile Manifesto, The Agile Manifesto for software development, 2001, http://www.agilemanifesto.org/, geraadpleegd op: 22-1-2019.

Anwar, F., Kempkes, B., Winterink, J., IT-auditor: assurance provider en bestuurlijke sparringpartner? Audit magazine (2), 2015, pp.22.

Bakker, B., Bree, T., Gijsbers, G, TNO-rapport Quickscan sectoren en ICT-technologieën 2017 (R11422), TNO, 2017, pp. 23-24.

Bociij, P. Chaffey, D., Greasley, A., Hickie, S., Business Information Systems: Technology, development an management fort he e-business. Harlow: Pearson, second Edition, 2003, pp. 307-309

Cao, L., Ramesh, B., Agile requirements engineering practices: An empericial study. IEEE software, 25 (1), 2008, pp. 60-67

Chow, T., Cao, D., A survey study of critical success factors in agile software projects. The Journal of Systems and Software 81, 2008, pp. 961–971.

Gerrits., T., Groot, R., Venneman, R., Agile guide voor wendbare organisaties. Van haren, 2013, pp. 109

Goh, J., Pan, S., Zuo, M., Developing the Agile IS Development Practices in Large-Scale IT Projects: The Trust Mediated Organizational Controls and IT Project Team Capabilities Perspective, Journal of the Association for Information Systems, 14(12), 2013, pp. 722-756.

Grund, C., Harbring, C., Trust and control at the workplace: evidence from representative samples of employees in Europe. Discussion paper series (4297). International research center: Institute for the study of Labor, 2009.

Karasek, R., Brisson, C., Kawakami, N., Houtman, I., Bongers, P., & Amick, B., The Job Content Questionnaire (JCQ): An Instrument for Internationally Comparative Assessments of Psychosocial Job Characteristics. Journal of Occupational Health Psychology, 3(4), 1998, pp. 322-355.

Ktata, Q., Levesque, G., Agile development: Issues and avenues requiring a substantial enhancement of the business perspective in large projects. C3S2E ’09 Proceedings of the 2nd Canadian Conference on Computer Science and Software Engineering, 2009, pp. 59-66.

Moet, B., Dingsøyr, T., Dyba, T., A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology 52, 2010, pp. 480–491.

Nerur, S., Mahapatra, R., Mangalaraj, G., Challenges of migrating to agile methodologies. Communications of the ACM 48 (5), 2005, pp., 73–78.

Qumer, A., & Henderson-Sellers, B., An evaluation of the degree of agility in six agile methods and its applicability for method engineering. Information and Software Technology, 50(4), 2008, pp. 280–295.

Royce, W.,W., “Managing the Development of Large Software Systems” in: Technical Papers of Western Electronic Show and Convention (WesCon), August 25–28, 1970, Los Angeles, USA

Ryan, R. M., Deci, E.,l., Self-determination theory and the faciliation of intrinsic motivation, social development, and well-being. American Psychologist 55 (1), 2000, pp., 68-78.

Standish Group, The Chaos report 2011-2015, The Standish Group International Inc., 2015.

Schwaber, K., Sutherland, J., The Scrum guide: the final guide: the rules of the game. Offered for license under the Attribution Share-Alike license of Creative Common, 2017, pp 4-18.

Stettina, C., Werner, H., Five Agile Factors: Helping Self-management to Self-reflect, Book series Communications in computer and information science (172), 2011, pp. 84-96.

Tanner., M., Willingh, U., Factors leading to the success and failure of agile projects implemented in traditionally waterfall environments. In: Human capital without borders: knowledge and learning for quality of life, 2014, pp. 698.

Version one, 12th annual state of agile report, Collabnet Versionone, 2017, pp. 1-16.

Noten

Burndown-chart: een grafische presentatie van de resterende hoeveelheid werk aan user storiesafgezet tegen de resterende tijd.

Velocity-chart: geeft de voortgang van het team weer in de som van de op voorhand geschatte hoeveelheid werk van het totaal aantal user storiesdat is afgerond in de betreffende sprint.

Pair programming: een praktijk die er van uitgaat dat twee programmeurs samen werken aan hetzelfde stuk code. De eerste programmeur is degene die het toetsenbord bedient en de code daadwerkelijk schrijft, in principe is zijn rol dus gelijk aan die van een solo-programmeur. De tweede programmeur heeft een controlerende en vooruitdenkende taak. Terwijl de code geschreven wordt, denkt hij dus al na over de te nemen stappen. Bovendien worden fouten snel opgemerkt en verwijderd. Regelmatig wisselen de twee programmeurs van rol, zodat sterke punten van beide programmeurs benut kunnen worden.

Geen categorie

José Luis Sanchez Mejia | MSc RE CICA EMITA CISA

José Luis heeft de afgelopen acht jaren IT-auditopdrachten bij financiële dienstverleners en grote accountantskantoren uitgevoerd. Hij heeft daarnaast onderzoek verricht naar Agile-assessments. Hij werkt momenteel als interim IT Audit consultant bij ABN AMRO via INTI Solutions.