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!
Persoonlijk en zakelijk heb ik helemaal niet zo heel veel met dat scrum. Alle Respect en ieder het zijne natuurlijk. Wanneer je het hebt over risico’s, dan zijn de risico’s op voorhand allang bekend en zou je daar allang je maatregelen voor hebben genomen.
De basis in en met IT is namelijk voor 100% voorspelbaar. Immers, aan elke stap die je moet zetten of zet, is al een waarde toegekend, anders gebeurd er namelijk niets. Geen input, geen output weet u nog? Dat betekend dat alle deelnemers, ook de steakholders, gewoon moeten weten wat de wetmatigheden, do’s en don’ts zijn van en met IT, en je dwingt risico’s de deur uit.
Ik weet het wel, nu zijn er veel professionals die roepen dat dit te eenvoudig zou zijn omdat…. maar ik challenge u wat dat betreft natuurlijk erg graag. Als je het namelijk over risico’s in en met IT wil hebben dan zijn er maar twee redenen dat je met impact door risico’s te maken krijgt.
Ondoordacht genomen actie of stappen of mensen die niet weten op welke manier je met de materie onder IT moet om gaan die dan een bepaalde invloed (willen) uitoefenen op een project. Als je beducht bent voor deze twee regels dan ben je ook beducht voor risico’s.
De impact en uitwerking van een risico is na zo’n dertig jaar automatiseren wel een beetje bekend. En bij mijn weten had je dertig jaar geleden niet zo iets nodig als scrum en/of lean. Wel oog voor bovenstaande. En die kennis is vrijwel gratis en gewoon beschikbaar in de vorm van ‘Ervaring’.
na 30 jaar automatiseringservaring is NQ niet meer zo Agile en Lean 😉
@Felix
NQ heeft echter gelijk.
Scrum is de burokratie van de IT.
Scrum is als schaken terwijl de meesten nog niet eens kunnen dammen.
Mijn bijdrage zal misschien al tig- keren op de draaitafel hebben gelegen, maar bij deze wil ik één en ander nuanceren.
Persoonlijk ben ik van het volgende overtuigd: projecten, wat die ook mogen zijn, bestaan uit aktiviteiten die volgens een bepaalde logic moeten worden uitgevoerd op basis van begrensde resources tov één of meerdere contractuele targets. Hiervoor heb je daadwerkelijk een Precedence nodig. Overwegend wordt nutteloos een CPM gebruikt. Uiterst belangrijk: bij een Precedence kan men twee aktiviteiten zowel met start/start- als met een eind/eind relatie verbinden.
Wat er nog meer komt bijkijken zijn mijn twee statements.
1. Een schedule wordt nooit afgewerkt zoals het aanvankelijk is opgesteld (baseline).
2. De doorlooptijden, empirisch, berekend of geschat, zijn de zwakste schakels in het schedule.
Persoonlijk ben ik de mening toegedaan dat velen vanaf hier of vooraf, met de handen in de lucht, de handdoek in de ring werpen. Onterecht. Door degelijke kennis van hèt systeem en geruggesteund door periodieke progress en aktualisatie kan men steeds gerichte coördinatie rapporten verdelen die leiden tot het bereiken van contractuele targets.
Persoonlijk ben ik een team player en weet het hier vooraf gaande in goede banen leiden (dit althans met een toch redelijke te verwachten medewerking van de uitvoerenden). Zou ik de mogelijkheid hebben mijn kennis betreffende ‘resource management’ te programmeren dan verdwijnen zienderogen alle obstakels om project na project met een contractuele bereikte target te versieren.
Wat ik hierbij nog kwijt wil is dat men door ‘onkunde’ over het ‘geheel’ van ‘Resource Management’ -voor eender welk type project- zaken heeft uitgevonden die commercieel veel hebben opgebracht en nog steeds opbrengen doch eigenlijk nutteloos zijn, zijnde risico’s.
Scheduling en ‘Resource Management’ is eenvoudiger dan men erover denkt. Hierbij wens ik het te houden.
Praktisch. U mag mij uitnodigen voor een verduidelijking. Aan de hand van een voorbeeld zal ik proberen mijn idee over ’Resource Management’ uit te leggen. Mijn voorbeeld gaat uit van 11 nep projecten. Een resource histogram duidt aan wanneer wie iets heeft uit te voeren. Op basis van een periodiek resource histogram kan men nagaan of men ‘op afstand’ bijtijds resources moet aantrekken of verwijderen; uiteraard een beslissing door het management te nemen.
Geen idee of ik me in dit forum mag voostellen, U contacteert mij op Jack.coolman@skynet.be of +32 475 745 761.
@ Felix The Cat
Met een minzame glimlach leg ik je graag het volgende even uit.
Ik heb sinds mijn dertiende tot mijn vijfenveertigste Aikido, Iaido en aardig wat Zen beoefend. Een onderdeel van alle oefeningen was…..?
Kai-Zen. Vrij vertaald betekend het niets meer of minder dan “Beter maken”. Perfectioneren zogezegd.
Een besef daarbij is dat elke beweging goed doordacht moet worden en door herhaling verbeterd. Laat dat nu geheel in lijn zijn met niets anders dan de menselijke natuur. Toyoda besefte dat begin jaren vijftig en maakte Kai Zen een deel van het productieproces. We spreken nu zo’n zestig jaar na dato en plots komt er een amerikaan die roept dat Scrum en Agile ‘het’ moet worden omdat.
Tweede kanttekening daarbij is eenvoudig dat professionals, Agile en lean niet tot weinig lineair zijn, iets wat IT als materie wel is. Kom je plots tot de ontdekking dat het dus in de wereld van IT weinig toevoegende waarde heeft. Of je moet het als zodanig leuk weten te verkopen natuurlijk.
Helaas verhoog je daarmee niet het rendement wat je beoogt te doen mbv IT. Wil je een gekleurde band halen? Ga dan naar een oosterse sport zou ik zeggen.
Scrum is gewoon een implementatie van Agile (manifest).
Het gevaar of de valkuil van Kai-zen is dat je wel op het juiste pad moet zijn om de verbeteringen zinvol te maken. Als je die analogie camera in de jaren negentig stapje voor stapje aan het verbeteren bent…
Scrum / Waterval / Whatever. Is gewoon een methodiek om ergens te komen en niet goed of slecht.
Beste Henri,
Het hele scrum/agile concept is gebaseerd op het Kaizen principe, zij het dan natuurlijk op zijn Amerikaans, vercommercialiseerd. Het principe van Kaizen werkt alleen wanneer iedereen deel uit maakt van het ‘Collectief’ en niet zoals op dit moment in NL gaande is de totale individualisering.
Kaizen ‘an sich’ kent geen valkuilen maar de constatering dat… En dat elke constatering, zelfs een ogenschijnlijke negatief, denkfout of een ondervonden hiaat of fout in de praktijk, waardevol is. Wanneer je dit namelijk toepast in, om het even welke, ontwikkeling, dan heeft het alleen een toevoegende waarde als je spreekt vanuit een collectief.
IT vs Kaizen
Bekijk je dit IT wise, dan kom je tot vrij vlotte conclusies. Iets werkt wel, iets werkt niet. Input = output en Geen Input = Geen Output. Ik heb niet ervaren dat Kaizen in IT werkelijk toevoegende waarde heeft. Reden dit te stellen is dat wanneer je begaan bent met de merites en wetmatigheden van IT, je als het ware je als professional er naar de werking conformeert. Ook hier geld, waar je mee om gaat wordt je door besmet.
IT vs proces en inrichting
Net zo voorspelbaar als de wetmatigheden en werking van IT is, zo voorspelbaar moeten de processen zijn. Ik heb dat vaker gezegd en blijf dit zeggen. De werkelijke problemen beginnen pas wanneer professionals denken dat niet te hoeven doen omdat…. En de vier redenen die ten grondslag liggen aan problemen in en met IT?
1. Incompetentie
2. Impotentie
3. Politiek
4. Commercie
Alle vier worden namelijk vaak verheven tot…. Maar in de praktijk zie je dan gewoon gebeuren dat zij contraproductief werken op het gestelde doel. Dan kun je natuurlijk roepen dat Scrum ‘een antwoord’ is maar ik stel dan meteen de vraag,”Hoe kan het zijn dat als je weet dat IT een 100% voorspelbare materie is, dat je het dan niet voor elkaar krijgt inrichting en proces dat evenzo te maken?”
Mocht je er sec over na willen denken kom je weer bij die vier voorgaanden uit. Telkens weer. Ik kijk niet naar goed/slecht, maar naar ’toevoegende waarde’. Richt het eerst maar eens in zoals IT werkt als materie, dan komt de rest vanzelf.
NQ (ik hou hem erin Mauwerd),
IT als materie is alleen voorspelbaar in de theorie of vanuit een model (=theorie). In de praktijk is IT hooguit deels voorspelbaar en hoe langer de keten hoe kleiner de voorspelbaarheid.
Scrum is geen antwoord, het is -nogmaals- een implementatie van het agile manifest.
De relatie tot Lean (Kaizen) en Agile is in mijn ogen deze: Agile = build, Lean = run net zoals je deze op Prince2 en Itil kan leggen. Prince2 is build, Itil = run.
Overigens vind ik je reactie toch lichtelijk verzuurd en beredeneerd vanuit een negatief referentie kader.
Ik heb projecten gedaan, sommige zijn gelukt, sommige mislukt, enkele waren een wild succes en al die projecten hadden verschillende aspecten die voor succes of faal zorgden. Met een goed team en een realistisch plan is de kans op lukken groter, ongeacht de methodiek. Veel projecten kun je al redelijk voorspellen wat de uitkomst word, maar methodiek is in mijn ogen niet de factor voor falen of slagen.
De werkelijkheid is complex door vele zichtbare en onzichtbare facetten, IT als materie voorspelbaar noemen vind ik erg theoretisch…
NQ,
Ik vraag me nog steeds af waarom je met deze kennis en ervaring nog geen artikel geschreven / gepubliceerd hebt.
Met wat andere structuur, onderbouwing en afronding kun je best van je reactie een opinie maken! Hulp nodig? Mail me maar.