Lean Software

Lean har sitt ursprung från Toyotas tillverkningsindustri. Både Lean (produktion) och Toyota Production System (TPS) är båda koncept med samma ursprung. Det finns en otydlighet och överlapp mellan olika koncept som Lean, Agile och Toyota Production System (TPS) och The Toyota Way.

En annan komplexitet är att Lean är dåligt definierat och beskrivs i olika publikationer på skilda sätt såsom – priciper, förbättringssätt, kvalitetsystem, metod och verktyg.

Övergripande värderingen i lean är ”fokus på kunden”. Detta realiseras av ett antal viktiga principer som (där det för varje princip finns ett antal tekniker):

Just in Time (JIT) med fokus på att öka flödet
Göra rätt saker, dvs efterstäva värdeskapande och eliminera slöseri (waste)
Samarbete och respekt mellan/för medarbetare

Lean SW är en anpassning av Lean till programvara. Mycket av tankegångarna är samma men det finns skillnader då produktion och utveckling skiljer sig. Inom produktion är processen stabil (återkommande uppgifter, låg varians och flödet är kontinuerligt) medans verkligheten är mer instabil inom utveckling.

Vad är det bra till?

Lean SW ger ett flertal fördelar:

Ökat flöde – genom att fokusera på ”JIT” med korta köer, små batchar, och ett pull system med begränsningar på mängden parallelt arbete (WIP)
Kostnadsbesparing – med syftet att göra rätt saker kommer slöseriet att minska vilket leder till kostnadsbesparingar
Ökad produktivitet – det ökade flödet och eliminering av slöseri leder till att man gör rätt saker i rätt tid som resulterar i ökad produktivitet
Nöjdhet/delaktighet – en hörnpelare i Lean är vesäntligheten av att jobba tillsammans och respketera varandras åsikter vilket bidrar till gemensamt åtagande och en personal som är mer delaktig och nöjd

Utmaningar

Det finns en mängd olika utmaningar när man arbetar med Lean SW:

Helhestyn. För att kunna arbeta iterativt och färdigställa delmängder av en produkt så krävs försåelse för produkten helhet och hur de ingående delarna hänger ihop
Uppdelning av produkt. För att lyckas väl med Lean SW krävs att man kan bryta upp produkten i mindre delar för att kunna realisera små batcher och pull-system vilket kräver en genomtänkt arkitektur.
Bred kompetens. Att minska mängden parallelt arbete är centralt vilket kräver ett större överlapp av kompetens, både i avseende på produkt (ex klient-server) och discipliner (ex krav, utveckling och test)
Vissa delar går mot gängse förtåelse. Några principer i Lean går stick i stäv mot gällande praxis. Enligt Lean skall vi inte överbelasta kapaciteten för då ökar risken för försening vid varians. Fokus i Lean är på att produkten ”jobbar” medans i många av dagens utvecklingsorganisationer är fokus på att hålla personalen fullt sysselsatt.
Förändringsproblematik. Som vid alla organisations och processförändringar finns det en mängd utmaningar och potentiella problem. En speciell utmaning med Lean är att den till dels kräver att större del av organisationen blir inblandad.

Vad är det?

Det finns ett antal källor som aspirerar på att definiera Lean SW, vi är främst inspirerade av Popendick som gjort en översättning från generell Lean till hur det bör apliceras inom mot programvara och Reinertsen som fokuserar på JIT i Lean med detaljerar principer inspirerade som hämtar teorier från andra industrier än bilindustrin.

LEAN SW (Poppendick):

I boken ”Lean Software Development” översättes de traditionella Lean principerna:

Eliminera “waste” – Allt som inte adderar till kudvärde ses som slöseri och skall minimeras. I ett SW-perspektiv översättes det till: delvis utfört arbete, extra funktioner, omlärning, överlämnande, byte av uppgift, förseningar och buggar. Första steget i denna minimering är identifiering, som ex. Kan göras genom en värdeströmsanalys.
Förstärk lärande – Varje utveckling av SW innebär nytt lärande vilket bör adresseras genom att jobba tätt med kunden där man förenklar processen med användarkrav. Isället bör man komma igång och i korta iterationer utveckla och testa tidigt så att all partner kan få snabb återkoppling.
Besluta så sent som möjligt – Vid utveckling av SW finns alltid osäkerheter och behov av ändringar. Detta kan hanteras genom vänta med osäkra beslut till senare iterationer medans man arbetar med klargjorda områden medans man utreder/förbereder olika förlag kring de områden där man väntat med beslut.
Leverera så fort som möjligt – Kundnytta får man inte förren något kommit kunden till godo. Genom att dela upp systemet och leverera olika funtioner i taget prioriterat efter vad kunden vill ha åstakommer vi denna nytta i steg (JIT). Dessutom ju snabbare destå mer feedback och lärande.
Respektera teamet - Beslut skall fattas där man har rätt information. Organisationen skall ge stöd för att eliminera de flödeshinder som teamen indentifierar och inte kan adressera själva. Detta leder även till större åtagnade och delaktighet hos teammedlemmarna.
Bygg in kvaliteten - Kvalitet är svårt att realisera i få loopar. Utan förstålese byggs upp via flera iterationer med direkt kontakt mellan kund och leverantör. Korta iterationer ställer krav på automatiserade regressionstester. Andra kvalitetsprinciper är att fel skall rättas direkt och att omstrukturering av kod skall ske kontinuerligt.
Se till helheten – För att kunna jobbamed små delar av en produkt så krävs försåelse för produkten syfte, helhet och hur de ingående delarna hänger ihop. Det gäller även arbetssättet, för att kunna identifiera slöseri och öka hastig-heten gäller det att förstå syftet och hur de olika utvecklingsmomenten hänger ihop.

2nd Generation Lean Product Development (Reinertsen )

Reinertsen konstaterade att en hel del av principeran kring flödes optimering från Lean (produktion) inte var tillämpliga inom designarbete då det där är mer insabila processer med mindre repitition, mer variationer och inte lika kontinuerligt flöde. Reinertsen fann då lösningar från helt andra domäner som köteori, trafikhantering, telekommunikation, operativsystem och internet.

Reinertsen definierar i sina publikationer (bla i Managing the design factory och The Principles of Product Development Flow) viktiga områden att bemästra för att uppnå effektivt flöde som levererar affärsvärde:

Beslutramverk för att styra med data. För att kunna jämföra olika aspekter som försening, funktions neddragning och resursökning behöver dessa dimesioner översättas i monetära termer. Sedan kan man ex. Avgöra om en månads försening är ”bättre” än en att dra ner på två features.
Ta vara på variation. Inom produktion är variation något som skall elimineras. Men när det gäller design processer så vill man ha innovation vilket medför variation. Viktigt är dock att styra variationen. När vill vi ha variation, ofta tidigt i processen, och i vilken form (resurser, tid, funktionsmängd)?
Korta köer. Köer uppstår vid för hög resursutnyttjning och variation. De medför bla längre cykletid, ökad risk, lägre kvalitet och lägre motivation. Ändå är köer sällan i fokus i dagens utveckling. Det finns ett antal tekniker för att begränsa köer: begränsa pågående arbete, begränsa resursutnyttjninge, mer tvär-kompetenta resurser och korta iterationer
Korta iterationer. Genom att bryta upp utvecklingen i mindre steg möjlighet att realisera kundvärde och ökar lärandet. Korta iterationer är också nycklen till att hålla köerna korta.Den motverkande kraften är vilken transaktionskostnad som finns? Till exempel inom ASIC utveckling är kostnaden för att bränna en krets dyr och skall hellst ske bara en gång.
Begränsningar på pågående arbete. Mängden av pågående arbete (Work In Progress WIP) påverkar risken för varians och effekten när den inträffar. Genom att styra WIP genom att sätta gränser för mängden pågående arbete i systemet /delsystem kan man kontrollera både köer och cykeltid. WIP kan åskådliggörs påvisuella kontroll tavlor (ex: kanban).
Styr genom takt och synkronisering. För att stärka flödet är det viktigt att planera takten och synkronisering. Takt skyddar varians från att påverka närliggande steg och ger predikterbarhet. Synkronisering, i vilken ordning uppgifter skallgöras, kan påverka köer utan att ändra kapacitet eller iterationslängd!

Var kommer det ifrån?

Lean SW har sitt ursprung från Toyotas tillverkningsindustri. Både Lean (produktion) och Toyota Production Systsem (TPS) är båda koncept med samma ursprung. Taiichi Ohno, fadern till TPS, inledde sitt arbete med TPS 1932 och förfinade detta i 60 år. 1978 publicerades boken Toyota Production System – beyond large scale production. Först 1988 kom begreppet kring Lean, i en artikel av john Krafcik ”Triumph of the Lean Production System”. Men först 1990 med boken ”The machine that Changed the World” (Womack, Jones & Roos) tar det riktig fart. Idag har Lean annamats inom många områden, som Lean IT, Lean Education, och då även Lean SW development.

Vår erfarenhet

Addalot har arbetat mycket med de olika Lean SW metoderna och med att integrera hela eller delar i organisationers samtliga processer i arbete med att förbättra, förenkla och effektivisera deras arbetssätt. Vi är väldigt positiva till Lean SW i ett förbättringsperspektiv, då bidrar Lean SW med sitt fokus på helhetssyn och verksamhetsnytta.

Läs mera

Du kan läsa mer om Lean på Wikipedia och sedan följa wikipediasidornas referenser vidare för djupare beskrivningar.

Följande böcker kan vi också rekommendera: