Metoder för mjukvaruutveckling: Lean vs Agile Principles

”Lean” och ”Agile” är termer som har använts mycket på senare tid, ofta med hänvisning till metoder för mjukvaruutveckling, projektledning eller organisatoriska stilar.

Men undrar du någonsin:

Vad är Lean? Vad är Agile? Finns det någon skillnad?

Merriam-Webster Dictionary definierar agil som ”att ha en snabb, uppfinningsrik och anpassningsbar karaktär, eller kännetecknas av att vara beredd att röra sig med snabb och enkel elegans”.

Lean definieras helt enkelt som ”smal och hälsosam, eller som innehåller lite eller inget fett”.

Med utgångspunkt i dessa definitioner kan vi anta att en person som är lean och en person som är agil kan ha många gemensamma egenskaper. Samma sak gäller i samband med mjukvaruutveckling.

Vad är agilt? Vad är lean?

Agile är nu allmänt känt i teknikvärlden som en uppsättning värderingar och principer för att vägleda utvecklingen av programvara. I ”The Agile Manifesto” fastställs fyra värden och tolv principer. Agile är exakt vad du tror att det kan vara. Det är agilt. Metodiken gynnar flexibilitet, kommunikation, samarbete och enkelhet.

Lean är mindre känt och saknar en tydlig definition som stöds av ett professionellt samförstånd.Termen ”Lean” myntades ursprungligen för att beskriva en modell för tillverkningsorganisation som bygger på Toyotas produktionssystem, men anses vanligen vara ett delramverk inom Agile-paraplyet för mjukvaruutveckling.

I dag råder det stor förvirring om vad som är Lean, vad som är Agile, om de är en och samma sak och vilken som bör användas.

Födelsen av nya metoder för mjukvaruutveckling

Både Lean och Agile utvecklades som ett svar på bristerna i befintliga planstyrda metoder som Waterfall. Utvecklare och chefer inom programvaruteknik som använts sedan 1970-talet började märka ineffektiviteten hos Waterfall på 90-talet. Med mer dynamiska marknader och tekniskt kunniga konsumenter kunde Waterfall inte reagera tillräckligt snabbt på marknadens krav, förändrad teknik eller leverera felfri programvara på ett konsekvent sätt.

I jakten på en bättre modell försökte skaparna av Lean och Agile att utveckla metoder med ett mer kundfokuserat tillvägagångssätt. De nya metoderna tog till sig förmågan att anpassa sig som en konkurrensfördel, gynnade tidig och kontinuerlig testning och tog med sig ett mänskligt inslag i projektledning och genomförande.

Lean vs. Agile-principer

Lean Software Development (LSD) föreslogs först av dr. Robert Charette som ett sätt att bygga upp förändringstoleranta organisationer som blev alltmer beroende av mjukvara.

Nästan kom ”The Agile Manifesto” där de 12 principerna för agil mjukvaruutveckling förankrades.

Det andra auktoritativa arbetet om metoder för mjukvaruutveckling tillskrivs Mary och Tom Poppendieck, som publicerade Lean Software Development: Här finns en jämförelse sida vid sida av värderingar och principer för var och en av dem:

Om man jämför de 12 principerna i Dr. Charettes LSD och de 12 principerna för Agile, kan man se att de är slående lika varandra. De sju Lean-principer som Poppendiecks föreslår är mindre målinriktade, men överlappar ändå ”The Agile Manifesto” och Charettes Lean Software Development.

Här är fler element som de alla har gemensamt:

• Värdet av att reagera snabbt på kundernas behov
• Testning i ett tidigt skede
• Ett iterativt tillvägagångssätt för utveckling
• MVP-stil (Minimum Viable Product) i stället för funktionstunga
• Samarbete både inom företaget och med externa intressenter

Tidslinje

Vi har undersökt de vattendelare och publikationer som gav upphov till dessa terminologier för att se hur de blev populära. Kolla in vår tidslinje nedan som beskriver utvecklingen, och lägg till dessa till din läslista om du är så benägen!

Ursprunget till Lean och Agile

Som du kan se på tidslinjen användes begreppet Lean för första gången av Womack et. al. 1990 för att beskriva Toyotas produktionssystem i deras bok The Machine That Changed The World. Dr Robert Charette anpassade senare de Lean-idéer som beskrevs i tidigare publikationer för att skapa sin ”Lean Software Development”.

Tecknet Agile var inte allmänt använt förrän publiceringen av ”The Agile Manifesto” 2001. Termerna Agile och Lean myntades båda av västerländska tekniker eller akademiker som hänvisade till Toyotas produktionssystem (mer om detta senare).

Vi kanske får en del kritik för att vi säger detta, men med detta i åtanke är termerna Lean och Agile faktiskt inte så viktiga. Att ha två termer som härstammar från samma principer bidrar faktiskt till förvirring i ämnet. Med detta sagt är detta den terminologi som branschen har antagit, så framöver kommer vi att fortsätta att använda dem.

Tidslinjen är också en annan källa till förvirring. Dr Robert Charette introducerade sina idéer om Lean Software Development i början och mitten av 1990-talet. Det taktiska syftet och de tolv principerna för hans metod för Lean Development beskrevs 1998 i en artikel med titeln ”Lean Development”, nästan tre år före ”The Agile Manifesto”. Som ett bevis på överlappningen mellan Lean och Agile skrevs artikeln av Jim Highsmith, som senare blev en av grundarna av den agila rörelsen. Highsmiths artikel fick dock inte stor spridning, och det var inte förrän 2003 som Charette själv skrev en mer djupgående förklaring bakom sin Lean Development-strategi i forskningsrapporten ”Challenging the Fundamental Notions of Software Development”.

I en mejlväxling med dr. Charette var han snabb med att påpeka att hans uppfattning om Lean Development var avsedd för den organisatoriska nivån inom mjukvaruområdet:

Mine föddes ur ett strategiskt såväl som operativt behov av att förbättra IT:s affärsmässiga/uppdragsmässiga värde för organisationen, och jag närmade mig detta från ett riskhanteringsperspektiv.
-Dr Robert N. Charette

Detta skiljer sig något från Agile, som först föreslogs strikt som ett ”bättre sätt att utveckla mjukvara”, men som nu tillämpas på olika projekt och förvaltningsmetoder.

2003 var också året då Poppendiecks publicerade Lean Software Development: An Agile Toolkit. I boken beskrevs sju principer för Lean Development, som korrelerar direkt med de sju formerna av slöseri i Lean Manufacturing.

Poppendiecks bok gav samtidigt stöd åt Lean som metod för mjukvaruutveckling och suddade ut skillnaden mellan Lean och Agile, genom att föreslå Lean som en kompletterande metod inom Agile. I själva verket såldes boken vid publiceringstillfället som den senaste publikationen inom The Agile Software Development Series.

I dag anses Poppendiecks flera arbeten i ämnet vara nödvändig läsning för Lean- och ”aspirerande-Lean”-programvaruutvecklare.

Divergens i tillämpningen

En av de viktigaste skillnaderna mellan Lean och Agile är, enligt Dr Charette, att Agile är nedifrån och upp medan Lean är uppifrån och ner. Detta är tydligt i Leans end-to-end-struktur (E2E) och i den princip om att se helheten som Poppendiecks föreslog. Nedan förklarar vi dessa principer i praktiken i värdeflödeskartläggningen.

Värdeflödeskartläggning

För att förverkliga principen See the Whole beskriver Poppendiecks i detalj en metod för värdeflödeskartläggning för att avslöja de värdeskapande aktiviteterna jämfört med de icke värdeskapande aktiviteterna genom hela utvecklingsprocessen från början till slut.

Värdeflödeskartläggningen analyserar utvecklingscykeln från den tidpunkt då ett krav tas emot till den tidpunkt då det levereras till kunden. Målet är att identifiera slöseri i form av lagerhållning och väntan (förseningar i produktionen) och utforska nya metoder för att minska pågående arbete och ledtider.

Enligt Poppendiecks är kartläggning av värdeflödet en enkel övning som bara kräver en penna och ett papper. Processen är följande:

1. Kartlägg ditt nuvarande värdeflöde (börja med ett krav och en tidslinje med åtgärder på vägen till leverans)
2. Analysera den största orsaken till slöseri (Vad håller upp Work-in-Progress?)
3. Utveckla en plan för att halvera detta slöseri
4. Skapa en framtida värdeflödeskarta

Det agila paradigmet enligt ”The Agile Manifesto” gynnar korta iterationscykler och frekventa leveranser framför en holistisk helhetsbild från början till slut. E2E-fokus är därför unikt för Lean. Det är faktiskt på grund av E2E-konstruktionen som Lean (snarare än Agile) oftare tillämpas som organisationsstruktur och ledningsstil.

Den genomgående synen kräver att hela organisationen deltar för att eliminera slöseri. Detta är ett eko av Dr Charettes uttalade syfte med sitt ursprungliga Lean Development-koncept:

Lean Development är en filosofi, ett sätt att se och tänka på IT och dess förhållande till en organisation, lika mycket som det är en utvecklingsmetod.

Lean Kanban Vs. Agile Kanban

Både Lean och Agile har antagit TPS Kanban-system med små variationer. Toyotas Kanban-system utformades för att begränsa pågående arbete.

I motsats till traditionell ”push-tillverkning”, där lagret skjuts till nästa steg i processen, drar Kanban bara in nytt material i produktionen när det aktuella stycket har bearbetats och komponenterna behöver fyllas på.

Kanban-kort blir till återförrådsbeställningar och skickas tillbaka till det föregående steget i produktionen. Detta resulterar i att det pågående arbetet minimeras och att det outnyttjade lagret minskar.

I programvaruutveckling används en Kanban-tavla i stället för att skicka Kanban-kort från ett tillverkningssteg tillbaka till det föregående steget. Klisterlappar används, oftast för att representera pågående krav.

Enligt det kapitel som Kai Petersen har bidragit med i Modern Software Engineering Concepts and Practices: Till skillnad från Agile, som använder iterationscykler med fast varaktighet för att begränsa utvecklingstiden och som styr Kanban-brädan, begränsar Lean antalet uppgifter som tillåts vid varje given tidpunkt. Detta gör det möjligt för Lean att uppfylla sitt primära mål att begränsa WIP, samtidigt som man mer exakt mäter ledtiden och identifierar slöseri i produktionen. När en uppgift är slutförd kan en ny tas fram från den prioriterade listan. Medan Lean använder begreppet kontinuerligt flöde börjar Agile varje ny iteration med ett nytt bräde.

Vissa team inser fördelarna med båda tillvägagångssätten och börjar använda en hybridmetod som kallas scrumban.

Detta är bara två av de subtila skillnaderna i tillvägagångssättet som Lean och Agile tar för att uppnå gemensamma mål. En annan artikel publicerad på Codementor utforskar fler användningsområden och tillämpningar av Lean och Agile.

I praktiken är det oviktigt om ditt team använder sig av en så kallad ”Agile”-metod eller en ”Lean”-metod. Det viktiga är att hitta rätt metoder för att optimera dina arbetsflöden och konsekvent leverera värde till dina kunder, vilket båda metoderna ser som det yttersta syftet.

TPS-kopplingen

Så vad har allt detta att göra med Toyota Production System? I stort sett allt. Skaparna av både Agile och Lean var starkt påverkade av TPS, vilket Womack et. al. beskriver i The Machine That Changed the World. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. Företaget kunde inte hoppas på att följa en Detroitmodell med massproduktion och överleva.

Under dessa förhållanden satte Taiichi Ohno och Kiichiro Toyoda upp ett mål att förbli lönsamma genom att eliminera slöseri i produktionen, förkorta ledtiderna och bara tillverka det som kunderna behövde, även känt som Just-in-Time (JIT)-tillverkning.

För att eliminera slöseri beslöt sig Ohno för att bara tillverka det som behövdes, när det behövdes, och bara i den mängd som det behövdes.

Den iterativa processen inom Lean och Agile som fokuserar på att minimera utvecklingen av funktioner och maximera leveransen av uppdateringar speglar direkt Toyotas Just-in-Time-tillverkning.

Jidoka

Jidoka (自働化) kan översättas som automatisering med mänsklig prägel, ibland kallad ”intelligent automation”. Jidoka spelar en viktig roll för att eliminera slöseri i produktionen genom att göra maskinerna mer självständiga, vilket frigör människor till en mer aktiv roll i produktionen och frigör mänsklig kreativitet.

Jidoka bygger på intelligenta maskiner som stannar automatiskt när det finns en oegentlighet. Mänskliga arbetare kan då gå in och åtgärda problemet, vilket förhindrar att defekter förs vidare i produktionsprocessen.

Jidoka ger också varje anställd möjlighet att stoppa produktionslinjen när ett problem upptäcks. Principen omfattar en process i fyra steg för att eliminera slöseri med defekta produkter:

1. Detektera avvikelsen
2. Stoppa produktionen
3. Fixa eller korrigera det omedelbara tillståndet
4. Undersöka grundorsaken och åtgärda situationen

Det går att se Jidoka-konceptet i Lean- och Agile-fokuseringen på tidiga och frekventa testningar för att utrota buggar, och betoning på konsultationer med kunderna för att identifiera användarnas smärtor.

Spill av TPS i en mjukvaruutvecklingskontext

För att uppnå JIT-tillverkning beskrev Taiichi Ohno sju former av slöseri som måste elimineras. Nummer åtta lades till senare. Om man tittar närmare på Agile och Leans värderingar, mål och principer kan man se att de är utformade för att skydda sig mot TPS:s åtta slöserier. I boken Lean Software Development från 2003: An Agile Toolkit, presenterade Poppendiecks TPS-avfallet i ett programvaruutvecklingssammanhang:

1. Överproduktionens slöseri. Överproduktionens slöseri är en av de största orsakerna till att vattenfallsmetoden har övergivits. Överproduktion anses vara extra kodning för funktioner som inte efterfrågades och som kunden kanske inte vill ha.

Detta återspeglas i följande principer:

Agile ⟶ enkelhet
Charettes Lean⟶ minimalism
Poppendiecks Lean ⟶ eliminera slöseri

2. Slöseriet med att vänta. I JIT-tillverkning är det slöseri att vänta på en ledig maskin eller arbetare. Inom programvaruutveckling är det slöseri att vänta på ett team med överkapacitet. Om det uppstår fördröjningar i produktionen som gör att ett team måste stå i beredskap, eller gör att kunden måste vänta på leverans, finns det slöseri.

Matchningsprinciperna är följande:

Agile ⟶ frekventa cykler
Charettes Lean ⟶ ⅓ av tiden (mål för LSD), 80 % lösning i dag
Poppendiecks Lean⟶ leverera så fort som möjligt

3. Slöseriet med transporter. Inom mjukvaruutveckling översätts transport med ”byte av uppgift”. För många överlämningar eller anställda som tilldelas flera team med krav på överdriven multitasking är ineffektivt och ett slöseri.

Matchande principer:

Agile ⟶ samverkan mellan intressenter, självorganiserande team, kultur av
förtroende, stöd och motivation
Charettes Lean ⟶ laginsatser
Poppendiecks Lean ⟶ ge teamet inflytande

4. Slöseriet med överbearbetning. Detta är helt enkelt extra processer som egentligen inte behövs för att leverera värde till kunden. Det främsta exemplet är dokumentation. Överdriven dokumentation för oflexibla processer kommer inte att vara värdefull, inte heller överdrivet detaljerade användarmanualer som skulle kunna sammanfattas på en sida eller två. Dokumentation är tidskrävande men ger ett begränsat värde för slutanvändaren.

Matchande principer:

Agile ⟶ enkelhet, fungerande programvara som mått
Charettes Lean ⟶ minimalism
Poppendiecks Lean ⟶ eliminera slöseri

5. Slöseri med lagerhållning. Inventarieavfall är pågående arbete för vilket en investering har gjorts, men som inte har något värde förrän det är färdigställt. Med andra ord ger ofullständig programvara inget värde för användaren. Lean och Agile värdesätter snabba och frekventa leveranser, med betoning på frekventa iterativa cykler och leverans av fungerande mjukvara.

Matchande principer:

Agile ⟶ kundtillfredsställelse (genom tidiga och frekventa kund
leveranser)
Charettes Lean ⟶ 80 % lösning i dag
Poppendiecks Lean ⟶ leverera så fort som möjligt

6. Slöseriet med förflyttning. Waste of movement är överskottsarbete som krävs för att få information eller besvara frågor. Detta är vanligt när team inte är samlokaliserade, om uppgifter avslutas och resultaten inte omedelbart görs tillgängliga för alla relevanta parter, eller när intressenter inte är lättillgängliga för konsultation.

Matchande principer:

Agile ⟶ samverkan mellan intressenter, kommunikation ansikte mot ansikte
Charettes Lean ⟶ kundmedverkan, teamarbete
Poppendiecks Lean ⟶ eliminera slöseri

7. Spill av defekter. Precis som i tillverkningsindustrin utgör produktion av defekt eller buggig programvara en bortkastad investering för företaget. Ju snabbare en defekt upptäcks, desto större är sannolikheten att slöseriet minskas. Många agila och Lean-principer syftar till att stoppa slöseriet med defekter. För att minska defekter lägger alla tre metoderna stor vikt vid tidig och frekvent testning.

Matchande principer:

Agile ⟶ teknisk excellens, fungerande mjukvara som mått
Charettes Lean ⟶ kundtillfredsställelse
Poppendiecks Lean⟶ förstärker lärandet

8. Slöseriet med outnyttjad medarbetarkreativitet. Inom mjukvaruutveckling beror oanvänd kreativitet på en rigid färdplan och brist på mänskligt samarbete. Precis som Jidoka (自働化) strävar Agile och Lean efter att maximera mänskligt samarbete och innovation för att få ut bästa möjliga resultat av tekniken.

Matchande principer:

Agile ⟶ samarbete mellan intressenter, reflektion i teamet
Charettes Lean ⟶ ”oskriven” 13:e princip om tillfredsställelse genom
arbete
Poppendiecks Lean ⟶ förstärka inlärning

TPS-värden i mjukvaruutvecklingsmetoder

Flera av de kärnvärden som ingår i TPS återspeglas också i Agile och Lean mjukvaruutvecklingsmetoderna.

Kaizen (改善) kan översättas med kontinuerlig förbättring. Med flexibla, iterativa, kundfokuserade modeller är kontinuerlig förbättring kanske det viktigaste värdet i agila och lean metoder för mjukvaruutveckling.

Hansei (反省) betyder självreflektion. Som ett sätt att förbättra effektiviteten antar Agile Manifesto direkt teamets självreflektion som sin tolfte princip. När Charette introducerar sin Lean Development-modell utmanar han läsarna att reflektera över alla nuvarande antaganden som dikterar de processer de använder som ett första steg för att hitta bättre processer. Poppendiecks princip om att förstärka lärandet kan också betraktas som Hansei.

Respekten för människor (尊重) är central i alla tre paradigmerna. Det första värdet i ”The Agile Manifesto” är att ”värdera individer och interaktioner framför processer och verktyg”.

Respekten för människor förekommer också i Dr. Charettes påstående om vikten av att individer upplever tillfredsställelse genom arbetet, och Poppendiecks Lean-princip om att ge grupper inflytande. Detta värde erkänner att när individer är delaktiga i beslutsfattandet och förbättrar sin arbetsmiljö blir de mer innovativa och effektiva arbetare.

Seiri (整理) är principen som speglar slöseri. Seiri dikterar att det som är onödigt ska tas bort. Detta omfattar alla de ursprungliga sju slöserierna i TPS, för vilka vi redan har identifierat det parallella slöseriet i mjukvaruutvecklingsmiljön.

Gengchi Genbutsu (現地現物) kan bokstavligen översättas till ”faktisk plats, faktisk sak”. I praktiken betyder detta ”inspektera för att förstå”. När det finns ett problem i produktionsprocessen bör chefen gå till källan för att förstå problemet och bestämma hur det ska lösas.

I mjukvaruutveckling manifesteras detta värde i betoningen på korta iterationscykler, tidig testning och samarbete med kunderna så att mjukvaruingenjörerna kan bygga fungerande mjukvara som användarna faktiskt vill ha.

Slutsats

Som vi nämnde i inledningen av det här inlägget är Lean-metodiken mindre välförstådd och betraktas ofta som en Agile-praktik. Lean är kanske mindre väldefinierad helt enkelt på grund av dess bredare tillämpningar.

Lean har ett mer direkt samband med Toyotas produktionssystem och föreslogs först som en organisatorisk uppsättning metoder och praktiker för företagsledning och tillämpades först senare på programvaruutveckling. Agile, å andra sidan, utvecklades specifikt för mjukvaruutveckling av hängivna yrkesverksamma inom området.

Efter att ha redogjort för den gemensamma bakgrunden och de allmänna principerna för dessa två metoder kan man se att dessa två paradigm har mer gemensamt än de har skillnader.

En av huvudförfattarna till ”The Agile Manifesto”, Martin Fowler, som också har arbetat nära Poppendiecks, har påpekat att Lean och Agile inte utesluter varandra:

Lean och Agile är djupt sammanflätade i mjukvaruvärlden. Man kan egentligen inte tala om att de är alternativ…. man gör inte Agile eller Lean, man gör Agile och Lean.

1. De 12 principerna i Charettes Lean Software Development beskrevs faktiskt för första gången i Jim Highsmiths artikel ”Lean Development” från 1998. Detta utvecklades senare i Charettes egen artikel ”Challenging the Fundamental Notions of Software Development” ︎

.