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.
Doch was bedeutet Agil vs. Wasserfall überhaupt konkret? Das Wasserfallmodell ist ein lineares Vorgehensmodell, bei welchem das Vorgehen in aufeinander folgende Projektphasen mit konkret definierten Start- und Endpunkten organisiert ist. Grob kann man sich das so vorstellen:
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:
In der Definitionsphase wird zunächst festgelegt, was überhaupt entstehen soll. Beispielsweise der Kunde gibt einen Wunsch an: Er möchte einen Tisch. Man analysiert und definiert dann die Anforderungen und erstellt einen Plan, was alles zu erledigen ist. Im Entwurf erstellt man dann einen Produktentwurf, in unserem Beispiel also eine Skizze des Tischs.
Bei der Implementierungsphase wird das ganze handfester: Wir wählen Material aus, bestimmen die genauen Maßangaben und bauen den Tisch. In der Kontrolle überprüfen wir, ob alles so funktioniert, wie wir es geplant haben: Steht der Tisch? Stimmen die Proportionen? Die Utvärdering erfolgt dann zusammen mit dem Kunden: Wir übergeben das Produkt und erhalten eine Rückmeldung.
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.
Übrigens, ein kurzer Hinweis im Kontext agile Transformation: Willst du sicher gehen, dass ihr aktuell die richtigen Prioritäten in eurer agilen Transformation setzt?
Dann mach unseren Reifegrad-Check für eure agile Transformation - dauert nur 3 Minuten. Du bekommst sogar einen Benchmark auf Basis der über dreihundert anderen Teilnehmer*innen. Siehe Button 🙂
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.
Risikoaversion bezeichnet hier die Tendenz, in Entscheidungssituationen die Möglichkeit zu wählen, welche mit dem wenigsten Risiko - also dem geringsten Verlust - hinsichtlich des Ergebnisses, einhergeht. (vgl. Kahneman & Tversky, 1979)
Agile vs. Wasserfall Methoden fordern von uns diese vermeintliche Sicherheit aufzugeben: Statt auf altbewährte Methoden zurückzugreifen und feste Strukturen und Prinzipien zu verwenden, werden alte Denkmuster der Planungsillusion aufgebrochen und iterative Methoden verwendet. Das führt zunächst zu einer gefühlt gestiegenen Unsicherheit, da man neuartige - scheinbar risikoreiche - Vorgehensweisen anwenden muss, die Unsicherheit als Teil des Plans interpretieren.
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
Die agile Methodologie - wie auch die Wasserfall Methodologie - beinhaltet gewisse Nachteile:
- 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.
Selbstverständlich sind je nach Projekt verschiedene Vorgehensweisen mehr oder weniger geeignet.
Das Wasserfallmodell ist vor allem für Projekte geeignet, die bereits im Vorfeld bekannte und konstante Anforderungen beinhalten.
Agile Methoden sind insbesondere für Projekte optimal, in denen viele unvorhersehbare Faktoren auftreten können und daher flexible Reflektionsschleifen nötig sind. In den meisten technologischen Projekten ist so eine Unsicherheit zwangsläufig gegeben, weshalb gerade hier agile Methoden stark im Aufwind sind.
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?
Bei all dem Hype um “agile” kann man manchmal dazu neigen, agile Methoden als Allheilmittel zu sehen. Zu Unrecht. Das vielleicht verblüffende Ergebnis dieses Textes ist eindeutig.
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 entwickelt man zwar - wie bei der Wasserfall Methodik - einen konkreten, langfristigen Plan mit einzelnen, festgelegten Sequenzen: den Features. Allerdings sind die einzelnen Features sehr kurz, wodurch kurzfristige Reaktionen auf sich wechselnde Anforderungen möglich sind. Das Vorgehen ist zwar nicht so iterativ wie agile Methoden, stellt aber gegebenenfalls einen angemessenen Mittelweg dar.
Und so kommen wir zu dem eher verblüffenden Ergebnis: Es muss nicht immer Agile vs. Wasserfall Methode heißen. Die beiden Methoden können sich durchaus auch gegenseitig ergänzen. Beide haben ihre Berechtigung. Je nach Projekt und Kontext.
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 viele ist “Agilität” noch Neuland. Sie stellen sich zurecht die Frage: Mache ich das Projekt lieber agil oder nach Wasserfall? Wie würde ich denn anfangen mit agilen Methoden? Eine “agile” Antwort hierauf wäre: Startet Experimente. Probiert iterativ unterschiedliche Dinge aus.
Klassicherweise werden agile Methoden über zwei Wege eingeführt, die sich auch hervorragend für “Anfänger” eignen: Kanban und Retrospektiven.
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?
Falls ihr darüber nachdenkt, agile Methoden einzuführen…
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.
