Agile vs. vattenfallsmetoden - jämförelse och skillnader
I arbetslivet hör vi hela tiden att vi befinner oss i en VUCA-värld och att vi måste anpassa oss till vår ständigt föränderliga miljö. Alla talar om att vi befinner oss i en omvandling mot smidighet. Vissa människor kanske inte längre kan se igenom detta och undrar vad det betyder för organisationer överhuvudtaget.
I motsats till den så kallade vattenfallsmetoden är agility av en helt annan kaliber. När man försöker förstå vad Agile kontra vattenfallsmetoden är och vilken som passar bäst när, är det mycket möjligt att man blir förvirrad.
Om du känner likadant kanske vi kan hjälpa dig, för här förklarar vi vad agil vs. vattenfall innebär.
Vattenfallsmodellen
Enligt mottot “gamla kvastar sveper bra” används den beprövade vattenfallsmetoden i många företag. Detta är inte förvånande och absolut inte alltid fel, eftersom vattenfallsmodellen är en klassiker inom projektledning och i många fall har bevisat att den kan vara effektiv.
Men vad betyder Agil kontra Vattenfall egentligen konkret? Vattenfallsmodellen är en linjär processmodell där processen är organiserad i på varandra följande projektfaser med konkret definierade start- och slutpunkter. Grovt sett kan man föreställa sig det så här:
Innan vi går djupare, en snabb kommentar. Vi hade nyligen 11 internationella agila experter som gäster i ett webinar – om en fråga: Hur skalar man agila metoder på rätt sätt?
Resultatet är denna fantastiska videoinspelning (engelska), som bland annat tar upp följande frågor:
- Är det bättre att börja nedifrån och upp eller uppifrån och ned?
- Hur får man ledare att enas om en gemensam vision?
- Hur väljer man rätt agile framework – och varför är det egentligen inte så viktigt?
Min varmaste rekommendation: Ta en titt! Det tar relativt lång tid, men det är värt varenda minut.
Låt oss titta på det hela med ett enkelt exempel:
I definitionsfasen fastställs först vad som ska skapas överhuvudtaget. Till exempel anger kunden en önskan: Han vill ha ett bord. Man analyserar och definierar sedan kraven och skapar en plan för vad som behöver göras. I utkastet skapar man sedan ett produktutkast, i vårt exempel en skiss av bordet.
Vid implementeringsfasen blir det hela mer konkret: Vi väljer material, bestämmer de exakta måtten och bygger bordet. I kontrollen kontrollerar vi om allt fungerar som vi har planerat: Står bordet? Stämmer proportionerna? Den Utvärdering sker sedan tillsammans med kunden: Vi överlämnar produkten och får feedback.
Så varför ändra på något när ordspråket säger: ändra aldrig på ett fungerande system.
Agile (iterativ) kontra vattenfall (linjär) metodik
Även om vattenfallsmodellen definitivt har goda sidor och är effektiv i många situationer, bör företag engagera sig i att bli mer agila. Varför det? Därför att den värld som vi alla verkar i ställer allt mer komplexa och motsägelsefulla krav på oss, och vi har ofta svårt att reagera på dem med vattenfallstänkande.
Vattenfallsmetoden har vissa faror. Även om vi har en hög känsla av säkerhet genom planering och struktur, är vi också mycket bundna i våra processer. Arbetsprocessen är ganska statisk och på grund av den exakta planeringen har vi bara ett mycket litet mått av flexibelt spelrum. Och det är precis vad vi behöver i vår dynamiska miljö. Det är här smidigheten kommer in i bilden. Så låt oss ta en titt på Agile jämfört med vattenfallsmetoden.
Men vad är egentligen definitionen av agile? Enligt Duden agile är något i stil med “påtagligt rörlig; snabb och kvick” och denna definition kan väl översättas till arbetslivet.
Smidighet i företag innebär att man iterativt kan anpassa strategier, strukturer och processer till de faktiska, aktuella omständigheterna. Detta är viktigt eftersom vi står inför komplexa förändringar på grund av digitalisering och demografiska förändringar och därför måste förbli anpassningsbara.
Förresten, en kort notis i samband med agil transformation: Vill du vara säker på att ni för närvarande prioriterar rätt i er agila transformation?
Gör då vår mognadsgradskontroll för er agila transformation - det tar bara 3 minuter. Du får till och med ett riktmärke baserat på de över trehundra andra deltagarna. Se knappen 🙂
Bygga ett bord med agila metoder
Låt oss fortsätta med samma exempel som tidigare: Kunden vill ha ett bord. Så vi börjar med att göra en skiss. Jag visar den för kunden och han bestämmer sedan om han har föreställt sig det på det sättet eller inte. Om inte, anpassas skissen igen. Så snart skissen är klar väljer jag material och frågar kunden iterativt om allt är till belåtenhet.
Kanske säger kunden då: “Åh nej, jag tror att jag hellre vill ha furu istället för körsbär”. Så det är ett annat träslag trots allt: så vi gör ett nytt urval. Sedan monteras bordet och även här rådfrågas kunden regelbundet och ändringar görs vid behov.
Det kan man se: Den agila metoden gör att vi kan reagera flexibelt på förändrade krav, vilket är relevant i den komplexa miljön.
Därför är vattenfallsmetodikens statiska karaktär inte alltid tillräcklig. Dessutom kan det hända att fel i implementeringen bara blir uppenbara under utvärderingen på grund av den stela uppfattningen i vattenfallsmodellen. Detta skulle leda till betydligt högre korrigeringskostnader än en flexibel anpassning.
"Många medarbetare vågar inte säga vad de tycker!"
Lös denna utmaning
"Vi upptäcker för många oväntade problem och buggar i ett sent skede!"
Lös denna utmaning
"Varför tar det mig ibland flera timmar att förbereda en enkel retrospektiv?"
Lös denna utmaningAgile vs. vattenfallsmetoder i arbetslivet
Det är ofta fortfarande svårt att utforma agila och iterativa processer i företag. Detta beror på att människor tenderar att vara riskaverta till sin natur och ibland har socialiserats in i sitt professionella sammanhang under årtionden med ett tankemönster som är format av vattenfall.
Risk aversion avser här tendensen att i beslutssituationer välja den möjlighet som medför minst risk - alltså den minsta förlusten - när det gäller resultatet. (jfr Kahneman & Tversky, 1979)
Agila kontra vattenfallsmetoder kräver att vi ger upp denna förmodade säkerhet: Istället för att ta till beprövade metoder och använda fasta strukturer och principer, bryts gamla tankemönster om planeringsillusionen och iterativa metoder används. Detta leder först till en känsla av ökad osäkerhet, eftersom man måste använda nya - till synes riskfyllda - tillvägagångssätt som tolkar osäkerhet som en del av planen.
Att planera för denna osäkerhet leder till nödvändig flexibilitet på lång sikt. Vi utvecklar en rad handlingsalternativ, vilket i sin tur stabiliserar säkerheten i VUCA-arbetsvärlden.
Balans mellan dynamik och stabilitet
Den agila metodiken - liksom vattenfallsmetodiken - innehåller vissa nackdelar:
- Agile-metoder synliggör och tar hänsyn till osäkerheter i planeringen, så att planerna måste innehålla mer utrymme för nya rön
- Det konkreta resultatet är svårare att uppskatta, eftersom nya rön kan leda till avvikelser från det ursprungliga planerade resultatet.
- Av de skäl som nämns ovan verkar framgångar vara mindre kalkylerbara i jämförelse med det klassiska vattenfallsprojektet.
Självklart är olika tillvägagångssätt mer eller mindre lämpliga beroende på projekt.
Vattenfallsmodellen är särskilt lämplig för projekt som redan i förväg kända och konstanta krav innehåller.
Agila metoder är särskilt optimala för projekt där många oförutsägbara faktorer kan uppstå och därför flexibla reflektionsslingor är nödvändiga. I de flesta tekniska projekt är en sådan osäkerhet oundviklig, vilket är anledningen till att agila metoder är starkt på frammarsch just här.
Förresten: Om du specifikt vill kräva ett agilt tankesätt i ditt team eller företag är det värt att ta en titt på vår artikel om den fantastiska sanningen bakom det agila tankesättet .
Agile vs. vattenfallsmetod eller kombination?
Med all hype kring “agilt” kan man ibland vara benägen att se agila metoder som ett universalmedel. Med orätt. Det kanske förvånande resultatet av denna text är tydligt.
Det visar sig att användningen av av båda metoderna kombinerad leder effektivt till målet (Herrmann, 2007). Sådana kombinationer är användbara i situationer där vattenfallsmodellen krävs men denna inte är lämplig för projektets komplexitet.
Ett slags mellanting av de båda metoderna är den så kallade Funktionsdriven utveckling (FDD).
Vid FDD utvecklar man visserligen - precis som med vattenfallsmetodiken - en konkret, långsiktig plan med enskilda, fastställda sekvenser: funktionerna. De enskilda funktionerna är dock mycket korta, vilket möjliggör kortsiktiga reaktioner på förändrade krav. Tillvägagångssättet är visserligen inte lika iterativt som agila metoder, men kan eventuellt vara en lämplig medelväg.
Och så kommer vi till det ganska förvånande resultatet: Det behöver inte alltid vara Agil kontra Vattenfallsmetod. De två metoderna kan mycket väl komplettera varandra. Båda har sin plats. Beroende på projekt och sammanhang.
Men eftersom agila metoder fortfarande är okänd mark för många, frågar de sig med rätta hur de kan ge agila metoder ett försök.
Osäker på hur du ska börja?
För många är “agilitet” fortfarande nytt territorium. De ställer sig med rätta frågan: Ska jag hellre göra projektet agilt eller enligt vattenfallsmodellen? Hur skulle jag börja med agila metoder? Ett “agilt” svar på detta skulle vara: Starta experiment. Prova iterativt olika saker.
Klassiskt sett införs agila metoder på två sätt, som också är utmärkta för “nybörjare”: Kanban och retrospektiver.
Kanban och retrospektiv som en klassisk startpunkt
Kanban använder en offentligt synlig (Kanban) tavla där varje teammedlem synliggör sina aktuella aktiviteter. Detta främjar kommunikation, effektivitet och i slutändan projektets framgång. Mer information om Kanban hittar du här här.
Den grundläggande idén bakom retrospektiv är att aktivt reflektera över varandra som ett team på en regelbunden basis. Vanligtvis var fjortonde dag sätter ni er ner i ett retrospektivt möte och ställer frågor som: Vad går bra just nu? Vad är det som inte går så bra? Och vilka åtgärder kan vi vidta för att göra saker bättre?
Om ni funderar på att införa agila metoder…
Om du fortfarande letar efter en lämplig retrobräda kan vår artikel hjälpa dig med ämnet: De bästa retrobrädorna i jämförelse.
Källor
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, volym 112, utgåva 2, maj 1997, sidorna 647–661, https://doi.org/10.1162/003355397555226
Herrmann, A. (2007). Funktionsdriven utveckling mellan vattenfall och smidighet.
