Compliance en de wet van Fluitsma & van Tijn

Elk Agile teamlid weet: compliant moet je zijn, duiken is geen optie. En we weten ook allemaal welk woord ons hierin het meeste jeuk bezorgt, namelijk het woord ‘moeten’. Want Agile teams zijn autonoom, ze zijn zelf verantwoordelijk voor hun processen en hebben invloed op wanneer er wat moet gebeuren. “Die schrijf je niet de wetten voor, die laat je in hun waarde” schreven Fluitsma & Van Tijn al in 1996 over de Nederlandse mentaliteit. Dat geldt zeker ook voor Agile teams.

Maar ja, met schouderophalend negeren van compliance kom je jezelf vroeg of laat toch tegen. Niet compliant zijn is feitelijk ook een vorm van technical debt opbouwen, maar dan wel met mogelijk grote consequenties. Dus de terechte vraag is: gegeven de autonomie van Agile teams, hoe ga je nu goed om met het (aantoonbaar) compliant zijn of worden? 

Eerst even een klein stapje terug, want wat verstaan we precies onder compliance? In onze visie is dat het aantoonbaar voldoen aan interne en externe afspraken, verplichtingen en wetgeving. Dat zijn over het algemeen aspecten die door een partij buiten het Agile team gevalideerd, geaccepteerd of gecontroleerd moeten worden (denk aan wetgeving, interne kaders of specifieke normen). Er is dus sprake van een feedback loop die doorlopen moet worden. Net als bij… gewone user stories! 

Dus kunnen we stellen dat eisen uit wet- en regelgeving gelijk behandeld kunnen worden als user stories? Ik denk van wel. In principe worden bij compliance dezelfde refinement stappen doorlopen:

• Een behoefte vanuit een bedrijfsproces dient geanalyseerd te worden. In het geval van compliance kan dat bijvoorbeeld gaan om een aspect van Life Cycle Management (versiebeheer en veiligheidsupdates): op welke versies behoort onze software te draaien? 
• Een oplossingsrichting dient verfijnd te worden tot behapbare brokken werk (features of epics) die door een of meerdere teams gerealiseerd kan worden (bijvoorbeeld voor systeem X dient een upgrade plaats te vinden naar versie Y om security updates te kunnen blijven installeren);
• Dit wordt uitgewerkt in stories voorzien van acceptatiecriteria (bijv. ‘geen aantoonbaar performance verlies of verlies van functionaliteit’);
• De stories worden gerealiseerd in sprints, waarbij het moet voldoen aan de Definition of Done (DoD). 

Je kunt dit op dezelfde manier ook met andere compliance aspecten kunnen doen (bijvoorbeeld Privacy & Security by Design). En veel Agile teams doen dit ook zo met hun non-functionele requirements (NFR). Dat betekent dus wel dat hierop de Definition of Done (DoD) is aan te passen met het nu voldoen aan het nieuwe compliancy aspect.

Wanneer je compliance op deze manier opneemt in het refinement proces van de Agile teams, dan treedt er nauwelijks weerstand op heb ik gemerkt. Dan is compliance niet een moeilijk of lastig iets waarvoor ineens zaken ad hoc opgelost moeten worden. En zo schrijf je Agile teams dus niet de wetten voor en laat je ze in hun waarde!