Ha gärna mätetal men...

...vet vad du vill uppnå om du vill styra på dem. Du behöver en kvalitativ förståelse för behovet, något du kan uttrycka utan mätvärde, och som inte är självklart. "Ökad omsättning med 30 %" är inget vägledande mål. Effekten du vill ha är "ökad omsättning". Exakt hur mycket är inte relevant om du inte har en idé om hur du vill uppnå det. Hur ska det uppnås? Hur ser visionen ut? Beskriv bilden ("jag ser framför mig hur fler går till min webbplats och klickar på köpknappen eftersom de upplever att..."). (Man kan här fundera över vad Simon Sinek menar med "Start With Why".)

...förstå den naturliga variationen. En säljare får i snitt ett "ja", två "kanske", och sjutton "nej" på tjugo samtal. Ibland blir det två "ja". Har säljaren varit extra duktig? Ibland blir det noll "ja". Har säljaren varit dålig? Troligen inte. Troligen ligger utfallet inom den naturliga variationen. Om man försöker styra med återkoppling på slumpmässig variation blir återkopplingen lika slumpmässig och riskerar då att förstärka slumpmässigheten. (William Deming har skrivit en hel del om detta.)

...analysera orsakerna bakom utfallet. Ingen kan styra på hur saker råkar bli. Man styr genom att ändra på de faktorer som påverkar utfallet. Om du inte vet hur olika beteenden och företeelser faktiskt påverkar så kan du inte styra. Att titta på ett mätetal utan att veta hur du ska reagera på förändringar, vilka spakar som måste dras i, är fåfängligt. ("Vanity metrics" som Eric Ries kallar dem i "Lean Startup".)

...anlägg systemsyn. Värde skapas i komplexa system. Du kan inte dela upp ett målvärde för en helhet och distribuera ut i delarna. Helheten är inte summan av vad som sker i delarna, utan vad som uppstår i samspelet mellan dem. Att öka försäljningen kan innebära att verksamheten levererar mer, men kan lika gärna leda till att verksamheten levererar mindre. På grund av systemeffekter. (Donatella Meadows med flera har skrivit mycket om detta.)

...se din okunskap. Ju närmare värdeskapandet man är, desto större chans till förståelse har man av de faktiska styrande faktorerna. Om du inte är på själva golvet där värdet skapas är risken stor att du hyser en massa missuppfattningar om hur saker fungerar. En ledning kan ha tillgång till överblick, kunskaper om affärsstrategier, och annan specialistkompetens som lämpar sig för styrning. Men kunskapen om hur värde och spill uppstår i verksamheten ökar dramatiskt med avståndet till golvet. Vilka mätvärden menar folket på golvet är de viktiga för slutresultatet? (Se vad Toyota lägger i begreppet gemba.)

...låt dem inte vara för evigt. Rena utfallsmått är ofta viktiga över lång tid. Hur mycket pengar man tjänar. Hur många defekter. Kapaciteten att leverera. Men det intressanta var ju att hitta de faktorer som påverkar utfallen. Och förståelsen för dem kan utvecklas väldigt snabbt. Man kan vara helt övertygad om att det är faktor X som kontrollerar utfall Y, men plötsligt inse att det i själva verket är faktor Z som styr både X och Y. Om man då låst fast sin organisation i att styra på faktor X genom regelbundna mätningar, så kommer man att styra fel. En agil organisation måste kunna ändra uppföljningsmönster snabbt.

...vet hur de påverkar. Mätvärden påverkar alltid det man försöker mäta. Måste du tvinga fram dem? Är de enkla eller svåra att ta fram? Innebär de en administrativ börda? Du tvingar väl ingen annan? Och i samma stund man styr på dem så upphör de att vara statistiskt relevanta mätvärden för utfall på grund av de skevheter som då skapas. (Se Goodharts lag.)

...se deras otillräcklighet. De viktigaste faktorerna som påverkar utfallet i din verksamhet kan sällan mätas, och om de kan mätas kan man sällan styra dem numeriskt. Kulturfaktorer till exempel. Det viktigaste kommer alltid att vara ledarskapet. Vad och hur man kommunicerar. Mätetal har sin plats, som utfallsmått på helheter, som tillfälliga indikatorer på ett kvalitativt förbättringsarbete, eller som larmvillkor för att kunna delegera tryggt. Men akta dig för att halka in i fällan att försöka styra enbart på numeriska mål (management by objectives). Till och med uppfinnaren av management by objectives själv, Peter Drucker, tog avstånd från sin skapelse när han såg effekten. (Varför inte utforska alternativ till MBO, som till exempel strategiförankring, hoshin?)

A Capability View on Agility

Agile "methods" (Scrum, SAFe, DSDM etc) are not tools but toolboxes, collections of tools that skilled folks have seen work so they have put them in a toolbox and put a name on it. The "methods", the toolboxes, are very similar when it comes to what tools they contain. Iterations, cross functional teams, daily meetings preferably in front of a kanban board of sorts are often present.

What creates agility in a collaboration however isn't the name of the toolbox, or even the tools, but the new capabilities you can build using the tools. When you focus on the capabilities you need, you will be able to select the correct tool for the job and be able to avoid the not so helpful religious fights about what toolbox one should use.

You don't need the product owner but the capability in the organization to understand and decide what is the most important thing right now given that this product should be healthy during its full life cycle. A product owner is one way of creating that capability.

You don't need sprints but the capabilities to review what you are doing at regular intervals and to plan ahead a bit, synchronized with other efforts. Having sprints is one method, but there are others.

You don't need the scrum master but the capability to have coaching servant leadership working in the organization, where the human factors are understood and regarded.

You don't need the retrospective but some structured way of doing kaizen, continuous improvement.

The toolboxes are often excellent starting points. The particular collection of tools has after all proven to be effective. But by all means, don't look at the tools, look at what you are trying to build.

Focus on the capabilities.

Att verka utan att synas

Arbetet som agil coach går ut på att få andra att glänsa. Man försöker tillämpa systemtänkande på de samspel man ser, försöker få de andra i samspelet att tillägna sig samma sorts tänkande, och att de i grupp kommer igång och löser de underliggande strukturella problemen som hindrar dem från att skapa väldigt mycket värde.

Det är att agera katalysator och inte vara en ingrediens. En igångsättare men inte en nödvändig förutsättning för att arbetet ska fungera i fortsättningen. Om man inte gör sig onödig på den plats där man är så kommer man aldrig vidare till att hjälpa nästa.

Man behöver kunna verka utan att synas. Det är, tycker jag, en av de svåraste sakerna i agil coachning.

För samtidigt behöver man ett visst mått av synlighet för att kunna göra sitt jobb väl.

En grupp har till exempel ett stort behov av direkt ledarskap i början av sin resa. Med tiden ska den bli självgående och ha förmågan att fatta bra beslut tillsammans, men till att börja med behöver de någon som både hjälper dem att formulera det gemensamma syftet och ger dem några konkreta samarbetsverktyg att börja med.

För att få handlingsutrymme, till exempel för att alls få uppdraget, behöver man tydliggöra visionen och möjligheterna. Det innebär att ställa sig i rampljuset en stund. Vara den som erbjuder sig att visa vägen, också för att vara den som organisationen tydligt kan skylla på om det inte går vägen.

Man kan också behöva manövrera ut andra som tar väldigt mycket plats på arenan. Formella och informella ledare som har en annan agenda än den som man kommit överens med ledningen om. Folk som kanske vill ta de synliga ledarpositionerna, inte som ett första steg på resan att lyfta andra, utan som ett sätt att glädja sitt eget ego.

I lean och agilt handlar ledarskapet mycket om att på ett medvetet sätt motverka de intuitioner om ledarskap som vi människor har mer eller mindre medfött, och som också ofta bekräftas av våra mänskliga kulturer.

Vi belönar gärna narcissism hos våra ledare. Vi underordnar oss den som är lite bufflig och hotfull. Och när vi är på en förändringsresa och det börjar skaka lite så tyr vi oss hellre till de som rakt och enkelt berättar för oss vad vi ska göra än till de som krånglar och vill att vi ska fatta egna beslut och våga stå på egna ben.

Det luriga är att man som vägvisare på förändringsresan behöver både kunna ikläda sig rollen som direkt ledargestalt och backa undan för att stärka självledarskapet. Detta hos människor som hellre lyssnar till vem som helst som kan uppvisa direkt ledarskap, och helst i kombination med bufflighet, i synnerhet precis när resan känns som otäckast och det faktiska behovet av både direkt ledarskap narcissism och bufflighet är som lägst.

Det är det svåra tycker jag.

The third digitalization insight

The first insight is that something needs to be done.

You can already now see lots of possibilities. Things that you sense could be done better or differently using digital equipment to connect the value stream. Or things that you see that your competitors do that you don't.

The worst reaction to this insight would be if you shout further down in the organization to start do all these things that you see needs to be done: "Start more projects! More digitalization! Why are you so slow?"

Instead you can meditate over the second insight. What you need is the organizational capability to invent. To look at your value streams in a new light. Can design thinking help? Probably. Implementing design sprints? Yes, that is one specific thing you can work with.

Or why not invest in an innovation center? A place where certain people in your organization are allowed to innovate, free of the constraints that reigns in the rest of the organization? Allowing two "modes" of operation in different sections of the organization: one fast where all the cool things are done, and one slow, where all your normal dull and slow and not so innovative people can do all the normal dull things.

While working "bi-modal" (as it is sometimes called) can be a starting point, it is definitely not a solution. What you could (and should) use it for is to let it help you get the third insight.

The second insight was that your lack of digitalization ability isn't caused by a lack of digitalization projects. The third insight is that your lack of digitalization ability isn't caused by the lack of innovative people or innovation centers. It is caused by structural hindrances, systemic factors, that you are responsible for upholding.

Organizations need structures that prevent them from falling apart. Organizations, just like organisms, must possess the capability to prevent too much change to happen at the same time. They must possess what biologists call homeostasis. On the other hand: the biological term for total standstill in the organism is death.

What the third insight inspires people to do is to invest in the organizational capability to move rapidly but with preserved integrity. Innovation centers can be organizational prototypes where those capabilities can be developed, but if the capabilities stay there, the innovations they might come up with will not affect the rest of the organization. Your core value streams will not develop.

That organizational capability is called business agility, and the ways of implementing it are well known and investigated during more than twenty years. They are neither hard or easy to implement, rather medium hard, but they involve a critical look at the present structures, including leadership culture and high level financial KPI:s.

The third insight is that you, as the leader of the organization, must start with yourself and think about what kind of organization you want to lead.

Dröjsmålskostnad (cost of delay)

En av Donald Reinertsens stora bidrag till tjänsteutvecklingen är att han trycker på att man bör mäta värdet av en framtida förändring i en tjänst utifrån dess dröjsmålskostnad (cost of delay).

Dröjsmålskostnaden kan uttryckas som svaret på frågan: "Vad förlorar vi varje dag på att inte ha genomfört förändringen än?" Det är en kraftfull fråga som hjälper till att lösa många svårigheter folk har med att prioritera. Exempelvis dessa:

Vilka kvalitetshöjande åtgärder ska vi satsa på först?

Vi har problem med API:et för integrationen med systemet Gnork. Det ger ett visst antal ärenden i supporten. Vi har även problem med våra automattester. Det ger långa driftsättningstider som binder upp folk stora delar av veckan när det är driftsättningsdags.

Genom att räkna på kostnaden för dessa bägge problem under någon representativ tidsrymd (till exempel inräkna både driftsättningsperioder och perioder utan driftsättning) kan vi få en kostnad per tidsenhet som ger oss vägledning i frågan om vad som är viktigast att åtgärda.

Vilka deadlines är viktiga och vilka är det inte?

En deadline kan ses som en kalendertidpunkt då kostnaden för att inte ha en åtgärd på plats (dröjsmålskostnaden, cost of delay) ökar till ohanterliga nivåer. Det kan gälla förändringar i tjänsten motiverade av lagkrav under hot om höga viten, eller att inte ha en produkt i drift den dag man har köpt TV-reklam och vill slå på stora trumman.

Men vad gör man när man köpt TV-reklam, och ett nytt lagkrav träder i kraft, och man inte tagit höjd i sin kalendertidplan för dröjsmål på grund av faktorer man inte kunnat förutse?

Att ha beslutandemakt över en tjänst innefattar att behöva ta tuffa beslut. Genom att räkna på dröjsmålskostnaden kan man ta det minst dåliga beslutet och priortiera även bland sådant som "inte får lov att ske" (vilket man som chef ju är satt att hantera, hade chefandet varit enkelt kunde vi skrivit en javaskriptsnurra som chefade).

Hur ska vi ställa kvalitetshöjande åtgärder mot större strategiska projekt?

Här kommer den stora vinsten med fördröjningskostnad: Det finns ett (otillräckligt) sätt att räkna på tjänsteinvesteringar som går ut på att man tar det nya tjänstebeteendets livscykelintäkt ("Vi snackar miljooooooner här va!") dividerat med livscykelkostnaden ("Måste det kosta så mycket? Kan ni inte göra det lite enklare? Underhåll? Nä, det blir för dyrt! Felärendena får supporten ta hand om! Den ligger i Långbortistan så den blir billig!"). Gissningar om livscykelintäkt (gärna aggregerat på flera år) dividerat med livscykelkostnad (unikt låg), ger en (gravt osäker) uppfattning om satsningens relativa värde.

Jämfört med alla sådana business case där kronorna räknas i miljoner både på intäkts- och kostnadssidan står sig de "mindre" kvalitetshöjande åtgärdena slätt. Det finns på allvar organisationer som inte räknar de mindre förbättringarna som värdetillväxt på sin investering (så kallad capex) utan som rena kostnader (så kallad opex) vilket gör att de stora projekten alltid ges förtur i budgeten trots att deras bidrag till värdetillväxten sett till livscykeln kan vara betydligt mer blygsam än de många men mindre åtgärderna.

Fördröjningskostnaden jämför istället äpplen med äpplen genom att ställa samma fråga till bägge typerna av investering: vad är kostnaden per dag av att göra detta? Vad är kostnaden per dag av att inte göra detta?

Totala business case baserade på livscykel är lögnaktiga eftersom de innefattar så mycket osäkerhet och inte tar hänsyn till att tjänsterna behöver mycket underhåll under livslängden för att fortsätta generera värde. När man aggregerar långa tidsrymder aggregerar man även den risk som varje dag eller varje vecka finns att ROI av skäl man inte kan rå för plötsligt störtdyker och kräver utvecklingsinsatser för att vara uthärdligt.

Kostnaden för en defekt är vad den kostar att kompensera för, varje dag. Det kan gälla manuell handpåläggning eller andra ökade kostnader, eller att man tappar intäktsmöjligheter. Kostnaden för ett icke driftsatt paket av funktioner (till exempel en ny produkt) är den uteblivna intäktsmöjligheten (eller viten kopplade till exempelvis lagkrav), varje dag.

Det är detta "varje dag" som är nyckeln. Genom att bryta ner till jämförbara kalendertidsenheter blir investeringarna möjliga att räkna på. Tack Donald Reinertsen för den tankegången, och tack Dean Leffingwell för att du populariserat det genom SAFe (även om SAFe:s resonemang runt fördröjningskostnad inte är riktigt detsamma som Reinertsens).