Follow Us on Twitter

Betere besluitvorming door model gestuurde Agile projectplanning

Gepubliceerd in

November 2016 – Als Product Owner mag je iedere Sprint je handtekening zetten onder een rekening van 40.000 Euro. Dat is een gemiddelde gebaseerd op 7 personen in het team met een tarief van 80 Euro per uur en Sprints van twee weken. Na drie maanden ben je alweer een kwart miljoen verder.

Je zou en mag verwachten dat de Product Owner met zulke investeringen grip heeft op de balans tussen investeren en waarde creëren. “Wanneer is het product goed genoeg, hoeveel moeten we nog investeren?”. Ook de opdrachtgever heeft dringende vragen. “Wat gaat het kosten en wanneer is het af?”.

Helaas kunnen deze vragen vaak niet beantwoord worden. Een Agile project starten is een sprong in het diepe en het wordt een lang traject van nagelbijten. Dat kan ook anders. In dit Whitebook beschrijf ik een werkwijze die inzicht creëert én rekening houdt met de onzekerheden van een Agile planning.

De wetenschappelijke aanpak voor onzekerheid

Agile/Scrum is een raamwerk voor productontwikkeling. Het kenmerkende van productontwikkeling is dat er veel onzekerheden zijn. Het product bestaat immers nog niet en moet nog ontwikkeld worden. Het Scrum-proces kent daarom ook een sterk empirisch karakter. Iedere Sprint wordt een nieuw onderdeel van het product ontwikkeld. Daarna volgt een Review waarbij vastgesteld wordt in hoeverre het nieuwe onderdeel voldoet aan de wensen. Eventueel wordt de Product Backlog bijgesteld. Daarna start de volgende Sprint.

Ook de wetenschap kent sinds jaar en dag een empirische werkwijze om kennis te vergaren. Ook hier is sprake van een cyclisch proces van leren en verbeteren:


Jan van Eijck (1984), Filosofie: een inleiding, Meppel: Boom.

De stappen in de wetenschappelijke aanpak zijn 1 op 1 te matchen met Agile/Scrum:

Wetenschap  Agile/Scrum 
Hypothese
 
De Product Backlog bevat allerlei wensen in de vorm van User Stories, Incident meldingen, Epics, etc. De hele Product Backlog kan worden beschouwd als een hypothese, want alle wensen zijn niet in de praktijk getoetst door een gerealiseerd en werkend product.
Voorspellen
 
Zowel de waarde (Business Value) als de omvang (Story Points) van een Product Backlog Item kunnen geschat worden. Het blijft echter theorie, want je weet pas wat je krijgt en wat het gekost heeft als het af is en in gebruik genomen is.
Toetsen   De beste manier om een werkend product te toetsen is het in productie te nemen en te gebruiken. Als dat niet kan zijn er minder sterke manieren, zoals schaduwdraaien, een pilot of een uitgebreide acceptatietest.  
Evalueren   Vanuit het toetsen ontstaan nieuwe inzichten. Deze nieuwe inzichten leiden tot nieuwe Product Backlog Items en/of tot een gewijzigde planning.  

Tot zover eigenlijk niets nieuws. Wat kunnen wij leren van de wetenschap als het gaat om het plannen van een Agile project?

De hypothese versterken met een model

Een Product Backlog met een hele serie van kleine en grote wensen zou voor een wetenschapper weinig waarde hebben als model voor een hypothese. De vraag “Wanneer is het af?” kan niet beantwoord worden met zo’n model en dat blijkt ook in de praktijk een moeilijke vraag te zijn voor een Product Owner.

Om de vraag beantwoord te krijgen is meer inzicht nodig in het te ontwikkelen product:

  • Welke onderdelen bevat het product?
  • Zijn er onderlinge afhankelijkheden tussen die onderdelen?
  • Wat is de inspanning per onderdeel?
  • Etc.

We zijn in eerste instantie geïnteresseerd in de grote brokken functionaliteiten, in “Epics”. Bij het maken van een webshop zouden dat bijvoorbeeld de volgende Epics kunnen zijn: catalogus, zoeken, winkelmandje, iDeal betaalmodule, creditcard betaalmodule, etc.

In de meeste gevallen is er meer voor nodig om een product te realiseren dan alleen het lineair “afvinken van gerealiseerde Epics”. Alhoewel een model per definitie een vereenvoudigde weergave van de werkelijkheid is, is de aanpak meestal complexer en hoort daar een complexer model bij. 

Enkele voorbeelden:

Voorbeeld 1
Eerst een maatwerk zaaksysteem ontwikkelen en dan uitrollen over meerdere afdelingen. Het idee is dat het te ontwikkelen zaaksysteem generiek inzetbaar is voor alle afdelingen. De eerste fase van het project bestaat uit het ontwikkelen van het zaaksysteem. Daarna vindt per afdeling een implementatieactiviteit plaats, waarbij het systeem wordt ingericht, in gebruik wordt genomen en in beheer wordt genomen. De verwachting is dat er bij iedere uitrol kleine wijzigingen op het systeem moeten worden doorgevoerd.

De grafiek geeft de volgorde van de componenten aan en de aard van de activiteiten.

Voorbeeld 2
Eerst worden enkele basis features ontwikkeld. Daarna wordt het nog eenvoudige systeem uitgerold over alle afdelingen. Daarna wordt het systeem mooier gemaakt en tegelijkertijd uitgerold over de afdelingen.

De essentie van het maken van een model is dat het team inzichtelijk maakt welke aanpak wordt gevolgd en welke aannames daarbij worden gehanteerd.

Bij voorbeeld 1 zijn de volgende aannames zichtbaar:

  • We maken eerst alle features af, daarna start pas de implementatie;
  • Bij iedere implementatie moeten we nog wat sleutelen aan het product;
  • Bij iedere nieuwe implementatie wordt er minder gesleuteld.

Bij voorbeeld 2 zijn weer andere aannames zichtbaar. Het gaat hierbij niet om de vraag of het model van voorbeeld 2 beter is dan het model van voorbeeld 1. Waar het wel om gaat is dat het team probeert een model te ontwikkelen wat past bij de situatie van het team, en dat tegelijkertijd de impliciete ideeën en aannames expliciet gemaakt worden.

Voorspellingen toevoegen

Op basis van het model wordt het mogelijk voorspellingen te gaan doen.

In principe kent iedere Epic een bepaalde omvang, bijvoorbeeld uit te drukken in een hoeveelheid Story Points, maar dan wel op een heel andere schaal dan de Story Points van een Product Backlog Item.

Om te komen tot een schatting per Epic zijn de volgende methoden mogelijk:

  • “Best Guess” schatten
    Zonder ervaringscijfers is het vaak toch mogelijk om te schatten op gevoel. Bijvoorbeeld: 2 Sprints voor feature A.
  • Epics relatief schatten t.o.v. elkaar
    “Wij denken dat feature B ongeveer even groot is als feature A”.
  • Extrapoleren
    “We hebben nu 50% gerealiseerd van feature A en hebben daar 1 Sprint voor gebruikt. Het restant zal waarschijnlijk nog 1 Sprint kosten”.
  • Een pilot
    Als het echt niet anders kan dan is een pilot mogelijk om een eerste inzicht te krijgen in de omvang.

Natuurlijk is een combinatie van deze methoden ook mogelijk. Op basis van de schattingen kan (bijvoorbeeld in Excel) het model compleet gemaakt worden. De aannames (qua schattingen) kan je hierin expliciet maken, dus zichtbaar tonen als factor of cijfer in Excel.

Onderstaand het model behorende bij voorbeeld 1 in Excel:

Leereffect implementatie 25%     
       
Epic Factor  Schatting SP  Cummulatief 
Feature a (ijkpunt)   100 100
Feature b 1 100 200
Feature c 1,5 150 350
Feature d 1 100 450
Feature e 0,5 50 500
Afdeling a (ijkpunt)   40 540
Afdeling b   30 570
Afdeling c   23 593
Afdeling d   17 609
Afdeling e en f   13 622

De aannames zijn:

  • Feature A is geschat op 100 SP.
  • De features zijn onderling geschat, uitgedrukt in een factor t.o.v. feature A.
  • De eerste implementatie kost 40 SP.
  • Iedere nieuwe implementatie is 25% sneller dan de vorige.
  • Afdelingen e en f kunnen tegelijkertijd.

Het model toont op dit moment aan hoe groot de omvang van het product is (622 SP). Daarmee kan je nog geen voorspelling doen van de doorlooptijd, dus een planning.

Wat ontbreekt is een schatting van de Velocity van het team, dus de hoeveelheid Story Points die geleverd kan worden per Sprint. De Velocity is echter eenvoudig berekenbaar als er al ervaringscijfers zijn. Als er geen ervaringscijfers zijn moet de Velocity geschat worden. Als de Velocity wordt toegevoegd aan het model is een voorspelling mogelijk. Onderstaand een voorbeeld.

Op basis van het model, inclusief de aannames en op basis van een Velocity van 40 SP zou het product in 16 Sprints gereed moeten zijn.

Natuurlijk is dit een eenvoudig voorbeeld. Er moet bijvoorbeeld ook nagedacht worden over wat bij elkaar past in een Sprint. Ook is de Velocity geen constant gegeven.

De resultaten toetsen

De resultaten van iedere Sprint worden op verschillende manieren getoetst. De eerste toets is de kwaliteitstoets. De klant en/of gebruikers bepalen de waarde van hetgeen is opgeleverd. Eventueel ontstaan nieuwe User Stories.

De tweede toets is de planningstechnische toets. Klopt het resultaat met de voorspelling?

Het is belangrijk om iedere User Story in de administratie te koppelen aan een Epic. Op deze wijze kan ook per Epic de voortgang getoetst worden en kan beoordeeld worden of de geschatte omvang van de Epic nog klopt.

Evalueren en model bijstellen

Op basis van de nieuwe inzichten wordt het model bijgesteld. Hierbij is alles weer mogelijk. De volgorde en de inhoud van de Epics, de omvang van de Epics. Alles mag aangepast worden. Het is uitdrukkelijk niet de bedoeling om de werkelijkheid aan te passen op het model. Het is juist de bedoeling om te leren en op basis van feiten en nieuwe inzichten het model aan te scherpen.

Je mag van een opdrachtgever vragen om respect te hebben voor de onzekerheden in een Agile aanpak. Aan de andere kant moet de vraag van de opdrachtgever om een planning gerespecteerd worden. Daar hoort transparantie bij over de aannames die het team doet en daar hoort ook bij dat het onder de planning liggende model aangepast mag worden.

Als het goed is wordt gedurende het project het voorspellende vermogen van het model steeds beter, omdat het model continu wordt aangescherpt op basis van hetgeen geleerd is.

Nog enkele tips

Start met een sprint 0
Ieder project, Agile of niet, begint met een besluit om te starten. Als het even kan probeer je daar te voorspellen wat de Business Case van het project is (kosten versus baten).

Juist bij een Agile aanpak, met alle onzekerheden die er zijn, is het verstandig om meteen een model op te stellen als basis voor de besluitvorming. De opdrachtgever weet meteen op basis van welke aannames de kosten en baten gecalculeerd worden en heeft een beter beeld van de risico’s. De opdrachtgever kan bijvoorbeeld vragen om een risicovol onderdeel als eerste op te pakken.

Gebruik een spint 0, een hoeveelheid tijd vóór de eerste sprint, om dit soort zaken uit te werken.

Werk het model iedere Sprint bij
Het mag vanzelfsprekend zijn dat het model na iedere Sprint getoetst en bijgesteld moet worden. Geef de opdrachtgever feedback op de nieuwe inzichten, het aangepaste model en de bijbehorende planning. Eigenlijk toets je iedere Sprint de Business Case van het project met behulp van het aangepaste model.

Maak het niet te ingewikkeld
Het complex maken van het model levert in de praktijk geen betere voorspelling op, maar gaat wel extra tijd kosten om te evalueren en beheren. Het gaat om de grote lijn, de Epics, niet om een Story Point meer of minder.

Betrek het hele team erbij
Stel het model samen met het team op. Het model is gebaseerd op de op te leveren producten. Het team maakt die producten en heeft daardoor inzicht in wat daarvoor moet gebeuren en wat de afhankelijkheden zijn.

Blijf eerlijk en transparant
Als het team moeite heeft om iedere Sprint een werkend product op te leveren, dan heeft het geen zin om een model op te stellen wat suggereert dat het wel iedere Sprint lukt. Het is niet erg als de Agile volwassenheid nog niet op het gewenste niveau is, maar maak het dan wel transparant. In principe is het zo dat iets wat niet Done is, ook niet meegeteld wordt in de Velocity.

Het is ook mogelijk om in het model rekening te houden met “housekeeping” activiteiten zoals rework, refactoren, bugs, etc. Er zijn verschillende manieren om dit soort zaken mee te nemen in de planning. Waar het om gaat is dat je model eerlijk en transparant blijft.

Wanneer heb je een model nodig?
Als al het werk zeer voorspelbaar is, dan is waarschijnlijk geen model nodig. Echter, hoe vaak komt dat eigenlijk voor en waarom volg je dan een Agile aanpak?

Zelfs bij Agile projecten vallen we te vaak in de valkuil om te denken dat we het resultaat kunnen voorspellen en dat we afwijkingen beredeneren naar gewenste antwoorden. Ik hoef denk ik niet uit te leggen hoe dat in de praktijk uitvalt. Mijn advies is om altijd een model op te stellen en om dat model te toetsen op basis van deelopleveringen die daadwerkelijk in gebruik genomen worden. “The proof of the pudding is in the eating”.

Conclusie

Voorspellen van de doorlooptijd van een Agile project is wel degelijk mogelijk, mits het team de moeite neemt om de aanpak, inhoud en omvang van het project in een model te gieten. Onzekerheden zijn geen hindernis om zo’n model te maken, maar zijn juist expliciet een onderdeel van het model.

Als het opstellen, evalueren en aanpassen van het model een standaard onderdeel wordt van het Agile proces, stel je de opdrachtgever tijdig in staat om besluiten nemen over geld en tijd.

Waardering:
 
Tags:

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.