Een opdrachtgever wil weten waar hij aan toe is. Dat is niet meer dan logisch. Hij wil weten wat hij krijgt en wat het kost, voordat hij een IT project groen licht geeft. Dus hij vraagt om een planning met kostenraming.

Maar krijgt de opdrachtgever dan ook wat hij nodig heeft?

Traditionele planning

Voor het maken van een planning moet je weten wat de scope en de requirements van het te ontwikkelen systeem zijn. En je moet weten hoeveel tijd het kost om die software te realiseren. Beide weet je aan het begin van het project nog niet.

Je moet dus een inschatting, een voorspelling doen. Maar hoe betrouwbaar en reëel is dat?

Requirements voorspellen

Voor het maken van de planning heb je de complete set requirements van het op te leveren eindresultaat nodig. Die requirements moeten juist en volledig zijn, zodat er tijdens het ontwikkeltraject geen grote wijzigen optreden. Want dan moet ook de planning en eventueel het budget aangepast worden.

De afgelopen decennia hebben ons geleerd dat dat een onmogelijke opgave is. Uit onderzoek van Jones blijkt dat bij een project van 1,5 jaar het aantal requirements (tijdens de ontwikkeling van het systeem) gemiddeld met 43% toeneemt.

Dat komt niet alleen omdat het vrijwel onmogelijk is om op voorhand alle requirements op tafel te krijgen. Het komt ook omdat de inzichten en behoeften van de gebruikers en andere business stakeholders gedurende de rit wijzigen.

Benodigde ontwikkeltijd voorspellen

Je schat de benodigde ontwikkeltijd voor het implementeren van de requirements. Maar waar baseer je die inschatting op? Op een benchmark? Op ervaring? Hoe schat een ontwikkelaar of een projectmanager het aantal uren in?

Een steeds terugkerend probleem is dat die tijdsinschattingen achteraf niet betrouwbaar blijken te zijn.

We zijn tijds- en budgetoverschrijdingen zelfs gewoon gaan vinden! Als je daar even over nadenkt zie je hoe absurd dat is. Opdrachtgevers baseren hun beslissingen op planningen waarvan eigenlijk iedereen weet dat ze verre van betrouwbaar zijn. En toch doen we het elk volgend project weer opnieuw.

Maar gelukkig is er tegenwoordig een alternatief.

Het agile alternatief

In een agile traject geven we de opdrachtgever geen schijnzekerheid, maar bieden hem voorspelbaarheid en transparantie.

Het gegeven dat de planning bij de start van een project onbetrouwbaar is, compenseren we door waardegedreven en incrementeel te werken. Daardoor kunnen we gegarandeerd binnen tijd en budget een systeem met veel businesswaarde opleveren. We kunnen alleen niet garanderen met welke functionaliteit exact.

Dat mag de business zelf bepalen tijdens de rit. De product owner (als afgevaardigde van de opdrachtgever en de business) bepaalt welke functionaliteit (user stories) als eerste gebouwd wordt. De prioritering van de user stories in de product backlog stelt hij voornamelijk vast op basis van de verwachte businesswaarde.

Bovendien mag de product owner of opdrachtgever er gaandeweg de rit voor kiezen om de voorziene functionaliteit te beperken. Dat kan nodig zijn om binnen budget te blijven. Of hij mag er ook voor kiezen om meer (of minder ) sprints te doen. Dat kan nodig zijn om alle gewenste functionaliteit te realiseren.

Planningen op basis van de realiteit

Agile biedt de tools om inzichtelijk te maken wat er binnen tijd en budget opgeleverd kan worden. Na gemiddeld 3 sprints kunnen agile teams daar al een reëel beeld van geven. En dat wordt snel daarna echt betrouwbaar.

Dat komt omdat je je in agile baseert op de realiteit en niet op voorspellingen (zoals bij traditionele planningen). Je hoeft de requirements niet te voorspellen en dus niet op voorhand op te stellen. In plaats daarvan baseer je de planning op het aantal te realiseren punten (story points). Hoe dat in z’n werk gaat lees je in het blogartikel Zo geef je ‘zekerheid’ aan het management.

Ook de benodigde ontwikkeltijd hoef je niet te voorspellen. In plaats daarvan baseer je de planning op ervaringscijfers. Je neemt de gemiddelde ontwikkelsnelheid van het team in de laatste 3 sprints. Bij een ingewerkt agile team is dat een betrouwbare maatstaf. Alle sprints hebben immers dezelfde lengte en vergen dezelfde type werkzaamheden.

Betrouwbare planningen

Om weg te blijven van de schijnzekerheid van fixed price – fixed time – fixed scope planningen, heeft de opdrachtgever de keuze tussen:

A. Gegarandeerd binnen tijd en budget, en zelf elke sprint opnieuw de mogelijkheid om de scope te bepalen. Binnen de mogelijkheden uiteraard. En met in acht neming van de gemiddelde ontwikkelsnelheid van het team.

Door het aantal resterende sprints te vermenigvuldigen met de velocity (gemiddelde ontwikkelsnelheid uitgedrukt in punten), krijg je het totaal aantal punten dat nog gerealiseerd kan worden. Welke requirements dat zijn is voor de planning niet van belang!

B. Gegarandeerde scope, en niet onaangenaam verrast worden door tijds- en budgetoverschrijdingen. Ook niet als gevolg van wijzigingen in de requirements.

Door het totaal aantal nog te realiseren punten (story points) te delen door de gemiddelde ontwikkelsnelheid (velocity), krijg je het aantal benodigde sprints om de resterende functionaliteit (user stories) te realiseren.

Discussie

Ik ben me ervan bewust dat dit onderwerp de nodigde reacties en discussies oproept. En inhoudelijke discussies juich ik altijd toe. Daar kun je veel van leren. Dus houd je niet in en plaats je reactie, kritische noot of ervaringen met planningen onder dit artikel.

Nicole de Swart

Misschien vind je dit ook interessant

15 reacties

  • Jip Schwering

    Hier komt de advocaat van de duivel:

    1. In een traditioneel project kun je dan toch een percentage (op basis van eigen ervaringen en onderzoeken) bij je planning optellen om hem reeeler te maken? Je hoeft niet alles te voorspellen als je er rekening mee kunt houden dat je niet alles kunt voorspellen.

    2. Als je weet dat je structureel te optimistisch schat, dan kun je pessimistischer gaan schatten. Ik heb hier goede ervaringen mee.

    3. Story points en velocity zijn geen agile begrippen, maar scrum. Agile en scrum zijn niet hetzelfde, scrum gaat verder en heeft een andere essentie, dat van continu verbeteren. Scrum kan een implementatie van agile zijn, maar willen we het vakgebied niet zuiver houden en agile laten zijn wat het is?

    4. In theorie kun je eenvoudig je velocity bepalen. Maar hiervoor moet je scrum team een heel goed scrum team zijn. Ik ben dat zelf nog niet tegengekomen.

    5. Er zal blijven gelden dat een afgegeven planning een beperkte houdbaarheidsdatum heeft. 2 tot 3 sprints vooruit plannen lukt wel. Maar daarna is het koffiedik kijken. Het is niet zo dat je planning ineens betrouwbaarder en reeeler wordt. Wat wel zo is, is dat je constant blijft herplannen en op die manier grip houdt en geleidelijk aan een steeds betrouwbaardere planning creeert. Maar het is een illusie om te denken dat je na 2 tot 3 sprints al een betrouwbare planning hebt: Je epics op je backlog zijn moeilijk in te schatten en er komt altijd van alles tussendoor fietsen, of dingen vallen weg, of je velocity is niet stabiel omdat je niet echt scrum doet met zijn allen (zoals in veel organisaties het geval is).

    6. Het is hier van groot belang dat de product owner zijn research fase goed invult zodat de backlog al relatief compleet is. Zodat het team kan schatten en je een planning kan maken. Echter in de praktijk zie ik het gebeuren dat een team begint terwijl de backlog half klaar is. Onder het motto: we beginnen maar vast en zien wel waar we uitkomen.

    • Nicole de Swart

      Altijd goed voor de discussie een advocaat van de duivel:-)

      1 en 2: Ja, je kunt idd ruimer gaan schatten. Ik heb me in het verleden vaak afgevraagd waarom dat niet op grote schaal gebeurt. Een positieve business case en budget los krijgen, wordt dan wel een stuk lastiger.

      3: Agile is idd een gedachtengoed en Scrum is een manier (verreweg de meest gebruikte) om daar invulling aan te geven. User stories, user points en velocity zijn geen Scrum begrippen (zie officiële Scrum guide).

      4: Voor ieder scrumteam moet het mogelijk zijn om de velocity te bepalen. Dat gebeurt idd niet altijd maar ze zouden het wel kunnen. Een heel goed scrum team heeft een veel hogere velocity (beter gezegd productiviteit) dan een minder goed functionerend team. Als het goed is neemt de velocity van een team gedurende het project toe, omdat ze beter op elkaar ingespeeld raken en verbeteringen in hun werkwijze doorvoeren.

      5: Je planningen worden in het begin van het project betrouwbaarder omdat je velocity steeds betrouwbaarder wordt. Als je probeert te voorspellen welke requirements/user stories er allemaal geïmplementeerd moeten worden, is plannen inderdaad koffiedik kijken. Requirements wijzigen te vaak. Daarom is het verstandiger (vooral ook voor de business) om een waardegedreven aanpak te kiezen.

      6: Zoals je het formuleert, klinkt het alsof een complete product backlog alleen het probleem van de product owner is. Als het goed is, helpt het team hem daarbij en leiden ze een initiële product backlog af uit de productvisie. Jammer dat er in veel projecgten te weinig aandacht is voor de productvisie.

      • Jip Schwering

        Nicole, bedankt voor de aangebrachte nuances in je reactie. Ik ben het daarin met je eens.

        En ik zie inderdaad ook dat er geregeld geen duidelijke productvisie is en dat het team meer zou kunnen bemoeien met de backlog. Ook zie ik dat de product owner vaak soms geheel op de hoogte is van zijn/haar taken of verantwoordelijkheden en geen tijd heeft om die te vervullen. Maar dat is weer een ander onderwerp.

        In de praktijk staan we dus nog voor een boel uitdagingen. Het is een hele andere manier van werken en ik zie dat dit voor een aantal mensen toch lastig is. Wat er volgens mij vaak gebeurt is dat er wel elementen uit de scrum gereedschap worden gepakt, maar dat die vervolgens half worden gebruikt, en dat er een aantal elementen helemaal niet wordt gebruikt. Agile/scrum wordt daarme niet volledig omarmd. In de ruimte die dan ontstaat wordt er vaak ’traditioneel’ gewerkt. Het grote risico is dat je dan niet the best of both worlds krijgt maar juist the worst of both worlds.

        • Nicole de Swart

          Jip, ik deel je observaties en help daarom analisten de beschikbare gereedschappen op een effectieve manier te gebruiken. Daar is inderdaad nog de nodige winst te behalen.

  • Ingrid van Oorschot

    Zoals Jip al in punt 1 en 2 meldt is planning ook in traditionele projecten aan ervaring aan te passen en dus betrouwbaarder te maken.
    Maar agile is een gedachtegoed waarop verschillende methoden gebaseerd zijn. Scrum is zo’n methode. Hierdoor kun je agile en scrum niet vergelijken en niet stellen dat scrum dieper gaat dan agile.
    Ook zijn user stories en story points niet beperkt tot scrum: XP en LEAN werken er mee. Het is niet juist er vanuit te gaan dat alle agile projecten één manier van plannen kennen. Elke op agile gebaseerde methode heeft zijn eigen manier van plannen.
    Ik vraag me trouwens af of je wel over plannen kunt praten. Je maakt zoals vermeld afspraken over delen die aan het eind van de iteratie gebruiksklaar zullen worden opgeleverd. Het komt er eigenlijk op neer dat je zoveel voorkomt dat er budget en/of tijdsoverschrijdingen zullen ontstaan. Dit door het eindresultaat van het totale project niet vooraf vast te leggen, maar afhankelijk van tijd en geld te maken. En dat is iets waar de opdrachtgever vaak nog niet goed van doordrongen is. Daar ligt m.i. nog wel wat werk.

    • Nicole de Swart

      @Ingrid: Ik zou releaseplanningen zonder vaste scope wel gewoon planningen noemen. Voor projecten waarbij time-to-market cruciaal is bijvoorbeeld, is de doorlooptijd veel belangrijker dan de scope.

      Veel opdrachtgever willen idd nog steeds het budget, de doorlooptijd en tevens de scope vastzetten. Dat dat niet reëel is, hebben ze ondertussen wel ervaren denk ik. Het alternatief (een waardegedreven aanpak, agile, scrum) begint nu gelukkig steeds meer door te dringen, maar er is idd nog genoeg werk te doen op dat vlak.

    • Jip Schwering

      Scrum wordt vaak gezien als Agile aanpak, maar hoe dit heeft kunnen gebeuren snap ik niet helemaal. Eigenlijk is Agile niets meer dan het Agile manifesto. Het is inderdaad een gedachtegoed. Scrum gaat wel degelijk verder omdat het een framework is die veel meer elementen omvat (en een andere essentie heeft) dan in het Agile manifesto staan omschreven. Nu is het zo dat het Scrum framework wel in aansluit op de principes in het Agile manifesto, maar dat wil niet zeggen dat Scrum gebaseerd is op Agile. Sterker nog, Scrum bestond al in 1993 en het Agile manifesto is pas in 2001 beschreven. Zelfde geldt voor XP.

      Je hebt wel gelijk dat story points en velocity niet scrum exclusief zijn. Je zou dan eigenlijk moeten zeggen: Agile is een gedachtegoed, Scrum is een daarop aansluitend framework (maar ook meer dan dat!), en dingen als user stories zijn technieken die je zou kunnen toepassen binnen een dergelijk framework.

      Dus ik ben het 100% met je eens dat niet alle agile projecten één manier van plannen kennen. Afhankelijk van hoe je het in de praktijk invult kun je dan een planningsmethodiek kiezen.

      Ik denk dat je nog wel over planning moet praten, maar je moet onderkennen dat dit een heel ander soort planning is dan die we traditioneel gewend zijn om te maken. En zoals met alle planningen geldt, is het van essentieel belang om de planning op waarde te kunnen schatten. Een planning in een agile project heeft in die zin een andere betekenis en ook een ander doel dan een planning in een traditioneel project.

  • Doeterniettoe

    Agile werken neemt een grote vlucht, maar is niet exclusief verbonden met scrum. Agile is inderdaad in 2001 met het ondertekenen van het manifest in Utah door 17 softwareontwikkelaars ‘live’ gegaan. Daar zijn ze uitgegaan van ‘best practises’ in softwareontwikkeling, niet zijnde waterval. Denk daarbij aan RAD (jaren 80, Boem, Schultz en Martin), Scrum (voor het eerst genoemd in 83 door Nonaka en Takeuchi, de aanpak zoals wij die nu kennen is in 93 door Schwaber en Sutherland opgezet), DSDM (95, door speciaal daarvoor opgericht consortium) eXtreme Programming (XP, door Beck, Auer, Cunningham, Fowler en Jeffries) en Feature Driven Development (FDD). Deze informatie is afkomstig van 1 van de ondertekenaars van het manifest Arie van Bennekum. De gelaagdheid is dus als volgt: Agile is een gedachtegoed, o.a. geïnspireerd door scrum.
    ECHTER, in dit rijtje moet vooral ook niet de LEAN methode vergeten worden, ontstaan vanuit geen verspilling en continue verbeteren, afkomstig uit Japan (met name Toyota).
    LEAN moet dan gezien worden als een managementfilosofie (5 S en plan do act check), Agile als een ‘mindset’, scrum als een agile aanpak. Ook al is scrum eerder als aanpak beschreven, het is wel degelijk als een agile aanpak te kenmerken.

  • Rik Manhaeve

    Leiden agile requirements (meestal user stories) tot een betere planning? Essentieel is de beheersing van de planning.
    Er is ook veel verwarring tussen plan en planning. Een plan is wat je gaat doen in welke volgorde (bv user stories en prioriteit). Een planning is hoeveel tijd je heiervoor nodig hebt. Daar wringt precies het schoentje.

    Planning betrouwbaarder maken heeft zeer weinig met agile te maken. Agile gebruikt het ‘Rolling Wave’ planningsproces en zet dat bijna extreem in (extreem is hier niet negatief). Voor de planning is het proces van Agile ‘niets nieuws onder de zon’. Rolling Wave planning laat toe te plannen met grote onzekerheid door te leren uit het verleden. Dit bestaat al lange tijd maar is te weinig gebruikt in het verleden. Je plant een eerste stap in detail en de rest globaal. Als de eerste stap is afgewerkt, plan je in detail het tweede stuk en gebruikt de ervaring van het eerste stuk.

    Je kan dan ‘functionality boxing’ en ’time boxing’ gaan doen. Ofwel is de inhoud belangrijkst ofwel de tijd. Het management, de klant zal moeten kiezen.

    Een groot probleem blijft wel de onzekerheid bij het begin van het project en dat heb je nodig in je business case. Je kan stellen dat het ’tussen 3 maand en 8 maand zal duren’. Het management hoort enkel 3 maand, de rest niet meer. Als je de optimistische schatting overschrijdt (zeker) begint het gedonder. Immers bij de business case houdt het niet op. De business case is een meetlat om je project op te volgen. Continu aanpassen en opnieuw evalueren of we nog doorgaan is een must.

    Daarvoor heb ik nog steeds geen afdoende en werkbare oplossing gezien die ook het management hiervan volledig kan overtuigen.

    • Nicole de Swart

      Dank voor je aanvullingen Rik.
      Traditioneel denkende managers overtuig je er inderdaad niet mee. Sterk punt van agile vind ik dat die manager niet meteen committent voor het hele project hoeft te geven. Hij krijgt zelf het stuur in handen en kan iedere sprint beslissen of hij nog een extra sprint wil. Als het agile team netjes iedere sprint werkende software oplevert en het systeem geleidelijk uitbouwt van primitief naar volwassen, kan hij de kosten-baten eenvoudig afwegen.

      • Manhaeve Hendrik

        Nicole,

        Dank je wel voor de reactie. Het klopt dat de manager het stuur in handen krijgt.
        Maar stuurt die ook?
        Herzien ze de business case na elke fase (na elke sprint zou wat te frequent zijn)?
        Stoppen ze projecten die niet meer rendabel (niet enkel financieel) zijn?

        Als de business case geregeld wordt herzien en de adequate beslissingen worden genomen, werkt dit. Maar darr loopt het o zoveel mis.

        Het aantal projecten dat gestopt wordt, waarbij de planning herzien is, de business case aangepast zouden mogelijke indicatoren zijn dat het werkt, ook buiten IT en dus in de business. Is er daar enig zicht op?

        • Nicole de Swart

          Hendrik, De business heeft niet eerder echt het stuur in handen gehad. Herzien van de business case klinkt veel te zwaar. Ik bedoel echt beginnen met een primitief/minimaal systeem en dat sprint na sprint uitbreiden en verbeteren totdat het goed genoeg is. De business ontdekt gaandeweg het project wat hun daadwerkelijke requirements zijn door het systeem uit te proberen en feedback te geven. Het systeem wordt, op aangeven van de business, steeds beter en uitgebreider. Totdat extra verbeteringen niet meer opwegen tegen de kosten.

          Bij veel organisaties zie ik dit om bijvoorbeeld de volgende redenen mis gaan:
          – Ze beginnen niet met een minimaal systeem (of stoppen daar veel te veel functionaliteit in)
          – Er is weinig betrokkenheid van de business
          – Het ontwikkelteam bouwt nog traditioneel
          – Men werkt plangedreven i.p.v. waardegedreven

  • Cees den Haan

    Nicole, ik wil graag reageren op jouw opmerking “beginnen met een primitief/minimaal systeem en dat sprint na sprint uitbreiden en verbeteren totdat het goed genoeg is”. Ik ben een ervaren systeemontwikkelaar/analist/onwerper. Als je werkelijk op deze wijze een systeem gaat ontwikkelen zal je er telkens tegenaan lopen dat de database moet worden aangepast of uitgebreid en dat daardoor reeds ontwikkelde software moet worden aangepast. Dit zal in bepaalde gevallen van nieuwe ontwikkelingen leiden tot houtje touwtje oplossingen waar niemand op zit te wachten en wat uiteindelijk een dure oplossing wordt. M.i. werkt deze aanpak prima als software wordt ontwikkeld die gebruik maakt van een bestaande database.

    • Nicole de Swart

      Cees, vroeger was dat inderdaad zo en was het dus niet verstandig om op de door mij genoemde manier te werken. Echter met de komst van agile en in dit verband vooral de technische agile practices is dat geen probleem meer, sterker nog de kwaliteit van software wordt beter. Daarvoor moet je dus wel op een andere manier gaan ontwikkelen.

  • Eric Pauwels

    Vroeger (Waterfall) lag zowel de scope, het budget en de tijd op voorhand vast en het resultaat was… vaak of 60% van de scoop of over budget en/of over tijd.
    Bij Scrum ligt de tijd en dus ook het budget vast en de business (proxy customer) bepaalt wat het team hiervoor aflevert. Dankzij het voortschrijdend inzicht en hoogste business value eerst, zijn we zeker dat het project een grote bijdrage aan de businessbehoeften levert

Geef een reactie