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!
Nog altijd zal de wet van behoud van ellende op gaan.
Dus in die zin zullen de risico’s misschien veranderen per methode maar uiteindelijk zul je tegen globaal dezelfde hoeveelheden fouten oplopen.
Scrum gaat naar mijn mening vooral over controle van een software ontwikkelings project maar het gaat niet over de inhoud. Als ik termen lees als productowners, sprints, spikes, pokeren, scrumboard, productbacklog etc dan gaan mijn oren klapperen. En inmiddels is het me wel duidelijk dat je met de scrum ook weer alle kanten op kan, nog meer half gedefinieerde abstracties. Weer reden voor een volgende discussie, de zoektocht naar de ware scum en agile, wat betekenen deze termen nu precies en wat verwacht je ervan. De discussie komt dan wel heel ver een werkend software naar tevredenheid af te staan. Het proces is heilig verklaard, het gaat over orde, controle en registratie. Inderdaad, de project bureaucratie. Poolse landdag ict.
Ook in de verhoren van de ict commissie heb ik agile en scrum al een paar keer terug horen komen.
Een link naar een stukje van een verhoor van Dhr Leether, een juridische adviseur, het gaat over een project bij de Hanzehogeschool in Zwolle:
http://www.youtube.com/watch?feature=player_detailpage&v=b1jxhAfm_pI#t=4150
Ook Dhr Mathijssen, adviseur ICT zegt er iets aardigs over:
http://www.youtube.com/watch?v=i9fC-Ol_Hrk&feature=player_detailpage#t=652
Ook deze beide verhoren zijn de moeite waard om te beluisteren. Zeker Mathijssen is erg leuk om te horen, hij heeft zelf een overzicht aangelegd van ICT projecten en kosten. In binnenland en buitenland. Zo heeft hij het over twee projecten met vergelijkbare functionaliteit en waar het ene project zo rond de 4 miljoen gekost heeft kostte het ander project over de 100 miljoen.
Ik zie dat de algemeen heersende kennis over methodieken behoorlijk diepgaand is.
Ik hoop toch dat naast al dat gewauwel de kennis is van datgene wat uiteindelijk ons vakgebied is minstens zo groot is.
NQ : elke keer hetzelfde verhaal vertellen zonder dat de boodschap overkomt is beter dan Agile, Scrum en Lean.
Jan : een klein team van specialisten dat zelf beslist aan de hand van productowner wensen, gefaciliteerd door scrum master is bureacratisch ?
Ewout : Scrum niet doen want te moeilijk ?
Henri : Vat ik zo goed samen, niet IT maar NQ is voorspelbaar ?
Johan : volgens artikel loop je met scrum ook tegen fouten aan, maar is het gevolg niet zo groot omdat je er agile mee om gaat. Je grijpt zo vroeg mogelijk in.
Louis : ok, jij, NQ, Jan en ik gaan samen zonder methode een project doen want we hebben allemaal ervaring dus we hebben geen structuur nodig. Dat gaat wat worden 😉
Pascal : ProjectManagement is geen deel van ons vakgebied ?
Hoi Egbert,
Net stuk. Lekker praktisch.
@Felix Nee, dat lijkt me geen goed plan. Wel graag met een projectleider die de lijn in de gaten houdt, niet elke ochtend en je mag erbij zitten. DAt lijk me iets voor Felix, NQ of Jan. Iemand met een natuurlijk overwicht. Voor het overgewicht zorg ik wel.
@Felix
wie zegt dat ik geen methode volg? Volgens mij is er een neiging om hetzelfde steeds onder andere naam maar met nieuwe buzzwords te “verkopen”.
Ik ben echter geen ontwikkelaar, meer integrator en/of beheerder, projektleider en begeleider.
@NQ
IT is voorspelbaar, net zo voorspelbaar als het gedrag van mensen, kijk maar in de kommentaren op computable!
@ Reza
Onderwerp hadden we in het verleden al eens aangesneden en mijn reactie daarop klaarblijkelijk in oblivious verdwenen. Ook prima natuurlijk.
@ Felix
Frappant dat mensen dan nog steeds niet willen begrijpen wat de onderliggende wetmatigheden zijn. Soit, ik hoef die rekeningen niet te betalen. Behalve dan als belastingbetaler bij f#ck #ps van de overheden. Dat stoort mij dus tsja….
@ Jan
Je reactie was voor mij idd weer erg voorspelbaar.
@ Henri
Spijtig dat ik je hier tegen moet spreken maar de voorspelbaarheid is onveranderd sinds de weefmachine dus is het verbazingwekkend dat niemand juist daar aandacht aan besteed. Maar altijd bereid één op één tot nadere uitleg natuurlijk. ;O)
Om het weer even terug te brengen naar het oorspronkelijke artikel. Onlangs kwam ik deze Agile Risk Radar tegen, waarin risico’s heel intelligent in de toekomende tijd voor het team worden weergegeven:
http://www.bigvisible.com/2011/12/visualizing-project-risks-and-impediments/
Ik ben vereerd dat ik zo’n boeiende discussie heb getriggerd, maar met alle respect: het is wel een beetje off-topic.
Vergis je niet mensen: Scrum is echt groot geworden, of je het nu fijn vindt of niet. Ik schat dat momenteel de helft van alle IT ontwikkeling met Scrum of anderszins agile gebeurt. Dus laten we de voordelen omarmen en iets doen aan de zwakke kanten. Zo’n zwakke kant is risicoanalyse en -beheersing en daar gaat m’n bijdrage over. Ik kijk nog steeds uit naar een inspirerende inhoudelijke reactie!