Når et agilt setup vokser fra 1-2 teams til 8, 15 eller 40 teams, ændrer problemerne sig. Det handler mindre om at “gøre Scrum rigtigt” i ét team og mere om, hvordan man skaber fælles retning, reducerer afhængigheder og stadig leverer stabilt til kunderne.
To af de mest kendte skaleringsrammeværk er SAFe og LeSS. De kan begge bringe orden i kaos, men de gør det med vidt forskellige greb, og valget får store konsekvenser for roller, planlægning, ledelse og hvor meget frihed teams reelt får.
Hvad betyder “skalering” i praksis?
Skalering er ikke kun “flere teams”. Det er flere interessenter, flere systemer, flere afhængigheder og ofte flere krav til risikostyring og dokumentation. Samtidig stiger prisen på misforståelser: Et enkelt uklart roadmap kan sende fem teams i hver sin retning.
— Du kan få dem tilsendt herunder! —
Skalering bliver også hurtigt et organisationsdesign-problem. Hvis arkitektur, test, drift, compliance og produktbeslutninger ligger i siloer, så vil et skaleringsrammeværk enten forsøge at koordinere siloerne eller nedbryde dem.
Nogle organisationer har mest brug for faste kadencer og tydelige ansvarspunkter. Andre har mest brug for at gøre produktet mere “ét”, så teams kan arbejde mere selvstændigt.
SAFe kort fortalt: når koordination og governance fylder
SAFe (Scaled Agile Framework) tilbyder en relativt detaljeret model for, hvordan mange teams kan arbejde i takt. En central idé er Agile Release Train (ART): en stabil gruppe af typisk 5-15 teams, som leverer sammen mod fælles mål.
Planlægning samles i Program Increment (PI), ofte hver 8-12 uge, hvor alle relevante deltagere mødes og skaber en fælles plan for den kommende periode. Det giver synlighed, fælles afhængighedsstyring og ofte en oplevelse af “nu ved vi, hvad der sker”.
SAFe introducerer også flere tværgående roller (fx Release Train Engineer og Product Management på programniveau) og artefakter, der passer godt til organisationer med mange eksterne krav til rapportering, sporbarhed og risikostyring.
Til gengæld kommer det med en pris: mere struktur, flere ceremonier og større behov for træning. Det kan fungere rigtig godt, når det bliver brugt bevidst, men kan også ende som proces-overhead, hvis man implementerer “alt på plakaten” uden at skære til.
Hent vores bøger og skabeloner herunder
LeSS kort fortalt: Scrum i stor skala med “barely sufficient” struktur
LeSS (Large-Scale Scrum) er, i sin kerne, Scrum udvidet til flere teams, der arbejder på ét produkt. Den vigtigste forskel er ofte denne: LeSS insisterer på én fælles Product Backlog og én Product Owner for hele produktet (i LeSS Huge kan der være Area Product Owners, men stadig med én samlet retning).
LeSS forsøger at holde antallet af ekstra roller og processer lavt. Koordination sker primært gennem fælles Scrum-events på tværs af teams: fælles planlægning, fælles review og fælles retrospektiv, så hele “produktgruppen” lærer sammen.
Det gør LeSS attraktivt for organisationer, der vil styrke selvstyrende feature-teams og reducere mellemled, håndoffs og lokal optimering. Til gengæld kræver det modne teams, stærk teknisk kvalitet (CI/CD og testautomatisering er næsten ikke til at komme udenom) og ledelse, der reelt vil flytte beslutninger tættere på dem, der bygger produktet.
De vigtigste forskelle i hverdagen
Forskellene bliver tydelige, når du kigger på, hvor beslutninger tages, hvordan planlægning samles, og hvor meget “systemet” hjælper dig med koordinering.
| Dimension | SAFe | LeSS |
|---|---|---|
| Grundmodel | Flere niveauer (team, program, portfolio) | Fladere: flere teams om ét produkt |
| Planlægningsrytme | PI-planlægning i større blokke + iterationer | Sprint-baseret planlægning med fælles events |
| Roller | Flere specialiserede roller på tværs | Få roller, tæt på Scrum |
| Afhængigheder | Synliggøres ofte via programboards og planlægning | Adresseres løbende, og teams presses mod at fjerne dem |
| Ledelsestilgang | Kan passe godt til governance og rapporteringsbehov | Kræver typisk mere decentral beslutningskraft |
| Risiko ved dårlig implementering | “Agil” projektstyring med meget bureaukrati | Understøttelse mangler, hvis teams og ledelse ikke er klar |
Tabellen kan bruges som en hurtig sanity check, men den siger ikke alt. Det afgørende er, hvad du faktisk forsøger at løse.
Hvad passer bedst til din organisation?
Det hjælper at tænke i problemtyper frem for framework-navne. Skal I først og fremmest have fælles retning og forudsigelig levering på tværs af mange enheder? Eller skal I først og fremmest reducere siloer og gøre teams i stand til at levere end-to-end uden mellemled?
Efter at have talt med mange projektledere og teams ser man ofte de samme signaler gå igen. Her er et praktisk pejlemærke, du kan bruge i en workshop med ledelse og nøglepersoner:
- Stærke compliance-krav: I har brug for tydelige beslutningsfora, sporbarhed og faste planlægningspunkter
- Mange afhængigheder på tværs: I kan ikke levere uden koordination på tværs af teams og systemer
- Modne feature-teams: Teams kan selv designe, bygge, teste og få i drift uden tunge overleveringer
- Én produktretning: Det er realistisk med én fælles prioritering, én backlog og én samlet produktforståelse
- Ledelsesstil: SAFe passer ofte, når der er behov for tydelige roller og kadence; LeSS passer ofte, når ledelse vil flytte beslutninger tættere på teams
Hvis din organisation er midt imellem, er det normalt. Mange ender med at starte mere struktureret og gradvist forenkle, eller starte enkelt og senere tilføje udvalgte koordineringsmekanismer.
En hurtig tommelfingerregel kan også være team-antal: LeSS Basic er typisk 2-8 teams om ét produkt, mens SAFe ofte giver mest mening, når du har et helt “tog” med mange teams, eller når portfolio-styring fylder meget.
Indføring i virkeligheden: faldgruber du kan planlægge dig ud af
En skaleringsmodel redder ikke en organisation, der stadig er styret som klassiske projekter med mange overleveringer. Den kan tværtimod gøre problemerne mere stabile og sværere at få øje på.
I SAFe ser man tit, at PI-planlægning bliver til en stor forhandling om kapacitet, hvor teams lover for meget, og hvor afhængigheder bare flyttes rundt på et board. Hvis I vælger SAFe, bør I være ret kompromisløse omkring: færre, tydeligere mål pr. PI, aktiv reduktion af work in progress og skarp prioritering, når alt ikke kan være vigtigt.
I LeSS ser man tit, at organisationen beholder siloer (analyse, test, drift, arkitektur) og håber, at fælles events løser det. Det gør de sjældent. LeSS fungerer bedst, når man faktisk omdesigner teams, så de kan levere et færdigt produktinkrement hver sprint, og når teknisk kvalitet bliver en ledelsesprioritet, ikke kun en team-ambition.
Her er nogle konkrete modtræk, der ofte hjælper uanset valg:
- Skær ceremonier til, før I skalerer dem
- Gør afhængigheder synlige hver uge, ikke kun ved store planlægningsdage
- Byg kvalitet ind via automatiserede tests og hyppig integration
- Sæt en grænse for, hvor meget arbejde der må være i gang samtidig
- Lav én tydelig prioritering, som teams kan stole på
Det lyder banalt, men det er ofte her, skala knækker.
En enkel beslutningsproces, du kan køre på 2 uger
Valget bliver bedst, når det kobles til jeres konkrete leverancekæde og jeres største friktioner. Brug en kort, tidsbokset proces, hvor I prioriterer læring frem for perfekte slides.
Start med at samle et lille tværgående hold: repræsentanter fra udvikling, produkt, drift og en leder med mandat til at ændre rammer. Aftal på forhånd, hvad “bedre” betyder for jer: hurtigere time-to-market, færre fejl i drift, mere stabil planopfyldelse, eller mindre spild i koordinering.
Herefter kan I køre denne 5-trins proces:
- Kortlæg jeres flow fra idé til drift, inkl. ventetider og godkendelser
- Tæl reelle afhængigheder mellem teams i den sidste måned og hvor de opstod
- Vælg 2-3 designprincipper, I vil styre efter (fx fælles prioritering, stabil kadence, færre håndoffs)
- Kør et pilot-setup i 8-12 uger med tydelige målepunkter
- Beslut: skaler op, justér, eller stop og ændr organisationsdesign først
Det vigtigste er, at rammeværket ikke bliver målet. Leverancen og læringen er målet.
Hvad du kan måle de første 3 måneder uden at drukne i metrikker
Hvis I ikke måler noget, ender diskussionen ofte i mavefornemmelser og politiske kampe. Hvis I måler for meget, begynder teams at optimere tal i stedet for kundeværdi.
Vælg få, robuste signaler der passer til både SAFe og LeSS: lead time på de vigtigste typer arbejde, stabilitet i drift (fejl og rollback), samt hvor ofte I faktisk kan sætte noget i produktion. Kombinér det med et simpelt spørgsmål til teams og interessenter: “Fik vi lettere ved at levere, eller byggede vi mere koordinering?”
En enkelt sætning kan være en god start: Mål tiden fra prioriteret backlog-item til drift, og følg udviklingen uge for uge.
Hvis du vil gøre det ekstra anvendeligt som projektleder, så aftal også ét “adfærds-mål”, der skal kunne ses: færre eskalationer om afhængigheder, færre parallelle initiativer, eller mere tid til fælles produktlæring i reviews. Det er ofte dér, du kan se, om SAFe eller LeSS faktisk ændrer måden, I arbejder på, og ikke kun kalenderen.
— Du kan få dem tilsendt herunder! —
