Mange eksperter har tidligere udtrykt deres holdning til de store anerkendte rammeværk for skalering. Her beskriver de nogle af de udfordringer, der opleves i markedet med skalering ved hjælp af skaleringsrammeværk. Ved en simpel søgning på jobindex ser man en stigning i antallet af jobopslag med agile roller, f.eks. Scrum Master og Product Owner, men også de mere diskutable roller som Release Train Engineer, SAFe Program Consultant og Product Manager. Det understreger vigtigheden af at forstå mekanismerne bag rammeværkene men også konsekvenserne ved at indføre dem. Ligesom med fyrværkeri så kan resultatet være festligt og farverigt, men uden sikkerhedsbriller og fornuftig håndtering kan man hurtigt komme galt afsted.

Luxshan Ratnaravi, Agile Coach hos Bankdata, har lavet en liste af spørgsmål man kan besvare, for at finde ud af om skalering er korrekt, og om man skal anvende et prædefineret rammeværk. Oversat til dansk er spørgsmålene:

1. Hvilke udfordringer kan vi ikke løse uden at skalere?
2. Hvad vil vi opnå ved at skalere?
3. Kan eksisterende rammeværk hjælpe os – eller skal vi udvælge enkelte praktikker for at komme videre?
4. Hvilke indikatorer kan vi måle på, for at se om vi går i den rigtige retning?
5. Er teamene modne nok til at starte på en skalering?
6. Har vi forsøgt at reducere afhængigheder?
7. Organiserer vi os efter værdistrømme?
8. Er det muligt at skabe et mål og en vision på tværs af de teams, der skal skalere sammen?
9. Bliver teamene bedre sammen end hver for sig?
10. Skal teamene arbejde som feature-teams?
11. Er interessenterne enige i at investeringen i skalering er mindre end fordelene?
12. Prioriterer vi på tværs af teams, produkter og kompetencer?

Den type spørgsmål er super relevante, og bør indgå i enhver beslutning om skalering. I tillæg så er det min opfattelse, at skalering er en midlertidig håndtering af en fælles udfordring. Og hvad betyder det så? Det betyder at en introduktion af f.eks. SAFe bør ses som en måde at løse de midlertidige udfordringer der identificeres med de 12 spørgsmål. Over tid bør organisationen arbejde på at reducere behovet for tværgående mål og visioner med et slutmål om at kunne arbejde som selvstændige teams, der kan finde ud af at tale sammen retidigt med resten af organisationen.

Uanset hvilket rammeværk – eller intet rammeværk – der vælges, er det vigtigt, at forstå de bagvedliggende mekanismer. Det kræver både stor erfaring i metoderne, kendskab til organisationen samt evne til at implementere og facilitere. Det opnåes typisk ved en kombination af eksterne eksperter sammen med interne medarbejdere og ledere. Der findes intet, der kan implementers udelukkende af eksterne, med et håb om at organisationen efterfølgende kan løbe videre med opgaven. Det kræver en forandring af organisation, medarbejdere, arbejdsform og leverancemodel.

Det mest udbredte rammeværk for tiden er SAFe, som tilbyder noget så farligt, som en drejebog for, hvordan en organisation kan omstille sig fra traditionelle plandrevne metoder til noget, der minder om iterativ og inkrementiel udvikling. SAFe kalder det for “SAFe Implementation Roadmap”. Det farlige i drejebogen og egentlig i hele rammeværket ses flere steder:

• Drejebogen kan ses, som den eneste korrekte måde at gå fra A til B, og det er langt fra tilfældet. Rammeværket er skrevet ud fra een virkelighed og din organisation kan let have en anden og derfor kræve en anden sekvens.
• Uden dybere kendskab til de bagvedliggende mekanismer kan man introducere roller, events og artefakter uden at opnå en egentlig forbedring. Erfaringer fra fejlende transformationer fortæller at man blot har udskiftet eksisterende jobtitler med roller fra det nye rammeværk uden at tage hensyn til formålet i forhold til at skabe mere agilitet.
• Uden dybere kendskab til organisationen og produkterne kan man introducere teams, gruppering af teams og porteføljer, der ikke skaber værdi. De fleste organisationer har allerede introduceret teams i forskelligt format; nogle steder er de tilpasset systemporteføljen andre steder efter kompetencer. Hvis man ikke reorganiserer sig efter produkter og værdistrøm giver forandringen ingen værdi.
• Rammeværket kan ses som den endegyldige sandhed, hvor tilpasninger og forbedringer hos de enkelte teams ses som dysfunktioner. De forskellige events og artefakter har naturligvis et formål og det er det man skal tage hensyn til; hvilket format og hvilke detaljer der er relevante er forskellig fra organisation til organisation.
• Det mest farlige ved rammeværket er dog, at man kan anvende det mekanisk uden at opnå nogen reel ændring; f.eks. kan de forskellige lag i rammeværket hurtigt overstættes til en traditionel stage-gate baseret vandfaldsorganisation hvilket ikke er formålstjenstlig og bestemt ikke værdiskabende

Er der så noget godt i at have en drejebog og et rammeværk? Ja, helt bestemt:

• Drejebogen understreger vigtigheden i at uddanne og rekruttere dygtige medarbejdere og ledere i alle funktioner. Det er vigtigt at der er forståelse, ejerskab og motivation hos alle der er involveret i forandringen. Det gælder både medarbejderne i teamene men også ledelse, kunder og andre interessenter.
• Drejebogen viser, at der er mange artefakter, mennesker og overvejelser der skal håndteres for at opnå reel værdi af omstillingen. De skal alle have fornuftig vejledning og uddannelse så de forstår forandringen.
• Drejebogen fremhæver vigtigheden i at have forandringsagenter til at hjælpe med at forstå rammeværket og omsætte det på en måde, som skaber mere værdi en udgangspunktet. En forandring sker ikke fra den ene dag til den anden. Det har vist sig at give stor værdi at have et team af dygtige medarbejdere og ledere med ansvar for at omsætte fra tanke til handling i organisationen.
• Rammeværket navngiver roller som kan genkendes i jobopslag på tværs af virksomheder, hvilket giver medarbejderne tryghed når skal rekrutteres og uddannes. Det er en styrke, da folk således ved hvad der forventes i modsætning til selvopfundne roller som Chief Product Owner Team Lead eller lignende.
• Rammeværket kan bruges som et udgangspunkt for samarbejde mellem flere teams med et fokus på at blive bedre end før.

Summa sumarum; det er vigtigt at tage sikkerhedsbrillerne på, når man anvender et skaleringsrammeværk, da man ellers kan ende med varige mén og have en følelse af forbedring som ikke er korrekt.

Ovenstående er udtryk for mine personlige holdninger baseret på mine grundlæggende antagelser, værdier og erfaringer. Men det bliver det ikke nødvendigvis rigtigt af, og der er helt sikket flere måde at fortolke og perspektivere Luxshans liste og rammeværk. Jeg er derfor meget interesseret i at høre, hvilke refleksioner I har gjort i forhold til jeres agile rejse? Del dem gerne i kommentarfeltet, herunder, eller skriv til mig mail@agilerasmus.com. Er du interesseret i at høre mere om mit perspektiv på SAFe, Scrum eller Agile generelt, er du selvfølgelig også meget velkommen til at kontakte mig.