Agil udvikling eller vandfaldsmodellen: Hvilken projektform passer til jeres projekt?

Af Weapp · Opdateret

Valget handler ikke om hvilken metode der er mest moderne, men om hvor sikre kravene er, hvordan budgettet skal fungere og hvor hurtigt jeres organisation kan træffe beslutninger. Er kravene klare og faste, passer et forløb efter vandfaldsmodellen. Er de usikre og skal afdækkes, passer et agilt forløb. Ofte er svaret en hybrid med en fast ramme og agil levering.

Spørgsmålet “agil eller vandfaldsmodellen” stilles ofte som et trosspørgsmål, hvor agil udvikling er det moderne og rigtige, og vandfald er noget man burde skamme sig over. Det er et dårligt udgangspunkt. Begge er værktøjer, og valget handler ikke om mode, men om tre nøgterne faktorer: hvor sikre jeres krav er, hvordan budgettet skal fungere og hvor hurtigt jeres organisation kan træffe beslutninger. Tag udgangspunkt i dem, ikke i hvad der lyder finest på et bestyrelsesmøde.

Hvad de to faktisk indebærer

I et forløb efter vandfaldsmodellen beslutter I alt på forhånd. Kravene specificeres, prisen fastsættes, og derefter bygges produktet fase for fase frem til en færdig levering. Det giver forudsigelighed: I ved hvad I får og hvad det koster. Men kun hvis kravene virkelig holder.

I et agilt forløb bygges produktet i korte cyklusser. I ser resultater tidligt og ofte og kan justere retningen undervejs. Det giver fleksibilitet og mulighed for at finde den rigtige løsning, men kræver at I er til stede og styrer. Ellers bliver de forkerte ting bygget hurtigt.

Når vandfaldsmodellen faktisk er det rigtige

Vandfaldsmodellen passer dårligt til uklare krav, men der er situationer hvor den er det fornuftige valg:

  • Kravene er veldefinerede og stabile. Ved I præcis hvad der skal bygges, og kommer det ikke til at ændre sig, er det meste af værdien ved agilitet væk.
  • Der kræves en fast pris. Skal investeringen godkendes ud fra et præcist tal, skal scopet være låst, og så passer vandfaldsmodellen.
  • Udbud eller certificering styrer. Offentlige udbud og hårde regulatoriske krav kræver ofte at alt specificeres på forhånd. Så er formen givet.

Fælden er at vælge vandfaldsmodellen fordi det føles trygt mens kravene i virkeligheden er uldne. Så låser I en pris ud fra et gæt og betaler for at bygge den forkerte ting meget præcist.

Hvad agil udvikling kræver af jer

Agil udvikling er ikke gratis fleksibilitet. Det har en pris, og prisen betales med jeres engagement. Metoden virker kun hvis I kan stille med:

  • En aktiv person på jeres side med tid og mandat til at prioritere og svare hver uge.
  • Beslutningsevne. Teamet støder hele tiden på valg og har brug for hurtige svar for ikke at gå i stå.
  • Accept af at resultatet formes undervejs. I bytter en detaljeret plan i starten ud med indflydelse gennem hele forløbet.

Mangler det, bliver agil udvikling bare en dyr måde at bygge de forkerte ting hurtigt på. En organisation der ikke kan afsætte en engageret person på kundesiden, får ofte mere ud af et klart specificeret forløb.

Et eksempel

Sig at I skal bygge et internt system og er i tvivl. Er den proces I digitaliserer, allerede fastlagt i detaljer og kendt af alle, og vil den sandsynligvis ikke ændre sig? Så kan I specificere den, bede om en fast pris og køre efter vandfaldsmodellen: forudsigeligt og til en fornuftig pris. Er det derimod et nyt kunderettet værktøj hvor I gætter jer frem til hvad brugerne vil have? Så vil kravene ændre sig når I ser virkeligheden, og en låst fastpris bliver en spændetrøje. Dér vinder I ved at arbejde agilt, gerne efter et kort forprojekt der indkredser retningen.

Hybriden er ofte svaret

Virkeligheden kræver sjældent metodemæssig renhed. Det mest almindelige sunde forløb ligger midt imellem: en fast budgetramme og et klart mål i toppen med agil og fleksibel levering inden for rammen. Ledelsen får sin forudsigelighed i form af en kendt omkostning og retning mens teamet får bevægelsesfriheden til at bygge det rigtige.

Sammenhængen med pengene er altså tydelig: Vandfaldsmodellen lægger risikoen i kravfasen og passer til fast pris mens agil udvikling leverer værdi tidligere, men kræver at I styrer scopet. Hybriden forsøger at tage det bedste fra begge. Metoden afgør ikke omkostningen alene, men den former hvordan I bevarer kontrollen over den.

Vi hos Weapp tilpasser formen efter projektet og ikke omvendt, og vi hælder ofte til en fast ramme med agil levering. Vil du drøfte hvad der passer til jeres næste projekt? Se vores ydelser eller kontakt os.

Ofte stillede spørgsmål

Er vandfaldsmodellen altid et dårligere valg end agil udvikling?

Nej. Vandfaldsmodellen har fået et dårligt ry, men passer godt når kravene er veldefinerede og stabile, når der kræves en fast pris eller når et udbud eller en certificering kræver at alt specificeres på forhånd. Problemet opstår når man bruger vandfaldsmodellen til projekter hvor kravene i virkeligheden er uklare.

Hvad kræver agil udvikling af vores organisation?

En aktiv person på jeres side med tid og mandat, evnen til at træffe løbende beslutninger og accept af at slutresultatet formes undervejs. Kan I ikke afsætte en person der prioriterer hver uge, fungerer agil udvikling dårligt: Så bliver de forkerte ting bygget hurtigt. Metoden flytter ansvaret fra kravspecifikationen til jeres tilstedeværelse.

Kan man kombinere agil udvikling og vandfaldsmodellen?

Ja, og det er ofte det bedste. En almindelig hybrid er en fast budgetramme og et klart mål i toppen med agil, fleksibel levering inden for rammen. Så får I den forudsigelighed som en ledelse ønsker, og den bevægelsesfrihed som et udviklingsprojekt har brug for. Metodemæssig renhed er sjældent pointen.

Hvordan påvirker metodevalget prisen?

Vandfaldsmodellen passer til fast pris, men lægger risikoen i kravfasen: Bliver kravene forkerte, bliver hele løsningen forkert. Agil udvikling kobles oftere med betaling efter medgået tid og leverer værdi tidligere, men kræver at I styrer scopet aktivt for at holde budgettet. Metoden afgør altså ikke omkostningen alene, men den former hvordan I styrer den.

Vi ved ikke rigtig hvad vi vil bygge. Hvilken form passer?

Så taler det meste for at arbejde agilt, eventuelt med et kort forprojekt først. At låse en detaljeret kravspecifikation når I endnu ikke ved hvad I har brug for, er den klassiske fælde: I betaler for at bygge den forkerte ting meget præcist. Når I arbejder agilt, finder I den rigtige løsning undervejs.