Kurs: Lotsa till självstyre i Göteborg (26/3)

Som jag skrev om tidigare ska jag i vår ge en heldagsutbildning i hur man kan bedriva ett coachande ledarskap inuti eller för ett arbetslag som vill bli mer självgående (och därmed agila). Är du teamcoach, scrummaster, linjechef, leanvägvisare eller liknande kan detta vara något för dig. Arbetsnamnet är just nu "Lotsa till självstyre".

Det är svårt med namn. Man hade kunnat kalla kursen "Agilt ledarskap" eller "Masterclass i agil lagcoachning" eller en massa andra saker. Men varje namnförslag beskriver bara någon aspekt av innehållet, och utlämnar en massa annat. Jag fastnade till slut för "Lotsa till självstyre" för det uttrycker både målet: ett självgående gott gäng som jobbar bra ihop, och vägen dit: att man lotsar mer än styr.

Nu har vi ett datum spikat också, det blir torsdag 26 mars 2015. Kursen kostar 6000 kronor plus moms, pågår från klockan 9 till 16.15, och innehåller god fika, god lunch, goda kunskaper, goda samtal, och lite kursmaterial.

Kursen går av stapeln hos Squeed i Göteborg, som visserligen är ett IT-bolag men notera att den här kursen inte innehåller något IT-specifikt. En scrummasterutbildning förutsätter Scrum, en metod som har systemutvecklingsrötter. Den här kursen lär istället ut ett coachande agilt ledarskap, oavsett inom vilken bransch du jobbar i.

Lärandet

Det krångliga är inte att organisera sig så att en rulle plåt i en fabrik förvandlas till en bil. Det krångliga är att hantera informationsflödena som går i motsatt riktning, och att få organisationen att på ett smidigt sätt självorganisera sig runt förändringar i denna information. Lärandet är en central komponent i att få till smidiga arbetsflöden. I grund och botten är vägen till smidighet ett pedagogiskt problem.

Ur introduktionen till momentet om den lärande organisationen.

Jag håller på att uppdatera mitt utbildningsmaterial. Under de senaste åren har jag sett vad som fungerar och vad som inte fungerar. Efter att ha lett ett par massiva utbildningssatsningar har jag sett hur själva kurshållandet är väldigt ineffektivt. Det måste kompletteras. Jag har läst om, och pratat med många skollärare som använder sig av, det flippade klassrummet. Jag försöker arbeta in element från Traning From the Back of the Room. Och jag försöker tillgodogöra mig så mycket av både ny och gammal kunskap om kognitiva funktioner och pedagogik som möjligt: Om hur färdigheter och kunskaper kodas in i oss. Om hur språk och andra mentala modeller påverkar hur vi lär oss. Om hur viktigt det sociala samspelet är för att befästa kunskaper.

För att smidiga metoder med sitt stora fokus på delegering och självorganisation ska fungera så krävs det att verktygen (kunskapen och förmågorna) är väl spridda till alla nivåer och yrkesgrupper. Lärandet måste fungera även för en stressad vuxen med låga förkunskaper, låg självstudieförmåga, kort uppmärksamhetsspann.

Jag försöker formulera mig i ett par vägledande principer som jag kan ha i bakhuvudet när jag jobbar med mitt material. Men jag känner att jag skulle behöva bolla de här principerna tillsammans med fler människor som också är intresserade av lärande.

Korta moment i ett tydligt sammanhang. Alla kunskaps- och pusselbitarna måste vara väldigt välavgränsade. När man har en ansträngd uppmärksamhets- och tidsekonomi blir varje sekund i fokus dyrbar. Man måste hela tiden se slutet på momentet, för att veta hur man ska hushålla med den mentala engergin. Samtidigt får inte bitarna ligga huller om buller utan ska vara relaterade. Man ska veta när man dyker in i ett moment vart det för en och hur det förhåller sig till andra moment. Ett moment definieras av sina lärpunkter, de kunskaper eller färdigheter du ska ha tillägnat dig när du är klar med momentet.

Digitala mobilanpassade självskattningsverktyg. Självskattningsverktyg med snabb återkoppling ger både information om hur långt man kommit i sitt lärande och vad man har kvar, samtidigt som det lär ut. Ökar man svårighetsgraden i små steg är sådana här verktyg flowskapande, precis som ett bra dataspel. Verktygen måste följa momenten.

Flermodalt men i en konsekvent begreppsrymd. Informationen måste vara förankrad i en enkel och konsekvent begreppsrymd så att man på ett ekonomiskt sätt kan knyta informationsbitar till ett och samma semantiska nätverk, utan att behöva öda tid på att översätta mellan modellerna. Samtidigt måste det finnas flera parallella presentationer av samma rymd: texter, upplästa texter, föreläsningar, bilder, filmer, spel, övningar. Engageras flera sinnen befästs kunskapen bättre.

Förankra kunskapen och förmågorna med utgångspunkt i sociala situationer. När kunskaper och förmågor beskrivs utifrån sin förmåga att påverka sociala samspel där starka känslor är inblandade, så upplever vi dem som mer relevanta än när de inte gör det. Människans utgångspunkt är för de allra flesta det sociala samspelet i närmiljön.

Så långt har jag tänkt, och börjat arbeta utifrån. Jag känner att jag skulle vilja ha lite återkoppling runt de här tankarna.

Uppdatering, 26 augusti 2015: Jag fick två goda reflektioner på Facebook:

Relevans. Det jag skrev om att "Förankra kunskapen och förmågorna med utgångspunkt i sociala situationer" handlar i grund och botten om relevans. Det är en observation att vi människor ofta upplever sociala samspel som särskilt relevanta. Samspel har stor emotionell betydelse, och starka känslor är viktiga för inlärningen. En psykolog i bekantskapskretsen påpekade att kunskaper och förmågor som förhindrar starka negativa emotioner är särskilt lätta att lära sig. Det är en starkare drivkraft än glädje och andra positiva emotioner.

Världsbild. Arbetssätten jag lär ut bygger på vissa antaganden om världen: att människor är välvilliga och potentiellt kompetenta, att organisationer liknar organiska komplexa system, osv. Om jag inte aktivt ser till att förmedla den världsbilden, och därtill hörande goda syften, så kommer själva kunskaperna och färdigheterna jag lär ut att hamna snett.

Inlägg om Synk

Några inlägg om den generella agila metoden Synk:

Synktavlan - En beskrivning av den värdeflödestavla vi använder oss av.

Ärendepreparering i Synk - Visar hur ärenden går från inkorgen till planerat genomförande.

Mötena i Synk - En översikt över mötena: planeringsmötet på måndagen; det dagliga synkmötet; veckomötet, månadsmötet och förbättringsmötet på fredagarna, samt det strategiska kvartalsmötet.

Planeringsmötet - Mer i detalj vad man gör den första halvtimmen varje måndag.

Synkmötet - Beskrivning av arbetsgången under det dagliga morgonmötet.

Veckomötet - Om det avslutande veckomötet vid fredag lunch.

1-3-6-9 poäng - Om ett sätt att mäta framstegen under veckan.

Masterklass i agil lagcoachning?

Till våren kommer jag att hålla lite utbildningar och seminarer i Göteborg. Det är inte helt spikat än, men det är några ämnen jag överväger. En grej som jag särskilt gillar, och som jag hitills bara har hållit företags- och organisationsinternt men som jag skulle vilja nå ut med till fler, det är den här:

Masterclass i agil lagcoachning: Folk som är linjechefer i agila eller lean-organisationer, eller på andra sätt jobbar med ett coachande ledarskap för team i sådana organisationer (scrum masters, leanvägvisare etc), brukar tycka om den här heldagskursen. Vi utgår från några av de frågor som ni tar med er in i rummet, och så avhandlar vi:

• Gruppdynamik utifrån Tuckman och Wheelan. Organisationen som summan av kvaliteten i relationerna.
• Sociala motivatorer och demotivatorer utifrån bl a David Rock, Daniel Pink, och Matt Lieberman.
• Hur man synliggör arbetet för att minska stress och press med hjälp av flödestavlor och vettiga mätetal.
• Konstruktiv mötesfacilitering för beslutsmöten, lärandemöten, och problemlösarmöten. Hur samtal blir coachande.
• Medarbetardrivet förbättringsarbete i små steg. På riktigt medarbetardrivet.

Låter det intressant? Nå mig på Twitter eller här nere i kommentarsfältet, så pratar vi.

Respektera människan

"Nej, du får inte ha mer än ETT foto på familjen på ditt skrivbord! Nu är vi ju Lean!" "Vi har infört Lean på den här vårdcentralen, så alla tidsbokningar är lika långa och din tid är nu ute!" "I och med Lean har vi standardiserat våra arbetsprocesser. Ska du jobba här är det din uppgift att följa dem, inte att ifrågasätta dem!"

Ovanstående är alldeles autentiska tillämpningar av vad vissa svenska organisationer tror är att arbeta lika effektivt som på Toyota. Jag har själv stött på dem, både sett och hört, och varje gång man träffar andra leanvägvisare och agila coacher kan de berätta i stort sett samma sak. Vi himlar med ögonen och suckar och skojar om LAME (Lean As Misguided Executed); eller MEAN. De har ju inte förstått! Men vad har de inte förstått? Kan man sammanfatta det på ett sätt för att hjälpa dem att förstå?

På Toyota har man rensat bort många av sina långa listor av principer och tankegångar. Man har försökt renodla sina tankesätt, och kommit fram till att hela filosofin kan sammanfattas i två punkter: Ständig förbättring, och Respektera människan. Och dessa hör dessutom intimt ihop.

Att respektera människan är något mer än att bara vara artig. Ibland kan till och med respekten visa sig i att man är brutalt ärlig på ett sätt som inte uppfattas som speciellt artig. Det handlar nämligen inte om artighet, utan om att ta hänsyn till folks faktiska behov när de ska hjälpas åt för att uppfylla organisationens gemensamma syfte. Jag tänker på tre saker:

Anpassa miljön efter människan

Jag kan inte japanska, men har fått förklarat för mig av flera människor som kan språket, att Toyotas sätt att skriva "Respektera människan" egentligen kanske bör översättas med "Respektera det mänskliga inom människan".

Ska vi kräva av kroppsarbetaren att hen ska jobba med felaktigt utformade verktyg som sliter ner kroppen, eller ska vi anpassa verktygen efter hur kroppen faktiskt fungerar? Ska vi sätta tankearbetaren i pratiga miljöer där tankarna hela tiden avbryts, eller ska vi erbjuda tankestödjande miljöer? Ska vi tvinga folk att ha många bollar i luften samtidigt, trots att vi är byggda för att fokusera? Använder vi tankeergonomiska verktyg? Vår hjärna och resten av vår kropp ser ut på ett visst sätt, är verktygen i samklang med det?

Det är inte dyrare att anpassa processerna än att se människor slitas ner. Om det mänskliga faktiska funktionssättet inte är i harmoni med hur vi förväntas jobba, så har vi en inbyggd produktivitetsförlust. Vi går sönder, samtidigt som arbetet blir sämre utfört än vad det skulle kunna bli. Att harmonisera arbetssättet med människorna som ska utföra arbetet är ekonomiskt sunt. Trots det tillåter vi arbetssätt som förstör oss.

Varför blir det så? En mänsklig egenhet är att vi alldeles för lätt håller oss med osanna föreställningar om människans konstruktion. En annan mänsklig egenhet är att osanna föreställningar upphöjs till allmän lag så länge som en högstatusperson tror på dem. Men att få reda på hur människan egentligen fungerar som bäst kräver istället empiri, att man tittar på fakta. Empiriskt förhållningssätt utmanar ständigt statushierarkier, och därför är kampen för empiri inom verksamheten en ständig kamp. Det krävs ett konstant arbete för att inte tappa bort kunskapen om hur människor faktiskt fungerar som bäst.

Om alla, inklusive ledningen, på allvar har ambitionen att visa respekt för det mänskliga inom varje människa, kan det hjälpa oss att undkomma dessa tankefällor. Jag kanske tänker bättre om jag har tjugo bilder av min familj på skrivbordet. Är det mitt jobb att tänka bör jag då naturligtvis då också ha tjugo bilder där. Oavsett vad någon lam "lean"-konsult har sagt, och oavsett vad min chef tror om optimala arbetssätt.

Mänsklig variation ÄR

Principen om att respektera människan är en humanism. Det liknar Kants hållning att aldrig se människor som instrument för något annat, utan istället se varje människa som ett mål i sig. Som vi såg ovan så är det sunt att respektera mänskligheten bland de anställda, även om vi skulle betrakta dem som verktyg. På samma sätt som jag inte överlastar en maskin eller tvingar den att arbeta i en temperatur den inte är byggd för, ska jag inte överlasta mina små människor jag har anställt.

Alltför stor variation är en smidighetens fiende. Inom tillverkningsindustrin försöker vi utplåna variationen. Vi försöker hela tiden flytta gränserna för vad som är acceptabel tolerans när det gäller måtten på sakerna vi tillverkar, och mängder med tankesätt och processer har utformats för att förbättra den här aspekten. "Six sigma" till exempel. De tankesätten och processerna har definitivt sin plats i lean-familjen, och är viktiga för smidighet inom tillverkningsindustrin.

Skruvar och muttrar är ting. Där ska vi minimera variationen. Men människor är människor. I enlighet med principen om att respektera mänskligheten inom människan är det inte lean (utan "mean") att minimiera variation som har ett mänskligt ursprung. Den variationen ska inte minimeras utan hanteras.

När folk med bakgrund i "lean production" ger sig på att försöka "leanifiera" processer där arbetspaketen består av människor, är det inte ovanligt att de tar miste just här. De sätter igång med att minimera variationen och är inte vana vid att själva skruvarna och muttrarna i processen har känslor och ska respekteras.

Det är inte lean att på en vårdcentral standardisera tiderna på ett sätt så att de besvär folk faktiskt söker för inte kan hanteras på ett vettigt sätt. Istället ska man försöka utforma processen för att hantera alla dessa olika patienters varierande behov av tid. Att möta folks behov är ju själva vårdcentralens syfte.

Det är inte lean att optimera provtagningsflödet om det innebär att människor tvingas vänta. Istället bör man optimera människornas upplevelse genom systemet, både patienternas, de anhörigas, och vårdpersonalens. Respekt för människan handlar om respekt för ALLA människor!

Ständig förbättring är respekt

En uppfattning man ibland stöter på är att det är bristande respekt att ställa krav på folk eller att ifrågasätta dem. Inom lean och smidiga metoder säger vi istället att det förhåller sig tvärtom: Att inte ställa krav på förändring och förbättring (vilket kräver ifrågasättande) är respektlöst. Människan är skapt för att uppfinna bättre sätt att jobba på, och vi kallar bara det för förbättring som faktiskt ökar värdet för människor. Ständig förbättring och att respektera människan hänger ihop!

En anekdot runt det tidiga förbättringsarbetet på Toyota handlar om hur en fabrikschef lite burdust hjälpte sin personal att standardisera sina arbetssätt. Kvaliteten hade varit väldigt skiftande, eftersom folk hade monterat saker på högst olika vis. Nu slogs det fast hur man skulle jobba, och beskrivningen sattes upp på väggen så att alla kunde se att saker och ting gjordes rätt, och nåde den som avvek från standarden.

"Jag kommer tillbaks om en vecka..." sa chefen, "...och då vill jag se att ni har förändrat processen!".

Fundamentet "Ständig förbättring" bygger på insikten om att alla förbättringsinitiativ måste utgå från platsen, gemban, golvet, där själva värdet skapas och också spillen och slöserierna uppstår. Det är människorna som står på själva golvet som vet vad som faktiskt händer där, både det bra och det dåliga.

Ständig förbättring utan respekt blir det när någon som befinner sig ganska långt från golvet tror att hen vet vad som händer där och vad som behöver göras. Det är väldigt lätt att man som chef tror att man förstår golvet. Och nog förstår man, men eftersom man inte ser allt så blir också ens förståelse väldigt grumlig. De förbättringsåtgärder man föreslår utifrån sin upphöjda position misslyckas garanterat.

Istället bygger förbättringsarbetet inom lean på att det drivs från golvet. Det är chefens uppgift att på ett coachande sätt hjälpa folket på golvet att se vad som händer och vad som behöver göras. Det innebär bland annat, som syns i länken, att man som chef ifrågasätter och utmanar folks uppfattning om vad som händer. Men inte att man ersätter deras ytliga förståelse med sin egen ytliga förståelse, utan att man använder förbättringsverktyg (rotorsaksanalysen, A3, Toyota Kata, riktiga retrospektiv etc) för att ersätta all ytlig förståelse med en gemensam djupare.

Man coachar sina anställda i att använda de empiriska förbättringsverktygen, och därigenom försöker man motverka tendensen att det är personen som är högst i rang som bestämmer vad som är sant. "Asking people to improve their work and giving them the tools to do it (e.g. Kaizen) shows the ultimate form of respect in my opinion. In other words management is saying that we trust and expect that you will take a hand in making things better in order to ensure our survival. The implied message is one of mutual trust and respect."

Att utgå från verkligheten är att respektera människan.

Lean och smidighet handlar i grund och botten om en enda sak: öka värdet. Men ett värde är alltid en människas upplevda värde. Det finns gott om moraliska skäl för varför vi inte ska betrakta människor som ekonomiska verktyg för våra egna syften. Men även om vi skulle välja att betrakta dem så, så är det ändå mer lönsamt att hålla på principen om att respektera själva det mänskliga inuti oss. Det största värdet skapas i en långsiktig och uthållig process, och den långsiktigheten är bara möjlig om var och en får det som den faktiskt behöver. Det finns inget annat skäl än dumhet (LAME) eller elakhet (MEAN) att inte låta denna princip vara vägledande i allt man gör.

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.

Veckomötet

Veckomötet vid fredag lunch är vad som avslutar veckorytmen. Det är nu vi samlar statistik.

Ha ett A4-papper uppsatt på tavlan där veckostatistiken anges. Skriv veckonumret i början på en ny rad. Bredvid skriver du:

• antalet ärenden som ligger i Klart,
• antal ärenden som är i Acceptera,
• samt antalet ärenden i resten av tavlan förutom i Inkorg och Avvisa (dvs summera ärendena i Prio, Preparera, Redo, Plan, Utför, och Verifiera; det är dessa ärenden som räknas som pågående).
• Skriv ett minustecken och
• antal ärenden som är i Inkorg samt
• antalet ärenden som är i Avvisa.

Med röd penna skriver ni antalet akuta ärenden på hela tavlan (både i Klart och i alla andra kolumner). Skriv ett divisonstecken (snedstreck). Räkna hur många persondagar (i heltidsekvivalenter) som arbetade under med tavlan under veckan, och skriv ner det.

Om ni har haft övertid så skriv det inom parentes som en multiplikator (om övertiden var 10% så skriv 1.1).

Med denna enkla statistik kan man få en enormt massa information som är användbar när man ska förbättra sig. Under detta möte ska vi tömma kolumnen Klart samt kolumnen Avvisa. Var säker på att du i bägge fallen har meddelat mottagaren.

Diskutera er situation: vad fungerade bra och vad fungerade mindre bra? Vilka strategier kan ni välja mellan nästa vecka för att tackla problemen ni ser? Vilka strukturella hinder och problem ser ni att ni brottas med just nu? Skriv upp dem på en klisterlapp och sätt i ett fält på tavlan som ni kallar Hinder. Det är där ni samlar ämnen för era förbättringsmöten.

Fatta ett gruppbeslut: ska ni gå in i ett förbättringsmöte nu för att hantera något av problemen ni lyfte, eller kan sådant vänta till det obligatoriska förbättringsmötet efter månadsmötet?

Synkmötet

Metoden Scrum kallar det kvartslånga dagliga mötet för "Scrum". Metoden Puls kallar mötet för "Puls". Naturligtvis kallar jag det dagliga mötet för "Synk". För att det är just en synkronisering mellan människor det handlar om.

Många lean/agila metoder utgår från att man är organiserade i ett självstyrande arbetslag som delar på ett och samma flöde. Synk utgår inte från detta. Naturligtvis är det bra om vi kan forma sådana grupper, och ett skäl till att börja använda Synk är att man i framtiden kanske gärna bildar sådana grupper. Men Synk ska kunna användas närhelst folk behöver visualisera och synkronisera sina ärenden, även om de ännu inte hittat fram till ett samarbete om dem.

Reglerna för Synkmötena är hursomhelst ungefär desamma som för metodkusinernas: stående, framför flödestavlan, samma tid varje dag (utom på måndagar, för då är det planeringsmöte).

Inflöde

Många verksamheter har inte en central inkorg för alla ärenden. Istället kommer ärendena till en grupp människor genom meddelanden direkt till individerna. Till Synkmötet, eller helst innan, tar var och en med sig inkomna ärenden och sätter i Inkorgen. Dessutom föreskriver Synk att var och en lyfter inkomna ärenden när man går på lunch (passera förbi Synktavlan), och när man går för dagen.

I och med att man lyft ärendena till tavlan är det inte längre ens eget ärende. Det blir gruppens ansvar att hantera det, vilket är skönt. Det är annars en källa till mental överbelastning att vara ensam ansvarig för ett ärende. Skriv en förklarande rubrik på ärendet som identifierar det.

Förare, hjälpare, mottagare

Börja med att gå igenom de nyinkomna ärendena. För varje ärende ska det finnas en förare och en hjälpare från inom gruppen. Det vanliga är att den som kommit med ärendet blir förare, och att någon annan i gruppen erbjuder sig att bli medhjälpare. Det ska också finnas en mottagare av ärendet utanför gruppen, oftast den som inkommit med ärendet.

Om Lisa är förare, Hassan är hjälpare, och Li är mottagare skriver man överst på lappen "Lisa och Hassan till Li". Vill man spara tid på mötet har man gjort upp om detta på förhand och redan skrivit på sina lappar.

Gruppbeslut

Synk använder sig på sociokratiskt manér av beslut "utan avgörande invändningar". Närhelst gruppen ska fatta ett beslut om en fråga ska någon ställa frågan så att den kan besvaras med "Ja" eller "Nej". Sedan röstar man med handtecken: den som inte känner att beslutet spelar så stor roll gör inget tecken, den som vill besvara med "Ja" ger tummen upp, den som vill besvara med "Nej, det tycker jag inte men jag vill inte stoppa för er andra" ger tummen ner, och den som vill besvara med ett "Nej, det ska vi absolut inte göra" räcker upp handen (avgörande invändning).

Finns det en avgörande invändning ska de som har den avgörande invändningen argumentera för varför "Ja"-alternativet ska blockeras. De övriga får då argumentera emot invändarna, och ge sakliga skäl för varför man ska rösta "Ja" trots allt. Sedan tar man en ny omgång, och kvarstår de avgörande invändningarna är gruppens beslut "Nej".

Om de avgörande invändningarna är borta men det fortfarande finns "tumme ner" ska de som har gett "tumme ner" argumentera för varför de tycker det är en dålig idé. Sedan tar man en ny omgång där de som röstade tumme ner antingen lägger ner sin röst, röstar för, eller ger en avgörande invändning.

Akutärenden och sista-datum-ärenden

Synk använder de tre serviceklasserna från Kanbanmetoden: akutärenden (som ska ges högsta prioritet), normala ärenden som prioriteras mot varandra, samt ärenden med sista-datum som ska behandlas som normala ärenden utom om prognosen för dem visar att de riskerar att inte nå i mål på sitt sista-datum. Då ska de behandlas som akutärenden tills deras prognos är positiv igen.

Titta i väntekolumnerna (Inkorg, Prio, Redo, och Plan) efter akutärenden (rita en röd ram på varje akutärendes klisterlapp), eller sista-datum-ärenden (skriv sista-datumet i nedre högra hörnet). Akutärenden, och sista-datum-ärenden som riskerar att fallera, ska ges prioritet. Välj vad ni trycker undan för att sätta dem i en värdeskapande kolumn (Preparera, Utför, Verifiera).

Jobba från höger för vanliga ärenden

När de akuta ärendena är omhändertagna tittar man på ärendena i kolumnerna från höger: Kan vi påskynda mottagarens accepterande av ärendena i Acceptera? Hur ska vi hjälpas åt för att kunna Verifiera respektive Utföra ärendena? Hur ligger vi gentemot Plan? Dags att lyfta in mer från Redo, eller ska de Avvisas? Hur kan vi bli bättre på att Preparera färdigt? Stämmer vår Prio? Är det dags att ta in något nytt från Inkorgen?

Fokusera på att gå i mål.

Planeringsmötet i Synk

Planeringsmötet är ett stående möte varje måndag morgon framför tavelväggen. Det bör kunna klaras av på cirka en halvtimme om man parkerar många diskussioner till efterföljande lösningsmöten. Syftet med planeringsmötet är att justera prioriteringarna mellan ärenden, uppdatera planerna och schemat för veckan, och se över sina prognoser.

Från höger till vänster

Om det inte finns något akutärende någonstans som behöver beredas väg på tavlan, bör man gå från höger (nära slutet) till vänster. Fokus ska ligga på att avsluta ärenden, inte på att dra in nya i flödet. "Sluta börja och börja slutföra!" som vi säger.

Se över planen

• Finns det saker kvar i plankolumnen? Varför är de kvar? Var de dåligt förberedda och bör backa till Preparera? Dök vi på oförutsedda problem?
• Vad är veckans förväntade hastighet i veckoärenden per vecka? Innehåller planen fler ärenden än så? Backa överskottsärenden till Redo om de är redo, och till Preparera om de inte är det.
• Innehåller planen de viktigaste ärendena just nu? Byt ut ärenden mellan Plan och Redo och flytta om i Plan så att det viktigaste är överst. Fyll på med det viktigaste från Redo och ifrån projekten vid behov.
• Kolla prognosen. För varje ärende: markera (med blyerts, små klisterlappar, eller med magneter) vilken veckodag ni tror att ärendet ska påbörjas och vilken veckodag det troligen kommer att slutföras. Ser det fortfarande ut som en realistisk plan?

Blicka framåt

• Projekten som hänger under planeringstavlan är de viktigaste just nu. Ska ärenden därifrån hamna i Preparera? Ofullständiga veckoärenden som behöver göras färdiga? Skapa en klisterlapp och sätt i Prio. Onedbrutna månadsärenden eller större som behöver brytas ner? Skapa en klisterlapp och sätt i Prio.
• Vad är viktigast i Inkorgen just nu? Lyft till Prio.
• Kommer vi ha tid att lägga så mycket tid på preparering som det verkar? Hur är det med ärendena som redan är i Preparera? Är de viktigare än det som står i Prio? Ska ärenden backa från Preparera till Prio och läggas under någonting annat?
• Är ordningen på ärendena i Prio rätt? Står det viktigaste först?

Rensa

Ibland står vi med alldeles för mycket på tavlan. Ärenden är i Preparera, Utför, och Verifiera men har varit blockerade länge. Redo och Prio är fyllda med långt mycket mer än vi klarar av inom en rimlig tid. Det är dags att fatta tuffa beslut:

• Kan vi få mottagaren att verifiera åt oss? Dvs sätta i Acceptera och ta över ansvaret att kontrollera om vi levererat rätt?
• Ska vi flytta ärendena som är blockerade i Preparera och Utför till Avvisa eftersom vi inte verkar få fram information om dem?
• Eller ska vi sätta dem i Preparera för att bryta ner dem i ännu mindre delar där vi löser delmängder av problemen? Och skapa ett projekt av det ärende som kanske var för stort?

Alla förändringar i ärendena som vi gör (bryter om dem, planerar om dem, avvisar dem, omformulerar dem) kräver att vi tar en diskussion med mottagaren. Eftersom vi i Synk ser till att ärenden har en mottagare, och eftersom det för varje mottagare finns två ansvariga, så uppstår inga tveksamheter om vilka som behöver kontakta vem.

Trickfrågan för att ta reda på vem som är mottagare för ett ärende är att fråga vem som blir mest upprörd om vi struntar i det.

Mötena i Synk

För att få ner antalet improduktiva möten gör man i Synk som i många andra lean/agila metoder: håll nere antalet möten, och försök istället samla frågeställningarna till några olika korta möten som har varsitt fokus.

Grunden i Synk är veckopulsen. Måndag morgon börjar med planeringsmöte där planen för veckan läggs och prognoserna uppdateras. Varje morgon därefter kör man ett snabbt synkmöte där man följer upp planen och justerar den löpande. Varje fredag efter lunch gör man ett veckomöte där man ser vad som blev gjort under veckan (både färdigställda veckoärenden, månadsärenden, kvartalsärenden, och årsärenden), man samlar statistik, man följer upp pågående metodförbättringar, och man identifierar nya behov av att förbättra av metoden. Känns en sådan förbättringspunkt som viktig går man över i ett snabbt förbättringsmöte där man jobbar med PDCA på A3:or som gruppen samlar sina förbättringsinitiativ runt.

Annars kan förbättringen kanske vänta till månadsmötet som hålls sista fredagen varje månad, direkt efter veckomötet. På månadsmötet prioriterar man bland projekten, och justerar prognoserna för dessa. Månadsmötet går över i ett obligatoriskt förbättringsmöte där man diskuterar behoven av förbättring, prioriterar mellan behoven, utökar sin problemanalys, och kommer på nya motmedel mot förbättringshinder.

Dessa avslutningsmöten (veckomöten, månadsmöten, förbättringsmöten) ska inte ta längre tid än fredag eftermiddag. Men en gång per kvartal kan man dessutom hålla ett lite mer strategiskt kvartalsmöte där man firar uppnådda segrar och tittar på verksamhetens inriktning. Då kan avslutningen tillåtas att hålla på en hel dag.

Vart och ett av dessa möten förtjänar ett eget inlägg.

Ärendepreparering i Synk

Den generella agila metoden Synk bygger på att man har en kanbantavla i centrum. På tavlan är varje ärende representerad av en klisterlapp som sitter i någon av de fördefinierade kolumnerna. Varje kolumn är ett fält som motsvarar ett steg i flödet. Alla ärenden som är klara att utföras sitter i Redo-fältet, och för att hamna där måste de motsvara ett "redokriterium". Att preparera ett ärende är att få det att hamna i Redo-fältet.

Synk har ett generellt redokriterium för sina ärenden:

• Vem gör vi det för?
• Vad gör vi? En leverabel, en tillfälle, eller en aktivitet? Är acceptanskriterierna satta?
• Varför gör vi det? Vilka effektmål strävar vi efter hos mottagaren?
• Hur ska vi göra det? Finns det fortfarande utestående frågor?
• Storleken: Är det görbart inom en vecka för någon konstellation av oss som samarbetar runt den här tavlan?

Dessa frågor ställer vi runt varje ärende som vi drar från Inkorgen till Preparera-fältet på Planeringstavlan. Typiskt är att göra det på Planeringsmötet på måndagsmorgonen, men varje dagligt Synkmöte är ett tillfälle att göra detta på, om vi finner ett ärende i Inkorgen såpass viktigt att det behöver hanteras direkt.

Oavsett när det sker: i samma stund som vi drar ett ärende till Preparera ska vi bestämma vilka som ska preparera det, och när det ska ske.

Under själva prepareringen tar vi ett tomt liggande A4-papper. Det är vårt ärende. Vi skriver rubriken på ärendet, samma som på lappen som sitter på tavlan. På pappret försöker vi fånga Vem/Vad/Varför och Hur. Våra pågående ärenden sätts upp på väggen bredvid tavlan.

När vi fångat tillräckligt med information om ärendet frågar vi oss om någon konstellation av oss som samverkar runt tavlan kommer att kunna genomföra ärendet under en vecka (fem arbetsdagar). Om så är fallet så är ärendet redo och ska hamna i Redo-fältet. Om inte, så behöver det brytas ner.

Nedbrytning

Man börjar med en uppskattning av hur stort ärendet är. Är det praktiskt genomförbart under en vecka för oss sätter vi ett "W" i övre vänstra hörnet. Ryms det inom en månad sätter vi ett "M". Tar det upp till ett kvartal sätter vi "Q". Annars gissa vi på ett år: "Y".

Veckoärendena är färdignedbrutna, och om alla frågor är besvarade är de Redo. För ett månadsärende gäller att bryta ner i flera delmål. Kan vi hitta flera veckoärenden (det kan vara fler än fyra) som tillsammans uppfyller målet i månadsärendet? Skapa en A4 för varje sådant nytt veckoärende. De behöver inte vara fullständiga, bara tillräckligt ifyllda för att ge en uppskattning om vad som behöver göras. Förtydligandet kommer sen.

Se till att veckoärendena för ett månadsärende pekar ut sitt månadsärende. Samla A4:orna för de veckoärenden som hör till ett månadsärende och fäst dem i närheten av, eller på, varandra.

På samma sätt kan kvartalsärenden brytas ner i flera månadsärenden (kan vara fler än tre) och årsärenden i kvartalsärenden (kan vara fler än fyra). Kom ihåg att man som sagt inte behöver beskriva dessa fullständigt. Varje ärende större än ett veckoärende kallar vi för ett "Projekt".

Man behöver inte heller bryta ner varje ärende hela vägen till veckoärenden direkt om man inte vill. De måste vara nedbrutna till förtydligade veckomål för att vara "Redo" (japp, det är bara veckoärenden som är på tavlan från och med Redo och framåt). Men om man stöter på ett års-, kvartals- eller månadsärende som vid närmare eftertanke inte är så prioriterat (kanske för att man ser att det är så stort) så behöver man inte bryta ner ytterligare förrän man snart ska utföra dem.

Ihopsamling

Små och enkla veckoärenden behöver inte någon egen A4. Där räcker det med en klisterlapp för varje veckoärende. Är det flera relaterade ärenden kan man skapa ett månadsärende att sätta dem på så att de inte tar upp plats på själva tavlan om det dröjer innan vi ska utföra dem.

Även enkla, ofta återkommande, veckoärenden som faller inom samma kategori kan man samla i ett övergripande kategoriärende. Sätt ingen storlek ("W", "M", "Q", "Y") på kategoriärendet. Placera inte veckoärendena på tavlan förrän det börjar dra ihop sig att utföra dem.

Förtydligande

När en klisterlapp hamnar i Preparera-fältet kan den alltså resultera i flera A4:or som täcker både stora och små ärenden, som kanske inte ska utföras direkt. A4;orna sätts upp bredvid tavlan (eller hamnar i ett pappersfack). Då bör man ta bort lappen från Preparera och sätta på ärendet så att lappen inte tar upp plats på tavlan. Tavlan är till för att vi ska ha fokus.

Om det däremot är ett ärende som vi har beslutat ska börja genomföras direkt tar vi inte bort lappen ur Preparera. Istället skapar vi A4:or, bryter ner, väljer ut det viktigaste delärendet, bryter ner det, osv, hela vägen till veckomål för det viktigaste månadsmålet. Dessa veckomål förtydligar vi tills deras A4;or är helt Redo.

Om vi beslutar att vi ska utföra dessa veckomål inom de närmaste veckorna skapar vi varsin klisterlapp och sätter i Redo-fältet. Deras respektive A4:or (tillsammans med deras övergripande månadsärende) sätts upp nedanför Planerings-tavlan, längst till höger. Nu har vi brutit ner, nu är vi klara att köra.

Ständig process

Denna ärendepreparering är ständigt pågående. Varje måndagsplanering ser man över både vad som ska tas från Redo in i Plan, men också vad som behöver tas till Redo från antingen Preparera-fältet eller från de större ärendena utanför tavlan ("Projekten").

Synktavlan

Sedan mina kanbantavlor konvergerat genom åren, och oavsett vilken process de stött så småningom fått samma utseende, så bestämde jag mig för att ha det utseendet som utgångspunkt när jag beskrev Synk (en generell agil metod). Så här är då SYNK-tavlan!

Tre tavlor

Synk hanterar de tre stegen planering, genomförande, och avlämning. Vart och ett av de tre stegen har sin egen tavla, eller sin egen del av en större tavla.

Planering

På planeringstavlan finns kolumnerna Inkorg, Prio, Preparera, och Avvisa.

Inkorg - Denna kolumn har man ingen kontroll över. Här hamnar allt som är nytt, alla önskemål på saker som ska göras, alla problem någon antar att ni är ansvariga för osv. För att kunna hantera allt arbete behöver det hamna i en inkorg.

Prio - Vi är en trång resurs, en begränsande faktor, en flaskhals. Därför behöver vi prioritera. Det värdeskapande arbetet här består i att ur Inkorg ta viktiga saker som det är dags att börja titta på.

Preparera - För varje ärende i Prio ställer vi oss några frågor:

• Vet vi för vem vi gör det?
• Vet vi vad vi ska leverera? En leverabel eller ett tillfälle eller bara en aktivitet?
• Är acceptanskriterierna satta för leverabeln eller tillfället eller aktiviteten?
• Vet vi varför vi ska göra det (vilken effekt det antas ha hos mottagaren)?
• Vet vi hur vi ska göra eller finns det fortfarande utestående frågor?
• Är det görbart inom en vecka för någon konstellation av oss som samarbetar runt den här tavlan?

Är svaret på någon av dessa frågor "Nej" så hamnar ärendet i Preparera. Synk beskriver olika strategier för att få fram svaren på frågorna och för att bryta ner större ärenden i mindre.

Avvisa - Här hamnar sånt som inte kan preparera, eller som vi inte vill preparera, eller som vi inte vill göra, eller sånt som vi inte hinner med när vi har prioriterat den viktigaste delen av In. Det är en viktig del av arbetet att hantera avvisningarna direkt så att folk inte väntar på att få något utfört som inte kommer att bli av. Signallera tidigt om något inte kommer att bli gjort.

Genomförande

På genomförandetavlan finns kolumnerna: Redo, Plan, Utför, Verifiera.

Redo - Detta är genomförandetavlans inkorg. Den har vi inte heller kontroll över. Ingen vet hur snabbt det kommer in viktiga saker, eller hur snabbt prepareringen går. Däremot kan man arbeta med att begränsa storleken på Redokolumnen för att inte få den fylld med viktiga saker som vi ändå inte har tid med att göra.

Plan - Detta är genomförandetavlans priokolumn. Här sätter vi upp de saker som vi vill göra, i den ordning vi tänkt oss göra den. Här kan man göra en prognos för vilken veckodag de olika ärendena blir färdiga. Synk försöker hålla planeringen på den här nivån till max en vecka bort.

Utför - Här hamnar ärendena när vi utför dem. Vi drar inte till oss mer än vi klarar av.

Verifiera - När saker är utförda ska vi verifiera att de är rätt gjorda. Observera att detta är vår egen verifikation att vi inte gjort fel. Det är inte att mottagaren berättar det för oss.

Avlämning

Avlämningstavlan har bara två kolumner: Acceptera och Klar. Resten av tavlan används till statistik och förbättringshantering.

Acceptera - När vi verifierat ett ärende är det dags att få mottagarens acceptans på det genomförda. Vi ska ju inte gå in i genomförande utan att ha acceptanskriterierna klara för oss. Det här steget har vi för att följa upp att mottagaren har tagit emot så att vi kan släppa ärendet.

Klart - När mottagaren har accepterat ärendet sätts det i denna kolumn. Här får ärendet hänga kvar tills att vi summerar på veckomötet (fredag lunch).

Dessa tavlor (eller taveldelar) används i Synk för att hantera ärendeflödet under en vecka.

Agil förändringsledning

Efter att ha stoppat tårna i ett antal lite större agila förändringsprojekt tänkte jag dela med mig litegrann av några iakttagelser. Jag tänkte att jag skulle berätta om dem, och för att ge något slags teoretiskt ramverk runt iakttagelserna placerar jag dem i Kotters 8-stegsmodell för förändringsledning. Kotters modell är både genomförbar (ja, den funkar) och i linje med beteendeveteskaplig forskning (validerad). Det är när man tillämpar den med lean/agila glasögon som vissa intressanta saker blir uppenbara, och dem tänkte jag berätta lite om.

1. Liknöjdheten

Det första och största hindret mot en förändring, det som Kotter utnämner till Misstag Nummer Ett i sin modell, är liknöjdheten. Vi människor är konservativa av naturen. Att konservera betyder att bevara, och eftersom vi är skapta för ett liv på savannen där man i perioder verkligen måste bevara alla resurser för att kunna överleva, så undviker vi gärna förändring. Att byta beteende kräver t ex rent fysiskt mer kolhydrater, eftersom vi måste koppla in vår stora logiska människohjärna i högre grad än när vi agerar per automatik. Särskilt jobbigt är det för oss att behöva byta sociala förhållanden, t ex att interagera på nya sätt med nya grupper och kanske till och med ändra i maktförhållandena inom gruppen! Sådant tär på resurserna. Tär fysiskt.

Nu innebär alla organisationsförändringar av värde att vi faktiskt ändrar allt det här. Till våra hjärnors fasa. Bränna all denna dyrbara energi?

Den smärtan gör att våra hjärnor gärna går mycket långt för att undvika att för oss själva erkänna behovet av en förändring. Är vi underställda alla andra är vi vana vid att allt som utmanar ledarskiktet och den rådande ordningen riskerar att slå tillbaks på oss själva. Är vi överordnade vill vi ju absolut inte tänka oss att steppa ner från den positionen. Har vi precis genomskådat mekanismerna i organisationen och gjort oss beredda att klättra i den vill vi ju verkligen inte att reglerna plötsligt ska ändras. Plus att förändring är jobbigt och människohjärnan är ofta lat. Allt detta gör att vi får en individuell ovilja mot förändringar.

När vi människor agerar i grupp blir vi dessutom ofta dummare än som individer. Gruppbeslut bygger på gruppkommunikation, och det är svårt för andra analyser än de allra enklaste att slå igenom. Har vi som individer en ovilja mot förändring söker vi gärna bekräftelse hos varandra. I en organisation där vi alla funnit en plats kommer frestelsen att inför varandra bekräfta värdet av inte rucka på något att vara stor. Särskilt i ett företag där vi lever på forna segrar, eller om vi jobbar på en myndighet som oavsett hur bra vi leverar alltid kommer att vara kvar. Bägge dessa har jag sett på mer än ett ställe. Sammantaget blir effekten att känslan av angelägenhet blir alldeles för liten. Varför förändra? Dumheter! Vi som har det så bra!

Det är denna brist på angelägenhet (urgency), detta överflöd av liknöjdhet (complacency) som Kotter utnämner som det första man måste jobba på. Förstås. Om det inte finns skäl att flytta sin rumpa från läge A till läge B, varför ska man göra det? Nu har Kotter lite ideer om hur man väcker organisationen. Till exempel funderar han på hur en ledning kan väcka organisationen genom att sätta en massa nästintill omöjliga mål. Eller hur man skapar en kris och låter den träffa organisationen, även om det kostar en massa pengar. Eller låta organisationen möta riktiga data lite oftare, till exempel få veta att kunderna eller medborgarna inte är helnöjda till exempel.

Har man lean/agil-glasögonen på sig så är man oerhört negativ till den första strategin: nästintill omöjliga mål. Effekten blir alldeles för ofta den som Deming varnade för: eftersom utfallet till 95% beror på systemet mer än individen riskerar sådana incitament mer att sporra individer att börja fuska för att för egen del klara av målen. Även till priset av en organisation som faller isär. Även den andra strategin är väldigt tveksam. Transparensen i en äkta kris är visserligen bra, men det blir en otrygg miljö av att det är verkliga värden som går förlorade. Folk kommer att må dåligt och göra varandra illa.

Istället har vi två verktyg i vår låda. Det häftigaste verktyget är ständig förbättring. I princip går det ut på att man i ett arbetslag är tränad att se skillnad på var man är idag och vad man vill bli. Man ställer sig, på ett analytiskt sätt, frågan varför man inte är halvvägs till det man vill bli redan. Sedan genomför man strukturerade experiment för att försöka hitta metoden att stänga detta gap. Ständig förbättring brukar man inte kunna uppnå med en gång. Det gäller att organisationen vill träna sig i det tänkandet.

På väg till ständig förbättring har vi ett annat verktyg, ett som fungerar oavsett mognad: transparens. Det är egentligen flera verktyg, men de har det gemensamt att det utsätter oss för verkligheten mer än vanligt. Alltså den tredje metoden Kotter föreslår.

Vi agilister/leanmänniskor behöver inte varken konstruera kriser eller sätta "inspirerande" halvt omöjliga mål. Det räcker med att hitta de där jobbiga bilderna av verkligheten som visar oss att vi inte är bäst i världen. Att här finns problem värda att ta tag i. Det kan vara flödestavlor som visar på stora flaskhalsar i värdeskapandet. Det kan vara uppmätta omloppstider för hur lång tid det tar för ett värdeskapande ärende att bli förverkligat. Eller så kan det vara en jobbig aggregerad lista över alla avvikelser och defekter som faktiskt finns. Vi agilister har en rätt stor uppsättning av dessa verktyg, eftersom folk i den här världen har insett i flera årtionden att ökad transparens är den enskilt viktigaste faktorn för ökad smidighet.

Transparensverktygen är nu inte så enkla som de låter. Som jag förklarade innan kan hjärnan lägga ner en massa energi på att inte behöva förändra ett nuläge, och denna tendens förstärks när människor agerar i grupp. Hjärnan kan till och med *vägra* att se sanningen i vitögat, och i grupp kan människor få för sig att lägga skulden på den som kommit med de dåliga nyheterna snarare än att acceptera problemen. Folk tror att det är maktskiftena i lean och agilt som är de stora förändrarna, men dessa kommer på andra plats. Det är den ökade transparensen som först och främst både skapar angelägenhet att röra sig bort från status quo och ger vägledning om hur. Detta har även Kotter sett, och placerar alltså brist på angelägenhet som första punkten i sin modell.

Principen om Säkerhet

Här följer ytterligare ett utdrag ur boken Smidigt! - Agila metoder för en vanlig arbetsplats: stycket om "Säkerhet" från ett kapitel som räknar upp viktiga ledord. Stycket om säkerhet följer direkt på stycket om enkelhet som handlar om att förenkla och ta bort onödigheter.

Principen om enkelhet är förrädisk. En alldeles för ytlig syn på vad som är värdeskapande skapar ibland en destruktiv "spill"-jakt där värdefulla arbetsmoment (som t ex små pauser) tas bort eftersom värdena av dem är osynliga. Det är då som *"lean"* övergår i *"mean"*.

Det är t ex sant att onödig väntan är ett spill, och att det ökar omloppstiden för ett ärende genom hela värdeflödet. Ökade omloppstider tillsammans med kravet att ha mycket på agendan skapar många påbörjade ärenden, vilket driver upp komplexiteten i arbete vilket ökar risken för fel vilket också är en stor spillkälla.

Den ytliga betraktaren ser bara de långa omloppstiderna och drar slutsatsen att det jobbas för dåligt. Den ytliga betraktaren säger: "Öka takten!" Därmed förvärras problemen. Systemsyn lär oss att omloppstiderna beror på orsaker. Ska omloppstiden ner måste orsakerna åtgärdas. En orsak är kravet att ha många saker på agendan samtidigt. För många ärenden påbörjas, och alldeles för få avslutas. Människorna har blivit *överlastade*, den spillkälla som på japanska kallas *"muri"*. Fel uppstår. Folk mår inte bra. Vi får ett osäkert och bräckligt värdeflöde.

Säkerhet handlar om att ha god kvalitet på sina procedurer. Ett sk kanbansystem kan se till att inget steg i flödet blir överlastat. Tydliga regler för hur man arbetar inom ett steg och vad som krävs av det man lämnar ifrån sig minskar felen. Välkända larmvillkor gör att alla vet när processen måste nödstoppas (*"andon"*, *"jidoka"*), vilket ökar allas trygghet och minskar behovet av övervakning. Allt detta bidrar till att hålla ner omloppstiderna och minska spillet, vilket driver upp produktiviteten.

Det finns alltså ingen motsättning mellan hög produktivitet och kvalitet och säkerhet. Det vi lärt oss genom de smidiga teknikerna är att varje produktivitetsvinst som uppkommer genom att man försöker hetsa och fuska med kvalitets- och säkerhetsprocedurer är kortsiktig, och i förlängningen ofta resulterar i haverier. I kunskapsarbete finns många starka indikatorer på en osäkerhet i processerna: en känsla av otillräcklighet, plötsligt påkommen övertid, stress, många samtidiga ärenden och svällande inkorgar. Det är viktiga larmsignaler som man måste ta på allvar. I Scrum pratar man om "uthållig fart": hur blir det om vi fortsätter på det här sättet? Håller det? Håller vi?

Värdekarta

När en organisation har lagt ner en massa möda på att implementera olika leantekniker men man känner att det inte har hjälpt på något avgörande sätt, så är det ofta för att organisationen har tillämpat teknikerna på alldeles fel saker. De har inte lyckats hitta och förbättra värdeflödet.

Kontorslean är ett vanligt exempel. Du kommer till ett kontor där det sitter lappar på alla rum om städningsintervall (standardized work, visual management), folk får inte lov att ha mer än ett (1) foto på barnen på skrivbordet samtidigt, eller fler än en blyertspenna och bläckpenna i omlopp på samma gång (5 S, 1x1 Flow), och kopiatorn är placerad i ett rum i mitten av kontoret så att alla ska nå den med så få steg som möjligt (reduce motion, reduce transportation) osv osv.

Visst, kontorsarbetet har i vissa avseenden blivit lättare eftersom du inte behöver gå så långt för att komma till kopiatorn. Men också tråkigare, för du vill ha många bilder på familjen och du vill sitta och leka med en Hello Kitty-penna (som är helt oduglig att skriva med) när du tänker. Dessutom är du arg eftersom den här lean-skiten har tryckts ner i halsen på dig av någon annan, nån som inte begriper vad ni gör på det här kontoret, för själva tänkandet har inte blivt bättre!

Grundproblemet här är att den som bestämt om de nya arbetssätten inte har lyckats se hur kontoret skapar värde. Man har förbättrat flödet av pennor och kopierade papper, men inte flödet av tankar och beslut. Det är en ganska vanlig miss när den som skulle hjälpa till med lean på kontoret kommer från tillverkningsindustrin. Där är värdeflödena är ganska enkla: en huvudprocess som tillverkar en mojäng, och så lite stödprocesser för att förse huvudprocessen med material och människor. Men hur skapas värdena på kontoret?

Man måste alltid göra en värdekarta när man inför någon leanteknik, en bild av hur värdena skapas. Annars riskerar man att tillämpa rätt tekniker på fel flöde. Det är dessutom bra om det är folk nära golvet som kartlägger, i synnerhet på ett kontor där värdeflödena är komplexa och diffusa. Så hur gör man om man ska rita en värdekarta för en avdelning på ett kontor?

Ett sätt är att jobba i två steg. Kontorsarbeten har tyvärr ofta ganska många individuella moment (ökar risker och belastning och behovet av överlämningar). Därför kan man behöva börja med att varje individ gör sin egen karta (fast gärna i samarbete). Sedan, i steg två, försöker man tillsammans skapa en gemensam bild, på ungefär samma sätt som var och en redan har gjort för sig själv.

Oavsett hur stor kartläggningen är så jobbar man på samma sätt: man börjar bakifrån. Det handlar om att skapa värde (så som en yttre mottagare har definierat värde), så allt måste utgå från det som mottagaren får. Är det en produkt? Ett beslut? En behandling? Taiichi Ohno sa: Allt vi gör är att titta på vad det är som gör kunden nöjd. Sedan försöker vi ta bort så mycket tid och arbete och material som möjligt för att nå dit.

Så vilka är produkterna och vilka är mottagarna? En ledningsgrupp kanske levererar stöd, beslut och interventioner åt personalen och processer för relevant styrdata åt sina överordnade (precis som varje enskild avdelningschef gör). En utredningsavdelning levererar utredningar av olika storlekar, men också offerter och uppskattningar runt framtida utredningar. Lagerarbetare levererar mottagning, lagring, hittande, utrensning osv. Systemutvecklare levererar ny funktionalitet, offert på ny funktionalitet, och felkorrigering i befintlig funktionalitet. Vad levererar ni?

När man vet vad som ska uppnås börjar man gå baklänges genom systemet. Vad gör vi för att nå målet? Vilka är delmålen på vägen? Vad gör vi för att nå delmålen? Genom att vi hela tiden fråga oss "Vad krävs för att nå hit?" tecknar vi bilden av ett dragande system. Mottagaren vill dra en leverans av oss, och då blir vi tvungna att dra till oss information, omvandlande arbete osv i steg. Till slut når vi fram till en yttre gräns av inleveranser från andra personer, inleveranser som på ett kontor ofta består av information i form av fakta och tyckande. Hur ser informationsbehovet ut för varje ärende?

Fokus ska vara på leveransen, och inte på arbetet. Du levererar inte programmering utan ett färdigt system. Du levererar inte utredningsarbete utan den färdiga utredningen. Fokus ska inte heller ligga på vem som gör vad i det här skedet, även om ni bör notera det. Nu har ni en bild av hur ni likt en växt med rötter suger åt er "material" (fysiska saker men också informationsbitar), och i olika steg transformerar det till en "frukt", något som mottagaren blir glad av.

Märk att det här "materialflödet" ni precis har ritat upp motsvaras av ett informationsflöde som går åt andra hållet. Materialflödet i slutet av händelsekedjan, när mottagaren får sin leverans, motsvaras av ett informationsflöde på samma plats fast i motsatt riktning och i början: beställningen. Detsamma gäller för varje annan punkt i bilden: där sker ett flöde av "material" från vänster till höger men bara som ett svar på en förfrågan från höger till vänster. Vi ska inte göra så mycket mer med det här nu, men det är en viktig insikt. En av de grundläggande insikterna inom smidiga arbetssätt är att trögheter i materialflödet ofta beror på trögheter i informationsflödet åt andra hållet. Vi släpper det nu, men kommer att återvända till det.

När ni har skapat den gemensamma bilden kommer ni att se vilka samverkanspunkter med varandra och med andra som finns. Ett sätt man kan gå vidare är att skilja mellan yttre och inre samarbeten och jobba med tydliga gränssnitt för de yttre samarbetena, och med tät samverkan ("svärmning") för de inre. Men också det är en övning för sedan.

En annan informationsbit som kartan kan ge er är var och när det faktiska värdet skapas. Det är genom att reflektera över kartan man kan hitta ställen där ärenden blockeras, går fel, utsätts för onödigt mycket arbete osv. Inom industrin är detta bland de viktigaste informationsbitarna: att värdekartan används för att hitta spill. När folk med industribakgrund hjälper informationsarbetare på kontor med kartläggning blir det därför ofta den här aspekten man tittar extra mycket på. Men på kontoret är det i allmänhet viktigare att först fokusera på mängden med värdeflöden (för de är ofta fler än på verkstadsgolvet), på informationsbehovet, och på samverkanspunkterna. Det är ju då som den dolda komplexiteten i kontorsarbetet blir synlig.

Den här kartan bör aldrig bli färdig utan vara en del av er grupps kontinuerliga arbetsdokument. När ni hittar spillkällor i flödena och tar bort dem så kommer kartan att behöva ritas om. Använd kartan som en ständig avbild av er process, så att ni kan använda kartan som ett verktyg i er ständiga förbättring.

Samlingsinlägg: studier

Lite referenser till studier. Fylls på efterhand.

Referenserna om TPN och DMN längst ner.

Against multitasking Stanford 2009. Article.

Om ingrupper och utgrupper hos barn, och genetiskt överförbara svårigheter att hantera gruppdynamik: In-Groups and Out-Groups

Om hur subjektiva bedömningar och därtill hörande känslor motsvaras av aktivitetsmönster i OFC: popvetartikel, Chikazoe et al 2014

Smidiga saker

Jag håller ju på att skriva en liten bok som heter "Smidigt - Agila arbetssätt för en vanlig arbetsplats". Den innehåller ett antal smidiga tekniker lånade från agil systemutveckling och från lean, men beskrivna på ett sånt sätt att de går att tillämpa i många sorters arbeten.

Några av teknikerna hänger intimt samman med varandra, nästan som ett metodramverk. Jag tänkte att jag skulle beskriva lite av det i en post. Så bort med engelskan och bort med systemutvecklingen: nu ska jag berätta om smidiga arbetssätt.

Laget

För att öka värdeskapandet och minska risker och negativ stress försöker man att samarbeta om en värdeström (=saker som gör en mottagare glad) i arbetslag om upp till 8-9 personer. Alla i laget har inte samma kunskaper och färdigheter, och kommer därför aldrig att kunna göra varandras arbetsuppgifter fullt ut, men man försöker så långt det är möjligt att samarbeta.

Laget är självorganiserade, dvs de bestämmer själva (inom givna ramar) hur arbetet ska bedrivas, men de är inte självstyrande eftersom det handlar om att betjäna en mottagares intressen. Vad som ska göras kommer i slutändan alltid att bli givet utifrån.

Inkorgen

Det vanliga är att arbetsuppgifter flödar in över människor på ett lite okontrollerat sätt. Det viktigaste för att få smidighet på arbetet är att varje arbetslag centraliserar sin inkorg. Kanalerna in till laget kan fortfarande vara flera och till och med gå via olika individer i laget; men därifrån måste ärendena samlas på ett och samma ställe så att man kan ha kontroll över dem.

Förfining

En värdeström har en början och ett slut. När ärenden kommer in i lagets del av värdeströmmen är de troligen inte tillräckligt väldefinierade för att man ska kunna börja jobba med dem, de har troligen inte ett väldefinierat slutmål beskrivna så precist så att man kan otvetydigt avgöra om ärendet är klart, och vi vet förmodligen inte hurpass stora de är. Varje ärende måste göras startklart så att:

• inga avgörande frågor är obesvarade,
• vi vet hur vi ska kunna testa om ärendet är färdigt,
• vi vet någorlunda om det kan göras färdigt inom en dag, en vecka, en månad, ett kvartal, eller längre än så.

Att föra ärendet till att bli startklart kallas för förfining och utförs av hela eller delar av laget vid behov. Det är vanligt att laget skapar en veckorytm där särskilda tillfällen viks åt förfiningsarbete.

Tidsramning

Att skaffa sig en idé om hur stort ett mål är, det krävs för att kunna planera men också för att kunna förfina det till rätt nivå. Därför måste man se vilken tidsram som gäller för varje ärende. Ärendet måste tidsramas. Observera att detta inte är detsamma som en tidsuppskattning där man (mycket osäkert) gissar hur lång tid saker tar för att bli färdiga. Istället gör man en grovskattning om vilka tidsramar som krävs:

• Är det här klart inom en dag? Då är det ett dagsmål (D).
• Om inte: klarar vi av detta inom fem dagar? Då är det ett veckomål (W).
• Om inte: klarar vi av detta inom fyra veckor? Då är det ett månadsmål (M).
• Om inte: klarar vi av detta inom tre månader? Då är det ett kvartalsmål (Q).
• Om inte: klarar vi av detta inom fyra kvartal? Då är det ett årsmål (Y).

Så man bör sikta på att kunna uppnå flera dagsmål på en dag, flera veckomål på en vecka, flera månadsmål på en månad, flera kvartalsmål på ett kvartal, och flera årsmål på ett år.

Nedbrytning

Även årslånga projekt utförs i dagsetapper. Årsprojekt bör brytas ner i månadsmål, månadsmål i veckomål, och veckomål i dagsmål. Så snart man har förfinat ett ärende och antagit att ärendet tar en vecka eller mer, måste man bryta ner det i delmål. Delmålen blir egna ärenden som först är oförfinade och sedan startklara. Är de nedbrutna ärendena större än dagsmål bryter man ner dem ytterligare ett steg osv.

Prioritering

Det troliga är att lagets arbete är en flaskhals i värdeströmmen, dvs att det finns fler önskemål om att de ska utföra värdeskapande ärenden än vad de hinner med att utföra. Det betyder att prioritering blir viktigt: vad är det vi inte ska göra?

Prioriteringen äger alltid rum inom en struktur som är större än laget. Det kan hända att laget är betrott att prioritera helt själva, men det sker ändå på delegation från någon yttre intressent. Om inte annat så sker det på delegation från en kund. Hur prioriteringen sker, om det är en prioriteringschef som griper in, om det är en utsedd styrgrupp som fattar besluten, om laget prioriterar enligt vissa på förhand uppsatta regler; det spelar ingen roll. Det viktiga är att den är tydlig och att den sker direkt vid behov.

Det finns många ställen som ska prioriteras: I vilken ordning ska ärendena i inkorgen förfinas, i vilken ordning ska de förfinade ärendena utföras, och i vilken ordning ska vi sedan testa av att de är korrekt utförda? Utan prioritering kan vi inte arbeta. Därför måste laget sätta krav på sin omgivande organisation, särskilt ledningsfunktionerna, för att få till en vettig prioritering.

Akutärenden

Akutärenden är specialfall som tillåts köra över all prioritering och alltid gå först. De måste ändå igenom hela kedjan: förfining, tidsramning, nedbrytning, ytterligare förfining osv.

Prognosmakande

Ett veckomål tar inte precis en vecka för laget, och ett dagsmål tar inte precis en dag. Beroende på omständigheter kan man klara av flera dagsmål på en dag, eller sitta en vecka med ett dagsmål. Det spelar ingen roll. Det intressanta är att laget i genomsnitt kommer att klara av ett visst antal dagsmål på en vecka. Det är veckorytmens hastighet. På samma sätt kommer laget att klara av ett visst antal veckomål på en månad, och ett visst antal månadsmål per kvartal.

Det betyder att vi kan titta på ett ärende och givet dess förhållande till andra ärenden få en idé om när i tiden ärendet kommer att bli färdigt. Erfarenheten visar att precisionen man får i prognoserna är mycket bättre om man på detta sätt mäter ärendenas hastighet och baserar gissningarna på detta data. Dock kommer akutärenden alltid att kunna slå sönder dessa planer.

Fasta datum

Alla ärenden kan ges datum i form av prognoser: givet den här hastigheten och prioriteringen, så kommer detta ärende att vara färdigt vid en viss tidpunkt. Ett ärende som har ett fast datum, en deadline är något annat: ett datum som måste hållas. Det betyder att ärendet ges rätt att, precis som akutärendet, slå sönder den övriga prioriteringen. Skillnaden mellan akutärenden och ärenden med fasta datum är att de fasta datumen bara slår sönder prioriteringen om det fasta datumet är hotat.

Bokslut

Efter varje vecka samlar laget ihop de färdiga dagsmålen. Man

• Räknar hur många icke-akuta ärenden man gjort färdigt, dvs lagets hastighet.
• Ser hur många persondagar veckan innehöll (normalarbetstiden minus frånvaron).
• Räknar hur många procents övertid man lade (bör vara noll).
• Uppskattar hur många procent av tiden (tioprocentsintervall per person räcker) som varje ärende tog, både akuta och icke-akuta.

Dessa enkla siffror kan ge enormt stor planeringskapacitet och förmåga till budgetuppföljning och information till hur man ska kunna förbättra verksamheten.

Liknande bokslut kan göras efter varje månad, kvartal, och år.

Flödestavla

Det är smart att samla alla ärenden på en tavla. Ett exempel på en tavla har en rad för varje horisont (vecka för alla dagsmålen, månad för alla veckomålen, och kvartal för alla månadsmålen). I varje rad finns kolumnerna ospec, startklar, prio, utförs, verifieras, klart. Vem som jobbar med vad synliggörs med personliga magneter (begränsa antalet per person). Tavlan brukar dessutom innehålla inkorgen samt den första priolistan, och lite annat som behövs.

Metodvägg

Laget skriver ner sitt arbetssätt, t ex noteringar om när de olika mötena hålls osv, i enkla punkter att sätta upp på väggen. Att göra sitt arbetssätt uttalat och synligt gör det lättare att ta ansvar för det.

Tjänstekatalog

Ett av de viktigaste dokumenten på metodtavlan är den som presenterar lagets tjänstekatalog, en beskrivning av varje tjänst som de utför för sin omgivning. I det dokumentet skriver man upp vad som krävs av en beställing av varje sort, hur man kan vänta sig att den behandlas osv.

Förbättringsmöte

För att kunna ta ansvar för sitt eget arbetssätt och förbättra sin metod har laget med jämna mellanrum förbättringsmöten. Där ser man vad nästa delmål i processförbättringen skulle kunna vara, man gör en rotorsaksanalys för att se vad det beror på att man inte redan är där, och man beskriver ett nytt experimentellt arbetssätt som förmodas kunna avhjälpa bristen. Laget beslutar om att genomföra experimentet under en period och bokar upp en uppföljning där man beslutar om den experimentella förändringen ska permanentas (och metodväggen uppdateras).

Förbättringstavla

Förslagsvis använder man A3-analys för att arbeta med förbättringen. Sätt upp A3-orna på en förbättringsvägg. Läs på om och träna på A3-analys och Toyota Kata för att få mer konkreta tips på hur man kan följa upp sin förbättring.

Synkmöte

En gång om dagen brukar laget samlas till ett kort (max 15 minuter) synkmöte stående framför flödestavlan, där man stämmer av hur det har gått hitills och hur man behöver hantera det. På synkmötet hanterar man uppkomna svårigheter och ändrade prioriteringar, och man ser hur man behöver fördela sin tid mellan utförande, verifiering, prioritering, förbättring, förfining och nedbrytning. Synken är bland de viktigaste mötena man har, och det ersätter många andra möten.

Sammanfattning

I princip så ser ramverket ut. Ni som arbetat med Scrum, Scrumban, Kanban, förbättringsmöten i lean osv känner igen er. Skillnaden mot Scrum är bl a att jag rekommenderar en flödestavla som kan hantera flera rytmer (inte bara en enda sprintrytm), att flödet uppdateras löpande (ingen nollställd tavla), att jag inte pekar ut en explicit metodcoach (motsvarande en "Scrum Master") eftersom tanken är att laget tar ansvar för detta, och att jag inte pekar ut en explicit prioriteringsperson (en "Product Owner") eftersom jag ser att det snarare är en funktion än en roll, en funktion som kan behöva täckas av flera roller och personer i en organisation.

Många som haft mig som agil coach känner igen delarna, för det är de här teknikerna jag brukar ta till för att hjälpa lag att hantera t ex polyrytmiska flöden, planerings- och prognossvårigheter, eller frånvaro av prioriteringar.

Jag är också rätt explicit med vilka tekniker jag tycker att folk ska använda (treskiktad flödestavla, Toyota Kata och A3, metodvägg etc). Därmed inte sagt att man måste. Det här är en startpunktsmetod: börja så här. Sedan använder man förbättringsmötena för att skapa något ännu bättre av det.

The position for a Scrum Master is open!

(Another attempt to blog in English, since this is a commentary to this post by Henrik Berglund.)

Position now open. But what is the proper position for a Scrum Master then?

According to the very definition of Scrum: the Scrum guide, the role of the Scrum Master is to make Scrum understood and enacted. As a Scrum Master, you don't have any formal authority to do so, so you have to resort to helping others understand their parts. The guide talks about understanding and helping others to understand.

In that sense, the position of the Scrum Master (or a similar coach-like servant leader when other frameworks than Scrum is being used) is always needed. Just as Henrik points out: we are never fully learned. And still I think that it is a worthy target for a Scrum Master to try to make herself unneeded. Or rather: her current position unneeded.

I look upon it as an instance of situational leadership. While the overarching goals remains (developing high value through optimizing flow and value generation), the actual job description have to change continously. In an organization involved in some kind of agile transformation, things change with time:

Knowledge of the framework change: When you start out with Scrum or Kanban or some other approach, people will need a lot of hand holding. The Scrum Master will need to facilitate the events by booking them and even leading them to begin with. With time, people will learn to manage these themselves, if the Scrum Master helps them take that responsibility. While the Scrum Master exists to make Scrum happen, Scrum isn't supposed to die when the Scrum Master is away.

The team matures with time: The dynamics of the group evolves with time. Bruce Tuckman noticed that the maturity of the team can be measured by its ability to reach good collective agreement. As Wikipedia states it:

These high-performing teams can function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision. By this time, they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decision-making process without supervision. Dissent is expected and allowed as long as it is channeled through means acceptable to the team.

Helping them to reach there and remain there is a constant responsibility of a team coach. Exactly how it is done varies greatly, and a lot of the things the team need help with in earlier stages of their development, they will be able to take on themselves. In this sense, it is good for a Scrum Master to make herself unneeded.

The organisation matures with time: Here is where I see that the job of a Scrum Master / agile coach might be a transitional phase in an organisation's development. If you start Scrum in a hostile environment, fx an organisation where certain fundamental truths about software development isn't regarded properly, a lot of energy needs to be spent on protecting the team from bad management decisions. You will create some agile bubbles by fending off too heavy and/or too vague work items being pushed; and try to minimize the impact of bad incentives and other mangagement dysfunctions.

But that will probably change with time. When we use visual management to become good at showing the impact of bad decisions, the decisions will be better. When more people in the organisation becomes aware of the fundamental psychological and mathematical truths that every member of the lean family (of which agile is one) is built upon, the management will no longer stand in the way for team development.

And when that happens, why can't the management take on the coaching servant leader role? Do we need a separate Srum Master role for this?

In mature lean organisations, it is the floor-management, the manager closest to the team, who take on the responsibility of coaching the team on its continuous improvement journey. This is a natural step in meeting the need that Henrik points out: Organizations need to learn how to learn. It is obviously a waste having both a management structure that works against agility in the organisation, and then have a Scrum Master who is there to minimize the impact of the bad management. The natural fix after a root-cause analysis would be to fix the management.

However, the path for an organisation to walk before they understand this might be long, and it is clear that the majority of the organisations have a need for guides who can help them do the walk. Our job as agile coaches are far from over. But I can definitely see that it is a transitional phase, and when that is over we need to take another job. Probably as managers of the organisations that now has integrated agile values and practices in their very core.

SAFe and different scaling dimensions

(Since I was asked in English about some of my views on the Scaled Agile Framework, I will try to blog in English, even though it is not my first language.)

I have spent the greater part of my consulting time the last three years in larger organisations that are trying to achieve more agility in their systems development, so questions of how one handles different scalability issues when it comes to lean and agile has been quite important to me. One can not mention the words "agile" and "scale" without thinking of Dean Leffingwell's Scaled Agile Framework ("SAFe"), and when trying to be agile at a scale you have to deal with one or more of the issues that he touches. So it doesn't matter if you choose to follow his advise in a particular question or if you choose do the opposite: you need to have an informed opinion of what the SAFe says and why it is wise to follow or go against in your particular case.

First, you need to understand what you mean by "scale". The context of the Scrum definition is a product where a single Product Owner can prioritize among customer values - often in the form of features -, and a integrated cross-functional team can implement at least one feature within the boundaries of a couple of weeks. As soon as your reality transcends that, you need to employ some strategies in order to cope with it. Some of those strategies might be of the sort that they break the rules of Scrum.

Here usually comes the first set of criticism against attempts to scale: "This smells of component teams!", "You shouldn't have to coordinate among several teams, why can't they self-organize?", "You should be able to show an integrated piece of functionality after each sprint!" To which the thoughtful reply always is: "Well, yes, but if we can't?" Certain problem and solution domains are so complex that we need to take time, to use many teams, to build up a small testing debt once in a while. It is not by choice, we have inherited the complexity, and now we have to do the best we can with what we have.

Scaling is basically done along the dimensions of either the number of people necessary to create the value, or the time neeed, or both. We might need more than one team, and we might need more than one sprint. When you think of it, both the Scrum team and the sprint are in themselves scaling techniques along these dimensions: if you need more than one person, use a cross-functional team; and lock the requirements for 2-4 weeks (and call that period a "sprint") before integrating, since it will probably take more than a day to implement. SAFe is basically an extension of those Scrum strategies.

Even the single team organisation has in fact a scalability issue: that of time. Even where you can develop single features within a sprint, features are often meaningful only in contexts together with other features, for instance to support a whole scenario for some user. So even in the small scale you will probably have to coordinate implementation activities over time, aggregating sub-goals towards a more valuable bigger goal. The act of identifying important larger goals and decompose them into smaller but meaningful slices is called "refinement", and the backlog very much resembles a refinery where crude ideas enter at the bottom (like crude oil) that will be clarified and broken down further up.

While cracking and refining crude oil is a continuous process, refining backlog items is best done in distinct levels. Dean Leffingwell's book Agile Software Requirements (which would later be developed into the SAFe) proposes three distinct levels of the backlog, expressed as three distinct backlogs: the portfolio level, the program level, and the team level. The levels are typically coordinated with time frames of the different planning horizons so that the team level coordinates sprints, the program level coordinates releases, and the portfolio level coordinate the investments either they are done continuously (which SAFe and beyond budgeting suggests) or on a year-by-year basis.

That approach is in my experience very fruitful. In fact, the backlog is a value stream map of the development. Development is the generation, refinement and codification of knowledge; the backlog tracks exactly that; and when implementing lean (and agile is a lean implementation) you need to organise (and thus scale) around the value stream. In my experience, you often need a bit more granularity in the backlog levels: I often propose the horizons/levels of: within a sprint (2 weeks), an iteration (3 sprints), 2-4 iterations (2-6 months), and a "project" level that tracks initiatives that lasts for half a year up t two years (even if the usefulness of initiatives of that size can be doubted). While the division of the backlog needs to fit the particular situation, this approach of dividing the backlog into sections is fruitful.

SAFe strategies can however be problematic when it comes to how you organise work. The depiction of the backlog levels as if they were separate backlogs owned by separate departments tempts people into organising handoffs instead of using soft handovers involving members from different departments swarming around the items when they need to be refined. While Leffingwell himself always stresses the use of such lean practises instead of wasteful formalism, the presentation of the SAFe easily lends itself to a bureaucratic interpretation as I have encountered many times.

Another problematic area is that SAFe, just as Scrum, doesn't scale well when we need many different cadences - rythms - in parallel. Scrum talks about only one cadence, the sprint, and SAFe expands with adding the concept of iteration (a period of a couple of sprints in which you can develop several parts and integrate them), and a more elaborate description of how you manage releases. Scrum explicitely states that the sprint should rather not be replanned, which is a way of saying that the sprint is the shortest cadence you should allow for, and SAFe talks about the need of having all involved teams using the same takt of sprints and iterations. SAFe even mandates that the different teams should employ the same strategy when calculating velocity and making forecasts.

In my experience, this is where both SAFe and Scrum breaks. First because the domain of them both is limited to just one small part of the product/service lifecycle: the development. When doing development and development only, you might have the luxury of plans that can remain static for two weeks. But I have yet to see even a development team that never have to respond quickly to some external requests. Therefore: every Scrum team I have seen have had to be able to handle several cadences. On a side note, it is also often a bad practise to have isolated teams doing only planned development. The more responsibility and understanding of the lifecycle they can have, the better they understand the user's actual needs and the business value they provide. DevOps are good for a reason.

So since almost every Scrum team need to handle issues on both a daily, weekly, and bi-weekly basis, maybe using Scrumban or some other Scrum/Kanban hybrid, the organisation need to be polyrythmic in more complex figures than what both Scrum and SAFe assumes. A team where 80% of a week's work isn't possible to plan at the beginning of the week, will need to employ different strategies for doing development in a predictable way compared to the team where only 20% of the work has to be unplanned. They need different methods of forecasting, different jidoka conditions, and thus different ways of working. One or two sizes can't fit all situations we end up in. We need to bring in more practices and techniques than what is suggested in Scrum and SAFe in order to make it work well.

So in short: this is why in my experience SAFe suggests many good ways of coordinating the enterprise backlog among several teams and disciplines; but is too limited and can be harmful when it comes to coordinate the actual work.

Att förändra

Som sagt: du (och jag) ÄR inte si eller så. Vi har lättare för att bete oss på det ena eller andra sättet, särskilt i vissa situationer, men att det finns någon statisk personlighet som sätter ramarna för oss är det svårt att finna bevis för. Däremot verkar vi ha en inbyggd bias för att tro på personligheter. (Och det verkar som om vi behöver en någorlunda konsistent berättelse om vår egen person för att må bra, men det är delvis en annan fråga).

Det betyder att folk kan förändra sina beteenden ganska mycket, mer än många tror, och det är en väldigt bra egenskap hos oss när vi kastas in i nya situationer. De som leder en organisation där många människor samarbetar för att uppnå ett syfte är det helt nödvändigt att kunna verka för förändrade beteenden, annars kommer inte att organisationen att uppnå sina syften tillräckligt bra. Risken är istället att folk mår dåligt där.

När jag hjälper människor i organisationer att stärka varandras förändring blir jag hjälpt av att arbeta utifrån modeller om hur människor beter sig och fattar beslut. Modeller beskriver aldrig verkligheten särskilt exakt, utan är fulla av förenklingar, men om de är tillräckligt beskrivande kan de vara användbara.

En modell jag använder är till exempel en uppräkning av saker som påverkar mitt beteende:

• Världsbild - hur analyserar jag situationer, med vilka ord, hur tror jag att världen hänger ihop?
• Attityd - vilka grundläggande förväntningar och angreppssätt har jag?
• Strategier - vilka konkreta beteenden har jag tillgång till (kunskap om, vana vid, osv)?
• Omvärldsbeteende - hur upplever jag att världen möter mig precis just nu?

När mitt, eller andras, beteende behöver förändras så kan jag med hjälp av modellen titta på situationen utifrån dessa vinklar, och undersöka om det finns sätt att påverka världsbilden, attityden, strategierna eller omvärldens beteenden.

När jag fått frågan om jag kan hjälpa till i ett förändringsarbete har ofta de som frågar redan försökt. Men deras modell brukar bara innehålla omvärldsbeteende ("Vi ska försöka ändra på de här yttre begränsningarna, men vi kommer att bli tvungna att acceptera det mesta av dem ändå!") parat med gnäll över felaktiga beteenden ("Men sluta bete dig som du gör!"). I bästa fall försöker de åtminstone föreslå ett par nya strategier att pröva ("Bete dig så här istället!").

Men det är alltför sällan som folk kommer på tanken att attityder i högsta grad är situationsbundna och därför möjliga att påverka. Det är också alltför sällan som folk förstår hur mycket våra världsbilder som påverkar våra beteenden. Man fastnar, helt i onödan, för att man inte har tillgång till så många verktyg. Jag hoppas kunna beskriva en del av de verktyg jag använder mig av, verktyg som då bland annat används för att påverka den här modellen.