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 egentligen agil vs. vattenfall rent konkret? Vattenfallsmodellen är en linjär processmodell där processen organiseras i successiva projektfaser med konkret definierade start- och slutpunkter. I grova drag 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 definitionsfasenbestäms först vad som ska skapas i första hand. Kunden uttrycker till exempel en önskan: Han vill ha ett bord. Därefter analyseras och definieras kraven och en plan upprättas för allt som behöver göras. I utkastet skapar man sedan ett produktutkast, i vårt exempel en skiss av bordet. .
I genomförandefasenblir det hela mer konkret: vi väljer material, bestämmer de exakta måtten och bygger bordet. I kontrollfasen kontrollerar vi om allt fungerar som vi planerat: Står bordet stadigt? Är proportionerna de rätta? Utvärderingen 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 snabb kommentar i samband med agil omvandling: Vill du se till att du för närvarande är rätt prioriteringar i din agila organisation Förvandling?
Ta sedan vår mognadskontroll för din agila transformation – tar bara 3 minuter. Du får även ett riktmärke baserat på över trehundra andra deltagare. 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.
De flesta Agile-vagnar kör i cirklar....
...och behandla ytliga symptom. Det är dags att använda psykologi – för en hållbar förändring av tankesättet.
Agile 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.
Med riskaversion avses här tendensen att i beslutssituationer välja det alternativ som är förknippat med minst risk – dvs. minst förlust – med avseende på utfallet. (jfr Kahneman & Tversky, 1979)
Agile vs. vattenfallsmetoder kräver att vi ger upp denna förmodade säkerhet: istället för att falla tillbaka på beprövade metoder och använda fasta strukturer och principer, bryts gamla tankemönster i planeringsillusionen upp och iterativa metoder används. Detta leder inledningsvis till en upplevd ökning av osäkerheten, eftersom man måste tillämpa nya – till synes riskfyllda – förfaranden 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
Såväl den agila metoden – som vattenfallsmetoden – 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.
Beroende på projektet är naturligtvis olika metoder mer eller mindre lämpliga.
Vattenfallsmodellen är särskilt lämplig för projekt som redan i förväg innehåller kända och konstanta krav. .
Agile-metoder är särskilt optimala för projekt där många oförutsägbara faktorerkan inträffa och flexibla reflektionsloopar därför är nödvändiga. I de flesta tekniska projekt är en sådan osäkerhet oundviklig, vilket är anledningen till att agila metoder är 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 "agile" kan man ibland ha en tendens att se agila metoder som en universallösning. Helt felaktigt. Det kanske häpnadsväckande 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 Precis som i vattenfallsmetodiken utvecklas en konkret, långsiktig plan med enskilda, fasta sekvenser: features. De enskilda funktionerna är dock mycket korta, vilket gör det möjligt att reagera kortsiktigt på förändrade krav. Tillvägagångssättet är inte lika iterativt som agila metoder, men det utgör en lämplig medelväg där så är lämpligt.
Och så kommer vi till den ganska förbryllande slutsatsen: Det behöver inte alltid vara Agile vs. Vattenfallsmetod. De två metoderna kan också komplettera varandra. Båda har sitt berättigande. 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 ett okänt begrepp. De frågar sig med rätta: Skulle jag hellre göra projektet agilt eller enligt vattenfallsprincipen? Hur börjar jag med agila metoder? Ett "agilt" svar på detta skulle vara: Börja experimentera. Testa olika saker iterativt.
Klassiskt introduceras agila metoder på två sätt som också är idealiska för "nybörjare": Kanban och retrospektiv.
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 du 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.
https://www.pinuts.de/blog/webstrategie/projektmanagement-wasserfall-gegen-scrum
