Sjukvården lär oss konsten att prioritera

Går vi en grundkurs i livräddning är bland det första vi får lära oss att om vi behöver prioritera bland flera skadade inte börja hjälpa den som skriker högst. Till vår hjälp för att ta det beslutet lär vi oss prioriteringsmodeller och riktlinjer för livräddande insatser i situationer där kapaciteten understiger behoven.

En grundläggande prioriteringsmodell för livräddande insatser på olyckplatser och på akutmottagningar under hög belastning är Triage och en välkänd riktlinje är ABC. Med ABC lär vi oss att först säkra Andning, sen stoppa Blödning och sen hantera Chock. ABC blir således riktlinjen som gör att vi inte springer fram till den som skriker högst det första vi gör – då den som skriker högst bevisligen kan andas (A). Det är en princip som föräldrar även lär sig ganska snabbt. Ser man barnet ramla följt av att det skriker kan man andas ut. Ett skrikande barn är ett levande barn.

Men varför är det ofta just den som ”skriker högst” vi prioriterar inom andra fält, tex inom IT- och affärsutveckling? Svaret ligger till viss del i avsaknaden av tydliga prioriteringsmodeller och riktlinjer baserade på att fungera i en dynamisk kontext där flöden inte är homogena. Utan att göra några övriga jämförelser mellan akutsjukvård och IT- och affärsutveckling delar de samma förutsättningar då de befinner sig i en kontext som är i allra högsta grad dynamisk med icke homogena flöden och med en ofta slumpvis efterfrågan.

Där det finns en kö – där finns behov av prioritering och sekvens

Det första vi behöver förstå är att prioritering bara behöver göras om behovet understiger kapaciteten. En akutmottagning kan mycket väl ledas enligt principen ”i tur och ordning” eller FIFO  (first-in-first-out). En akutmottagning eller en IT- och affärsutvecklingsprocess lever dock sällan under de förutsättningarna. Kontexten är dynamisk och flöden är inte homogena, FIFO fungerar således inte. Och inte heller ”den som skriker högst prioriteringen”.

Från TPS och Lean tillverkning lär vi oss att arbete i processen sker enligt FIFO (first-in-first-out), objekt med samma värde går igenom flödet i en jämn och förutbestämd takt (takttid) i produktionsceller. Det som går först in i produktionscellen kommer först ut. Det här är en optimal approach när kontexten är statisk och flödena homogena, vilket de är i en tillverkningsindustri.

Flöde

En bärande mekanism för att skapa förutsättningar för flöde i en process är att utveckla sekventiellt – att behandla patienter en och en, inte parallellt. Det vill säga hålla ner antalet saker vi gör samtidigt och göra tillräckligt klart innan vi påbörjar nytt.

Om vi bara påbörjar avancerade hjärtoperationer men aldrig avslutar några av dem må vi se sysselsatta ut i processen men vi skapar inget värde. För att optimera för flöde och inte för resursnyttjande arbetar vi i team där vi till viss del kan varandras uppgifter och den lediga kompetensen drar (pull) ett jobb istället för bli tilldelad genom push.

För att det ska fungera behöver vi en gemensam modell för prioritering och sekvensering. Annars drar vi jobb på olika premisser vilket kommer att skapa suboptimering före det önskade i att optimera systemet som en helhet.

Värdet och storleken på innehållet i kön är avgörande

Givet att vi har en kö behöver vi kunna kvantifiera värdet och storleken på de objekt som befinner sig i kön. Annars kan vi inte vikta objekten i relation till varandra när vi ska prioritera dem. I ett system som optimerar för flöde är utveckling sekventiellt nyckeln. För att veta hur sekvensen ska se ut behöver vi prioritera genom att resonera kring två parametrar:

  1. Vad är Cost of Delay för behovet (det vi vill utveckla)
  2. Vad är kostanden att implementera behovet där kostnaden utgörs av flera rörliga delar (tex ledtid, produktionskostnad, utvecklingskostnad)

Det är här Cost of Delay kommer in i bilden. Cost of Delay kombinerar tid (hur bråttom det är) med det potentiella värdet – två parametrar som människor inte är särskilt bra på att skilja mellan. För att fatta ekonomiska beslut måste vi förstå både hur potentiellt värdefullt något är och hur brådskande det är. Adderar vi storleken på jobbet (kostnaden att göra det) får vi prioriteringsmodellen WSJF som vi går igenom nedan.

“Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organization.” – Donald G. Reinertsen

På akutmottagningen har en hjärtinfarkt en högre CoD än en bruten arm. Det gör att vi enkelt kan prioritera mellan dem.

I vår IT- och affärsutveckling hjälper Cost of Delay oss utifrån tre viktiga aspekter: ta ekonomiska beslut baserade på avvägningar mellan flera rörliga parametrar, förbättra prioriteringen och fokusera dialogen på värde och hastighet.

  1. Utvecklingen i en dynamisk kontext är full av olika avvägningar – vi behäver ta hänsyn till flera rörlig delar. Vi behöver kunna resonera utifrån olika parametrar med ett livscykel perspektiv. Till exempel: Om vi ökar antalet utvecklare ökar vi också kostnaden, får vi igen den kostnaden i och med kortare ledtider? Vad är i så fall den kortare ledtiden värd?
  2. Cost of Delay hjälper oss att lägga gissningar och magkänsla åt sidan och fokusera på vad som har potentiellt värde och vad som är bråttom. CoD i WSJF hjälper oss att utveckla det som ger oss mest värde snabbast.
  3. I en organisation som har lite koll på värde och hur brådskande saker är i relation till varandra kommer att försöka optimera för andra saker som att sänka kostnader och hålla deadlines vilket skapar beteende som inte optimera för flöde av värde i dynamisk kontext.

En process har flera köer

När vi förstår att en kö bara uppstår om kapaciteten understiger behovet och att vi behöver kvantifiera innehållet i kön baserat på potentiellt värde och hur brådskande det är, är nästa princip vi behöver förstå att det finns flera köer i processen. Det finns en kö ”in service” och en kö ”out of service”, dvs det finns en kö utanför den värdeskapande delen i processen och det finns en kö i den värdeskapande delen i processen.

Flyget hjälper oss att förstå. Där har vi en kö på marken ”out of service” med plan som väntar på att lyfta och vi har en kö i luften ”in service” med flygplan som väntar på att få landa. Att ha en kö i luften med flygplan kostar flygbolaget mer än att ha en kö på marken med flygplan. Därför kan flygplan tillsynes utan nåra köer på marken bli stående innan start för att flygledningen vet att det kommer bli kö 4 timmar senare i den värdeskapande delen i processen i luften. Vi föredrar alltid att ha kön utanför den värdeskapande processen. Att ha en kö ”in service” kostar oss mer än att ha den utanför ”out of service”.

Viktigt är dock att vi minimera båda köerna, men vi gör det på olika sätt.

Genom att minimera köerna utanför utvecklingsprocessen minskar vi ledtiderna i utvecklingsprocessen.

För att inte få långliggare i systemet i sjukvården i situationen som råder nu behöver vi ”out of service” minska smittspridning på äldreboenden så att patienten inte blir en långliggare ”in service”. Vi hanterar alltså köerna på helt olika sätt. Genom att minimera köerna utanför utvecklingsprocessen minskar vi ledtiderna i utvecklingsprocessen.

Storleken på våra köer är ledande indikatorer (leadning indicators) på våra ledtider (time to market). Kom ihåg att time to market är ett konstaterande mätetal (lagging indicator). Vi har mer att tjäna på att reducera köerna före vi går på våra flaskhalsarna i en IT- och affärsutvecklingsprocess. På samma sätt i sjukvården – vi har mer att vinna på att minimera smittan (reducera köerna) än att bygga bort flaskhalsarna i processen. En process har alltid minst en flaskhals, när vi har reducerat en uppstår en annan.  

Olika prioriteringsmetoder för sekventiell utveckling

Modellerna nedan beskrivs i Don Reinertsens bok ”The Principles of Product Development Flow: Second Generation Lean Product Development”.

SJF – Shortest Job First

Om kostnaden av att vara sen är samma bör vi göra det jobb som tar minst tid först. Om vi gör det jobb som ta längst tid först kommer många små jobb att försenast. Då får vi något som kallas ”convoy effect” vilket syftar på att en långsam bil på en smal väg kan försena alla andra bilar på vägen.

Således:

  • Om två personer kommer in till akuten med liknande benbrott och således samma Cost of Delay men den ena personen är döv och behöver en teckenspråkstolk som är tillgänglig först om 5 timmar gipsar  vi det andra benbrottet först.
  • Om vi ska uppdatera den judiska informationen för två stycken likadana köpflöden för två liknande produkter med samma Cost Of Delay men den ena flödet behöver även byta ut alla produktbilder väljer vi att göra det utan bilder först eftersom det är ett mindre jobb.

HDCF – High Delay Cost First

När storleken på jobben är den samma men kostnaden av att vara sen skiljer sig åt är den ekonomiska approachen att göra de jobb med hög Cost of Delay först.

Således:

  • Om två personer kommer in till akuten med varsin fiskekrok i respektive tumme där person nummer 1 har en en gammal rostig krok och person nummer 2 har ny rostfri krok väljer vi att behandla person nummer 1 eftersom kostnaden att behandlas sent med en rostig krok i tummen troligen är högre än att behandlas sent med en krok som inte är rostig.
  • Om vi ska förenkla köpflödet för två stycken köpflöden och det kommer krävas samma tid för respektive flöde börjar vi med det köpflöde som har högst Cost Of Delay.

WSJF – Weighted Shortest Job First

När både storleken på jobbet och CoD varierar använder vi WSJF. Det här är den komplexa verklighten vi möter både på akutmottagningen och i den moderan IT- och affärsutvecklingen.

Bäst strategi i en dynamisk kontext är att göra det uppskattade värdefullaste och kortaste jobbet först (WSJF). I de här fallen prioriterar vi baserat på jobbstoleken och jobbets CoD. Formelen för det är att ta CoD genom jobbets storlek vilket ger siffran vi använder för vår prioritering för sekventiell utveckling.

Vad kan vi lära oss genom att betrakta det som händer just nu iom Corona

  • Fastna inte i om vi är för få eller för många – optimera för flöde av värde
  • Stora projekt stoppar upp flödet – det finns flera köer i en process
  • Värdet på kön sätts globalt, insatsen i tid lokalt – Vad vi optimerar för och Varför vi gör det behöver vara tydligt
  • Det är alltid en avvägning mellan flera parametrar – utgå från att vi behöver beakta flera rörliga delar

Fastna inte i om vi är för få eller för många

Hanne Kjöller, Dagens Nyheter, 2020-03-27. ”Redan när jag läste till sjuksköterska på 1980-talet lärde jag mig att det inte finns något som heter ”fullt på intensiven”. Är alla sängar upptagna flyttar man helt enkelt den som är minst sjuk till en lägre vårdnivå om man kan tänkas använda den platsen bättre.”

Resursoptimering i sig är destruktivt för flöde. Med en inställning att vi aldrig kan vara för får eller för många skiftar vi fokus från resursoptimering till att optimera för flöde med de kompentenser vi har – oavsett hur många/få de är. Till vår hjälp tar vi en gemensam och transparant prioriteringsmodell.

Stora projekt stoppar upp flödet

Dagens Nyheter, 2020-04-05, Mattias Bergström: ”Långliggare är dåligt för systemet, de proppar igen platserna. Det blir ingen omsättning.”

Att reducera storleken på våra jobb och handera köer i och utanför den värdeskapande processen skapar förutsättningar för flöde.

Värdet på kön sätts globalt, insatsen i tid lokalt

Dagens Nyheter, 2020-04-10: ”I måndags skickades ett dokument ut med tydliga åldersgränser till chefer på Karolinska, för prioriteringar inom intensivvården. Personer med biologisk ålder över 80, biologisk ålder 70–80 och svikt i två eller fler organ och personer med biologisk ålder 60–70 med svikt i tre eller fler organ ska inte ges intensivvård.”

Cost of Delay är en global parameter som behöver sättas av ledningen för att skapa tydlighet och fokus. Storleken, tiden, sätts av de som är närmast informationen.

Det är alltid en avvägning mellan flera parametrar

Lena Andersson, Dagens Nyheter, 2020-04-11:
”Saker och ting kan inte jämföras endast med avseende på antal dödsfall. Fenomenens karaktär och hur saker sker måste beaktas.”

I en dynamisk kontext med icke homogena flöden är ekononiska beslut alltid en avvägning mellan flera parametrar.

Sammanfattning

  • I en dynamisk kontext med icke homogena flöden behöver vi prioritera och utföra vår utveckling sekventiellt.
  • För att ha en hypotes kring i vilken ordning vi ska utföra vår utveckling behöver vi kvantifiera innehållet i kön baserat på det potentiella värdet, hur bråttom det är och storleken.
  • Vi behöver vara flexibla och anpassningsbara (dvs agila) kopplat till parameterna ”Vad vill vi optimera för?” men hålla oss till en gemensam och stabil modell för prioritering.

Referenser

A good read about Lean

In times of high uncertainty and complexity we once again get reminded of that we can’t know for sure in advance. In this environment that is changing rapidly we need to have a scientific approach.

Lean has been around for decades as a way of thinking and acting with a scientific mindset encouraging us to do experiments in small batches.

An excellent introduction to Lean and lean thinking is a short but
condensed book called “Lean: Manage work as a flow system, 2nd Edition” by France Bergeron and Joanne Gaudet. The book guides the reader from the origin at Toyota and TPS to the psychological concept of flow described by Mihaly Csikszentmihalyi.

The book is an excellent start if you are new to Lean but it is also a good read for the more experienced ones as it remindes the reader of the core in Lean and the connection between the process and the human being.

It is s a brilliant and easy introduction to Lean. I highly recommend it!

Read more: https://alpenpathsolutions.com/resources/

Fokus på omställningskostnaden möjliggör tidigare effekthemtagning och snabbar på vårt lärande

En mängd delar behöver samspela för att vi ska kunna uppnå ”Maximalt värde med kortast möjliga hållbara ledtider”.

När vi förstår hur delarna förhåller sig till varandra är vi också mer benägna att optimera systemet som en helhet, där 1+1 ofta blir 3, till skillnad från lokal optimering där 1+1 ibland till och med kan bli 0. SAFe princip nummer 2 är en fördjupning i de teorierna.

Relationen omställningskostnad, lagerkostnad och total kostnad och storleken på våra jobb är ett exempel på det. Genom att vi förstår och förhåller oss till samtliga av de delarna optimerar vi systemet som en helhet och 1+1 kan bli 3.

Om du är bekant med begreppen omställningskostnad och lagerkostnad kan du hoppa över följande stycke och hoppa direkt till nästa rubrik.

Omställningskostnad och lagerkostnad kan förklaras med följande exempel

Omställningskostnaden är kostnaden för att förändra status eller placering av en produkt/tjänst/feature från ett läge till ett annat, alltså inte själva kostnaden av produkten. Detta gäller både i utvecklingsprocessen som utanför utvecklingsprocessen . Lagerkostnad är kostnaden för att hålla produkten/featuren i lager i och utanför
utvecklingsprocessen med allt vad det innebär, dvs lagerkostnad, lagerförfall, cost of delay (försenad effekthemtagning) mm.

När jag handlar potatis i affären är omställningskostnad den insats i tid det tar för mig i tid att gå till och från affären, alltså insatsen i tid för att flytta produkten potatis från affären till mitt hem.

Säg att jag äter potatis varje dag. Den extrema omställningskostnaden skulle vara att varje dag gå till affären och köpa de potatisar jag behöver för det dagliga intaget. Det skulle ge en mycket hög omställningskostnad men samtidigt en mycket låg storlek på batch(så liten att jag kan bära hem potatisarna i min egen ficka). Det skulle också ge minsta möjliga lagerkostnad eftersom jag gör av med samma kvantitet jag köper in varje dag och således inte behöver något lager (skafferi).

I andra änden av ytterligheterna skulle vara att ha en extremt stor batch vilket skulle driva en mycket hög lagerkostnad men samtidigt en låg omställningskostnad. Om jag istället för varje dag köper potatis gör det en gång per år genom att använda en släpkärra kan jag ta hem en stor batch till en liten omställningskostnad (i tid skulle operationen med släpet motsvara i stort sätt samma insats som den dagliga insatsen).

Men stora batchar skapar behov av lager och binder kapital vilket i fallet med potatis skulle innebära att jag behöver investera i ett större skafferi och binda upp kapital i potatis för ett år. Och det skulle också generera ett lagerförfall då potatis på lager skulle kunna börja mögla, ruttna och angripas av skadedjur vilket resulterar i att en del av potatisarna på lagret förfaller (slöseri).

För den potatisälskande personen som vill äta potatis varje dag skulle nog den optimala storleken på batchen vara runt 21 potatisar (3 per dag) vilken skulle kunna motivera en omställningskostnad på en gång per vecka (personen går till affären en gång per vecka vilket känns rimligt). Den storleken på batch är fortfarande så låg att den inte skulle leda till ett behov av att investera i lager (större skafferi) med negativa effekter som lagerförfall, uppbundet kapital i lagret med ökad totalkostnad som följd.

Total kostnad = omställningskostnad + lagerkostnad

Den optimala storleken på våra jobb (batchar) ligger i spannet på en U-kurva, det är alltså ingen exakt vetenskap. Det viktiga är att vi förstår relationen omställningskostnad och små jobb och siktar på att minimera båda inom u-kurvan – vi är inte ute efter den perfekta analysen.

Total kostnad = omställningskostnad + lagerkostnad vilket betyder att om vi sänker omställningskostnaden sänker vi också den totala kostnaden!

Den sänkta omställningskostnaden i bilden nedan gör att den optimala batch-storleken minskar och även den totala kostnaden. Se hur den prickade vertikala linjen flyttar sig till vänter när omställningskostnaden sjunker.

Relationen omställningskostnad och optimal storlek på batch framgår tydligt.
Genom att sänka omställningskostnaden sjunker inte bara den totala kostnaden utan också den optimala storleken på batchen.

Leverera ofta och tidigt

Tillbaka till början av texten. En mängd delar behöver samspela för att vi ska kunna uppnå ”Maximalt värde med kortast möjliga hållbara ledtider”.

För att skapa värde med korta hållbara ledtider är vår förmåga att leverera ofta och tidigt viktigt. I lena-agil utveckling stödjer processerna det genom inkrementell och iterativ utveckling. SAFe princip nummer 1 är en fördjupning i de teorierna.

För att kunna leverera ofta och tidigt behöver vi bryta ner våra jobb i minder delar. Vi talar om att reducera storleken på våra batchar (jobb).

Lean betonar flödesoptimering (med hållbara ledtider) där små jobb (batchar) flödar snabbare i processen än stora jobb (batchar). SAFe princip nummer 6 är en fördjupning i de teorierna.

Små batchar ger en mängd fördelar. Bland annat

  • Ökad förutsägbarhet
  • Accelererad feedback
  • Hemtagning av effekt tidigare och oftare
  • Kortare ledtider
  • Reducerad risk

Men det bygger på att vi har låga omställningskostnader. Den primära faktorn som möjliggör små jobb (batchar) är just en låg omställningskostnad per jobb. Om vi reducerar storleken på jobben utan att reducera omställningskostnaden blir vi tvungna att betala omställningskostnaden mer ofta vilket ökar vår totala kostnad.

Om vi bara bryter ner våra jobb till mindre batchar riskerar vi att suboptimera, dvs 1+1 blir noll. Samtidigt som vi bryter ner våra jobb måste vi också sänka våra omställningskostnader. Dvs optimera systemet som en helhet.

Om vi blir duktiga på att bryta ner våra batchar i mindre delar och tex kan utveckla en features på två veckor men bara leverera varannan månad får vi inte ut nyttan av att våra batchar är små. Vi behöver med de små batcharna samtidigt få ner omställningskostnaderna (i exemplet varannan månad).

Automatisering och DevOps är nyckeln

Nyckeln till att sänka omställningskostnaden är automatisering, DevOps och tvärfunktionella team och tåg med kompetens att leverera ”end-to-end”. Att sänka omställningskostnaden innebär vi måste fokusera på och investering i infrastruktur, automatisering, och aktiviteter som CI (Continuous Integration), DevOps, automatiserade byggen, automatiserade regretonstetser med mera.

Sammanfattning

  • Små batchar gör att vi kan leverera ofta och tidigt
  • Den ekonomiskt optimala batchstorleken beror både på lagerkostnad (kostnaden för försenad återkoppling, lagerförfall och försenad leverans av värde (cost of delay)) och omställningskostnaden (kostnaden för att förbereda och implementera batchen). 
  • För att reducera storlek på våra batchar behöver vi sänka omställningskostnaden
  • Sänker vi omställningskostnaden sänker vi också den totala kostnaden!
    • Total kostnad = omställningskostnaden + lagerkostnad
  • Att sänka omställningskostnaden innebär att portfölj, tåg, team och projekt måste fokusera på och investering i infrastruktur, automatisering, och aktiviteter som CI (Continuous Integration), DevOps, automatiserade byggen, automatiserade regretionstester med mera.
  • Den teoretiska optimala storleken på våra jobb (batchar) är där omställningskostnaden och lagerkostnaden möts inom spannet på en u-kurva.

Referenser

Från värdekedjor till värdeströmmar genom att förhålla sig till helheten

Vi kan bara hanterar det vi kan se. Vi kan bara optimera systemet som en helhet om vi förstår systemet som en helhet och kan se helheten. Men vi utvecklar allra oftast bara en del av en helhet. När vi optimerar delen men tar ansvar för helheten optimerar vi både systemet som en helhet och den lokala delen – och därmed förenar vi det bästa från två perspektiv.  

Historiskt har vi utvecklat och organiserat oss linjärt dvs utvecklingen har passerar beslutspunkter och kompetensområden (silos) ”från vänster till höger i en kedja” utan att den som överlämnar har förstått helheten eller de besluts som togs två-tre steg till vänster i värdekedjan. I en värdekedja riskerar vi att tappa bort helhetsansvaret för ”concept to cash”.

I en vårdkedja som är linjär kan det resultera i att en patient får ”optimerad” behandling på delsymtom i en kedja där ingen tar ansvar för eller förstår de bakomliggande symtomen eller ser till helheten över tid.

I dagens DN beskriver Hanne Kjöller hur studenter på läkarlinjen i Uganda får lära sig att tänka på helheten när de initierar en behandling.

”På läkarlinjen, berättar studenterna i Uganda, får man lära sig att aldrig ta ett blodprov eller beställa en undersökning utan att ha någon idé om hur svaret påverkar den fortsatta handläggningen. Var på vägen tvingas de lära om? Och varför?”  

Beskrivningen på hur studenterna agerar är det vi kallar “hypotesdriven utveckling” och att “optimera systemet som en helhet” i lean-agilt arbetssätt. Det vill säga med vetenskaplig metod utrycka en hypotes som sedan följs upp och korrigeras under utvecklingen gång (eftersom omvärlden och förutsättningarna är dynamiska) för att nå maximal effekt.

När vi har till synes obegränsade resurser är det enkelt att glömma bort ansvaret för helheten. När det inte kostar oss någonting kortsiktigt med det slöseri som uppstår i lokal optimering och vid överlämningar då fortsätter vi med att beställa blodprover ”lösningar” utan att ta hänsyn till helheten. Lokal optimering kostar alltid mer än det smakar i det längre perspektivet.  

Lean uppkom via TPS i Japan där skalekonomi via massproduktion inte var något alternativ på grund av begränsad tillgång till resurser och liten marknad. Ett ansvar för helheten var inte bara ett måste utan också ett framgångsrecept (skulle det visa sig). Precis som exemplet från Uganda visar där läkarna jobbar smartare och optimerar systemet som en helhet (vårdkedjan), även vid lokal optimering (patienten).

Hypoteser och värdeströmmar i SAFe

Men en värdeström ser ju också ganska linjär ut, eller? Processen från idé (concept) till realisering av värde (cash) är en framåtriktad rörelse men med inbyggda feedback-loopar i processen där vi kontinuerligt skickar tillbaka data uppströms för att förbättra processen och produkten. Alla kan också från början se helheten (värdeströmmen) och de hinder som står i vägen för att med kortast möjliga hållbara ledtider realisera värde.

Hypoteser hjälper oss att tidigt fundera på vad vi vill uppnå och samtidigt ta ett ansvar i processen för att följa upp och korrigera på vägen.

I ramverket SAFe är hypoteser och leading indicators (tidiga indikatorer på “behandlingen”) inbyggda i processen från EPICs (Lean start up cycle) via features (Lean UX) och ner till storys (Lean UX).

Sammanfattning

Om vi inte behöver ta ansvar för hela processen eller har förståelse för hela processen och inte kan se hela processen då är det enkelt att tidigt beställa ”saker” istället för att ta ansvar för en potentiell effekt. Potentiell i den mening att effekten kan ju först bevisa sig när vi integrerar vår kod och användare eller kunderna börjar interagera med den. Patienten blir ju troligen inte frisk av receptet utan av behandlingen utifrån ett helhetsperspektiv där receptet är en del som ofta behöver justeras över tid och kombineras med flera aktiviteter (kompetenser) för att nå full effekt.

Kulturen har alltid varit generativ – nu även i 5.0

Kommentar: Med generativ i det här resonemanget menar jag ordets betydelse dvs något som “växer fram över tid”. Generativ kultur förklaras också av Ron Westrum kopplat till olika organisationskulturer.

En av de större nyheterna i SAFe 5.0 är inte något som adderats utan sex ord som har tagits bort. I SAFe House of Lean i den vänstra pelaren (Respect for People and Culture) har äntligen ”Culture changes comes last, not first” tagits bort.

En fara med ramverk, oavsett vilket, är när vi läser dem som regelverk. Det är enkelt att gå i fällan och bara hantera det som är synligt i tex processer, modeller och verktygslådor. Något jag skrev lite om i mitt förra inlägg.

Vad händer när det uttryckligen står ”Culture changes comes last, not first” och vi väljer att läsa det ordagrant. Ja, risken är ju att ingen direkt kommer att rusa på kultur-bollen. Detta när vi alla innerst inne vet att kulturen – den där som “sitter i väggarna” – det är den som är den egentliga utmaningen. Men eftersom kultur inte är lika synlig som ramverkets beskrivande delar och dessutom som i SAFe 4.6 inte uppmuntras att ta tag i riskerar den att bli liggande.

Nu är det ju inte SAFe eller nåt annat ramverk som bestämmer hur vi ska förhålla oss till vår kultur. Den har ju faktiskt alltid varit generativ och vår att forma. En kultur som inte anpassar sig och utvecklas med sin samtid blir inte långlivad. I dagens allt mer snabbrörliga och dynamiska värld är även kulturen i ständig förändring. Låt inte något ramverk lura i dig nåt annat.

Närstudie av formuleringen kring kultur i SAFe 5.0

I texten som beskriver pelaren ”Respect for People and Culture” i SAFe har det adderats några viktiga formuleringar och ord som uppmuntrar att ta tag i kulturen från början. I meningen: “The driving force behind this new behavior is a generative culture … “ har ordet “generative” smugits sig in i 5.0 till skillnad från i 4.6. Drivkraften bakom det nya beteende är inte bara kultur utan en generativ kultur. En kultur som växer fram, inte en kultur som ändras först på slutet.

I 4.6 formulerades förändringen och kulturen som: ”Where there is an urgency for positive change, improvement of culture is possible.”

I 5.0 formuleras förändringen och kulturen som: “When there is an urgency for positive change, transforming culture is possible.”

Istället för att nöja sig med att förbättra kulturen som i version 4.6 handlar det om transformera kulturen i 5.0.

Den något passiva avslutningen i 4.6 “Eventually, the culture will change naturally.” ersätts med formuleringen “The culture will change naturally over time.” Vilket manar till en förändring från början och sen löpande över tid.

Renoverat hus nu utan kulturförändring först på slutet.

Culture change comes first enligt Satya Nadella

Ledare spelar en avgörande roll för att få till en kulturförändring (vi är alla ledare). Microsofts VD Satya Nadella är ett bra exempel på en ledare som attackerade kulturen först i sin transformation av Microsoft. Och detta med god hjälp av Carol Dweck. Allt det går att läsa i hans bok ”Hit refresh”.

Nadella hittade språket och verktygen för att förändra kulturen och beteenden efter att ha läst Dwecks ”Mindset: The New Psychology of Success”. Boken uppmuntrar ett dynamiskt tankesätt (growth mindset) och att utmana sig själv att utforska och lära mer.
(Growth mindset och Dweck flyttar in i SAFe 5.0 under Lean-Agile Leadership.)

Microsoft hade länge lidit av en “know it all” kultur där experter och deras expertis var en allrådande vetenskap vilket skapade en negativ tävlingskultur och ett uteblivet samarbeta över organisatoriska gränser. Den kulturen vittnar även Bill Gates om i dokumentären om honom som finns på Netflix.

Satya Nadella insåg att han behövde förändra kulturen. Ett av de första dragen ha gjorde var att ge sig på Microsofts mission och formulerade om det från det kamerala “a computer on every desk in every home” till det mer människocentrerade “empowering every person and organization on the planet to achieve more”.

I ett tal på en säljkonferens säger han: ”We can have all the bold ambitions. We can have all the bold goals. We can aspire to our new mission. But it’s only going to happen if we live our culture, if we teach our culture. And to me that model of culture is not a static thing. It is about a dynamic learning culture in fact, the phrase we use to describe our emerging culture is ´growth mindset´, because it is about every individual, every one of us having that attitude – that mindset – of being able to overcome any constraint, stand up to any challenge, making it possible for us to grow and, thereby, for the company to grow”.

Han förändrade Microsoft genom att förändra kulturen och därmed förflytta tusentals medarbetare från en know-it-all-kultur till en learn-it-all-kultur.

Bäst beskrivet kanske det blir när Peggy Johnson, Executive Vice President på Microsoft, beskriver kulturförändringen. Peggy Johnson: “Satya had this idea of changing that culture from a know-it-all culture to a learn-it-all culture,”. https://www.inc.com/terence-mauri/how-satya-nadella-uses-learn-it-all-to-beat-know-it-all.html

Kulturen är generativ

Kulturförändringen börjar i samma sekund som vi väljer att anamma ett nytt arbetssätt – den sker inte på slutet. Den sker hela tiden – kulturen lever parallellt med sin förändring. Transformation är kultur, kultur är transformation. Nu även i SAFe 5.0 och sedan länge för Satya Nadella.

Referenser

Den semantiska transformationen – Noteringar från mitt blixttal på SAFe meetup – 191204

Temat på detta meetup var: Metrics – Mäta för att förbättra, lära, leverera men även driva förändringen

Först måste vi påminna oss om att vi alla är ledare för minst en person – oss själva. Där börjar ledarskapet. Att leda oss själva och andra innebär att kommunicera och visualisera vart vi ska och varför. Att leda i förändring kräver ett kommunikativ ledarskap där vi behöver uppdatera vårt språk för att skapa förutsättningar för både förändring och ständiga förbättringar.

Min fråga kring temat för meetupen blir: Hur kan vi som ledare med hjälp av de ord vi väljer att använda förändra beteenden?

När vi implementerar ett nytt ramverk med nya processer och principer som tex SAFe är det enkelt att gå i fällan och bara hantera det som är synligt i tex processer, verktyg, roller osv. För att få utväxling räcker inte det. Vi måste förändra både hur vi tänker och hur vi gör. Tar vi med oss ett språk anpassat till projekt och silos in till ett nytt sätt att utveckla får vi ingen långsiktig effekt. Och den ofta eftertraktade kulturförändringen är inte möjlig utan att vi förändrar vårt språk. Kulturförändringen börjar nämligen i samma sekund som vi väljer att anamma ett nytt arbetssätt – den sker inte på slutet.

Språk och mätetal

Om vi anammar ett nytt ramverk och börjar titta på mätetal men har kvar det gamla språket kring mätetal får vi inte till någon varaktig förändring.

I det plandrivna resursoptimeringstänket var det tex vanligt med mätetal kring resursoptimering. ”Hur många jobbar?” till skillnad mot i det lean-agila där vi mer är intresserade av ”Hur mycket jobb står stilla (och varför)?” och “Vad är Cost of Delay på jobbet som befinner sig stillastående i kön?”. Om vi går in i en lean-agila kontext med frågan ”hur många är sysselsatta?” får vi ingen förändring.

I det plandrivna resursoptimeringstänket var det vanligt att fråga efter ”Hur snabbt vi jobbar, kan vi jobba snabbare?”. I det lean-agila är vi mer intresserade av hur smart vi utvecklar. Vi vill accelerera hastigenhet på feedbacken eftersom vi anser att ett bra sätt att lära sig och bli bättre är genom feedback. Om vi går in i en lean-agila kontext med frågan ”kan vi jobba snabbare?” får vi ingen förändring.

I det plandrivna resursoptimeringstänket var det vanligt att fråga efter ”Hur mycket har vi gjort?”. I det lean-agila är vi mer intresserade av vilket värde vi har skapat. Om vi går in i en lean-agila kontext med frågan ”Kan vi göra mer?” får vi ingen förändring.

Det som är synligt är enklare men det osynlig ger större effekt.

Beteendeförändring

För att få till en beteendeförändring behöver vi förändra vårt språk. Det är enklare att hoppa rakt ner i verktygslådan och i metoder, det synliga, och slarva med orden. Det är vad vi säger och hur vi säger det som skapar förutsättningar för beteendeförändringar.

Vi behöver därför ställa oss frågan: Hur kan vi som ledare med hjälp av de ord vi väljer att använda förändra beteenden samtidigt som vi inför nya metoder och ramverk?

Notes from my talk @ Design Leadership & SAFe – 191120

Jens Wedin invited me to have a lightning talk at the meetup Design Leadership & SAFe. This is in short what I talked about and links to more reading that I was referring to.

I currently work as deputy head of LACE (Lean-Aglie Center) at Handelsbanken. In this blog I state my private thoughts.

The question stated in the invite (https://www.eventbrite.com/e/design-leadership-safe-tickets-79309973265) was:
How might we as design leaders or agile coaches and SAFe experts collaborate to find new and improved opportunities to create value in organizations where SAFe is used as framework?

This is my take on that:
A key answer to that is in the question. Leadership and Collaborate. The question then becomes: how to lead and collaborate? One hypothesis is to start your learning and leadership with a 3 x 3 view.

But first we we have to acknowledge that we all are leaders. You always leads at least one person: yourself. In your leadership lay a big responsibility to always encourage and inspire to learning – for yourself and for others. Toyota calls it Lean-thinking manager-teachers. As leaders we understand Lean thinking and principles and, as part of our everyday work activities, we teach them to others. There is always one person learning most in a class room situation: the teacher. Become a teacher!

We also need to acknowledge the fact that we all are developers. The difference between us is the prefix. We could be system developers, design developers, business developers and so on.

To change we have to lead, teach and we have to develop. Together.

Trying to describe the 3 x3 view
on learning and leadership at the meetup

Shift focus from method to the real purpose and then back to method

Don Reinertsen says: “What should we change in our development process? Eliminate waste? Increase quality? Shorten lead time? The key to answering this question is to step back to a more basic question: Why do we want to change the process? The answer: to increase profits.

How do we increase profits? The answer to that should decide how your development process should look like. And it is most likely a lean-agile process. Increase profits is of course crucial. But here can we lean more to the overall goal in Lean: value. “The goal of Lean is to deliver the maximum customer value in the shortest sustainable lead time … ”
It is up to you to define your value. It could be customer satisfactions, sustainability, less churn, happy co-workers, or a mix.

Learning and leadership with a 3 x 3 view

As a leader in SAFe and in a lean-agile context I need to be able to have the perspective IT-Customer-Business, I have to understand and refer to the knowledge base of Design-Lean-Agile and I have to encourage teamwork based on Structure-Purpose & Vision-Psychological safety.  

This is a good start point. After a while you wil be ready to go beyond the frameworks and models and dig deeper, especially around the knowledge areas and the teamwork parts.

Perspective

IT – Can we build it? Would it work?

Customer – Do customers and users want the solution?

Business – Will the solution creating more value than cost?

This perspective helps you both as an individual but also as a team, an ART and in the portfolio. Have we secured that we have those perspective when we entering a meeting or developing a product?

Knowledge

Design – explore the problem

Lean – build the right thing

Agile – build the thing right

Design is a way of working that enables us to act customer-centric and create successful services.

Lean is a way of thinking that aims to maximize customer benefit while minimizing waste in the system that produces customer benefit.  

Agile is about being adaptable and flexible in a changing world and together in cross-functional teams continuously delivering value with the customer in focus.

We need knowledge from all three areas and after a while we need to go deeper and discover what knowledge is behind design, lean and agile.

Team work

Structure – Scrum, Kanban, SAFe …

Purpose & vision – the why and the what

Psychological safety – a safe environment where all ideas are welcomed

If we leave one of these three out there will never be any real teamwork.

Lean-thinking manager-teachers

Management makes a system work. Leadership builds system or transforms old ones. To do that you need to learn and relearn all the time. And you have to teach and communicate.

Perspective, knowledge and team work will help you with that – regardless if you are in a SAFe context or not.

Do! And adjust. And think. But most important: do.

You will never be done so forget about done.  That is also important that everyone also understand – we will never be done.

Tell your story. Tell it every day, every week.

Hint: the story is not Lean-Agile or SAFe …

Good luck!

Read more

http://jonnyschneider.com/free-book

https://designthinking.ideo.com/

https://www.scaledagileframework.com/lean-agile-mindset

http://www.klas.one/2018/05/23/leadership-with-vision-navigate-by-numbers/

Paretoprincipen behöver Lean

På tidigt 1900-tal definierade Vilfredo Pareto (känd italiensk sociolog, nationalekonom och moralfilosof) den så kallade paretoprincipen.  Paretoprincipen är en empirisk regel enligt vilken 20 procent av orsakerna ofta står för 80 procent av verkan. I Vilfredo Paretos exempel visade han att 20 procent av den italienska befolkningen (funktionerna) innehade 80 procent av egendomen (värdet).

I perspektivet utveckling kan vi applicera Paretoprincipen på hur vi ska bryta ner och lansera våra features. Principen säger oss att vi får ut 80 % av värdet genom endast 20 % av funktionerna. En stor mängd av de funktioner vi utvecklar används aldrig eller sällan och skapar således inget eller litet värde. Fokus borde således läggas på de 20 procenten.

I böcker om Agil systemutveckling refereras ofta till Paretoprincipen. Ser vi på den tionde principen i det agila manifestet ”Enkelhet – konsten att maximera mängden arbete som inte görs – är grundläggande” går den hand i hand med Pareotprincipen. Konsten att maximera mängden arbete som inte görs det vill säga fokusera på de 20 procenten, fokusera inte på ”allt”.

Tongivande i Agil systemutveckling är att fokusera på att utveckla och leverera i små batchar vilket ger oss snabb feedback om det vi gör adderar värde eller inte. I stora projekt vet vi inte förens i slutet vilka de 20 procenten var som stod för en majoritet av värdet. I projekt krävs det att vi utvecklar 100 procent för att vi i efterhand ska kunna konstatera vilka av alla funktioner (de 20 procenten) var som gav 80 procent av värdet.

Hantera och prioritera kön

Men hur vet vi vilka av de features vi ska göra är inom ramen för de 20 procenten som potentiellt  utgör 80 procent av värdet?  För att optimera värdet behöver vi addera mekanismer från lean.

I lean produktutveckling är små batchar och hantering och prioritering av köer tongivande. Genom att prioritera innehållet (små batchar) i kön genom att små jobb med högt potentiellt värdet får gå först minimerar vi risken att träffa fel bland våra features.

Y-axeln som beskriver effekthemtagningen säkrar vi genom att leverera ofta för att ta hem feedback kring hur mycket värde vi skapar. Här hjälper oss SCRUM med struktur för att säkra den processen.

X-axeln som utgörs av de funktioner, eller features, vi utvecklar säkrar vi genom lean produktutveckling och värdebaserad prioritering. Mekanismerna i Lean startup som bygga-mäta-lära hjälper oss.

Sammanfattning

Paretoproncipen och agilt driver på oss att lansera tidigt och ofta med inställningen att en stor del av värdet kommer från en mindre del av de totala antalet features.

Lean hjälper oss att prioritera ibland alla features och ta små beslut ofta.

Time to market, knowledge & cash – tre delar i samma process

I lean strävar vi efter att optimera flödet och tiden mellan idé till effekthemtagning (Time to market). Att styra på den parametern är framförallt gångbart i en statisk kontext. I en dynamisk kontext som digital utvecklg behäver vi fler parametrar.

I digital utveckling i en komplex kontext blir tiden från idé till kunskap (Time to knowledge) central. När vi släpper ny funktionalitet till användaren och får feedback är det kunskap genom feedback vi främst är ute efter. Affärsvärdet kan realiseras initialt men det är över tid som den stora potentialen finns. Där behöver vår affärsprocess vara inbyggd i vår utvecklingsprocess. Time to cash sker iterativt och genom att se på affärsvärde som något vi upptäcker över tid – inte som något fördefinierat.   

Kunskap kan vi ofta hämta hem snabbare än värde

Därför är det viktigt att vi jobbar smartare och drivs av att lära oss genom feedback för att upptäcka det potentiella affärsvärdet genom iterativa lanseringar. Kunskap kan vi ofta hämta hem snabbare än värde men utan kunskap riskerar vi att missa var värdet finns på en rörlig marknaden där vi behöver kunna anpassa oss och ställa om snabbt till nya krav. Nokia var duktiga på time to market och time to cash på en befintlig marknad men missade time to knowlege.

Time to market, time to knowledge och time to cash är beroende av varandra men skiljer sig åt i hur vi mäter dem och vad vi vill att de ska göra och när. Det är när vi optimerar de tre delarna utifrån ett helhetstänk vi kan få rejäl utväxling. Var för sig gör de marginell nytta.

  • Time to market (output) – hur agil är vår pipeline?
  • Time to knowledge (outcome) – hur lär vi oss och går från “magkänsla” till “vi vet”?
  • Time to cash (outcome) – hur affärdriven och iterativ är vår utvecklingsprocess?

Time to market – tiden det tar för att ta en produkt till marknaden. Det är en lagging indicator, vi konstaterar tiden i efterhand. Värdet att få ner tiden är primärt kopplat till att vi vill lära oss snabbare inte nödvändigtvis att vi skapar värde snabbare. Det finns inget egenvärde i time to market – möjligen för ett systemteam. Time to market säger inget om värdet vi vill uppnå men spelar stor roll i hur snabbt vi kan få svar på om det finns något värde att hämta hem på marknaden.

Time to knowledge – tiden det tar från att vi definerar vår hypotes till att vi validerar den. Mätvärdet vi vill validera med är en leading indicator. Eftersom vi vill lära snabbt utvecklar vi i små batchar uttryckta som hypoteser som ger oss snabb feedback vilket gör att vi lär oss snabbare. Mätpunkter där vi validerar sätts upp som ”learning milestones”.

Time to cash – tiden det tar från idé till att vi skapar intäkt. Är intäkten högre än kostnaden för utvecklingen? Vi mäter över tid eftersom intäkter skapas över tid. Mätvärdet är av monetär art.


Time to cash och time to knowledge kräver att vi definera “learning milestons” där vi utvärderar löpande med objektiv data.

Time to cash surfar på time to market

Är inte detta vattenfall tänker du? Nej, inte om vi gör det i samma process, i samma loop, men ser det som olika mätvärden som har olika syften under olika tidshorisonter. En leading indicator surfar på en lagging indicator. Time to knowledge & cash surfar på time to market. Ju smidigare pipeline för time to market ju snabbare time to knowledge & cash.

Sammanfattning

  • I digital affärsutveckling är Time to market ett medel för att nå kunskap och intäkter
  • Affärsvärde upptäcker vi när vi utvecklar, det kan vi inte definera på förhand
  • Det är viktigare att vi lär oss snabbt än att vi jobbar snabbt
  • Att jobba snabbt leder sällan till att vi lär oss snabbt
  • Vår framgång bygger på att vi lär oss snabbare än våra konkurrenter (time to knowledge)
  • Ju smidigare pipeline för time to market ju snabbare time to knowledge & cash.

Smartare, inte snabbare

Den digitala transformationen är större än omställningen från resursoptimering till flödeseffektivisering. Transformationen utmanar också kulturen. Vi säger att vi förändrar kulturen efter att vi förändrar organisationen. När vi går från projektleverans till teamleverans förändrar vi en del av organisationen genom att vi sätter vi upp virtuella organisationer och introducerar nya metoder inom produkt- och systemutveckling. Om vi säger att vi förändrar kulturen efter att vi förändrar organisationen har vi ändå mycket att vinna på att inleda förändringen under metodskiftet.

Vi behöver både utmana  hur vi tänker och  hur vi gör. I förlängningen kräver transformationen att vi utvecklar vårt språk och vårt tänkande – där bor kulturen.

En gång lärde vi oss fel att nyckeln till ekonomisk framgång är effektivitet. Om vi tror på det kommer vi att fokusera på mätvärden som kapacitetsutnyttjande och hantera utvecklingsprocessen
med hög utnyttjandegrad (resursoptimering). Vi kommer mäta leverabler (output) utan att reflektera över värdet (outcome).

En gång lärde vi oss fel att att nyckeln till ekonomisk framgång är
överensstämmelse med planen. Om vi tror på det kommer vi att fokusera på att förhindra och korrigera avvikelser från planen. Vi kommer att investera kraft i att hantera oväntade hinder och ignorera nya möjligheter (innovation uteblir).

I omställningen från projekt och vattenfall till agila team och lean-agil
utveckling är språket centralt. Hur man förhåller sig till orden ”snabbare”, ”plan” och ”effektivare” avslöjar en del var man är i sin agila omställning. Vi behöver hjälpas åt i berättelsen att navigera rätt bland orden och att välja ett språk som bäddar för en uppdaterad kultur.

Vi ska inte jobba snabbare, vi ska jobba smartare.

Det finns flera saker som trumfar att jobba snabbare. Små batchar tex. En stor del av Lean produktutveckling bygger på processer för att jobba med mindre batchar. Vi omfamnar mindre batchar därför mindre batchar ger feedback snabbare och realiserar potentiellt värde snabbare. Det har inget att göra med att vi jobbar snabbare eller effektivare eller att kunderna får snabbare leveranser. Kunder vill inte nödvändigtvis få snabba leveranser de vill få rätt (= värde) leveranser.

Vi ska inte jobba snabbare, vi ska jobba smartare tillsammans och medlet är små ekonomiskt och storleksmässigt kvantifierade batchar uttryckta som hypoteser som ger oss snabb feedback vilket gör att vi lär oss snabbare och kan ta bättre ekonomiska beslut.

Genom att levererar i små batchar (iterationer och inkrement) tar vi mindre risker och vi hämtar hem det potentiella värdet snabbare. Det leder också till att vi får snabbare feedback. Och det är bara genom feedback baserad på objektiv data från våra IT-system och från våra kunder och användare som vi kan lära oss. I den projektdrivna kontexten sker lärandet sent eller aldrig.

Jobba snabbare spelar ingen roll om vi inte attackerar våra köer och storleken på jobben i dem, som exemplet nedan visar:

Jobba snabbare -> Små jobb -> Snabb feedback = ny kunskap snabbare

Jobba snabbare -> Stora jobb -> Långsam feedback= ny kunskap senare

Sammanfattning

  • Snabbar och effektivare (på fel sätt) väcker ett skadligt beteende som vi vill transformera oss från.
  • Vi ska inte jobba snabbare, vi ska jobba smartare.

Värdeloopsarmbandet

Bakgrund

Det här är en variant på ett klassiskt radband. Tanken med “Värdeloopsarmbandet” är att det ska hjälpa till att ge vägledning och fokus i transformationen. Det här är en första MVP. Håller konceptet? Ge gärna feedback: klas.fjarstedt [snabel-a] gmail.com

Få fokus på vägen till värdet med hjälp av Värdeloopsarmbandet

Alla tider hela tiden, är tider i förändring. De som är och har varit framgångsrika är de som surfar med förändringen och inte strävar mot. Det som nu sker i takt med digitaliseringen är att förändringen accelererar. Ett dynamiskt och komplext tillstånd är vardag och vi måste möta den vardagen genom att ständigt utveckla både våra produkter/tjänster och de processer vi utvecklar dem med. En agil organisation med ett lean-agilt mindset utvecklar båda.

I denna föränderliga värld finns det ett antal kärnvärden och principer som är tidlösa. Värdeloopsarmbandet är till för att hjälpa dig i vardagen att hitta kraften framåt genom att påminnas om ett par principer inspirerade av bland annat systemtänkande, lean och agilt.

När du fastnar i gamla hjulspår eller om någon har ett destruktivt traditionellt synsätt kring frågor i en dynamisk kontext – andas och följ värdeloopen från den vita Värdepärlan genom – Ledarskapspärlan (rosa) – Motivationspärlan (grön) – Kunskapspärlan (gul) – Kommunikationspärlan (cerise) – Hypotespärlan (pistage) – Innovationspärlan (mörkblå) – Flödespärlan (orange) – Jag-Du-Teampärlorna (genomskinnliga) – Helhetspärlan (blå).

Värdepärlan 

Den vita värdepärlan – början och slutet på loopen. När alla färger reflekteras framträder vitt och när alla andra pärlor samverkar skapas förutsättningar för värde.

Målet, som Lean har lärt oss, är att leverera den maximala mängden kundvärde på den kortast möjliga hållbara ledtiden med den högsta möjliga kvaliteten för kunder och samhället i stort. Hög moral, säkerhet och kundnöjdhet är andra viktiga mål och syften. Där börjar och slutar crikeln.

Ledarskapspärlan

Den rosa ledarksapspärlan påminner oss om att vi alla är ledare för minst en person – oss själva. Där börjar ledarskapet. Att leda oss själva och andra innebär att kunna kommunicera och visualisera vart vi ska och varför. Hur vi tar oss dit svarar teamet bäst på.

Att leda andra innebära att lära andra. Och för att lära andra måste du som ledare hela tiden lära. Och när vi lär och lär ut blir vi också varse perspektiven och inser att bara för att vi tittar åt samma håll ser vi inte samma sak. Genom empati skapar du som ledaren en förståelse för att olika männsikor ger gruppen olika perspektiv som rätt aggregerat skapar kreativitet.

Motivationspärlan

Den rosa motivationspärlan påminner oss om våra inneboende grundläggande drivkrafter. När vi föds är vi av naturen nyfikna. Det som motiverar oss är syfte, mästerskap och självstyre. Med tiden är det lätt att tappa bort de inre drivkrafterna.  

Syfte manar oss att göra något som känns meningsfullt och viktigt utöver det monetära.  Mästerskap väcker drivkraften att bli bättre, att lära oss mer. Självstyre är vår grundläggande vilja att styra oss själva. Du äger din egen motivation och inget hindar dig från att påverka andras.

Kunskapspärlan

Den gröna kunskapspärlan utmanar oss att accelererar vårt lärande. Den är vår katalysator när vi står inför en transformation. Den påminner oss om att intelligens och personlighet kan utvecklas – att min potential är okänd. Den stärker mitt dynamiska mindset och gör lärandet till ett mål i sig. Den uppmanar mig att alltid vara hungrig efter kunskap och att alltid vara villig att erkänna när jag inte vet.

Kunskapspärlan tar “att lära” förbi lärandet till en plats där nytänkande uppstår, där lärande innebär att tänka om och då också omfatta en avgörande sinnesförändring i oss. 

Kommunikationspärlan

Den gula kommunikationspärlan välkomnar motståndet och olikheterna och påminner oss om grundbetydelsen i kommunikation – att ”göra något gemensamt”.  Kommunikation bäddar för förflyttning. Om jag inte har förmågan att förflytta mig i tanken när jag möter på motstånd kommer jag heller aldrig att utvecklas.  Dialogen hjälper oss att vidga våra gränser tillsammans och diskussionen visar våra enskilda åsikter.

Det är inte bråttom att förstå. Det är bråttom att få oss att förstå att vi behöver förstå. Kommunikation hjälper oss med det.


Hypotespärlan

Den cerisa hypotespärlan hjälper oss att gå från jag tycker till vi vet, där vi vet uppstår i den hypotesdrivna utvecklingen när vi validerar eller falsifierar med objektiv data. Hypotesdriven utveckling gör oss alla till hungriga forskare som jagar data i form av värdeindikatorer att validera med.

Hypotesen tar oss från stelheten i det linjära tänkandet in i det cirkulära där vi tar oss framåt i den ständiga loopen byggamätalära. From know-it-all to learn-it-all.

Innovationspärlan

Den mörkblå innovationspärlan uppmanar oss om att  inte upprepa samma recept utan att utforska någonting nytt. Den öppnar våra ögon mot omvärlden och tar oss ut i verkligheten där kundernas faktiska behov väntar på innovativa lösningar.

Innovationspärlan påminner oss om att innovation bara kan hända om vi ger den tid och kraft. Därför fyller vi aldrig våra agendor till 100 % utan lämnar alltid tid till reflektion och omvärldsspaning – innovatörens luft och vatten.

Använd inte innovationens inneboende kraft till att lura systemet, använd det till att utveckla det. Innovera systemet som en helhet.

Flödespärlan

Den orangea flödesspärlan påminner oss om värdets väg från idé till konvertering. Se till att den vägen blir så kort som möjligt utan att gör avkall på hållbarhet och kvalitet. Målet är inte snabbhet, det är ett medel. Ju snabbare vi är  i vårt flöde desto tidigare får vi feedback från kunder och systemet. Genom feedback lär vi oss. Ett jämnt flöde skapar harmoni som både lärande och konvertering mår bra av.

Jag-du-teampärlorna

De tre jag-du-teampärlorna är genomskinliga, lika osynliga som kraften i teamet när vi arbetar tillsammans mot samma mål. Teamet består av individer där jag tillsammans är stark. Ett team är inte, ett team blir – genom individerna. För att det ska hända behöver vi en grundläggande respekt för människor. Människor är inte resurser, människor är kompetenser och i teamet aggregerar vi kompetenserna till en förmåga vida överstigande den individuella.  

Helhetspärlan

Den blå helhetspärlan är vår version av den blå planeten som astronauterna ser från månen. Först med den blicken kan vi förstå hur saker hänger ihop och att en del är beroende av en annan fast att det vid första anblicken inte verkar så.

Helhetspärlan uppmanar oss att ta ett steg tillbaka och betrakta vår omgivning i ett helhetsperspektiv. Då blir det uppenbart att vi måste optimera systemet med den blicken. Lokal optimering driven ur falska incitament är inte bara destruktiv för den enskilda leveransen utan också för alla delar i systemet. Se skönheten i helheten och kom ihåg att delarna också är helheter. Och det är bara vi som helheter som kan optimera systemet.


Tack till Penny för MVP-produktion

Värde genom korta ledtider och innovation

Flera intressanta rubriker och artiklar i dagens DN (2019-02-16) i motordelen som visar på de olika perspektiven kring produkt- och processutveckling.

Framgångsrik utveckling bygger både på en effektiv utvecklingsprocess med inbyggt kvalitet och en förmåga till innovation.

”Många taxichaufförer vittnar om att de kör över 30.000 mil med sina Hybrid-Toyotor utan att byta annat än radiokanal.”

”Veckans mest udda nyhet – från Tessla!” (Dog mode) ”Volvo i bottenskiktet i ny kvalitetsmätning” (Lexus och Toyota i topp)

”Jaguares Tesladödare en dröm att köra”

Tesla kan svara blixtsnabbt på ett kundönskemål (Dog Mode) med att uppdatera mjukvaran i bilen som förstås blir en PR-succe. Men sett till produktivitet i fabriken ligger de många gånger efter liknande bilar i antalet skeppade Teslas per anställd. Väntelistan är lång och konkurrenterna börjar komma i fatt. (Se tex Jaguare-rubriken)

Toyota, som inte just nu kan slå Tesla i snabbhet med sina mjukvarauppdateringar, är å andra sidan bra mycket mer effektiva i fabriken och dessutom bäst i klassen kring kvalitet.

Vem kommer vinna i längden då? Alla biltillverkare kommer att kunna leverera elbilar i framtiden men vem kan leverera med kortast möjliga ledtid och kontinuerligt erbjuda förbättringar via mjukvaruuppdateringar?

Ja, svaret står väl skrivet i taket på Lean-huset. Den som kan leverera: Värde med kortast möjliga hållbara ledtider och högsta kvalitet för människor och sammhället …

Hypotesdriven utveckling – ett avgörande medel i transformationen

  • En del i den digitala transformationen är att vi går från jag tycker till vi vet, där vi vet uppstår i den hypotesdrivna utvecklingen när vi validerar med objektiv data
  • Utan möjlighet att validera med objektiv data kan vi inte utveckla hypotesdrivet, dvs då faller transformationen
  • En nytta som inte går att mäta är ingen nytta
  • Målet är att tjäna pengar, transformation till en lean-agil kontext är ett medel. Utan transformation är chansen liten att nå framgång och tjäna pengar i en accelererande digital kontext.

Metod och process får aldrig bli målet. Det kan var lätt att gå i den fällen, inte minst vid en transformation där metod och process är avgörande katalysatorer för förändring. Men varken transformation som sådan, metod eller process är målet. Målet för ett företag är kort och gott att tjäna pengar

Väljer vi SAFe för att transformera vår verksamhet och utveckling från den destruktiva resurs- och lokaloptimerande verksamheten till att skapa värde över tid med kortast möjliga hållbara ledtider och hela systemet i fokus finns det vissa medel som är mer avgörande än andra. Jag vill lyfta fram tre.

Lean-agilt ledarskap, hypotesdriven utveckling och DevOps. Utan dessa tre ingen SAFe, ingen transformation och därmed ingen potential att nå lönsamhet över tid.

Denna bloggpost fokuserar på hypotesdriven utveckling. Som de två andra är det allas angelägenhet, därmed inte sagt att det är allas syssla. Men kom ihåg, vi är alla utvecklare.

Hypotesdriven utveckling: “Tillsammans definiera hypoteser som vi genom experiment validerar eller falsifierar med objektiv data.”

Hypotesdriven utveckling förklaras enklast genom att vi likt forskaren formulerar en hypotes och sen gör ett experiment för att validera eller falsifiera hypotesen. Experimentet i vår utveckling formulerar vi som en MVP. Eftersom hur snabbt vi lär oss är avgörande för vår potential att skapa värde bryter vi ner arbetet i små delar och itererar. För att accelerera lärandet utvecklar vi i cyklen bygga-mäta-lära. Genom verktyg som Lean ger oss för att optimera flödet fokuserar vi på att minimerar den totala tiden genom läroloopen. Ett av de största slöseriet i utvecklingsprocessen är som bekant att slösa med människors tid …

Både EPIC och Feature-processen i SAFe bygger på hypotesdriven utveckling med hjälp av Lean startup och Lean UX. Det är absolut grundläggande att förstå det och att det är allas angelägenhet. Låt er inte luras av metodnamnen Lean Startup och Lean UX där det är lätt att tro att ”det bara är för start ups” och “lean UX: det fixar väl UX:arna …”. Fel, fel, fel. Alla måste förstå och praktisera dessa metoder på alla nivåer. Annars är det bara att glömma transformationen.

Featuren innehåller tre viktiga parametrar:  hypotesformulering kring nyttan som ska var mätbar.

Det är helt avgörande för produkt- och systemutveckling i en komplex miljö att vi förstår och lär oss arbeta systematiskt med effekthemtagning i team och tåg –i små batchar.

Vägledning i Nyttorealisering 2.0

Det statliga initiativet ”E-delegationen” beskriver i sin publikation ”Vägledning i nyttorealisering 2.0” vad nytta är.
Citaten nedan är direkt kopierade från publikationen:

  • En nytta har alltid ett kvantifierbart värde uttryckt i pengar, resurser eller kvalitetsmått (tid, volym, nöjd kund etc.).
  • Nytta är en mätbar förändring vilken uppfattas som positiv av en eller flera intressenter och som bidrar till ett eller flera verksamhetsmål.
  • En nytta som inte går att mäta är ingen nytta. 
  • Utan nollmätning kan man bara gissa om en förändringsinsats har haft någon effekt.

Formulera hypoteser

I den traditionella projektstyrda utvecklingskontexten beställde vi saker och observerade progress vid beslutspunkter. När vi arbetar hypotesdrivet formulerar vi en hypotes och validerar löpande med objektiv data som vi matchar mot uppsatta leading indicators. Vi går från jag tycker – till vi vet med hjälp av objektiv data.

Men det räcker alltså inte med att formulera en hypotes. Den absolut avgörande faktorn och förmågan är om vi kan och har IT-förmågan att mäta och använda objektiv data för att validera vår hypotes med. För att följa den röda råden i bloggposten: utan data ingen hypotesdriven utveckling. Gällande data och metrics är det första vi måste förstå skillnaden mellan output och outcome och varför de två är viktiga men bör hållas isär.

I SAFe använder vi data (metrics) på två sätt – output och outcome.

Output ger oss en bild av i vilken hastighet vi leverera utan att nödvändigtvis berätta om det är värde vi levererar. Klickar vi på Metrics ingången i the big picture i SAFe hittar vi framför allt metrics kopplat till tågets output. Den datan är viktig för att kunna vara förutsägbar i vår leveranstakt gentemot affären/kunden. I Lean budget processen på portföljnivå måste vi ha en idé om tågens leveransförmåga och hastighet för att kunna prioritera och distribuera EPICs över tågen. Det är lätt att gå i fällan och bara säkra den här metrics-förmågan, vilket slutar i att vi visst hittar en förutsägbarhet och en hastighet men vi leverera därmed inte per automatik värde. Hastighet är inte lika med värde.

“What gets measured gets managed.” Det vi mäter är det vi styr verksamheten efter. Eftersom output är enklare att mäta än outcome är risken överhängande att vi styr affärsutvecklingen med fel siffror. ”Vi jobbar snabbt men levererar skräp”. Tips: fråga aldrig hur snabbt det går eller om det kan gå snabbare när du går på ett teams demo. Fråga efter värde! Och hur du kan hjälpa teamen att röja hinder för att skapa värde med kortare ledtider.

Outcome är förenklat att mäta värdet som våra EPICS och Features realiserar eller är på väg att realisera. Eftersom vi bara ska utveckla så länge det värde vi skapar är mer prioriterat än något annat potentiellt värde är det viktig att vi mäter kontinuerligt och över tid i våra iterationer. Team som äger effekten testar och analyserar bäst över tid.

I hypotesdriven utveckling använder vi leading indicators för att validera våra hypoteser mot medan vi utvecklar dem. De är framåtriktade mätetal som vi kan påverka till skillnad mot traditionella lagging indicators som är mer av konstaterande art. IT-förmågan att arbeta med leading indicators utvecklar vi i pipelinen och de hänger tätt ihop med release on demand med funktioner som nollmätning, funnel analys, feature toggles, A/B tester, dark releaser osv.

När vi hanterar leadning indicatos måste vi vara på vår vakt att de inte är vanity metrics, dvs mätetal som är enkla att mäta med som inte direkt kan påverka värdet. 

Här är ett exempel på hur variablerna kan förhålla sig till varandra:

  • Affärsmål: väga 75 kg
  • Vanity metric: mäta antal gånger man ställer sig på vågen (ej relevant)
  • Lagging indicator: jag väger just nu 80 kg (konstaterande)
  • Leading indicator 1: mäta kalorier i Pizzan framför oss (actionable)
  • Leading indicator 2: mäta förbränning i träningsaktiviteten (actionable)

Sammanfattning

  • Det finns massor av medel för att nå målet, vissa medel är mer avgörande än andra
  • Hypotesdriven utveckling är det övergripande konceptet och processen att bedriva utveckling på i SAFe
  • Hypotesdriven utveckling är allas angelägenhet
  • Vi kan inte utveckla hypotesdrivet om vi inte har tillgång till objektiv data för att validera med och göra nollmätningar
  • Vi behöver mäta både output och outcome. Det är två olika metrics och vi måste förstå hur de förhåller sig till varandra och till målet/visionen

Referenser

  • https://www.scaledagileframework.com/metrics/
  • https://www.scaledagileframework.com/guidance-applied-innovation-accounting-in-safe/
  • https://www.bokus.com/bok/9781491953600/lean-ux-2e/
  • https://www.bokus.com/bok/9780307887894/the-lean-startup/
  • https://www.scaledagileframework.com/blog/innovation-accounting-helps-to-quickly-evaluate-mvps/
  • https://www.digg.se/nyheter–publikationer/Publikationer/nyttorealisering

Så kommer du igång med mobbutveckling

Börja med att anamma inställningen att alla är utvecklare. Sen har vi olika prefix som tex systemutvecklare, verksamhetsutvecklare, metodutvecklare, UXutvecklare osv … Men alla är utvecklare helt enkelt. Och därför behöver vi oftare utveckla tillsammans.

Som ledare handlar det om att skapa förutsättningar för att få det att hända

Men hur kommer du igång? Eftersom det handlar om förändring kan du per automatik inte räkna med draghjälp. Som ledare handlar det om att skapa förutsättningar för att få det att hända. Effekten av mobbutveckling måste upplevas och det går inte bara genom teori förstå fördelarna. Seeing is believing. Så, kavla upp armarna och:

  • Hitta minst två personer som du delar drivet och intresset med. Helst en kodare (driver) och en UX:are (navigatör). Men två personer gör ingen mobb. Men det är en början.
  • Är du produktägare – gör aktiviteten till ett mål med sprinten. Kom ihåg att ett agilt team utvecklar sin produkt/tjänst och utvecklar hur vi arbetar tillsammans. Markera det senare som PO genom att göra way of working viktigast i en sprint. Helt plötsligt är sprintmålet ”vi ska mobbutveckla”.
  • Hämta/låna/köp en stor TV-apparat.
  • Fixa ett bord att ställa framför teven (finns ofta bord i källaren).
  • Muta in en plats som blir dedikerad till mobbutveckling
  • Sätt upp lappar på vångingsplanet som berättar vad ni gör. Kommunicera och missionera – iterera.
  • Boka in de ni vill samarbeta med (team, personer, projekt). Kalla dem till platsen där skärmen står. ”Är mötet här? Ja, och nu upphör mötet och overgår till utveckling.”
  • Ganska snabbt får ni anhängare. Håll dem varma. Behåll momentum genom att bjuda in och boka upp.
  • Sätt upp mål kopplat till själva aktiviteten. ”Vi ska mobbutveckla x timmar innan jul”.
  • Blogga internt om vad ni gör och med vilka och förstås vilken effekt ni skapar.
  • Vill du ha draghjälp från SAFe kan du slänga upp princip 1, 2, 8 och 9 på väggen och peka på om nån skulle få för sig att ifrågasätta vad som händer.

Lycka till!