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!
Afgelopen woensdag gaf ik op Testnet samen met collega Philip Bosch een workshop ‘Risicoanalyse in een agile setting’. Ik presenteerde daar een concrete agile aanpak van risico’s die we vanuit mijn organisatie samen met een klankbordgroep met onder andere RABO, KPN, VGZ, Bol.com, Politie NL en Ministerie van EZ hebben ontwikkeld. De 40 deelnemers waren bijzonder enthousiast.
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 scrum weer topzwaar maken.
Scrum heeft best goede papieren wat dat betreft, want als je de plank een keer echt misslaat heb je nooit meer dan één sprint weggegooid. Dus de mate van tijd en geld die je kwijt bent aan een verkeerde keuze is inherent beperkt.
Als de (business) risico’s echt groot zijn dan moet je wat meer doen. Liefst 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. In de workshop hebben we verteld hoe je verschillende risicotypen – we onderkennen er vier – onderbrengt in het reguliere scrum proces ‘as is’.
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
Resultaat: je 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 word de risicomitigatie traceerbaar en controleerbaar. Inzichtelijk dus, hoewel m’n taalgeweten nog steeds stuitert bij dit woord, maar nu gebruik ik het dan toch echt zelf.
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 die je hier vindt. 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 meestal 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. Ik vermoed dat het een klein reeksje gaat worden. Lijkt me leuk!
Met de hartelijke agile groeten!
Onze reacties kruisten elkaar, zelfde boodschap, dank je Anko! Ik ga die agile risk radar zsm bekijken. De risicoplot op http://www.smartest.nl/toolstemplates/risicoanalyse lijkt erop vermoed ik.
Leuk en herkenbaar stuk Egbert.
Ik kijk uit naar het vervolg.
‘Ik kijk nog steeds uit naar een inspirerende inhoudelijke reactie!’
Zonder er echt over te vallen vind ik deze uitspraak wel een tikje jammer. Alsof de gegeven reacties niet inspirerend genoeg zouden zijn voor ‘further debate’.
Gents,
Wellicht is het u door uw perfectionisme in eigen vakdiscipline een beetje ontgaan, maar kan iemand de volgende vraag even voor mij beantwoorden?
‘Wat is hetgeen waarmee u elke stap in en met materie IT in beweging zet?’
En aansluitend dan natuurlijk waaraan moet ‘dat’ voldoen om een stap te kunnen zetten?
Het antwoord op beiden is ‘Value’. Even los van wat die is dan natuurlijk. Ik hoop toch dat u het met mij eens zult zijn dat ‘Momentum’ en ‘Doel’ voor een ieder vast staat wil die iets met en in IT doen. Dat betekend dat de waarde die u nodig hebt om ‘Doel’ te bereiken vast staat.
Dat geld evenzeer voor de opzet van proces, stap, plan, project of programma in en met IT. Indien dat niet het geval is? Dan is het zeer eenvoudig. Hele hoge rekeningen. Zo voorspelbaar als voorgaande is, zo voorspelbaar zijn ook de processen en dan weer mijn stelling, waarom wachten op een fail/problem als je dat ook gewoon voor kan zijn?
Oh ja, commercie en human nature. Ik vergat die twee even. Uiteraard mag een ieder het natuurlijk vanuit eigen disciplinaire of commerciële visie bekijken. Laat onverlet dat je nog steeds ‘Value’ nodig hebt ook maar iets in beweging te zetten.
Al sinds het prille begin heeft de business moeite met het formuleren van haar vraag. Evenzo heeft IT moeite met het formuleren van de mogelijke oplossingen. Geruime tijd dicteerde de IT wat “goed” was voor de business en het laatste decennium zien we de business weer terrein terug veroveren. Maar nog steeds is vaak aan de start van een traject voor de IT niet helder wat de business wil, en voor de business niet helder wat de IT kan.
Zolang dit fundamentele issue niet is opgelost kunt u scrummen wat u wilt, watervallen wat u wilt, lean, mean en clean doen wat u wilt – het blijft dan focussen op succesjes. En die worden in elk traject geboekt.
Straks komt er weer een nieuw inzicht en, daar kun je op wachten, de bijbehorende successtory’s. Dat inzicht en die werkwijze op zich is misschien niet fout; de grootste fout die we maken is achter die succesjes aan te hollen in plaats van te werken aan fundamenteel wederzijds begrip.
Als dit laatste wel gebeurt, voorspel ik dat scrum nog succesvoller wordt, … en waterval ook, en lean en …