Agile Scrum vraagt om een ver nieuwing van de

Spotlight | Interne beheersing en IT
Agile Scrum vraagt om een
ver­­nieuwing 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 observatie­­­­technieken.
Interne beheersing en IT
29