Prince2 og Scrum

På det sidste har vi fået mange spørgsmål om, hvordan man kombinerer Prince2 med Scrum. Der er mange steder i det offentlige i Danmark, hvor Prince2 bare skal bruges, og det kryber også ind i Norge nogle steder nu. 

Prince2 beskrives som et “governance” system og er i natur en såkaldt “stage-gate” model, hvor et initiativ eller projekt deles op i faser (stages), og hvor man kun kan komme til næste fase ved at gå igennem en port (gate). Visse betingelser skal være tilstede for at kunne passere, herunder at den business-case, der startede projektet stadig er gyldig. Det er der jo ikke noget galt med. De fleste vil være enige om, at det er en god ide at stoppe op med faste intervaller og verificere, at vi er på ret kurs. Det lyder næsten som Agile og Scrum :-).

Prince2 har introduceret et Prince2 Agile koncept, som forsøger at skabe rum til at selve eksekveringen af arbejdet kan gøres agilt, f.eks. ved hjælp af Scrum. Såvidt man læse sig til det, er der mange fornuftige tanker. Blandt andet bruger man, ligesom os, Cynefin som tankemodel til at forstå, hvor komplekst arbejdet er, og dermed hvilken angrebsvinkel, man skal anlægge.

Men den grundlæggende DNA i Prince2 er stadigvæk som i figuren ovenfor, Plan-Delegate-Monitor-Control. Det er altså en model, der skal sikre at folk holder sig til en plan og et budget, forandringer er exceptions. I modsætning hertil ses Scrum, Agile og Lean som en konstant bevægelse imod en bedre og bedre løsning, som opdages undervejs. I større projekter, der bruger Scrum, er der naturligvis også en langtidsplan, men den består vigtige milepæle og ydre begrænsninger, vi må indrette os efter. Vi kalder den ofte dette en Roadmap.

Hvis man anstrenger sig lidt, kan man godt få denne overordnede fase model til at passe sammen med Scrum og agile. Men der er nogle faldgruber, som man skal være opmærksom på:

  • Prince2 kommer næsten altid med den bagage, at der er en skarp adskillelse mellem ledelse og udførelse (“Separation of thinking and doing”). Nogen lægger en plan og nogen udfører. Hvis dette princip får lov at slå igennem, mister man Teamets engagement; de læner sig tilbage og gør, hvad der bliver sagt. Prince2 kommer ud af samme urtebed som New Public Management, med Tayloristisk fokus på adskillelse af ledelse og udførelse, måltal og opfølgning. I stedet må vi fastholde, at ledelse er Servant Leadership, hvor lederen ser sig som servicerende dem, han har ansvar for.
  • I Prince2 er det snublende nemt at lave gates mellem faser til checkpoints op imod en eksisterende plan, ofte bliver dette til review af dokumenter, som eksperter har skrevet, fordi man har den adskillelse beskrevet ovenfor. I stedet bør disse gates være sessions, hvor man involverer alle og får revideret sin roadmap, sine milestones og de top level epics, der i næste fase bliver vigtige.
  • Det er nemt at tro, at man kan lave en mere detaljeret plan end virkeligheden egentlig giver baggrund for. Det er en meget almindelig kognitiv bias. I stedet må vi argumentere for at man accepterer en Roadmap på oversigtsniveau.
  • I Prince2 er det meget nemt at læse instruktionerne sådan at kommandoerne ripler ovenfra og ned fra styregruppe til projektleder til teamledere og til sidst til mig på gulvet. Alene brugen af ordet arbejdspakker leder os i den retning. Vi får ikke folk engagerede på denne måde. Vi fastholder meget nemt den gamle hierarkiske kommandostruktur.
  • I Prince2 er der en sand velsignelse af roller, der skal udføre forskellige ting. Det kommer nok af vores fascination af eksperterne. I praksis er det meget svært i et projekt at fastholde en fælles forståelse af hvem, der gør hvad, med så mange detaljer. Det har været et problem med alle heavy weight process modeller fra RUP i 90’erne til SAFe nu om stunder. I stedet må man få de roller, der er i Scrum til at levere de ting, der skal til for at Prince2, reelt kan bruge det til noget. Se f.eks. følgende tabel:

 

Prince2 kan være et krav i en organisation, og så må man jo indrette sig eller finde noget andet.

Dem, der er over et projekt, har ansvar for en portefølje eller et program, skal jo kunne følge op på tværs af projekter og prioritere mellem initiativer. Der er ikke noget galt med det. Men man må sikre sig konstant, at det indbyggede “push” i en compliance model mod primært at følge en plan og være forudsigelig, ikke tager livet af det agile. Man bliver nødt til at se kombination af Scrum og Prince som et overgangsstykke (Adaptor pattern), der gør at en traditionel hierarkisk organisation kan fungere med et hjørne, der kører agilt efter nogle helt andre præmisser.