In deze blog gaat inspearit in op een wijze waarop door onafhankelijke toetsing (audit) een agile ontwikkeling “in control” kan blijven.

Intro

In de traditionele waterval-ontwikkelmethode zijn de momenten van controle, testen en audit duidelijk aanwijsbare punten in de overdracht van het voortbrengingsproces naar het instandhoudingsproces.

Voor de overdracht tussen deze fases wordt door de beheer- en gebruikersorganisatie een “garantie” vanuit het ontwikkelproject gevraagd dat alle gevraagde functionaliteit werkt zoals is gevraagd. Deze vastlegging op basis van de ontwikkeling en uitgevoerde testen zijn te beoordelen door een QA rol (of audit functie). Dit gedurende het traject en bij de overdracht.

Een ontwikkeltraject op basis van een agile ontwikkelmethode kent na elke cyclus of fase een (deel)oplevering. Hierbij is de vraag of elke deeloplevering ook volledig is uitgevoerd in lijn met de business case die ooit aan de basis van de ontwikkeling heeft gestaan.

Agile project governance

Elke fase in een agile project bevat stappen die qua inhoud gelijk zijn aan een traditioneel ontwikkeltraject. Hierbij is de fasering van de stappen anders. Doordat er deelopleveringen van meerdere features tegelijk plaatsvinden zijn ook de doorlooptijden van deze stappen zelf anders. Hierdoor is het niet meer voldoende gedurende het ontwikkeltraject alleen controle uit te voeren op basis van doorlooptijd en planning, maar zou de controle ook al tijdens het gehele traject een uitspraak moeten doen over de resultaten van dit project.

Elke softwareontwikkeling doorloopt een aantal fases. Er zal vanuit een vraag een globaal idee ontstaan voor een product (businessvraag). Dit product wordt in een globaal document beschreven (businesscase). Op basis van de businesscase worden requirements opgesteld (use cases en (non-)functionals). Vanaf dit punt kunnen ontwikkelingen op een agile wijze worden opgepakt. Deze functionals worden in het scrumteam verder als epics en features opgedeeld en per feature vindt er een ontwerp/bouw/test-traject plaats. Uiteindelijk moeten alle opgeleverde epics samen de originele business vraag invullen.

Om te komen tot een goede governance over agile ontwikkeltrajecten is op elk van de overkoepelende processen in een ontwikkeltraject een sturing- en controlemoment noodzakelijk. Wij benoemen hiervoor de processen ontwerp, ontwikkel, project en beheer. Voor elk van deze processen kan een zogenoemd “three lines of defence” model worden ingericht. Hierbij zijn de lagen als volgt opgedeeld:

1. Het team
2. Project quality control
3. Onafhankelijke toets (audit functie)

Uitgangspunt bij dit model is dat de scrummaster (samen met de productowner) verantwoordelijk is voor het ontwikkeltraject en de kwaliteitsprocessen hierin. Zij kunnen hierin worden ondersteund door een functie die adviseert, coördineert en bewaakt of het management zijn verantwoordelijkheden ook daadwerkelijk neemt. Dit is de tweede lijn, in dit model de Project QC. Ook het opstellen van verantwoording naar het senior management / de directie en het (mede)opstellen van risicoanalyses behoort tot de taak van de tweede lijn. Ten slotte is het wenselijk dat er een functie bestaat die controleert of het samenspel tussen de eerste en tweede lijn soepel functioneert en daarover een objectief, onafhankelijk oordeel velt met mogelijkheden tot verbetering. Het is namelijk niet wenselijk dat er geen overlapping is, of erger: blinde vlekken bestaan. Deze functie is de derde lijn. Dit is een onafhankelijke functie van het project.

Uiteraard is bij het toepassen van scaled agile of de toepassing van frames zoals SAFe en LESS, het uitvoeren van dit deel van het governance vraagstuk ook mogelijk. Hierbij dient echter wel extra aandacht geschonken te worden aan de integratie en onderlinge samenhang.

Een onafhankelijke toets

inspearit hanteert voor het uitvoeren van een onafhankelijk toets een referentiekader gebaseerd op de vier majeure stappen binnen een ontwikkelingstraject. Dit referentiekader (of in audit termen: het controle framework) is hieronder op hoofdlijnen beschreven.

Ontwerp

De ontwerpstap is zoals beschreven de stap waarin de businessvraag wordt vertaald naar een nieuw te ontwikkelen product. In de ontwerpfase worden de vragen van alle stakeholders benoemd en vertaald naar het product. Onderdeel van de ontwerpfase is compliancy. Hieronder verstaan wij het voldoen aan wet- en regelgeving, intern beleid en procedures en de verwachtingen van key stakeholders.

• Zijn (non-)functionals (o.a. ISO25010) in lijn met de verwachting van de opdrachtgevers
• Is de businesscase voldoende uitgewerkt in de requirements
• Is de compliancy, inclusief het voldoen aan wet- en regelgeving geborgd

Ontwikkel

Bij het ontwikkelen (en vervolgens testen) van software dient binnen een agile project te worden voldaan aan de algemene eisen die een organisatie stelt vanuit het beleid. Dit wordt door de teams gereflecteerd door middel van de checklist ‘Definition of Done’ (DoD). Door het scrumteam, en ook de QA, dient gecontroleerd te worden of hieraan voldaan is en of het backlog-item van status Ready naar status Done kan.

• Zijn (non)functional requirments voldoende geborgd
• Is de kwaliteit van de opgeleverde functionaliteit voldoende en is voldaan aan de DoD
• Wordt er door de teams effectief/efficiënt gewerkt om tot voldoende functionaliteit te komen

Project

Naast de inhoud is er ook processturing in de vorm van project. Hier moet de sturing plaatsvinden op de resultaten die het project oplevert en bewaking dat deze resultaten in lijn zijn met het oorspronkelijke doel van het project, de businesscase.

• Wordt de Business Case nog steeds gehaald en is de burndown-chart in lijn hiermee
• Wordt de rol van quality control juist ingevuld
• Is de benutting van het budget in lijn met de voortgang en resultaten
• Wordt de governance nageleefd en nemen partijen aantoonbaar hun rol
• Is er voldoende oog voor risico’s, beoordeling, evaluatie, testen en/of acceptatie

Beheer

Nadat het project de functionaliteit heeft opgeleverd zal deze, indien de organisatie nog niet in Dev-Ops is overgegaan, moeten landen in de beheerorganisatie zodat dit onderdeel wordt van het dagelijkse beheer en de verantwoordelijkheid van de lijn.

• Heeft de overdracht naar beheer/lijn juist plaatsgevonden. Is er voldoende beschreven qua documentatie en kan het beheer voldoende uitgevoerd worden
• Is er een juiste aansluiting met bestaande objecten/koppelingen binnen het bestaande IT landschap

Auteurs