Agil vs vandfald: hvilken metode passer til jeres IT-projekt?

For et år siden underskrev en virksomhed en kontrakt på en ny medlemsplatform med en kravspecifikation på 80 sider. I måned ni får de det færdige system at se for første gang. Det gør præcis det, der står i specifikationen, men verden har flyttet sig: halvdelen af medlemmerne bruger nu mobilen, en ny betalingsløsning er blevet standard, og to af de vigtigste funktioner viser sig at være for besværlige i praksis. Ingen gjorde noget forkert. Metoden gav dem bare først svar, da det var dyrt at ændre noget. Det er kernen i debatten om agil vs vandfald.

Denne guide er skrevet til jer, der køber software, og som skal forstå, hvad leverandørens metode betyder for pris, risiko og jeres egen tid. I får forskellene forklaret, en sammenligningstabel, en beslutningstabel, et regneeksempel og et konkret svar på, hvordan fast pris og agil udvikling passer sammen.

Hvad er forskellen på agil og vandfald?

Hvad er vandfaldsmodellen?

Vandfaldsmodellen er den klassiske måde at styre projekter på. Den har navnet, fordi arbejdet flyder nedad fra fase til fase, og hver fase skal være færdig og godkendt, før den næste begynder. Metoden kommer fra byggeri og produktion, hvor det giver god mening: man kan ikke støbe fundamentet om, når taget er lagt på.

Styrken er forudsigelighed: I kender scope, pris og deadline fra start, og der er grundig dokumentation. Svagheden er, at I først ser og prøver løsningen sent. Har kravspecifikationen et hul, eller har behovet ændret sig, opdages det i testfasen, hvor ændringer er dyrest. Det er en af de hyppigste årsager til, at IT-projekter fejler.

Hvad er agil udvikling?

Agil udvikling er en samlebetegnelse for metoder, der bygger software i små, færdige stykker og bruger feedback til at styre retningen. Begrebet blev formuleret i Det Agile Manifest fra 2001, hvor en gruppe softwareudviklere beskrev fire værdier, blandt andet at fungerende software og samarbejde med kunden vægter højere end omfattende dokumentation og kontraktforhandling. De mest udbredte metoder er Scrum og Kanban. I praksis består et agilt projekt typisk af disse elementer:

• En backlog: en prioriteret liste af brugerhistorier, der beskriver, hvad der skal bygges.
• En produktejer hos kunden, der prioriterer listen og træffer beslutninger.
• Korte forløb, kaldet sprints, typisk på 1–2 uger, hvor en del af listen bygges færdig.
• En demo ved slutningen af hvert forløb, hvor kunden ser og prøver det nye.
• En evaluering, hvor teamet forbedrer måden at arbejde på.
• En definition af “færdig”, så alle ved, hvornår en historie er klar til brug.

Agil vs vandfald: sammenligning punkt for punkt

Hvornår skal man vælge agil, og hvornår vandfald?

Kan man kombinere fast pris med agil udvikling?

Ja, og det er efter vores erfaring den model, der passer bedst til de fleste små og mellemstore virksomheder. Mange tror, at agil kræver timepris, fordi scopet kan ændre sig. Men agil handler om at prioritere og levere i små stykker, og det kan sagtens ske inden for en fast ramme. Nøglen er at skelne mellem tre ting: hvad der ligger fast, hvad der kan justeres, og hvordan ændringer håndteres.

• Fast: prisen, den overordnede ramme og antallet af funktioner og integrationer.
• Fast: must-historierne, som er beskrevet med acceptkriterier før start.
• Justerbart: detaljerne i design og flow, som afklares sprint for sprint.
• Justerbart: rækkefølgen, så det vigtigste bygges og vises først.
• Ændringer: en ny idé kan byttes med en funktion af samme størrelse uden ekstra pris.
• Ændringer: ønskes der mere, prissættes tillægget fast, før det bygges.

Vores pakker følger samme tankegang. I får et skriftligt tilbud til fast pris inden for 24 timer, med antallet af funktioner og integrationer listet, og I følger fremdriften i vores kundepanel, hvor I kan se, hvad der er færdigt, og hvad der venter på jer. Vil I dykke ned i økonomien bag modellerne, så læs guiden til fast pris vs timepris.

Sådan fungerer den hybride model trin for trin

Regneeksempel: samme kundeportal med to metoder

Forestil jer en kundeportal med 24 funktioner og to integrationer. Tallene er et eksempel. I vandfaldsversionen er alt beskrevet på forhånd, og kunden ser portalen første gang i uge 12. Her viser det sig, at kunderne gerne vil kunne downloade fakturaer som samlet fil, og at ordreoversigten er for tung på mobilen. Begge dele kræver ændringer i allerede færdig kode, og det bliver til et tillæg og fire ugers forsinkelse.

I den hybride version er de samme 24 funktioner aftalt til fast pris, men ordreoversigten bygges og vises allerede i uge 4. Kunden tester den på sin telefon og beder om en enklere mobilversion, som justeres i næste forløb. Ønsket om samlet download af fakturaer dukker op i uge 6 og byttes med en statistikside, som alle er enige om kan vente til version to. Portalen lanceres til tiden og til den aftalte pris. Det er samme team, samme timer og samme budget. Forskellen er, hvornår spørgsmålene bliver stillet.

Hvilke myter om agil udvikling skal I kende?

• “Agil betyder, at der ikke er nogen plan.” Agile projekter har en klar retning og en prioriteret liste. Planen bliver bare mere detaljeret undervejs.
• “Agil betyder ingen dokumentation.” Der dokumenteres det, der skaber værdi: brugerhistorier, acceptkriterier og tekniske beslutninger.
• “Agil er altid dyrere.” Med en fast ramme er prisen kendt, og tidlig feedback sparer ofte timer.
• “Vandfald er forældet.” Til projekter med faste krav og mange afhængigheder er det stadig et stærkt valg.
• “Vi skal bruge Scrum for at være agile.” Scrum er én metode. Det vigtigste er korte forløb, hyppige demoer og en prioriteret liste.

Hvilke spørgsmål skal I stille leverandøren om deres arbejdsmetode?

1. Hvor ofte ser vi fungerende software, som vi selv kan prøve?
2. Hvem hos jer bygger løsningen, og møder vi dem fra start?
3. Hvordan håndterer I ændringer, og hvad koster de?
4. Hvad ligger fast i aftalen: pris, scope, deadline eller alle tre?
5. Hvordan beskriver I, hvornår en funktion er færdig?
6. Hvor meget tid skal vi selv afsætte om ugen?
7. Hvordan kan vi følge fremdriften mellem møderne?
8. Hvad sker der, hvis vi vil stoppe efter halvdelen?

Gode svar er konkrete: demo hver eller hver anden uge, en navngivet kontaktperson i teamet, en skriftlig regel for ændringer og adgang til et overblik, I selv kan tjekke. Starter I helt fra bunden, så begynd med en discovery-workshop, og se, hvordan tidsplanen typisk ser ud i guiden til hvor lang tid det tager at lave en app. Er I klar til et tal, så beskriv projektet her, og få et skriftligt tilbud til fast pris inden for 24 timer.