Att bli lite bättre varje dag. Skulle inte det vara fantastiskt? På Easy LMS är vi alla anhängare av Kaizen-metoden. Denna japanska produktivitetsmetod hjälper oss att ta itu med tidsspillan, för att göra arbetet trevligare och lättare. Dess nyckelaspekt är kontinuerlig förbättring.
Varför Kaizen?
Stora förbättringsprocesser. Vi har försökt, tro mig, men aldrig med önskad effekt. De stannade upp, eftersom vi inte kunde välja bland alla möjliga förbättringar och vi förlorade oss i de dagliga frågorna. Det var alltid en kundfråga som dök upp däremellan, som var mer angelägen än att sätta upp en hel process;
Eftersom vi verkligen gillar att förbättra oss har vi valt Kaizen-metoden. Efter att ha läst boken Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results av Mike Rother blev vi övertygade om dess effektivitet. Kaizen fokuserar trots allt inte på att allt ska bli perfekt på en gång, utan på att ta små steg varje dag. De små stegen är verkligen mycket små steg. Totalt sett kommer dessa steg att ta dig långt. I slutändan springer du också ett maraton steg för steg.
Den bokstavliga översättningen av Kaizen är "förändring till det bättre".
Översikt över Kaizen-metoderna på Easy LMS
Kaizen har ett brett spektrum av metoder och processer, både stora och små, för att förverkliga förbättringar. Kaizen på Easy LMS är baserat på följande delar:
Bestäm riktning genom att använda målförhållanden.
Små kontinuerliga förbättringar.
Rotorsaksanalys: fråga varför fem gånger.
Kunskap är makt.
Kaizen är allas ansvar.
Låt oss fokusera på delarna två till fem, illustrerade med ett exempel på hur vi genomför Kaizen. Del ett behöver en hel artikel för att förklara ?.
Del 2: Små kontinuerliga förbättringar
Vissa förbättringar verkar vara för små och just då är det viktigt att göra dem.
Hur liten är liten? I vårt fall är det mycket litet. Att lära sig genvägar, eller till och med flytta en skrivare till en mer praktisk plats, är en förbättring. Att göra små förbättringar är därför kanske det svåraste steget. Vissa förbättringar verkar vara för meningslösa, för små eller ha för liten inverkan. Därför låter man ofta bli att göra dem, och just då är det viktigt att göra dem. Den andra faran är att ju längre du väntar, desto större blir problemet, vilket innebär att du måste lägga det i planeringen, med alla de faror som är förknippade med det. Du kan börja direkt med att göra små förbättringar. Även utan godkännande från ledningen. Varje steg framåt genererar vinst.
Det insåg vi när vi tittade närmare på vår releasecykel. Tidigare skapade vi ny funktionalitet eller löste buggar online ("releasing") en gång varannan vecka. Nu gör vi det minst två gånger i veckan, och mycket snart kommer det att vara varje gång vi har slutfört något.
Vägen till detta består av dussintals små (mini) steg. Vi skulle vilja lyfta fram fyra:
Vi testar först allt innan det går live. För att testa en release var utvecklarna först tvungna att göra den tillgänglig i vår testmiljö. Utvecklare glömde ibland detta eller var sjuka. När allt kommer omkring är vi bara mänskliga ?. Detta gav oss en god anledning att se till att vår testare Caroline själv kan lägga upp releasen i testmiljön.
Automatisk generering av en release tar 45 minuter, vilket är en ganska lång tid att vänta. Eftersom det tar så lång tid gör vi det nu på bestämda tider: Måndag och torsdag morgon kl. 06.00. När Caroline kommer kan hon börja direkt. Men först, naturligtvis, en kopp kaffe ?.
Initialt var en utvecklare också skyldig att sätta en release live i live-miljön. Så är det inte längre. Caroline gör det nu själv. Att sätta den live är bara möjligt om allt har godkänts.
Vi genomför alltid acceptanstester och det tar mycket tid. Speciellt om det är 25 stycken, vilket är fallet hos oss. Därför började vi automatisera dessa tester en efter en. Det första testet sparade oss lite tid. Nu är de alla automatiserade och det sparar oss 12 timmar i veckan.
Del 3: Grundorsaksanalys, att fråga varför fem gånger
När du använder Kaizen lappar du inte bara ihop saker och ting.
När du använder Kaizen lappar du inte bara ihop saker och ting. Man tar itu med grundorsaken till ett problem, så att man bara behöver lösa det en gång. Alltid lika effektivt. Du kan hitta grundorsaken till problemet genom att fråga "varför" fem gånger;
Varje gång vi inte når ett visst mål gör vi en analys av grundorsaken. Detta ger oss en gräns på tre användarberättelser som kan vara under utveckling. Vi har bestämt detta tillsammans. Detta tvingar oss att slutföra berättelserna i prioritetsordning. Om någon plockar upp en fjärde berättelse stoppar vi arbetet och börjar analysera.
Nyligen var vi tvungna att sätta något i drift medan tre berättelser redan höll på att utvecklas. Att sätta något live innebär story nummer fyra. Vi kom fram till följande analys:
Varför har vi öppnat en ny story?
Vi måste göra en release och releasen kräver en story som anger vad som måste göras.
Varför behöver vi den här storyn?
Vi ska ta flera nya, efterfrågade funktioner i drift.
Varför ska vi ta flera funktioner i drift?
Vi tar aldrig bara en funktion i drift.
Varför gör vi inte det här?
Att skapa en release tar för mycket tid. Kostnaderna överväger fördelarna.
Varför tar det så lång tid?
Testning är flaskhalsen.
Varför är testning flaskhalsen?
De automatiserade testerna är inte tillräckligt tillförlitliga, så det blir mycket manuell testning.
Varför är de automatiserade testerna otillförlitliga?
För att vi använder ett äldre ramverk som vi kör tester i.
Det finns flera olika lösningar på olika nivåer för att lösa detta problem. Tillsammans bestämmer vi vad som är den bästa lösningen för tillfället. Lösningen för denna grundorsak är att uppdatera ramverket för att köra testerna;
Del 4: Kunskap är makt
Hur vet du om en förändring har varit framgångsrik? Kunskap är makt. Skapa en baslinje och mät den sedan igen efter justeringen. Vi försöker göra så många saker mätbara som möjligt, men ibland är det också en magkänsla som säger att något kan göras snabbare eller bättre. Återigen, vi är bara människor;
En process som vi har gjort helt mätbar är den för en användarberättelse. Innan en berättelse kan gå live går den igenom en hel rad steg. Hur lång tid tog de här stegen? Det hade vi ingen aning om förrän vi började mäta tiden. Då stod det genast klart var flaskhalsen fanns: det tog för lång tid innan Caroline kunde testa. Vi genomförde en grundorsaksanalys och implementerade omedelbart en förbättring baserad på denna. En annan förbättring som kom fram var processen för att hantera översättningarna. Men det är något för en annan artikel.
Del 5: Kaizen är allas ansvar
Kaizen fungerar bara om alla i företaget bidrar till det genom att ta ansvar och ge tid och uppmärksamhet åt det. På Easy LMS får alla utrymme att komma med förbättringsförslag och tid att ägna sig åt dem. För vi vet att det kommer att gynna oss på lång sikt.
Nu när du har läst den här artikeln, skulle du vilja ta ett steg på vägen mot Kaizen?
