Denne side er blevet automatisk oversat. For en bedre læseoplevelse bedes du skifte til engelsk.

Skift til engelsk

Agile vs. vandfaldsmetoden - sammenligning og forskelle

I arbejdslivet hører vi hele tiden, at vi befinder os i en VUCA-verden, og at vi er nødt til at tilpasse os vores stadigt skiftende omgivelser. Alle taler om, at vi befinder os i en transformation mod agilitet. Nogle mennesker kan måske ikke længere gennemskue det og undrer sig over, hvad det overhovedet betyder for organisationer. 

I modsætning til den såkaldte vandfaldsmetode er agilitet af en helt anden kaliber. Når man prøver at forstå, hvad Agile vs. vandfaldsmetoden er, og hvad der er bedst hvornår, er det meget muligt at blive forvirret. 

Hvis du har det på samme måde, kan vi måske hjælpe dig, for her forklarer vi, hvad agil vs. vandfald betyder.

Vandfaldsmodel

Tro mod mottoet “gamle koste fejer godt” bruges den afprøvede vandfaldsmetode i mange virksomheder. Det er ikke overraskende og bestemt ikke altid forkert, for vandfaldsmodellen er klassikeren inden for projektledelse og har i mange tilfælde bevist, at den kan være effektiv.

Men hvad betyder Agil vs. Vandfald egentlig konkret? Vandfaldsmodellen er en lineær fremgangsmåde, hvor fremgangsmåden er organiseret i fortløbende projektfaser med konkret definerede start- og slutpunkter. Groft sagt kan man forestille sig det sådan her:

Før vi går i dybden, en hurtig bemærkning. Vi havde for nylig 11 internationale agile eksperter som gæster i et webinar – om et spørgsmål: Hvordan skalerer man agile metoder ordentligt?

Resultatet er denne fantastiske videooptagelse (engelsk), som bl.a. behandler følgende spørgsmål:

  • Er det bedre at starte nedefra og op eller oppefra og ned?
  • Hvordan får man ledere til at enes om en fælles vision?
  • Hvordan vælger man det rigtige agile framework –, og hvorfor er det egentlig ikke så vigtigt?

Min varmeste anbefaling: Tag et kig! Det tager relativt lang tid, men det er hvert minut værd.

Lad os se på det hele med et simpelt eksempel:

I Definitionsfasen fastlægges det først, hvad der overhovedet skal skabes. For eksempel giver kunden et ønske: Han vil gerne have et bord. Man analyserer og definerer derefter kravene og laver en plan for, hvad der skal gøres. I udkastet laver man derefter et produktudkast, i vores eksempel altså en skitse af bordet. 

I Implementeringsfasen bliver det hele mere håndgribeligt: Vi vælger materiale, bestemmer de nøjagtige mål og bygger bordet. I kontrollen kontrollerer vi, om alt fungerer, som vi har planlagt: Står bordet? Passer proportionerne? Den Evaluering sker derefter sammen med kunden: Vi overdrager produktet og får feedback. 

Så hvorfor ændre noget, når man siger, at man aldrig skal ændre et kørende system.

Agile (iterativ) vs. vandfaldsmetode (lineær)

Selv om vandfaldsmodellen bestemt har gode sider og er effektiv i mange situationer, bør virksomheder engagere sig i at blive mere agile. Og hvorfor? Fordi den verden, vi alle opererer i, stiller flere og flere komplekse og modstridende krav til os, og vi har ofte svært ved at reagere på dem med vandfaldstænkning.

Vandfaldsmetoden har nogle farer. Selvom vi har en høj følelse af sikkerhed gennem planlægning og struktur, er vi også meget bundne i vores processer. Arbejdsprocessen er ret statisk, og på grund af den nøjagtige planlægning har vi kun et meget lille fleksibelt spillerum. Og det er netop det, vi har brug for i vores dynamiske miljø. Det er her, agilitet kommer ind i billedet. Så lad os tage et kig på Agile i forhold til vandfaldsmetoden.

Men hvad er egentlig definitionen på agil? I henhold til Duden agile er noget i retning af “Tydelig smidighed; hurtig og adræt” og denne definition kan overføres til arbejdslivet. 

Agilitet i virksomheder betyder at være i stand til iterativt at tilpasse strategier, strukturer og processer til de faktiske, aktuelle omstændigheder. Det er vigtigt, da vi står over for komplekse forandringer på grund af digitalisering og demografiske ændringer og derfor er nødt til at være omstillingsparate. 

I øvrigt, en kort bemærkning i forbindelse med agil transformation: Vil du være sikker på, at I aktuelt sætter de rigtige prioriteter i jeres agile transformation? 

Så tag vores modenhedscheck for jeres agile transformation - det tager kun 3 minutter. Du får endda et benchmark baseret på de over tre hundrede andre deltagere. Se knappen 🙂

At bygge et bord med agile metoder

Lad os holde os til det samme eksempel som før: Kunden vil have et bord. Så vi starter med at lave en skitse. Jeg viser den til kunden, og han beslutter så, om han har forestillet sig det på den måde eller ej. Hvis ikke, tilpasses skitsen igen. Så snart skitsen er færdig, vælger jeg materialet og spørger iterativt kunden, om alt er til hans tilfredshed.

Måske siger kunden så: “Åh nej, jeg tror hellere, jeg vil have fyrretræ i stedet for kirsebær”. Så er det alligevel en anden træsort, og vi foretager et nyt valg. Derefter samles bordet, og også her konsulteres kunden regelmæssigt, og der foretages ændringer, hvis det er nødvendigt.
Det kan du se: Den agile metode giver os mulighed for at reagere fleksibelt på skiftende krav, hvilket er relevant i det komplekse miljø. 

Derfor er vandfaldsmetodikkens statiske natur ikke altid tilstrækkelig. Desuden kan det ske, at fejl i implementeringen først bliver synlige under evalueringen på grund af vandfaldsmodellens stive koncept. Dette ville resultere i betydeligt højere korrektionsomkostninger end en fleksibel tilpasning.

Agile vs. vandfaldsmetoder i arbejdslivet

Det er ofte stadig svært at designe agile og iterative processer i virksomheder. Det skyldes, at folk har en tendens til at være risikoaverse af natur og nogle gange er blevet socialiseret i deres professionelle kontekst i årtier med et tankemønster formet af vandfald. 

Risikoaversion betegner her tendensen til i beslutningssituationer at vælge den mulighed, der er forbundet med mindst risiko - altså det mindste tab - med hensyn til resultatet. (jf. Kahneman & Tversky, 1979)

Agile vs. Vandfaldsmetoder kræver, at vi opgiver denne formodede sikkerhed: I stedet for at ty til gennemprøvede metoder og bruge faste strukturer og principper, brydes gamle tankemønstre om planlægningsillusionen, og iterative metoder anvendes. Det fører i første omgang til en følelse af øget usikkerhed, da man er nødt til at anvende nye - tilsyneladende risikable - fremgangsmåder, der fortolker usikkerhed som en del af planen.

Planlægning af denne usikkerhed fører til den nødvendige fleksibilitet på lang sigt. Vi udvikler en række handlemuligheder, som igen stabiliserer sikkerheden i VUCA-arbejdsverdenen.

At holde dynamik og stabilitet i balance 

Den agile metodologi - ligesom Vandfaldsmetodologien - indeholder visse ulemper:

  • Agile-metoder synliggør og tager højde for planlægningsusikkerheder, så planerne skal indeholde mere plads til nye fund.
  • Det konkrete resultat er sværere at estimere, da nye fund kan føre til afvigelser fra det oprindeligt planlagte resultat.
  • Af de grunde, der er nævnt ovenfor, virker succeser mindre kalkulerbare i modsætning til det klassiske vandfaldsprojekt.

Det er selvfølgelig mere eller mindre hensigtsmæssigt med forskellige fremgangsmåder afhængigt af projektet.
Vandfaldsmodellen er især velegnet til projekter, der allerede indeholder kendte og konstante krav på forhånd. indeholder. 

Agile metoder er især optimale til projekter, hvor mange uforudsigelige faktorer kan forekomme, og derfor er fleksible refleksionssløjfer nødvendige. I de fleste teknologiske projekter er en sådan usikkerhed uundgåelig, hvorfor netop agile metoder er stærkt på vej frem her.

Forresten: Hvis du specifikt ønsker at kræve en agil tankegang i dit team eller din virksomhed, er det værd at tage et kig på vores artikel om den Den fantastiske sandhed bag den agile tankegang .

Agile vs. vandfaldsmetode eller kombination?

Med al den hype omkring “agil” kan man nogle gange være tilbøjelig til at se agile metoder som et universalmiddel. Med urette. Det måske overraskende resultat af denne tekst er entydigt.

Det viser sig, at brugen af af begge metoder kombineret fører effektivt til målet (Herrmann, 2007). Sådanne kombinationer er nyttige i situationer, hvor vandfaldsmodellen er påkrævet, men hvor den ikke passer til projektets kompleksitet. 

En slags mellemting mellem begge metoder er den såkaldte Funktionsdrevet udvikling (FDD).

FDD udvikler man ganske vist - som ved Vandfaldsmetoden - en konkret, langsigtet plan med enkelte, fastlagte sekvenser: funktionerne. De enkelte funktioner er dog meget korte, hvilket gør det muligt at reagere hurtigt på skiftende krav. Fremgangsmåden er ikke så iterativ som agile metoder, men kan eventuelt være en passende mellemvej. 

Og sådan kommer vi frem til det snarere overraskende resultat: Det behøver ikke altid at hedde Agil vs. Vandfaldsmetode. De to metoder kan sagtens supplere hinanden. Begge har deres berettigelse. Afhængigt af projekt og kontekst.

Men da agile metoder stadig er ukendt land for mange, spørger de med rette sig selv, hvordan de kan give agile metoder et forsøg.

Er du i tvivl om, hvordan du starter?

For mange er “agilitet” stadig nyt land. De stiller sig med rette spørgsmålet: Vil jeg hellere gøre projektet agilt eller efter vandfald? Hvordan ville jeg overhovedet begynde med agile metoder? Et “agilt” svar på dette ville være: Start eksperimenter. Prøv iterativt forskellige ting af.

Klassisk set indføres agile metoder via to veje, som også er fremragende til “begyndere”: Kanban og retrospektiver.

Kanban og retrospektiver som et klassisk udgangspunkt

Kanban bruger en offentligt synlig (Kanban)-tavle, hvor hvert teammedlem gør sine aktuelle aktiviteter gennemsigtige. Det fremmer kommunikation, effektivitet og i sidste ende projektets succes. Du kan finde mere information om Kanban her

Den grundlæggende idé bag retrospektive møder er at reflektere aktivt over hinanden som et team på en regelmæssig basis. Typisk hver 14. dag sætter man sig ned til et retrospektivt møde og stiller spørgsmål som: Hvad går godt lige nu? Hvad går ikke så godt? Og hvad kan vi gøre for at gøre tingene bedre?

Hvis I overvejer at indføre agile metoder…

Hvis du stadig er på udkig efter et passende retrobræt, kan vores artikel hjælpe dig med emnet: De bedste retroboards i sammenligning.

Kilder

Richard H. Thaler, Amos Tversky, Daniel Kahneman, Alan Schwartz, The Effect of Myopia and Loss Aversion on Risk Taking: An Experimental Test, The Quarterly Journal of Economics, bind 112, udgave 2, maj 1997, side 647–661, https://doi.org/10.1162/003355397555226

Herrmann, A. (2007). Funktionsdrevet udvikling mellem vandfald og agilitet.

akquinet

Blog-kategori

Flere artikler om "Skalering af smidighed"

Se alle artikler i denne kategori
Agil Spotify-model: Squads, Tribes, Chapters & Guilds forklaret

Agil Spotify-model: Squads, Tribes, Chapters & Guilds forklaret

Den agile Spotify-model med Squads, Tribes, Chapters og Guilds forklaret på en enkel måde. Lær mere om fordele, typiske faldgruber og anvendelsestilfælde.

Agility Health Radar: De 13 mest populære modeller for agile KPI'er

Agility Health Radar: De 13 mest populære modeller for agile KPI'er

Opdag de 13 mest populære Agility Health Radar-modeller til agile KPI'er. Optimer dine teams og projekters sundhed med disse værktøjer.

Arbejdsaftaler: 10 eksempler, prøver og skabeloner

Arbejdsaftaler: 10 eksempler, prøver og skabeloner

Agile Working Agreements: 10 eksempler, mønstre & skabeloner til Scrum, Remote Teams og SAFe. Sådan forbedrer du samarbejdet og styrker teams!

Scrum Masteren som tjenende leder: 8 tanker til eftertanke

Scrum Masteren som tjenende leder: 8 tanker til eftertanke

Lær, hvordan du som Scrum Master bliver en Servant Leader! 8 tips om kommunikation, selvorganisering og agil projektledelse til dit agile team.

Resultatmål for produktchefer: 5 tips og eksempler

Resultatmål for produktchefer: 5 tips og eksempler

Produktchef Performance Mål: Tips & eksempler på smarte mål, niveauer og udvikling. Lær her, hvordan du gør præstationen målbar!

Hvad er en Product Owner i Scaled Agile Framework SAFe? - Tal, data, fakta 

Hvad er en Product Owner i Scaled Agile Framework SAFe? - Tal, data, fakta 

Hvad laver en SAFe Product Owner? Vi forklarer rollen i Scaled Agile Framework, opgaver, ansvarsområder og de 6 typer af Product Owners.

Scrum - hvad er det? Det er ganske enkelt forklaret!

Scrum - hvad er det? Det er ganske enkelt forklaret!

Scrum let forklaret: Hvad betyder agilt arbejde? Vi belyser rollerne (Product Owner, Scrum Master, Team), Sprint, Backlog og Scrums succes.

Kombination af OKR og Scrum: Sådan fungerer det (workshops, sprintmål og cyklusser)

Kombination af OKR og Scrum: Sådan fungerer det (workshops, sprintmål og cyklusser)

Lær, hvordan du kombinerer OKR og Scrum med succes! Vi viser dig, hvordan workshops, sprintmål og cyklusser passer optimalt sammen. Sådan fungerer agilt arbejde!

Agile i stor skala: En sammenligning af de 5 vigtigste frameworks

Agile i stor skala: En sammenligning af de 5 vigtigste frameworks

Agil i stor skala: Opdag de vigtigste frameworks (SAFe, LeSS, DA, Spotify, Scrum@Scale) til agil skalering i virksomheden. 5 principper & 6 trin.

Echometer Nyhedsbrev

Gå ikke glip af opdateringer om Echometer & få inspiration til agilt arbejde