Flödet eller folket?

Ramlade för en liten tid sedan på ett större managementkonsultbolags metod att implementera något lean/agilliknande på kontorsgolvet. Det såg bra ut. En gemensam tavla, synliggjorda arbetsflöden, dagliga synkmöten runt denna tavla. Men det var något som verkade lite avigt.

Tavlan hade en simbana för varje person. På tavlan kunde folk se vilka ärenden jag jobbade med genom att titta i min simbana, eller i Hezans simbana för att se Hezans ärenden. Det var alltså en tavla med resursfokus, snarare än med flödesfokus.

Synkmötena blir med en sådan tavla bara en rapporteringspunkt: Jag berättar vad jag gör, vilket du kan se i min bana, och du berättar vad du gör. Kommer någon dit och frågar hur det går med det ena eller andra värdeskapandet fladdrar vi med blicken över tavlan. Vem av oss var det nu som höll på med just den gruppen av ärenden? Hur nära målet är vi? Hur ska vi synliggöra att vi behöver samarbeta om ett och samma mål? Klippa sönder samma lapp och sätta upp en del i varje persons simbana?

Ett resursfokus kan inte samsas med ett flödesfokus. Om min simbana ser tom ut kan man dra slutsatsen att jag behöver ta till mig lite mer arbete för att bli fullbelagd. Men det säger ingenting om hastigheten på de ärenden vi jobbar på. Det säger ingenting om det värde vi försöker leverera. Rent matematiskt fungerar det tvärtom: ju mer vi maximerar vårt kapacitetsutnyttjande, desto långsammare kommer genomströmningshastigheten av ärenden att bli. Åtminstone när vi närmar oss våra kapacitetstak.

Ha flödena i fokus på era flödestavlor. Låt simbanan utgöras av en värdeström. Visualisera hur nära målen respektive ärende är. Då får synkmötena fokus på synkronisering runt värdeskapandet snarare än att vara ett enkelt pulsmöte där var och en rapporterar vad den sysslar med.

Frågan om vad var och en gör är fortfarande viktig. Men hellre att man kanske försöker begränsa vad var och en håller på med samtidigt (för att undvika dyr uppgiftsväxling). I Synk använder vi magneter: varje person har bara ett visst antal magneter. Du sätter en magnet på varje ärende du jobbar på. Går det för långsamt och är för svårsynkroniserat: minska antalet magneter.

Skaffa fokus. Optimera på flöde, inte på folk. Samsas och svärma runt värdeskapandet. Synka.

Ledarskap och ansvar

Det var en gång en skola i Göteborg, en skola jag själv för övrigt gick i några år på 80-talet. Som ni kan läsa i artikeln var där en chef som hade att välja mellan att antingen följa budgeten eller lagen. Ett i grunden omöjligt val, men som chefen ändå tog sig an. Någon måste ju göra det, och ledarskap är att ta ansvar för en situation även när den är hopplös.

Skolchefen valde en väg som innebar en övertrasserad budget, något som naturligtvis ledde till problem och att skolchefen så småningom slutade. Chefens egen berättelse kan man läsa här. Man kan ha många synpunkter på händelseförloppet, men det som jag skulle vilja fokusera på är alla frågor runt ledarskap, chefskap, och förvaltning som det här väcker.

Det är alltid vanskligt att utifrån en tidningsartikel uttala sig om ett speciellt fall, men låt oss för diskussionens skull anta att de två artiklarna ger oss en hyfsat god bild av verkligheten. Då framträder ett mönster som jag sett alltför många gånger och det är farorna med det mönstret jag skulle vilja belysa.

Vi har alltså en linjechef (skolchefen) som upplever en konflikt mellan kraven på verksamheten och de resurser som finns tillgängliga. Chefen gör helt rätt i att kvalitativt analysera situationen och besluta om de åtgärder som krävs. Chefen är dock hela tiden medveten om att detta innebär ett avsteg från den budget hon är tilldelad, och agerar därför i enlighet med jidoka-principen och eskalerar denna avvikelse till sin överordnade mellanchef.

Nu händer det intressanta:

"Hon hade hållit sin närmaste chef underättad om ekonomin hela tiden. Hon fick därför något av en chock när hon blev kallad till stadsdelsdirektören som förklarade att de inte hade förtroende för henne eftersom hon överskridit budgeten."

Jag har inga problem att tro på att hon fortlöpande underrättat sin chef, mellanchefen om situationen utan att dölja något. Skolinspektionen hade kritiserat skolan för brister, och hon var uttryckligen rekryterad för att åtgärda dessa brister. Om inte mellanchefen följt upp hennes arbete kontinuerligt hade det varit mycket anmärkningsvärt.

När nu stadsdelsdirektören, mellanchefens chef om jag förstått det rätt, kallar in skolchefen och meddelar henne om förvaltningens bristande förtroende, och att skolchefen blir förvånad över detta, så säger det en hel del:

1. Mellanchefen måste ha eskalerat ärendet till stadsdelsdirektören utan att ha meddelat skolchefen. Den bristande transparensen kan man ha synpunkter på.

2. Om du är en mellanchef och möter en underställd linjechef som meddelar att hon överskrider budgeten för att hantera en akut situation har du i princip bara tre rimliga sätt att agera på:

• Säga: "Bra! Jag bedömer att du gör rätt och står bakom dig i det här."
• Säga: "Nej, du har inte prioriterat rätt. Budgeten är viktigare än lagkraven."
• Säga: "Detta är ohållbart. Vi får gemensamt försöka hitta en tredje väg, eller så eskalerar vi ärendet till min chef om vi inte kan hitta en utväg."

Det fjärde sättet: att lyfta hela situationen uppåt utan att själv ha någon åsikt i frågan, och låta stadsdelsdirektören fälla avgörandet och till och med meddela beslutet, är inte bara fegt. Det är att tydligt bevisa att man själv är fullständigt onödig som chef. Om man inte leder sina underställda genom att hjälpa dem i kniviga prioriteringssituationer så är man bara en budbärare mellan nivån under sig och nivån över sig. En budbärartjänst man lika gärna kan ersätta med epost.

En chef bidrar genom stöttning och resursallokeringsbeslut. Kan man inte leverera detta bidrar man inte med något värde. Då är hela ens egen tjänst ett spill och ett slöseri.

Skolchefens fundamentala kritik mot förvaltningen så här i efterhand kretsar mycket kring organisationen med de många mellanchefsnivåerna:

"– Jag är inte arg på någon person, utan på ett system som vi människor byggt oss in i. En stadsdelsorganisation där mellancheferna blivit fler, rollerna otydligare och beslutsgångarna snåriga. Det kräver stora resurser som borde användas för skolans huvuduppdrag och komma barnen till del."

I lean och agila metoder eftersträvar vi platta organisationer, och det är av precis de orsaker som hon nämner. Vi betraktar chefer som leverantörer, leverantörer av goda och precisa beslut. Snårighet och otydlighet vad gäller besluten är muda, spill, slöseri, waste, på samma sätt som kopieringspapper av dålig kvalitet är spill. Nyckelordet är få men tydliga chefsnivåer. Inte många och flummiga.

Jag håller med skolchefen om att de korta beslutsvägarna på föräldrakooperativet där hon jobbar idag bör kunna replikeras i den kommunala förvaltningen. Det här är ingen fråga om mer eller mindre resurser till verksamheterna (vet att Göteborgs kommun dräller av projekt där man vräkt på resuser med tveksamt resultat), utan en fråga om ett undfallande och ogenomtänkt ledarskap. Jag rekommenderar att skolchefens systemsyn bör spridas i förvaltningen, genom de beprövade metoder i systemtänkande och smidiga arbetsmetoder som faktiskt finns, och att resuserna läggs på eleverna som behöver dem istället för på meningslösa mellanchefspositioner.

När det gäller just det särskilda fallet måste vi vara försiktiga med att döma. Artiklarna innehåller bara en liten del av sanningen. Men detta generella mönster av vagt och meningslöst ledarskap från onödiga chefsnivåer har jag stött på tillräckligt ofta. Det finns, och vi bör göra vad vi kan för att städa bort det.

Den drivande gruppen

(Detta är det andra inlägget i en genomgång av Kotters åtta misstag vid förändringsledning, och vad vi agilister gör för att undvika dem.)

2. Ingen grupp som visar vägen

Lean och agilt uppfanns av ett nödtvång. Japansk industri har alltid tvingats hantera resursknapphet, för Japan har oerhört ont om industrivänliga naturresurser och måste importera nästan allting. De måste bli experter på själva förädlingssteget, eftersom de inte får råvarorna billigt. Efter andra världskriget behövde de i sitt krigströtta land denna hushållningskonst ännu mer, och så uppfann man de tekniker som vi idag kallar "lean": flödesoptimering, spilljakt, människovänliga verksamheter, och ständig förbättring.

I slutet på 80-talet och början på 90-talet behövde mjukvaruutvecklare hantera det faktum att mjukvaruprojekt misslyckades i exponentiellt högre grad än tidigare, bara för att komplexiteten i datoriseringen och omfattningen av projekten växte. I organisationer där omgivningen, t ex beställare och ekonomistyrningsfunktion, inte förstod att mjukvaruutveckling kräver ständiga omtag och att verksamheten därför är omöjlig att planera i förväg, där behövde man i ännu högre grad hantera detta. I sådana miljöer med missriktade försök att kontrollera utvecklingen, där är risken för misslyckanden ännu större. Som motvikt lånade utvecklingsorganisationen en massa verktyg från det japanska fabriksgolvet och drev igenom dem, inte sällan på tvärs mot organisationens vilja.

I leanrörelsens Japan var medvetenheten om problemet stor i hela organisationen, och därför också angelägenhetsgraden. Man gjorde förändringsarbetet till en prioriterad verksamhet för själva ledningen. Det är alla chefers ansvar att sprida insikten om behovet av förändring, men också att sprida de trygga verktygen för att folk själva ska kunna experimentera och förbättra sitt eget arbete. I västerländsk mjukvaruindustri var (eller är) inte insikten om förändringsbehovet lika spridd. Där drevs förändringen av modiga människor som vågade gå på tvärs i organisationen för att kunna skapa agila bubblor i en huvudsak fientlig miljö.

Nöden har alltså historiskt agerat drivkraft för förändring i både lean och agilt. Men där japanska industriföretag som Toyota förankrat förändringen på ledningsnivå, har vi agilister inom IT ofta nöjt oss med att skapa små bubblor av agilitet. Inom lean vill man förvandla hela ledarskapet och gör den närmaste linjechefen till att bli en coachande förändringsledare. Men inom agil mjukvarutuveckling inrättar vi istället till exempel rollen "Scrum Master" och liknande som ska ha till uppgift att skydda produktiviteten inom en grupp, mot ledningens, inte sällan linjechefens, destruktiva inflytande. Organisationen tvingas alltså lägga ner energi på att bekämpa sig själv.

Kotter påpekar att ska det bli något av förändringen så måste det till en grupp som driver den. Gruppen måste bestå av folk med tillräckliga mandat så att de faktiskt får lov att bestämma sånt som behöver bestämmas. Ska förändringen genomsyra en större del av organisationen måste denna grupp, koalitionen som Kotter kallar den, ha kanska stor beslutsmakt.

Här går man ofta vilse när man ska driva agil förändring i lite större organisationer. Läser man en bok om Scrum och börjar i den lilla skalan, så är det lätt att tro att allt som behövs är en liten agil bubbla. Förändringen behöver aldrig kliva utanför den. Men det är fel. Till en början räcker det med bubblor som så småningom växer samman. Men en stor del av resan mot organisationsagilitet handlar om att få syn på de stora strukturella hinder för lättrörlighet som finns i organisationen idag. De agila metoderna tar inte bort dessa hinder, men gör dem plågsamt synliga. Behovet av större organisationsförändringar blir uppenbart.

Då hjälper inte längre självstyre och delegering och små bubblor som skyddas av scrum masters. Då måste organisationen fatta beslut om sin egen transformering, och inrätta en gruppering som driver den.

Är det lean/agilt man ska införa uppstår nu en avgörande stund för den gruppen. Metoderna i lean/agilt är ju inte handgrepp som folk ska börja utföra på order från ledningen oavsett vilka hinder de stöter på. Det är ju metoder som ska avslöja hindren och hjälpa folk att på ett metodiskt sätt avlägsna dem. En stor del av dessa hinder är alltid dagens ledning, inte sällan hos de människor som sitter på själva förändringsmandaten. Det är inte ovanligt att den förändringsdrivande gruppen måste förändra sig själv och sina förantaganden flera gånger för att lyckas.

Så det är verkligen vanligt att man glömmer bort behovet av en drivande grupp vid införande av lean/agilt. Men det är minst lika vanligt att en drivande grupp, när den väl är på plats, inte driver igenom förändringen på ett lean/agilt sätt. I sin iver att vara drivande lyssnar den inte på de signaler som de nya arbetssätten sänder ut. De modifierar inte sitt angreppssätt och sina planer under resans gång. De ignorerar den agila huvudregeln om att ständigt granska och anpassa ("inspect and adapt"). Gruppen måste själv vara genomsyrad av agila värden och arbetssätt för att lyckas, och det innebär bland annat ödmjukhet att inte väja för insikten om att man själv kan vara lika mycket ett hinder för förändring som en drivkraft för den.