Blogg100, smidighet, samtid och framtid

Det här är en sporadiskt uppdaterad blogg. Den är min överskottsventil: jag trycker ut en text här då och då som inte får plats i något av det andra jag skriver och tänker. Jag kanske har varit insyltad i ett kunduppdrag som tagit all min tid. Men så tar uppdraget slut och då får jag tid att gå vidare med en tanke jag inte hunnit gå vidare med tidigare, och så blir det en bloggtext.

I andra tider har jag haft en blogg som ett tankeredskap. Ett ställe där man kan spotta ur sig det halvfärdiga. Bedriva själva tankeprocessen i det offentliga. Jag har litegrann saknat det.

Fredrik Wass på Bisonblog har i tre års tid kört en bloggutmaning på våren: blogga en post om dagen i hundra dagar. Han kallar tilltaget för #Blogg100, och tanken är att försöka konstgöda den svenska bloggosfären en smula. Den som inte direkt dog men slutade att vara ett bubblande ekosystem för några år sedan.

Jag vill försöka vara med i detta i år. Men det kräver att man har något att säga som passar det reflekterande (till skillnad från det färdigreflekterade) formatet. De predikningar om smidiga metoder som hittills fyllt den här bloggen är inte riktigt den sortens text. Vanligen skriver jag om konkreta tips och råd, och jag lägger inte ut något på bloggen om jag inte vet att det funkar och att åtminstone någon kan ha konkret nytta av det. Det ska vara genomtänkt och beprövat så att jag inte lockar någon på falska premisser.

Men jag har även en tankegång som absolut inte är färdig och där jag känner ett behov av att spekulera. Det gäller frågan om vilka samhällsförändringar man kan se i förlängningen av de smidiga metoderna. Agila metoder är som sagt inte något vi tar till inom en avgränsad genomförandefas av systemutvecklingsprojekt. Agila metoder sätter fingret på dysfunktioner som uppstår långt innan genomförandefasen, och utövar därigenom ett förändringstryck på hela värdekedjan.

På samma sätt funkar även de andra leanmetoderna. På golvet manifesteras strukturella dysfunktioner som har sitt upphov någon helt annanstans än just på golvet. Till exempel utanför organisationen, eller i beslutsfattandet högre upp i hierarkin. Under ett omoget ledarskap som tror att leanmetoderna handlar om att fixa till en avgränsad del av värdeströmmen misslyckas alltid lean. Antingen ger man inte folk verktyg att utforska rotorsakerna till problemen, eller så kväser man dem när de gör synligt att man själv är en del av problemen. Medan äkta lean är och förblir ett sätt att förbättra (dvs förändra) ledarskapet.

Tänk på alla vanföreställninga de smidiga metoderna avslöjar: tron att komplexa värdeströmmar kan toppstyras med direktiv, tron att de ekonomiska styrningsmodellerna inte bidrar till ett ökat spill, tron att problem i dynamiska system uppstått på det ställe där vi först får syn på dem, tron att ökat resursutnyttjande och beläggningsgrad sänker priset per producerad enhet, samt många många fler. Dessa stolligheter tros ju inte bara av enskilda chefer inom vissa verksamheter. Föreställningarna genomsyrar breda lager av samhället, och är tillochmed ibland institutionaliserade, som till exempel inom Statskontorets regelverk som tvingar fram stora projekt med hög risk.

Vad händer med ett modernt samhälle där dessa föreställningar monteras ner? Hur ändrar vi styrmedlen? Vad händer med arbetet, och upplevelsena av arbete? Vilka saker blir viktiga att utforska och vilka blir det inte? Det tänkte jag försöka fundera, spekulativt och tentativt kring. Under hundra dagar. Vi får se hur de går.

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.]

Vi bygger broar

- "Ja, agilt handlar ju bara om hur IT levererar projektet. För oss som beställer projekten kommer det inte att påverka!"

Hos en av mina kunder, som precis lämnat en period av gruvligt misslyckade IT-projekt bakom sig, hörde jag dessa ord yttras i fikarummet av en person från "verksamheten" (varför skiljer folk på "verksamhet" och "IT"?) som satt och pratade med en projektledare. Projektledaren nickade och höll med.

Organisationen hade gjort sin läxa och började nu sedan en tid tillbaka försöka tillämpa olika tekniker från den "agila" verktygslådan. Vi var mitt uppe i en stor utbildningssatsning och tittade samtidigt på olika sätt att organisera arbetet i linjen för att försöka komma bort ifrån de destruktiva projekten.

Skulle jag lägga mig i samtalet? Berätta för dem att de hade fått vissa fundamentala saker om bakfoten? Nej. Tids nog kommer de att bli varse, tänkte jag. Och jag vill dessutom att de ska nå den insikten inom ramen för en utbildning där de kan få ställa alla frågor och skapa sig en förståelse för hur helheten kan tänkas se ut.

Men deras tankevurpa är väldigt vanlig. Eftersom själva systemutvecklandet ofta är flaskhalsen i förbättringen av IT-system, så är det där som problem manifesterar sig. Och vi tror ju ofta (felaktigt) att problem uppstår i närheten av sin manifestation. Agila metoder ses då som en sorts smörjolja för att få de tröga kugghjulen hos IT att börja snurra lite fortare.

- "Scrum är en projektledningsmetod för IT-projekt i genomförandefasen!" kan det få heta.

- "Jo, vår projektstyrningsmetod kan köras agilt. Efter förstudie med analys och framtagning av lösningsförslag och specifikationer, så sker implementationen agilt i iterationer tills det är dags för systemtest!"

Det här tänkandet bygger på tron att problemen inom systemutveckling handlar om att vi gör rätt saker men att vi gör dem för långsamt. Då förstår man inte varför det går långsamt. Man förstår inte att överlämningar kostar. Att analysen, hur bra genomförd den än är, ändå kan peka fullständigt fel vilket ingen kan förstå förrän man faktiskt börjar att koda. Att avbrotten i form av olika faser kostar multum, och att uppgiftsväxlingen till följd av försök att på ett okoordinerat sätt köra projekten parallellt leder till merkostnader på över 100%. Man tror att förseningar är irriterande men billiga i jämförelse med att släppa delfunktionalitet så fort som möjligt, och man tror att uteblivna valmöjligheter i mjukvaran är betydligt dyrare än utveckling och förvaltning av alla dessa valmöjligheter.

Det som lean och agila metoder framförallt gör är att skapa synlighet om var de verkliga flaskhalsarna är. Kostnaden för trög omsättningstakt på information blir synlig, och produktutvecklingens faktiska ekonomi kommer i dagen. Den nya informationen skapar genast ett förändringstryck på andra delar i kedjan. När andelen krav som förblivit oförändrade från analys till systemtest visar sig vara låg, så ifrågasätter man förstås produktiviteten i analysfasen och varför inte analyserandet också ska ingå i en agil feedbackloop. När tidplaner sätts efter mätning av faktiska hastigheter istället för på väldigt volatila estimat, så blir värdet av att prioritera hårdare bland funktionerna uppebart (och beräkningsbart).

Vi blir varse om att vi deltar i en värdeström och att vi har ett ansvar att göra hela värdeströmmen bättre.

För att lyckas med detta öppnar vi våra dörrar. Agilitet åstadkommer man med transparens. Vi på IT-sidan har tekniker för att hjälpa verksamheter att förstå nyttor och effekthemtagning. Vi kan analysera flera varianter av brukarflöden parallellt för att tillsammans se vilka som ger störst värde till lägst kostnad. Agila metoder för systemutveckling ger oss en infrastruktur där vi kan identifiera behov och ta fram lösningar i ett obrutet flöde. Användarna har behov nu och ska inte behöva vänta längre än nödvändigt. Väntan är spill.

Men när vi nu öppnar våra dörrar och erbjuder metoder att länka ihop systemutvecklingsprocessen med de andra värdeflödena, så krävs det att någon på verksamhetssidan tar emot. Att de förstår att alla beställare-utförare-modeller är dyra och skadliga. Att de förändrar finansieringen av utveckling bort ifrån stora klumpsummor för oklara mål, till jämna flöden där man ska kunna se tydlig nytta direkt. Att verksamheterna också börjar att optimera bemanningen för tillgänglighet istället för utnyttjandegrad, så att det dyrbara samarbetet inte äventyras av konstlad tidsbrist.

Vi fixar det här tillsammans!

Nästa prat?

Vi samlade ihop papprena. För tre veckor sedan beslöt vi oss för att prova veckoliga samplaneringsmöten för att kunna synka mellan avdelningarna och skapa en samlad och sedan ständigt uppdaterad bild av den faktiska arbetsbelastningen på hela enheten. Den bilden skulle sedan kunna användas för att förmå chefer och beställare att prioritera hårdare mellan ärendena.

Nu hade vi provat, och funnit att det fungerade. Vi beslöt att permanenta mötet som en del i vår arbetsgång.

"Vad blir nästa steg?" frågades det. Vi hade en lista: Skapa ett dokument som beskrev mötet, uppdatera bilden av belastningen, var och en behövde sitta på sin kammare och ta fram ett förslag till omprioritering som chefer och beställare skulle kunna förhålla sig till. Och jo, sedan förstås också kommunicera den uppdaterade bilden, kommunicera beslutet om mötet, och kommunicera våra förslag till omprioritering.

Det är det där sista, kommunikationen, som är det viktiga.

Det är så lätt att glömma bort att inget av det vi kallade "steg" ovan egentligen för processen en enda bit framåt. Inget förändras av någon enda aktivitet vars beskrivning börjar med "Jag ska sätta mig och ...". Arbetsprocesser handlar inte om vad vi gör på vår kammare. Arbetsprocesser handlar om vilka interaktioner folk har med varandra. Vi människor och våra samspel är viktigare än våra metoder och verktyg.

Om aktiviteten kan beskrivas på formen "Vi ska sätta oss och ..." har vi kommit ett steg längre. Då är vi igång och förändrar processen inom vår egen krets. Om aktiviteten kan beskrivas på formen "Vi ska sätta oss med dem där borta och ..." har vi äntligen påbörjat vår riktiga förändringsresa. Den där vi börjar påverka helheten, där vi börjar genomsyra den.

Så nästa gång ni frågar er: "Vad blir nästa steg?" (i sig en viktig coachande fråga, annars är det lätt att glömma bort att vi behöver göra konkreta nästa steg), så ställ även frågan: "Vad blir nästa prat?"

Fundera sedan: Vilka behöver prata med varandra för att något verkligen ska hända och förändras? Vilka grejer behöver vi göra på vår kammare innan för att få en bra kvalitet på pratet? Kan vi rensa bland de grejerna? Kan vi på det sättet få pratet att äga rum lite tidigare, så att inte processförändringen blir så seg och utdragen?

1-3-6-9 poäng

På en "kadensdelad" synktavla (det jag använder oftast nuförtiden) hänger ärendena i respektive avdelning: Dagsärenden i dagskolumnen, veckoärendena i veckokolumnen, månadsärendena i månadskolumnen, och så vidare. Risken är stor att ärendena blir hängande där. Tavlan fylls liksom på utan att man hinner ta hand om allt.

Ett sätt att hålla nere mängden pågående arbete och samtidigt se framstegen, är att varje dag i veckan se hur mycket det är kvar på veckoärendena. Varje veckoärende som inte är påbörjat (men ändå hänger i veckokolumnen, i sig en indikation om att man tagit på sig för mycket) har 10 poäng.

Så snart vi påbörjat ett veckoärende genom att ha gjort färdigt dess första dagsärende, så får veckoärendet 9 poäng. När vi gjort mellan en tredjedel och hälften av veckoärendet får det 6 poäng. När vi gjort mellan hälften och två tredjedelar får det 3 poäng. När det bara är pyttelite kvar får det ett poäng. När vi är klara får det noll, och ärendet flyttas över till Verifierings-kolumnen.

På så sätt kan vi hålla ordning på veckoärendena: kommer vi att nå i mål med dem? Vi kan se hur den sammanlagda summan av de pågående veckoärendenas poäng krymper. Detta utan att behöva räkna i någon finkornig enhet som "timmar" eller liknande. Varje ärende har sex steg: färdigt till 0%, 10%, 30%, 60%, 90%. och 100%. Det är kategorier som är mycket lätta att kategorisera in i.

Man kan spåra detta fysiskt på olika sätt. Har man många småmagneter kan man sätta fyra magneter (90% kvar) på lappen som första steg, och sedan ta bort dem en i taget när ärendet kommer närmare målet (60%, 30%, 10%, helt färdigt). De borttagna magneterna kan placeras i en ruta vid sidan av, en ruta där man då kan se de totala framstegen.

Eller så kan man sätta prickar på veckoärendena när de närmar sig målet. Fast det finns en nackdel: man får svårare att backa då. Ett ärende kan ju även <b>fjärma</b> sig målet under resans gång. Det är ju viktigt att man inte tänker på prickarna i termer av <b>upparbetad tid</b> utan som just hur långt det faktiskt är kvar.