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 smidig vs. fossefall helt konkret? Fossefallsmodellen er en lineær prosedyremodell der prosessen organiseres i suksessive prosjektfaser med konkret definerte start- og sluttpunkter. Grovt sett kan du forestille deg 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 definisjonsfasenbestemmes det først hva som skal skapes. Kunden oppgir for eksempel et ønske: Han vil ha et bord. Deretter analyseres og defineres kravene, og det utarbeides en plan for alt som skal gjøres. I utkastet lager man så et produktutkast, i vårt eksempel en skisse av bordet.
I implementeringsfasenblir det hele mer håndgripelig: Vi velger materialer, bestemmer de nøyaktige målene og bygger bordet. I kontrollfasen sjekker vi om alt fungerer som planlagt: Står bordet stødig? Er proporsjonene riktige? Evalueringen skjer deretter sammen med kunden: Vi overleverer produktet og får tilbakemeldinger. </span
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, en liten bemerkning i forbindelse med smidig transformasjon: Ønsker du å forsikre deg om at du for øyeblikket er de riktige prioriteringene i din agile Forvandling?
Ta deretter vår modenhetssjekk for din smidige transformasjon – tar bare 3 minutter. Du får til og med en benchmark basert på over tre hundre andre deltakere. Se knappen 🙂.
Å 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.
De fleste Agile-bussene kjører rundt i sirkler....
og behandle overfladiske symptomer. Det er på tide å bruke psykologi – for å oppnå en bærekraftig holdningsendring.
"Hvorfor tar det meg noen ganger flere timer å forberede et enkelt tilbakeblikk?"
Agile 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.
Med risikoaversjon menes her tendensen til å velge det alternativet i beslutningssituasjoner som er forbundet med minst risiko –, dvs. minst tap – med hensyn til utfallet. (jf. Kahneman & Tversky, 1979).
Agile vs. fossefallsmetoder krever at vi gir opp denne antatte tryggheten: I stedet for å falle tilbake på velprøvde metoder og bruke faste strukturer og prinsipper, bryter man opp gamle tankemønstre fra planleggingsillusjonen og bruker iterative metoder. Dette fører i første omgang til en opplevd økning i usikkerhet, ettersom man må anvende nye, tilsynelatende risikable –-prosedyrer 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
Både den smidige metoden – og fossefallsmetoden – har 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.
Selvfølgelig er ulike tilnærminger mer eller mindre egnet avhengig av prosjektet.
Vannfallsmodellen er spesielt egnet for prosjekter som allerede på forhånd inneholder kjente og konstante krav. .
Agile-metoder er spesielt optimale for prosjekter der mange uforutsigbare faktorerkan oppstå og fleksible refleksjonssløyfer derfor er nødvendige. I de fleste teknologiprosjekter er slik usikkerhet uunngåelig, og det er derfor smidige metoder er på fremmarsj nettopp 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 ha en tendens til å se agile metoder som et universalmiddel. Med urette. Det kanskje oppsiktsvekkende 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 Som i fossefallsmetodikken utvikles det en konkret, langsiktig plan med individuelle, faste sekvenser: funksjonene. De enkelte funksjonene er imidlertid svært korte, noe som muliggjør kortsiktige reaksjoner på endrede krav. Tilnærmingen er ikke like iterativ som smidige metoder, men representerer en mellomting der det er hensiktsmessig.
Og så kommer vi til en ganske forvirrende konklusjon: Det trenger ikke alltid å være Agile. vs. Fossemetoden. De to metodene kan også utfylle hverandre. Begge har sin berettigelse. Avhengig av prosjektet og konteksten.
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 ukjent territorium. De spør seg selv med rette: Foretrekker jeg å gjennomføre prosjektet smidig eller etter fossefallsmetoden? Hvordan skal jeg begynne med smidige metoder? Et "smidig" svar på dette vil være: Start med eksperimenter. Prøv ut forskjellige ting iterativt.
Klassisk introduseres smidige metoder på to måter som også er ideelle 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 du vurderer å innføre smidige 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.
https://www.pinuts.de/blog/webstrategie/projektmanagement-wasserfall-gegen-scrum
