Om elke dag een beetje beter te worden. Zou dat niet geweldig zijn? Bij Easy LMS zijn we allemaal aanhangers van de Kaizen-methode. Deze Japanse productiviteitsmethode helpt ons om tijdverlies aan te pakken, om het werk leuker en lichter te maken. Het belangrijkste aspect is continu verbeteren;
Waarom Kaizen?
Grote verbeteringsprocessen. We hebben het geprobeerd, geloof me, maar nooit met het gewenste effect. Ze liepen vast, omdat we niet konden kiezen uit alle mogelijke verbeteringen en we ons verloren in de dagelijkse beslommeringen. Er kwam altijd wel een klantvraag tussendoor die urgenter was dan het opzetten van een heel proces.
Omdat we graag willen verbeteren, hebben we gekozen voor de Kaizen-methode. Na het lezen van het boek Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results van Mike Rother, waren we overtuigd van de effectiviteit. Kaizen focust immers niet op het feit dat alles in één keer perfect moet zijn, maar op het nemen van kleine stapjes elke dag. De kleine stapjes zijn inderdaad heel kleine stapjes. In totaal brengen deze stappen je ver. Uiteindelijk loop je ook stap voor stap een marathon.
De letterlijke vertaling van Kaizen is "verandering ten goede".
Overzicht van de Kaizen-methoden bij Easy LMS
Kaizen kent een breed scala aan methoden en processen, zowel groot als klein, om verbeteringen te realiseren. Kaizen bij Easy LMS is gebaseerd op de volgende onderdelen:
Richting bepalen met behulp van doelvoorwaarden.
Kleine, voortdurende verbeteringen.
Routeoorzaakanalyse: vijf keer vragen waarom.
Kennis is macht.
Kaizen is ieders verantwoordelijkheid.
Laten we ons richten op deel twee tot en met vijf, geïllustreerd met een voorbeeld van hoe we Kaizen uitvoeren. Deel één heeft een heel artikel nodig om uit te leggen ?.
Deel 2: Kleine voortdurende verbeteringen
Sommige verbeteringen lijken te klein en juist dan is het belangrijk om ze aan te brengen.
Hoe klein is klein? In ons geval heel klein. Het aanleren van sneltoetsen, of zelfs het verplaatsen van een printer naar een handigere locatie, is een verbetering. Kleine verbeteringen aanbrengen is daarom misschien wel de moeilijkste stap. Sommige verbeteringen lijken te futiel, te klein of te weinig impact te hebben. Daarom maak je ze vaak niet, en juist dan is het belangrijk om ze wel te maken. Het andere gevaar is dat hoe langer je wacht, hoe groter het probleem wordt, waardoor je het in de planning moet zetten, met alle gevaren van dien. Je kunt direct beginnen met het aanbrengen van kleine verbeteringen. Zelfs zonder goedkeuring van het management. Elke stap vooruit levert winst op.
We realiseerden ons dat toen we onze releasecyclus onder de loep namen. In het verleden maakten we eens in de paar weken nieuwe functionaliteit of losten we bugs online op ("releasen"). Nu doen we dit minstens twee keer per week, en zeer binnenkort zal het elke keer zijn als we iets hebben voltooid.
De weg hiernaartoe bestaat uit tientallen kleine (mini)stapjes. We willen er graag vier uitlichten:
Wij testen eerst alles voordat het live gaat. Om een release te testen, moesten ontwikkelaars deze eerst beschikbaar maken in onze testomgeving. Ontwikkelaars vergaten dit wel eens, of waren ziek. We zijn tenslotte ook maar mensen ?. Dit was voor ons reden genoeg om ervoor te zorgen dat onze tester, Caroline, de release zelf in de testomgeving kan zetten.
Het automatisch genereren van een release duurt 45 minuten, wat een vrij lange wachttijd is. Omdat dit zo lang duurt, doen we dit nu op vaste tijden: Maandag- en donderdagochtend om 6:00 uur. Als Caroline arriveert, kan ze meteen beginnen. Maar eerst natuurlijk een kopje koffie ?.
In het begin was een ontwikkelaar ook verplicht om een release live te zetten in de live omgeving. Dat is nu niet meer het geval. Caroline doet dit nu zelf. Live zetten kan alleen als alles is goedgekeurd.
We voeren altijd acceptatietesten uit en dat kost veel tijd. Vooral als het er 25 zijn, zoals bij ons het geval is. Daarom zijn we deze tests een voor een gaan automatiseren. De eerste test bespaarde ons al wat tijd. Nu zijn ze allemaal geautomatiseerd en dat scheelt ons 12 uur per week.
Deel 3: Analyse van de oorzaak, vijf keer vragen waarom
Als je Kaizen gebruikt, lap je niet zomaar dingen op.
Wanneer je Kaizen gebruikt, lap je niet zomaar dingen op. Je pakt de oorzaak van een probleem aan, zodat je het maar één keer hoeft op te lossen. Zo efficiënt. Je kunt de hoofdoorzaak van het probleem vinden door vijf keer "waarom" te vragen.
Elke keer dat we een bepaald doel niet halen, voeren we een oorzakenanalyse uit. Dit geeft ons een limiet van drie user stories die in ontwikkeling mogen zijn. Dit hebben we samen bepaald. Dit dwingt ons om stories in volgorde van prioriteit af te ronden. Als iemand een vierde story oppakt, stoppen we het werk en gaan we analyseren.
Onlangs moesten we iets live zetten terwijl er al drie verhalen in ontwikkeling waren. Iets live zetten, betekent verhaal nummer vier. We kwamen tot de volgende analyse:
Waarom hebben we een nieuw story geopend?
We moeten een release doen en voor de release is een story nodig waarin staat wat er moet gebeuren.
Waarom hebben we deze story nodig? We gaan verschillende nieuwe, aangevraagde functionaliteiten live zetten.
Waarom zetten we meerdere functionaliteiten live?
We zetten nooit slechts één functionaliteit live.
Waarom doen we dit niet?
Het maken van een release kost te veel tijd. De kosten wegen niet op tegen de baten.
Waarom kost het zoveel tijd?
Testen is de bottleneck.
Waarom is testen de bottleneck?De geautomatiseerde tests zijn niet betrouwbaar genoeg, dus er wordt veel handmatig getest.
Waarom zijn de geautomatiseerde tests onbetrouwbaar?
Omdat we een ouder framework gebruiken waarin we tests uitvoeren.
Er zijn meerdere oplossingen op verschillende niveaus om dit probleem op te lossen. Samen beslissen we wat op dit moment de beste oplossing is. De oplossing voor deze hoofdoorzaak is het updaten van het framework voor het uitvoeren van de tests.
Deel 4: Kennis is macht
Hoe weet je of een verandering succesvol is? Kennis is macht. Creëer een basislijn en meet deze na de aanpassing opnieuw. We proberen zoveel mogelijk dingen meetbaar te maken, maar soms is het ook een onderbuikgevoel dat iets sneller of beter kan. Nogmaals, we zijn ook maar mensen;
Een proces dat we volledig meetbaar hebben gemaakt is dat van een user story. Voordat een verhaal live kan gaan, doorloopt het een hele reeks stappen. Hoe lang duurden deze stappen? We hadden geen idee totdat we de tijd gingen meten. Toen was meteen duidelijk waar de bottleneck zat: het duurde te lang voordat Caroline kon testen. We hebben een oorzakenanalyse uitgevoerd en op basis daarvan meteen een verbetering doorgevoerd. Een andere verbetering die naar voren kwam: het proces voor het beheren van de vertalingen. Maar dat is iets voor een ander artikel.
Deel 5: Kaizen is ieders verantwoordelijkheid
Kaizen werkt alleen als iedereen in het bedrijf eraan bijdraagt door verantwoordelijkheid te nemen en er tijd en aandacht aan te besteden. Bij Easy LMS krijgt iedereen de ruimte om met verbeteringen te komen en de tijd om eraan te besteden. Omdat we weten dat we er op de lange termijn beter van worden.
Wil je, nu je dit artikel hebt gelezen, een stap zetten op weg naar Kaizen?
