Mange teams støder på det samme spørgsmål, når Scrum begynder at virke: Skal vi bare lave flere Scrum-teams, eller er tiden kommet til SAFe?
Det korte svar er, at de to rammeværker ikke løser præcis det samme problem. Scrum hjælper et lille, tværfunktionelt team med at levere hurtigt og lære løbende. SAFe hjælper en større organisation med at få mange teams til at arbejde i samme retning, med fælles planlægning, tydeligere styring og bedre håndtering af afhængigheder.
Det gør valget vigtigt. Skalerer man for tidligt, kan man ende med unødigt mange roller, møder og processer. Venter man for længe, kan teams begynde at blokere hinanden, prioriteter bliver uklare, og levering bliver ustabil. Derfor bør spørgsmålet ikke være, hvilket framework der “er bedst”, men hvilket niveau af struktur der faktisk er nødvendigt.
— Du kan få dem tilsendt herunder! —
Scrum og SAFe er bygget til forskellig kompleksitet
Scrum er bevidst enkelt. Et Scrum-team arbejder med én backlog, korte sprints og et klart mål for hver iteration. Kernen er transparens, inspektion og tilpasning. Det gør Scrum stærkt, når et team eller få teams kan træffe beslutninger tæt på produktet.
SAFe, som står for Scaled Agile Framework, går et skridt videre. Her handler det ikke kun om teamets rytme, men også om koordinering mellem mange teams, fælles planlægningshorisont, programniveau og kobling til strategi og portefølje. Det er især relevant, når løsningen er stor, teknisk sammenhængende og afhængig af leverancer fra mange hold på samme tid.
Her er forskellen i kondenseret form:
| Aspekt | Scrum | SAFe |
|---|---|---|
| Primært fokus | Et enkelt team eller få teams | Mange teams og større organisationer |
| Typisk planlægningsrytme | Sprints på 1 til 4 uger | Sprints inden for Program Increments på typisk 8 til 12 uger |
| Roller | Product Owner, Scrum Master, udviklere | Teamroller plus bl.a. Release Train Engineer, Product Management og arkitekturroller |
| Styring | Teamnær, let og fleksibel | Mere struktureret, med kobling til program og portefølje |
| Koordinering | Direkte dialog, Scrum of Scrums, let skaleringsmodel | Fælles PI Planning, programboard og faste tværgående fora |
| Passer bedst til | Få afhængigheder og høj autonomi | Mange afhængigheder, fælles retning og styringsbehov |
Tabellen viser den vigtigste pointe: Scrum og SAFe er ikke konkurrenter i klassisk forstand. De passer til forskellige grader af organisatorisk og teknisk kompleksitet.
Når Scrum stadig er nok
Mange organisationer går i gang med at skalere, så snart de får to eller tre teams. Det er sjældent nødvendigt. Hvis teams kan samarbejde direkte, dele viden hurtigt og integrere løbende uden større friktion, kan Scrum stadig være et rigtig godt valg.
Det gælder især, når der er én tydelig produktretning, en overskuelig arkitektur og en Product Owner, der reelt kan prioritere. I den situation er den lette struktur en fordel. Beslutninger tages hurtigere, feedback kommer tættere på arbejdet, og teamene oplever ofte mere ejerskab.
Hent vores bøger og skabeloner herunder
Hvis der opstår behov for lidt mere koordinering, findes der skaleringsmodeller, som bygger videre på Scrum i stedet for at erstatte det. Nexus, LeSS og Scrum@Scale er typiske eksempler. Fælles for dem er, at de forsøger at bevare Scrums enkelhed og kun lægge det ovenpå, som er nødvendigt for at håndtere integration og samarbejde på tværs.
Der er flere tegn på, at I endnu ikke behøver SAFe:
- Ét produkt og én tydelig backlog
- Få tværgående afhængigheder
- Løbende integration uden store flaskehalse
- Direkte koordinering mellem teams
- Hurtige beslutninger tæt på produktet
Scrum er altså ikke “for småt” bare fordi organisationen vokser lidt. Det bliver først for lille, når kompleksiteten vokser hurtigere end teamenes evne til selv at koordinere.
Når SAFe begynder at give mening
SAFe bliver interessant, når koordinering ikke længere kan klares med god vilje, tavlemøder og ekstra snakke mellem Scrum Masters. Det sker ofte, når mange teams arbejder på samme løsning, når afhængighederne er tunge, og når prioriteringer skal hænge sammen på tværs af produkter, platforme eller forretningsområder.
Et centralt element i SAFe er Agile Release Train, ofte forkortet ART. Her samles typisk 5 til 12 teams i en fælles leveranceenhed med fælles rytme, fælles mål og en fælles planlægningsbegivenhed kaldet PI Planning. Det giver overblik over afhængigheder, kapacitet og leverancemål i en længere horisont end et enkelt sprint.
Det er ikke gratis.
SAFe kræver flere roller, mere træning og mere disciplin i planlægning og prioritering. Hvis organisationen ikke er klar til det, kan rammeværket hurtigt opleves som tungt. Men i store og sammensatte setup kan den ekstra struktur være netop det, der gør levering mulig og mere stabil.
Typiske situationer, hvor SAFe ofte giver mening, ser sådan ud:
- Mange teams: I har flere teams, som leverer til samme løsning og påvirker hinandens arbejde løbende
- Afhængigheder: Kritiske leverancer bliver forsinket, fordi teams venter på hinanden
- Styringsbehov: Der er behov for fælles prioritering mellem ledelse, produkt og udvikling
- Compliance: Dokumentation, risikostyring eller regulatoriske krav kræver mere synlig struktur
Det er værd at holde fast i, at SAFe ikke bør vælges for at “virke mere professionelt”. Det bør vælges, når koordinering og retning faktisk er blevet en begrænsning for flow og levering.
Du skal ikke skalere efter teamantal alene
Et af de mest udbredte fejltrin er at koble valget direkte til antal medarbejdere. “Vi er nu 40 personer, så nu skal vi have SAFe.” Den logik er for grov.
Nogle organisationer kan arbejde fint med Scrum-baseret skalering med 30 eller 50 mennesker, hvis produktet er afgrænset, arkitekturen er enkel, og teams kan levere selvstændigt. Andre får store problemer allerede ved 15 til 20 personer, hvis de arbejder på et tæt integreret system med mange fælles komponenter og høje kvalitetskrav.
Det afgørende spørgsmål er derfor ikke kun størrelse, men hvor afhængige teams er af hinanden. Jo flere afhængigheder, desto større behov for fælles rytme, fælles mål og tydelig prioritering. Her kan SAFe være en hjælp. Hvis afhængighederne er få, vil en lettere model ofte være både hurtigere og sundere.
En praktisk vurdering kan tage udgangspunkt i fire trin:
- Kortlæg, hvor ofte teams blokerer hinanden
- Se på, hvor mange leverancer der kræver fælles integration
- Vurder, om prioritering foregår ét sted eller mange steder samtidig
- Test en lettere skaleringsmodel, før I indfører en tungere
Det sidste punkt er vigtigt. Mange kan nøjes med at styrke backlogstyring, arkitekturarbejde og tværgående planlægning, før det giver mening at skifte til et fuldt skaleret framework.
De vigtigste valgkriterier
Der er især fire forhold, som bør veje tungt i valget mellem Scrum-skalering og SAFe.
Det første er kompleksitet. Ikke bare produktets størrelse, men også antallet af koblinger mellem teams, systemer og interessenter. Hvis leverancer sjældent kan færdiggøres uden bidrag fra flere teams, stiger behovet for en fælles model markant.
Det andet er styring. Nogle organisationer har behov for tæt kobling mellem strategi, budget, roadmap og udviklingsarbejde. Her passer SAFe ofte bedre, fordi rammeværket har mekanismer til planlægning og prioritering på flere niveauer. Hvis målet derimod er maksimal teamautonomi og hurtige lokale beslutninger, er Scrum et bedre udgangspunkt.
Det tredje er kultur og modenhed. Scrum kræver, at teams kan tage ansvar, prioritere godt og håndtere usikkerhed uden at få svar på alt ovenfra. SAFe kræver noget andet: ledelsesopbakning, træning, tydelige roller og villighed til at arbejde i en mere fælles rytme. Ingen af delene er lette, men de stiller forskellige krav.
Det fjerde er tempoet i forandringen. Hvis organisationen ønsker hurtige forbedringer uden et stort transformationsprogram, er det som regel klogt at starte med den letteste mulige model. Hvis situationen allerede er præget af fragmenteret planlægning, parallelle prioriteringer og manglende sammenhæng mellem forretning og udvikling, kan en mere tydelig ramme være nødvendig.
Hvad der ofte går galt
Mange problemer skyldes ikke rammeværket i sig selv, men måden det indføres på. Nogle holder fast i Scrum, selv om teams reelt ikke længere kan levere uden tung tværgående koordinering. Så ender man med uformelle møder, skjulte afhængigheder og en voksende følelse af kaos.
Andre gør det modsatte og indfører SAFe som et stort organisatorisk projekt, før de basale agile vaner sidder fast. Hvis backloggen er uklar, hvis teamene ikke arbejder tværfunktionelt, eller hvis ledelsen stadig skifter prioriteringer fra uge til uge, hjælper ekstra lag af planlægning sjældent nok.
Et sundt valg kræver derfor ærlig diagnose frem for ønsketænkning.
En nøgtern måde at tage beslutningen på
Start med produktet, ikke med frameworket. Hvad er det, I prøver at levere? Hvor mange teams er reelt nødvendige? Hvilke afhængigheder skaber forsinkelser? Hvor mister I fart i dag?
Når billedet er klart, kan I lave en enkel beslutningsramme:
- Bevar Scrum: Når få teams kan levere med høj autonomi og lav koordinationsomkostning
- Udvid Scrum let: Når I har behov for fælles planlægning, integration og bedre synlighed, men stadig vil holde strukturen enkel
- Gå mod SAFe: Når mange teams skal styres mod fælles mål, og afhængigheder, governance eller compliance fylder markant
Det er også en god idé at køre en pilot. Lad et afgrænset område afprøve en fælles PI-lignende planlægning, eller test en Nexus-lignende koordinering mellem nogle få teams. Mål på konkrete forhold: leveringsevne, kvalitet, lead time, stabilitet og oplevet klarhed i prioriteringen.
Hvis du står med tre til seks teams, er det ofte for tidligt at hoppe direkte til en stor model. Hvis du står med ti teams, fælles arkitektur, lange integrationsforløb og uklare prioriteringer, er det ofte for sent at nøjes med håbet om, at lidt mere dialog løser det.
Det vigtigste er at vælge den mindst tunge struktur, der giver jer bedre flow. Det er sjældent et mål i sig selv at “gå SAFe”. Målet er at få arbejdet sikkert, tydeligt og hurtigere i mål.
— Du kan få dem tilsendt herunder! —
