Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

In Scrum draai je risico's de nek om

 

Computable Expert

ing. Egbert Bouman
Practice Manager bij Valori, Valori. Expert van Computable voor de topics Development en Overheid.

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 pratenHou 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 pokerenHet 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!
 

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5089426). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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.

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!

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 …

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×