Follow Us on Twitter

Agile releaseplanning met PRINCE2 toleranties en Scrum Business Value

Gepubliceerd in

Juni 2012 – Met een agile projectaanpak zoals bijvoorbeeld Scrum wordt vaak gestuurd naar een vaste opleverdatum in combinatie met een variabele projectscope. Scrum kent een aantal instrumenten om de status en voortgang van zo'n agile project te bewaken. Bij sommige organisaties wordt een meer formele methode gehanteerd om projecten aan te sturen, bijvoorbeeld PRINCE2.

Dit whitebook toont aan op welke wijze PRINCE2 en Scrum elkaar kunnen aanvullen in het sturen van projecten met een variabele scope.

PRINCE2 en agile?

PRINCE2 is een erg goed schaalbare methode. Onze ervaring is dat PRINCE2 en Scrum elkaar aanvullen. Een goede PRINCE2/Scrum implementatie is lean, kent de "slankheid" en effectiviteit van Scrum en levert net een beetje meer sturingsmogelijkheden op voor de opdrachtgever dan alleen Scrum. In onze eerdere whitebooks is hier al veel over geschreven.

PRINCE2 toleranties

De PRINCE2 methode is opgebouwd rondom 7 principes. Als een project voldoet aan deze 7 principes dan is het een PRINCE2 project.

Principe 5 van PRINCE2 betreft "management by exception".
Programmeurs vertalen de Engelse term exception misschien als een "fout", waarbij het management moet ingrijpen als er iets fout gaat. Een meer juiste vertaling is "delegeren van de dagelijkse operationele projectaansturing binnen vastgestelde grenzen". In PRINCE2 wordt in een projectplan beschreven wat de grenzen (toleranties) zijn waarbinnen het project zelfstandig zijn gang mag gaan.

PRINCE2 toleranties

Voor een project kan iedere combinatie van tolerantietypen vastgesteld worden. Bijvoorbeeld de duur van het project mag 1 maand uitlopen buiten de vastgestelde planning van 1 jaar als de kosten dan niet stijgen met meer dan 5% boven het vastgestelde projectbudget.

Het gebruik van toleranties is geen truc van het management om projecten schijnbaar minder tijd of geld te geven, maar is een positief instrument waarbij het project vertrouwen en zelfstandigheid krijgt.

Het tolerantietype scope is uiteraard erg geschikt om variabele scope projecten aan te sturen. Als opdrachtgever kan je bijvoorbeeld MOSCOW gebruiken om een minimaal verplichte en additioneel gewenste scope te definiëren, maar hoe richt je dat in?

Scrum Business Value

Scrum is een iteratieve en incrementele aanpak om producten te ontwikkelen. In vaste timeboxen van 1 a 4 weken (een Sprint) wordt telkens een deel van het product ontwikkeld. Vaak wordt de opleverdatum vastgezet op een specifieke datum en is het van te voren niet precies aan te geven welke functionaliteiten op dat moment gereed zijn. Scrum kent gelukkig wel een aantal instrumenten waarmee tussentijds gestuurd kan worden op het gewenste projectresultaat.

De drijvende motor binnen het Scrum proces is een lijst waarin de werkvoorraad beschreven staat. Deze lijst (Product Backlog) bevat individuele werkpakketten (Product backlog Items), waarvan een deel in iedere Sprint opgepakt en gerealiseerd wordt (de Sprint backlog).

Er zijn allerlei manieren om een Product Backlog Item te beschrijven. Belangrijk in de context van dit Whitebook is dat een Product Backlog Item een bepaalde waarde heeft voor de opdrachtgever, een Business Value. De werkvoorraad op de Product Backlog is variabel in omvang maar in ieder geval gesorteerd op Business Value. Belangrijke functionaliteiten worden dus opgeleverd vóór de minder belangrijke functionaliteiten.

Product backlog

De definitie wat Business Value inhoudt wordt niet door Scrum ingevuld. Het moet een definitie zijn die duidelijk genoeg is voor de opdrachtgever en het team om goed te prioriteren en wordt bij ieder project op maat vastgesteld.

Door de definitie van Business Value op werkpakket niveau ontstaat een beeld van de totale werkvoorraad binnen een Scrum project. Om voorspellingen te kunnen doen wat het project wanneer gaat opleveren is meer nodig.

Scrum project planning

Naast een Business Value kent ieder Product Backlog Item ook een schatting van de inspanning om dit item te realiseren (Story Points). Ieder Product Backlog Item is in essentie een mini Business Case: " is het mij waard om deze inspanning te leveren voor de waarde die het oplevert".

Een agile planning is opgebouwd uit de volgende componenten:

  1. Hoe groot is de totale werkvoorraad?
    Een optelsom van alle Story Points.
  2. Wat is de huidige ontwikkelsnelheid (Velocity)?
    Hoeveel Story Points worden iedere Sprint opgeleverd?
  3. Wat is de geschatte toekomstige ontwikkelsnelheid?
    De toekomstige ontwikkelsnelheid wordt geschat op basis van eerdere Sprints.

De combinatie van deze drie componenten geeft inzicht hoeveel Sprints nodig zijn om de gewenste scope op te leveren, of hoeveel scope wordt opgeleverd met het vastgestelde aantal Sprints.

In onderstaande eenvoudige voorbeeld bedraagt de scope 300 SP, is in 6 Sprints 30 SP per Sprint opgeleverd. Met nog 4 Sprints te gaan is het project klaar.

Agile planning

In een complexer en meer realistisch scenario er is geen sprake van een vaste omvang van de scope. Op basis van de Business Value is een een Must Have scope gedefinieerd en daarnaast een aantal smaken optionele scope. In onderstaand voorbeeld geeft de rode lijn de minimale vereiste scope aan. De groene lijn is de gewenste hoeveelheid scope. Er is meer scope gedefinieerd, maar dat is optioneel (de blauwe lijn).

In dit scenario is het project na Sprint 9 klaar op basis van de gewenste scope doelstelling (in een nog meer realistisch scenario veranderen de schattingen bij iedere Sprint. Dat zou echter het voorbeeld minder leesbaar hebben gemaakt en verandert de essentie van het Whitebook niet).

Agile planning (complexer)

Agile PRINCE2 planning

De contouren voor een agile projectplanning met PRINCE2 zijn inmiddels duidelijk. Een tolerantiegrens kan op scope gedefinieerd worden. Dat kan bijvoorbeeld met een MOSCOW definitie zoals in dit bovenstaande voorbeelden aangegeven, maar andere definities zijn ook prima.

Een nog niet beschreven praktisch punt is dat een duidelijke relatie gewenst is tussen de definitie van Business Value voor een individueel Product Backlog Item en daarnaast de definitie op projectniveau wat minimale scope is en wat optionele scope is.

Als de relatie niet duidelijk is wordt het moeilijk vast te stellen welk deel van de projectscope af is bij afronding van een PBI. En hoeveel Sprints zijn er dan nog nodig? Daarnaast is er een groot psychologisch voordeel als de projectdoelstelling 1 op 1 terug te relateren is naar de Business Value van individuele werkpakketten. Het creëert focus en voorkomt discussies.

Een voorbeeld:
Een bedrijf vervangt de complete ontwikkelarchitectuur door nieuwe technologieën en tools. Ook het ontwikkelproces en de infrastructuur worden onder de loep genomen. Uiteindelijk moeten alle bedrijfsprocessen opnieuw ontwikkeld worden in de nieuwe technologie. Het is echter essentieel dat de ontwikkelarchitectuur goed functioneert voordat al die bedrijfsprocessen worden ontwikkeld, anders ontstaan er grote risico's voor kwaliteit en kosten. Er wordt 1 bedrijfsproces geselecteerd dat als eerste wordt ontwikkeld. Hiermee wordt snel vastgesteld of alles naar behoren functioneert.

De volgende Business Value is gedefinieerd:

  1. We ontwikkelen voor ieder deel van de IT architectuur een voor de gebruiker werkend en zichtbaar deel van het bedrijfsproces, waarmee we aantonen dat we een goed functionerend bedrijfsproces kunnen bouwen met behulp van de nieuwe ontwikkelarchitectuur.
  2. We ontwikkelen een primair bedrijfsproces met gelijkwaardige functionele rijkheid vergeleken met het huidige bedrijfsproces;
  3. We ontwikkelen secundaire takken van het bedrijfsproces met gelijkwaardige functionele rijkheid vergeleken met de huidige bedrijfsprocessen;
  4. We verbeteren de bedrijfsprocessen t.o.v. de huidige processen.

De Must Have scope bestaat uit alle PBI met Business Value 1 en 2, waarbij geldt dat vanwege risicomanagement Business Value 1 voorrang heeft op 2.

De Should Have scope bestaat uit alle PBI met Business Value 3. Optioneel is BV 4. (Hierbij wordt nog wel gekeken naar de inspanning. Eventueel krijgt een BV 4 voorrang op een BV 3 als er verbeterd kan worden met lagere kosten dan het gelijkwaardige alternatief).

Deze definitie van Business Value is zowel te hanteren op project niveau als op het niveau van de Product Backlog. In de projectplanning kan eenvoudig uitgerekend worden hoeveel werkvoorraad nog aanwezig is in de Product Backlog en binnen welk deel van de scope. Tijdens de uitvoering van het project is het duidelijk welke keuzes gemaakt moeten worden op het gewenste projectresultaat te bereiken.

In PRINCE2 terminologie zijn de volgende toleranties gedefinieerd op basis van de Business Value: "Er zijn 10 Sprints beschikbaar gesteld voor het project. Realiseer hierbinnen minimaal de Must Have scope (BV 1 en 2) en bij voorkeur ook de Should Have scope (BV 3)".

Na de 10 Sprints wordt de status besproken. Het is niet erg als niet de volledige Should Have scope gerealiseerd is, dat zou erg optimistisch zijn. Het is wel erg als de Must Have scope niet gerealiseerd is. In dat geval is onvoldoende aangetoond dat de nieuwe ontwikkelarchitectuur voldoet. Van de projectmanager wordt verwacht dat hij zo'n situatie actief signaleert naar de Stuurgroep op het moment dat het inzicht ontstaat dat het niet haalbaar is (een exception volgens PRINCE2). Dat is dus eerder dan pas na Sprint 10.

Conclusie

Het managen van agile projecten vanuit een PRINCE2 besturingsmodel is erg eenvoudig als het PRINCE2 instrument van toleranties wordt toegepast. Het is daarbij wel handig als er gebruik gemaakt wordt van agile instrumenten voor planning en voortgang.

PRINCE2 toleranties kunnen gedefinieerd worden op 6 verschillende projectaspecten, waarbij scope en tijd de meest voor de hand liggende zijn voor agile projecten. Het is verder verstandig de toleranties vast te stellen met een definitie die het team ook operationeel kan toepassen bij het waarderen en prioriteren van werkpakketten. Zo praten we allemaal dezelfde taal: opdrachtgever, projectmanager en team en hebben we allemaal hetzelfde beeld bij de status van het project.

Referenties

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.