Hvordan man taler Improvement Kata

Vi har trænet Improvement Kata i et godt stykke tid nu, men vi kæmper stadig med betydningen af de forskellige udtryk, og hvordan vi skal anvende dem. Efter at have læst denne artikel bør du have et klart billede af forbedringskataens dele, hvad de betyder, og hvordan du anvender dem. 

Lad os komme i gang!.

Proces vs. resultat

Før vi kan dykke ned i detaljerne i Improvement Kata-sproget, bør vi starte med at skelne mellem processen og resultatet. Dette er måske den sværeste del af Improvement Kata. Vi er vant til at tænke på mål og resultater, og hvad vi ønsker at opnå. Vi vil gerne nå vores produktionstal. Vi er fokuseret på resultatet. Med Improvement Kata fokuserer vi på den proces, der fører til et resultat. Vi skal sætte processen i centrum, og resultatet er udfaldet af processen. Jeg prøver altid at forklare det på denne måde:

• Du kan ikke udføre et mål eller et resultat.

• Men du kan udføre en proces.

Hvorfor er det så svært?

Dette skift i tankegang er den sværeste del af Improvement Kata. Vi er tidligt blevet opdraget til at tænke på resultater. Vi skal sætte dristige mål og række ud efter stjernerne. Det er ikke indgroet i vores kultur at tænke på processen. Så vi er nødt til at foretage et mindset-skift for at lære at skelne og fokusere på processen.

Forbedring af det daglige arbejde er vigtigere end det daglige arbejde. Men det kommer ikke i stedet for det daglige arbejde.

Før vi går i gang, et overblik

Dette er en skematisk oversigt over Improvement Kata-processen. Jeg vil diskutere de forskellige dele i denne artikel, og du kan bruge dette billede som reference.

Det sande nord - vores vision for virksomheden

Vi ønsker at være en rolig virksomhed. Og vi tror på, at vi kan opnå det ved at stræbe efter disse fire ting i vores processer:

• Single item flow, i rækkefølge og on-demand.

• Zero defects.

• 100% value-added.

• Security for people..

Lad os undersøge dem nærmere.

Flow af enkeltvarer, i rækkefølge og on-demand

Det er et af de overordnede principper i Improvement Kata. Før vi gør noget andet, bør vi flytte en proces, en hvilken som helst proces, tættere på at være et flow af et enkelt element, i rækkefølge og on-demand. Men hvorfor nu det?

Vi vil have en stabil og forudsigelig proces. Vi vil have en skalerbar proces og en proces uden en masse spild. For at nå dertil er vi nødt til at se flaskehalsene i den proces. Når vi går over til et flow med et enkelt element, ser vi de flaskehalse så hurtigt som muligt. Og mere tydeligt. Du er nødt til at løse dem, ellers kan intet flyde gennem processen.

Hvis vi har en proces med et enkelt emneflow i rækkefølge, kan vi ikke skære hjørner og fremskynde tingene for at få dem gjort. Vi er nødt til at fjerne en flaskehals i processen, før vi kan komme videre. Så længe vi ikke er der, kan vi snyde. Hvis du tydeligt kan se flaskehalsen i en proces, kan du begynde at løse den og forbedre processen, hvilket fører til bedre resultater.

Nul fejl og mangler

Hver gang en proces ikke fungerer som defineret, har vi en defekt. Så en defekt er fokuseret på processen, ikke på resultatet. Alle fejl bør undersøges for at lære af dem.

Mange problemer er lig med en glad chef.

100 % værditilvækst

Alt, hvad vi gør i en proces, skal tilføre værdi til slutresultatet af processen. Hvis vi gør ting i vores proces, som ikke tilfører værdi, bør vi ikke gøre det. Dette kaldes også at fjerne spild fra en proces.

Mange "lean"-diskussioner fokuserer på at slippe af med spild. Antagelsen er, at det at slippe af med spild er et mål for at være lean, mens det at slippe af med spild faktisk er et resultat af Improvement Kata. Det er ikke et mål i sig selv.

Sikkerhed for mennesker

Alle de ting, vi gør, skal overholde dette princip. Når vi sætter en udfordring, en måltilstand eller en procesbeskrivelse, skal vi altid tjekke, om den er inden for denne grænse.

Folk begår fejl. De systemer, vi har på plads, skal hjælpe med at forhindre det, eller hvis de sker, skal de reducere konsekvenserne af en fejl. Det skal være sikkert at begå fejl. De bør ikke resultere i katastrofale hændelser. Og hvis der sker en katastrofal begivenhed eller en mindre katastrofal begivenhed, skal vi forbedre systemerne.

Sikkerhed for mennesker betyder også, at alle kan være sig selv på jobbet. Vi skal kunne sige vores mening, give feedback og dele viden. Det er sådan, vi lærer som mennesker og som organisation.

Nuværende tilstand

Hvis vi taler om den nuværende tilstand, taler vi om den proces, vi ønsker at forbedre. I en perfekt verden burde denne proces have en klar beskrivelse. Beskrivelsen skal fortælle, hvordan vi gerne vil have, at processen skal fungere. Beskrivelsen bør indeholde:

• Alle trin i processen.

• Den tid, hvert trin kan tage.

• Hvor mange mennesker der arbejder på et trin.

• Alle kvalitetsmålinger for dette trin.

• Hvor meget lagerbeholdning der er tilladt pr. trin.

• Den samlede cyklustid for processen.

Den kan også indeholde en beskrivelse af processens karakteristika. Eventuelle bekymringer vedrørende menneskers sikkerhed bør nævnes, og sidst, men ikke mindst, bør den indeholde en resultatmåling.

For en ny proces kan denne beskrivelse laves undervejs. Mens vi arbejder på at forbedre processen, opdager vi, hvordan processen skal fungere. Det kan og bør skrives ned, så det kan bruges som dokumentation for processen. Og mens vi ændrer og forbedrer processen, skal denne dokumentation opdateres. Du vil se, at jo længere tid du arbejder med en proces, jo mere raffineret bliver den.

Hvorfor er det så svært?

For at kunne gå over til single item flow og ikke ende med lokale optimeringer skal vi stræbe efter én proces. Pas på med at beskrive en proces som en selvstændig proces, som i virkeligheden er en del af en større proces, og dermed er en delproces i sig selv.

Da vi begyndte at anvende Improvement Kata, havde vi en udviklingsproces, en testproces og en dokumentations-, oversættelses- og kommunikationsproces. Jeg havde svært ved at overbevise udviklingsafdelingen om, at vi var nødt til at inkludere testprocessen som en del af den samlede udviklingspipeline. For ved at forbedre udviklingscyklussen, men ikke være i stand til at teste og implementere historier, havde vi skabt spild.

Vi er nødt til at optimere helheden.

Eksempel

Lad os bruge et eksempel til at illustrere dette. Vores proces med at levere værdi til kunder består af følgende delprocesser for at få en funktion online:

• Beslut hvad der skal bygges - 3 uger

  • Saml oplysninger om funktionsanmodninger (efter behov).

  • Ranger funktionsanmodninger for at få en prioritet (i rækkefølge).

  • Beskriv denne funktion, og planlæg udviklingen af den.

• Udvikl en historie - 3 dage

  • Diskuter med produktejeren.

  • Definér acceptkriterier.

  • Design, byg, kodegennemgang.

  • Refaktorér koden.

  • Test med teamet.

• Test og udrulning af en historie - 3 timer

  • Byg historien til staging.

  • Kør accepttest.

  • Test en historie.

  • Sammenlæg historien.

  • Udrul til produktion.

• Oversæt - 1 dag

  • Opret en enkelt pakke for denne historie til oversætterne.

  • Send pakken til oversætterne.

  • Oversætterne oversætter etiketterne til denne historie.

• Dokumenterer og kommunikerer - 3 dage

  • Skriv udgivelsesnoter.

  • Skrive, opdatere og udgive hjælpeartikler.

  • Kommunikere med relevante kunder.

Vi har en masse dokumentation for hvert trin, der beskriver, hvilken kvalitet der skal overholdes, hvor mange historier der kan være i et givet trin, hvor mange iterationer der er tilladt, og hvor mange fejl der er tilladt i en historie. Det ville være en artikel for sig selv.

Det vigtige, man kan lære af dette, er, at hvis man vil optimere helheden, skal man have alle trin i en proces og måle dem. Hvis du ikke gør det på denne måde, vil en optimering i ét trin medføre spild i et andet trin.

Resultatmåling

Resultatmålingen beskriver, hvad en proces producerer. Det er resultatet af processen. Vi måler outcome-metricen en gang imellem for at tjekke, om processen stadig er på vej til at levere det ønskede resultat til virksomheden. Det er det, andre virksomheder bruger som mål eller delmål.

Hvorfor er det så svært?

Det, vi synes er svært, er at skelne klart mellem resultater (outcome metric) og proces. Og når man først har defineret en resultatmåling, ser det pludselig ud til at være et mål. Som vi er nødt til at nå, og som vi bliver skuffede over ikke at nå. Det eneste formål med en resultatmåling er at kunne måle, om man kommer tættere på det mål, man ønsker at nå.

Eksempel

Resultatet af vores udviklingsproces er, at vi ønsker at udgive en funktion til 100 dollars hver tredje måned pr. team. Vi tror, at en sådan funktion, der giver værdi til vores kunder hver måned, vil give os den vækst, som virksomheden har brug for til at blive en rolig virksomhed.

Udfordring

Udfordringen beskriver den fremtidige tilstand i din proces, som du ønsker at nå. Det svære ved dette er at huske på, at vi taler om processen, ikke resultatet. Du skal beskrive, hvordan du gerne vil have, at processen skal fungere, og ikke et mål eller et resultat. En udfordring kan ligge langt væk med en lang tidshorisont, alt mellem seks uger og et år. Hvis du allerede ved, hvordan du kommer derhen, er den for tæt på. Udfordringen giver retning og bliver brudt ned til mindre mål.

Det bedste sted at starte med at definere udfordringen er at nå frem til enkeltvareflow. Derefter bør du stræbe efter in sequence, og den sidste del bør handle om efterspørgsel. Det tog os to år at nå frem til flow af enkeltvarer og i rækkefølge.

Hvorfor er det så svært?

Igen handler det om at tænke i processer og ikke i resultater. For mange mennesker er det svært at håndtere den usikkerhed, at man ikke ved, hvordan man skal komme derhen.

Eksempler

Da vi startede med Improvement Kata, havde vi den udfordring at gå over til single item flow for at frigive en historie. Så når en historie var klar, skulle den være online.

Et andet eksempel er delprocessen for oversættelser. Vi definerede udfordringen sådan her:
I løbet af tre måneder skal vi nå frem til et enkelt emneflow for oversættelser med en cyklustid på én dag uden at bruge tid på at besvare spørgsmål.

Måltilstand

En måltilstand er det første skridt, der bringer dig tættere på din udfordring, og som kan nås inden for tre til seks uger. Det er den fremtidige tilstand i processen, vi sigter mod. Måltilstanden vil give os en fornemmelse af retningen for vores forbedringer. Hvordan gør vi det? Vi måler vores arbejdsproces, mens vi arbejder. Hver gang vi har en afvigelse fra processen som beskrevet i måltilstanden, er vi nødt til at se nærmere på det. Det kalder vi en 'root cause analysis' (RCA). Ved at udføre RCA'er får vi oplysninger om vores flaskehals.

Eksempel

Til udfordringen om oversættelserne definerede vi denne første målbetingelse:
Definér og mål den tid, det tager at oversætte et enkelt element til alle sprog. Vi ønsker at måle pr. sprog.

Flaskehals

Nogle gange har vi kaldt det en forhindring. Men ordet flaskehals er meget bedre egnet til at beskrive, hvad det er. En proces kan kun have én flaskehals (men mange forhindringer). Flaskehalsen er det, der forhindrer os i at nå vores måltilstand.

Hvis du ser på et timeglas, er flaskehalsen den del, der er mindst. At øge størrelsen på timeglasset før eller efter flaskehalsen øger ikke flowet. At forbedre alt andet end flaskehalsen er spild. Flaskehalsen forhindrer varen i at flyde uafbrudt gennem processen eller er den del af processen, der har den laveste gennemstrømning.

Kun en forbedring af flaskehalsen vil bringe dig tættere på din måltilstand. Vi løser flaskehalsen ved at lave en PDCA-cyklus (mere om det senere).

Hvorfor er det så svært?

Det sværeste er at definere flaskehalsen. Når du begynder at forbedre dig og får styr på det, ser du en masse ting, der kan forbedres, men som ikke er flaskehalsen. Trangen til at løse de ting er svær at modstå, især når det er små ting, man kan gøre. Det er svært at holde fast i at løse flaskehalsen, og det kræver en vis disciplin. På den anden side, selv om teorien siger, at der kun er én flaskehals, er det altid bedre at løse noget end at søge efter flaskehalsen og ikke løse noget. Når du laver en forbedring, får du mulighed for at praktisere RCA- og PDCA-cyklusserne.

Forbedre det, der skal forbedres, ikke det, der kan forbedres.

Eksempel

I vores oversættelseseksempel definerede vi den første flaskehals på følgende måde:
Vi ved ikke, hvad et element består af. Vi har ikke defineret et element, og vi ved ikke, hvilke etiketter og sider, der skal oversættes, der er en del af det element.

RCA

Som jeg forklarede, er RCA en forkortelse for "root cause analysis". Hver gang vi har en afvigelse fra vores måltilstand, laver vi en RCA for at finde den grundlæggende årsag. Når du finder den grundlæggende årsag, finder du flaskehalsen.

Hvorfor er det så svært?

En afvigelse fra måltilstanden sker aldrig på et belejligt tidspunkt, for det meste er man nødt til at forstyrre folk for at få dem til at mødes og lave RCA'en. Vi vil gerne lave RCA'en så tæt som muligt på det tidspunkt, hvor afvigelsen sker, så informationssporet ikke bliver koldt. Så at lave RCA er en afvejning mellem ikke at arbejde i flow og at forbedre sig dagligt.

Forleden havde jeg en diskussion med Maarten, Front-End Developer & UX Designer, om en funktion, der tog lang tid at få online. Det udviklede sig sådan her:

Maarten: Vi har endelig historien, der automatisk genererer billederne til dokumentationen online. Det tog os to RCA'er og en masse arbejde at få det gjort.
Mig: Du skal ikke bekymre dig om, at det tog længere tid end planlagt, for vi lærte en masse i processen.
Maarten: Ja, de RCA'er, vi lavede, flyttede min tankegang fra "denne proces er ustabil" til "hvorfor er denne proces så ustabil?".

Med dette mindset-skift kan du begynde at se på den grundlæggende årsag og tænke på løsninger. Med den tidligere tankegang bliver du kun irriteret og frustreret, og det vil ikke forbedre noget.

Vi er nødt til at sætte farten ned for at kunne køre hurtigere.

PDCA

PDCA er en forkortelse for 'Plan, Do, Check, Act'. Det er en proces, hvor man forbedrer en flaskehals i små skridt. Udfordringen her er at finde på et lille skridt til at forbedre processen. Noget, du kan gøre i dag. Til nogle ting har vi naturligvis brug for mere tid. F.eks. hvis vi skal udvikle eller automatisere noget. Men vi bør altid forsøge at gøre tingene mindre. Kan vi først lave en forbedring i hånden, så vi kan se, om den bringer os tættere på måltilstanden? Når det er tilfældet, kan vi så automatisere? En lille forbedring vil flytte vores synsfelt og øge vores videnstærskel. Efter forbedringen ser og ved vi mere.

En for stor forbedring kan føre til spild, fordi den ikke bringer os tættere på udfordringen. Det er derfor, vi skal holde forbedringerne små. Vi kan kun lave én forbedring pr. proces pr. dag. Ellers ved vi ikke, om forbedringen rent faktisk har forbedret noget.

Hvorfor er det så svært?

Det meste af tiden ser vi en masse ting, der kan forbedres. Og vi vil gerne have dem af vejen i den tro, at det vil løse alle problemer, så vi kan fortsætte med vores arbejde. Men vi ved ikke, om alle problemerne stadig eksisterer, når vi har lavet nogle små forbedringer.

En anden svær ting er ikke at tænke for langt frem og se alle forhindringerne på vejen. Man ved ikke, om de forhindringer rent faktisk vil dukke op, når vi er der. Og om den forhindring faktisk er flaskehalsen. Så vi ved det ikke, før vi er der.

At tage små skridt er at maksimere det arbejde, der ikke er gjort. Vi når frem, når vi når frem.

Synsfelt eller videnstærskel

Synsfeltet eller videnstærsklen er det, vi ved i øjeblikket, og det, vi kan se. I dette synsfelt er der mange mulige forbedringer. Udfordringen vil give os en retning for vores forbedringer. Hvis vi foretager en lille forbedring, vil vi flytte vores synsfelt (blå linje) og øge vores videnstærskel i retning af udfordringen. Efter dette skift ved vi mere og kan se andre forbedringer og skridt, vi kan tage for at nå vores udfordring.

Hvorfor er det så svært?

Vi bebrejder os selv, at vi ikke har set forbedringer tidligere. Du kan fange nogen i at sige "hvorfor gjorde vi ikke det her sidste år?".

Jeg er nødt til at citere den berømte hollandske fodboldspiller Cruijff her:

Je gaat het pas zien als je het door hebt.

Groft oversat:

Du vil først se det, når du forstår det.