Spotlight | Interne beheersing en IT
Agile Scrum vraagt om een vernieuwing van de controleaanpak Martijn van Zomeren - Risk Assurance, Assurance
Steeds meer organisaties zetten de Agile Scrum-methodiek in op veranderende marktbewegingen. Agile Scrum vraagt om een vernieuwing van de controleaanpak. Hiervoor zijn nog geen referentiekaders beschikbaar. In dit artikel worden enkele handvatten voor de controle gegeven.
Samenvatting De markt beweegt door de digitalisering steeds sneller. Projecten en programma’s zijn een veelvuldig gebruikt middel voor organisaties om effectief in te spelen op deze ontwikkelingen. De Agile Scrumprojectmethodologie heeft als uitgangspunt dat specificaties kunnen veranderen gedurende het project en leidt tot verkorting van de time to market van nieuwe IT-functionaliteit. Het uitvoeren van een controle is bij uitstek een effectief middel om inzicht in de risico’s en de interne beheersing van een project te krijgen. Het accent van de controle van Agile Scrum ligt niet zozeer op de output van elke individuele ontwikkelstap, maar meer op de beoordeling van het ontwikkelproces, de organisatorische inrichting, het team, en op de ‘softe’ in plaats van de ‘harde’ interne-beheersingsmaatregelen.
1. De digitale revolutie als basis voor adoptie van Agile Scrum als projectmethodologie Mede door de toenemende digitalisering worden organisaties gedwongen om hun businessmodellen en bedrijfsprocessen steeds vaker en sneller te veranderen of te verbeteren. De Agile Scrum-methode is hier uitermate geschikt voor. Agile Scrum heeft namelijk als uitgangspunt dat specificaties gedurende het ontwikkelproces moeten kunnen veranderen en dat in zeer korte doorlooptijd nieuwe kwalitatief hoogstaande functionaliteiten in productie genomen moeten kunnen worden. De werkwijze in een notendop: de verschillende expertisegebieden die zijn vereist voor een succesvol project, zijn binnen één team door verschillende teamleden vertegenwoordigd. Het team werkt met elkaar samen van ‘sprint’ naar ‘sprint’. Dit zijn steeds korte iteraties, van een periode van één tot vier weken, waarin het team een kant en klaar product oplevert, naar de wensen - specificaties - van de klant, als onderdeel van het totale project. Aan het begin van elke sprint bepaalt het team de hoofddoelstelling van die sprint en de taken en verantwoordelijkheden van elk teamlid. Aan het einde geven de teamleden in een eerlijke communicatie aan of de subdoelstelling gehaald is, en trekt het team lessen uit de afgelopen sprint, zodat de teamprestaties continu verbeteren. Interne beheersing en IT
23
Agile Scrum geschikter voor snel veranderende wereld dan de traditionele watervalmethodieken Tot nu toe waren veel systeemontwikkelingsprocessen gebaseerd op de traditionele watervalmethode. De watervalmethode is een beheerste methode voor de ontwikkeling van nieuwe applicaties en functionaliteiten, waarbij stap voor stap door verschillende functies van de originele specificaties (technisch ontwerp, functioneel ontwerp, datamodel, ontwikkelen, testen) naar inproductiename wordt toegewerkt. Het resultaat van de voorgaande stap is de input voor de daaropvolgende stap, waarbij de oorspronkelijke specificaties als uitgangspunt worden gehanteerd voor validatie van de juiste uitvoering van de processtappen. Dit maakt het watervalproces een goed beheersbaar en te controleren proces, waarbij de verschillende functionele expertises gescheiden van elkaar aan een deel van de totale eindoplossing werken. Bezwaar van deze methode is dat de communicatie tussen de verschillende functies binnen het totale ontwikkelproces beperkt is, en er veel overdrachtsmomenten nodig zijn voordat de functionaliteit in productie kan worden genomen. Agile Scrum Agile Scrum heeft juist als uitgangspunt dat specificaties gedurende het ontwikkelproces moeten kunnen veranderen. Agile Scrum tracht op deze wijze de silo’s, het gebrek aan communicatie en het teveel aan overdrachtsmomenten te doorbreken. Per iteratie, sprint, wordt door het multifunctionele team werkbare IT-functionaliteit opgeleverd. Het team is zelfsturend en gericht op het continu evalueren en leren hoe effectiever kan worden samengewerkt in het belang van de klant. De uitgangspunten van Agile om dit te bewerkstelligen zijn in 2001 verwoord in het Agile Manifesto: • Personen en interacties zijn belangrijker dan processen en tools. • Werkende bruikbare sofwarefunctionaliteit is belangrijker dan uitgebreide documentatie. • Samenwerking met de klant levert meer op dan onderhandelingen over het contract. • Effectief kunnen omgaan met verandering is belangrijker dan strikt het oorspronkelijke plan volgen. Vanuit een controleperspectief zijn veelgehoorde bezwaren ten aanzien van Agile Scrum dat teams te veel vrijheid krijgen, waardoor de beoogde reikwijdte en baten van de eindoplossing niet overeenkomen met de wensen van de organisatie. Door de beperkte documentatie van de tussenliggende producten is het lastiger voor iemand van buiten het team inzicht te krijgen in de kwaliteit en voortgang van de te realiseren functionaliteit, en de samenhang met de systeemontwikkeling die door andere teams in dezelfde keten plaatsvindt, te bewaken.
Figuur 1. Softwareontwikkeling: watervalproces versus Scrum-proces Figuur 1 Softwareontwikkeling: watervalproces versus Agile Scrum-proces
Maand 8
Maand 6
Maand 4
Maand 2
Start
Watervalmethode
Eisen Ontwerp Ontwikkeling Validatie
Agile Scrum
Sprint 1
Eisen
Ontwerp
Documents
Documents
Sprint 2
Ongevalideerde Code
Software
Sprint ..x
``` Software Software is:
Software
Software
25% Compleet
Software
Software
50% Compleet
Software
Software
75% Compleet
Software 100% Compleet
PwC
2. Controle door IT-auditor geeft inzicht in risico’s en beheersing van het project Omdat een Agile Scrum-project grote consequenties kan hebben voor de interne beheersing, de financiën, het duurzame concurrentievermogen, en de motivatie van het personeel, is het essentieel dat het slaagt. De IT-auditor geeft inzicht in de risico’s en de beheersing van het project. De context waarbinnen Agile Scrum wordt toegepast is essentieel voor het kunnen duiden van de
24
Spotlight Jaargang 22 - 2015 uitgave 2
risico’s die specifiek gelden voor het betreffende controleobject. De opsomming in figuur 2 geeft een vertrekpunt voor de risicoanalyse als fundament van de controleaanpak. Agile Scrum onderscheidt een aantal processtappen, rollen en instrumenten die aanknopingspunten bieden voor het nader identificeren van interne-beheersingsmaatregelen die moeten worden opgenomen in de reikwijdte van de controleaanpak (zie figuur 3).
1
Figuur 2 Voornaamste risico’s Agile Scrum-project Risico 1
Het senior management van de organisatie is onvoldoende betrokken bij de ontwikkeling van het project. Hierdoor draagt de opgeleverde functionaliteit niet bij aan de realisatie van de businesscase.
2
Business value wordt niet juist toegekend aan de specificaties, waardoor in de prioritering van de ontwikkeling onvoldoende rekening wordt gehouden met de afhankelijkheden die tussen de specificaties bestaan om een werkende functionaliteit op te leveren.
3
Teams krijgen te veel vrijheid, waardoor de beoogde reikwijdte en baten van de eindoplossing niet overeenkomen met de specificaties van de organisatie.
4
De door het Scrum-team opgeleverde functionaliteit voldoet niet aan de conventies van de organisatie met betrekking tot de architectuur, het datamodel en de gebruikte communicatieprotocollen.
5
De kwaliteit van het ontwikkelingsproces is niet toereikend, wat leidt tot veel rework en inefficiënties.
6
De organisatie heeft onvoldoende zicht op de inhoudelijke voortgang en kwaliteit van de ontwikkeling om tijdig bij te kunnen sturen in samenhang met andere ontwikkelingstrajecten.
7
De documentatie is niet toereikend om de opgeleverde functionaliteit in de toekomst goed te kunnen beheren/ onderhouden.
8
In het ontwikkelingsproces is onvoldoende aandacht voor application life cycle management, waardoor beheerskosten na inproductiename kunnen oplopen.
9
De omringende organisatie is niet voldoende klaar/volwassen om de Agile Scrum-methodiek effectief toe te kunnen
passen, waardoor het management interventies pleegt die afbreuk doen aan het realiseren van zelfsturende highFiguur 3. Het Scrum-proces performing Scrum-teams.
Figuur 3 Het Agile Scrum-proces De Product Owner en het Scrum-team verfijnen samen de gewenste functionaliteiten in de backlog en het team ontwerpt, bouwt en test functies
De Product Owner prioriteert gewenste functionaliteiten op basis van toegevoegde waarde voor de organisatie
A B C D E
Ontwerp
A
A
Test
DEMO
B
Ontwerp
Sprint backlog
Product backlog
Code
De Product Owner reviewt en geeft goedkeuring op datgene wat het team gebouwd heeft
B
Code
Fragment van de applicatie
WEB A B APP DB
Test
2-4-wekelijkse iteraties Sprints
Werkende software
Door de risico’s te identificeren kan de organisatie, met behulp van de AO/IC-beginselen van Starreveld, ook interne-beheersingsmaatregelen ontwerpen die deze risico’s mitigeren of zelfs weg kunnen nemen.
• User stories Vervolgens vertaalt het Scrum-team de specificaties naar user stories: een praktische beschrijving van de te ontwikkelen functionaliteit waarmee invulling wordt gegeven aan de door de klant gestelde specificaties.
3. De processtappen van Agile Scrum
• Sprint backlog Het Agile Scrum-proces wordt opgedeeld in iteraties van twee tot vier weken, de zogenaamde sprints. Het team bepaalt tijdens de sprintplanning welke user stories in de aankomende sprint zullen worden ontwikkeld, en verwerkt de betreffende user stories in de sprint backlog. Gedurende de sprint worden voor deze user stories op iteratieve wijze het ontwerp-, ontwikkel- en testproces doorlopen, en wordt werkbare functionaliteit opgeleverd.
De processtappen van de Agile Scrum-methodiek zien er als volgt uit: • Product backlog Het Scrum-team registreert en prioriteert de specificaties (wensen) van de organisatie in een product backlog, een overzicht van de specificaties die nog door het team moeten worden ingevuld.
Interne beheersing en IT
25
26
Spotlight Jaargang 22 - 2015 uitgave 2
• Eindproduct Als het product/de functionaliteit, zoals verwoord in de user story, klaar is, wordt dit aangeboden aan de Product Owner (de klant, die als zodanig onderdeel is van het Scrum-team). Deze bepaalt of de gerealiseerde functio naliteit voldoet aan de door de organisatie gestelde acceptatiecriteria, en of deze werkt. • Inproductiename Na goedkeuring van de Product Owner wordt de betreffende functionaliteit in productie genomen.
4. Functiescheiding binnen de rollen van Agile Scrum Naast deze goederenbeweging is er ook een duidelijke functiescheiding tussen de verschillende rollen binnen Scrum. • De Product Owner heeft een beschikkende functie De Product Owner is de klant. Hij is verantwoordelijk voor het melden en prioriteren van de specificaties van de organisatie in het licht van de bedrijfsdoelstellingen en de beoogde baten in de businesscase. De Product Owner zorgt voor de acceptatie van de door het ontwikkelteam opgeleverde functionaliteit voorafgaand aan inproductie name. • Het team heeft een uitvoerende functie Het team is verantwoordelijk voor het ontwikkelen en testen van de specificaties zoals die door de Product Owner (de klant) worden aangereikt, conform de meegegeven (kwaliteits)standaarden en eisen. Het team heeft niet de mogelijkheid om de gerealiseerde functionaliteit te accepteren en in productie te nemen. In de bovengenoemde rolverdeling van de Product Owner en het team is de vereiste scheiding tussen ontwikkeling en productie effectief gerealiseerd. • De Scrum Master heeft een registrerende en faciliterende functie De scrummaster helpt het team bij de effectieve uitvoering van het ontwikkelproces. Hij vervult geen inhoudelijke rol, maar wel een belangrijke rol in de juiste en volledige registratie van de uit te voeren taken en de bijbehorende status. Op basis van deze primaire registratie kan de scrummaster het team inzicht geven in de kwaliteit en effectiviteit van zijn functioneren. Daarnaast heeft de scrummaster de taak om organisatorische belemmeringen voor het team om effectief te kunnen functioneren, weg te nemen. Indien bovenstaande drie rollen als zodanig effectief worden ingevuld, is de vereiste functiescheiding tussen de beschikkende, de registrerende en de uitvoerende rol gerealiseerd. Alleen de controlerende functie moet dan nog worden ingevuld. • De controlerende functie In het uitgangspunt van een zelfsturend multidisciplinair
high performing team, voert het team allereerst zelf een belangrijk deel van deze controlerende functie uit. Zo hoort de Quality Control functie deel uit te maken van het team. Het team draagt ook de verantwoordelijkheid om gedurende het ontwikkelingsproces te blijven valideren of het proces volledig is gevolgd en of er wordt voldaan aan alle vereisten in de ‘Definitions of Ready’ en ‘Definitions of Done’ (zie kader). Die checks moeten uitgevoerd zijn voordat het team een user story oplevert aan de Product Owner ter acceptatie. De laatste stap in het Agile Scrumontwikkelproces is de evaluatie (retrospectief) door het team. In de evaluatie bespreekt het team wat goed ging en wat beter kan en hoe die verbetering vervolgens gerealiseerd moet worden.
Definition of Ready: criteria waaraan voldaan moet worden voordat een ‘product increment’, de user story, is afgerond (lees: ‘Done’), en mag worden meegeteld in de sprintresultaten van het team. Definition of Done: criteria waaraan de beschrijving van een user story moet voldoen voordat de betreffende user story opgenomen mag worden op de sprint backlog voor de aankomende sprint.
5. Informatie over status en kwaliteit van proces en product essentieel voor leercyclus Voor een effectieve evaluatie is goede informatievoorziening essentieel om waar nodig bij te kunnen sturen. Naast het meten van de Velocity en Burndown (zie kader) van het team, zijn ook het aantal fouten, de omvang van de reparatiewerkzaamheden, en het aantal operationele verstoringen na inproductiename relevante indicatoren om een beeld te krijgen van de voortgang en kwaliteit van het team. Al deze informatie wordt pas relevant als het team, al dan niet geholpen door het management, de nodige consequenties en acties aan deze informatie verbindt. Zoals eerder is vermeld, zijn Scrum-teams zelfsturend en gericht op het continu leren en verbeteren van de teamprestatie in het belang van de klant. In dat kader zijn cultuur, gedrag en leiderschap zeer belangrijke softe interne-beheersingsmaatregelen in een effectief en efficiënt Agile Scrum-proces. Het uitvoeren van een onafhankelijke controle of Quality Assurance-toets kan in positieve zin bijdragen aan het versterken van deze interne-controlecyclus.
Velocity: geeft de voortgang van het team weer in de som van de op voorhand geschatte hoeveelheid werk van het totaal aantal user stories dat is afgerond (lees: ‘Done’) in de betreffende sprint. Burndown chart: is een grafische presentatie van de resterende hoeveelheid werk aan user stories afgezet tegen de resterende tijd. Deze chart wordt gebruikt om de voortgang te meten en te voorspellen wanneer alle werkzaamheden zijn afgerond.
Interne beheersing en IT2727
Figuur 4 Interne-beheersingsmaatregelen Agile Scrum-proces als basis voor de controle Controle-elementen Scrum Organisatorisch • samenstelling van het team (multidisciplinair, ervaren ontwikkelaars, klant aan tafel, Quality Control) • SMART geformuleerde businesscase met breed draagvlak in de organisatie • Product Owner met voldoende kennis en mandaat toewijzen aan project • Scrum is door organisatie beschreven (minimaal: organisatieconventies, processen, rollen, taken, bevoegdheden, verantwoordelijkheden, mijlpalen, afstemming op de organisatie) • data-, architectuur- en codingconventies • heldere governancestructuur met op actie gerichte rapportages/informatievoorziening • training en begeleiding/coaching team in uitvoering van Scrum • op elkaar afgestemde en zo veel mogelijk geautomatiseerde ontwikkel-, test-, implementatie-, en beheerprocessen • geïmplementeerd kwaliteitsmanagementsysteem met inzicht in de belangrijkste indicatoren voor het meten van de voortgang en kwaliteit van het Scrum-project • cultuur en gedrag die gericht zijn op het continu valideren, evalueren en verbeteren van teamprestaties Procesmatig • vooraf gedefinieerde vastomlijnde time boxes per sprint (drie tot vijf weken), waarbinnen de gehele ontwikkelcyclus wordt afgerond • Scrum-team volledig toegewijd aan het project • de rollen van facilitator, uitvoerend team en Product Owner worden gescheiden gehouden • Definition of Ready en Definition of Done actief gehanteerd voor validatie van de kwaliteit van user stories en deliverables, en bevatten organisatorische vereisten ten aanzien van de AO/IC • user cases/stories worden voorafgaand aan elke sprint vastgesteld (geen changes tijdens de sprint) • Design to Budget-principe voor sprintplanning toegepast, leverbetrouwbaarheid van het team gemonitord • release na elke sprint van user stories ‘Done’ na vereiste testings en akkoord van de Product Owner • evaluatie na elke sprint aan de hand van het kwaliteitsmanagementsysteem om verbeteracties te duiden Technologisch • projectadministratiesoftware (Jira, Clarity, TFS) geïmplementeerd voor het monitoren van de voortgang • OTAP-scheiding geëffectueerd (Ontwikkel, Test, Acceptatie, en Productie) • geïmplementeerd Continuous Deployment-mechanisme • geautomatiseerde testing ingericht op basis van de systeemcode • geïmplementeerd Continuous Integration-mechanisme • schaalbaar distribueerbare infrastructuur die ‘container deployment’ mogelijk maakt • configurationmanagement en ‘deployment tooling’ aanwezig voor actief en geautomatiseerd versiebeheer
6. Interne-beheersingsmaatregelen van Agile Scrum als aanknopingspunten controleaanpak Met de identificatie van de belangrijkste risco’s en elementen van de interne beheersing van een Agile Scrum-project is een belangrijke basis gelegd voor het bepalen van de controleaanpak. De specifieke reikwijdte en risico’s van het controleobject vormen de basis om de juiste focus in de controleaanpak te brengen, en vervolgens de aanpak verder te operationaliseren in de te testen interne-beheersingsmaatregelen en de te hanteren testtechnieken. Figuur 4 geeft een overzicht van de interne-beheersingsmaatregelen van het Agile Scrum-proces. Op basis hiervan kan de controleaanpak gevormd worden.
7. Controleaanpak Agile Scrum vraagt om juiste balans tussen harde en softe interne-beheersingsmaatregelen We zien naast ‘harde’ interne-beheersingsmaatregelen, zoals de juistheid en volledigheid van Definition of Done, ook meer ‘softe’ interne-beheersingsmaatregelen terugkomen, zoals de daadwerkelijke toepassing van de Definition of Done door de Product Owner als basis voor 28
Spotlight Jaargang 22 - 2015 uitgave 2
acceptatie van de opgeleverde systeemfunctionaliteiten, of de wijze waarop de gemeten voortgang en kwaliteit van de teamprestaties actief wordt gebruik als evaluatieen verbeterinstrument. Vaak zijn de harde interne-beheersingsmaatregelen (zoals beleid, procesdefinitie, conventies) wel aanwezig, maar verbindt het team of het management daar geen harde consequenties aan wanneer de resultaten tegenvallen. Soms simpelweg omdat de informatievoorziening daartoe ontbreekt in de organisatie. Een bepaalde mate van registratie en documentatie, beide harde interne-beheersingsmaatregelen, is dus wel degelijk nodig om deze informatievoorziening te kunnen realiseren. Het excuus dat documentatie niet nodig is omdat ‘dit is Agile Scrum is en dat werkt anders’ gaat niet op als je niet in staat bent om de kwaliteit en progressie te evalueren en uiteindelijk een systeem moet kunnen beheren. De kracht van Agile Scrum zit in de iteratieve processen en het hanteren van de juiste mix van harde en softe interne-beheersingsmaatregelen gericht op het continu valideren, evalueren en verbeteren van de geleverde prestaties. Als deze iteratieve cyclus effectief wordt toegepast, worden risico’s en eventuele tekortkomingen in een vroegtijdig stadium geïdentificeerd en door middel
De controlerende functie draagt als speler van het team bij aan het leerproces in het team Doordat Agile Scrum werkt met kortcyclische iteratieve leerprocessen kunnen risico’s met betrekking op het gewenste eindresultaat van een project, in een vroegtijdig stadium onderkend en aangepakt worden. Om dit te kunnen bewerkstelligen, doet Agile Scrum onder meer een beroep op de controlerende functie om onafhankelijk de kwaliteit van het stelsel van internebeheersingsmaatregelen te toetsen als input voor het leerproces van het team.
van acties aangepakt. De auditor doet er dus goed aan om in zijn controleaanpak het accent te leggen op de juiste balans tussen harde en softe interne-beheersingsmaatregelen en de effectiviteit daarvan binnen de iteratieve processen van Agile Scrum. Meer aandacht voor het proces en de softe interne-beheersingsmaatregelen daarbinnen brengt automatisch een verschuiving van inspectie naar observatie als testtechniek met zich mee. Deze verschuiving daagt de auditor uit om vanuit zijn onafhankelijke positie feitelijke observaties aan het team en de organisatie terug te geven met betrekking tot de effectiviteit van de interne beheersing en de iteratieve leercyclus van het team.
8. Conclusie: accent controle op proces, team, softe interne-beheersingsmaatregelen en observatietechnieken In de huidige tijd van digitalisering is de vaardigheid om in kort tijdsbestek effectief in te kunnen spelen op de veranderende klantbehoefte essentieel voor bedrijven
om te overleven. De Agile Scrum-methodologie is er bij uitstek op gericht om met een zelfsturend multifunctioneel team via korte iteraties nieuwe functionaliteiten te kunnen realiseren. Het uitvoeren van een controle op een Agile Scrum-project kan een positieve bijdrage leveren aan de effectiviteit van de interne beheersing van een Agile Scrum, mits de auditor op passende wijze aandacht besteedt aan de specifieke risico’s en controlemaatregelen van deze methodologie. De goederenbeweging, functiescheiding, en het zelflerende vermogen van het Scrum-team zijn belangrijke aandachtspunten voor de auditor, waarbij de organisatorische inbedding inclusief de cultuur en het gedrag moeten zorgen voor de juiste voedingsbodem voor effectieve toepassing van Agile Scrum. Dit vraagt in de controleaanpak een verschuiving: • van uitkomst meer naar het proces en het team; • van harde naar meer softe interne-beheersingsmaat regelen; en • van inspectietechnieken naar observatietechnieken.
Interne beheersing en IT
29
