Lean slog först igenom inom produktutveckling i den japanska bilindustrin. Den agila rörelsen inom systemutveckling med metoder som Scrum och XP lånade sina grundprinciper från Lean-filosofin. Några exempel på agila principer från Lean är kundfokus, snabba leveranser och öppenhet för sena ändringar. Med ett tankesätt hämtat från Lean kan både beställare och leverantörer av IT-system tillämpa liknande värderingar på kundvärde och ständig förbättring. Centralt i Lean-filosofin är kundvärde. Målet är att varje aktivitet av varje medarbetare ska vara kopplad till kundvärde. Allt annat är slöseri och kan tas bort.
Det talas allt oftare i Sverige om Lean och Lean IT. När principerna från Lean produktion appliceras på systemutveckling är det praxis att sju grundprinciper gäller. Några av principerna på engelska saknar motsvarande svenska begrepp med samma betydelse. Därför har jag valt att använda mig av de engelska benämningarna i artikeln:
- Eliminate waste
- Deliver fast
- Defer commitment
- Create knowledge
- Respect people
- Build in quality
- Optimize the whole
Artikeln är tänkt som den första i en serie artiklar om Lean. Den är en introduktion till de första tre principerna ovan med reflektioner kring vad det kan innebära för kravhantering och test.
Eliminate waste
Inom systemutveckling är överflödiga programfunktioner kanske den värsta formen av slöseri. Som exempel på slöseri jobbade jag själv med implementering av ett beställningssystem för en kund i Sverige. Standardsystemet innehöll en telesäljmodul med en funktion för ringlistor som ursprungligen var byggd för en kund i USA. Den svenska kunden hade aldrig jobbat med ringlistor. Därför gick mycket projekttid åt för förståelse av funktionen och kravställning kring kundspecifika anpassningar. Efter flera omgångar med reviderade krav, implementering, test och rättningar var modulen färdig. Men kunden arbetade på ett sätt som inte krävde ringlistor, så ringlistor användes aldrig i produktion. Nästa projekt hade som mål att ta bort allt som var onödigt i systemet, inklusive ringlistor. Funktionen ringlistor var ”slöseri”. Den gav noll värde för kunden men medförde stor kostnad i form av utbildning, kravställning, test och rättning. Tid som skulle ha lagts på något värdefullt till kunden istället.
Om de två huvudsyftena med test är att 1) verifiera för att hitta fel och 2) validera att kunden får nytta av systemet, kan vi dra följande slutsats när vi tänker Lean:
Validering är mycket viktigare än verifiering.
Visst måste vi ändå verifiera för att hitta fel, men om det inte finns något direkt värde till kunden är all nedlagd tid bara slöseri. Därför ska prioritering i vårt krav- och testarbete lägga störst vikt vid kundvärde!
Deliver fast
Det är ifrån Lean-principen ”Deliver fast” som den agila revolutionen har sina rötter. Korta iterationer är idag inget nytt inom systemutveckling eftersom Sverige till stor del tagit till sig metoder som Scrum och XP. Nu börjar agila metoder kallas för Lean och cirkeln är sluten. Det handlar inte bara om att byta ut ett buzzword mot ett annat. Det handlar också om ett fundamentalt tankeskifte. Agila systemutvecklingsmetoder tilltalar framförallt systemutvecklare även om beställaren och kunden står i centrum. Det är lätt att bara tänka på utvecklare när vi hör ordet Scrum. Lean beskriver samma grundprinciper med ett språk som tilltalar även beställare och kunder. Figurerna nedan jämför iterationer ur ett agilt perspektiv och ur ett Lean-perspektiv.
När vi illustrerar iterationer enligt Lean får vi begrepp som är mindre utvecklingsfokuserade och mer kundfokuserade. Som exempel har vi nu begreppet ”feedback ” istället för ”test”. Test är en utvecklingsaktivitet vars syfte är feedback. Ännu viktigare är användning av begreppet ”förbättring” istället för ”rättning”. När vi jobbar sekventiellt med tron att vi har allt rätt i krav från början, då handlar test om att hitta fel och se till att de blir rättade. När vi jobbar iterativt är huvudsyftet att leverera mervärde till kunden genom lärdomar och insikter från feedback.
Defer commitment
Enligt Lean-principen ”Defer commitment” ska man fatta beslut som innebär åtagande så sent som möjligt. Det kallas också för ”Just in time commitment”. Genom att senarelägga ”frysning” av krav tills vi har provat och utvärderat olika alternativ kan vi fatta bra beslut, baserade på fakta och feedback istället för på spekulation. Att tänka Lean innebär ett paradigmskifte i vårt kravarbete. Vi har lärt oss att ju senare vi inför en ändring, desto dyrare blir systemutveckling. Men utan feedback är vi begränsade till spekulation istället för fakta i kravarbetet. Det är inte konstigt att beslut baserade på spekulation ofta visar sig vara fel i längden. Med andra ord är tidiga (fel) beslut mycket dyrare än sena (bra) beslut byggda på feedback. Därför ska vi senarelägga vissa beslut även om det kan innebära en viss kostnad att införa en ändring senare. Det vi tjänar i ökat kundvärde när vi fattar rätt kravbeslut motiverar risken för ökade kostnader i samband med senare ändringar.
I 1987 drog Barry Boehm slutsatsen att kostnaden för en ändring i produktion är 100 gånger kostnaden för samma ändring i tidiga krav- och designaktiviteter. Men Boehm själv noterade redan 2001 att slutsatsen delvis beror på att man jobbar sekventiellt med tidiga beslut. Med arbetssätt enligt Lean konstater Boehm att kostnaden för ändringar i produktion minskas till så lite som fem gånger kostnaden för samma ändring i krav- och designaktiviteter.
Den optimala kurvan enligt principen ”Defer commitment” är den till ovan till höger. I verkligheten landar vi ofta någonstans emellan kurvorna. Du kan närma dig kurvan till höger till exempel genom att använda prototyper och användningstester. Genom prototyper kan man snabbt ta fram konkreta och visuella lösningar som fungerar bra som underlag för dialog. Om prototyper tillämpas med rätt styrning kommer dialogen att ge värdefull feedback som i sin tur kommer att leda till en bättre lösning. Med användningstester (också ”användbarhetstester” eller ”kundtester”) är syftet att få validering av slutanvändare så tidigt som möjligt. Metoden leder nästan alltid till tidig feedback samt förbättrade lösningar precis som prototyper. Användningstester tillsammans med prototyper ger ännu bättre effekt. Tänk test tidigt!
Summering
Genom tillämpning av de principer som Lean systemutveckling består av, strävar vi efter ständig förbättring för att leverera mer kundvärde med mindre slöseri.
Källor
- “Implementing Lean Software Development”: From Concept to Cash” av Mary Poppendieck och Tom Poppendieck, 2007.
- ”Lean Software Development: An Agile Toolkit” av Mary Poppendieck och Tom Poppendieck, 2003.
- Agile Manifesto agilemanifesto.org
På något sätt gillar jag uttrycket ”förbättring” istället för ”rättning”. Det är ju så jag ser på min roll att förbättra upplevelsen för kunden, se till att kunden får det han/hon vill ha. Dock så kan jag tänka mig att det i börja kan kännas lite tandlöst att inför projketägare m.m. säga att ”vi blir 2 veckor sena, vi har några förbättringar vi måste hinna med”. Det känns helt klart mera kraftfullt att säga att ”vi blir 2 veckor sena, vi har några kritiska rättningar vi måste hinna med”.
Jag håller med om att “rättningar” är kraftigare än “förbättringar” som begrepp i sammanhanget förseningar. Min framtidsvision är att vi når en testmognad som innebär att förseningar inte beror på felrättningar i samma utsträckning som de gör idag. Med testdriven utveckling ska vi upptäcka felen tidigare för att därefter lägga fokus på nytta och förbättringar. Lika bra att fokus på nytta och förbättringar drivs av de som kallar sig för testare och testledare idag.