Agile vs. fossefallsmetoden - sammenligning og forskjeller
I arbeidslivet hører vi hele tiden at vi befinner oss i en VUCA-verden, og at vi må tilpasse oss de stadig skiftende omgivelsene. Alle snakker om at vi befinner oss i en omstilling mot smidighet. Noen kan kanskje ikke lenger gjennomskue dette og lurer på hva det i det hele tatt betyr for organisasjoner.
I motsetning til den såkalte fossefallsmetoden er agility av et helt annet kaliber. Når man prøver å forstå hva Agile vs. fossefallsmetoden er, og hva som passer best når, er det lett å bli forvirret.
Hvis du føler det samme, kan vi kanskje hjelpe deg, for her forklarer vi hva smidig vs. fossefall betyr.
Fossemodell
Tro mot mottoet “gamle koster feier godt” brukes den velprøvde fossefallsmetoden i mange bedrifter. Det er ikke overraskende og slett ikke alltid feil, for fossefallsmodellen er en klassiker innen prosjektledelse og har i mange tilfeller vist seg å være effektiv.
Men hva betyr egentlig Agil vs. fossefall konkret? Fossefallsmodellen er en lineær fremgangsmåte der fremgangsmåten er organisert i påfølgende prosjektfaser med konkret definerte start- og sluttpunkter. Grovt sett kan man forestille seg det slik:
Før vi går i dybden, en liten notis. Vi hadde nylig 11 internasjonale agile eksperter som gjester i et webinar – om et spørsmål: Hvordan skalerer man agile metoder på riktig måte?
Resultatet er dette fantastiske videoopptaket (engelsk), som blant annet tar for seg følgende spørsmål:
- Er det bedre å starte nedenfra og opp eller ovenfra og ned?
- Hvordan får man ledere til å enes om en felles visjon?
- Hvordan velge riktig agilt rammeverk –, og hvorfor er det egentlig ikke så viktig?
Min varmeste anbefaling: Ta en titt! Det tar relativt lang tid, men det er verdt hvert minutt.
La oss se på det hele med et enkelt eksempel:
I Definisjonsfasen fastlegges det først hva som skal opprettes. For eksempel gir kunden et ønske: Han vil ha et bord. Man analyserer og definerer deretter kravene og lager en plan for hva som må gjøres. I utkastet lager man deretter et produktdesign, i vårt eksempel en skisse av bordet.
I Implementeringsfasen blir det hele mer håndfast: Vi velger materiale, bestemmer de nøyaktige målene og bygger bordet. I kontrollen sjekker vi om alt fungerer som vi har planlagt: Står bordet? Stemmer proporsjonene? Den Evaluering skjer deretter sammen med kunden: Vi overleverer produktet og får tilbakemelding.
Så hvorfor endre noe som helst når det heter at man aldri skal endre et system som er i gang.
Agile (iterativ) vs. fossefallsmetodikk (lineær)
Selv om fossefallsmodellen definitivt har sine gode sider og er effektiv i mange situasjoner, bør bedrifter engasjere seg i å bli mer smidige. Hvorfor det? Fordi verden vi alle opererer i, stiller stadig mer komplekse og motstridende krav til oss, og vi har ofte vanskelig for å reagere på dem med fossefallstenkning.
Fossemetoden har noen farer. Selv om vi har en høy grad av trygghet gjennom planlegging og struktur, er vi også veldig bundet i prosessene våre. Arbeidsprosessen er ganske statisk, og på grunn av den nøyaktige planleggingen har vi bare et svært lite fleksibelt spillerom. Og det er nettopp det vi trenger i vårt dynamiske miljø. Det er her smidigheten kommer inn i bildet. Så la oss ta en titt på Agile kontra fossefallsmetoden.
Men hva er egentlig definisjonen på smidig? Ifølge Duden agile er noe sånt som “Tydelig bevegelighet; rask og kvikk”, og denne definisjonen kan godt overføres til arbeidslivet.
Smidighet i bedrifter betyr å kunne tilpasse strategier, strukturer og prosesser iterativt til de faktiske, aktuelle omstendighetene. Dette er avgjørende ettersom vi står overfor komplekse endringer som følge av digitalisering og demografiske endringer, og derfor må være tilpasningsdyktige.
Forresten, et kort notat i sammenheng med agil transformasjon: Vil du være sikker på at dere for tiden prioriterer riktig i deres agile transformasjon?
Ta vår modenhetssjekk for din agile transformasjon – det tar bare 3 minutter. Du får til og med et benchmark basert på de over tre hundre andre deltakerne. Se knapp 🙂
Å bygge et bord med smidige metoder
La oss holde oss til samme eksempel som tidligere: Kunden ønsker seg et bord. Vi begynner med å lage en skisse. Denne viser jeg kunden, og så bestemmer han seg for om han har forestilt seg det slik eller ikke. Hvis ikke, tilpasses skissen på nytt. Så snart skissen er ferdig, velger jeg materialet og spør kunden iterativt om han er fornøyd.
Kanskje kunden sier: “Å nei, jeg tror jeg heller vil ha furu i stedet for kirsebær”. Da er det et annet treslag som gjelder, og vi gjør et nytt valg. Deretter settes bordet sammen, og også her blir kunden jevnlig konsultert, og det gjøres endringer om nødvendig.
Det kan du se: Den smidige metodikken gjør at vi kan reagere fleksibelt på endrede krav, noe som er relevant i et komplekst miljø.
Derfor er det ikke alltid tilstrekkelig at fossefallsmetodikken er statisk. I tillegg kan det skje at feil i implementeringen først blir synlige under evalueringen på grunn av fossefallsmodellens rigide utforming. Dette vil føre til betydelig høyere korrigeringskostnader enn ved en fleksibel tilpasning.
"Mange teammedlemmer tør ikke å si ifra!"
Løs denne utfordringen
"Vi oppdager for mange uventede problemer og bugs på et sent tidspunkt!"
Løs denne utfordringen
"Hvorfor tar det meg noen ganger flere timer å forberede et enkelt tilbakeblikk?"
Løs denne utfordringenAgile kontra fossefallsmetoder i arbeidslivet
Det er fortsatt vanskelig å designe smidige og iterative prosesser i bedrifter. Det skyldes at folk har en tendens til å være risikoaverse av natur, og at de i noen tilfeller har blitt sosialisert inn i et tankemønster preget av fossefall i flere tiår.
Risikoaversjon refererer her til tendensen til å velge muligheten i beslutningssituasjoner som innebærer minst risiko – det vil si det minste tapet – med hensyn til resultatet. (jf. Kahneman & Tversky, 1979)
Agile vs. fossefallmetoder krever at vi gir opp denne antatte sikkerheten: I stedet for å falle tilbake på utprøvde metoder og bruke faste strukturer og prinsipper, brytes gamle tankemønstre om planleggingsillusjonen og iterative metoder brukes. Dette fører først til en følelse av økt usikkerhet, fordi man må bruke nye – tilsynelatende risikable – tilnærminger som tolker usikkerhet som en del av planen.
Å planlegge for denne usikkerheten fører til den nødvendige fleksibiliteten på lang sikt. Vi utvikler en rekke handlingsalternativer som igjen stabiliserer sikkerheten i VUCA-arbeidslivet.
Å holde dynamikk og stabilitet i balanse
Den agile metodologien – som også fossefallmetodologien – innebærer visse ulemper:
- Agile-metoder synliggjør og tar hensyn til usikkerhet i planleggingen, slik at planene i større grad må ta høyde for nye funn.
- Det konkrete resultatet er vanskeligere å estimere, ettersom nye funn kan føre til avvik fra det opprinnelige planlagte resultatet.
- Av de grunnene som er nevnt ovenfor, virker suksesser mindre kalkulerbare enn i det klassiske fossefallsprosjektet.
Det er selvsagt forskjellige fremgangsmåter som er mer eller mindre egnet avhengig av prosjektet.
Fossefallsmodellen er spesielt egnet for prosjekter som allerede har kjente og konstante krav inneholder.
Agile metoder er spesielt optimale for prosjekter der mange uforutsigbare faktorer kan oppstå og fleksible refleksjonsløkker derfor er nødvendige. I de fleste teknologiske prosjekter er en slik usikkerhet uunngåelig, og det er derfor agile metoder er sterkt på fremmarsj her.
Forresten: Hvis du spesifikt ønsker å etterspørre en smidig tankegang i teamet eller selskapet ditt, er det verdt å ta en titt på artikkelen vår om Den fantastiske sannheten bak det smidige tankesettet .
Agile vs. fossefallsmetode eller en kombinasjon?
Med all hypen rundt «agile» kan man noen ganger bli fristet til å se agile metoder som en universalmiddel. Med urette. Det kanskje overraskende resultatet av denne teksten er tydelig.
Det viser seg at bruken av av begge metodene kombinert fører effektivt til målet (Herrmann, 2007). Slike kombinasjoner er nyttige i situasjoner der fossefallsmodellen er påkrevd, men ikke passer til prosjektets kompleksitet.
En slags mellomting mellom de to metodene er den såkalte Funksjonsdrevet utvikling (FDD).
På FDD utvikler man riktignok – som i fossefallmetoden – en konkret, langsiktig plan med individuelle, fastlagte sekvenser: funksjonene. Imidlertid er de enkelte funksjonene svært korte, noe som muliggjør kortsiktige reaksjoner på skiftende krav. Fremgangsmåten er ikke like iterativ som agile metoder, men kan eventuelt representere en passende mellomting.
Og slik kommer vi til det heller overraskende resultatet: Det trenger ikke alltid å hete Agil vs. fossefallmetode. De to metodene kan absolutt utfylle hverandre. Begge har sin berettigelse. Avhengig av prosjekt og kontekst.
Men siden agile metoder fortsatt er ukjent terreng for mange, spør de seg med rette hvordan de kan prøve seg på agile metoder.
Er du usikker på hvordan du skal begynne?
For mange er «smidighet» fortsatt nytt territorium. De stiller seg med rette spørsmålet: Vil jeg heller gjøre prosjektet smidig eller etter fossefall? Hvordan ville jeg begynt med agile metoder? Et «agilt» svar på dette vil være: Start eksperimenter. Prøv iterativt forskjellige ting.
Klassisk sett introduseres agile metoder på to måter, som også er utmerket for «nybegynnere»: Kanban og retrospektiver.
Kanban og retrospektiver som et klassisk utgangspunkt
Kanban bruker en offentlig synlig tavle (Kanban-tavle) der hvert teammedlem synliggjør sine aktuelle aktiviteter. Dette fremmer kommunikasjon, effektivitet og til syvende og sist prosjektets suksess. Her finner du mer informasjon om Kanban her.
Grunntanken bak retrospektive møter er å reflektere aktivt over hverandre som team med jevne mellomrom. Vanligvis setter man seg ned i et retrospektivt møte hver fjortende dag og stiller spørsmål som: Hva går bra akkurat nå? Hva går ikke så bra? Og hvilke tiltak kan vi iverksette for å gjøre ting bedre?
Hvis dere tenker på å innføre agile metoder…
Hvis du fortsatt er på utkikk etter et passende retrobrett, kan artikkelen vår hjelpe deg med emnet: De beste retrobrettene 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, Volume 112, Issue 2, May 1997, Pages 647–661, https://doi.org/10.1162/003355397555226
Herrmann, A. (2007). Funksjonsdrevet utvikling mellom fossefall og smidighet.
