Valget mellem Agile og Waterfall definerer et softwareprojekts omkostningsmodel, risikoprofil og rapporteringsrytme, længe før den første linje kode skrives. Alle har en holdning til det. Og oftest betyder en præference for den ene metode, at man helt afskriver den anden.
Tænk på det som en kanal over for en flod. En kanal bliver opmålt, prissat og gravet én gang, og den fører vandet præcis derhen, hvor du har besluttet, det skal løbe. En flod finder sit eget leje og når frem alligevel, bare ikke ad den rute, du havde tegnet. Ingen af delene er en bedre måde at flytte vand på. Det afhænger af terrænet.
Det korte svar: Brug waterfall-modellen når kravene er faste, det eksterne miljø sandsynligvis ikke ændrer sig, og et fastlagt scope og budget betyder mere end tilpasningsdygtighed. Brug den agile tilgang når produktvisionen kan ændre sig, når du har brug for fungerende software tidligt, eller når omkostningerne ved at bygge det forkerte i seks måneder er højere end omkostningerne ved at genplanlægge hver anden uge.
Er Waterfall død? Har Agile taget over? Er den ene bedre end den anden? Denne artikel gør status over begge metoder, besvarer de spørgsmål, der rent faktisk dukker op i opstartsmøder, og forklarer, hvorfor vi hos Imaginary Cloud valgte Agile frem for Waterfall, og hvornår vi stadig ikke ville gøre det.
Waterfall-metoden har fået sit navn fra sine sekventielle faser, der er arrangeret nedadgående ligesom rigtige vandfald, hvor hver fase er et skridt mellem den første og den sidste. Winston Walker Royce beskrev den i 1970 i sit papir Managing the Development of Large Software Systems til IEEE WESCON-konferencen. Den omfattede oprindeligt fem distinkte faser: krav, design, implementering, verificering og vedligeholdelse.
Her er den del, som sammenligningsartikler ofte udelader. Royce præsenterede den rene sekventielle model som den version, der "er risikabel og lægger op til fiasko", hvorefter han brugte resten af papiret på at argumentere for iteration mellem faserne. Det, de fleste kalder Waterfall, er diagrammet. Ikke argumentet bag det.
Variationer opstod gennem de efterfølgende årtier, men logikken bestod. Gør en fase færdig, og dens output bliver input til den næste, som starter umiddelbart efter. Dens enkelhed gjorde den let at forstå og let at tage i brug. Waterfall sikrer, at hver fase er afsluttet, før den næste begynder – for at forhindre, at udviklingen starter, før designarbejdet er udført, hvilket er måden, hvorpå uoverensstemmelser sniger sig ind i begge ender. Modellen hviler også på præmissen om, at man kan estimere hele projektets omkostninger og indsats i kravfasen. Det holder præcis så længe, som kravene gør.
Waterfall-modellen var aldrig den eneste mulige tilgang. Men det tog indtil 2001, før den stod over for et fundamentalt paradigmeskift. Hvad forårsagede det? Agile.
Principperne for inkrementel udvikling var allerede i brug, spredt ud over forskellige processer. Det var først i 2001, med Manifesto for Agile Software Development, at Agile, som vi kender det, blev introduceret og gjort populært. Et meget ligefremt dokument, sammensat af en gruppe udviklere i Snowbird, Utah, som brød med konventionerne for softwareudvikling på én gang. Pludselig var der et reelt alternativ til vandfaldsmodellen.
Agiles cyklusser, som konventionelt kaldes sprints, leverer værdi kumulativt, hvor hver del er en brik i et større puslespil, der fører til færdiggørelse. Det er her, metoden adskiller sig mest fra vandfaldsmodellen. Tilgangen søger fleksibilitet. Den muliggør regelmæssige inkrementer og reducerer tiden brugt på planlægning ved at arbejde i kortere tidsbokse: faste perioder på en uge eller to, som arbejdet tilpasses, frem for omvendt. Hver iteration afleverer fungerende software ved afslutningen, og planlægningen af det nærmeste skridt sker mere detaljeret end for de efterfølgende skridt.
Mekanismen, der får dette til at fungere, er backloggen: den prioriterede liste over alt, hvad produktet måtte have brug for, hvorfra hvert sprint henter de næstmest værdifulde elementer. Ændringer håndteres ved at omprioritere listen. Ikke ved at genåbne en plan.
Mange undergrupper adopterer Agile som filosofi, ligesom der opstod variationer omkring vandfaldsmodellen. DSDM, Feature-Driven Development, Extreme Programming og, sandsynligvis den mest populære, Scrum trækker alle på Agile i softwareudvikling. Sandheden er, at navnet betyder langt mindre end, om backloggen rent faktisk bliver genprioriteret, hvilket er den del, de fleste brugere i stilhed springer over.
Næsten lige så mange mener, at Waterfall er dødt, som mener, at Agile er en ubetydelig trend. Der er intet galt i at have forskellige holdninger. Lad os se på beviserne, og de har ændret sig siden de undersøgelser, som de fleste artikler stadig citerer.
I årevis var det foretrukne tal Stack Overflow Developer Survey fra 2018, som placerede Agile på omkring 85 % og Waterfall nede omkring 15 %. Det tal er blevet forældet, og ikke fordi Waterfall kollapsede. Det blev forældet, fordi spørgsmålet ændrede sig. Senere undersøgelser stoppede helt med at rapportere en klar opdeling af rammeværk: Stack Overflows nyere udviklerundersøgelser flyttede fokus til værktøjer og AI-adoption, og Digital.ai's State of Agile rapport (det mest citerede barometer på området) fjernede spørgsmålet "hvilket rammeværk bruger du" helt i sin 2025-udgave efter at have stillet det i sytten år.
Det, der erstattede kapløbet mellem de to, er et klart tredje svar: hybrid. Ifølge 18th State of Agile Report (Digital.ai, 2025), bruger omkring 74 % af organisationerne nu hybride eller hjemmebyggede tilgange frem for et enkelt rent rammeværk, hvilket er en stigning fra omkring 10 % for et årti siden. Den samme rapport viste, at kun omkring 13 % siger, at Agile er dybt forankret i hele virksomheden; de fleste beskriver det som tilstedeværende, men ikke fuldt fungerende. I mellemtiden har Project Management Institutes Pulse of the Profession i årevis rapporteret, at mere end halvdelen af organisationerne stadig bruger traditionelle, strukturerede metoder et eller andet sted i deres portefølje.
Hvis man læser grundigt efter, er historien ikke, at Waterfall døde, og Agile vandt. Historien er, at rene metoder tabte, og at middelvejen tog over. To ting følger af det:
Agile afslørede ganske rigtigt svagheder ved vandfaldsmodellen, og det er der ingen tvivl om: hvor svært det er at rette fejl fundet i tidligere faser, og hvordan hele processen skal gennemføres, før man står med fungerende software, med stor usikkerhed undervejs. Men at vælge den ene frem for den anden blot for at være bedre er en illusion. Det dækker som regel over, at der slet ikke er nogen ordentlig proces.
| Dimension | Vandfaldsmodel | Agil tilgang |
|---|---|---|
| Krav | Låst og godkendt, før designfasen begynder | Forventes at udvikle sig; forfines i hver iteration |
| Omkostningsmodel | Estimat for hele projektet udarbejdes på forhånd | Estimeres pr. iteration i forhold til et løbende budget |
| Risikoprofil | Koncentreret til sidst, ved integration og test | Fordelt over sprints og afdækket tidligt |
| Dokumentation | Omfattende, udarbejdes fase for fase | Mindre omfattende, udarbejdes hvor det har sin berettigelse |
| Involvering af interessenter | Koncentreret omkring kravspecifikation og godkendelse | Løbende, med et review i hvert sprint |
| Leveringskadence | Én udgivelse til sidst | Fungerende software ved slutningen af hvert sprint |
| Håndtering af ændringer | Formel ændringsanmodning, som regel genforhandlet | Omprioriteres i backloggen ved næste planlægningsmøde |
| Bedst egnede projekter | Stabilt omfang og miljø, arbejde med mange compliance-krav | Usikkert omfang, skiftende markeder, nye produkter |
Waterfall-metoden er det stærkeste valg til stabile projekter. Den omfattende planlægning foregår først, hvor man tager højde for alle aspekter (interne såvel som eksterne), der kan påvirke udførelsen. Uanset projektets størrelse passer Waterfall til et miljø, der sandsynligvis ikke ændrer sig, mens du bygger. Til den type arbejde var Waterfall den bedste metode, før Agile kom til, og det er det stadig. Hvis du kan planlægge det hele på forhånd i et miljø med lav risiko, vinder du intet ved at opdele det i sprints. Fokusér i stedet på slutresultatet.
Agile er vejen frem for projekter med en mere fleksibel og uforudsigelig natur. Hvis produktvisionen kan ændre sig på grund af markedsdynamikker, bør du bygge og tilpasse dig med Agile. Det er også den bedste metode til at sikre, at et projekt ikke forsvinder ind i udviklingsfasen i månedsvis uden at vise noget. Hvert sprint afsluttes med et kontrolpunkt, hvor produktejeren kan teste og godkende det udførte arbejde. Og et MVP passer naturligt ind i den rytme.
I projekter under forandring, der kører med Waterfall, skaber de manglende kontrolpunkter en risiko, fordi problemer, der opdages til sidst, er sværere at løse. Den ekstra tid, der bruges på at planlægge hele projektet, er ingen garanti for, at design og udvikling forløber gnidningsfrit til målstregen. De fleste problemer er lige så uønskede, som de er uforudsigelige.
Før man overhovedet nævner en metode, er der fire ting, der afgør valget. Placér dit projekt på hver række herunder: Jo længere mod venstre det lander, desto mere oplagt er Waterfall; jo længere mod højre, desto mere oplagt er Agile. En reel opdeling er ikke et tegn på manglende beslutningsevne, men derimod et argument for en bevidst hybridløsning.
Valget mellem Agile og Waterfall er mere end blot et marketingtiltag. Vælger du det forkerte værktøj til opgaven, betaler du prisen i tid og kræfter. For den, der godkender budgettet, er der fire konsekvenser, der betyder noget.
Budgetforudsigelighed. Waterfall giver dig et fast tal tidligt i forløbet, hvilket er præcis, hvad en bestyrelse ønsker at se. Tallet er dog kun så pålideligt som de krav, der ligger til grund for det; forudsigeligheden er reel, når omfanget er fastlåst, men illusorisk, når det ikke er. Agile giver dig i stedet et kontrolleret forbrug: mindre vished om det samlede beløb, men større vished om, hvad hver måned har bidraget med.
Eksponering for ændringer. I Waterfall-modellen er en ændring efter godkendelse en ændringsanmodning, der skal genforhandles i forhold til pris og deadline. I de fastprisprojekter, vi har kørt og overtaget, er det typisk her, at marginen og tidsplanen skrider. I Agile absorberes ændringer ved at omprioritere backloggen, så prisen er lig med det, der bliver skubbet ud af planen.
Tid til første værdi. Waterfall leverer værdi én gang, til allersidst. Agile leverer noget brugbart efter hvert sprint, hvilket er afgørende, når dit produkt skal præsenteres for brugere, myndigheder eller investorer, før det fulde omfang er færdigudviklet. Det er også grunden til, at et MVP passer naturligt ind i en agil proces, men virker malplaceret i en Waterfall-model.
Governance og rapportering. Waterfall rapporterer fremskridt i forhold til en plan, hvilket ser godt ud for en styregruppe, men kan skjule integrationsrisici indtil sent i forløbet. Agile rapporterer om fungerende software, hvilket er sværere at pynte på, og kræver interessenter, der kan engagere sig hver anden uge frem for hvert kvartal.
De færreste af de organisationer, vi arbejder med, benytter en af modellerne i sin rene form, hvilket – som tallene ovenfor viser – nu gør dem til flertallet frem for undtagelsen. Det mønster, vi oftest ser, er en faseopdelt struktur på programniveau med faste milepæle, budgetter og compliance-gates, kombineret med agil leverance i hver fase. Discovery og arkitektur planlægges på forhånd, hvorefter selve udviklingen kører i sprints inden for disse rammer.
Det fungerer, når grænsen er bevidst. Det fejler, når den er tilfældig: et fast scope, en fast dato og et fast budget, hvor sprints er klistret på uden mulighed for at prioritere mellem opgaverne. Sprints skaber ikke fleksibilitet i sig selv. Det gør evnen til at ændre prioriteter.
Et konkret eksempel gør afvejningerne mindre abstrakte. FlippedNormals, en markedsplads for digital kunst og 3D-aktiver, kom til os med en platform, der var vokset fra sit fundament: Den kørte på WordPress, og selve teknologien var blevet en bremse for væksten. Opgaven var at migrere markedspladsen væk fra WordPress til en specialbygget platform og flytte den til AWS for at få en mere skalerbar infrastruktur – og tid var ikke en luksus, da den eksisterende stack aktivt begrænsede forretningen.
Det er præcis den type projekt, hvor valget af metode for alvor viser sit værd. En genopbygning og migrering af en kørende markedsplads er ikke en fast, forudsigelig specifikation, man kan prissætte én gang og derefter lægge fra sig; det er et bevægeligt mål, hvor omkostningerne ved at gætte forkert akkumuleres for hver uge, den gamle platform forbliver oppe. Derfor kørte vi projektet i etaper, hvor vi byggede den nye platform op i bidder og holdt forretningen orienteret ved hvert kontrolpunkt i stedet for at forsvinde i et kvartal og håbe på det bedste.
Den generelle pointe gælder uanset det præcise tal: Når teknologien er begrænsningen, og tiden er knap, gør trinvis levering det muligt at eliminere risikoen i små bidder i stedet for at satse hele resultatet på én stor lancering.
Så hvorfor foretrækker vi Agile frem for Waterfall? Vi kan roligt lade "Waterfall er dødt, længe leve Agile" ligge, hvor det hører hjemme. Som hovedregel er den ene ikke bedre end den anden, og det er for det meste en fejl at tro andet. Vi kørte med Waterfall i lang tid og skiftede til Agile, da vi fandt ud af, at det passede bedre til karakteren af de fleste af vores projekter.
I vores udviklingsproces har vi taget Scrum til os, som er en delmængde af Agile, med et par justeringer tilpasset vores kunders behov. Først kommer Discovery, derefter en Proof of Concept-fase, der kan afsluttes med en MVP, og derefter en række sprints, der tilføjer værdi løbende. Hvert sprint afsluttes med en definition af "done", som er aftalt med kunden, så "færdig" betyder det samme på begge sider af bordet.
Vores projekter er for det meste nye digitale produkter, hvor kravene ændrer sig, efterhånden som vi bliver klogere, hvilket er præcis den forudsætning, Agile er skabt til. Hvis vi arbejdede med en integration med fast scope og en fastlagt deadline, ville regnestykket se anderledes ud – og det ville vi også sige. Det ville være en fejl at betragte dette som den bedste proces for ethvert projekt, og derfor evaluerer og tilpasser vi den, når der er behov for det. Universelle løsninger findes ikke.
Ja, og det gør de fleste organisationer i dag. Den almindelige hybridmodel fastholder en faseopdelt struktur på programniveau med faste milepæle og compliance-gates, mens selve leverancen i hver fase køres agilt. Det fungerer, når grænsen mellem det faste og det fleksible er velovervejet, men det slår fejl, hvis omfang, tidsplan og budget alle er fastlåst på én gang.
Ingen af delene er i sig selv billigere. Waterfall giver et samlet estimat på forhånd, hvilket er billigere, hvis kravene holder, men dyrt, hvis der ophobes ændringsanmodninger. Agile bruger løbende af et budget og mindsker risikoen for at bygge det forkerte, men den endelige slutsum er mindre forudsigelig fra starten.
Waterfall passer mere naturligt til en fast pris for et fast omfang, fordi begge parter er enige om, hvad der købes, før arbejdet går i gang. Agile kan også udføres til fast pris ved at fastsætte budgettet og tidsrammen frem for omfanget, hvor backloggen prioriteres inden for disse rammer.
Ja. Den er stadig udbredt i regulerede brancher, offentlige udbud og integrationsarbejde med faste eksterne afhængigheder, hvor dokumentation, fase-gates og et defineret omfang er kontraktlige krav frem for præferencer.
Waterfall, eller en hybridmodel, er mest almindelig, hvor revisorer forventer dokumentation via fase-gates. Agile kan opfylde de samme krav, men dokumentation og sporbarhed skal indbygges i definitionen af "done" frem for at blive taget for givet.
Start med at se på, hvor stabile kravene er. Hvis omfanget kan defineres nu og holder stik, er Waterfall en mulighed. Hvis det bliver dyrt at opdage en forkert antagelse sent i forløbet, bør du vælge Agile. Vurder derefter, hvordan arbejdet er kontraheret, hvor ofte interessenter kan deltage, og hvilken dokumentation du skal kunne fremvise i forhold til compliance – altså de fire kriterier ovenfor.
Waterfall færdiggør hver fase, før den næste påbegyndes, og leverer det færdige produkt én gang til sidst. Agile arbejder i korte iterationer, der hver især leverer fungerende software, så kravene kan løbende tilpasses, efterhånden som produktet tager form.
Waterfall er ikke død, og Agile er ikke i sig selv det bedre valg. At betragte en af metoderne som standarden er den farligste måde at gribe softwareudvikling an på. De seneste år har gjort "at være Agile" til en fordel, en virksomhed kan bryste sig af – og alt det postyr gør det sværere at se, hvad Waterfall og Agile egentlig er til for.
Så undersøg terrænet, før du vælger kanalen eller floden. Stabilitet i krav, omkostninger ved ændringer, kontraktmodel og dokumentation af overholdelse er de fire kriterier, der afgør valget. Forstå dit projekts behov, vælg den metode, der passer til dem, og tilpas dig undervejs.
Overvejer du leveringsmodellen til dit næste projekt? Vi tager gerne en snak om det – også i de tilfælde, hvor Waterfall er det rigtige svar. Book et opkald så kortlægger vi dine krav, begrænsninger og kontraktmodel i forhold til den tilgang, der passer bedst.
Indholdsadministrator, teksteditor, og præsentator for strategiske ideer, sammen med at være en ivrig fan af filmkunst og visuel historiefortælling.
People who read this post, also found these interesting:
.webp)
