Hvad er den skalerede agile ramme (SAFe)?

Hvorfor er SAFe^® nyttigt? 

SAFe tilbyder organisationer en rettesnor (eller køreplan), som kan hjælpe dem på deres vej mod vækst. Rammeværket introduceres på teamniveau og rækker hele vejen op til den øverste ledelse, porteføljeniveauet eller programniveauet. 

Ud over køreplanen findes der målrettet uddannelse, som organisationer kan tage. SAFe tilbyder en omfattende vidensbase for dedikerede agile roller som Scrum Master, produktejere, arkitekter og det agile team som helhed.

Er SAFe^® en metode eller et rammeværk?

Som det fremgår af selve navnet, er SAFe et meget tilpasningsdygtigt rammeværk. Da det anvendes bredt af mindst 1.000.000 praktikere og 20.000 virksomheder globalt, ville SAFe sandsynligvis ikke have så bred appel og global udbredelse, hvis det var en rigid metode.

Det er dog et meget almindeligt spørgsmål, fordi metode og rammeværk i daglig tale ofte bruges synonymt. For at understøtte mit svar på dette spørgsmål er det derfor nyttigt at have Michael Woods ord i tankerne fra hans artikel om metode kontra rammeværk:

Generelt skaber rammeværk en struktur for, hvad man skal gøre, men overlader det til den udførende at afgøre, hvordan det bedst gøres, mens en metode beskriver det hele i detaljer: hvad der skal gøres, hvornår det skal gøres, hvordan det skal gøres, og hvorfor.

Michael Wood

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

SAFe^®-principper

Da SAFe giver organisationer en måde at skalere agile arbejdsmetoder på, efterhånden som organisationerne vokser, er dets fundament forankret i agil og lean produktudvikling samt systemtænkning, så det kan give vejledning ikke kun til et agilt team, men til ‘teams af teams’.

Der er 10 lean-agile principper, som rammeværket er baseret på:

1. Anlæg et økonomisk perspektiv: Fokuserer på konceptet om at levere værdi til kunderne tidligt og ofte. Et økonomisk perspektiv fremhæver også behovet for at tage højde for alle omkostninger (risiko, produktion, drift og udvikling) samt at operere inden for de godkendte budgetmæssige rammer
2. Anvend systemtænkning: Kræver en forståelse af de systemer, som organisationen, der skaber løsningen, indgår i, samt at løsningen også er et system (projektet, produktet)
3. Antag variation; bevar mulighederne: Fokuserer på ikke at beslutte sig for ét enkelt design eller ét sæt krav tidligt i udviklingen, men i stedet have flere designs og krav og bruge faktiske data (fra eksperimenter og test) til at indsnævre mulighederne
4. Byg trinvist med hurtige, integrerede læringscyklusser: Følger konceptet om at levere arbejde i mindre (hyppigere) dele og bygge videre på det tidligere arbejde
5. Basér milepæle på objektiv evaluering eller fungerende systemer: Evaluer arbejdet under udvikling på forskellige tidspunkter gennem hele den agile udviklingslivscyklus for at vurdere, om det, der udvikles, vil skabe økonomiske fordele og være egnet til brug
6. Visualisér og begræns igangværende arbejde (WIP), reducer batchstørrelser, og administrer kølængden: Som det antydes, fokuserer dette princip på at sætte en grænse for det arbejde, som personer eller teams har fået tildelt på et givet tidspunkt (for at undgå overbelastning og sikre et ensartet flow i arbejdet og leverancerne)
7. Anvend en fast rytme; synkronisér med planlægning på tværs af domæner: Følg et mønster, hvor man afstemmer planlægningen på tværs af teams med andre
8. Frigør vidensarbejdernes indre motivation: Forstå behovet for at give teammedlemmerne autonomi, tydelige rammer og håndtering af hindringer samt at skabe en kultur præget af engagement
9. Decentralisér beslutningstagningen: For at handle hurtigt og levere hyppigere skal beslutninger decentraliseres, så de personer, der er tættest på situationen, kan træffe dem
10. Organisér efter værdi: I stedet for at organisere teams omkring specifikke funktioner (f.eks. design, test osv.) skal de organiseres omkring tværfunktionelle teams samt kunde- og forretningsværdi.

Sådan implementerer du det skalerede agile rammeværk^® 

Trin 1: Det rette tankesæt

For at begynde implementeringen af SAFe skal en organisation have et ønske om at forbedre sin forretningsagilitet og en villighed til at indføre et Lean-Agile-tankesæt.

Lean-Agile kombinerer overbevisninger, principper og handlinger fra Det Agile Manifest og Lean-tænkning. Det er en transformation fra et fastlåst tankesæt til et vækstorienteret tankesæt, hvor fagfolk er klar til at eksperimentere, lade sig inspirere af andre, udforske muligheder, lade sig udfordre og omfavne fejl.

Målet med Lean er at levere maksimal værdi til kunderne på minimal tid og samtidig levere den højest mulige kvalitet. Lean-tænkning kan defineres som:

• At specificere produktets værdi
• At definere en værdistrøm for hvert produkt
• At skabe et uafbrudt værdiflow
• At lade kunden trække værdien
• At stræbe efter perfektion

Trin 2: Definition af en værdistrøm 

En værdistrøm er en række trin (og organisatoriske komponenter), der er nødvendige for at levere værdi til en kunde – fra den indledende udløsende faktor til modtagelsen af det endelige produkt eller den endelige serviceydelse. Den er utrolig vigtig, når SAFe implementeres.

SAFe fokuserer på at optimere værdistrømmen for at levere et kontinuerligt værdiflow ved at organisere personer omkring værdistrømme, så personer og teams arbejder problemfrit sammen i stedet for at være opdelt i siloer eller segmenter.

Hvis en virksomhed eksempelvis fremstiller specialdesignede keramiske kaffekrus til salg på sin hjemmeside, kan en værdistrøm se sådan ud:

I eksemplet ovenfor er alle de processer, der er nødvendige for at levere værdi, fra det øjeblik kunden afgiver sin bestilling på kaffekruset, til kunden modtager sin forsendelse, organiseret for at sikre, at værdien flyder.

Trin 3: Opsætning af agilt udgivelsestog (ART)

Et agilt udgivelsestog (ART) er en kombination af flere agile teams. De er opbygget omkring en værdistrøm og forventes løbende at levere værdi ved at udvikle løsninger, der gavner slutbrugere og kunden.

SAFe drejer sig om koordinering af flere agile teams, og et ART omfatter alle de personer, der er nødvendige for at udvikle, teste og implementere produktet eller tjenesten. Det består typisk af 50–125 personer eller 10–12 forskellige agile teams (med en teamstørrelse på 8 til 10 personer).

Et ART er tværfunktionelt og indeholder alle de personer og organisatoriske ressourcer, der kræves for at udvikle, opbygge og levere et komplet sæt produkter eller tjenester til en kunde. Afhængigt af organisationens størrelse kan der være flere ART'er (tænk på store organisationer med mere end 500 personer).

Trin 4: Definition af forskellige roller i SAFe^®

Som i enhver organisationsstruktur er visse roller nødvendige og bør tildeles. I SAFe ligner rollerne på det enkelte agile teams niveau rollerne i et lille agilt team, men der er nogle få ekstra roller og interessenter:

• Scrum-master: faciliterer agile ceremonier og fjerner eventuelle hindringer
• Produktejer: ejer produktbackloggen og prioriterer elementerne i den
• Medlemmer af Scrum-teamet: færdiggør prioriterede backlogelementer og leverancer for at skabe værdi for kunderne
• Udgivelsestogsingeniør (RTE): I SAFe ART er dette programlederen og koordinatoren for de agile teams
• Systemarkitekter/-ingeniører: I både tekniske og ikke-tekniske organisationer hjælper systemarkitekter og ingeniører med produkt- eller softwareudvikling ved at levere et solidt arkitektonisk grundlag for løsningen

Trin 5: Forberedelse af en programbacklog til det agile udgivelsestog

Du har opsat dit ART og har nu flere agile teams. For at hjælpe med at koordinere, hvad der skal udvikles eller bygges, skal du oprette en programbacklog.

En programbacklog vil indeholde funktioner, epics, brugerhistorier, funktionalitet og arkitekturarbejde (systemer), der er nødvendigt for at understøtte værdistrømmen og skabe værdi for kunderne. 

En fælles backlog kræver input fra mange ART-roller såsom udgivelsestogsingeniøren, produktejere og andre som produktledelsen og organisationens ledere. En produktbacklog vil også hjælpe i det næste implementeringstrin med at definere, hvem der arbejder på hvad og hvornår.

Trin 6: Planlægning af programinkrement (PI) og ART-synkroniseringer

I det sidste trin skal du planlægge, hvem der udfører arbejdet, og hvornår det sker. I SAFe kaldes denne begivenhed planlægning af programinkrement (PI). Den er central i SAFe, gennemføres regelmæssigt og er en mulighed for at skabe fælles retning med hele ART'et.

Et PI kan have den længde, organisationen ønsker, men det varer typisk 3 måneder (12 uger). Det giver mulighed for 6 sprints á 2 uger, som teamsene skal planlægge. Dette foregår typisk med hele ART'et til stede (ja, alle agile teams).

På grund af omfanget er PI-planlægning normalt en todagesbegivenhed, der omfatter:

• En præsentation af forretningskonteksten, de strategiske mål og missionen
• Planlægningssessioner i mindre grupper for de agile teams, hvor de udarbejder deres plan med elementer fra deres teambacklog fra den fælles programbacklog
• Præsentation af udkast til planer fra alle agile teams
• Ledelsesgennemgang og diskussioner om problemløsning
• Teamarbejde i mindre grupper for at justere og færdiggøre deres plan
• Præsentation af de endelige planer og tillidsafstemning
• Gennemgang af programrisici og omarbejdning af planen (hvis nødvendigt)

Efter PI-planlægningen er afsluttet, fortsætter koordineringen og samarbejdet. Hyppigt i løbet af PI'et mødes repræsentanter for de agile teams (PO'en og Scrum-masteren) sammen med RTE'en til en ART-synkronisering for at gennemgå de agile teams' fremskridt og identificere eventuelle afhængigheder, problemer eller blokeringer, der kræver koordinering. Dette kan ske med ethvert interval under et PI, men hver anden uge (eller ved afslutningen af hvert sprint eller hver iteration) er en god kadence.

Hvilke værktøjer bruges i SAFe^®?

Da SAFe benytter andre agile metoder såsom Scrum og Kanban, findes der en række værktøjer, som kan bruges til at hjælpe agile teams, der arbejder med SAFe.

Hvis du vil have anbefalinger til værktøjer, der kan bruges til SAFe, kan du begynde med vores lister over agile værktøjer og agile projektstyringssoftware.

Da PI-planlægning anbefales som en aktivitet på stedet (ansigt til ansigt), anbefales følgende værktøjer også:

• Et stort eventområde, hvor hele ART kan samles og arbejde i teams
• Whiteboards eller store flipoverark
• Whiteboardtuscher
• Post-It-sedler eller selvklæbende sedler (bruges til at repræsentere elementer fra teamets backlog)
• Snacks og forfriskninger (for hvem elsker ikke snacks 😊)

SAFe^® & andre agile metoder

Jeg håber, du nød den agile fest og mødet med vores nye festgæst, SAFe. Som du måske har bemærket, har SAFe faktisk meget til fælles med nogle af de andre gæster, såsom Scrum og Lean. Det er begyndelsen på et godt forhold!

Hvis din organisation vokser, og det bliver mere kompliceret at lede flere agile teams, kan du på samme måde overveje at invitere SAFe med til din fest. Hvis du har spørgsmål, er du velkommen til at kontakte mig via LinkedIn eller Twitter.

Hvis du vil vide mere om andre hybride projektstyringsmetoder og værktøjer, kan du tilmelde dig The Digital Project Manager-nyhedsbrevet. Vil du have mere? Se vores medlemskab!

^®SAFe og Scaled Agile Framework er registrerede varemærker tilhørende Scaled Agile, Inc.