5 veelvoorkomende planningsfouten in softwareontwikkeling

Het is moeilijk om de toekomst te voorspellen, ook al bestaan er specifieke methoden die precies daarvoor bedoeld zijn. De realiteit is dat zelfs het plannen van een eenvoudig softwareontwikkelingsproject al een uitdaging is. Er zijn veel dingen waar je rekening mee moet houden en net zo veel dingen die mis kunnen gaan. Het is bewezen dat het vaak fout gaat wanneer software alleen op basis van voorspellingen wordt opgeleverd. Helaas is dat nog steeds een hardnekkige gewoonte.

De meest gemaakte fouten bij softwareontwikkeling:

1. De complexiteit van softwareontwikkeling wordt vaak onderschat

Softwareontwikkeling wordt vaak vergeleken met het bouwen van een huis. Dat lijkt een goede vergelijking, want op het eerste gezicht "bouwen" softwareontwikkelaars iets. Helaas verschilt softwareontwikkeling fundamenteel van de traditionele huizenbouw. Wanneer zulke planningsmethoden worden toegepast, kan dat dus tot problemen leiden.

Nassim Nicholas Taleb beschrijft in zijn boek "The Black Swan" twee verschillende werelden: "Mediocristan" en "Extremistan". Beide werelden vertegenwoordigen twee verschillende soorten onzekerheid.

Om dit verschil te demonstreren, stelt Taleb het volgende experiment voor:
Je selecteert 1.000 willekeurige personen uit de bevolking. Deze personen gaan vervolgens hoofd aan voet achter elkaar liggen, zodat ze een lange lijn vormen.

Laten we ervan uitgaan dat de gemiddelde lengte van een persoon 1,68 m is. De lijn zou dan ongeveer 1.680 meter lang zijn. Een dubbel zo lange lijn (3.360 m) zou dan uit ongeveer 2.000 personen moeten bestaan (die ook een gemiddelde lengte van 1,68 m hebben).

Wat zou er gebeuren als er nog eens 1.000 personen bij de bestaande lijn gaan liggen? Dit keer nemen we echter de langste man ter wereld (Sultan Kösen, 2,51 m) mee. In dat geval heb je slechts 1.999 personen nodig. Zelfs nadat zo'n worst-case scenario in de planning is meegenomen, is er dus geen groot verschil met onze oorspronkelijke berekening.

Nu proberen we hetzelfde experiment nog een keer – maar met een andere berekening:

Dit keer worden 1.000 willekeurige personen uit de bevolking geselecteerd en wordt het vermogen van de betreffende families vastgelegd. Het gemiddelde vermogen van een familie in de VS bedraagt bijvoorbeeld 110.000 dollar. Voor deze groep zou dat een totaalbedrag van 110.000.000 dollar zijn. Vervolgens schat je de benodigde grootte van een kluisruimte om het totale vermogen van 2.000 personen te kunnen bergen. Je kunt de grootte relatief eenvoudig berekenen door de benodigde grootte voor het vermogen van 1.000 personen te bepalen en die dan te verdubbelen.

Nu nemen we weer 1.000 personen, maar deze keer met Bill Gates erbij. Wat zou er nu kunnen gebeuren? De oorspronkelijke schatting was voor een kluis waarin 220.000.000 dollar kan worden bewaard. Nu heb je er echter een nodig voor 77.500.000.000,00 dollar. Wat voor verschil maakt een worst-case scenario hier?

Wat hebben deze experimenten met softwareontwikkeling te maken?
Als je al ervaring hebt met softwareontwikkeling, ben je vast wel eens een probleem tegengekomen dat je niet kon oplossen. Misschien is het een bug die heel moeilijk te fixen is. Of het is een technisch probleem dat je met de beschikbare tools niet kunt oplossen. De oorspronkelijke schatting was niet slechts een beetje onnauwkeurig, maar wijkt 10%, 20% of 500% af. Dat is de wereld van softwareontwikkeling. Dat is "Extremistan" (tweede experiment), waarbij één voorval of element een grote invloed op het resultaat kan hebben.

De meeste bouwprojecten komen uit de wereld van "Mediocristan" (het eerste experiment), waar afwijkingen in het geheel worden uitgemiddeld. Laten we het experiment herhalen met willekeurig gekozen wolkenkrabbers en deze gebouwen als dominostenen naast elkaar leggen. Nu komt het hoogste gebouw ter wereld, de Burj Khalifa, in beeld. Is het resultaat uiteindelijk hetzelfde als bij het voorbeeld met de lengte van personen of bij het voorbeeld met het vermogen?

Hoe kun je voorkomen dat je "Extremistan" met "Mediocristan" verwart? Het is belangrijk om het type taak dat je plant tot in het kleinste detail te begrijpen. Als de werklast van een individueel item potentieel sterk kan afwijken van die van andere items, is het raadzaam om passende planningsmethoden te gebruiken. Daarom zijn de empirische planningsmethoden die in Scrum worden ingezet, geschikter voor projecten uit "Extremistan".

2. Het onvoorziene plannen we niet

Complexe taken vereisen een ander soort risicomanagement. Bij de gebruikelijke projectplanning worden buffers ingezet voor onvoorziene voorvallen. Er heerst vaak het geloof dat het onvoorziene wordt gecompenseerd doordat verloren tijd wordt ingehaald met gewonnen tijd. Helaas werkt dat bij complex werk niet.

Bij dit project zijn we ervan overtuigd dat we op de geplande datum kunnen opleveren. Maar laten we eens aannemen dat de achterliggende feiten de volgende zijn:

• Je bent een kalkoen
• De voortgang die wordt gevolgd, is je gewicht
• Niemand heeft je over Thanksgiving verteld. Wat gebeurt er met kalkoenen met Thanksgiving?
  Hoe voel je je nu?

Nassim Nicholas Taleb gebruikt deze metafoor in zijn boek "The Black Swan" om de impact van onvoorziene voorvallen te illustreren. De kalkoen heeft nog nooit van Thanksgiving gehoord en er is ook geen buffer ingecalculeerd. Onvoorziene voorvallen zijn in traditionele planning niet voorzien. Maar bij softwareontwikkeling komen ze vaak voor.

Hoe kun je deze fout vermijden? Het raamwerk van Scrum voorziet erin dat er op regelmatige basis afzonderlijke delen van software worden opgeleverd. Het risico wordt verkleind door vroeg en vaak op te leveren – en niet door ingeplande buffers. Als er onvoorziene voorvallen optreden, is er de mogelijkheid om terug te vallen op wat er tot dan toe is gebouwd.

3. Vaak wordt aan stakeholders een belofte gedaan die niet kan worden nagekomen

Als we toch weten dat softwareontwikkeling complex en risicovol is, waarom kunnen we dat dan niet gewoon aan de stakeholders meedelen? Waarom doen we beloftes die we niet kunnen nakomen? Het antwoord is dat leidinggevenden zekerheid nodig hebben. Zij stellen het budget vast, zij moeten er zeker van zijn dat alle werkzaamheden gepland zijn, zij willen een deadline en ze willen uiteraard alle gewenste features.

Maar zijn in steen gebeitelde toezeggingen noodzakelijk?
De meeste vakmensen uit de branche begrijpen het risico. Ze begrijpen ook dat ze vaak een risico moeten nemen om rendement en winst te behalen. Heel vaak is de hoogte van het risico direct verbonden met het potentiële rendement. De meeste bedrijven zouden de voorkeur geven aan een gegarandeerd rendement. Ze weten echter dat de winst uit zulke investeringen zo laag is dat het zich vaak helemaal niet loont om te investeren. Als iedereen dat weet, waarom doet dan niet iedereen het?

Als stakeholders de verhouding tussen risico en beloning (winst) begrijpen, waarom volgen we bij softwareontwikkeling dan niet hetzelfde principe? Bij elke nieuwe release is er een element van beloning. In elk goed project is er een berekening van de rentabiliteit (Return on Investment (ROI)). Als er een aanzienlijke rentabiliteit in een project te verwachten is, dan moeten de stakeholders een zeker risico verwachten. Praat dus met je stakeholders hierover. Maak hen erop attent dat ze misschien niet alles zullen krijgen wat op het moment van de planning werd verwacht. Dat is het risico bij softwareontwikkeling. Het betekent niet dat je het risico niet kunt beperken. Een eerlijk gesprek zou echter zeker gevoerd moeten worden.

Als stakeholders bindende toezeggingen van je willen, dan moet je alleen toezeggingen doen die je ook kunt nakomen. Verbind je tot samenwerking. Verbind je ertoe om je aan het afgesproken proces te houden. Verbind je tot kwaliteitsgericht werken. Verbind je tot voortdurende inspectie en aanpassing. Verbind je ertoe transparantie te waarborgen.

Praat met de stakeholders over risico en beloning en leg hun uit dat het bouwen van nieuwe software hetzelfde principe volgt. Bespreek welke maatregelen voor risicobeperking kunnen worden toegepast. En verbind je alleen tot wat je werkelijk kunt leveren.

4. We geven stakeholders vaak de indruk dat sommige werkzaamheden gratis zijn

Als we onze stakeholders bepaalde features op een bepaald moment en voor een bepaald budget beloven, dan denken ze dat ze deze features hebben betaald en gekocht. Als ontwikkelaar heb je je ertoe verplicht om de features ook op te leveren. Het risico is nu dat de stakeholders denken dat er geen meerkosten op hen afkomen. Ze hebben immers al betaald en geloven dat alle extra features in de prijs zijn inbegrepen. Het enige waar ze zich zorgen over maken, zijn de kosten voor eventuele wijzigingen. In zijn boek "Predictably Irrational" beschrijft Dan Ariely de verandering in menselijk gedrag wanneer iets gratis is:

"Overal zijn voor- en nadelen, maar als iets gratis is, vergeet je de nadelen."
Als je stakeholders begrijpen dat geen enkele feature gegarandeerd is totdat deze is opgeleverd, zullen ze vaker participeren, beslissingen nemen en compromissen sluiten. Ze zullen erop staan dat eerst belangrijke features worden afgerond en daarna minder belangrijke. Ze zullen minder snel bereid zijn om veel moeite te doen voor features die niet zo belangrijk zijn.

Daarom moet je je stakeholders er regelmatig aan herinneren dat er geen garantie is dat een feature volgens plan wordt opgeleverd, totdat deze daadwerkelijk is uitgeleverd.

Voor het stellen van prioriteiten moet er gedurende het project permanent met de stakeholders worden samengewerkt. Scrum Sprint Reviews geven stakeholders regelmatig de mogelijkheid om de voortgang van het proces te beoordelen, het aanstaande werk te bespreken en prioriteiten te stellen.

5. We handelen niet professioneel

Stel je voor dat je een oogoperatie moet ondergaan. De oogarts weet dat er bij deze operatie een risico van 10% bestaat dat er complicaties kunnen optreden en dat in plaats van een verbetering blindheid het gevolg kan zijn. De arts besluit deze informatie voor je achter te houden. Hij gelooft dat hij anders je opdracht kan verliezen. Stel je nu voor dat je de operatie laat uitvoeren en je gezichtsvermogen verliest. Dan kom je erachter dat de oogarts dit risico kende, maar je er niet over heeft geïnformeerd. Hij zou met serieuze consequenties te maken krijgen. Dit is zeker niet de werkwijze die je van een professional zou verwachten.

Zou het beter zijn als de oogarts voor het risico waarschuwt maar dan zou zeggen: "Maak je geen zorgen, ik ben een heel goede oogarts en ik garandeer je dat er niets zal gebeuren." Zou dat professioneler zijn?

Dit scenario herhaalt zich voortdurend in softwareontwikkelingsprojecten. We liegen tegen onze stakeholders. De reden waarom we liegen kan slecht zijn (de stakeholders ertoe bewegen het contract te tekenen), goed (de stakeholders hun angst wegnemen) of we liegen gewoon tegen onszelf. Het resultaat blijft hetzelfde: het is uiterst onprofessioneel!

Om deze fout te vermijden moet je eerlijk zijn, ook als dat moeilijk is. Daarmee geef je de stakeholders namelijk de mogelijkheid om de risico's te herkennen en dienovereenkomstig te plannen. Een professional gebruikt en bevordert de empirische grondslagen in Scrum en helpt de stakeholders daarmee om beter met risico's om te gaan.

Samenvatting: Planningsfouten in softwareontwikkeling

Het is moeilijk om de toekomst te voorspellen. Wanneer we complexe softwareontwikkeling plannen, maken we veel fouten die vaak tot een laag slagingspercentage leiden. Door het gebruik van Scrum worden zulke fouten vermeden.

Deze tekst is afkomstig uit de blog van Steve Porter en is door ons naar het Nederlands vertaald.

Wat doet een Product Owner?

=> Leer meer over de taken en verantwoordelijkheden van Product Owners.

De Sprint Planning Meeting

=> Verloop en belangrijke tips voor Product Owners over Sprint Planning