Vattenfall eller agilt? Vi väljer båda!
Tänk dig att ett bolag köper en genomlysning av hela verksamheten. Allt gås igenom: flöden ses över för att hitta flaskhalsar, systemen granskas, tech stacken och den tekniska skulden kartläggs. Analysen är bra, prioriteringarna är rimliga och alla är överens om planen. Implementeringen läggs upp som ett sammanhållet projekt som ska vara klart till nästa sommar.
Under hösten händer det som brukar hända. En leverantör höjer sina licenspriser, ett nytt krav från en stor kund dyker upp och en avdelning organiseras om. Ingenting dramatiskt, men tillsammans gör det att ordningen i planen inte längre riktigt stämmer.
Ingen har gjort fel, och planen var bra när den gjordes. Men en plan som ska hålla i ett år behöver kunna förändras på vägen. Det är här vattenfallsmetoden ofta får kritik, och där agila metoder brukar lyftas fram som motsatsen. Vår erfarenhet är att man inte behöver välja. Det bästa resultatet får man ofta genom att använda rätt metod i rätt skede.
Vad är vattenfallsmetoden?
Vattenfallsmetoden är ett sätt att driva projekt i fasta steg som följer på varandra. Precis som vatten i ett vattenfall rinner arbetet bara nedåt, aldrig tillbaka upp. Först bestäms kraven, alltså vad som ska göras. Sedan kommer analys och design, där man planerar hur det ska göras. Därefter följer själva genomförandet, test och kontroll, och till sist leverans och förvaltning. Varje steg ska vara helt klart innan nästa börjar. Planen görs i början, och sedan följer man den.
Ett vanligt missförstånd
Här kommer en oväntad detalj. Vattenfallsmodellen brukar spåras till en artikel från 1970 av den amerikanske ingenjören Winston Royce, Managing the Development of Large Software Systems.
Royce ritade mycket riktigt upp stegen i en rak kedja. Men han varnade för att följa dem i ett enda varv. Han kallade det riskabelt, eftersom problem då ofta upptäcks först i slutet, när de är som dyrast att rätta.
Hans egen rekommendation var återkoppling mellan stegen och att involvera kunden löpande. Han föreslog dessutom att man skulle "göra det två gånger": först en mindre, förberedande version för att lära sig var riskerna finns, och först därefter det riktiga genomförandet. Ordet "vattenfall" använde han aldrig; det kom först några år senare.
Royce var alltså inte emot strukturen i sig, utan mot att följa den utan återkoppling. Och hans idé om att först göra en mindre, förberedande insats innan man satsar fullt är samma tanke som ligger bakom en förstudie.
Vad vattenfall betyder för dig som kund
För dig som kund ger vattenfall trygghet. Du vet vad som ska göras, ungefär vad det kostar och när det ska vara klart. Baksidan är att förbättringarna ofta märks först mot slutet, och att det blir dyrare att ändra kurs ju längre in i planen man kommer.
Och agilt, då?
Agila metoder, som Scrum, bygger på motsatt idé. I stället för en stor plan arbetar man i korta omgångar, ofta några veckor i taget. Arbetet samlas i en prioriterad att göra-lista, en så kallad backlog, och efter varje omgång stämmer man av med kunden och prioriterar om vid behov.
Styrkan är flexibiliteten. Svagheten är att helhetsbilden kan bli otydlig, och att det kan vara svårt att veta vad hela resan kommer att kosta. För en kund som står inför stora investeringar, som systembyten, är det en rimlig oro.
Så gör vi: vattenfall först, sedan agilt
Vi tar Royce på orden och kombinerar struktur med återkoppling. Ett uppdrag hos oss har två faser.
Den första fasen är en förstudie som följer vattenfallsprincipen. Vi går steg för steg igenom flöden, system, tech stack, organisation och teknisk skuld. Resultatet är en rapport med en prioriteringslista, från det som är viktigast till det som kan vänta, med lösningsförslag och uppskattade kostnader. Med det underlaget fattar ni beslut om vad som ska genomföras.
I den andra fasen, implementeringen, blir arbetssättet agilt. Prioriteringslistan blir en backlog, och vi genomför arbetet i omgångar. Vi stämmer av med er löpande och prioriterar om när verksamheten förändras, så att förbättringarna märks tidigt och alltid riktas mot det som är viktigast just nu.
En detalj som gör stor skillnad är att designen alltid ligger ett steg före utvecklingen. Det betyder att det hela tiden finns en genomarbetad backlog med uppgifter som redan är planerade och designade. Utvecklingen stannar aldrig i väntan på beslut, och varje förändring hinner tänkas igenom ordentligt innan den byggs.
Det är kombinationen av de två som är poängen. I början behöver du struktur och ett tryggt beslutsunderlag, och när förbättringsarbetet väl är igång behövs flexibiliteten att följa med när verksamheten förändras.
Funderar du på att se över verksamheten, systemen eller den tekniska skulden? Hör av dig, så berättar vi hur en förstudie skulle kunna se ut för just er.
Källa: Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, s. 1–9.
Publicerat av: