Hvordan snakke Improvement Kata

Vi har praktisert Improvement Kata i en god stund nå, men vi sliter fortsatt med betydningen av de ulike begrepene, og hvordan vi skal bruke dem. Etter å ha lest denne artikkelen bør du ha en klar oversikt over delene i Improvement Kata, hva de betyr, og hvordan du kan bruke dem. 

La oss komme i gang!

Prosess vs. resultat

Før vi kan dykke ned i detaljene i Improvement Kata-språket, bør vi begynne med å skille mellom prosess og resultat. Dette er kanskje den vanskeligste delen av Improvement Kata. Vi er vant til å tenke på mål og resultater og på hva vi ønsker å oppnå. Vi ønsker å nå produksjonstallene våre. Vi er fokusert på resultatet. Med Improvement Kata fokuserer vi på prosessen som fører til et resultat. Vi skal sette prosessen i fokus, og resultatet er utfallet av prosessen. Jeg prøver alltid å forklare det på denne måten:

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

• Men du kan gjennomføre en prosess.

Hvorfor er dette vanskelig?

Denne holdningsendringen er den vanskeligste delen av Improvement Kata. Vi har tidlig lært oss å tenke på utfall og resultater. Vi må sette oss dristige mål og strekke oss etter stjernene. Det er ikke innarbeidet i vår kultur å tenke på prosessen. Vi må derfor endre tankesettet vårt for å lære oss å skille mellom dette, og fokusere på prosessen.

Forbedring av det daglige arbeidet er viktigere enn det daglige arbeidet. Men det kommer ikke i stedet for det daglige arbeidet.

Før vi begynner, en oversikt

Dette er en skjematisk oversikt over Improvement Kata-prosessen. Jeg vil diskutere de ulike delene i denne artikkelen, men du kan bruke dette bildet som en referanse.

The true north - vår visjon for selskapet

Vi ønsker å være et rolig selskap. Og vi tror at vi kan oppnå det ved å etterstrebe disse fire tingene i prosessene våre:

• Enkelt vareflyt, i rekkefølge og på forespørsel.

• Zero defekter.

• 100 % verdiskapning.

• Sikkerhet for mennesker.

La oss undersøke dem nærmere.

Flyt av enkeltartikler, i sekvens og på forespørsel

Dette er et av de overordnede prinsippene i Improvement Kata. Før vi gjør noe annet, bør vi flytte en prosess, uansett hvilken som helst prosess, nærmere en flyt av ett enkelt element, i sekvens og på forespørsel. Men hvorfor det?

Vi ønsker en stabil og forutsigbar prosess. Vi vil ha en skalerbar prosess, og en prosess uten mye sløsing. For å komme dit må vi se flaskehalsene i prosessen. Ved å gå over til en enkelt vareflyt ser vi disse flaskehalsene så raskt som mulig. Og enda tydeligere. Du må løse dem, ellers kan ingenting flyte gjennom prosessen.

Hvis vi har en prosess med én enkelt vareflyt, i rekkefølge, kan vi ikke ta snarveier og fremskynde ting for å få ting gjort. Vi må fjerne en flaskehals i prosessen før vi kan gå videre. Så lenge vi ikke er der, kan vi jukse. Hvis du tydelig kan se flaskehalsen i en prosess, kan du begynne å løse den og forbedre prosessen, noe som fører til bedre resultater.

Null feil

Hver gang en prosess ikke fungerer som definert, har vi en defekt. En defekt fokuserer altså på prosessen, ikke på resultatet. Alle feil bør undersøkes for å lære av dem.

Mange problemer er lik en fornøyd sjef.

100 % verdiskapning

Alt vi gjør i en prosess, skal tilføre verdi til sluttresultatet av prosessen. Hvis vi gjør ting i prosessen som ikke tilfører verdi, bør vi la være å gjøre det. Dette kalles også å fjerne sløsing fra en prosess.

Mange "lean"-diskusjoner fokuserer på å bli kvitt sløsing. Antagelsen er at det å bli kvitt sløsing er et mål med lean, mens det å bli kvitt sløsing faktisk er et resultat av Improvement Kata. Det er ikke et mål i seg selv.

Sikkerhet for mennesker

Alt vi gjør, må følge dette prinsippet. Når vi setter en utfordring, en måltilstand eller en prosessbeskrivelse, må vi alltid sjekke om den er innenfor denne grensen.

Folk gjør feil. Systemene vi har på plass, skal bidra til å forhindre det, eller hvis de skjer, skal de redusere konsekvensene av en feil. Det skal være trygt å gjøre feil. De skal ikke føre til katastrofale hendelser. Og hvis det skjer en katastrofal eller mindre katastrofal hendelse, må vi forbedre systemene.

Trygghet for mennesker betyr også at alle kan være seg selv på jobben. Vi skal kunne si ifra, gi tilbakemeldinger og dele kunnskap. Det er slik vi lærer som mennesker og som organisasjon.

Nåværende tilstand

Hvis vi snakker om den nåværende tilstanden, snakker vi om prosessen vi ønsker å forbedre. I en perfekt verden bør denne prosessen ha en klar beskrivelse. Denne beskrivelsen skal fortelle deg hvordan vi ønsker at prosessen skal fungere. Beskrivelsen bør inneholde følgende:

• Alle trinn i prosessen.

• Hvor lang tid hvert trinn kan ta.

• Hvor mange personer som jobber med et trinn.

• Eventuelle kvalitetsmålinger for dette trinnet.

• Hvor mye lagerbeholdning som er tillatt per trinn.

• Den totale syklustiden for prosessen.

Den kan også inneholde en beskrivelse av hva som kjennetegner denne prosessen. Eventuelle bekymringer med hensyn til sikkerheten for mennesker bør nevnes, og sist, men ikke minst, bør den inneholde en resultatmåling.

For en ny prosess kan denne beskrivelsen gjøres underveis. Mens vi jobber med å forbedre prosessen, oppdager vi hvordan prosessen skal fungere. Dette kan og bør skrives ned, slik at det kan brukes som dokumentasjon på prosessen. Og mens vi endrer og forbedrer prosessen, bør denne dokumentasjonen oppdateres. Du vil se at jo lenger du jobber med en prosess, jo mer forfinet blir den.

Hvorfor er dette vanskelig?

For å kunne gå over til enkeltelementflyt og ikke ende opp med lokale optimaliseringer, må vi etterstrebe én prosess. Se opp for å beskrive en prosess som en frittstående prosess, som egentlig er en del av en større prosess, og dermed er en delprosess i seg selv.

Da vi begynte å bruke Improvement Kata, hadde vi en utviklingsprosess, en testprosess og en dokumentasjons-, oversettelses- og kommunikasjonsprosess. Jeg hadde vanskelig for å overbevise utviklingsavdelingen om at vi måtte inkludere testprosessen som en del av den totale utviklingspipelinen. For ved å forbedre utviklingssyklusen, men ikke være i stand til å teste og distribuere historier, hadde vi skapt sløsing.

Vi må optimalisere helheten.

Eksempel

La oss bruke et eksempel for å illustrere dette. Vår prosess for å levere verdi til kundene består av følgende delprosesser for å få en funksjon på nett:

• Bestemme hva som skal bygges - 3 uker

  • Samle inn informasjon om funksjonsforespørsler (på forespørsel).

  • Ranger funksjonsforespørsler for å få en prioritet (i rekkefølge).

  • Beskriv denne funksjonen og planlegg utviklingen av den.

• Utvikle en historie - 3 dager

  • Diskuter med produkteier.

  • Definere akseptkriterier.

  • Designe, bygge, kodegjennomgang.

  • Refaktorere koden.

  • Teste med teamet.

• Test og distribuer en historie - 3 timer

  • Bygg historien til staging.

  • Kjør akseptansetester.

  • Test en historie.

  • Slå sammen historien.

  • Distribuer til produksjon.

• Oversett - 1 dag

  • Lag en enkelt elementpakke for denne historien for oversetterne.

  • Send pakken til oversetterne.

  • Send pakken til oversetterne.

  • Oversetterne oversetter etikettene for denne historien.

• Dokumentere og kommunisere - 3 dager

  • Skriv utgivelsesmerknader.

  • Skrive, oppdatere og publisere hjelpeartikler.

  • Kommunisere med relevante kunder.

Vi har mye dokumentasjon for hvert trinn som beskriver hvilken kvalitet som skal følges, hvor mange historier som kan inngå i et gitt trinn, hvor mange iterasjoner som er tillatt, og hvor mange feil som er tillatt i en historie. Det ville vært en artikkel for seg selv.

Det viktige å ta med seg fra dette er at for å optimalisere helheten må du ha alle trinnene i én prosess og måle dem. Hvis du ikke gjør det på denne måten, vil en optimalisering i ett trinn føre til sløsing i et annet trinn.

Resultatmåling

Resultatmålet beskriver hva en prosess produserer. Dette er resultatet av prosessen. Vi måler resultatmålet en gang i blant for å sjekke om prosessen fortsatt er på vei til å levere det ønskede resultatet til selskapet. Det er dette andre selskaper bruker som mål eller delmål.

Hvorfor er dette vanskelig?

Det vi synes er vanskelig, er å skille klart mellom resultater (resultatmåling) og prosess. Og når man først har definert et resultatmål, blir det plutselig et mål. Som vi må nå, og som vi blir skuffet over at vi ikke når. Det eneste formålet med resultatmålene er å kunne måle om man nærmer seg det målet man ønsker å oppnå.

Eksempel

Resultatmålet fra utviklingsprosessen vår er at vi ønsker å lansere en funksjon til 100 dollar hver tredje måned per team. Vi tror at det å lansere en slik funksjon som gir verdi for kundene våre hver måned, vil gi oss den veksten selskapet trenger for å være et rolig selskap.

Challenge

Utfordringen beskriver den fremtidige tilstanden i prosessen som du ønsker å oppnå. Det vanskelige med dette er å huske på at vi snakker om prosessen, ikke resultatet. Du skal beskrive hvordan du ønsker at prosessen skal fungere, og ikke et mål eller et resultat. En utfordring kan ligge langt unna med en lang tidslinje, alt fra seks uker til et år. Hvis du allerede vet hvordan du skal komme dit, er den for nær. Utfordringen gir retning, og vil bli brutt ned til mindre delmål.

Det beste stedet å starte med å definere utfordringen er å komme til flyten av enkeltartikler. Deretter bør du strebe etter in sequence, og den siste delen bør handle om etterspørsel. Det tok oss to år å komme frem til enkeltvareflyt og i sekvens.

Hvorfor er dette vanskelig?

Igjen handler dette om å tenke i prosesser og ikke i resultater. For mange mennesker er det vanskelig å takle usikkerheten om at man ikke vet hvordan man skal komme dit.

Eksempler

Da vi begynte med Improvement Kata, hadde vi en utfordring med å gå over til single item flow for publisering av en historie. Så når en historie var klar, skulle den legges ut på nettet.

Et annet eksempel er delprosessen for oversettelser. Vi definerte utfordringen slik:
I løpet av tre måneder skal vi få til en enkeltpostflyt for oversettelser, med en syklustid på én dag, uten å bruke tid på å svare på spørsmål.

Måltilstand

En måltilstand er det første steget som bringer deg nærmere utfordringen din, og som er oppnåelig i løpet av tre til seks uker. Dette er den fremtidige tilstanden i prosessen som vi sikter mot. Måltilstanden vil gi oss en følelse av retning for forbedringene våre. Hvordan gjør vi det? Vi måler arbeidsprosessen mens vi jobber. Hver gang vi har et avvik fra prosessen slik den er beskrevet i måltilstanden, må vi se nærmere på det. Vi kaller det en "rotårsaksanalyse" (forkortet RCA). Ved å gjennomføre RCA-analyser får vi informasjon om flaskehalsen vår.

Eksempel

For utfordringen om oversettelsene definerte vi denne første målbetingelsen:
Definér og mål tiden det tar å oversette et enkelt element til alle språk. Vi ønsker å måle per språk.

Bottleneck

Noen ganger har vi omtalt dette som et hinder. Men ordet flaskehals er mye bedre egnet til å beskrive hva det er. En prosess kan bare ha én flaskehals (men mange hindringer). Flaskehalsen er det som hindrer oss i å nå måltilstanden.

Hvis du ser på et timeglass, er den minste delen flaskehalsen. Å øke størrelsen på timeglasset før eller etter flaskehalsen øker ikke flyten. Å forbedre noe annet enn flaskehalsen er sløsing. Flaskehalsen hindrer varen i å flyte uavbrutt gjennom prosessen, eller er den delen av prosessen som har lavest gjennomstrømning.

Bare ved å forbedre flaskehalsen kommer du nærmere måltilstanden. Vi løser flaskehalsen ved å gjennomføre en PDCA-syklus (mer om det senere).

Hvorfor er dette vanskelig?

Det vanskeligste er å definere flaskehalsen. Når du begynner å forbedre deg og får taket på det, ser du mange ting som kan forbedres, men som ikke er flaskehalsen. Det er vanskelig å motstå trangen til å løse disse tingene, spesielt når det er små ting du kan gjøre. Det er vanskelig å holde seg til å løse flaskehalsen, og det krever en viss disiplin. På den annen side, selv om teorien sier at det bare finnes én flaskehals, er det alltid bedre å løse noe enn å lete etter flaskehalsen og ikke løse noe. Når du gjennomfører en forbedring, får du praktisert RCA- og PDCA-syklusene.

Forbedre det som må forbedres, ikke det som kan forbedres.

Eksempel

I oversettelseseksemplet vårt definerte vi den første flaskehalsen på følgende måte:
Vi vet ikke hva et element består av. Vi har ikke definert et element, og vi vet ikke hvilke etiketter og sider som må oversettes, som er en del av elementet.

RCA

Som jeg forklarte, er RCA en forkortelse for "rotårsaksanalyse". Hver gang vi har et avvik fra måltilstanden, gjennomfører vi en RCA for å finne årsaken til avviket. Ved å finne rotårsaken finner vi flaskehalsen.

Hvorfor er dette vanskelig?

Et avvik fra måltilstanden skjer aldri på et beleilig tidspunkt, og som oftest må du forstyrre folk for å få dem til å komme sammen for å gjøre RCA-en. Vi liker å gjennomføre RCA så nært opp til avviket som mulig, slik at informasjonssporet ikke blir kaldt. Så det å gjennomføre RCA er en avveining mellom å ikke jobbe i flyt og å forbedre seg daglig.

Her om dagen hadde jeg en diskusjon med Maarten, frontend-utvikler og UX-designer, om en funksjon som det tok lang tid å få på nett. Det utspilte seg slik:

Maarten: Endelig har vi historien som automatisk genererer bildene til dokumentasjonen på nettet. Det tok oss to RCA-er og mye arbeid å få det til.
Meg: Ikke bekymre deg for at det tok lengre tid enn planlagt, for vi lærte mye i prosessen.
Maarten: Ja, RCA-ene vi gjorde, endret tankesettet mitt fra "denne prosessen er ustabil" til "hvorfor er denne prosessen så ustabil?".

Med dette tankesettet kan du begynne å se på årsaken og tenke på løsninger. Med det tidligere tankesettet blir du bare irritert og frustrert, og det vil ikke forbedre noe som helst.

Vi må bremse ned for å kjøre fortere.

PDCA

PDCA er en forkortelse for "Plan, Do, Check, Act". Det er en prosess for å forbedre en flaskehals i små skritt. Utfordringen her er å finne på et lite skritt for å forbedre prosessen. Noe du kan gjøre i dag. For noen ting trenger vi åpenbart mer tid. For eksempel hvis vi trenger å utvikle eller automatisere noe. Men vi bør alltid prøve å gjøre ting mindre. Kan vi først gjøre en forbedring for hånd, slik at vi kan se om det bringer oss nærmere måltilstanden? Når det er tilfelle, kan vi automatisere? En liten forbedring vil flytte synsfeltet vårt og øke kunnskapsterskelen vår. Etter forbedringen ser og vet vi mer.

For store forbedringer kan føre til sløsing fordi de ikke bringer oss nærmere utfordringen. Derfor må vi holde forbedringene små. Vi kan bare gjøre én forbedring per prosess per dag. Ellers vet vi ikke om forbedringen faktisk har ført til noe.

Hvorfor er dette vanskelig?

Som oftest ser vi mange ting som kan forbedres. Og vi ønsker å få dem ut av veien, i den tro at det vil løse alle problemer, slik at vi kan fortsette med arbeidet vårt. Men vi vet ikke om alle problemene fortsatt eksisterer når vi har gjort noen små forbedringer.

En annen vanskelig ting er å ikke tenke for langt frem og se alle hindringene på veien. Du vet ikke om disse hindringene faktisk vil materialisere seg når vi er der. Og om hindringen faktisk er flaskehalsen. Så det vet vi ikke før vi kommer dit.

Å ta små skritt er å maksimere det arbeidet som ikke er gjort.

Synsfelt eller kunnskapsterskel

Synsfeltet eller kunnskapsterskelen er det vi vet i dag, og det vi kan se. I dette synsfeltet finnes det mange mulige forbedringer. Utfordringen vil gi oss en retning for forbedringene våre. Hvis vi gjør en liten forbedring, vil vi flytte synsfeltet vårt (blå linje) og øke kunnskapsterskelen vår i retning av utfordringen. Etter denne forskyvningen vet vi mer og kan se andre forbedringer og skritt vi kan ta for å nå utfordringen.

Hvorfor er dette vanskelig?

Vi klandrer oss selv for at vi ikke har sett forbedringer tidligere. Du kan få noen til å si "hvorfor gjorde vi ikke dette i fjor?".

Jeg må sitere den berømte nederlandske fotballspilleren Cruijff her:

Je gaat het pas zien als je het doorhebt.

Oversatt omtrent til:

Du vil bare se det når du forstår det.