Behåll lugnet och var stolt. Det är vad vi strävar efter här på Easy LMS. Det låter bra, men hur kommer vi dit? Vi styr genom processer och inte genom resultat. Vi vill att våra processer ska förbättras, så att vi får bättre resultat. Det är därför vi använder målvillkor istället för mål. Även om de låter likadant är de helt olika. Vi ska förklara varför.
Målvillkor och mål förklarade
Låt oss börja med ett verkligt exempel (från Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results) som du säkert känner igen. Du vill gå upp på morgonen och vara vid ditt skrivbord inom en timme. Om detta är ditt personliga mål och du är försenad måste du skynda dig. Du kanske kör för fort, hoppar över frukosten eller borstar inte tänderna. Du tar genvägar för att nå ditt mål. Om du definierar detta som ett måltillstånd måste du dela upp det i delsteg som du kan mäta. Om du inte hinner till jobbet på en timme är det inget problem, eftersom du vet vilket delsteg du kan förbättra. Så låt oss bryta ner målvillkoret till följande steg:
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) av denna process är att komma till jobbet i tid, välmatad, välklädd, välduschad, med rena tänder och utan att bli stressad. Det ligger i allas intresse ?
Ok, men hur skiljer sig mål från målförhållanden?
Ett måltillstånd är en beskrivning av processerna i ditt dagliga arbete när allt går som smort.
Tillbaka till lite teori. Vi känner alla till känslan när arbetet inte går som planerat. Saker tar längre tid än man tänkt sig, eller så stöter man på hinder längs vägen. Många saker kan gå fel. Ett måltillstånd är en beskrivning av de processer i ditt dagliga arbete när allt går som smort. Ett måltillstånd beskriver hur vi vill att vår arbetsprocess och alla dess delprocesser ska vara. Det är det framtida tillståndet för en process som du siktar på. Måltillståndet kommer att ge oss en riktning för våra förbättringar. Hur gör vi? Vi mäter vår arbetsprocess medan vi arbetar. Varje gång en process inte fungerar enligt definitionen i måltillståndet måste vi undersöka det. Vi kallar det för en "grundorsaksanalys". Vi försöker komma fram till en enkel lösning. Genom att snabbt implementera denna kommer vi närmare vårt önskade tillstånd.
Jämför det med ett mål. Ett mål ska uppfyllas. Du måste göra allt som står i din makt för att nå målet, som i rutinexemplet ovan. Det låter som en heroisk sak att göra, eller hur? Det är fel. Det är dumt, enligt vår åsikt. Målsättningar leder till stress, övertid och besvikelse över missade mål. Det skapar en möjlighet att ta genvägar för att nå målet. Detta skadar kvaliteten och kundnöjdheten i det långa loppet.
Om du måste uppnå ett mål kommer du inte att investera i processförbättringar.
Dessutom, om du måste uppfylla ett mål kommer du inte att investera i processförbättringar. Processförbättringar betalar sig bara över tiden. Tid som läggs på att förbättra kommer naturligtvis att skada dina kortsiktiga resultat. När du äntligen når ditt mål eller missar din deadline kan du i efterhand se tillbaka på de saker som inte gick som planerat. Men det kommer att ske dagar eller veckor senare, efter att det faktiska "felsteget" inträffade. Eftersom det är så länge sedan kommer spåret att vara kallt och du kommer inte att ha några handlingsbara insikter om hur du kan nå ditt mål nästa gång. Du har missat möjligheten att förbättra din process.
För att sammanfatta: mål döljer ineffektivitet och möjligheter till lärande, medan målförhållanden hjälper till att klargöra var du bör förbättra dig, du observerar och optimerar processen istället för att fokusera på resultatet.
Om du hittar en liten lösning som du kan implementera direkt, behöver du förmodligen inte den stora dyra lösningen alls.
Hur man använder målförhållanden för att förbättra
Återgå till vårt exempel med morgonrutinen. Den första morgonen du börjar mäta ser du att det tar 20 minuter att klä på sig. Nu måste du göra en analys av grundorsaken. När du dyker in upptäcker du att det tar 10 minuter att plocka fram dina kläder. Du förlorar 10 minuter där. Så du kommer fram till två lösningar:
Plocka ut dina kläder kvällen innan.
Köp en Porsche 911 för att minska restiden.
Båda låter som bra lösningar. De får dig att komma i tid till jobbet. Eller hur? Nix, fel. Låt mig förklara:
Om du kämpar med att komma till jobbet i tid har du förmodligen fått rådet att göra dina kläder redo dagen innan. Men det är inte en verklig processförbättring. Att plocka ut kläder tar fortfarande 10 minuter. Varför inte gå och lägga sig 10 minuter tidigare, vakna 10 minuter tidigare och spendera de 10 minuter det tar? En riktig lösning skulle vara att minska tidsåtgången: använd samma skjorta eller polotröja som Mark Zuckerberg eller Steve Jobs gjorde. Eller ha samma uppsättning kläder varje måndag, och om du tvättar, lägg dessa kläder tillsammans i en hög. Eller omorganisera din garderob så att du har matchande kläder som går ihop i dina lådor.
Lösningen att köpa en bil är för stor. Du har inte budgeten. Leveranstiden för bilen är ett par veckor. Om du hittar en liten lösning som du kan implementera direkt, behöver du förmodligen inte den stora dyra lösningen alls.
Låt oss titta på några exempel från Easy LMS
På Easy LMS strävar vi efter ett flöde med ett enda objekt.
På Easy LMS strävar vi efter ett flöde med ett enda objekt. Det betyder att vi vill att en användarberättelse ska kunna flöda smidigt genom vår utvecklingsprocess utan att vänta någonstans på att andra objekt ska bli klara. När vi började arbeta med det här målvillkoret fungerade det inte smidigt. Cykeln, dvs. den tid det tar från det att vi börjar arbeta med en ny funktion till dess att den finns online, var 32 dagar. Vi började titta på data om vår arbetsprocess för att ta reda på vad vi kunde förbättra. Vi märkte att berättelser fastnade i väntan på en release. Vår releaseprocess var det första vi ville förbättra.
Gör två releaser i veckan
Vi satte upp följande utmaning: att nå ett enda artikelflöde inom ett år. För att nå dit skulle vi behöva sätta upp olika målvillkor för att ta oss närmare vårt mål.
Det första målet vi satte upp var att gå från en release varannan eller var tredje vecka till två releaser i veckan. Detta kändes nästan ouppnåeligt:
Vi började planera två releaser i veckan, på tisdag och torsdag, och bara se vad vi skulle stöta på längs vägen. Vi satte oss ner och beskrev de steg som behövdes för att göra releasen och vem som var ansvarig för vad.
Den allra första releasen gick inte som den skulle. Den utvecklare som var ansvarig för releasen var sjuk den dagen. Resten av utvecklarna var tilldelade ett annat projekt. Lösningen var att automatisera och schemalägga releasen så att den inte var beroende av manuella åtgärder. Automatiseringen placerade releasen på staging-servern tidigt på morgonen på tisdag och torsdag, redo för acceptanstestet som skulle köras av Caroline (QA / QC).
Nästa flaskhals vi stötte på var Caroline. Hon är ansvarig för att slutföra releasen, men den dagen var hon väldigt upptagen med att hantera översättarna för att få allt översatt från den tidigare releasen. Vi förbättrade vår översättningsprocess, vilket är en helt annan historia, så att Caroline skulle få mer tid att fokusera på testning. Jag hör att du tänker, varför inte anställa en extra testare? På den tiden hade vi inte budget för att anställa en extra testare. Att använda mål känns som en rimlig lösning på problemet, men att anställa extra personer är inte en verklig processförbättring.
Efter två månader, och många små förbättringar, lyckades vi komma upp i två releaser i veckan;
För nästa målvillkor riktade vi uppmärksamheten mot olika delar av utvecklingsprocessen. När vi fortsatte att förbättra vår arbetsprocess flöt fler och fler berättelser genom utvecklingsprocessen. Som ett resultat av detta blev releaserna större. Större releaser tar mer tid. Ibland kunde vi inte slutföra en release innan nästa release var klar. Detta gjorde att vi missade målet om två releaser i veckan;
Hur vi gick från två till fyra releaser i veckan
För att lösa detta problem måste releaserna bli mindre. Vi bestämde oss för att sätta nästa målvillkor på att göra en release när fyra stories var redo att släppas. Detta resulterade i mer frekventa, mindre releaser. Nyligen höjde vi ribban och sänkte antalet berättelser i en release till två. Vi är nästan framme vid en deploy av ett enda objekt;
Att gå från två releaser varannan eller var tredje vecka till fyra releaser i veckan är ett enormt framsteg. För att komma dit gjorde vi massor av små förbättringar, och ett par större, som att automatisera nästan alla acceptanstester.
Cykeltid
Som ett resultat av dessa målvillkor fick vi ner cykeltiden för en story från 32 dagar till sex dagar.
Längs vägen definierade och förbättrade vi beskrivningen av målvillkoren, lärde oss mycket och minskade en hel del slöseri. Som ett resultat av dessa målvillkor fick vi ner cykeltiden för en story från 32 dagar till sex dagar - med kod av bättre kvalitet, färre distraktioner, nästan inga hotfixes och nöjdare medarbetare.
Vad innebär detta för vår företagskultur?
Vi säger alltid att misslyckande inte är något dåligt, så länge du lär dig något. Om vi har ett målvillkor på plats vet vi faktiskt när vi misslyckas och vad vi behöver lära oss. Så misslyckande leder till lärande.
Vi är ivriga elever. Uppfyllde vi alla målvillkor? Då har vi inte lärt oss tillräckligt och vi bör ställa in ett nytt, strängare, mer utmanande målvillkor som sätter oss upp för misslyckande igen. Detta ger oss kontinuerligt lärande.
Lärande är det viktigaste målvillkoret för oss, för att vara ett framgångsrikt och hållbart företag. Att lära sig att förbättra är det första steget i denna inlärningskurva.
Nyfiken på vår speciella arbetskultur? Utforska vår Working at Easy LMS-sektion för att lära dig mer!
Gå till Att arbeta på Easy LMS
