SAFe PI planlægning: Den største opfindelse siden opvaskemaskinen!

I min personlige version af menneskehedens udviklingshistorie er der nogle vigtige milepæle: Det starter med opfindelsen af hjulet. Den næste store var opvaskemaskinen. Det følte jeg i hvert fald, som far i en familie med 3 børn og to hårdtarbejdende forældre. Den næste store ting var agil udvikling, som jeg først stiftede bekendtskab med i form af eXtreme Programming, i starten af dette årtusinde. Næste store skridt for menneskeheden er så SAFe, der giver os en metode at opnå fordelene ved agil udvikling også i store organisationer.

I SAFe hedder den centrale enhed et “Agile Release Train” - et team af teams. På samme måde som et agil team har en række ritualer, man er blevet enige om at følge, er der en række ritualer på team-af-teams niveauet. Et af dem er fælles “Big-room” planlægning.

Når mange mennesker skal arbejde sammen om et agilt projekt, kan det være svært at sikre koordination og overblik, og det er ofte en udfordring at opnå den høje grad af selvorganisering og ejerskab, som er sådan en vigtig drivkraft i agile teams.

Det mest almindelig er, at der ikke er nogen der har det store overblik, eller at det kun er en “super-projektleder” der ved, hvad der egentlig foregår.

Symptomerne er mange: Dårlig kvalitet, lav produktivitet og uerkendte afhængigheder, masser af: “Hovsa - vi troede at nogle andre gjorde noget, som vi ikke har fået aftalt med dem”.

Resultatet: forsinkelser og konstant brandslukning, da alle venter på hinanden og de samlede løsninger bliver integreret alt for sent i forløbet.

SAFe’s svar på dette er at man afholder 2 dages fælles planlægning 4-6 gange om året, hvor alle (ja, ALLE!) der arbejder sammen på en større løsning, er sammen om at lægge planen for det næste Program Increment, som det hedder i SAFe terminologien. Et Program Increment varer typisk 8-10 uger.

Vi starter typisk med, at alle får den samme information om vision, prioriteter og fælles tekniske emner. Dernæst udformer og estimerer hvert team user stories, i samarbejde med deres PO (Product Owner) og andre teams. Det hele udmunder i en midlertidig plan, som er lavet af de enkelte teams og afstemt med andre teams planer, så man tager højde for, hvor teams er afhængige af hinanden og tager stilling til risiko.

Denne plan præsenteres sidst på dagen, og efter en god nats søvn, og muligvis justeringer, udarbejdes den endelige plan i løbet af den næste dag.

Jeg møder ind imellem mennesker, der er skeptiske overfor denne praksis. Indvendingerne går nogen gange på, at man da ikke kan planlægge så lang tid ud i fremtiden -  “Det er jo ikke agilt!” og andre gange på, at det er alt for kostbart at involvere alle personer. Endelig er der nogen der har den fejlagtige opfattelse, at man skal kende alle detaljer for at kunne lave en plan.

Hvad kommer der ud af det?

1. Alle er sammen og kan umiddelbart afklare og lave aftaler, der ellers ville tage lang tid.

2. Fælles retning - alignment

3. En backlog for hvert team

4. Afhængigheder er identificeret og forhandlet

5. Teams har lavet deres egen plan. Det giver ejerskab og realisme

Er det tiden og pengene værd? Tja man kan også spørge om man har råd til at lade være. De omkostninger, der følger af dårlig koordinering, sent opdagede afhængigheder og uklare mål, er svære at gøre op i kroner og ører, men i de allerfleste store programmer, vil de langt overstige omkostningerne ved 2 dages fælles planlægning.

Er der ikke nogen alternativer tænker du måske? Jo, det ville ikke være fair at lade være med at nævne dem.

Man kan:

  • Nedskalere: Trim projektet ned til et enkelt eller to teams. Så er behovet for koordination langt mindre og enklere.
  • Bruge et andet rammeværk end SAFe: Der er nogle stykker på markedet. De mest udbredte og omtalte på vore breddegrader er LESS og Nexus.  

Begge er bestemt en mulighed, særlig for virksomheder som vil gå mere radikalt til værks, og bl.a.  organisere sig uden hierarkier og siloer og de mange roller man normalt har i store virksomheder.

Læs mere om SAFe her: http://www.scaledagileframework.com/
Læs om LeSS her: http://less.works/
Læs om Nexus her: https://www.scrum.org/Resources/The-Nexus-Guide