Kultur och procedur

Det här med mätande som jag pratat om de senaste dagarna är ett typexempel på hur oerhört sammanflätad kulturen är med de konkreta handgreppen och procedurerna man ägnar sig åt. De ger verkligen varandra, som jag skrev om här.

Kulturen i en organisation kan beskrivas som summan av de beteenden som alla förväntar sig ska uppstå i en viss situation. Om medarbetarna på golvet inte själva har tillgång till de handgrepp och beteenden som krävs för att själva kunna ta ansvar för sitt eget förbättringsarbete, så kommer ingen - inte deras omgivning och inte de själva - någonsin att förvänta sig att de ska kunna ta ansvar heller.

Det blir fel när beskrivningar av nya sätt att arbeta enbart fokuserar på kulturskiftet och inte på de konkreta handgreppen och verktygen som de nya sätten kräver. "I en agil organisation litar chefen på medarbetarna!" kan det heta. Men risken är stor att en chef som enbart byter attityd blir besviken. Det troliga är att medarbetarna inte kommer att ägna sig åt att ta över ansvaret för sitt eget arbetssätt, eftersom de inte riktigt vet hur man gör och inte vet vilket mandat de har.

Om vi däremot inför nya arbetssätt, som till exempel systematisk medarbetardriven ständig förbättring, kan dessa driva fram nödvändiga kulturskiften. Medarbetardriven förbättring kräver ett ständigt pågående samtal om var ansvarsområdena går. Det kräver att alla förstår vad en process är, och att processer har en naturlig variation. Detta stöttar en kultur där man inte ser på vems fel saker och ting är, utan istället jobbar på att lösa rotorsakerna till problemen.

Enbart nya handgrepp och beteenden förvandlar i sig inga kulturer. Men kulturer föds i en kontext, och de nya arbetssätten förvandlar just kontexten, samtidigt som de ger nya möjliga sätt att se, tänka, och agera. Så handgreppen och de konkreta verktygen är nödvändiga, men inte tillräckliga, för att få kulturskiftena att äga rum.

Naturlig variation

Ett sätt att missbruka mätningar på är när folk får för sig att det är meningsfullt att över tid mäta en känd variation som är naturlig inom den egna processen, utan att se till orsakerna för utfallet och försöka påverka dem.

Ta ett säljscenario. En säljare ringer tvåhundra samtal i veckan. I snitt resulterar detta i fyra affärer. Men ibland blir det åtta och ibland blir det ingenting. Hur bör säljarens chef agera?

Chefen tror att beröm och andra belöningar förstärker det goda utfallet, så hen bestämmer sig för att berömma (och belöna) de veckor antalet affärer överstiger fyra, och ge kritik de veckor antalet affärer understiger detta. Men eftersom fyra är ett medelvärde kan vi på förhand räkna ut att hälften av veckorna komemr att resultera i kritik och hälften i beröm. Vilken nytta gör denna återkoppling? Ingen alls. Den blir lika godtycklig som utfallet.

Psykologin bedrar oss här, på flera sätt.

Vi tror lätt att variationen i det naturliga utfallet är mindre än vad det är. Våra hjärnor är mönstermatchande apparater som reagerar på utfall utanför ungefär en till två standardavvikelser. Men en åttondel av alla utfall ligger inte där. Utfall som med regelbundenhet faller utanför våra förväntningar borde leda till att vi justerar våra förväntningar.

Vi tror också att utfall är mycket starkare knutet till avsikt än vad det är. Hade säljarens resultat berott på hens goda vilja, då hade beröm och klander kanske fungerat. Men det vet vi ingenting om! I ett modernt samhälle med alla faktorer som påverkar utfallet är kopplingen till den goda viljan ofta svagt.

Istället bör vi tänka så här:

Beröm och klander påverkar beteenden. Det enda en säljare kan påverka är sitt eget beteende, inte allt annat som påverkar utfallet i säljsituationen. Det är det rätta beteendet som borde förstärkas.

Om vi vill öka försäljningen: vilket är det rätta beteendet då? Det vet vi inte förrän vi har analyserat situationen. Om chefen istället lär ut ständig förbättring kommer säljaren själv, eller ännu hellre säljarna själva - tillsammans - att skaffa sig en större förståelse för de faktorer som faktiskt spelar roll. Sedan hittar de varianter i beteendet som de testar för att se om resultatet blir bättre.

Den lyckliga känslan när man rott i land med en affär är alldeles tillräcklig återkoppling. Ingen chef behöver förstärka varken den känslan eller känslan av misslyckande. Särskilt som säljaren inte kan reagera på chefens återkoppling på något meningsfullt sätt.

Det är verktygen för självledarskap, t ex ständig förbättring, som chefen behöver ge de anställda. Vilken tur då att chefen vet hur man gör detta!

Mät dig själv

Mätetal, alltså. Att mäta utan att kunna agera på mätetalet på ett produktivt sätt är slöseri. Inget blir bättre, bara sämre (eller i bästa fall lika illa som tidigare). Tryggheten i mätetalen är då falsk, när vi får en känsla av kontroll utan att faktiskt kunna kontrollera något.

Mätetal som berättar hur bra det går för oss kallade jag hälsoindikatorer. De måste mäta hela värdeflöden, eller åtminstone stora stycken av dem. Resultatet i en del av ett flöde säger som bekant oftast ingenting om hela flödets förmåga. Tvärtom kan ofta en för bra prestation i en del av flödet förstöra för helheten. En alldeles för duktig säljare som säljer mer än vad resten av verksamheten förmår leverera till exempel. Överlasten det medför innebär inte sällan en större kostnad än den ökade intäkten.

Men hälsoindikatorer kan vi inte agera på direkt. Vi måste analysera kvalitativt och ta reda på varför utfallet är som det är. Vilka påverkansfaktorer finns? Kan vi pröva varianter på vårt sätt att arbeta för att se om hälsan i flödet blir bättre? Alltså helt vanligt kaizen-arbete: medarbetardriven ständig förbättring på empirisk grund. I det arbetet tar vi fram tillfälliga nyckeltal för att mäta resultatet av experimentet. Men så snart vi konstaterat vad utfallet av den nya processen blivit kan vi släppa mätningen. Processen levererar ett visst resultat, med en viss variation, och vi får inte bättre kontroll över utfallet genom att behålla processen samtidigt som vi mäter en massa. Processen är ju som den är.

Däremot är det viktigt att vi reagerar snabbt på destruktiva avvikelser. När utfallet blir katastrofalt måste vi genast slå larm. Vår process måste innehålla en sådan känslighet att vi omedelbart ser och kan agera.

Dessa tre sorters mätvärden kan vi använda produktivt, om vi kan lita på dem och styra med hjälp av dem. Men observera att det kräver att vi mäter oss själva! För en hälsoindikator är det självklart. Sitter jag i en ledningsgrupp och ska mäta hur hela flödet mår, så mäter jag samtidigt min egen grupps förmåga att leda flödet. Att mäta hur de enskilda delarna i flödet mår ger mig ingen värdefull information om helheten.

Framförallt kan jag inte styra på mätvärdet, om jag mäter någon annan. Som din chef vet jag ju inte bättre än du vad som orsakar utfallet. Du är närmast golvet, gemban, och har tillgång till bättre information än jag. Om du mäter dig själv så kan du också åtgärda problemen själv. Om du trots information saknar förmåga att mäta dig och ta ansvar för din egen process är det mer effektivt om du får den förmågan än om någon annan tar ansvaret ifrån dig.

När det gäller larmvillkor så är dessa en överenskommelse. Larm betyder att någonting ska eskaleras. En grupp eller avdelning som utför någon sorts arbete gör detta på förväntat sätt och hanterar sina egna anomalier inom sina egna ramar. Men så snart de inte själva kan hantera det behöver någon annan gripa in. Mellan gruppen som utför och gruppen som griper in måste det finnas en överenskommelse om när det ska ske och hur. Men fortfarande är det gruppen som utför som är närmast golvet och som har störst chans att utveckla en tillräckligt känslig process som larmar i tid. Även där gäller principen om att man bör mäta sig själv.

O Heliga Mätetaaaaaal!

Ett fenomen jag stött på flera gånger: Viljan att ha mätvärden för mätvärdenas egen skull.

— "Nu när vi inför agilt vill vi ha mätvärden. Varje team måste ta fram KPI:er!"

— "Gärna det! Vilka KPI:er är verksamheten intresserade av?"

— "Alltså, det vet vi inte. Men vi måste ha mätvärden *mumlar något om kvalitetscertifiering*! Ni agilister gillar inte mätvärden, eller?"

— "Tvärtom, vi älskar all empiri! Att mäta är viktigt så att de beslut som folk tar baserar sig på saklig grund och inte på gissningar."

— "Bra! Så då inför ni mätvärden? KPI:er?"

— "Gärna det! Vilka KPI:er är verksamheten intresserade av?"

— "Men det var väldigt vad du slingrar dig! Jag tror inte att ni agilister egentligen vill mäta! Jag tror ni är hippies! Lyssna: en professionell och storskalig verksamhet behöver mätvärden för att kunna styras! Vi måste ha kontroll! Mätbarhet! Förstår du?"

— "Ja, absolut! Vilka KPI:er är verksamheten intresserade av?"

Mätbarhet är viktigt men inget självändamål. Mätetal är förenade med stora kostnader och stora risker, så det vill till att vi vet vad vi ska ha värdena till. Peter Druckers lite aningslösa syn på nyckeltal mötte tidigt kritik från leanpionjärer, inte minst från statistikern William Deming som visste att siffror kan vara förrädiska. Risken är jättestor att nyckeltalen leder helt vilse. Ankringseffekter, Goodharts lag, falsk trygghet; listan på störningar och skevheter som nyckeltal bidrar med kan göras lång.

Det finns mycket att säga om mätetal (och en del har jag redan sagt), men det viktigaste för en agilist är att mätetalet dels måste mäta något mätbart värde, och att mätetalet måste kunna användas för att öka värdeskapandet. Kan du inte agera på mätningen så är mätningen onödig och störande. Mäter du fel sak, så är mätningen farlig eftersom den kan få dig att styra åt helt fel håll.

I många organisationer betraktas nyckeltal som nästan heliga. När man kommer med nya arbetssätt så blir man ofta tillfrågad om relevanta nyckeltal, precis som i dialogen ovan. Siffrorna ska liksom bara vara där. Men för en lean/agilist är inte metoden ett självändamål. Det är värdeutflödet, det som metoden är tänkt att uppnå i den aktuella organisationen, som är viktigt. Därför är mitt svar alltid en motfråga: vilka värden är det som är viktiga för er?

När organisationen inte kan svara på den frågan så vet jag att vi har ett större problem framför oss än frånvaron av mätetal i en metod. Vet vi inte vad som är värdefullt vet vi inte vilken effekt metoden är tänkt att få hos oss, och då är det inte säkert att vi ens ska införa metoden.

Culture! is...?

(This post was triggered by a discussion on culture change I had with some English speaking fellow agilists. I write in English for them.)

Sometimes you end up wondering if culture begets behaviour, or if culture is a consequence of the behaviours that flourish. Depending on how you define culture, the answer will of course vary, but if culture is a common expectation of how we and others ought to behave given a certain set of circumstances I say that both are correct. Behaviours form expectations, and expectations affect our behaviours.

One idea that I have a hard time to grasp is the idea that you have to change the culture in an organisation before you can alter the behaviours that are prevalent there. I wonder how one can accomplish that at all. What, besides behaviour, can transfer knowledge about people's expectations? How is culture communicated, other than by behaviour?

We can communicate expectations and be clear in our reactions when people behave in an untolerable manner.

Behaviour can be affected by conscious action. It is how people act and react that in time will form culture, so by affecting actions and reactions, we will change culture. Rules and regulations often lack power in themselves to change culture, but sends a clear message and creates a formal backdrop. If we raise awareness on how we actually behave, we might inspire an urge to change, and by providing alternatives we make the change possible.

Action needs decisions, and decisions are made out of feelings, how we spontaneously evaluate a situation. That evaluation is made in a context formed by interpretation patterns we inherit from our past. By reflecting about the past, and bring new words and images onto the table, we will affect how things are framed.

No single tool will change culture. But culture isn't static. It is either sustained by current words, images, and behaviours; or it is changed by us when we change. So let's change.

Jag vet varför jag gör det här

Jag vet precis varför jag gör det här.

I början av min systemutvecklarbana deltog jag i ett projekt som göra en enkel migrering av ett administrativt system. Men ingen hade frågat användarna om vilka aspekter av det gamla systemet som var de viktiga, så vi råkade - trots all god vilja, kunskap, och möda - att leverera ett system som gjorde användarna arga och frustrerade. Varje dag på jobbet.

Jag har varit i organisationer där hög svansföring och rätt kläder betytt mer än faktisk kompetens. Där duktiga människor farit illa och min egen självkänsla fått törnar av medicinsk valör.

Jag har sett folk utsatta för konstant stress, inte för att arbetet i sig är jobbigt, utan för att själva arbetsplatsens organisation håller alla - även chefen - i ett fängelse. Uppföljningsverktyg och befintliga rutiner och intrasslade mandat har blockerat all förbättring.

Jag har sett lönsamma och roliga ställen förvandlas till förlusttyngda och deprimerande arbetsplatser, bara för att någon fått för sig att försöka hålla nere en viss kostnad och inte sett hur den suboptimeringen helt förstört den produktiva strukturen (och på så sätt kostat många gånger mer).

Lean och agila metoder löser inte alla problem. Jag har sett lean och agila metoder införas, och att införandet har lett till både kaos och ännu mer toppstyre.

Men om man inför det som man ska (och det är inte så svårt att veta vad som är rätt sätt), så sätter metoderna fingret på de strukturella hinder till smidighet organisationen lider av. Metoderna erbjuder också verktyg för att ta bort de strukturella hindren, om bara mandatet att använda de verktygen finns.

Jag har sett folk få mer frihet, bli betraktade som dugliga och professionella människor snarare än heltidsekvivalenta resurser, och få bättre kontroll över sin egen situation. Jag har sett chefer som börjat se sina medarbetare på ett nytt sätt. Som minskat på detaljpillet.

Jag har sett rädsla försvinna och ersättas av förtroendefullt samarbete. Jag har sett kostnader sjunka. Jag har sett intäkter gå upp. Jag har sett kvaliteten öka tillsammans med arbetsglädjen. Jag har sett gladare kunder, snabbare hjälp, och möjlighet att hjälpa dem flera gånger så att det till slut blir helt rätt.

Och sett folk ta det lite lugnare samtidigt som de fått uträttat så mycket mer. Så jag vet precis varför jag gör det här.

(Länk till Arbetsmiljöverkets rapport. En tredjedel av all arbetsplatssjukdom har organisatoriska och sociala faktorer. Helt i onödan.)

Skalningsdimensioner och vektorer

Jag kom hem ifrån konferensen Agila Sverige med en hejdundrande förkylning (vilket troligen förklarade min trötthet och förvirring under själva konferensen) samt med en massa oavslutade samtal runt storskalighet. En del av samtalen har fortsatt på twitter och i epost, och en del av dem har rört det jag ofta återkommer till: skalningsdimensioner.

Att det finns många personer i organisationen är inte i sig ett kriterium på att man har behov av skalbarhetstekniker. Om de många personerna är organiserade i små självorganiserade arbetslag som oberoende av varandra kan leverera nytta och värde minst var fjärde vecka, så behövs inga andra agila tekniker än dem man använder sig av i en liten organisation.

Däremot finns det andra dimensioner som driver behov av ytterligare tekniker än de som t ex Scrum pratar om. Jag brukar tänka på dessa tre dimensioner:

Tid. Ibland (för att inte säga ofta) är det svårt eller omöjligt att leverera kundnyttor på kort varsel. Tiden för att skapa en nytta beror av trögheter i informationsflödet i organisationen. Är trögheten stor kommer det att ta tid, oavsett hur hårt alla arbetar. Arbetar man med mjukvara finns det dessutom alltid en underliggande komplexitet i plattformen som gör det trögt. Nytta på kort varsel är i mjukvarusammanhang svårt.

Konceptet med sprintar (som i Scrum) är en skalningsteknik för att hantera detta. Vi vet från lean att det mest värdefulla sättet att leverera nyttor på är ett kontinuerligt utflöde av en välbehövlig nytta åt gången. Men mjukvara behöver oftast modifieras batchvis, på grund av alla interna beroenden. Därför har man sprintar där ett tvärfunktionellt arbetslag levererar en handfull nyttor efter en två-till-fyraveckorsperiod.

När tiden mellan nyttorna på grund av underliggande trögheter måste utsträckas utöver det, då kan man använda Leffingwells uppdelning i hela nyttor och delnyttor ("features" och "stories" i SAFe), och man kan använda story mapping (Patterson) och olika slicing-tekniker (Cockburn) för att maximera värdet av varje delnytta.

Komplexitet. Det tvärfunktionella arbetslaget ska helst kunna skapa fullständiga nyttor genom att genomföra förändringar på alla nivåer i plattformen. Inom systemutveckling pratar man om "full stack development" där samma team tar sig an databasen, logiklager, och gränssnitt. Men om plattformen är för komplex går det inte att skapa sådana team. Särskilt inte om de olika delarna av plattformen har olika stort förändringstryck på sig, måste uppdateras i helt olika cykler, eller helt enkelt är tekniskt mycket olika. Då behöver man använda knep för att koordinera nyttoskapande mellan team, utan att teamen bryter den övergripande arkitekturella enigheten.

Bredd. Det finns situationer då man behöver leverera mycket nytta. Om man arbetat strukturellt för att få ner ledtiderna och komplexiteten (det som driver de andra dimensionerna), så kan man skala upp genom att låta flera parallella konstellationer arbeta samtidigt i bredd. Men man måste förstå att även den bandbredden kan begränsas av andra saker än antalet konstellationer. Arbetet måste koordineras, och det är inte säkert att plattformen håller för förändringstrycket. Då kan det krävas en uppsättning skalningstekniker för att jämna ut flöden och koordinera leveranser, till exempel olika kanbansystem.

Så varför menar jag att medvetenheten om dessa skalningsdimensioner är viktig då?

När du ser på din egen verksamhet så kan du få en bättre förståelse för utmaningarna. Tänk dig att dimensionerna bildar ett rum, och att er situation kan beskrivas som en uppsättning vektorer i detta rum. Vilka skalningsvektorer måste ni angripa? Vilka tekniker kan ni behöva ta till?

Jag ser ofta människor som inför en skalningsutmaning föreslår att man blint ska tillämpa en färdigpaketerad uppsättning skalningstekniker, exempelvis SAFe eller LeSS. Men det är som att svinga en stor träklubba i ett mörkt rum och hoppas att man inte slår sönder något värdefullt utan bara dödar den där myggan man är irriterad på. Skalningsteknikerna är dyra! De finns för att vi ska kunna skademinimera närvaron av strukturella hinder. Men inför vi dem där vi inte har dessa strukturella hinder så skapar vi istället hinder.

Så genom att se på vilka skalningsvektorer vi faktiskt har, så kan vi lite bättre välja precis den uppsättning skalningstekniker vi faktiskt behöver, och inte dra på oss dyr overhead genom att tillämpa tekniker i onödan.