Å bli litt bedre hver dag. Ville ikke det vært flott? Hos Easy LMS er vi alle tilhengere av Kaizen-metoden. Denne japanske produktivitetsmetoden hjelper oss med å takle tidssløsing, slik at arbeidet blir hyggeligere og lettere. Det viktigste aspektet er kontinuerlig forbedring;
Hvorfor Kaizen?
Store forbedringsprosesser. Vi har prøvd, tro meg, men aldri med ønsket effekt. De stoppet opp fordi vi ikke kunne velge blant alle de mulige forbedringene, og vi fortapte oss i de daglige problemene. Det var alltid et kundespørsmål som dukket opp innimellom, og som var mer presserende enn å sette i gang en hel prosess;
Siden vi virkelig liker å forbedre oss, har vi valgt Kaizen-metoden. Etter å ha lest boken Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results av Mike Rother, ble vi overbevist om dens effektivitet. Kaizen fokuserer tross alt ikke på at alt skal være perfekt på én gang, men på å ta små skritt hver dag. De små skrittene er faktisk veldig små skritt. Totalt sett vil disse skrittene ta deg langt. Til syvende og sist løper du også et maraton steg for steg;
Den bokstavelige oversettelsen av Kaizen er "endring til det bedre".
Oversikt over Kaizen-metodene hos Easy LMS
Kaizen har et bredt spekter av metoder og prosesser, både store og små, for å realisere forbedringer. Kaizen hos Easy LMS er basert på følgende deler:
Bestem retning ved hjelp av målbetingelser.
Små, kontinuerlige forbedringer.
Rotårsaksanalyse: spør hvorfor fem ganger.
Kunnskap er makt.
Kaizen er alles ansvar.
La oss fokusere på del to til fem, illustrert med et eksempel på hvordan vi gjennomfører Kaizen. Del én trenger en hel artikkel for å forklare ?.
Del 2: Små, kontinuerlige forbedringer
Noen forbedringer synes å være for små, og nettopp da er det viktig å gjøre dem.
Hvor liten er liten? I vårt tilfelle er det veldig lite. Å lære seg snarveier, eller til og med å flytte en skriver til et mer praktisk sted, er en forbedring. Å gjøre små forbedringer er derfor kanskje det vanskeligste steget. Noen forbedringer virker for meningsløse, for små eller har for liten effekt. Derfor lar man ofte være å gjøre dem, og nettopp da er det viktig å gjøre dem. Den andre faren er at jo lenger du venter, desto større blir problemet, noe som betyr at du må legge det inn i planleggingen, med alle de farene det innebærer. Du kan begynne umiddelbart med å gjøre små forbedringer. Selv uten godkjenning fra ledelsen. Hvert skritt fremover genererer fortjeneste;
Det innså vi da vi tok en nærmere titt på lanseringssyklusen vår. Tidligere skapte vi ny funksjonalitet eller løste feil på nettet ("releaset") med noen ukers mellomrom. Nå gjør vi dette minst to ganger i uken, og snart blir det hver gang vi har fullført noe;
Veien til dette består av dusinvis av små (mini)skritt. Vi vil gjerne trekke frem fire av dem:
Vi tester først alt før det går live. For å teste en utgivelse måtte utviklerne først gjøre den tilgjengelig i testmiljøet vårt. Noen ganger glemte utviklerne dette, eller var syke. Vi er tross alt bare mennesker. Dette ga oss god grunn til å sørge for at testeren vår, Caroline, selv kan legge releasen i testmiljøet.
Automatisk generering av en release tar 45 minutter, noe som er en ganske lang ventetid. Fordi dette tar så lang tid, gjør vi det nå på faste tidspunkter: Mandag og torsdag morgen kl. 06.00. Når Caroline kommer, kan hun begynne med en gang. Men først en kopp kaffe, selvfølgelig.
Til å begynne med var det også et krav at en utvikler skulle sette en release live i live-miljøet. Slik er det ikke lenger. Nå gjør Caroline dette selv. Det er bare mulig å sette den live hvis alt er godkjent.
Vi gjennomfører alltid akseptansetester, og det tar mye tid. Spesielt hvis det er 25, slik tilfellet er hos oss. Derfor begynte vi å automatisere disse testene én og én. Den første testen sparte oss litt tid. Nå er alle automatisert, og det sparer oss for 12 timer i uken.
Del 3: Årsaksanalyse, spør hvorfor fem ganger
Når du bruker Kaizen, lapper du ikke bare på ting.
Når du bruker Kaizen, lapper du ikke bare på ting. Du tar tak i årsaken til et problem, slik at du bare trenger å løse det én gang. Alltid like effektivt. Du kan finne årsaken til problemet ved å spørre "hvorfor" fem ganger;
Hver gang vi ikke når et bestemt mål, utfører vi en rotårsaksanalyse. Dette gir oss en grense på tre brukerhistorier som kan være under utvikling. Dette har vi bestemt sammen. Dette tvinger oss til å fullføre historiene i prioritert rekkefølge. Hvis noen tar opp en fjerde historie, stopper vi arbeidet og begynner å analysere.
Nylig måtte vi sette noe i produksjon mens tre historier allerede var under utvikling. Å sette noe live betyr historie nummer fire. Vi kom frem til følgende analyse:
Hvorfor har vi åpnet en ny historie?
Vi må gjøre en utgivelse, og utgivelsen krever en historie som sier hva som må gjøres.
Hvorfor trenger vi denne historien?
Vi skal ta i bruk flere nye, etterspurte funksjonaliteter.
Hvorfor skal vi ta flere funksjoner i bruk?
Vi tar aldri bare én funksjonalitet i bruk.
Hvorfor gjør vi ikke dette?
Det tar for mye tid å lage en release. Kostnadene er større enn fordelene.
Hvorfor tar det så lang tid?
Testing er flaskehalsen.
Hvorfor er testing flaskehalsen?
De automatiserte testene er ikke pålitelige nok, så det blir mye manuell testing.
Hvorfor er de automatiserte testene upålitelige?
Fordi vi bruker et eldre rammeverk som vi kjører tester i.
Det finnes flere løsninger på ulike nivåer for å løse dette problemet. Sammen bestemmer vi hva som er den beste løsningen for øyeblikket. Løsningen på dette problemet er å oppdatere rammeverket for kjøring av testene;
Del 4: Kunnskap er makt
Hvordan vet du om en endring har vært vellykket? Kunnskap er makt. Lag en baseline, og mål den igjen etter justeringen. Vi prøver å gjøre så mye som mulig målbart, men noen ganger er det også en magefølelse som sier at noe kan gjøres raskere eller bedre. Igjen, vi er bare mennesker;
En prosess som vi har gjort fullt ut målbar, er brukerhistorier. Før en historie kan gå live, går den gjennom en hel rekke trinn. Hvor lang tid tok disse stegene? Det ante vi ikke før vi begynte å måle tiden. Da ble det umiddelbart klart hvor flaskehalsen var: Det tok for lang tid før Caroline kunne teste. Vi gjennomførte en rotårsaksanalyse og iverksatte umiddelbart en forbedring basert på denne. En annen forbedring som kom frem, var prosessen for håndtering av oversettelsene. Men det er noe for en annen artikkel;
Del 5: Kaizen er alles ansvar
Kaizen fungerer bare hvis alle i bedriften bidrar til det ved å ta ansvar og bruke tid og oppmerksomhet på det. Hos Easy LMS får alle rom til å komme med forslag til forbedringer og tid til å bruke på dem. Fordi vi vet at vi vil tjene på det på lang sikt;
Nå som du har lest denne artikkelen, har du lyst til å ta et skritt på veien mot Kaizen?
