PRINCE2 + Scrum: 1 + 1 = 3

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.

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

• Whitebook "PRINCE2, licht en effectief"
• Whitebook "Releaseplanning met Scrum"
• Whitebook "PRINCE2 2009, nieuwe inzichten en nieuwe kansen?"
• Whitebook "Snel succesvolle projecten uitvoeren"