Principen om mänsklighet

(Ytterligare ett litet smakprov från boken "Smidigt - Agila arbetssätt för en vanlig arbetsplats")

Principen om systemsyn ligger nära principen om mänsklighet. På många ställen i litteraturen om lean och agila metoder kallas det för principen *"Respekt!"* och att man ska *"Respektera folk!"*, men det är lite mer än bara artighet och vänlighet. Det handlar om respekt för det faktum att vi är människor, med allt vad det innebär.

Ska man utforma människorna efter systemen, eller ska man utforma systemen efter människorna? Kan vi agera enbart utifrån välvilja är det självklart att människans behov alltid ska få styra. Problemet är att välvilja enbart inte åstadkommer mat, medicin, och tak över huvudet. Vi *måste* underkasta oss de materiella villkoren.

Det här skapar bilden av ett vägval i huvudet på oss: "Antingen agerar vi välvilligt mot alla människor men då får vi ineffektiva produktionsapparater, eller så tvingar vi in folk i våra produktionssystem så att de gör nytta för det blir i slutändan bäst för alla om arbetet bär frukt!"

Men den här motsättningen är falsk. Det är en tankevurpa. När det gäller maskiner vet vi att de inte går att betvinga. Logistikföretaget anpassar sina tidtabeller efter fordonens faktiska begränsningar, och maskiner körs inte i botten så att de kräver dyr renovering eller förtida skrotning. Vi anpassar systemen efter komponenternas behov. Åtminstone om vi vill att våra verksamheter ska kunna fungera över tid.

Spontant betraktar vi inte människor som maskiner. Det är ofta bra, men i just detta fall leder det oss vilse. Vi glömmer bort att människor faktiskt **är**, eller åtminstone **går runt med**, ett maskineri. En biologiskt komplex köttrobot som, likt vilket maskineri som helst, fungerar som bäst under vissa omständigheter.

Maskinen har servicebehov, vi måste sova. Maskinen kan överhettas, vi kan av stress få för höga kortisolnivåer under lång tid som förstör våra kognitiva förmågor. Känsliga mätinstrument går sönder om vi överlastar dem. Våra intrycksfilter också känsliga och kan överlastas, och då ryker vår produktionsförmåga all världens väg. För att inte tala om det uppenbara när det gäller vår fysiska ergonomi med belastning och tunga lyft och så vidare.

Våra mänskliga behov kan vi inte betvinga. De är som de är. Det är därför vi gör klokast i att anpassa produktionssystemen efter hur vi faktiskt fungerar. Dessutom: om vi anpasser systemen efter vanliga människor slipper vi betala de gigantiska superlöner som de sällsynta supermänniskorna kräver, och vi slipper bli utslitna. Vi är människor, och det ska respekteras. Om inte annat så av lönsamhetsskäl.

Värdeflödesperspektivet

(Detta är ett utkast till ett kapitel i en liten bok om smidiga arbetsmetoder jag jobbar med.)

När vi människor spontant ska organisera oss blir det gärna i termer av hierarkier eftersom vi underordnar oss folk med dominanta beteenden, och vi söker klarhet i vem som är tänkt att göra vad så att vi blir trygga med de sociala förväntningarna i en grupp.

Det är precis dessa naturliga mekanismer som gör det möjligt för t ex en flock chimpanser att jaga kött i grupp och sedan fördela bytet.

Är vi obetänksamma skapar vi alltså naturligt organisationspyramider och strikta roller, utan att tänka efter om detta verkligen är optimalt för uppgiften.

En annan egenhet vi har är att vi inte har någon spontan känsla för när vi åstadkommer något av värde. Vi har belöningssystem i hjärnan som gör oss tillfreds när vi lyckas trigga dem, och vi har en känsla för när vi arbetar hårt och när vi inte gör det.

Men vi kan inte spontant känna igen hög produktivitet på samma sätt som vi känner av lycka eller hög arbetsbelastning. Det gör att vi tenderar att värdesätta hårt arbete högre än låg ansträngning även om den låga ansträngningen skulle resultera i ett större värde än det hårda arbetet. Inte heller förstår vi vad stort värde är, om vi inte lyckas koppla det till något som triggar vårt naturliga system av inre belöningar i hjärnan.

När dessa naturliga förutsättningar får spela fritt skapas alltså

• pyramidorganisationer
• där folk som beter sig dominant ges mandat att bestämma,
• där folk är låsta i sina strikta yrkesroller,
• där den som inte sliter ut sig misstänks för att inte bidra med så mycket av värde,
• och där folk tenderar att sträva efter det som känns bra inuti dem själva.

Men ska man leverera en kvalificerad tjänst eller produkt kan man inte göra det i en apflock. Det krävs ett intrikat samspel av olika yrkesgrupper som använder sina färdigheter till det yttersta och där **flödet** för det som ska levereras är mjukt och effektivt.

Pyramidorganisationer där de olika yrkesgrupperna arbetar i varsina specialiserade avdelningar brukar kallas för "stuprörsorganisationer". När något ska levereras kommer flödet att passera flera stuprörsgränser. Där sker det överlämningar som ofta är knöliga, där information tappas, och där ärenden inte sällan köas upp.

När ärendena köas upp blir folk stressade och börjar ta på sig för mycket, och gärna flera ärenden samtidigt eftersom detta ger en känsla av produktivitet. Dvs en känsla av hårt arbete, produktivitet kan vi ju inte känna.

Genom studier och mätningar **vet** vi sedan länge att överlämningar och väntan innebär att produktionen tappar värde, vi **vet** att det innebär en extra kostnad att göra flera saker samtidigt, vi **vet** matematiskt att det producerade värdet per tidsenhet blir gigantiskt mycket högre när vi fokuserar på att avsluta ärenden och leverera värde, än på att påbörja nya.

Men för att detta vetande, som ju går emot flera av våra naturliga intuitioner, ska kunna omvandlas till nytta i verkligheten så behöver vi handla efter det. Och då måste flödet synliggöras.

Det är detta som är värdeflödesperspektivet. Oavsett om du är ensam om att se det eller om hela din organisation har beslutat att organisera sig runt värdeflödena, så är det det horisontella värdeflödet, tvärs genom alla stuprör fram till mottagaren, som är utgångspunkten för alla smidiga arbetssätt.

Detta gäller antingen vårt värde är en människa som behöver omvårdnad, ett stycke råvara som ska bearbetas, en önskad funktion som ska implementeras i ett datorsystem, smådelar som ska sättas samman, eller en utbildning som ska hållas. Värdeflödesperspektivet är lika giltigt för saker som för tjänster, lika giltigt för produktion som för utveckling.

Det intuitiva sättet att se på en organisation leder till ett kostnadsfokus och *"resursoptimering"*, dvs att man försöker belasta varje enskild människa och maskin i systemet så mycket som möjligt, vilket inte är särskilt optimalt.

Med värdeflödesperspektivet får man istället ett flödesfokus. Allt handlar om att öka flödeseffektiviteten, vilket totalt sett producerar högre värden per tidsenhet. Att överlasta maskiner, processer, och människor **minskar** flödeseffektiviteten.

Kort om mätvärden

Ytterligare ett inlägg föranlett av en twitterdiskussion under dagen.

Inom smidiga arbetsmetoder (lean, agilt etc) finns det ett sätt att använda mätvärden som skiljer sig något från det som är populärt på många ställen just nu.

Det hela går tillbaks på statistikern Harold Dodge, en pionjär inom kvalitetsarbete som på 1920-talet påminde om att det är omöjligt att inspektera fram kvalitet. Den kan bara mätas i efterhand, och då som resultat av den process som skapade det man vill mäta kvaliteten på.

Mätvärden kan alltså vara indikatorer på hur väl en process kan skapa värde, men är inget man direkt kan styra på. Det är ungefär som kroppstemperaturen: termometern kan berätta hurpass hög feber jag har, men temperaturvärdet ger mig ingen vägledning i hur jag kan sänka den eller hur jag ska bära mig åt för att inte bli sjuk till att börja med.

Det är därför som William Deming tar upp under sin tionde punkt att man måste sluta styra på numerära mål: "Eliminate management by objective. Eliminate management by numbers, numerical goals." Om din process naturligt resulterar i 10-12 enheter per dag, så hjälper det inte att säga att du ska öka till 14. Om din process naturligt åstadkommer tre defekter i veckan kan inget inspirerande linjetal få ner dem till noll.

Så kallade "KPI:er" ("key performance indicators") eller "nyckeltal" var ursprungligen tänkta att vara just indikatorer, visa hur en process mår. Men så föddes tanken att man även skulle kunna styra på dem, och att man genom att bryta ner övergripande nyckeltal för organisationsmålen organisatoriskt skulle kunna få fram nyckeltal för avdelningar och individer. Detta paper är ett typexempel på det tänkandet.

Problemen är många med det sättet att tänka. Till exempel är det knappast organisatoriskt man bör bryta ner ett nyckeltal. Organisationen finns ju till för att skapa ett värde i ett värdeflöde, så nyckeltalen måste ju rimligen tillämpas på just värdeflödet. Att fokusera på det horisontella värdeflödet och glädjen hos slutanvändaren istället för på den vertikala organisationspyramiden är för övrigt typiskt för alla smidiga metoder. Gör man detta samtidigt som man tvingas styra efter nedbrutna nyckeltal som följer av att vara en del i en organisation har man skapat en målkonflikt i organisation, mitt i sitt eget arbete.

Men fortfarande kan vi inte styra på värdena, bara veta hur det går. Det beror ju på att frågan om hur värde skapas är en kvalitativ fråga och inte en kvantitativ. Det intressanta är inte hur mycket?, utan hur? Det är symptomatiskt att alla som pratar om att KPI:er måste vara möjliga att agera på, samtidigt inte lyckas berätta hur man gör för att hitta dessa.

Peter Drucker formulerade det i termer av det lilla förrädiska ordet if: "...if these KPIs are assigned properly, will ultimately influence the right behavior of these employees while allowing managers to refer to a concrete set of metrics showing true worker performance." Om man bara hittar rätt mätvärde så blir allt bra. Leta vidare!

Att på det här sättet behöva övervaka utfallet av ett arbetsmoment kontinuerligt är spill. Grupper i smidiga organisationer har istället definierat sina standardprocedurer, och sett till att de följer dessa. Därigenom vet de att utfallet antingen blir som förväntat inom en känd och tidigare uppmätt variation, eller så slår ett larm till.

Utan denna statistiska kontroll är allt förbättringsarbete och allt mätande meningslöst. Mäter du nuläget kommer du inte att veta om dina mätningar står sig nästa vecka så att de berätta om förbättringen lyckades eller ej. Värdet ger en illusion av kontroll: du "kontrollerar" ju hur landet ligger, men du kontrollerar ju inget. Har gruppen däremot definierade procedurer för hur de arbetar, så har de också möjlighet att förbättra dessa.

I en smidig organisation är det flödeseffektiviteten som ska förbättras. Vi minskar hindren, jämnar ut flödena, tar bort saker som orsakar defekter; och allt syftar till att leverera mer värde snabbare. Det är så som vi ökar värdet på kedjan, och det är i den riktningen vi vill förändra oss.

Vi ställer oss frågan vad det är idag som ligger mellan oss och fullständig flödeseffektivitet. Sedan ser vi om det är något vi kan testa att förändra som kan ta oss ett steg närmare det målet. Vi tittar på nuläget, vi antar ett framtida läge som vi är nöjda med, och så provar vi det nya sättet en liten tid.

Efter en tids experimenterande med det nya sättet mäter vi och ser om det blev en förbättring. Om så är fallet kan vi bestämma oss för att permanenta det nya sättet. Då skriver vi in det nya sättet som en standardprocedur, och så släpper vi mätningen. Vi vet ju vad den nya processen förmår leverera. Nu ska vi istället titta på nästa förbättring, mäta där, hitta på en nytt sätt, prova det, mäta, och utvärdera.

Det är den plats ett mätvärde har i en smidig organisation. Att leverera värde är en process. Vi blir inte mindre sjuka av att titta på en termometer varje morgon som visar normala värden. Att glo är bara slöseri med tid. Vi blir istället mindre sjuka genom att prova konkreta handgrepp i våra procedurer ("Tvätta händerna oftare, tag inte i hand!"); och vi använder temporära mätningar för att se att vi är på rätt väg.

Vad är lean, vad är agilt?

Ett litet inlägg, motiverat av att jag fick precis den här frågan på Twitter nu på morgonen.

Både "lean" och "agilt" är hiskeligt breda termer, såpass breda att de nästan kan syfta på allt och ingenting. De förklarar alltså egentligen inget, men de uttrycker två aspekter av en önskan om hur samarbeten skulle kunna bli mer smidiga.

Skälet till varför man inte kan säga "Vi provade lean/agilt men det funkade inte", är att man inte har beskrivit vad det var man provade. Ständig förbättring? Självstyrande team? Kanbansystem? Tavelmöten? I synnerhet har man inte beskrivit vad man inte provade. Lean och agilt är samlingsnamn på ett antal konkreta tekniker, och det är naturligtvis de konkreta teknikerna man alls kan ha en uppfattning om. Det är ju de som ger positiva och negativa effekter, inte vad man kallar ansatsen som sådan.

Begreppet Lean lanserades 1986 och populariserades 1990 som samlingsnamn på de idéer och praktiker runt flödeseffektivitet och lagarbete som Toyota utvecklat under efterkrigstiden för att kunna kombinera effektivitet, hög kvalitet, och lönsamhet. Innan dess kallades ansatsen ibland för "Kaizen" (="förbättring"), eftersom alla leanmetoder innehåller processteg där man förbättrar själva processen. Ofta gick ansatsen helt enkelt under namnet "Toyota Production System".

Ansatsen fick namnet "lean" (="slank") eftersom det handlar om att hela tiden skala bort allt som inte är nödvändigt för värdeskapandet.

Agilt lanserades år 2001 som ett samlingsnamn på de idéer och praktiker runt systemutveckling som vuxit fram under 1990-talet bland de som engagerat sig i objektorienterad utveckling. Namnet fick det på grund av idealet att värdera förmågan att smidigt ändra sig högre än förmågan att följa en plan.

Skälet till att just den aspekten ses som så viktig har att göra med att varje systemutvecklingsansats börjar med så många okända faktorer att de faktiskt är omöjliga att planera på förhand. Även nya insikter som visserligen bara ger små förändringar i kravbilden, kan få stora konsekvenser vad gäller i vilken ordning man bör göra saker, eller för vad som är enkelt respektive svårt osv. Bättre att smabbt kunna omplanera på ett strukturerat sätt, än att tvingas följa en plan som har blivit omkullsprungen av verkligheten.

Lean och agilt hänger ihop på många sätt. De konkreta tekniker som de sk "agila" metoderna innehåller har nästan samtliga hämtats mer eller mindre oförändrade från Toyotafabrikerna. Bägge ansatserna syftar till flödeseffektivitet, och det är precis det som teknikerna på olika sätt ger. Blir processen mer slimmad och effektiv (slankhet) så kommer den att möjliggöra snabbare förändringar (agilitet). Och omvänt: vill du öka agiliteten blir du tvungen att rensa bort onödigheterna.

Så det är verkligen smidiga ansatser från samma tankefamilj (dit också saker som Rightshifting, Beyond Budgeting, Lean UX, Management 3.0, Agile HR osv hör); de syftar på vad ett samarbete skulle kunna bli, de delar konkreta tekniker, men de kan inte förespråkas eller kritiseras som sådana. Det är endast de specifika teknikerna vi kan ha synpunkter på och erfarenheter av.

Out of the Crisis, kapitel 1

I vår bokcirkel har vi under vecka 49 läst kapitel 1 av Out of the Crisis, och jag tänkte posta ett litet sammandrag och några tankar.

Kapitlet slår fast det som är Demings huvudtes: orsaken till dagens (det sena sjuttiotalets) situation inom industrin är systemisk. Den låga produktiviteten och kvaliteten är en följd av att produktionssystemen ser ut som de gör, det hjälper inte att lappa och laga, utan systemen måste tänkas om. Och det är ledningens ansvar att se till att så sker.

Man tror att kvalitet är dyrt och hindrar produktivitet, men sanningen är att kvalitet, låga kostnader, och hög produktivitet går hand i hand; så länge som man förbättrar kvaliteten systematiskt. Det blir mindre spill i processen. Dessutom mår alla bättre.

Deming citerar en japansk chef som efter resor världen över konstaterar att i Europa och i USA är folk intresserade av att hålla nere kostnaderna för kvalitetsarbetet, och av att försöka inspektera fram kvalitet. I Japan arbetar man istället med systematiskt kvalitetsarbete i enlighet med Shewharts metoder (som Deming hade undervisat japanska industrialister i). I Europa och i USA var frågan: hur sänker vi kvaliteten utan att tappa kunder? Vad är vår lägsta nödvändiga kvalitetsförbättring? I Japan förbättrade man istället processerna kontinuerligt utan hänsyn till kostnader. Resultatet blev högre kvalitet till lägre kostnader.

Hemligheten är att hög kvalitet betyder låg variation, och det innebär högre produktivitet, vilket innebär att kostnaden per enhet sjunker även om processen kostar pengar att förbättra.

Detta har alla arbetare traditionellt vetat, och i efterkrigs-Japan visste även fabriksledningarna det.

Deming sätter kunden i fokus, och menar att alla måste målmedvetet arbeta för att kundens behov alltid ska tillgodoses. Det är produktionens konstanta syfte. För att detta ska ske måste man granska kvaliteten på alla inflöden: material, verktyg, ledningsbeslut, arbetsordningar, och arbeta långsiktigt tillsammans med leverantörer. Detta innebar en svår omställning för många japanska fabriker, men ledde till att det fattiga landet Japan kunde bli rikt, även utan en massa naturtillgångar.

Ledarskapet, styrningen, och processerna betyder mycket mer för rikedomen än naturtillgångarna. Deming kallar USA för ett av världens minst utvecklade länder. "It would be a mistake to export American management to a friendly country".

När man mäter kvalitet kan man bli förfärad för att den är låg. Men titta istället på variationen. Om kvaliteten är låg men samtidigt jämn (inom tre standardavvikelser upp eller ner) så är det fråga om systematisk variation. Det hjälper inte att skylla på arbetarna. Det är processen som stabilt och förutsägbart skapar alla dessa defekter.

Genom att angripa produktionssystemet (processteg, handgrepp, osv) kan man på bara några veckor sänka antalet defekter med flera procent och tjäna på den ökade produktiviteten. Detta utan att investera i nya maskiner eller anställa fler arbetare.

Det gäller att arbeta smartare, inte hårdare. Numeriska produktionsmål kan locka arbetsledare att acceptera fler defekter. Om man istället har kvalitetsmål kommer produktionen att öka utan försämrad kvalitet. Då tvingas man angripa orsakerna till varför defekterna uppstår (kvaliteten på materialet, på maskinerna, på handgreppen). Med utjämnade processer kommer också möjligheterna att spara på råvaror

Defekterna har nämligen ett högt pris. Det måste tas med i kalkylen. Då ser man att dålig kvalitet inte lönar sig.

Deming föreskriver kontinuerlig förbättring. Att förlita sig på nya maskiner och ny teknik är inte i sig lösningen. Ett kontinuerligt förbättringsarbete däremot ger resultat inom dagens befintliga ramar. Däremot kan ny teknik vara en del i denna process. Det finns många exempel på där modernisering av maskinparken och datorisering gett goda resultat. Men det är inte tillräckligt.

Inte bara företag utan även myndigheter tjänar på detta tänkande. Inte bara tillverkande organisationer utan även tjänsteorganisationer.

Notera att mäta defekter inte hjälper dig att undvika dem. Deming tar upp flera dråpliga exempel på kvalitetsmätningar och kvalitetskontor som inte förbättrar, utan bara är dyra sätt att konstatera hur illa de är. Man måste kunna agera på mätvärdena för att de ska kunna göra nytta.

När man ska förbättra en process är det viktigt att man vet vilket som är värdeflödet så att man inte försöker förbättra fel sak. Boken nämner Edisons automatiska röstningsmaskin som han försökte sälja till den amerikanska kongressen för att underlätta vid voteringar. Han blev förvånad när det som han såg som en förbättring (undvika dröjsmål) i själva verket förstörde den demokratiska processen som var uppbyggd kring att ett visst dröjsmål skulle finnas i frågorna.

Tankar

Notera hur den minskade variationen (de minskade defekterna) möjliggör innovation, genom att mindre energi måste läggas på att hantera avvikelser. Processförbättringen köper dig tid till mer processförbättring.

Att systemfelen är ledningens ansvar kan leda en att tro att ledningen ska fixa systemet åt arbetarna. Men som vi sett från lean och agila metoder finns det allt att vinna på att arbetarna själva får verktyg och mandat att förbättra processen. Men fortfarande krävs en ledning som allokerar resurser till detta.

Anomalierna ger så mycket viktig information om processen. Aggregerat data som mäter både bra och dåliga resultat kommer att resultera i ett medelvärde som döljer alla orsaker till problem. Uttrycker du leveransförseningar i andelen leveranser som är i tid så vet du inte vad som orsakar förseningarna. Aggregerar du förseningsminuter kan du däremot se hur dessa stiger under vissa omständigheter, och du får därigenom bättre möjligheter att angripa rotorsakerna.

Det är detta tänkande ("Mät där det gör ont!") som ger information om hur problemet ska avhjälpas. Anekdoten på sidan 10 om måleriutrustningen som ibland täckte med för mycket och ibland med för lite färg (och som man hela tiden justerade vilket ledde till större variation), handlar om detta.

Ett varningens ord till chefer: "Support is not enough, action is required!"

Gruppkata: Problemintervju

En kata man kan använda i problemlösningsprocessen är en problemintervju.

En person, problemägaren, har upplevt sig ha en insikt om ett problem. De övriga turas om att under cirka tio minuter ställa frågor till problemägaren om problemets natur, teorier om hur problemet uppstår, vilka negativa effekter det har osv osv.

Gruppens fokus är att att skaffa sig så god kunskap som möjligt om problemägarens syn på saken. Det är inte ett forum för att värdera problemet, eller ifrågasätta några av de mekanismer som problemägaren menar sig ha iakttagit. Man bör också undvika att försöka hitta en lösning på problemet, eftersom kunskapen om problemet på det här stadiet är alldeles för dålig. Deltagare som tror sig ha en lösning bör notera denna, så att man kan ta fram vid ett senare tillfälle.

Deltagarna bör använda dels öppna frågor när de intervjuar (frågor som inte bara kan besvaras med ja eller nej), dels formulera dem utifrån problemägarens subjektiva upplevelse. Dvs istället för att fråga "Är det så att.." bör man fråga "Hur tror du att...".

Deltagarna bör också vara mån om en nyfiken, respektfull och undersökande ton. I just den här intervjusituationen har problemägaren hundraprocentigt tolkningsmandat och problemformuleringsprivilegium. Det betyder inte att gruppen från och med intervjun kommer att se på saken precis som problemägaren skulle önska, så därför behöver ingen använda just den här situationen till att ifrågasätta eller diskvalificera problemägarens uppgifter. Att validera problemet och bestämma en handlingsplan är helt enkelt en senare fråga.

Det är viktigt att inte dra ut på processen. Håll det kort och kärnfullt, och låt ordet rotera mellan deltagarna.

De positiva effekter man vill nå är bland andra dessa:

• Ingen ska behöva vara ohörd. Alla i gruppen har lika stor rätt att få sin sida av saken hörd. Just dessa tio minuter tillhör person X, och det betyder att även person Y och person Z kan förvänta sig samma möjlighet.
• Genom att alla får ta del av problemägarens perspektiv och drivkrafter så ökar empatin inom gruppen, och vägen till att få en gemensam syn på saken kortas. Detta kan öka gruppens angelägenhet (urgency) att ta itu med en problematik.
• De som blir stressade av att inte hela tiden få ha problemformuleringsprivilegiet tränas i att släppa det. Att släppa det för stunden betyder ju inte att man tappar inflytande permanent. Gruppen behöver träna att hålla flera parallella problemformuleringar i luften samtidigt, och först därefter validera och värdera dem i tur och ordning.

Begränsningar och risker med katan är bland andra dessa:

• Den kommer inte i sig att hjälpa gruppen att validera och värdera ett problem, bara att inventera det.
• I en grupp där maktförhållandena varit djupt ojämna och folk varit ovana vid att lyssna in främmande perspektiv utan att omedelbart döma över dem, innebär denna kata ett stort avsteg från vad som räknats som normalt inom gruppen. Stor stress kan uppstå, och folk kan av det skälet göra dumma saker och trampa varandra på tårna.
• Resultatet är väldigt osorterat: Man får en människas spekulationer om problemets orsaker, blandat med dennes subjektiva uppfattningar om hur illa det är.

Problemlösning i grupp

Ibland är en människa ensam om att se och uttrycka ett visst problem. Detta skapar en massa spänningar i en grupp:

• Människan tänker: "Det är nog bara jag. Ingen annan verkar se det."
• Någon i omgivningen tänker: "Det där kan inte jag se. Hen har nog helt fel."
• Någon annan i omgivningen tänker: "Usch, det stämmer kanske, men det blir ett väldigt jobbigt problem att hantera om vi väljer att lyfta upp det."

Observera att jag skriver "tänker", men "tänkandet" här kan också vara helt omedveten process. Resultatet blir detsamma: gruppen undviker att hantera ett problem som en (eller ett par) av dess medlemmar har identifierat. Därmed blockeras förbättringsprocessen.

I en handlingsförlamad grupp är ståndpunkterna om gruppens nästa steg sällan uttalade. Det är t ex rätt vanligt med en outtalad idé om att alla problem som gruppen har noterat med nödvändighet ska värderas som viktigare än annat och därmed hanteras. Då blir problemformuleringsprivilegiet i gruppen dyrbart och laddat. Gruppen orkar ju inte att hantera precis varenda sak som någon i gruppen uppfattar som ett problem. Den tysta förhandlingen om vem som ska ha inflytande i gruppen får orimligt höga insatser. Maktkamp uppstår.

För att bryta detta dödläge måste man bryta den svartvita synen på "problem". "Problem" är till att börja med dels en beskrivning av ett skeende, och dels ett värdeomdöme (skeendet går inte rätt till). Beskrivningen av skeendet är inte självklart: jag kan se tokigt på situationen och jag kan ha en tokig uppfattning om de inblandade orsakssammanhangen. Värdeomdömet uppfattas spontant ofta som binärt (saker är antingen problem eller inte), men i själva verket innebär olika saker mer eller mindre problem jämfört med annat, beroende på omständigheterna.

Om gruppen sedan ska välja att försöka hantera problemet och i så fall med vilken strategi, är också öppna frågor. Vilka av orsakerna till problemet kan man angripa? Hur stor är sannolikheten att strategierna kommer att lyckas? Vilka är kostnaderna för de olika strategierna? Vilka är riskerna?

I en grupp där processerna för förbättringen är omedvetna och tysta riskerar dödlägen ständigt att uppstå. Vårt naturliga spontana sätt att hantera dödlägena är att förlita oss på primitiva auktoritära grepp med dominansbeteenden och underkastelsebeteenden som styr gruppen genom att trigga olika känslor hos dess medlemmar. Inte sällan mår folk dåligt i sådana grupper, och inte sällan blir resultatet undermåligt jämfört med alternativen.

I smidiga metoder försöker man sig istället på att angripa problemlösningen empiriskt på ett genomtänkt sätt. Observationen är att gruppen då förbättrar sin process snabbare, når bättre resultat, och att folket i gruppen mår bättre (eftersom vi utgår från hur vi människor faktiskt fungerar). Jag skrev om gruppkator förut, och ständig förbättring (kaizen) kan man med fördel utföra i formen av olika sådana. Jag tänker att jag ska tipsa om några, fast det får bli i en senare post.

Bokcirkel: Demings Out of the Crisis #ootcr

Vi är några stycken som tänker läsa Out of the Crisis ihop. Se om den kan lära oss och kunskapsarbetarna i vår tid något, även om den var skriven för den amerikanska industrin i början av 80-talet.

Vi i Göteborg planerar att träffas nån gång i veckan och prata. När det gäller själva bokcirkeln har jag annars tänkt att vi kan prova länsbibliotekens webbtjänst bokcirklar.se, så om ni vill vara med i cirkeln rekommenderar jag att ni går med där. Då kan vi ha en diskussion även om vi befinner oss på olika platser på jordklotet.

På twitter använder vi taggen #ootcr.

Så häng på om du vill! Till i morgon (måndag 2 december 2013) läser vi om Deming på Wikipedia, och vi läser allt i boken innan kapitel 1 (förordet, om författaren, etc).

Gruppkata

En av utmaningarna i kampsporter är att reflexmässigt kunna ta till de mest effektiva rörelserna i en situation där stressnivåerna är på topp och orken som lägst. Hur kan man i lugna omständigheter lära sig att i skarpt läge reflexmässigt aktivera ett visst rörelsemönster?

Den motoriska inlärningen sker genom att man utför den rörelse man vill träna in. Det gör inget om rörelsen först tränas in långsamt och lite styltigt, för vitsen är att känslan från det ena kroppsläget ska trigga beredskapen att utföra en rörelse till nästa läge, och sedan nästa. Med tiden kommer snabbheten och flytet, när rörelserna har blivit automatiserade i sekvenser. På den här principen bygger också skalövningar och simträning. Inom de japanska kampsporterna använder man kator: en sorts skalövningar för kroppen, anpassade för att träna in ett rörelsemönster som sedan ska kunna fungera i kamp.

En grupps beteende fungerar på ungefär samma sätt som ett motoriskt minne. En viss situation triggar en automatisk beredskap hos var och en i gruppen att bete sig på ett visst sätt. Flera beteenden sitter ofta ihop i långa kedjor där en situation orsakar ett beteende som skapar en situation som orsakar nästa beteende osv. Precis som en rörelsesekvens hos individen.

Den här automatiken gör att gruppbeteenden kan vara svåra att förändra. Det räcker inte att ha insikt om att gruppsamspelet bör eller till och med måste förändras. Det räcker inte att se och konstatera att processerna leder till dåliga resultat. Det enda som skapar förändring är om man faktiskt ändrar beteendet. Bryter mönstret och vanan.

När jag som individ ska lära mig något nytt, så behöver jag dels veta hur jag ska lära in det, och jag behöver bestämma mig för att öva på det. Ändra mitt beteende. Detsamma gäller gruppen: vi måste aktivt träna på ett nytt gemensamt beteende för att kunna ändra oss. Men att göra saker i grupp kan vara många gånger svårare än att göra det själv. Det är många beslut som ska fattas: om vi ska ändra beteende, hur vi ska gå till väga, när vi ska göra det osv. Beteendeförändring kräver ledarskap. Människans grundhållning är annars att låta allt förbli vid det gamla.

Ett beslut uppifrån, ett diktat, kan underlätta gruppens förändring. Men om man från golvet vill införa smidigare arbetsmetoder kan man få vänta länge eftersom det ju är ledningens nuvarande beteende som skapat dagens situation. Ska arbetssätten ändras behöver ofta impulsen komma nerifrån golvet, och då äger plötsligt gruppen frågan om hur och när igen. Vilken förändring ska man föreslå? För att inte tala om att många beslut om "smidighet" uppifrån ("Nu ska ni köra lean!") resulterar i rena katastrofer eftersom perspektivet från ovan saknar så mycket information om vari osmidigheterna egentligen består. Ledningen ger sig ut på spilljakt utifrån helt felaktiga antaganden om vad som är spill respektive värde.

En fördefinierad metod kan också underlätta gruppens förändring. Den innehåller ett antal beprövade samarbetstekniker, beskrivna och utforskade av andra. Man minskar risken genom att gå i andras fotspår, eller åtminstone känns det så. Det fördefinierade minskar antalet beslut folk måste ta. Men samtidigt kan en metod vara lite för stor att fatta beslut om. Man kan behöva ett förändringsmandat ovanifrån för att börja arbeta i enlighet med Scrum eller Kaizen inom vården till exempel, och då äger golvet fortfarande frågan om hur man skapar sig ett sådant mandat.

En lösning på det här kollektiva igångsättningsproblemet ligger i att man förstår att metoderna egentligen är uppbyggda av flera små gruppövningar. De föreskrivna mötena i metoderna är i själva verket skalövningar där gruppen tränas i det nya samarbetssättet. De är små kator, om vi ska prata japanska.

En gruppkata är till exempel tavelmötet, det som ofta kallas huddle i amerikansk lean, eller scrum i Scrum. Genom att varje dag mötas i femton minuter runt dagens gemensamma uppgifter i syfte att lyfta och undanröja hindren i flödet blir gruppen mer och mer medveten om sitt kollektiva ansvar för resultatet, och mer och mer flödesorienterad.

En annan gruppkata är förbättringsmötet, det som ibland kallas Kaizen eller Toyota kata, eller retrospektiv. Genom att regelbundet mötas och reflektera över hur arbetssätten kan förbättras, och sedan faktiskt förbättra dem, så tränas gruppen i att själva ta ansvar för sin process.

Medan ett helt metodramverk kan vara tungt att införa och kräva mycket förbättringsmandat, så är en enskild gruppkata enkel och lättviktig. Den är ofarlig att föreslå, behöver ofta inte ta längre än en kafferast att göra, och blir en startpunkt för en förändring till det bättre. Många kator syftar inte till att ändra saker direkt, utan till att skapa en klarare blick över vad som egentligen äger rum i den egna verksamheten. De blir på så sätt en ögonöppnare och kan göra själva förändringen självklar för alla.

Backloggens sektioner

I agil systemutveckling, t ex med hjälp av Kanban eller Scrum, brukar man använda en behovslista som kallas "backlog". Det är ett lite olyckligt namn eftersom det antyder att den innehåller det som ännu inte blivit gjort, sådant man ligger efter med. Men så är det inte.

Behovslistan är en sorts prioriteringslista, ett slags kö där man strängt prioriterar mellan behoven så att den dyrbara tiden alltid ägnas åt det som är mest värdefullt. Systemutvecklarlaget är en trång sektor i detta värdeflöde, så man behöver välja bort merparten av alla behov. Därför behöver dessa rangordnas.

Men backloggen är något mer än bara ett prioriteringsverktyg: backloggen är samtidigt en bild av värdeflödet inom en utvecklingsorganisation. Man kan likna den vid ett raffinaderi: i botten kommer luddiga ideer in, som sedan förfinas till tydliga funktionsbeskrivningar och bryts ner till implementerbara kravpunkter som hamnar överst. Det är ju nämligen lönlöst att prioritera upp något som inte är implementerbart.

I regelverket runt Scrum är detta görbarhetskriterium uttalat: varje utvecklarlag ska ha en tydlig Definition of Ready som bestämmer om något är implementerbart eller ej. Det betyder att den översta delen av behovslistan får en egen sektion: en lista med görbara saker. Scrum förtydligar att det är lönlöst för en produktägare (personen med den höga hatten) att komma till planeringsmötena utan görbarheter.

Denna princip om att sektionera behovslistan för att synliggöra värdeflödet kan man med fördel tillämpa på fler ställen i listan än överst. Definition of Ready visar att det finns ett sista förfiningssteg samtliga ärenden måste passera om de ska göras. Men visst måste de förfinas dessförinnan? Arbetas med? Kan man inte synliggöra även dessa förfiningssteg? Jo, och när man gör det kan man märka att arbetet med behovslistan blir lite tydligare.

Ett görbarhetskriterium för ett ärende består oftast av två delar: att frågetecknena ska vara uträtade (inga öppna frågor, all nödvändig information på plats, tydligt acceptanskriterium), samt att ärendet inte ska vara för stort. Många lag anger storleksbegränsningen till "inte större än att två personer kan färdigställa det på en vecka".

Ärenden som är för stora måste alltså brytas ner till mindre ärenden. Och detta kan bara ske efter det att alla stora frågetecken är uträtade. Alltså finns det en sektion under den översta där alla ärenden är förtydligade, men där det ännu inte är säkerställt att de går att genomföra på den önskade korta tiden. I en backlog för mjukvara är det där alla färdigspecificerade funktioner bor.

Det betyder att det under den sektionen finns en sektion för de identifierade funktioner som inte är färdigutredda än. De kanske bara har brukarberättelsens formulering "Som roll vill jag funktion för att nytta", men inte någon beskrivning av hur den ska implementeras, eller något acceptanskriterium.

På så sätt kan vi prioritera inom varje sektion, och ta de översta i varje sektion och öka värdet på dem så att de får flytta upp en våning. Detta skapar synlighet och gör behovslistan lite lättare att arbeta med.

Incitament, inschitaschment

Jeffrey Pfeffer och Robert Sutton har skrivit boken Hard facts, dangerous half-truths, and total nonsense som berör en viktig komponent i alla smidiga arbetssätt: vi försöker jobba evidensbaserat. Boken tar upp mängder med trender inom organisationsstyrning och granskar dem i ljuset av vad vetenskaplig forskning på området säger (upp till år 2006). Den är en guldgruva för var och en som misstänker att grunden för en viss modern ledarskapspraxis inte är så solid. Ofta är det ju fråga om halvsanningar, giltiga under vissa villkor men inte under andra; och det är intressant att se precis när och hur saker fungerar.

Ett exempel är frågan om ekonomiska incitament. Det finns som bekant en stor övertro på de yttre incitamentens förmåga att förbättra produktivitet, och boken går igenom några av alla aspekter i frågan. Här återfinns t ex Demings observation att eftersom produktiviteten till allra största delen beror på hur produktionen organiserats samt på slumpmässiga naturliga variationer, så är det lönlöst och demoraliserande att belöna och bestraffa individer för produktionsapparatens dagsform.

Precis som denna forskningsöversikt visar så fungerar ekonomiska drivkrafter av och till. Men dels kan det vara ett problem att de faktiskt fungerar: incitamentsstrukturerna orsakar suboptimeringar för precis de faktorer som belönas vilket kan skada hela värdeflödet, och dels kan de yttre incitamenten vara ett svagare substitut för betydligt starkare, mer träffsäkra, och billigare inre motivatorer.

Det finns skäl att återkomma till incitaments- och motivationsforskningen mer i detalj. Boken länkar till många studier, och jag tänkte ta mig tid att läsa flera av dem. Men ett par punkter jag snappat upp är intressanta att nämna redan nu:

• Belöna lag för gott utfört arbete är mer effektivt än att belöna individer. Bl a för att man då får fokus på effektiva samarbeten istället för på individuella suboptimeringar.
• Kunskapsarbete är svårstyrt med yttre belöningar. Effektivt kunskapsarbete måste bygga på inre motivation att förstå, uppfinna, undersöka; och inre motivatorer förstörs ofta av yttre belöningar.
• Ett av skälen till att belöningar fungerar är att de uttrycker vad organisationen faktiskt vill. Inte sällan håller sig organisationer med saker man säger sig värdesätta. Men man är inte glasklar med vad man i varje stund värdesätter mer än andra saker, annat än genom belöningar. Men den informationen kan man kommunicera på annat sätt än genom pengar, t ex genom en tydlig backlog.

Validera alla sidor

Konflikt är egentligen normaltillståndet, om vi med konflikter menar att vår personliga uppfattning bryts av mot omgivningens. Den stora majoriteten av alla dessa "konflikter" löses hela tiden i ett ständigt pågående medvetet eller omedvetet förhandlande om konsensus. Att harmoniera med vår omgivande grupp är något vi är byggda för.

Den gruppdynamiska processen som t ex Bruce Tuckman och Susan Wheelan ägnat så stor del av 60-70- respektive 80-90-talen att utforska, den mäter en grupps sammanhållning som dess förmåga att fatta gemensamma konstruktiva beslut. Man har noterat att en mogen grupp som kan detta samtidigt är en grupp som samarbetar väldigt bra och kan skapa stora värden genom att utnyttja medlemmarnas kunskaper och förmågor på ett produktivt sätt.

Men det kräver att gruppen under resans gång har tillskansat sig produktiva sätt att lösa konflikter på. Och det är inte helt självklart att sådana produktiva sätt uppstår. Den som är satt att göra det enklare för gruppen att nå dit, t ex en chef, en Scrummaster, en leanvägvisare, eller annan facilitator; behöver verktyg för att både förstå och intervenera i konflikter på ett bra sätt. För mig har praktiken att validera varit till stor hjälp, och jag tänkte berätta lite om hur den funkar.

För det första måste man förstå att alla beslut i en organisation, även inom en stark hierarki byggd på hot i själva verket är konsensusbeslut. För att en sträng hierarki ska fungera oss emellan måste vi vara överens om min underordning och din överordning. Så oavsett om vi försöker skapa en egalitär självstyrande smidig arbetsgrupp eller en preussisk armédivision så är den ömsesidiga överenskommelsen nödvändig. Och gruppen måste hjälpas åt att nå dit, inom den maktstruktur man bestämt ska råda.

Det betyder att allas perspektiv alltid kommer vara viktiga för gruppen, även i de fall där någon bestämt att vissa personers perspektiv ska spela mindre roll för helheten än andras.

För det andra måste man förstå att ingen kommer att ge sitt samtycke till en grupp om hen inte får plats i gruppen. Jag kanske inte får det inflytande i gruppen som jag önskar, men det behöver inte hindra mig. Deltagandet i gruppen behöver inte ens vara bra för mig, inte ens att sammanhanget är destruktivt hindrar mitt deltagande. Jag har själv deltagit i konstellationer där jag misshandlats och kränkts, men det blockerade inte mitt deltagande i konstellationen. Däremot: om jag inte kan delta i en grupp kommer det att hindra.

Det betyder att vissa invändningar mot det gruppen bestämt är av den arten att de faktiskt kommer att blockera gruppens arbete i sin nuvarande form, i det att en gruppmedlem faktiskt inte kan delta under rådande omständigheter. Det handlar inte om medlemmens vilja eller mandat, invändningen kommer inte att kunna förhandlas bort oavsett vilka metoder du tänker använda.

Ska du bygga ett smidigt arbetslag finns det inget alternativ till en egalitär struktur med ett skiftande ledarskap inom gruppen. Där är hänsynen till allas olika intressen självklar. Men vad många missar är alltså att den hänsynen är precis lika viktig även i konflikter där parterna har radikalt olika utgångslägen i maktstrukturerna.

Vad är det då som ska bekräftas hos var och en? Marshal Rosenberg, personen bakom "giraffspråket", även känt som ickevåldskommunikation, pratar om fyra aspekter när en människa vill något:

• Observation, man betraktar ett skeende och ger det sin tolkning. I kommunikationen: "Jag ser att..."
• Känsla, man reagerar på det man varseblir med en känsla: "Jag känner att..."
• Behov, man upplever att man har ett otillfredsställt behov: "Jag behöver..."
• Önskning, och sammantaget leder det fram till en konkret önskan: "Jag skulle vilja..."

Dessa aspekter finns hos varje individ i varje stund, i synnerhet i en konflikt, oavsett om vi väljer att uppmärksamma dem eller ej. När vi inte uppmärksammar dem kan det leda till stor frustration och många låsningar. Maktkamper kan äga rum om tolkningsföreträdet vad gäller observationen, samtidigt som man hävdar en önskning som kommer att slå mot den andra partens behov. De starka affekterna förvärrar situationen.

Men när vi genom att lyssna och ställa frågor försöker kartlägga och bekräfta varje individs observationer, känslor, behov, och önskningar, så händer saker.

Vi behöver inte kriga om tolkningsföreträdet vad gäller observationerna. Vi kan konstatera att folk ser olika på saker och ting, och att ontologiska påståenden (utsagor om verkligheten) många gånger kan bekräftas eller förkastas genom ett enkelt experiment. En ontologisk fråga är antingen avgörbar på ett sånt sätt att ingen tvekan råder, eller så är den öppen och då är alla observationer likvärdiga och onödiga att strida om.

När man sätter ord på känslor mildras deras negativa inflytande över vår förmåga att tänka klart. Det kallas affect labeling och verkar fungera så att de delar av vår hjärna som tolkar verkligheten åt oss aktiveras och tar över processen från det mer primitiva paniksystemet som annars blockerar tänkandet.

När vi formulerar våra och andras behov accepterar vi dem. Vi kanske inte är benägna att tillgodose behoven, men det blir i så fall ett medvetet val och inte en dold konsekvens av att behoven ignoreras. Detta minskar också stressen hos var och en: att det alls finns ett språk för att uttrycka och hantera mina behov, och att det språket införs i vår gemensamma diskurs, det skapar en trygg miljö för mig att verka i. Att diskutera arbetssätt utan någon tänker på intäkter versus kostnader skapar otrygghet om du lever med vetskapen att intäkterna alltid måste överstiga kostnaderna för att det ska gå ihop. Att diskutera arbetsplatspolicies utan att någon nämner att de får olika konsekvenser beroende på vilket kön du tillhör skapar otrygghet om du lever med vetskapen att du kan drabbas negativt pga detta.

När vi slutligen blir konkreta och tydliga med våra önskemål om andras beteende kan vi äntligen börja analysera dem. Vad kostar en uppfylld önskning olika parter? Vilka behov uppfyller den? Falska önskningar om andras beteende som i själva verket är önskningar att något visst resultat ska uppnås oavsett om någon kan uppnå det, de avslöjas som orimligt önsketänkande. Och viktigast: om vi känner till de bakomliggande behoven kan vi börja förhandla om andra sätt att tillfredsställa dem.

Att hjälpa var och en i en konflikt att verbalisera detta skapar en miljö där man kan vara lösningsfokuserad. Kom ihåg att du som facilitator också ska verbalisera din vinkel av dessa fyra aspekter. Du är ju ingen utomstående betraktare utan deltagare i detta samspel. Folk behöver veta detta om dig för att vara trygga med var du står i konflikten och på så sätt bjuda in dig att hjälpa dem. Genom att själv verbalisera och kommunicera vad du verbaliserat tjänar också som ett föredöme.

Nästa steg blir nämligen att de olika sidorna ska bekräfta att de förstått varandras observationer, känslor, behov, och önskningar. Förstå och bekräfta är inte samma sak som att acceptera och böja sig inför. Här kan det finnas en liten känslomässig tröskel eftersom vi kan ha svårt att göra den skillnaden, särskilt om vi fortfarande befinner oss i affekt. Samtidigt är påståendena av typen: Jag ser, jag känner, jag behöver, jag önskar; omöjliga att säga emot. De är ju bara subjektiva observationer inifrån en människas hjärna och vi får ta dem för vad de är.

Har man väl kommit hit brukar resten gå av sig självt. Att blottlägga de inre aspekterna av konflikten fungerar som alla andra transparenshöjande smidiga tekniker: de gör det svårare att fatta destruktiva beslut. Däremot kan processen när man tillämpar denna praktik blottlägga så djupt liggande motsättningar att själva samspelet inom de befintliga strukturerna inte kan fortsätta. Det är en risk man måste vara medveten om.

Vad har du på menyn?

Vi blir ofta oerhört stressade av förfrågningar. Stressen är en sund signal, eftersom det vi blir stressade av sällan är förfrågningarna i sig, utan av att systemet vi arbetar inom inte har en vettig process för att hantera dem.

När förfrågningar plingar till i e-posten, eller när någon ringer och vill ha något gjort, så utmanar det flera av våra inre processer: vi tvingas växla uppmärksamhet, anstränga arbetsminnet ännu mer, fatta beslut på otillräcklig kunskap eller beslut om vi ska anstränga oss för att skaffa mer kunskap även om vi inte vet om det kommer att löna sig osv osv.

Detta får sekundära effekter: vi anar en ökad risk att misslyckas inför oss själva och dem vi känner har ett inflytande på oss, vi undrar vad som händer med relationerna till folk om vi kanske tvingas säga nej till dem nu, vi upplever oss trängda med ett krympande antal valmöjligheter, och den allmänna osäkerheten ökar när systemet på grund av allt detta blir mer oförutsägbart.

Vi är byggda för att bli stressade i de lägena, och om du inte erfar den stressen så är du att gratulera för då har du antingen utvecklade personliga strategier som skyddar dig eller så arbetar du på ett ställe där ni har systematiska sätt att möta detta på. Personliga strategier är en sorts första hjälpen, men smidiga arbetssätt handlar om att lösa problemet vid roten genom att göra strategierna gemensamma och tydliga.

Människans stressystem är byggt för att trigga fysisk respons (slåss, springa etc), stänga av känslor och intryck utom ett fåtal (tunnelseende), och inte blanda in det långsamma analytiska och energikrävande förnuftet. Den som funderar för mycket under en tigerattack blir lunch. Människans stressystem är alltså inte byggt för kunskapsarbete. Därför ska kunskapsarbete alltid utformas så att stressystemen inte aktiveras. Och det är det vi gör med hjälp av tjänstemodeller.

Tanken är enkel: för ett arbetssteg vi upplever som sårbart (t ex mycket av det vi gör på kontoret) separerar vi mottagandet av förfrågningen från utförandet. Att utföra är proaktivt, att hantera förfrågningar är reaktivt. Om vi inte skyddar utförandet från förfrågningarna kommer utförandet alltid att haverera.

Jag vet inte hur många organisationer jag sett där förfrågningar skickas som e-postmeddelanden eller telefonsamtal till individer, där man jagar individer, där man i princip försöker tjata sig till att individen ska byta prioritering och ägna sig åt en själv, oavsett vad detta innebär för hela organisationens förmåga att skapa värde. Detta skapar sårbara flödessteg där utförandet tar enorma mängder stryk.

För att minska stressen behöver man se över arbetsgången för de olika förfrågningar som skickas på en. Helst gör man det i grupp, och formerar sig kring en gemensam inkorg för förfrågningar som man sedan samarbetar om. Det skapar en mycket mindre sårbar organisation utan så stora personberoenden. Men även om man tvingas agera individuellt är angreppsättet detsamma: ställ frågan Vad har jag på menyn?

Ofta tror man att man har en meny som är mycket mindre än vad den är. Jag möter t ex systemutvecklingslag som tror att de har två saker på menyn: planerad utveckling och buggfixar. Men i verkligheten efterfrågar folk en massa saker från dem: tekniskt säljstöd, uttala sig om något, estimera en framtida lösning osv: och för inget av detta finns det en ordnad arbetsgång. Det rings och jagas istället.

Så skriv ner din meny. Vad har du lovat, implicit eller explicit, din omgivning att göra för dem? Inom vilka tidsramar? Inte sällan förväntar sig folk bara ett fåtal saker från dig, låt säga tre. Men de kan ha flera olika uppfattningar om vilka tidsramar som bör gälla: nu, inom några dagar, eller längre fram. Det kan vara en god idé att tänka på dessa som sex eller nio olika tjänster, för arbetsgången för den snabba pucken är inte alltid densamma som för den långsamma.

Ett nästa steg kan vara att se hur detta du lovar att göra, och när, passar in i det värdeskapande flödet. VARFÖR ska du överhuvudtaget göra det? För det är kanske inte någon bra idé att ägna möda åt att specificera ett arbete som ändå inte ger så högt värde. Och omvänt: om man vet varför det ger ett högt värde så blir det lättare att utforma arbetet bra. Men det får vi ta en annan gång.

Priolistan, hur man ökar värdet i en kö

Vi såg hur effektivt det är att beskriva sin verksamhet som ett flöde där vi steg för steg förädlar ett värde åt någon. Vi såg också hur ett dragande flöde skyddar varje steg från överlast och skyddar hela flödet från ojämnhet. Men eftersom det ofta finns tryck, åtminstone i början av ett flöde vid ärendemottagningen, så kommer det någonstans uppstå en ansamling av obehandlade ärenden. Inflödet är ofta större än utflödet. Vi såg hur en enkel kö troligen är den sämsta strategin för att hantera detta.

För alla ärenden i ansamlingen är troligen inte lika viktiga, sett ur hela flödets synvinkel. Om man istället kan hitta principer för att värdera och prioritera ärendena kan vi inrikta oss på att göra det som i varje stund är mest värdefullt. Inom sjukvården kallar man det för triage (efter franskans "sortera/utvälja"), för att se till att de mest brådskande akutpatienterna får hjälp först. I metoden Scrum i systemutvecklingen lägger man ärendena i en backlogg och kräver att en person, som man kallar Produktägare, med hela organisationens mandat i ryggen prioriterar mellan dem.

Medan det inte alltid fungerar så bra att peka ut en enda människa att i ensamt majestät prioritera (som man gör i Scrum), så är det riktigt att prioriteringen måste ske med hela organisationens mandat. Hur man väljer att prioritera i ansamlingen av ärenden inför ett steg, kommer nämligen inte att bara påverka det steget. Det kommer att styra hela flödets beteende.

Nu blir det lite svårt. Det finns ofta ingen på nivån ovanför flödesstegen som har kunskap och insikt om detaljerna i flödena för att kunna diktera villkoren på ett bra sätt, och det blir därför ofta fel när de gör det. Inom IT ser vi ständigt beslut om prioritering som fattas utifrån ett snävt perspektiv utan hänsyn till tekniska realiteter, vilket orsakar stora problem. Men att delegera är inte heller lösningen: den som prioriterar ärendena för en del av flödet kommer att suboptimera utan insikt om helheten.

Lösningen är att dels hitta de i samarbetet som bäst kan ta tillvara den glada mottagarens intresse genom hela flödet; och dels att alla de som samarbetar om flödet sammanstrålar inom ramen för sitt förbättringsarbete för att hitta och ta bort alla hinder för ett smidigt flöde. Ledningens ansvar i den processen är att ge golvet förutsättningarna (mandatet och förmågan) att förbättra flödena.

Jag kommer att återkomma med konkreta tekniker för hur man kan arbeta med att bestämma sin prioritering.

Infarkten

När flöden är tryckande finns inga garantier för att undgå överlast i dem. Effekten av överlast är ett tvärstopp. Men innan dess har saker påverkats: redan när du närmar dig det absoluta kapacitetstaket går processen långsamt. Jämför med att försöka ställa upp lite för många koppar på en kökshylla. Det går snabbt i början, men sedan börjar pusslet för att få plats med alla.

När saker börjar gå märkbart långsammare på ett ställe i flödet kommer de att orsaka trögheter, överlast, och ojämnhet även på andra ställen. Dessa kan i sin tur orsaka ännu mer tröghet och obalans som orsakar mer som orsakar mer.

Förseningen ledde fram till att projektledaren hann sluta och det ledde till att den nya projektledaren inte lärde sig lika bra och vissa fel släpptes igenom och för att komma ikapp försökte folk jobba dubbelt men då gick det ännu trögare och...

För att inte drabbas av varken överlast eller ojämnhet måste flöden vara dragande. Folk ska själva dra till sig ärenden att arbeta med. Ingen tjänar på att trycka arbete på någon annan. Det finns psykologiska skäl att låta bli, det finns matematiska skäl att låta bli, och den stora faran är om dessa effekter samverkar och skapar en infarkt.

Ibland kan man inte göra på något annat sätt. Inflödet av ärenden kan inte stoppas. Då blir det en ansamling. Vi såg förut hur köer nog är det sämsta sättet att hantera en ansamling på. Ett bättre alternativ är behovslistan, "backloggen". Den tänkte jag skriva en hel serie inlägg om. Men först ska jag till Agile Tour Vilnius och prata lite.

De usla jonglörerna

Det spelar ingen roll vad du säger i ditt CV eller på anställningsintervjun: Du är faktiskt inte bra på att hålla många bollar i luften samtidigt.

Det kan hända att du utvecklat strategier för att uppgiftsväxla mer effektivt inom vissa fält, och det kan hända att du har ett riktigt gott arbetsminne och stor förmåga att rikta uppmärksamheten. Det är naturligtvis intressant att veta, men frågan är varför du ödslar sådana förmågor på det spill som kallas uppgiftsväxling.

Rutinärenden kan vi automatisera i våra hjärnor och vi behöver därmed inte blanda in så mycket av vårt medvetna tänkande. Om vi gör något som tar vissa sinnen i bruk gör det inte så mycket om vi samtidigt gör något som tar andra sinnen i bruk. Det går med andra ord att lyssna på radio och vika tvätt samtidigt. Vi kan klara oss med partiell uppmärksamhet på varje uppgift.

Men ska vi göra två saker samtidigt, och dessa tar samma hjärnresurser i anspråk, så tvingas vi till ständig uppgiftsväxling mellan dem. En uppgiftsväxling innebär att vi måste flytta uppmärksamheten till det nya, bygga upp en ny mental bild av det nya, orientera oss i den bilden för att komma på vad vi ska göra, och sedan börja göra det.

När uppgiften är kognitivt enkel och inte skiljer sig så mycket från den förra uppgiften (som t ex i Henrik Knibergs namnskyltsexperiment) så blir påslaget minst 20% per sak att växla mellan. Skillnaden mellan att göra två namnskyltar en i taget respektive två samtidigt är i bästa fall cirka 20%.

När uppgiften är kognitivt svår blir den nya bilden i huvudet mycket mödosam att bygga upp. När man programmerar är det ju inte ovanligt att det kan ta en timme innan man åter befinner sig i den konceptuella värld som är systemets ännu orealiserade mekanismer och kan navigera i den obehindrat.

Blir man avbruten där har man dessutom problemet att insikter man gjort mentalt men som ännu inte omvandlats till kod försvinner. Ledtiden vid växling består alltså inte bara av att bygga upp det nya, utan även av att snabbt förpacka sammanhanget kring den befintliga uppgiften på ett sätt som inte gör tiden runt den förspilld.

En av vinsterna med att synliggöra sina flöden är att det går att börja kontrollera dem. Största orsaken till att vi tvingas jonglera mellan flera saker är att flödena har utformats tryckande. De har troligen inte utformats medvetet tryckande, men effekten av designen har blivit sådan. Arbetsuppgifterna ramlar på folk, likt bilar som utan att behöva köa i god ordning kör fram till betjäningsluckor lite hursomhelst.

Men genom att synliggöra sina flöden kan man se var uppgiftsväxlingarna uppstår så att det är möjligt att göra sig av med dem. Systemen måste göras dragande. Och när man synliggjort flödena börjar folk se på vilket sätt de samverkar i flödena. Att balansera arbetsbördor, att utforma strategier för hur man skyddar varandra från händelsestyrt arbete, det blir kort sagt möjligt att styra arbetet överhuvudtaget.

Och man gör sig av med den enorma produktivitetsförlust som uppgiftsväxling och samtidigt arbete utgör.

Begränsa er och bli bättre

Ett sätt att balansera sina flöden är att begränsa antalet samtidigt pågående ärenden i dem. "Limit Work In Progress (WIP)" som det heter. Detta är kontraintuitivt för många: hur kan en begränsning av antalet samtidiga ärenden förbättra flödets förmåga att leverera?

Svaret är trefalt: dels finns det en matematisk (köteoretisk) verklighet som inte bryr sig om våra intuitioner, dels är vi människor ytterst dåliga på att ha många saker igång samtidigt eftersom vi måste aktivt flytta vårt fokus mellan dem, och dels ökar många samtidiga ärenden systemrisken såpass mycket att saker brakar ihop för oss mycket oftare än när vi gör en sak i taget.

Köteori och begränsningar av pågående arbete

Agilisten David Lowe (stolt medlem av Sällskapet För Begränsandet Av Pågående Arbete har gjort en liten film som visar den matematiska sidan av saken:

Scenen är en servering för bilburna där folk i bilar i tur och ordning beställer, betalar, och får sin mat, i tre olika luckor. Luckorna tar olika lång tid, där den sista luckan tar längst tid: 40 sekunder (de övriga tar 20 respektive 30 sekunder). Tillåter du en bil i taget genom hela systemet blir den totala omloppstiden summan av alla luckor: 90 sekunder. Kötiden mellan luckorna är ju noll eftersom alla bara väntar på nästa bil. 90 sekunder är den kortast möjliga omloppstiden.

Genomströmningen är dock bara en bil per 90 sekunder. Kan man inte tjäna mer genom att tillåta fler samtidigt? Filmen visar vad som händer i systemet med olika begränsningar. Man kan konstatera att genomströmningen aldrig blir högre än flaskhalsen, den sista luckan som tar 40 sekunder. En kund var 40:e sekund är systemets maximala kapacitet.

Däremot ökar omloppstiden dramatiskt när man släpper in fler i systemet, eftersom köerna mellan luckorna växer. Med fem samtidiga bilar får du vänta i flera minuter, till största delen i kön till betalningen. Detta utan att systemet förmår hjälpa fler. Ett optimum nås runt 2-3 samtidiga.

Att begränsa antalet bilar i systemet kan alltså förbättra flödet på olika sätt. Notera dock att förmågan att hitta ett optimum förutsätter ett välordnat flöde till att börja med. Tjänsterna i luckorna levereras inom en stabil tid ("is under statistical control" som Deming skulle sagt), och den smala asfaltsremsan gör att ingen bil kan köra fram utan att det först finns en lucka framför att köra fram i (systemet är alltså dragande).

Varierar tjänstetiden och flera bilar kan köra fram till samma lucka samtidigt (systemet är tryckande) är funderingen kring optimala begränsningar i systemet helt meningslösa. Man måste först skapa ett förutsägbart dragande system för att kunna räkna på det. Stabilitet först, utjämning sedan.

I senare poster tänkte jag tala om nästa aspekt av att inte begränsa sig: vår bristande mänskliga förmåga att hålla flera bollar i luften samtidigt.

Sluta börja, börja sluta

OK, så vi har ett flöde där det ena steget trycker på fler ärenden än det andra steget klarar av. Det riskerar att bli en kö av ansamlingen av ärenden, och att blint öka resurserna i vår del av flödet hjälper inte helheten. Vad ska vi göra?

Första steget är att titta från höger. Tänk dig att flödet går från vänster till höger. Längst ut till höger är en glad människa. Det är för den människans skull flödet alls finns. Den människan blir inte glad för att flödet börjar att behandla en massa ärenden. Den människan blir inte glad för att ett visst steg i flödet börjar samla på sig ärenden i en väntekö. Den människan blir inte ens glad om bara delar av flödet blir bättre på att hantera sina ärenden. Den människan blir bara glad om förbättringen leder till att värdet kommer henne till del.

Så vad kan vi göra för att ta bort de sista hindren? De som hindrar ärendena från att ta det sista klivet till FÄRDIGT? Sedan: vad kan vi göra för att ta bort de näst sista hindren? De som hindrar ärendena från att ta det näst sista klivet till steget omedelbart innan FÄRDIGT? Och så vidare...

Att ha många saker på gång samtidigt ger en känsla av upptagenhet. Vi förväxlar gärna den känslan med en känsla av produktivitet. Men produktiva organisationer är organisationer där man inte har en massa saker igång samtidigt. Känslan i en produktiv organisation kan tvärtom vara rätt sömnig. Men det är ju för att man har sina saker under kontroll. Man levererar i ett stadigt tempo utan detta gigantiska spill som består i att försöka ha många saker igång samtidigt.

Henrik Kniberg har skapat ett enkelt experiment som avslöjar hur mycket omställningstid som förbrukas när en verksamhet försöker göra flera saker samtidigt. Jag har själv kört det experimentet som en övning på mängder av kurser, och resultatet är hela tiden det samma: När man har några parallella projekt igång blir tidsåtgången minst den dubbla jämfört med om man skulle göra en sak i taget.

Genom att börja från höger och metodiskt arbeta bort alla hinder för att leverera färdiga ärenden så ökas genomströmningen och väntan i flödet försvinner, ett steg i taget. Vi tittade på hur kapacitetsökningar i allmänhet är dåliga på att förbättra hela flöden. Att arbeta metodiskt från "höger", dvs från flödets mål: den nöjda människan, är däremot bra. Ha fokus på att avsluta ärenden, att få dem färdiga. Ha inte fokus på att påbörja många saker.

I nästa inlägg ska jag beskriva hur man kan begränsa antalet ärenden som får lov att befinna sig i varje steg, och hur den stelbentheten tvingar fram ett snabbare flöde.

Den fåfänga kapacitetsökningen

Om ett steg i ett flöde får ärenden i snabbare takt än det hinner behandla dem uppstår som sagt ansamlingar som vi tvingas hantera. Vi såg i en tidigare post hur köer är ett dyrt sätt att hantera dem. Är det bättre att öka kapaciteten?

Det är i alla fall lätt att dra slutsatsen att steget har för låg kapacitet. Att öka kapaciteten (tillföra mer resurser av något slag) är en förståelig impuls. Problemet är bara att detta inte nödvändigtvis gör hela flödet bättre. Den glada människan i slutet av flödet blir inte lyckligare av att en liten del av flödet fungerar något bättre. Det är färdiga saker som ger värde. Saker som ramlar ut i slutet av flödet.

Ökas kapaciteten i ditt steg kanske du överproducerar och skapar en ansamling inför nästa steg. Då har du egentligen inte löst någonting, bara flyttat problemet ett snäpp åt höger. Till en kostnaden av kapacitetsökningen dessutom.

Ökas kapaciteten i hela flödet ("Vi anslår mer resurser till hela verksamheten!") kan det hända att du får totalt sett mer ut av det. Men det är långt ifrån säkert! Om flödet i princip ser ut som tidigare, fast har en jämnt fördelad ökning av kapaciteter på olika håll, kommer du inte bara att producera mer nyttigheter utan även mer spill. Detta kan leda till överlast som blockerar än mer, så att slutresultatet är värre än innan.

Flöden är komplexa saker, och flaskhalsar flyttas runt när obalanser får systemet att skaka. Utfallet är inte linjärt mot insatsen. Man kan säga att alla obalanserade flöden lider av konstant resursbrist, oavsett den totala mängden resurser, eftersom någon del alltid kommer att vara underdimensionerad i förhållande till sina grannar.

Det rätta sättet att hantera den lokala kapacitetsbristen är att jämna ut flödet. Balansera det. Hur det kan gå till tänkte jag beskriva som nästa strategi.

Köer

Lite mer om flöden (fortsättning på detta inlägg) då...

Om varje steg i ett flöde jobbar dragande, dvs drar ärenden från steget innan, så blir inget steg överlastat, och flödet blir utjämnat (både överlast och ojämnhet är ju kända källor till spill).

Men flödena startar någonstans. Ärenden skapas utan hänsyn till flödets faktiska kapacitet. Det är inte akutintaget som bestämmer antalet patienter, utan den mängd olyckor och plötsliga sjukdomsfall som sker. Beställningar om ändrad systemfunktionalitet kan komma plötsligt och vara mycket högt prioriterade. Och flödet kan även själv innehålla steg som på samma sätt trycker ärenden till andra.

När ett steg agerar tryckande i en snabbare takt än vad nästa steg hinner med att behandla uppstår en ansamling av ärenden. Den måste man hantera. Jag tänkte beskriva några strategier i denna och kommande poster, tillsammans med kommentarer.

Kö - En kö är en ansamling där man säger att det ärende som väntat längst ska behandlas först. Man betar av dem i turordning. Denna strategi kan uppfattas som rättvis, eftersom kapacitetsbristen drabbar alla ärenden lika. En annan upplevd fördel är att kön är ett bevis på att nyttjandegraden av stegets resurser är 100%. Primitiva suboptimerande ekonomiska modeller ser lägre nyttjandegrad som spill och föredrar istället köer. Problemet är att värdet i ärenden som har en kortare genomströmningstid ofta är många gånger högre än ärenden som måste vänta; varför man snabbt förlorar stort på denna "besparing".

Grundproblemet är förstås att modellen bara beaktar flödets kostnader, utan att ställa dem i relation till flödets värdeproduktion. Att optimera på att resurserna ska vara tillgängliga så mycket som möjligt är ofta bättre. Att lägga ärenden i en kö är inte sällan den sämsta strategin. Om flödet består av flera steg där varje steg är överlastat på detta sätt, kommer ett ärende ha enormt långa ledtider där ärendet tvingas vänta på att tas omhand.

Och väntan, när ingen ökar värdet på ärendet utan det bara ligger och skräpar, är som bekant spill.

Bilden är från Boxoid och visar en resurs - en väg - som har en nyttjandegrad på nästan 100%. Varenda kvadratmeter av asfalten är täckt av bil. Visst måste det vara effektivt?

Flöde, möda, och nytta

Att inse att all värdefull verksamhet är ett flöde som i slutändan gör minst en människa glad är en beprövad metod att skaffa sig ett tankesätt som driver ut spill och osmidigheter. Leanpionjären Deming beskriver det som ett motgift mot ett par av de "verksamhetens dödliga sjukor" han beskriver i boken Ut ur krisen. Kartläggning av värdeströmmen är ett vanligt sätt att jaga slöserier i till exempel en tillverkningsprocess eller en vårdkedja. En mjukvaruskapande organisation skildrar sitt värdeflöde i en behovslista och en flödestavla.

Ett flöde tar ett ärende (en patient, en kund, ett råvaruämne, en önskad mjukvarufunktion) och omvandlar det - steg för steg - till ett levererat värde (färdigbehandlad patient, nöjd kund, färdig produkt, implementerad och levererad funktion) i händerna på någon (till exempel patienten eller kunden själv).

Vi behöver alltså identifiera vilka steg ärendet tar. I de fall där ett arbetslag arbetar tillsammans nära varandra med ett ärende i taget behöver man oftast inte dela upp värdeskapandet i diskreta steg. Där sker arbetet dynamiskt människorna emellan, och spillen är ofta inte av en sådan art att de synliggörs med t ex en flödestavla utan uppträder mer subtilt. Men när värdet skapas i en sekvens som innefattar att ansvaret för ärendet i någon form överlämnas från ett lag till ett annat, är det bra att visualisera det som om ärendet går från ett steg till ett annat.

Ett vanligt fel när man tänker på sitt värdeflöde är att man skiftar fokus från nyttan till mödan. Vi människor har ingen spontan känsla för värde, däremot har vi en väl utvecklad känsla för om vi arbetar hårt eller inte. Vår möda är för oss mycket mer konkret än resultatet av mödan. Vi blir lätt mödodrivna (efforts driven) snarare än nyttodrivna (results driven). Det är därför som känslan av produktivitet är bland de farligare känslorna vi har.

Varje steg ska alltså inte definieras utifrån vilket arbete som görs, utan utifrån vilka små värdefulla delmål som ärendet uppnår. Patienten fick sitt blodtryck taget och den önskade funktionen blev nedbruten i delfunktioner som kan implementeras och utvärderas på två veckor. Här kan en scrumterm hjälpa: delmålet utgör ärendets klarkriterium (Definition of Done) för detta steg i flödet.

På samma sätt behöver vi titta på vilket tillstånd ärendet måste befinna sig i för att på ett någorlunda förutsägbart sätt kunna behandlas i detta steg. Vi måste definiera ett görbarhetskriterum (Definition of Ready) för att kunna bestämma om ärendet ens är görbart.

Det blir nu ganska uppenbart att värdeflödet inte fungerar om inte görbarhetskriteriet för nästa steg är detsamma som klarkriteriet för vårt steg, eller om vårt görbarhetskriterium inte matchar det föregående stegets klarkriterium. Start- och slutvillkoren för våra respektive steg är som kontrakt i flödet. Vi måste samarbeta om dem.

Våra organisationer är tyvärr ofta utformade så att de som hanterar ärendet medan det har lågt värde inte sällan har större makt än de som hanterar ärendet i slutet. Det skapar en vilja att försöka forcera igenom ärenden (tryckande flöde), vilket skapar en enorm mängd spill i form av överlast och ojämnhet. I stället ska flödet fungera dragande, eftersom nästa steg i kedjan vet precis vad som krävs för att nå nästa delmål.

Men om man tittar på stegen tillsammans kommer man att upptäcka ställen där viktiga delar av värdeskapandet ramlar mellan stolarna. Låt företrädarna för efterföljande steg hela tiden ställa krav på de tidigare, och inför nya steg när ni ser att det är ett hopp mellan det ena stegets klarkriterium och nästa stegs krav på ärendet. Man ska kunna se hur ärendet i en obruten kedja får högre och högre värde.

Genom att ha detta fokus på värdet blir både syftet med hela kedjan tydligt, liksom syftet med varje steg. Detta är en nödvändig förutsättning för att kunna organisera själva arbetet, mödan, inom varje steg. Har vi inte koll på nyttan kommer vi inte ha koll på hur vi bör arbeta.

Bilden är från Wikipedia Commons.

Det här blev den första i en serie om flöden:

• Flöde, möda, och nytta
• Köer - om att köer är naturliga men inte speciellt effektiva.
• Den fåfänga kapacitetsökningen - om att den spontana impulsen att öka resurserna när det går trögt inte alltid är så smart.
• Sluta börja, börja sluta - om att lösningen är att påbörja färre saker och istället färdigställa desto fler.
• Begränsa er och bli bättre - och att begränsningar av hur mycket jobb man tar på sig faktiskt kan förbättra genomströmningen i flödet.
• De usla jonglörerna - om att vi är usla på att hantera flera saker samtidigt.
• Infarkten - om det havererade flödets sluttillstånd.

Flödestavlan

Verktygen för visuell styrning kan delas in i olika kategorier beroende på syftet. Processplanscher synliggör gruppens överenskomna arbetssätt. Stora väggkalenderar är ett fantastiskt verktyg för att hålla tidplaner och skapa en gemensam förståelse för vad som brinner i knutarna och vad man kan vänta med. Människokartor som visar vilka människor som huserar var i organisationen sätter ett ansikte på var och en och ökar vi-känslan (till skillnad från organisationskartor som gömmer bort att det är folk inblandade).

Och så har vi förstås den traditionella flödestavlan, känd från produktionsplaneringen och systemutvecklingen.

Idén bakom flödestavlan är att den ska få alla att se var olika ärenden befinner sig i värdeflödet. Annars har vi lätt att tänka att ärenden tillhör den-eller-den organisationsdelen eller är den-eller-den människans ansvar; vilket är sätt att tänka som skapar mycket spill.

I en flödestavla representeras varje ärende av ett kort som löper från vänster till höger. Kortet hoppar fram mellan olika kolumner, där varje kolumn motsvarar ett moment där ärendet antingen arbetas på (för att kunna hoppa till nästa kolumn), eller där ärendet vilar.

Vissa flöden är mycket detaljerade, med många kolumner som visar varje arbetsmoment. Men det finns också flöden som likt den traditionella flödestavlan i Scrum bara visar om ett ärende ska göras, arbetas på, eller är färdigt.

Vilken grad av detaljrikedom som krävs måste gruppen som har nytta av tavlan bestämma. Det finns en frestelse i att detaljera allt, vilket skapar merarbete och kan orsaka brist på nödvändig flexibilitet. I synnerhet finns en frestelse att från ledningshåll vilja detaljera allt, så att ledningen utifrån tavlan alltid ska få rätt slags rapporter. Det är ett misstag och ett stort slöseri. Flödestavlan ska koordinera samarbeten runt smidiga värdeflöden, för dem som har behov av denna koordination, och inte vara till för någon annan. Det finns betydligt bättre och effektivare sätt för en ledning att skaffa sig kunskap om sakernas tillstånd i värdeflödena.

Skälet till att ett Scrumlag klarar sig med den allomfattande kolumnen "Arbetas på" är att man svärmar runt ärendena. Laget jobbar tillsammans och har inte behov av att koordinera sig med hjälp av verktyg, eller att formalisera sin interna process. Kolumnerna "Att göra" och "Klart" är däremot samarbetspunkter där andra intressenter lämnar över eller tar vid.

På samma sätt kan man resonera i alla flöden: när samma lag behandlar ett ärende finns kanske inte behovet av att detaljera hur det görs. Det får i så fall laget bestämma, kanske är värdeprocessen såpass komplex att visualisering hjälper. Men när olika grupper av människor måste samarbeta, till exempel om att prioritera ärenden, eller precisera och bryta ner dem, då är separata kolumner på en flödestavla ett utmärkt hjälpmedel för att få alla som inte jobbar tillsammans dagligen att förstå hur landet ligger.

Det finns mer att säga om flödestavlor, till exempel om hur köer på tavlan kan vara både bra och dåligt, och hur man genom att ändra regelverket runt tavlan kan få flödena att bli bättre på olika sätt. Och inte minst hur man kan använda data från tavlan för att kunna göra prognoser. Men det får bli en annan gång, det är söndag morgon och jag ska till kyrkan.

Bilden visar en scrumtavla hos en av mina kunder.

Dokumentation?

Det agila manifestet för mjukvaruutveckling säger att man bör värdera fungerande mjukvara framför utförlig dokumentation. Slarviga läsare har tagit den raden som skäl att strunta i allt vad dokumentation heter, och ängsliga processmänniskor har tagit raden som skäl att bli oerhört tveksamma till metoder som kallar sig "agila". En process som inte förskriver precis vilka dokument som behövs kan ju inte vara en bra process, eller hur?

Men som sagt: Agilt är ingen process eller beskrivning av en metod. Agilitet är en egenskap ett samarbete kan behöva (tillsammans med slankhet, styrka och uthållighet) för att bli smidigt. För att kunna tackla frågan om dokumentation behöver man förstå varför manifestets undertecknare skrev som de gjorde.

Vad är syftet? Detta är alltid den första frågan. Att undra över hur man gör (t ex med dokumentation) är en signal om att man kanske inte har målet riktigt klart för sig.

Syftet, slutpunkten i alla värdeprocesser, är alltid minst en människa som blir glad över något. Vilka ska använda dokumentationen? Till vad?

När det gäller tjänster (och fungerande mjukvara är en tjänst) finns det två huvudsakliga lägen: du utvecklar tjänsten, och du utför tjänsten. Det agilister och lean-folk har upptäckt är att precis, kortfattad och lättförståelig dokumentation är nödvändig för att kunna utföra tjänsten rätt. En processbeskrivning gör att vi inte brakar ihop när läget blir pressat. Vi vet hur matbiten ska stekas, vi kan söka upp det kodstycke där felet i inloggningsrutan troligen finns, vi vet att krutladdningen som ska spränga bort dörren och blåsa upp flygplanets nödrutschbanor faktiskt är apterad. "Cabin crew: arm slides! Cross-check and report!"

Så dokumentation över hur saker fungerar ingår i tjänsten som utvecklingen levererar. Ingen tjänar på att den är extensiv och sitter i tjocka pärmar eller ligger på ett intranät. Däremot att den är lätt att hitta och hitta i. Planschprincipen, att all processdokumentation ska sitta i form av planscer på väggarna, ett ögonkast bort, är ett sätt. Människan som behöver dokumentationen behöver den fort, i en form som är anpassad för hennes hjärna.

Men hur är det med dokumentation för att utveckla själva tjänsten? Här brukar det finnas mycket att tjäna. Som det heter i den här utmärkta vägledningen för agil dokumentation: "Well-written documentation supports organizational memory effectively, but is a poor way to communicate during a project."

Det visar sig nämligen att tjänster i osmidiga organisationer gärna utvecklas i silos, att olika discipliner sitter på varsin kammare och klurar på sin del. Delarna lämnas sedan över till nästa kammare, och nu måste dokumentationen vara mycket omfattande för att informationen ska kunna klara av denna överlämning utan att sippra bort.

Men ändå sipprar det bort, för information överförs inte bäst med hjälp av dokument. Att utveckla en tjänst är att samla in, raffinera, och slutligen - vid behov - kodifiera denna kunskap. Det gäller mjukvara (mjukvara är kodifierad kunskap) och det gäller arbetsrutiner vid en hotellreception. Bäst på kunskapsraffinering är de som har de effektivaste flödena för att göra gemensamma insikter.

Gemensamma insikter görs i dialog. Riv upp alla silos där det går och svärma runt det som ska utvecklas. Om ni måste ha olika avdelningar med tillhörande överlämningar: ta bort all dokumentation som bara finns där för att stödja överlämningen. Ersätt den enkelriktade överlämningen med täta dialoger, och låt den skriftliga dokumentationen bli till i ett gemensamt avdelningsöverskridande samarbete om samma dokument. Och det är alltid de som ska utföra nästa steg i raffineringen som vet vad som behövs; information ska alltså inte tryckas fram i systemet utan efterfrågas från de som ska göra jobbet.

Ni har själva insikten om vilken dokumentation ni behöver. Det gäller bara att våga nöja sig med den.

Bilden föreställer processdokumentationen hos en av mina kunder, publicerat med tillstånd. Så snart man på ett förbätringsmöte/retrospektiv beslutat om att testa en liten förändring av processen (PDca) sätter man en handskriven post-it med den nya varianten rätt på väggen, där man önskar förändringen. Så snart man beslutat om att permanenta förändringen (pdCA) skriver man ut ett papper och förändrar dokumentationen. Planschprincipen, "Standardized work", och "Visual management" i ett kompakt litet smidigt nötskal.

Alltid en människa

En viktig del av alla smidiga tekniker (lean, agilt och så) är att få syn på värdet. Slöserier definieras som: nedlagd möda och material som inte ökar värdet jämfört med alternativen. Man gör värdeströmskartläggningar för att se när processen tillför värde och när den inte gör det. Allt ska underordnas värdeflödet.

Men värden finns inte. Inte i sig själva. Någon måste värdera för att man ska kunna säga att något är värt. Om värden är globala och eviga eller ej, det vet vi inte (här kommer tron in), utan allt vi vet om värden är att det är människor som värderar. Värderar olika, dessutom.

Ett värdeflöde slutar alltså alltid med en människa som blir glad. Med den insikten ramlar många pusselbitar på plats. Själv brukar jag aldrig närma mig en whiteboard som workshopverktyg utan att överst i högra hörnet rita en glad människa i profil. Det hjälper oss som är i lokalen att hela tiden påminna oss om varför vi är där:

Det är alltid en människas glädje, längst ut i slutet av värdeprocessen, oavsett vad vi försöker åstakomma; som är vårt yttersta mål.

Tilliten i systemet

För att öka räckvidden på sin ingrupp ("Öka vi-känslan" som det heter på hurtig konsultsvenska) behöver vi tillit. För att våga exponera resultat vi varit delaktiga i (en förutsättning för att kunna ta kommandot över sitt arbete) behöver vi tilliten att ingen angriper oss därför. Tillit är livsnödvändigt för den goda organisationen.

Det finns individualpsykologiska mekanismer som ökar tilliten. Att bli anförtrodd saker, dvs att någon visar tillit till en själv, ökar både ens egen grad av tillit till andra och ens benägenhet att inte svika dessa förtroenden.

Vi brukar önska mer tillit, vi idealiserar chefen som vågar delegera, och vi längtar efter det tillitsfulla arbetslaget. Hur ska vi nå dit? Chefscoachning på temat "Våga lita på dina medarbetare"? Försäkran gång på gång från ledningen att "Här får man misslyckas, här får man misslyckas"? Kanske påverkar till viss del, men önskar vi inte mer?

Det finns en faktor som påverkar tilliten mycket starkare än att folk i organisationen kommunicerar vilken tillitsnivå de önskar. Det är ju så att tillit är en ganska skör sak. Om jag som chef anförtror medarbetarna något och de ändå misslyckas gång på gång? Om gruppen inte klarar av sitt självstyre, och jag som en medlem av gruppen hela tiden blir delaktig i felen de andra gör? Om chefer och andra anförtror mig uppgifter, men jag hela tiden underpresterar eftersom det faktiskt är väldigt svårt?

Det som till slut avgör tilliten är inte ambitionen, utan den faktiska förmågan att leverera. Tillit skapas på det plan i vårt medvetande som arbetar med associationer, och vi har lätt att associera människor (inklusive oss själva) med "klarar inte av, klarar inte av". Levererar folk inte det förväntade och önskade, så slås tilliten sönder.

Men samtidigt vet vi att det är systemet mer än individerna inom det som bestämmer resultatet. En organisation, ett samspel, är alltid perfekt riggat för att ge det resultat det ger idag. Känslomässigt knyter vi visserligen tillit till om vi upplever att folk ger oss det vi önskar, men vi vet att det är omständigheterna som styr. Inte folks attityder eller förmåga att kämpa emot ett skakigt system.

Tricket är alltså att göra systemet mer värt vår tillit. Förbättras systemet kommer allas förmåga att leverera bli säkrare, och då ökar den mellanmänskliga tilliten till varandra. Vi måste alltså ta ansvar för processerna, så att det blir lättare att åstadkomma ett gott resultat inom dem. Driva ut rädslan för att göra fel genom att göra det svårare att göra fel. Inte genom att försöka inspirera folk att bli mer dumdristiga.

När Deming i sina fjorton punkter om ledarskap pratar om att skapa tillit ("Drive out fear, so that everyone may work effectively") gör han det som en kommentar till den föregående punkten om det viktiga ledarskapets roll, och då inte om ledaren som inspiratör och hejarklack utan en som ser till att processerna åstadkommer en trygg och produktiv miljö. Verksamheten ska inte vara så skör att folk blir rädda för att ta ansvar för delar av den.

Det finns i de smidiga arbetssätten många exempel på tekniker för att förbättra systemen. Jag har nämnt vissa redan här på bloggen och jag tänker skriva om fler. Men jag tänkte avslutningsvis i det här inlägget lyfta fram tre principer, som på ett särskilt sätt ökar just tilliten.

Det första är transparens. Ett system kan fungera riktigt dåligt och ändå inte vara en otrygg plats, om alla bara får omedelbar återkoppling från systemet självt om hur resultatet av deras olika vägval. Är du som chef obekväm med att delegera är det förmodligen av goda skäl, troligen är systemet för otydligt för att du ska vara trygg. På samma sätt upplever den som ska ta på sig arbetsuppgifterna en otrygghet. Men varje lättviktig synliggörandeteknik (korta cykler mellan avstämningarna, arbetstavlor som visar värdeflödet etc) motverkar detta.

Det andra är automatiska nödstopp, principen som på japanska kallas jidoka. Det gör att problem inte sprider sig när de uppstår. När en maskin löper amok ska hela produktionskedjan stoppas, när balansräkningen i ett företag börjar se ut på ett visst sätt ska styrelsen och VD genast tänka om, osv. Tokigheter uppstår, men vi ska tryggt kunna lita på att inget tokigt fortgår.

I Scrum sätter man till exempel upp ett sådant jidoka-larmsystem när det självstyrande utvecklarlaget larmar beställaren/kravchefen så fort de märker att delmålet för den pågående 2-4-veckorsperioden inte kommer att nås. Ingen behöver nervöst följa upp att de når målen, utan kan tryggt lita på att de får en omedelbar signal så fort det inte är fallet.

Det tredje är samarbeten. När centrala funktioner i verksamheten isoleras till enstaka individer ökar risken för haveriet markant. Genom att samarbeta, svärma, runt värdeflödena uppstår en gemensam syn på vad som sker och vad som ska göras, och ingenting vilar på en enstaka persons stackars axlar.

Allt detta ökar systemets förmåga att leverera, vilket ökar tilliten till systemet, vilket ökar tilliten mellan människor. Rädsla, i synnerhet befogad rädsla, bygger inte tillit.