Bevar roen og vær stolt. Det er det, vi stræber efter her på Easy LMS. Det lyder godt, men hvordan kommer vi derhen? Vi styrer efter processer og ikke efter resultater. Vi ønsker, at vores processer skal forbedres, så vi får bedre resultater. Det er derfor, vi bruger målbetingelser i stedet for mål. Selv om de lyder ens, er de helt forskellige. Vi forklarer hvorfor.
Målbetingelser og mål forklaret
Lad os starte med et virkeligt eksempel (fra Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results), som du sikkert kan genkende. Du vil gerne stå op om morgenen og være ved dit skrivebord inden for en time. Hvis det er dit personlige mål, og du kommer for sent, er du nødt til at skynde dig. Måske kører du for hurtigt, springer morgenmaden over eller børster ikke tænder. Skærer hjørner for at nå dit mål. Hvis du definerer dette som en måltilstand, skal du dele det op i delmål, som du kan måle. Hvis du ikke når på arbejde i løbet af en time, er det ikke noget problem, for du ved, hvilket delmål du kan forbedre. Så lad os bryde måltilstanden ned til følgende trin:
Get up and take a shower | 10 minutes |
Get dressed | 10 minutes |
Eat breakfast | 20 minutes |
Brush your teeth | 3 minutes |
Put on your shoes and coat | 2 minutes |
Ride your bike to work | 15 minutes |
Resultatet (målet) af denne proces er at komme på arbejde til tiden, velforsynet, påklædt, i bad, med rene tænder og uden at blive stresset. Det er i alles interesse ?
Ok, men hvordan adskiller mål sig fra målbetingelser?
En måltilstand er en beskrivelse af processerne i dit daglige arbejde, når alt kører som smurt.
Tilbage til noget teori. Vi kender alle følelsen af, at arbejdet ikke går som planlagt. Tingene tager længere tid, end man troede, eller man løber ind i forhindringer undervejs. Mange ting kan gå galt. En måltilstand er en beskrivelse af de processer i dit daglige arbejde, hvor alt går glat. En måltilstand beskriver, hvordan vi gerne vil have, at vores arbejdsproces og alle dens delprocesser skal være. Det er den fremtidige tilstand af en proces, som du sigter efter. Måltilstanden vil give os en fornemmelse af retning for vores forbedringer. Hvordan gør vi det? Vi måler vores arbejdsproces, mens vi arbejder. Hver gang en proces ikke fungerer som defineret i måltilstanden, er vi nødt til at se nærmere på det. Vi kalder det en 'root cause analysis'. Vi forsøger at finde en enkel løsning. Når vi implementerer den, kommer vi hurtigt tættere på den ønskede tilstand.
Sammenlign det med et mål. Et mål skal opfyldes. Du skal gøre alt, hvad der står i din magt, for at nå målet, som i rutineeksemplet ovenfor. Det lyder som en heroisk ting at gøre, ikke? Det er forkert. Det er dumt, efter vores mening. Målsætninger fører til stress, overarbejde og skuffelse over ikke at nå dem. Det skaber mulighed for at skære hjørner for at nå målet. Det skader kvaliteten og kundetilfredsheden i det lange løb;
Hvis du skal nå et mål, vil du ikke investere i procesforbedringer.
Desuden vil man ikke investere i procesforbedringer, hvis man skal opfylde et mål. Procesforbedringer betaler sig kun over tid. Tid brugt på forbedringer vil selvfølgelig skade dine kortsigtede resultater. Når du endelig når dit mål eller overskrider din deadline, kan du se tilbage på de ting, der ikke gik som planlagt. Men det vil være dage eller uger senere, efter at det faktiske "fejltrin" skete. Når det er så længe siden, er sporet koldt, og du har ingen brugbar indsigt i, hvordan du kan nå dit mål næste gang. Du er gået glip af muligheden for at forbedre din proces.
For at opsummere: Mål skjuler din ineffektivitet og dine læringsmuligheder, mens målbetingelser hjælper med at gøre det klart, hvor du skal forbedre dig, du observerer og optimerer processen i stedet for at fokusere på resultatet.
Hvis du finder en lille løsning, som du kan implementere med det samme, har du sandsynligvis slet ikke brug for den store, dyre løsning.
Hvordan man bruger målbetingelser til at forbedre sig
Gå tilbage til vores eksempel med morgenrutinen. Den første morgen, du begynder at måle, ser du, at det tager 20 minutter at komme i tøjet. Nu skal du lave en årsagsanalyse. Når du dykker ned i den, opdager du, at det tager 10 minutter at finde tøjet frem. Du mister 10 minutter der. Så du finder frem til to løsninger:
Hent dit tøj aftenen før.
Køb en Porsche 911 for at reducere rejsetiden.
Begge dele lyder som gode løsninger. De får dig på arbejde til tiden. Er det rigtigt? Nej, det er forkert. Lad mig forklare:
Hvis du kæmper med at komme på arbejde til tiden, er du sikkert blevet rådet til at gøre dit tøj klar dagen før. Men det er ikke en reel procesforbedring. Det tager stadig 10 minutter at vælge tøj. Hvorfor ikke gå i seng 10 minutter tidligere, vågne 10 minutter tidligere og bruge de 10 minutter, det tager? En rigtig løsning ville være at reducere tidsforbruget: Tag den samme skjorte eller rullekrave på, som Mark Zuckerberg gør, eller som Steve Jobs gjorde. Eller tag det samme sæt tøj på hver mandag, og hvis du vasker tøj, så læg tøjet sammen i en bunke. Eller omorganiser din garderobe, så du har matchende tøj i dine skuffer.
Løsningen med at købe en bil er for stor. Du har ikke budgettet. Leveringstiden for bilen er et par uger. Hvis du finder en lille løsning, som du kan implementere med det samme, har du sandsynligvis slet ikke brug for den store, dyre løsning.
Lad os se på nogle eksempler fra Easy LMS
Hos Easy LMS stræber vi efter et enkelt element-flow.
Hos Easy LMS stræber vi efter et enkelt element-flow. Det betyder, at vi ønsker, at en brugerhistorie skal kunne flyde gnidningsløst gennem vores udviklingsproces uden at vente på, at andre elementer bliver klar. Da vi begyndte at arbejde med dette mål, fungerede det ikke problemfrit. Cyklussen, dvs. den tid, det tager, fra vi begynder at arbejde på en ny funktion, til den er online, var 32 dage. Vi begyndte at se på data om vores arbejdsproces for at finde ud af, hvor vi kunne forbedre os. Vi lagde mærke til, at historier blev hængende og ventede på en udgivelse. Vores udgivelsesproces var den første ting, vi ville forbedre.
Lav to udgivelser om ugen
Vi satte os følgende udfordring: at nå frem til et enkelt vareflow inden for et år. For at nå dertil skulle vi opstille forskellige målbetingelser for at bringe os tættere på vores mål;
Det første mål, vi satte os, var at gå fra en udgivelse hver anden eller tredje uge til to udgivelser om ugen. Det føltes næsten uopnåeligt:
Vi begyndte at planlægge to udgivelser om ugen, tirsdag og torsdag, og bare se, hvad vi ville støde på undervejs. Vi satte os ned og beskrev de trin, der var nødvendige for at lave udgivelsen, og hvem der var ansvarlig for hvad.
Den allerførste udgivelse gik ikke, som den skulle. Den udvikler, der var ansvarlig for udgivelsen, var syg den dag. Resten af udviklerne var sat på et andet projekt. Løsningen var at automatisere og planlægge udgivelsen, så den ikke var afhængig af manuelle handlinger. Automatiseringen lagde releasen på staging-serveren tidligt om morgenen tirsdag og torsdag, så den var klar til, at Caroline (QA/QC) kunne køre accepttesten.
Den næste flaskehals, vi stødte på, var Caroline. Hun er ansvarlig for at færdiggøre udgivelsen, men den dag havde hun virkelig travlt med at styre oversætterne for at få alt oversat fra den forrige udgivelse. Vi forbedrede vores oversættelsesproces, hvilket er en helt anden historie, så Caroline kunne få mere tid til at fokusere på test. Jeg hører dig tænke, hvorfor ikke ansætte en ekstra tester? På det tidspunkt havde vi ikke budget til at ansætte en ekstra tester. Det føles som en plausibel løsning på problemet at bruge mål, men at ansætte ekstra folk er ikke en reel procesforbedring.
Efter to måneder og en masse små forbedringer lykkedes det os at komme op på to udgivelser om ugen;
For den næste måltilstand rettede vi opmærksomheden mod forskellige dele af udviklingsprocessen. Efterhånden som vi blev ved med at forbedre vores arbejdsproces, kom der flere og flere historier igennem udviklingsprocessen. Som følge heraf blev udgivelserne større. Større udgivelser tager mere tid. Nogle gange kunne vi ikke nå at færdiggøre en release, før den næste var klar. Det gjorde, at vi ikke nåede målet om to udgivelser om ugen;
Hvordan vi gik fra to til fire udgivelser om ugen
For at løse dette problem måtte udgivelserne blive mindre. Vi besluttede at sætte det næste mål om at lave en udgivelse, når fire historier var klar til at blive udgivet. Det resulterede i hyppigere, mindre udgivelser. For nylig hævede vi barren og sænkede antallet af historier i en release til to. Vi er næsten nede på at implementere et enkelt element;
At gå fra to udgivelser hver anden eller tredje uge til fire udgivelser om ugen er et kæmpe fremskridt. For at nå dertil lavede vi en masse små forbedringer og et par større, som f.eks. at automatisere næsten alle accepttest;
Cyklustid
Som et resultat af disse målbetingelser bragte vi cyklustiden for en historie ned fra 32 dage til seks dage.
Undervejs definerede og forbedrede vi beskrivelsen af målbetingelserne, lærte en masse og reducerede en masse spild. Som et resultat af disse målbetingelser bragte vi cyklustiden for en historie ned fra 32 dage til seks dage - med kode af bedre kvalitet, færre forstyrrelser, næsten ingen hotfixes og gladere mennesker.
Hvad betyder det for vores virksomhedskultur?
Vi siger altid, at det ikke er en dårlig ting at fejle, så længe man lærer noget. Hvis vi har et mål på plads, ved vi faktisk, hvornår vi fejler, og hvad vi har brug for at lære. Så fiasko fører til læring.
Vi er ivrige elever. Opfyldte vi alle målbetingelser? Så har vi ikke lært nok, og vi bør opstille et nyt, strengere og mere udfordrende målkrav, som sætter os i stand til at fejle igen. Det giver os kontinuerlig læring.
Læring er den vigtigste forudsætning for, at vi kan være en succesfuld og bæredygtig virksomhed. At lære at forbedre sig er det første skridt på denne læringskurve.
Nysgerrig på vores særlige arbejdskultur? Udforsk vores Working at Easy LMS-sektion for at lære mere!
Gå til at arbejde hos Easy LMS
