Stage-Gate vs. SCRUM vs. SAFe – hvilken metode passer?
- Metodevalget følger projektets natur, ikke en præference: Stage-Gate passer til fysiske produkter med dyre, svært reversible beslutninger, SCRUM til software med kort læringscyklus, SAFe til mange teams, der skal levere mod samme roadmap.
- De fleste store, teknologitunge virksomheder kører reelt en hybrid: faseporte mod ledelse og myndigheder, sprints inde i faserne.
- I regulerede brancher er dokumentationskravet ikke til forhandling – agil udvikling er tilladt, men sporbarheden skal følge med, ikke komme bagefter.
- Metoden løser ingenting i sig selv. Det afgørende er, om projektlederen kan oversætte mellem faseporte og sprints – og har den tekniske tyngde til at udfordre estimaterne.
Stage-Gate: styrken ved faseporte – og hvor den kommer til kort
Stage-Gate deler udviklingen op i faser, hvor hver fase afsluttes med en port: en formel beslutning om at fortsætte, justere eller stoppe. Styrken er kapitaldisciplin og forudsigelighed. Når et projekt indebærer værktøjsinvesteringer, komponentindkøb med lange leveringstider eller en godkendelsesproces, er det en fordel, at beslutningerne træffes eksplicit og dokumenteret frem for undervejs.
Svagheden viser sig, når forudsætningerne ændrer sig midt i en fase. Kravene er typisk låst ved portens begyndelse, og læring, der opstår undervejs, må ofte vente til næste port. I projekter med høj teknisk usikkerhed betyder det, at fejlantagelser kan nå at blive dyre, før de bliver synlige.
SCRUM: hurtig læring i software – og udfordringen ved fysiske produkter
SCRUM bygger på korte iterationer, hvor teamet leverer noget fungerende og justerer retning ud fra det. I softwareudvikling er det en stærk model, fordi omkostningen ved at ændre kurs er lav: koden kan skrives om.
I hardware er den regnestue en anden. En printplade, et støbeværktøj eller en mekanisk komponent har leveringstid og en fysisk pris ved omgørelse. Derfor fungerer ren SCRUM sjældent alene i produktudvikling, hvor mekanik, elektronik og software skal mødes mod samme deadline. Metoden kan sagtens bruges – men typisk på softwaredelen, indeni en overordnet faseplan.
En anden praktisk udfordring er styringen opad. En styregruppe, der forventer en portbeslutning med et beslutningsgrundlag, får ikke det samme ud af en sprint review. Oversættelsen mellem de to sprog er en af projektlederens vigtigste opgaver.
SAFe: når flere teams skal levere mod samme roadmap
SAFe (Scaled Agile Framework) er et forsøg på at løse skaleringsproblemet: hvad gør man, når ti teams arbejder på det samme produkt og er afhængige af hinanden? Svaret er en fælles planlægningskadence, hvor teams koordinerer afhængigheder og forpligter sig til fælles mål for en periode.
Det virker, når organisationen faktisk investerer i rammen – roller, kadence og prioriteringsmandat. Bliver SAFe derimod indført som en etikette oven på eksisterende styring, får I overhead uden gevinsten: flere møder, samme afhængighedsproblemer. Vurderingen bør derfor være nøgtern: har I nok afhængige teams til, at koordineringsgevinsten overstiger omkostningen?
Hybridmodellen: faseporte udadtil, sprints indadtil
- Faseporte bruges mod ledelse, investeringsbeslutninger og myndigheder – de fastholder kapitaldisciplin og dokumentation.
- Sprints bruges inde i faserne af de teams, hvor læringscyklussen er kort nok til det, typisk software og test.
- Porten redefineres fra “er alt færdigt?” til “har vi lært nok til at turde den næste investering?”
Metode i regulerede brancher: dokumentationen skal følge med
Sådan vælger I: fire spørgsmål
- Hvad koster det at ændre kurs? Er omkostningen lav (software), vægt iterationer. Er den høj (værktøj, komponenter, godkendelse), vægt faseporte.
- Hvor mange teams er afhængige af hinanden? Få teams: SCRUM rækker. Mange, med krydsafhængigheder: I har et skaleringsproblem, som SAFe eller en tilsvarende kadence skal løse.
- Hvem skal træffe beslutningerne – og hvor tit? Kræver jeres styringsmodel formelle beslutningsgrundlag, skal porte ind i modellen, uanset hvor agilt teamet arbejder.
- Hvad kræver compliance? Lad dokumentationskravet definere, hvad “færdig” betyder i hver iteration – ikke omvendt.
