Agile risicomanagement zonder Scrum te frustreren

Er zijn scrumdamentalisten die vinden dat je

niet over risico's moet praten. Als je gewoon

'scrum doet' loop je vanzelf tegen de risico's

aan en dan draai je ze de nek om. Klaar, just

in time!

Dat klinkt bijzonder aantrekkelijk, ja toch? Als

agile adept en CAT trainer vind ik van wel.

Maar als geestelijke vader van de PRIMA

aanpak voor product risico analyse en ISACA

gecertificeerd risico-auditor moet ik hier toch

echt wat meer van zeggen. Bij deze!

Op de TestNet Summerschool van afgelopen juli gaven collega Philip Bosch en ik voor de

tweede keer de workshop "Risicoanalyse in een agile setting", inmiddels AgRAM gedoopt.

De deelnemers waren ook nu weer unaniem enthousiast.

Keep Scrum lean, add just 'AgRAM'

AgRAM staat voor Agile Risico Analyse en Management (of als je wilt: Mitigatie). Het is een

concrete agile aanpak van risico's die we vanuit Valori samen met een klankbordgroep met

onder andere RABO, KPN, VGZ, Bol.com, Politie NL en Ministerie van EZ hebben

ontwikkeld.

Geen risico, geen gedoe

Je denkt nu dat ik als gecertificeerd risico auditor heb verteld hoe vreselijk fout de hierboven

genoemde scrumdamentalistische insteek is. Maar dat heb ik juist niet gedaan: denken in

kansen en mogelijkheden is natuurlijk veel leuker en motiverender dan denken in risico's. Als

de belangen en de risico's niet te groot zijn dan hoef je van mij niet over risico's te praten.

Hou ze gewoon impliciet binnen de perken zonder extra workshops, activiteiten, lijsten en

administraties die het agile proces weer topzwaar maken.

Scrum: impliciet risicomanagement

Scrum heeft goede papieren wat dat betreft, want als je de plank een keer echt misslaat heb

je nooit meer dan 1 sprint weggegooid. Dus de mate van tijd en geld die je kwijt bent aan

een verkeerde keuze is inherent beperkt.

Hamvraag: hoe expliciet wil je het hebben?

Er zijn goede redenen om niet teveel over

risico's te praten maar ze impliciet te

adresseren. Er zijn ook goede redenen

om wat meer expliciete aandacht aan

risico's te geven. De figuur hiernaast zet

ze voor je op een rijtje.

Bovenaan staan enkele redenen die voor

de ware agile professional moeilijk te

verteren zijn, omdat ze niet direct

bijdragen aan een beter product en

hooguit indirect waarde toevoegen. Toch

kunnen het hele goede en zelfs

doorslaggevende argumenten zijn voor

expliciete risicomaatregelen.

De onderste drie argumenten zijn naar mijn mening van directe waarde voor de kwaliteit en

de acceptatie van de deliverables van het scrumteam en moeten juist de agile professional

aanspreken.

Kortom, als de belangen en de (business) risico's echt groot zijn dan moet je een meer

expliciet risicoproces hebben. Maar liefst wel op zo'n manier dat we scrum niet alsnog

topzwaar maken en de velocity en productiviteit frustreren. Ik denk dat wij een benadering

hebben ontwikkeld die daarin geslaagd is.

Vier risicotypen

In de workshop hebben we verteld hoe je

verschillende risicotypen - we

onderkennen er vier - onderbrengt in het

reguliere scrum proces 'as is'. De

'beslistabel' hiernaast laat zien hoe.

Op deze manier gaat risicobeheersing

naadloos op in het reguliere scrum

conform de Scrum Guide plus spikes als

best pracice en HIP items uit het Scaled

Agile Framework.

Lean Risicomanagement, Auditors en testers blij

Resultaat: risicoanalyse en -beheersing liften gewoon mee met de normale activiteiten en

producten. Het team hoeft geen extra dingen te doen. Met een minimum aan overhead maak

je veel partijen blij. 'Geen risico, geen test', zeggen testers, en terecht. Voor auditors wordt

de risicomitigatie traceerbaar en controleerbaar.

Visualisatie

Wat we ook nog aanraden is iets van

risicovisualisatie op of naast het

scrumbord. Dat kan bijvoorbeeld met de

"risicoplot" die je maakt met de gratis

Excel risicoplot tool. Hoe meer een user

story rechtsboven in het rood staat, hoe

alerter je als team moet zijn met

ontwikkelen en testen. Het mooie van

deze visualisatie is dat het helemaal past

in het referentiekader van het team: je

ziet de user stories als bollen met

omvang (Story Points), value (impact) en

faalkans. Alleen de faalkans is geen

standaard attribuut in de product

backlog, dus die voeg je op enig moment

toe, bij voorkeur in de sprint planning

tijdens het pokeren. Het voordeel van

deze visualisatie ten opzichte van bijvoorbeeld een risk burndown chart is dat het geen

nieuwe risico-entiteiten introduceert zoals een risk burndown chart wel doet.

Tot zover voor nu

Als je vragen of betere ideeën hebt of gewoon meer wilt weten, laat het merken in een

reactie op deze post. Lijkt me leuk!

Als je geïnteresseerd bent in een AgRAM workshop, neem dan contact met me op

voor meer informatie.

Met de hartelijke agile groeten!

Auteur: Egbert Bouman