Hvorfor vi har målbetingelser i stedet for mål

Behold roen og vær stolt. Det er det vi streber etter her hos Easy LMS. Det høres fint ut, men hvordan kommer vi dit? Vi styrer etter prosess, og ikke etter resultater. Vi ønsker at prosessene våre skal bli bedre, slik at vi får bedre resultater. Det er derfor vi bruker målbetingelser i stedet for mål. Selv om de høres like ut, er de helt forskjellige. Vi skal forklare hvorfor.

Forklaring av målbetingelser og mål

La oss begynne med et reelt eksempel (fra Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results) som du sikkert kjenner deg igjen i. Du ønsker å stå opp om morgenen og være på jobb innen én time. Hvis dette er ditt personlige mål, og du er sent ute, må du skynde deg. Kanskje du kjører for fort, hopper over frokosten eller unnlater å pusse tennene. Du tar snarveier for å nå målet ditt. Hvis du definerer dette som en måltilstand, må du dele det opp i delmål som du kan måle. Hvis du ikke kommer deg på jobb i løpet av én time, er det ikke noe problem, for du vet hvilket delmål du kan forbedre deg på. Så la oss bryte ned måltilstanden til følgende trinn:

Resultatet (målet) av denne prosessen er å komme på jobb i tide, godt mett, påkledd, dusjet, med rene tenner og uten å bli stresset. Det er i alles interesse?

Ok, men hvordan skiller mål seg fra målbetingelser?

En måltilstand er en beskrivelse av prosessene i det daglige arbeidet når alt går som smurt.

Tilbake til litt teori. Vi kjenner alle følelsen når arbeidet ikke går som planlagt. Ting tar lengre tid enn du trodde, eller du støter på hindringer underveis. Det er mye som kan gå galt. En måltilstand er en beskrivelse av prosessene i det daglige arbeidet når alt går som smurt. En måltilstand beskriver hvordan vi ønsker at arbeidsprosessen og alle dens delprosesser skal være. Det er den fremtidige tilstanden for en prosess som du sikter mot. Måltilstanden vil gi oss en retning for forbedringsarbeidet. Hvordan gjør vi det? Vi måler arbeidsprosessen mens vi jobber. Hver gang en prosess ikke fungerer som definert i måltilstanden, må vi se nærmere på det. Vi kaller det en "rotårsaksanalyse". Vi prøver å finne en enkel løsning. Ved å implementere denne kommer vi raskt nærmere den ønskede tilstanden.

Sammenlign det med et mål. Et mål skal nås. Du må gjøre alt som står i din makt for å nå målet, som i rutineeksemplet ovenfor. Det høres ut som en heroisk ting å gjøre, ikke sant? Det er feil. Det er dumt, etter vår mening. Mål fører til stress, overtid og skuffelse over å ikke nå målene. Det skaper muligheten til å ta snarveier for å nå målet. Dette går ut over kvaliteten og kundetilfredsheten i det lange løp;

Hvis du må nå et mål, vil du ikke investere i prosessforbedringer.

Dessuten, hvis du må oppnå et mål, vil du ikke investere i prosessforbedringer. Prosessforbedringer lønner seg bare over tid. Tid brukt på forbedringer vil selvfølgelig gå ut over de kortsiktige resultatene. Når du endelig når målet ditt, eller når fristen din, kan du i ettertid se tilbake på de tingene som ikke gikk som planlagt. Men det vil være dager eller uker senere, etter at det faktiske "feiltrinnet" skjedde. Siden det er så lenge siden, vil sporet være kaldt, og du vil ikke ha noen handlingsrettet innsikt i hvordan du kan nå målet ditt neste gang. Du har gått glipp av muligheten til å forbedre prosessen.

For å oppsummere: Målene skjuler ineffektivitet og læringsmuligheter, mens målforholdene bidrar til å tydeliggjøre hvor du bør forbedre deg.

Hvis du finner en liten løsning du kan implementere med en gang, trenger du sannsynligvis ikke den store, dyre løsningen i det hele tatt.

Hvordan bruke målbetingelser til å forbedre

Gå tilbake til eksemplet med morgenrutinen vår. Den første morgenen du begynner å måle, ser du at det tar 20 minutter å kle på seg. Nå må du gjøre en årsaksanalyse. Når du går i gang, oppdager du at det tar 10 minutter å plukke ut klærne. Du mister 10 minutter der. Så du kommer frem til to løsninger: 

1. Plukk ut klærne kvelden før.

2. Kjøp en Porsche 911 for å redusere reisetiden.

Begge høres ut som gode løsninger. De får deg på jobb i tide. Ikke sant? Nei, feil. La meg forklare: 

1. Hvis du sliter med å komme deg på jobb i tide, har du sikkert fått råd om å gjøre klærne klare dagen før. Men det er ikke en reell prosessforbedring. Det tar fortsatt 10 minutter å velge ut klær. Hvorfor ikke legge deg 10 minutter tidligere, stå opp 10 minutter tidligere og bruke de 10 minuttene det tar? En virkelig løsning ville være å redusere tidsbruken: Bruk den samme skjorten eller rullekragen, slik Mark Zuckerberg eller Steve Jobs gjorde. Eller bruk det samme settet med klær hver mandag, og hvis du vasker klærne, legg dem sammen i en bunke. Eller omorganiser garderoben din slik at du har matchende klær sammen i skuffene dine.

2. Løsningen å kjøpe bil er for stor. Du har ikke budsjett til det. Leveringstiden på bilen er et par uker. Hvis du finner en liten løsning som du kan implementere med en gang, trenger du sannsynligvis ikke den store, dyre løsningen i det hele tatt.

La oss se på noen eksempler fra Easy LMS

Hos Easy LMS etterstreber vi en enkel vareflyt.

Hos Easy LMS streber vi etter en flyt av enkeltelementer. Det betyr at vi ønsker at en brukerhistorie skal kunne flyte jevnt gjennom utviklingsprosessen vår uten å vente på at andre elementer skal bli klare. Da vi begynte å jobbe med denne målsetningen, fungerte det ikke problemfritt. Syklusen, det vil si tiden det tar fra vi starter arbeidet med en ny funksjon til den er klar til bruk, var 32 dager. Vi begynte å se på dataene om arbeidsprosessen vår for å finne ut hva vi kunne forbedre. Vi la merke til at historier ble sittende fast i påvente av en utgivelse. Utgivelsesprosessen var det første vi ønsket å forbedre.

Gjør to utgivelser i uken

Vi satte oss følgende utfordring: å få til én enkelt vareflyt i løpet av ett år. For å komme dit måtte vi sette opp ulike målbetingelser for å komme nærmere målet vårt;

Det første målet vi satte oss, var å gå fra én utgivelse annenhver eller hver tredje uke til to utgivelser i uken. Dette føltes nesten uoppnåelig;

1. Vi begynte å planlegge to utgivelser i uken, på tirsdag og torsdag, og bare se hva vi ville støte på underveis. Vi satte oss ned og beskrev stegene som trengtes for å gjøre releasen, og hvem som hadde ansvar for hva. 

2. Den aller første releasen gikk ikke som den skulle. Utvikleren som var ansvarlig for releasen, var syk den dagen. Resten av utviklerne ble satt på et annet prosjekt. Løsningen ble å automatisere og planlegge releasen slik at den ikke var avhengig av manuelle handlinger. Automatiseringen gjorde at releasen ble lagt på staging-serveren tidlig om morgenen tirsdag og torsdag, klar for akseptansetesten som skulle kjøres av Caroline (QA/QC).

3. Den neste flaskehalsen vi møtte på, var Caroline. Hun er ansvarlig for å ferdigstille utgivelsen, men den dagen var hun veldig opptatt med å administrere oversetterne for å få oversatt alt fra den forrige utgivelsen. Vi forbedret oversettelsesprosessen vår, noe som er en helt annen historie, slik at Caroline skulle få mer tid til å fokusere på testing. Jeg hører at du tenker: Hvorfor ikke ansette en ekstra tester? På den tiden hadde vi ikke budsjett til å ansette en ekstra tester. Å bruke mål føles som en plausibel løsning på problemet, men å ansette ekstra folk er ikke en reell prosessforbedring. 

Etter to måneder, og mange små forbedringer, klarte vi å komme opp i to utgivelser i uken;

For den neste målbetingelsen rettet vi oppmerksomheten mot ulike deler av utviklingsprosessen. Etter hvert som vi forbedret arbeidsprosessen vår, strømmet flere og flere historier gjennom utviklingsprosessen. Som et resultat av dette ble utgivelsene større. Større utgivelser tar mer tid. Noen ganger rakk vi ikke å bli ferdig med en release før neste release var klar. Dette førte til at vi ikke klarte å nå målet om to utgivelser i uken;

Hvordan vi gikk fra to til fire utgivelser i uken

For å løse dette problemet måtte utgivelsene bli mindre. Vi bestemte oss for å sette som neste mål at vi skulle gjøre en utgivelse når fire historier var klare til utgivelse. Dette resulterte i hyppigere, mindre utgivelser. Nylig hevet vi lista og senket antallet historier i en release til to. Vi er nesten nede på én enkelt distribusjon;

Å gå fra to utgivelser annenhver eller tredje uke til fire utgivelser i uken er et enormt fremskritt. For å komme dit har vi gjort mange små forbedringer, og et par større, som å automatisere nesten alle akseptansetester;

Syklustid

Som et resultat av disse målsetningene fikk vi ned syklustiden for en sak fra 32 dager til seks dager.

Underveis definerte og forbedret vi beskrivelsen av målbetingelsen, lærte mye og reduserte mye sløsing. Som et resultat av disse målbetingelsene reduserte vi syklustiden for en historie fra 32 dager til seks dager - med bedre kvalitet på koden, færre distraksjoner, nesten ingen feilrettinger og mer fornøyde medarbeidere.

Hva betyr dette for bedriftskulturen vår?

1. Vi sier alltid at det ikke er så farlig å mislykkes, så lenge man lærer noe. Hvis vi har en målsetning, vet vi faktisk når vi mislykkes og hva vi trenger å lære. Så det å mislykkes fører til læring.

2. Vi er ivrige etter å lære. Oppfylte vi alle målbetingelsene? Da har vi ikke lært nok, og vi bør sette et nytt, strengere og mer utfordrende mål, noe som gjør at vi kan mislykkes igjen. Dette gir oss kontinuerlig læring. 

3. Læring er den viktigste målbetingelsen for oss, for å være et vellykket og bærekraftig selskap. Å lære hvordan vi kan forbedre oss er det første trinnet i denne læringskurven. 

Nysgjerrig på vår spesielle arbeidskultur? Utforsk vår Working at Easy LMS-seksjon for å lære mer!

Gå til Working at Easy LMS