Follow Us on Twitter

PRINCE2 + Scrum: 1 + 1 = 3

Gepubliceerd in

November 2009 - Scrum is een zeer effectief agile projectmanagement framework om in projecten snel resultaten te leveren. De 'methode Scrum' ligt erg dicht bij de onderliggende Lean principes. Dat is de kracht van de methode. De methode schrijft weinig voor en biedt veel ruimte voor een projectaanpak op maat. Het is tegelijkertijd ook de uitdaging. Het vergt veel kennis en begrip van die onderliggende principes om de juiste implementatiekeuzes te maken. Dat lukt lang niet altijd. Het internet staat vol met hulp vragen.

PRINCE2 lijkt een tegenovergestelde filosofie te volgen. De methode is op detailniveau uitgewerkt en lijkt weinig ruimte te bieden voor een projectaanpak op maat. Agility is ver te zoeken. Op het eerste gezicht lijkt een combinatie van PRINCE2 en Scrum dan ook onmogelijk.

Met dit Whitebook toon ik aan dat de combinatie wel degelijk kan. Sterker nog, het is juist de combinatie die bijzonder effectief is.

PRINCE2 licht en effectief

Dit Whitebook neemt aan dat er enige voorkennis aanwezig is over zowel PRINCE2 als Scrum.

Wat PRINCE2 betreft is het belangrijk te onderkennen dat ook PRINCE2 op maat gemaakt moet worden per project. Letterlijk het PRINCE2 handboek volgen zal bijna altijd leiden tot een mislukt project. Onze eerdere Whitebooks "PRINCE2, licht en effectief" en "PRINCE2 2009, nieuwe inzichten en nieuwe kansen?'' bieden wat dat betreft een goede inleiding.

Ook over Scrum is al veel gezegd. Zie onder andere onze Whitebooks "Releaseplanning met Scrum" en "Snel succesvolle projecten uitvoeren".

Positionering Scrum binnen PRINCE2

Het Scrum proces is vooral een uitvoerend proces. Het gaat vooral over het máken van de oplossing en veel minder over het managen van het projectproces. PRINCE2 gaat per definitie alleen over het managen van het projectproces. Hierdoor valt Scrum van nature binnen het "Managing Product Delivery" proces van PRINCE2.
Positionering Scrum binnen PRINCE2

Echter, Scrum kent wel degelijk aspecten die de andere processen van PRINCE2 raken. Andersom geredeneerd is ook een andere invulling nodig van enkele Scrum aspecten.
In eerste instantie zal ik de PRINCE2 + Scrum implementatie uitleggen vanuit het perspectief van bestaande implementatieproblemen met Scrum.

Daarna zal ik de combinatie verder invullen vanuit het PRINCE2 perspectief.

PRINCE2 oplossingen voor Scrum problemen

Het functioneren van de Product Owner

Een van de meest voorkomende problemen met Scrum betreft de rol van de Product Owner. In PRINCE2 terminologie is de Product Owner zowel de Senior Executive, de Senior User als de Senior Supplier. Het is niet voor niets dat PRINCE2 hier een andere rolverdeling kent, het is niet voor niets dat er in de praktijk zoveel problemen zijn met die Product Owner. Het is voor 1 persoon wel heel erg lastig om alle belangen te behartigen. De PRINCE2 invulling is veel volwassener en ook bewezen effectief. Omdat PRINCE2 tevens het "management by exception" principe hanteert kan de feitelijke inzet van de Stuurgroep zeer beperkt blijven, hetgeen mooi past bij de "Lean" principes achter Scrum.

In de combinatie PRINCE2 + Scrum worden de verantwoordelijkheden en taken van de Product Owner verdeeld binnen de Stuurgroep. In de strikte betekenis van het woord bestaat de Product Owner niet meer, deze is vervangen door de Stuurgroep.

Een additioneel voordeel van de Stuurgroep ten opzichte van de Product Owner is dat deze Stuurgroep meestal veel effectiever zal kunnen ondersteunen in het wegnemen van "impediments" (hindernissen). De Stuurgroep dekt immers alle belangen af, heeft de projecteindverantwoordelijkheid en heeft daardoor meestal ook de bevoegdheden om hindernissen weg te nemen.

Het functioneren van de Scrum Master

Een ander vaak voorkomend probleem is dat de combinatie van de Scrum Master met het team niet goed functioneert. Soms komt dit doordat de Scrum Master het team niet de ruimte geeft om zelfstandig te functioneren, soms komt dat omdat de Scrum Master niet in staat is de Scrum systematiek effectief te maken binnen het team. Ook gebeurd het dat een opdrachtgever of opdrachtnemer meer verantwoordelijkheden vraagt van de Scrum Master dan wat volgens de Scrum methode is toegestaan, simpelweg omdat men gewend is aan een projectmanager. Binnen Scrum is het team immers zelfsturend, de Scrum Master heeft geen bevoegdheden.

In mijn visie is het geen enkel probleem om zowel de verantwoordelijkheden te dragen van een projectmanager, als een effectief team te creëren met zelfstandigheid en daadkracht. In zowel de zuivere Scrum methodiek met een Scrum Master, als de PRINCE2 methodiek met een projectmanager komt het aan op de individuele kennis en kunde van de betreffende Scrum Master of projectmanager. Het voordeel van de projectmanager ten opzichte van de Scrum Master is dat de projectmanager wel de bevoegdheid heeft om in te grijpen als dat nodig is. De projectmanager heeft daardoor twee sturingsinstrumenten waarbij de Scrum Master maar een instrument heeft. In de linker hand het positieve instrument van delegeren en coachen, in de rechterhand de stok.

Start van het project

Scrum kent vaak een intensieve en chaotische start omdat de werkwijze nogal afwijkt van de traditionele waterval aanpak. Op zich zou dat geen probleem moeten zijn, het valt binnen het Scrum principe van leren door te doen. Bij een eerste iteratie is echter vaak de praktijk dat er wel heel erg veel leermomenten zijn, waardoor er in de ogen van de opdrachtgever nogal wat "mis gaat". Dit is maar voor een deel weg te nemen door het van te voren aan te kondigen. Zeggen is een ding, maar het ervaren is toch echt wat anders. In de Agile wereld zijn veel mensen dan ook voor een zogeheten "Sprint nul", een voorbereidingsfase voor de eerste iteratie. Wat daarbinnen moet gebeuren is echter onderdeel van discussie. Je wilt in ieder geval voorkomen dat het een soort analyse iteratie wordt. Terug naar waterval is zeker niet de bedoeling.

De voorbereidingsfase is dus erg belangrijk. Het vertrouwen in een agile aanpak zoals Scrum is initieel toch al in geringe mate aanwezig bij de opdrachtgever (zie de volgende paragraaf). Bovendien is het emotioneel voor alle betrokkenen, ook het team, een verkeerde start als er veel mis gaat. De voorbereiding hoeft ook helemaal niet zo intensief te zijn en kan zelf effectiever zijn voor het uiteindelijke projectresultaat.

Binnen PRINCE2 is de voorbereidingsfase een zeer belangrijk en integraal onderdeel van de methodiek, zie de processen "Starting up a project" en "Initiating a project".  Vooral het helder maken van de aanpak en het verkrijgen van commitment van de Stuurgroep zijn aspecten die ook bij Scrum waardevol zijn.

Vertrouwen

Een traditionele waterval aanpak biedt schijnzekerheid door het voorspellen van een vaste opleverdatum, projectprijs en/of opsomming van op te leveren functionaliteiten. Een agile aanpak zoals Scrum geeft geen zekerheid. De opdrachtgever moet er op vertrouwen dat het in orde gaat komen en dat het project snel gaat aangeven waar het project gaat eindigen.

Wat hierbij niet helpt is dat de Scrum aanpak bij veel mensen een onbekende aanpak is. Het helpt ook niet dat er volgens Scrum alleen een Product Owner bestaat die invloed kan  uitoefenen op het proces. Indien het project niet alleen wordt opgezet volgens Scrum, maar als een combinatie van PRINCE2 + Scrum, waarbij expliciet sturingsmogelijkheden aanwezig zijn met bekende PRINCE2 processen zoals "Directing a Project" is het makkelijker om de agile werkwijze te accepteren.

Product Backlog

In de Product Backlog worden alle openstaande wensen (User Stories) van de Product Owner vastgelegd. Dit is een nogal dynamische lijst want de lijst wordt continue bijgewerkt. Bovendien kunnen de wensen nogal verschillend van aard zijn en bestaan er vaak onderlinge afhankelijkheden. Het is lastig om zonder een aanvullende structurering van de wensen overzicht te houden. Het is interessant dat inmiddels op het internet oplossingen voorgesteld worden die bijzonder veel lijken op een PRINCE2 Product Breakdown Structure (PBS). Een hiërarchische indeling van de wensen.

De PBS kan een goede aanvulling zijn om overzicht te houden, mits vastgehouden wordt aan het INVEST acronym van Scrum.

Risico's

Scrum kent geen methode voor het managen van risico's. Dat is voor een deel ook niet nodig want veel risico's worden al impliciet bestreden door het in korte iteraties opleveren van de oplossing. Hierdoor wordt snel ontdekt of alles werkt of niet en kan in de volgende iteratie bijgestuurd worden. Alhoewel deze reactieve vorm van risicomanagement wel degelijk erg effectief is, dekt het niet het volledige gebied van risicomanagement. Er liggen ook genoeg uitdagingen buiten het team zelf, uitdagingen die het team niet kan oplossen, maar die wel het succes van het project beïnvloeden. Denk bijvoorbeeld aan afhankelijkheden met andere leveranciers. Juist voor dit soort risico's is het belangrijk dat de Stuurgroep geactiveerd wordt. PRINCE2 biedt hierbij een heel volwassen aanvulling op Scrum. Ook hier geldt dat het niet direct heel veel tijd hoeft te kosten en potentieel veel voordeel kan opleveren. Als de projectmanager goed Scrum volgt en tegelijkertijd ook de risico's expliciet rapporteert is het mijn ervaring dat de meeste risicomaatregelen bij de Stuurgroep liggen. Dat is erg goed omdat dan het team tijd kan besteden aan het creëren van waarde en niet aan het oplossen van problemen. In de terminologie van Scrum praten we eigenlijk over het proactief wegnemen van potentiële hindernissen m.b.v. het instrument van risicomanagement. Een belangrijke taak van de Scrum Master.

PRINCE2 verder agile maken

Bovenstaande opsomming van PRINCE2 oplossingen voor Scrum problemen beschrijft al een deel van de combinatie van PRINCE2 + Scrum. Het dekt nog niet alle aspecten die PRINCE2 agile maken.

Agile Business Case en Product Definities

Het is vanuit PRINCE2 toegestaan om de Business Case gedurende het project te detailleren. Dit impliceert ook dat het toegestaan is dat nog niet alle producten of de definities van alle producten bij de start van het project bekend moeten zijn. Een kenmerk van een agile aanpak is dat de projectscope dynamisch is. Het een sluit het ander dus niet uit.
Een goed functionerende aanpak is dat initieel het op te leveren product op hoofdlijnen wordt beschreven in een Product Definition. De detaillering van dit product vindt plaats gedurende het project door het opleveren van deelproducten.

De Business Case van het project groeit mee met de opleveren van deelproducten. Initieel is de Business Case vastgesteld op de initiële Product Definitie.

Toleranties

Het instrument van toleranties is bij uitstek geschikt in een agile aanpak. Toleranties kunnen bijvoorbeeld gezet worden op geld (= aantal iteraties plus teambezetting), op tijd (= aantal iteraties), op scope (bijvoorbeeld minimaal alle wensen afmaken met een specifieke Business Value).

Rapportages

Het is volgens de handleiding PRINCE2 2009 geen enkel probleem om de PRINCE2 sjablonen voor rapportages te vervangen door andere vormen van rapportages, zolang de informatiebehoefte van de ontvangende partijen maar gedekt wordt. Het is dan ook een heel goed idee om een aantal Scrum specifieke rapportagevormen mee te nemen in de rapportage naar de Stuurgroep. Met name de releasevoortgang op basis van geleverde Story Points per iteratie en de Velocity rapportages zijn bijzonder interessant voor de Stuurgroep.

Het is wel belangrijk dat de Stuurgroep instemt met het goedkeuren van een faseplan nadat de betreffende fase al gestart is. De Stuurgroep moet formeel immers een fase goedkeuren voordat deze fase start. Omdat met Scrum de fases elkaar bijzonder snel opvolgen is dat geen praktische afspraak. In mijn ervaring is het echter geen probleem om zo'n afspraak te maken. De Senior User in de rol van Product Owner heeft immers een grote rol in het vaststellen van de scope van een iteratie. Natuurlijk is het mogelijk om binnen een PRINCE2 management-fase meerdere technische fases te plaatsen (meerdere Scrum iteraties). Dan nog geldt dat het niet zo praktisch is om te wachten met starten totdat de goedkeuring komt. Een en ander is uiteraard ook afhankelijk van de specifieke projectcontext.

Lessons Learned

Lessons Learned zijn zowel bij PRINCE2 als Scrum een belangrijk hulpmiddel voor het effectief maken van het project. Er zijn geen specifieke aandachtpunten in de combinatie PRINCE2 met Scrum. Het is wel vermeldenswaardig dat juist in de combinatie van PRINCE2 met Scrum de Lessons Learned bijzonder effectief werken. Immers, iedere iteratie opnieuw wordt hetzelfde projectproces gevolgd met dezelfde mensen met gelijksoortige producten en in dezelfde hoeveelheid tijd. Oplossingen voor geconstateerde problemen kunnen direct toegepast worden en er kan heel snel geconstateerd worden of die oplossingen werken. Een heel groot verschil met de meeste Lessons Learned rapportages die pas opgesteld worden als het project af is. Dat zijn meestal Lessons Not Learned want je kunt er niets meer mee doen.

Conclusie

Scrum is een effectieve aanpak om snel projectresultaten te bereiken. Het vergt wel het nodige denkwerk, kennis en ervaring om de juiste implementatiekeuzes te maken. Scrum is dan ook beschreven als de "zuivere", ideale werkwijze. In de praktijk zal het zelden voorkomen dat de zuivere Scrum aanpak gevolgd kan worden. Als denkkader, "zo zou het moeten" werkt het prima. Je kan echter niet implementatiekeuzes maken vanuit een ideaalbeeld. Je moet keuzes maken vanuit de realiteit. Veranderen gaat nu eenmaal alleen goed in kleine stappen. (Dat zegt Scrum zelf ook: leren door te doen, niet door te voorspellen).

In de werkelijke wereld is PRINCE2 een bijzonder goede aanvulling op Scrum. Het team werkt vooral op de Scrum werkwijze. De projectmanager werkt volgens PRINCE2, waarbij PRINCE2 op een agile wijze is ingericht. Wat hierbij helpt is dat ook PRINCE2 adaptief is en overhead probeert te vermijden ("management by exception").  Zo ver hoef je dus niet af te wijken van de Lean principes achter Scrum.

Referenties

Waardering:
 

Reacties

Martin, Ik was begonnen aan een reactie op je post hier, maar dat begon wat uit de hand te lopen. Daarom heb ik het in een post gegoten: http://bartreyserhove.blogspot.com/2010/04/combining-scrum-and-prince2.html
Grappig. Iemand die weinig begrip van PRINCE2 heeft en er weinig zinnige dingen over zegt, maar uiteindelijk toch juiste conclusies trekt. Kijk voor de juiste visie in mijn LinkedIn profiel onder de Box Net functie. Er zijn daar diverse documenten die wel weergeven waar PRINCE2 over gaat. Er is daar ook een document te vinden hoe PRINCE2 en ontwikkelaanpakken te combineren zijn.
Beste Nico, Mijn aanpak is getoetst door Deloitte in het kader van een due dilligence audit. Na initiele scepsis ("PRINCE2 kan niet agile") is door hun bevestigd dat het wel degelijk een PRINCE2 project was. Ze beschouwden het zelfs als een "eye opener". Misschien heb ik toch wel een beetje begrepen hebben van PRINCE2. :-) Zowel de opdrachtgever als het team waren overigens erg enthousiast over de aanpak en het projectresultaat, dus het was niet alleen een PRINCE2 project, maar vooral ook een succesvol project. Ik heb nog even naar jouw documenten gekeken. Je geeft aan dat je de business niet moet vermoeien met een IT methode zoals bijvoorbeeld RUP. Dat ben ik helemaal met je eens. Het gaat uberhaupt niet om de methode, maar om mensen en hoe mensen samenwerken. De kracht van PRINCE2 is dat de methode op maat geimplementeerd kan worden voor de projectomgeving. Het probleem met PRINCE2 is echter dat veel mensen niet weten hoe dat moet of helemaal dit punt missen. Dat is dan ook de reden dat ik dit Whitebook heb geschreven. Ik laat zien dat je PRINCE2 niet dogmatisch hoeft toe te passen. Het kan heel anders dan de traditionele sequentiele waterval aanpak. Omdat ik een aanhanger ben van Lean/Agile gebruik ik de combinatie van Scrum en PRINCE2. Niet als stelling dat dit de enige manier is, er bestaat namelijk niet een manier die altijd werkt, maar omdat het een erg goede combinatie is waar veel mensen niet op komen. Daar ligt volgens mij een kans voor veel organisaties om PRINCE2 nog effectiever in te zetten, of om Scrum wat professioneler te managen. mvrgr Martin

Beste Martin, 

Prachtig voorbeeld hoe de Prince2 methodologie kan gealigneerd worden met de behoeftes van het project en de verschillende stakeholders.

Een toonbeeld van visie en strategie.

kr,

 

Kurt  

 

Heel erg bedankt voor deze verhelderende white paper. Een groto deel van mijn vragen omtrent de mogelijkheden van het combineren van PRINCE2 en Scrum zijn hiermee beantwoord.

Beste Martin,

Met veel interesse heb ik het whitebook gelezen over de combinatie van Prince2 en Scrum en ik zie daar veel mogelijkheden in voor mijn werk als projectmanager. In jouw whitebook stel je voor om de projectmanager zowel zijn eigen rol als de rol van scrum master te laten vervullen. Binnen onze organisatie wordt door 1 Scrumteam (zoveel ontwikkelaars, ontwerpers, etc. zijn er niet om meerdere teams te vormen) meerdere projecten tegelijkertijd uitgevoerd. Deze projecten worden niet altijd door 1 projectmanager geleid. Als iedere projectmanager tevens gaat fungeren als Scrum master, krijg je meerdere "kapiteins" op 1 schip wat mij niet bevordelijk lijkt voor het functioneren van het Scrumteam. Maar ik ben het wel helemaal eens met de situatieschetst dat de combinatie van de Scrum Master met het team niet altijd goed functioneert.

Daarnaast vroeg ik me af of het in de praktijk daadwerkelijk goed werkt om de product owner te vervangen door een stuurgroep. Daarin zitten diverse disciplines met ieder een "eigen agenda". Ik vraag me af hoe je meerdere projecten naast elkaar kunt uitvoeren, zonder product owner. Wie verzamelt dan alle eisen voor de product backlog en wie behartigt de belangen van diegene die input heeft gegeven aan de product backlog? Dit ook gezien het feit dat de samenstelling van de stuurgroep per project kan wisselen.

Het makkelijkste zou natuurlijk zijn om 1 project per keer uit te voeren, maar ik vrees dat onze organisatie daar niet zo geschikt voor is (gezien het grote aantal "wettelijke moetjes").

Ik ben benieuwd hoe jij tegen deze twee vragen aankijkt? Heb jij daar ervaring mee? Ik verneem heel graag jouw visie hierop en bedankt voor jouw whitebook. Helpt mij weer met het vinden van oplossingen voor projectmanagement issues waar ik in de praktijk tegenaan loop.

Hartelijke groet, Conny

Beste Conny,

Sorry voor de late beantwoording van jouw vragen, ik had jouw reactie gemist. :-/

Wat betreft de projectmanager is het zeker niet noodzakelijk om de rol van pm en scrummaster in 1 persoon te combineren. Het is een keuze die per project gemaakt moet worden. Ik geef in mijn whitebook in ieder geval aan dat combineren geen probleem hoeft te zijn. Een belangrijk argument wat mij betreft is de "span of control" van de pm, zeg maar "hoe druk" hij/zij het heeft. Als bij een niet agile project ook geen teamleider nodig is om het team aan te sturen, lijkt het mij in een agile project ook niet nodig om naast een pm ook een scrummaster in te zetten. Uiteraard onder de voorwaarde dat de pm de juiste skillset heeft.

Wat jouw situatie betreft kan ik mij goed voorstellen dat één scrummaster een betere keuze is dan verschillende pm'ers die afwisselend het team aansturen. Ik vraag me daarbij wel af wat die pm'ers dan daarnaast doen als zij niet met de it bezig zijn, misschien de business implementatie kant? Er zal vast een goede reden voor zijn. :-)

De grotere uitdaging in jouw organisatie zit in het prioriteren en verdelen van het werk. Dat probleem zou niet moeten spelen op pm niveau, scrummaster niveau of team niveau, maar zou geborgd moeten zijn bij de product owner of stuurgroep. Veel projecten kennen potentieel conflicterende belangen bij de opdrachtgever. Met het benoemen van een product owner is m.i. dat probleem vaak niet opgelost, maar eerder verdoezeld. De werkelijkheid is vaak dat er spanning blijf bestaan, echter voor de scrummaster meer verborgen. Hier kan Prince2 wel degelijk helpen met de stuurgroep constructie. Omdat de verschillende verantwoordelijkheden expliciet worden gemaakt help je juist de besluitvorming. 

In jouw situatie zou ik waarschijnlijk kiezen voor één stuurgroep, maar met verschillende senior users die afwisselend een rol spelen, afhankelijk van de prioritering en inzet van het team. Op deze wijze heb je iemand die verantwoordelijk is voor het team zelf en de geleverde kwaliteit en je hebt een scheidsrechter die overall verantwoordelijk is en kan prioriteren over de verschillende belanghebbenden. De senior users zijn dan tevens product owner.

m.vr.gr.

Martin

Heel helder verhaal. Leerzaam. Bedankt!!!

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.