Agile risicomanagement zonder Scrum te frustreren

donderdag 14 augustus 2014

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' hierboven 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.