Hur man talar Improvement Kata

Vi har tränat Improvement Kata ganska länge nu, men vi kämpar fortfarande med innebörden av de olika termerna och hur man tillämpar dem. Efter att ha läst den här artikeln bör du ha en klar bild av delarna i Improvement Kata, vad de betyder och hur man tillämpar dem. 

Låt oss komma igång!

Process kontra resultat

Innan vi går in på detaljerna i Improvement Kata-språket bör vi börja med att skilja mellan processen och resultatet. Det här är kanske den svåraste delen av Improvement Kata. Vi är vana vid att tänka på mål och resultat och vad vi vill åstadkomma. Vi vill komma upp i våra produktionssiffror. Vi är fokuserade på resultatet. Med Improvement Kata fokuserar vi på den process som leder till ett resultat. Vi ska sätta processen i rampljuset, och resultatet är resultatet av processen. Jag försöker alltid förklara det på det här sättet:

• Du kan inte utföra ett mål eller ett resultat.

• Men du kan utföra en process.

Varför är detta svårt?

Detta skifte i tankesätt är den svåraste delen av Improvement Kata. Vi har tidigt fått lära oss att tänka på utfall och resultat. Vi måste sätta upp djärva mål och sikta mot stjärnorna. Det ligger inte i vår kultur att tänka på processen. Så vi måste ändra vårt tankesätt för att lära oss att göra den här distinktionen och fokusera på processen.

Förbättring av det dagliga arbetet är viktigare än det dagliga arbetet. Men det kommer inte i stället för det dagliga arbetet.

Innan vi börjar, en översikt

Det här är en schematisk översikt över Improvement Kata-processen. Jag kommer att diskutera de olika delarna i den här artikeln, men du kan använda den här bilden som referens.

The true north - vår vision för företaget

Vi vill vara ett lugnt företag. Och vi tror att vi kan uppnå det genom att sträva efter dessa fyra saker i våra processer:

• Flöde av enstaka artiklar, i sekvens och på begäran.

• Noll defekter.

• 100% mervärde.

• Säkerhet för människor.

Låt oss undersöka dem närmare.

Flöde av enstaka artiklar, i sekvens och på begäran

Detta är en av de övergripande principerna i Improvement Kata. Innan vi gör något annat bör vi flytta en process, vilken process som helst, närmare att vara ett flöde av ett enda objekt, i sekvens och på begäran. Men varför ska vi göra det?

Vi vill ha en stabil och förutsägbar process. Vi vill ha en skalbar process och en process utan en massa slöseri. För att nå dit måste vi se flaskhalsarna i den processen. Att gå över till ett flöde med en enda artikel visar dessa flaskhalsar så snart som möjligt. Och på ett tydligare sätt. Du måste lösa dem, annars kan ingenting flöda genom processen.

Om vi har en flödesprocess med ett enda objekt, i sekvens, kan vi inte ta genvägar och påskynda saker för att få saker gjorda. Vi måste ta bort en flaskhals i processen innan vi kan gå vidare. Så länge vi inte är där kan vi fuska. Om du tydligt kan se flaskhalsen i en process kan du börja lösa den och förbättra processen, vilket leder till bättre resultat.

Noll defekter

Varje gång en process inte fungerar enligt definitionen har vi en defekt. En defekt är alltså inriktad på processen, inte på resultatet. Varje defekt bör undersökas för att vi ska kunna dra lärdom av den.

Många problem är lika med en glad chef.

100% värdeadderande

Allt vi gör i en process ska ge ett mervärde till processens slutresultat. Om vi gör saker i vår process som inte tillför värde ska vi inte göra det. Detta kallas också att ta bort slöseri från en process.

Många diskussioner om "lean" fokuserar på att bli av med slöseri. Antagandet är att eliminering av slöseri är ett mål för lean, medan eliminering av slöseri faktiskt är ett resultat av Improvement Kata. Det är inte ett mål i sig självt.

Säkerhet för människor

Allt vi gör måste följa den här principen. När vi sätter upp en utmaning, ett målvillkor eller en processbeskrivning måste vi alltid kontrollera om det ligger inom denna gräns.

Människor begår misstag. De system vi har på plats ska hjälpa till att förhindra det, eller om de inträffar ska de minska de konsekvenser som ett misstag får. Det ska vara säkert att göra misstag. De ska inte leda till några katastrofala händelser. Och om en katastrofal händelse eller en mindre katastrofal händelse inträffar måste vi förbättra systemen.

Trygghet för människor innebär också att alla kan vara sig själva på jobbet. Vi ska kunna säga vad vi tycker, ge feedback och dela med oss av kunskap. Det är så vi lär oss som människor och som organisation.

Nuvarande tillstånd

Om vi talar om nuläget talar vi om den process som vi vill förbättra. I en perfekt värld skulle denna process ha en tydlig beskrivning. Beskrivningen ska tala om hur vi vill att processen ska fungera. Beskrivningen bör innehålla:

• Alla steg i processen.

• Den tid varje steg kan ta.

• Hur många personer som arbetar med ett steg.

• Alla kvalitetsmått för detta steg.

• Hur mycket lager som tillåts per steg.

• Den totala cykeltiden för processen.

Den kan också innehålla en beskrivning av processens egenskaper. Eventuell oro för människors säkerhet bör nämnas, och sist men inte minst bör den innehålla en resultatmätning.

För en ny process kan den här beskrivningen göras under resans gång. Medan vi arbetar med att förbättra processen upptäcker vi hur processen ska fungera. Detta kan och bör skrivas ner så att det kan användas som dokumentation av processen. Och medan vi förändrar och förbättrar processen bör denna dokumentation uppdateras. Du kommer att se att ju längre du arbetar med en process, desto mer förfinad blir den.

Varför är detta svårt?

För att kunna gå över till single item flow och inte hamna i lokala optimeringar måste vi sträva efter en enda process. Se upp så att du inte beskriver en process som en fristående process, som i själva verket är en del av en större process och därmed är en egen delprocess.

När vi började tillämpa Improvement Kata hade vi en utvecklingsprocess, en testprocess och en dokumentations-, översättnings- och kommunikationsprocess. Jag hade svårt att övertyga utvecklingsavdelningen om att vi var tvungna att inkludera testprocessen som en del av den totala utvecklingspipelinen. För genom att förbättra utvecklingscykeln, men inte kunna testa och distribuera stories, hade vi skapat slöseri.

Vi måste optimera helheten.

Exempel

Låt oss använda ett exempel för att illustrera detta. Vår process för att leverera värde till kunder består av följande delprocesser för att få en funktion online:

• Besluta vad som ska byggas - 3 veckor

  • Samla information om funktionsförfrågningar (på begäran).

  • Ranka funktionsförfrågningar för att få en prioritet (i sekvens).

  • Beskriv denna funktion och planera den för utveckling.

• Utveckla en story - 3 dagar

  • Diskutera med produktägaren.

  • Definiera acceptanskriterier.

  • Design, bygg, kodgranskning.

  • Refaktorisera koden.

  • Testa med teamet.

• Testa och distribuera en story - 3 timmar

  • Bygga storyn till staging.

  • Köra acceptanstester.

  • Testa en story.

  • Sammanfoga story.

  • Distribuera till produktion.

• Översätt - 1 dag

  • Skapa ett paket med enstaka objekt för denna story för översättare.

  • Skicka paketet till översättarna.

  • Översättarna översätter etiketterna för den här artikeln.

• Dokumentera och kommunicera - 3 dagar

  • Skriva release notes.

  • Skriva, uppdatera och publicera hjälpartiklar.

  • Kommunicera med relevanta kunder.

Vi har en hel del dokumentation för varje steg som beskriver vilken kvalitet som ska följas, hur många stories som kan finnas i ett visst steg, hur många iterationer som tillåts och hur många defekter som tillåts i en story. Det skulle vara en artikel för sig.

Den viktiga lärdomen av detta är att för att optimera helheten måste man ha alla steg i en process och mäta dem. Om du inte gör det på det här sättet kommer en optimering i ett steg att leda till slöseri i ett annat steg.

Utfallsmått

Utfallsmåttet beskriver vad en process ger upphov till. Detta är resultatet av processen. Vi mäter utfallsmåttet då och då för att kontrollera om processen fortfarande är på rätt väg för att leverera det önskade resultatet till företaget. Det är detta som andra företag använder som mål eller targets.

Varför är detta svårt?

Det vi tycker är svårt är att göra en tydlig åtskillnad mellan resultat (utfallsmått) och process. Och när man väl har definierat ett resultatmått verkar det helt plötsligt vara ett mål. Som vi måste uppnå, och blir besvikna över att vi inte gör det. Det enda syftet med resultatmåttet är att kunna mäta om man närmar sig det mål man vill uppnå.

Exempel

Resultatmåttet från vår utvecklingsprocess är att vi vill släppa en 100-dollarsfunktion var tredje månad per team. Vi tror att en sådan funktion som levererar värde till våra kunder varje månad kommer att ge oss den tillväxt som företaget behöver för att vara ett lugnt företag.

Utmaning

Utmaningen beskriver det framtida tillstånd för din process som du vill uppnå. Det svåra med detta är att komma ihåg att vi pratar om processen, inte resultatet. Du ska beskriva hur du vill att processen ska fungera, och inte ett mål eller resultat. En utmaning kan ligga långt borta med en lång tidslinje, allt mellan sex veckor och ett år. Om du redan vet hur du ska ta dig dit är den för nära. Utmaningen ger riktning och kommer att brytas ner till mindre målförhållanden.

Det bästa stället att börja definiera utmaningen är att komma till flödet för enstaka artiklar. Sedan bör du sträva efter sekvens och den sista delen bör handla om efterfrågan. Det tog oss två år att nå fram till flödet av enstaka artiklar och i sekvens.

Varför är detta svårt?

Återigen handlar det om att tänka i processer och inte i resultat. För många människor är det svårt att hantera osäkerheten om att man inte vet hur man ska komma dit.

Exempel

När vi började med Improvement Kata hade vi utmaningen att gå över till single item flow för att släppa en story. Så när en berättelse var klar skulle den läggas ut online.

Ett annat exempel är delprocessen för översättningar. Vi definierade utmaningen så här:
Inom tre månader få till ett single item-flöde för översättningar, med en cykeltid på en dag, utan att spendera någon tid på att svara på frågor.

Måltillstånd

Ett måltillstånd är det första steget som tar dig närmare din utmaning och som är möjligt att uppnå inom tre till sex veckor. Det är processens framtida tillstånd som vi siktar på. Måltillståndet kommer att ge oss en känsla av riktning för våra förbättringar. Hur gör vi? Vi mäter vår arbetsprocess medan vi arbetar. Varje gång vi har en avvikelse från den process som beskrivs i måltillståndet måste vi undersöka det. Vi kallar det för en "grundorsaksanalys" (förkortat RCA). Genom att göra RCA:erna får vi information om vår flaskhals.

Exempel

För utmaningen om översättningarna definierade vi detta första målvillkor:
Definiera och mät den tid det tar att översätta ett enskilt objekt till alla språk. Vi vill mäta per språk.

Flaskhals

Ibland har vi kallat det för ett hinder. Men ordet flaskhals är mycket bättre lämpat att beskriva vad det är. En process kan bara ha en flaskhals (men många hinder). Flaskhalsen är det som hindrar oss från att komma till vårt måltillstånd.

Om du tittar på ett timglas är flaskhalsen den del som är minst. Att öka storleken på timglaset före eller efter flaskhalsen ökar inte flödet. Att förbättra något annat än flaskhalsen är slöseri. Flaskhalsen hindrar artikeln från att flöda oavbrutet genom processen eller är den del av processen som har lägst genomströmning.

Det är bara genom att förbättra flaskhalsen som du kommer närmare ditt måltillstånd. Vi löser flaskhalsen genom att göra en PDCA-cykel (mer om det senare).

Varför är detta svårt?

Det svåraste är att definiera flaskhalsen. När man börjar förbättra och får kläm på det ser man en massa saker som kan förbättras men som inte är flaskhalsen. Det är svårt att motstå viljan att lösa dessa problem, särskilt när det handlar om små saker som man kan göra. Att hålla fast vid att lösa flaskhalsen är svårt och kräver viss disciplin. Å andra sidan, även om teorin säger att det bara finns en flaskhals, är det alltid bättre att lösa något än att leta efter flaskhalsen och inte lösa något. Att göra en förbättring innebär att du får öva på RCA- och PDCA-cyklerna.

Förbättra det som måste förbättras, inte det som kan förbättras.

Exempel

I vårt översättningsexempel definierade vi den första flaskhalsen på följande sätt:
Vi vet inte vad en artikel består av. Vi har inte definierat en artikel och vi vet inte vilka etiketter och sidor som behöver översättas som ingår i den artikeln.

RCA

Som jag förklarade är RCA en förkortning av "root cause analysis". Varje gång vi har en avvikelse från vårt måltillstånd gör vi en RCA för att hitta grundorsaken. Genom att hitta grundorsaken får du reda på var flaskhalsen finns.

Varför är detta svårt?

En avvikelse från måltillståndet inträffar aldrig vid en lämplig tidpunkt, för det mesta måste man störa människor så att de samlas för att göra RCA. Vi vill gärna göra RCA så nära inpå avvikelsen som möjligt så att informationsspåret inte blir kallt. Så att göra RCA är en avvägning mellan att inte arbeta i flöde och att förbättra dagligen.

Jag hade en diskussion häromdagen med Maarten, Front-End Developer & UX Designer, om en funktion som tog lång tid att få online. Det utvecklades så här:

Maarten: Nu har vi äntligen en story som automatiskt genererar bilderna för dokumentationen online. Det tog oss två RCA:er och mycket arbete att få det gjort.
Mig: Oroa dig inte för att det tog längre tid än planerat, för vi lärde oss mycket under processen.
Maarten: Ja, de RCA:er vi gjorde förändrade mitt tankesätt från "den här processen är instabil" till "varför är den här processen så instabil?".

Med detta tankesätt kan du börja titta på grundorsaken och fundera på lösningar. Med det tidigare tankesättet blir du bara irriterad och frustrerad och det kommer inte att förbättra någonting.

Vi måste sakta ner för att kunna gå snabbare.

PDCA

PDCA är en förkortning för "Plan, Do, Check, Act". Processen för att förbättra en flaskhals i små steg. Utmaningen här är att komma på ett litet steg för att förbättra processen. Något som du kan göra redan idag. För vissa saker behöver vi uppenbarligen mer tid. Till exempel om vi behöver utveckla eller automatisera något. Men vi bör alltid försöka göra saker och ting mindre. Kan vi först göra en förbättring för hand så att vi kan se om det för oss närmare måltillståndet? När så är fallet, kan vi automatisera? En liten förbättring kommer att förändra vårt synfält och höja vår kunskapströskel. Efter förbättringen ser vi och vet vi mer.

En alltför stor förbättring kan leda till slöseri eftersom den inte för oss närmare utmaningen. Det är därför vi måste hålla förbättringarna små. Vi kan bara göra en förbättring per process och dag. Annars vet vi inte om förbättringen faktiskt förbättrade något.

Varför är detta svårt?

För det mesta ser vi en massa saker som kan förbättras. Och vi vill få dem ur vägen och tror att det kommer att lösa alla problem, så att vi kan fortsätta med vårt arbete. Men vi vet inte om alla dessa problem fortfarande finns kvar när vi gör några små förbättringar.

En annan svår sak är att inte tänka för långt framåt och se alla hinder på vägen. Man vet ju inte om de hindren faktiskt kommer att dyka upp när vi är där. Och om det där hindret faktiskt är flaskhalsen. Så det vet vi inte förrän vi är där.

Att ta små steg är att maximera det arbete som inte är gjort. Vi kommer dit när vi kommer dit.

Synfält eller kunskapströskel

Synfältet eller kunskapströskeln är det vi för närvarande vet och det vi kan se. I det här synfältet finns många möjliga förbättringar. Utmaningen kommer att ge oss en riktning för våra förbättringar. Om vi gör en liten förbättring kommer vi att förskjuta vårt synfält (blå linje) och öka vår kunskapströskel i riktning mot utmaningen. Efter denna förskjutning vet vi mer och kan se andra förbättringar och steg som vi kan ta för att nå vår utmaning.

Varför är detta svårt?

Vi klandrar oss själva för att vi inte har sett förbättringar tidigare. Du kan komma på någon med att säga "varför gjorde vi inte det här förra året?".

Jag måste här citera den berömde holländske fotbollsspelaren Cruijff:

Je gaat het pas zien als je het doorhebt.

Översatt ungefär till:

Du ser det först när du förstår det.