Controleprocessen dienen afgestemd te worden op agile werken

Het werken volgens Agile staat hoog op de agenda van de bestuursleden bij banken. Het succes van de banken hangt sterk af van de mate waarin zij in staat zijn zichzelf te vernieuwen en (zichtbare) toegevoegde waarde aan haar klanten te bieden. Hierin is de time-to-market  van IT ontwikkelingen van doorslaggevend succes, omdat de nieuwe producten/services direct afhankelijk zijn van IT. Het werken volgens Agile vergt een nieuwe manier van besturen (organiseren, coördineren, belonen en controleren).  In dit artikel gaat First Consulting in op de impact die Agile heeft op het beheersbaar houden van de IT ontwikkelingen binnen een bank.

Wat is agile?
Agile is in de basis ontstaan als een software ontwikkelmethodologie. Het is een manier om sneller, beter en goedkoper toegevoegde waarde aan klanten te bieden door op een andere manier te werken. Het gaat daarbij uit van principes als: beslissingen nemen op basis van economische redenen (business case), kort cyclisch ontwikkelen, werken in kleine vaste teams, denken vanuit een waardeketen en gedecentraliseerde besluitvorming (Bron: SAFE).

De Agile Way of Working heeft de afgelopen jaren haar succes laten zien in Sillicon Valley en begint in Nederland snel door te dringen. Zover zelfs dat ook de banken (traditioneel conventioneel ingericht, waarin het credo controle is beter dan vertrouwen een belangrijke plek inneemt) ook bezig zijn om zichzelf opnieuw in te richten.

De voordelen van agile zijn alom. De belangrijkste voordelen zijn het vergroten van de betrokkenheid van de business in de software ontwikkeling en het kort cyclisch richten op ontwikkelingen die direct toegevoegde waarde leveren. Echter, om het Agile werken te adopteren is het nodig om de organisatie anders in te richten. Een inrichting, waarbij het management ook de traditionele ‘waterval’ gedreven aanpak en sturing durft los te laten.

De traditionele manier van softwareontwikkeling is sterk gericht op het beheerst/gecontroleerd doorvoeren van wijzigingen. Dit aan de hand van een waterval gerichte methode.

Hierin worden allereerst de wensen/eisen opgehaald bij de business (requirements). Deze worden bevroren. Om vervolgens de ontwikkeling tot in detail te plannen. Daarbij worden conform Prince2 (projecten) en MSP (programma’s) governance boards ingericht om sturing te geven op de voortgang. Het credo hierin is dat sturing plaatsvindt op basis van excepties en dat het budget, tijd, middelen en kwaliteit vooraf is gedefinieerd. Een projectmanager wordt aangesteld om dit te managen en hierover gedurende de bouw te rapporteren in de stuurgroep. De betrokkenheid van de stakeholders (leveranciers, business en executive management) beperkt zich tot de periodieke stuurgroepen.

Afhankelijk van de aard van het project is er vooraf betrokkenheid van risicomanagement. Dit is voornamelijk gericht op het te leveren product. Daarnaast is er een (interne) audit dienst, gericht op de projectmanagement beoordeling op de kwaliteitsaspecten als geld, organisatie, tijd, kwaliteit, informatie, risicomanagement of een soort quality assurance rol, gericht op het beoordelen van de toekomstige inrichting en risico's. Deze aanpak heeft zich in het verleden vanuit een control/risicoperspectief redelijk bewezen. Vanuit een business case perspectief veel minder. De ontwikkeltijd van deze projecten kan meerjarig zijn en ondertussen kan de behoefte zijn gewijzigd. Hierdoor zijn veel ambitieuze projecten nooit gerealiseerd.

Agile gaat uit van andere principes. Centraal hierin staat het werken in multidisciplinaire teams, bestaande uit IT/security specialisten en business medewerkers. Hier wordt in korte cycli producten ontwikkeld en in productie gebracht (om de benefits direct te realiseren). De resultaten en risico’s worden daarmee veel sneller inzichtelijk, wat tijdige bijsturing mogelijk maakt. Hierdoor worden onnodig hoge kosten en afschrijvingen vermeden.

Het belang van agile zal de komende jaren verder toenemen door veranderende marktomstandigheden, alles moet sneller en beter. Hiermee worden bedrijven voor het dilemma gesteld van snelheid versus control.

Bij een bank speelt dit nog veel sterker dan in andere typen organisaties. Een bank kan slechts functioneren indien zij het vertrouwen geniet van het publiek. Dit vertrouwen kan door onbetrouwbare informatieverstrekking ernstig worden geschaad. Aan de betrouwbaarheid van de systemen (administratie) moeten daarom hoge eisen worden gesteld. Het stelsel van interne en externe controle is dan ook iets dat veel aandacht behoeft (2B). Alleen maar focussen op snelheid en in een soort van eeuwige bèta omgeving opereren is iets dat momenteel nog niet breed maatschappelijk wordt geaccepteerd. Al lijken de ontwikkelingen vanuit de Fintech wereld hierin verandering te brengen.

De Agile ontwikkelmethode biedt hierin een nieuw perspectief. Deze gaat uit van principes als:

• Interactie/communicatie en samenwerking van de business en IT, in kleine teams en minder op afstand werken en op basis van omvangrijke processen;
• Gericht op werkende software (met waarde voor de klant) en minder op de papieren waarheid;
• Flexibel en transparant inspelen op een veranderende behoefte en niet op het rechtlijnig volgen van het plan.

De benoemende principes hebben het ultieme doel de time-to-market te vergroten door het opleveren van goed werkende software. De interactie en kwaliteit van samenwerking is daarmee belangrijker geworden, dan het vooraf in detail uitwerken van het ontwerp en strikt volgen van alle processen en procedures. Hiermee is een nieuw paradigma ontstaan, dat niet meteen aansluit bij de manier waarop wordt aangekeken tegen risicomanagement binnen banken. Deze zijn vaak (gedwongen) om ‘rule based’ invulling te geven aan hun processen.

Daarbij komt dat de regeldruk binnen banken de afgelopen jaren alleen maar is toegenomen en daarmee ook de noodzaak om snel en transparant te kunnen rapporteren. De toezichthouders (intern/extern) zien zich nog altijd genoodzaakt te kijken naar de opzet, het bestaan en de werking om zekerheid te verkrijgen over de kwaliteit van de IT organisatie. Hierin speelt de al oude vraag of een maatregel effectief (werking) kan zijn als deze niet formeel is beschreven (opzet). Oftewel kan een IT omgeving worden beheerd, zonder dat de noodzakelijke procedures en richtlijnen op schrift staan. De dagelijkse praktijk laat zien dat sterk wordt gesteund op dergelijke principes. Niemand wil uiteindelijk in gebreken worden gesteld op het moment dat het misgaat (risicomijdend in verband met imagoschade, claims, etc.).

Hoe kan de snelheid dan toch toenemen, zonder de controle te verliezen? 
In de praktijk blijkt dat snelheid gerealiseerd kan worden door de bureaucratie (gelaagdheid) en regeldruk (aan checks & balances) meer in balans te brengen met de mogelijkheid om te ondernemen. Dit betekent dat de processen worden aangepast. En dat het ‘oude’ gedrag van het management rondom beheersing mee verandert. De eerste stap hierin is het creëren van een ‘sense of urgency’ waarin een gemeenschappelijk beeld ontstaat over de huidige situatie en de veranderingen die benodigd zijn. Vervolgens moet ruimte worden gemaakt om ‘bottum-up’ veranderingen te gaan doorvoeren, waarin het management vertrouwen geeft en kaders waarbinnen dit mag plaatsvinden.

De paradox is dat wanneer de Agile Way of Working succesvol wordt opgenomen in de organisatie, de risico’s ook verminderen. Een vermindering van risico’s aan de IT zijde (meer beheerste ontwikkeling) en aan de business zijde (snellere product/dienst introducties en feedback van klanten).

Maatregelen om controle te behouden
Om een succesvolle agile transformatie door te maken is het van belang om de huidige controle raamwerken aan te passen op het agile gedachtegoed. Belangrijke (nieuwe) aandachtspunten hierin zijn:

• Zichtbare commitment vanuit de business om de Product Owner rol in te vullen;
• Proactief meenemen van de toezichthouders in de Agile Way of Working;
• Geautomatiseerde tooling (E2E) om het proces te auditen en gegevensgerichte analyses uit te voeren;
• Eenduidig en transparant de agile ontwikkelmethode inrichten (steunen op het proces) en eigenaar benoemen;
• Betrokkenheid van de support afdelingen in het proces borgen. Dit betekent dat de architect, securityspecialist meer betrokken raakt bij het project. Dit om vertragingen en rework achteraf te vermijden;
• Medewerkers opleiden en trainen in alle systeemontwikkelonderdelen (niet alleen specialisatie, maar ook generalisatie) en continu leren en verbeteren;
• Lessons learned actief delen tussen verschillende agile teams (business en IT);
• KPI’s opstellen rondom kwaliteit en snelheid van levering;
• Toepassen van test en acceptance driven development en het automatiseren daarvan;
• Onafhankelijke rol van de tester borgen in het proces;
• De juiste criteria in de definition-of-done en evaluatie hiervan vastleggen na elke oplevering en goedkeuring van benodigde aanpassingen;
• Teambelang in plaats van individuele KPI’s: gezamenlijk streven naar het creëren van klantwaarde. Iedereen heeft hetzelfde doel voor ogen en werkt met elkaar samen.
• Het aanpassen van de processen/controle raamwerken (manier van besturing) is van groot belang om agile succesvol in te voeren. Wanneer dit niet gebeurt worden de ondersteunende processen als blockers gezien, in plaats van als enablers voor succes.