Met agile meer dan twee keer zoveel kans op een zeer waardevol IT project.
Grote kans dat jij nog niet wist dat is aangetoond: met een agile aanpak heb je meer dan twee keer zoveel kans op een zeer waardevol IT project. Anders gezegd: een aanpak waarbij vooraf in enorm detail wordt bepaald wat het doel is (de waterval methode), vormt een deksel op haar eigen succes. Je mist de kans om voortschrijdend inzicht mee te nemen en kunt nooit meer opleveren dan je vooraf kunt bedenken. Dit kun je bestrijden door een just in time, just enough principe toe te passen.
Achtergrond
Er zitten best wel wat Agile coaches en Scrum masters in mijn netwerk, dus er komen best veel berichten over voorbij op mijn tijdslijn op LinkedIn. Toch lees ik nooit iets over deze cijfers als het gaat over het maken van de keuze tussen agile ontwikkelen of niet.
Ik moet eerlijk bekennen dat het voor mij lange tijd vooral een gut feeling was, die in mijn eigen ervaring wel klopte, maar dat was uiteraard een (te) beperkte steekproef. Nu kan ik het met significante cijfers onderbouwen. Waar heb ik het over? Over het feit dat je met een agile aanpak meer dan twee keer zoveel kans hebt op een zeer waardevol project. Anders gezegd: een aanpak waarbij vooraf in enorm detail wordt bepaald wat het doel is vormt een deksel op haar eigen succes.
Het begon met het zien van de onderstaande tabel uit het CHAOS rapport van afgelopen jaar. Voor wie het niet weet: de Standish group doet al meer dan 25 jaar onderzoek naar het succes en falen van IT projecten en brengt elke zoveel jaar een nieuw CHAOS rapport hier over uit. Wat de tabel laat zien is hoe precies en gedetailleerd vooraf het doel van het project was gedefinieerd, uitgezet tegen de uiteindelijk opgeleverde waarde.
Wat zien we precies?
Als iemand die heel veel aandacht in projecten vraagt voor de op te leveren waarde – omdat hier vaak de helderheid ontbreekt met allerlei negatieve gevolgen – maar wel vooral op de grote lijnen focust was deze tabel een mooie bevestiging. Wat je in de tabel kunt aflezen is dat vooraf precies gedefinieerde doelen zeker mooie uitkomsten kunnen opleveren, maar een vooraf losjes gedefinieerd doel een veel grotere kans geeft op een echte klapper (very high value). Zo’n platte tabel maakt dat niet zo goed zichtbaar, dus heb ik voor wat extra helderheid de bovenste en onderste rij in een grafiek uitgezet.
Wat is er aan de hand?
Als je naar de donkerblauwe precise lijn kijkt (waar vooraf zeer precies en in detail het doel wordt beschreven) dan volgt deze een voorspelbare curve. Op zich logisch dat er in bijna 50% van de gevallen een gemiddelde waarde wordt opgeleverd. Maar dan springt het er meteen uit: distant gedefinieerde doelen leveren gemiddeld gezien een bovengemiddelde waarde op! Deze aanpak verschuift het zwaartepunt – de piek – naar de (very) high value kant, zoals de lichtblauwe lijn laat zien.
Misschien vraag je je nu af hoe dit komt. Dat heeft er alles mee maken dat je bij enorme focus op die precieze definiëring vooraf (of erger nog, door contractueel in detail de scope vast te leggen) de kans mist om voortschrijdend inzicht mee te nemen, die uiteindelijk tot meer waarde zou leiden. Je kunt nooit meer opleveren dan wat je vooraf hebt kunnen bedenken. Dit is dus de deksel op je eigen succes. Natuurlijk komt het voor dat iemand exact weet wat er moet gebeuren, dit precies op kan schrijven en dat ik ook klopt en veel waarde oplevert. Daarom levert dit in 7% van de gevallen een zeer hoge waarde op. Maar de kans is net zo groot dat je met deze aanpak een zeer lage waarde oplevert. De kans op zeer hoogwaardige resultaten is meer dan 2 keer zo groot bij een aanpak die het doel vooraf losjes definieert.
Het loont dus om niet vooraf alles tot in detail uit te werken. En laat dat nou precies zijn wat agile methodieken voorstellen om te doen. Het Agile manifest waardeert inspelen op verandering boven het volgen van een plan. De drie kernprincipes van Scrum zijn Transparantie, Inspectie & Aanpassing. Hier wordt in een bepaald ritme invulling aan gegeven en op die manier ben je periodiek bezig om te verfijnen en te verscherpen. En dat werkt dus niet alleen goed voor het verfijnen van de manier van (samen)werken, maar ook voor het detailleren van het doel van je project.
Hoe gebruik je dit in je voordeel?
Om dit te benutten hanteer ik in de projecten die ik mag begeleiden altijd het just in time, just enough principe als het over het bepalen van projectdoelen gaat. Daarin leggen we wel vooraf vast wat het doel is, maar beperken we ons tot de grote lijnen (op dat moment genoeg) tot je bij een specifiek onderdeel aan bent gekomen en dan werk je dit in detail uit. Zo laat mogelijk voor we een bepaald deel van het project realiseren leggen we de details van het doel van dat deel pas vast, om zoveel mogelijk ruimte voor voortschrijdend inzicht te creëren. En blijkbaar werkt dit dus niet alleen in mijn ervaring, maar is dit een meetbaar succesvolle strategie voor heel veel IT projecten.
Nog steeds sceptisch? Heb jij nu eenmaal vooraf een plan nodig met een vaste scope en zicht op de kosten, om je bij de business te kunnen verantwoorden? Dan daag ik je graag uit om het gesprek met me aan te gaan hoe we dit voor jouw project succesvol kunnen inzetten. Daarbij help ik je dit verhaal bij de business duidelijk te maken, zodat we de kans krijgen die very high value te realiseren!
Meer weten over hoe helderaar jouw IT projecten super succesvol kan maken? Kijk dan hier of neem contact op.
