När lean och agilt krockar

Alltså, lean och agilt är ju samma sak. Sätt andra (ofta japanska) namn på elementen i Scrum och du kan utan större problem förklara konceptet för en produktionsspecialist på bilfabriken. Men ändå har jag flera gånger sett hur agila initiativ och leaninitiativ har krockat inne på systemutvecklingsavdelningarna. Jag tänker på framförallt dessa varianter på temat:

Marmeladtårtbakelsegodis

Symptom: Folk hinner inte med sina retrospektiv eftersom de har bråttom till förbättringsmötena. Ledningen sitter och diskuterar hur schemat ska läggas så att inte dagliga scrummötet krockar med tavelmötet.

Orsak: Leangänget på "verksamheten" och agilgänget på "IT" har var och en på sitt håll drömt upp två i och för sig goda tillämpningar av lean/agila arbetssätt. Dessa försöker de nu trycka ut i organisationen.

Rotorsaker: Man förstår inte att man försöker göra samma sak (retrospektivet är ju ett förbättringsmöte), man förstår inte att man måste prata med varandra och ta ansvar för helheten, och man förstår inte att det är vansinne att försöka trycka ut processförbättringar. Har ni hört talas om dragande flöden?

Konsekvens: Eftersom situationen leder till lägre grad av lättrörlighet och ett minskat utflöde av värde, så kommer man att skrota både lean och agilt. Taylorism och projektdisciplin må funka dåligt, men det funkade åtminstone bättre.

Indikation på värre problem: Varken leangänget eller agilgänget har tänkt tanken att det är folket på golvet (gemban, teamet) som ska äga sin processförbättring. Bägge gängen ser som sin uppgift att föreskriva för andra hur de ska arbeta. De håller med om att metodiken är anpassningsbar, men de tror att det är deras uppgift att anpassa den åt andra. En äkta lean/agil-införare ser istället som sin uppgift att lära ut själva anpassningkonsten till samma folk som sen ska leva med metoderna.

Religiösa agilister

Symptom: De tvärfunktionella teamen har planeringsmöten, dagliga möten, granskningar och återblickar, precis enligt boken. De är energiska, har teamsymboler, åtnjuter stor frihet, och har definierat sitt eget syfte på en färgglad skylt på dörren in till teamrummet. Samtidigt måste de parera stor variation i inflödet, omloppstiderna för tingen i backloggen sträcker sig över år, och alla är egentligen överlastade, även om självstyret ger teamet möjlighet att blunda för överlasten.

Orsak: Här sker ingen direkt krock mot tankesätten i lean. Istället lyser tankesätten med sin totala frånvaro. Man har man helt enkelt inte förstått att den ökade agiliteten som de agila teknikerna kan ge ska användas för att förbättra värdeflödet. Agila metoder har ju inget självändamål. De måste bevisa sig för att vara värda kostnaden för dem. Värdet av dem måste visa sig i ett ökat nyttoutflöde. Utan den insikten styr man förvisso på rätt sätt (enligt körkortsboken) men inte till rätt mål.

Rotorsak: De som hjälpt organisationen att införa agilt har antingen själva inte en susning om hur det större pusslet kan läggas och varför det är en bra idé att lägga det, eller så har de missat att förmedla denna insikt. Av smidiga tekniker och handgrepp som ger en positiv effekt på sista raden i räkenskapsböckerna har det istället blivit ritualer och cargo-cult.

Konsekvens: Folk tröttnar så småningom på ritualer. Kostnaderna för dem börjar kännas. När inte värdet av dem blir uppenbart tröttnar även ledningen. Vid nästa neddragning ryker den agila coachen. Med all rätt.

Indikation på värre problem: Det är ganska många dysfunktioner som måste vara på plats för att den här situationen ska kunna inträffa: en ledning som inte förstår eller kan räkna på nyttan av det teamen gör (och därför inte kan ställa realistiska krav), en vana att inte ifrågasätta varför man gör som man gör, möjligheten att starta initiativ utan förankring i strategier... Dessa dysfunktioner är rätt vanliga, men lean och agila metoder ska i vanliga fall sätta ljuset på dem och få organisationen att börja ta tag i dem.

Konformistiska Förbundet Metod-Leaninisterna (rigorisitet!)

Symptom: "Vi har leanifierat den här utvecklingsavdelningen. Era agila metoder bryter mot våra beprövade effektivitets- och kvalitetshöjande tankesätt. Vi arbetar professionellt. På värdeströmstavlan kan vi följa var i projektmodellen ni befinner er, vi mäter antalet kodrader ni checkar in per dag och slår larm vid statistiska avvikelser, och vår 5S-grupp tog precis ner era röriga tavlor. Ni har alldeles för mycket små lappar synliga som stökar till det. Ska ni använda andra symboler som indikatorer än de som finns i manualen får ni ansöka om det hos metodkommittén. Vad betyder ens hjärtan och smiley-gubbar? Knarkar ni?"

Orsak: Lean ses, med rätta, som en mirakelmedicin. Men man tror, helt felaktigt, att det innebär att just leanverktygen X, Y och Z är mirakelmediciner. Dessa har införts med dunder och brak, utan att någon valt att fundera över varför just dessa verktyg skulle hjälpa just här.

Rotorsak: De som beslutat om leaninförandet förstår inte hur den egna värdeströmmen ser ut. I fabriken är värdeströmmarna ofta ganska enkla att se. På utvecklingsavdelningen kan det vara vanskligare. Tror man att projektmodellerna beskriver värdeflödet vid IT-utveckling har man uppenbarligen inte analyserat projektmodellerna med avseende på ojämnhet (projekt är enorma källor till mura). Tror man att det är ordningen på pappren och inte ordningen på tankarna som avgör om IT-utveckling lyckas, så vet man väldigt lite om det golv där man vill införa ordning-och-reda-verktyget 5S. Och ser man inte varför antalet kodrader bör hållas nere och så vet man ingenting om mjukvaruekonomi. Kod är en kostnad, inte ett värde.

Konsekvens: Skulle man följa leaninismen enligt ovan innebär det bom stopp för all produktivitet på utvecklingsavdelningen. I praktiken kommer inte folk att låta det ske. De kommer att köra lönnscrum, smyga in sina egna styrtavlor, och lägga (dyr och välavlönad) energi på att undvika inspektörerna. Möten kommer att ägnas åt att ljuga. Förhoppningsvis rinner leanifieringen ut i sanden. I värsta fall drivs den igenom med förnyad kraft.

Indikation på värre problem: Om man inte förstår de grundläggande skillnaderna mellan lean production och lean development är man illa ute om man äger en utvecklingsverksamhet. Inom lean production försöker vi t ex minimera variation (så länge vi inte kränker människor). Inom lean development försöker vi optimera den. Inom lean production försöker vi med trick som att begränsa samtidigt arbete för att jämna ut flöden. Inom utveckling (och andra verksamheter där variationen är nödvändig) kan begränsningar orsaka stopp i flödet, så vi behöver komplettera med andra tekniker som till exempel införa slack på ett helt annat sätt, osv osv.

Rotrotrotrotorsaken

I botten av dessa problem finns alltid en ledning som saknar de strategiska verktygen att se och förstå de ekonomiska villkoren för systemutveckling. Det gör att de ställer sig bakom beslut som är ekonomiskt destruktiva, till exempel låter lean och agilt krocka. Ändå är lean i grunden en utvecklingsstyrningsmodell. Deming presenterade PDCA i Japan som ett sätt att iterativt utveckla produkter (mycket liknande det sätt som Eric Ries beskriver utveckling på i boken Lean Startup). Det var Imai och andra som anpassade tankesätten till att gälla kvalitetsstyrning i tillverkningen. Och även kärnpunkten i lean production är utveckling: den ständiga processutvecklingen som bedrivs av folket på golvet. Produktionen är bara en konsekvens av detta innovationsarbete.

Människor som Donald Reinertsen har gjort mycket för att visa de ekonomiska villkoren för utveckling. Till exempel hur produktion av nätverkstjänster (telefoni, vägnät, och elström) har liknande villkor som IT-utveckling. Det finns alltså ramverk och metoder för att mäta och beskriva sådant som optimal beläggning av folks arbetstid, hur stor del av utvecklingskapaciteten man kan lova bort under en viss tidsperiod, och vilka spillkällorna egentligen är i en verksamhet som lever av att producera förfinad och exakt kunskap (systemutveckling är att förfina kunskap).

Vi som arbetar med att införa lean och agila metoder har här ett stort ansvar för att saker ser ut som de gör ute i verksamheterna. Om inte vi kan berätta om dessa saker så att de som styr förstår, vem ska då göra det? De tre exemplen på krockar jag nämnde ovan är förvisso komiska när de kläs i ord, men de är inte ovanliga. Jag har sett alla tre vid flera tillfällen, oberoende av varandra. Vi måste intensifiera vårt arbete att sprida verktygen som förhindrar krockarna. Det är vår uppgift att hitta sätt att lägga det större pusslet så att våra kunder förstår hur agilt och lean bara är två namn på samma sak: konsten att uppnå smidighet i hela flödet.

[Uppdatering: Läs gärna även ett annat litet inlägg jag skrev för något år sedan om lean och agilt.]