Blijf kalm en wees trots. Dat is waar we hier bij Easy LMS naar streven. Dat klinkt mooi, maar hoe komen we daar? We managen op proces en niet op resultaat. We willen dat onze processen verbeteren, zodat we betere resultaten krijgen. Daarom gebruiken we doelvoorwaarden in plaats van streefdoelen. Hoewel ze hetzelfde klinken, zijn ze totaal verschillend. We zullen uitleggen waarom.
Doelvoorwaarden en doelen uitgelegd
Laten we beginnen met een echt voorbeeld (uit Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results) dat je waarschijnlijk wel herkent. Je wilt 's ochtends opstaan en binnen een uur aan je bureau zitten. Als dit je persoonlijke doel is en je komt te laat, dan moet je je haasten. Misschien rijd je te hard, sla je het ontbijt over of poets je je tanden niet. De bochten afsnijden om je doel te halen. Als je dit als een doeltoestand definieert, moet je het opdelen in substappen die je kunt meten. Als je niet binnen een uur op je werk bent, is dat geen probleem, omdat je weet welke deelstap je kunt verbeteren. Laten we de doelvoorwaarde dus opsplitsen in de volgende stappen:
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 |
Het resultaat (het doel) van dit proces is om op tijd op het werk te zijn, goed gevoed, aangekleed, gedoucht, met schone tanden en zonder opgejaagd te worden. Dat is in ieders belang.
Ok, maar hoe verschillen doelen van doelomstandigheden?
Een doelconditie is een beschrijving van de processen in je dagelijkse werk wanneer alles soepel verloopt.
Terug naar de theorie. We kennen allemaal het gevoel wanneer werk niet gaat zoals gepland. Dingen duren langer dan je dacht, of je komt onderweg hordes tegen. Er kan van alles misgaan. Een targetconditie is een beschrijving van de processen in je dagelijkse werk wanneer alles soepel verloopt. Een doeltoestand beschrijft hoe we zouden willen dat ons werkproces en al zijn subprocessen verlopen. Dit is de toekomstige toestand van een proces waar je naar streeft. De doeltoestand geeft ons een gevoel van richting voor onze verbeteringen. Hoe? We meten ons werkproces terwijl we werken. Telkens wanneer een proces niet werkt zoals gedefinieerd in de doeltoestand, moeten we dat onderzoeken. We noemen dat een 'hoofdoorzaakanalyse'. We proberen met een eenvoudige oplossing te komen. De implementatie hiervan brengt ons snel dichter bij de gewenste toestand.
Vergelijk dat met een doel. Een doel moet worden gehaald. Je moet alles doen wat in je macht ligt om het doel te bereiken, zoals in het routinevoorbeeld hierboven. Dat klinkt als heldhaftig, toch? Fout. Het is dom, vinden wij. Doelen leiden tot stress, overwerk en teleurstelling over gemiste doelen. Het creëert de mogelijkheid om te bezuinigen om je doel te halen. Dit schaadt de kwaliteit en de klanttevredenheid op de lange termijn;
Als je een doelstelling moet halen, zul je niet investeren in procesverbeteringen.
Bovendien, als je een doelstelling moet halen, zul je niet investeren in procesverbeteringen. Procesverbeteringen betalen zich pas na verloop van tijd uit. De tijd die je besteedt aan verbeteren zal je resultaten op korte termijn natuurlijk schaden. Als je uiteindelijk je doel bereikt of je deadline mist, kun je achteraf terugkijken op de dingen die niet volgens plan gingen. Maar dat zal dagen of weken later zijn, nadat de feitelijke 'misstap' plaatsvond. Omdat het zo lang geleden is, zal het spoor koud zijn en heb je geen bruikbare inzichten over hoe je de volgende keer je doel kunt halen. Je hebt de kans gemist om je proces te verbeteren.
Kortom: doelen verbergen je inefficiënties en leermogelijkheden, terwijl doelomstandigheden helpen om duidelijk te maken waar je moet verbeteren, je observeert en optimaliseert het proces in plaats van je te richten op het resultaat.
Als je een kleine oplossing vindt die je meteen kunt implementeren, heb je de grote dure oplossing waarschijnlijk helemaal niet nodig.
Hoe doelomstandigheden gebruiken om te verbeteren
Terug naar ons voorbeeld van de ochtendroutine. De eerste ochtend dat je begint te meten, zie je dat aankleden 20 minuten duurt. Nu moet je een hoofdoorzaakanalyse uitvoeren. Als je erin duikt, ontdek je dat het uitzoeken van je kleren 10 minuten kost. Daar verlies je dus 10 minuten. Dus kom je met twee oplossingen:
Pak je kleren de avond van tevoren al uit.
Koop een Porsche 911 om de reistijd te verkorten.
Beide klinken als goede oplossingen. Ze zorgen dat je op tijd op je werk bent. Toch? Nee, fout. Laat het me uitleggen:
Als je moeite hebt om op tijd op je werk te komen, heb je waarschijnlijk het advies gekregen om je kleren de dag ervoor al klaar te leggen. Maar dat is geen echte procesverbetering. Het uitzoeken van kleding kost nog steeds 10 minuten. Waarom ga je niet 10 minuten eerder naar bed, word je niet 10 minuten eerder wakker en besteed je die 10 minuten niet uit? Een echte oplossing zou zijn om de benodigde tijd te verminderen: draag hetzelfde shirt of coltrui zoals Mark Zuckerberg doet, of Steve Jobs. Of draag elke maandag hetzelfde stel kleren en als je de was doet, leg die kleren dan bij elkaar op een stapel. Of reorganiseer je kledingkast zodat je bij elkaar passende kleding in je lades hebt liggen.
De oplossing om een auto te kopen is te groot. Je hebt het budget niet. De levertijd van de auto is een paar weken. Als je een kleine oplossing vindt die je meteen kunt implementeren, heb je de grote dure oplossing waarschijnlijk helemaal niet nodig.
Laten we eens kijken naar enkele voorbeelden van Easy LMS
Bij Easy LMS streven we naar een single item flow.
Bij Easy LMS streven we naar een single item flow. Dit betekent dat we willen dat een user story soepel door ons ontwikkelproces kan stromen zonder ergens te wachten tot andere items klaar zijn. Toen we met deze doelvoorwaarde begonnen te werken, werkte het niet soepel. De cyclus, de tijd die verstrijkt tussen het begin van het werk aan een nieuwe functie en het online zetten ervan, was 32 dagen. We begonnen naar de gegevens over ons werkproces te kijken om te zien waar we konden verbeteren. Het viel ons op dat verhalen bleven hangen in afwachting van een release. Ons release proces was het eerste wat we wilden verbeteren.
Doe twee releases per week
We stelden ons de volgende uitdaging: binnen een jaar naar één itemstroom. Om dat te bereiken, moesten we verschillende doelcondities instellen om dichter bij ons doel te komen.
De eerste doelvoorwaarde die we stelden was om van één release per twee of drie weken naar twee releases per week te gaan. Dit voelde bijna onhaalbaar:
We begonnen twee releases per week te plannen, op dinsdag en donderdag, om te zien wat we onderweg tegenkwamen. We gingen zitten en beschreven de stappen die nodig waren om de release uit te voeren en wie waarvoor verantwoordelijk was.
De allereerste release verliep niet zoals gepland. De ontwikkelaar die verantwoordelijk was voor de release was die dag ziek. De rest van de ontwikkelaars was aan een ander project toegewezen. De oplossing was om de release te automatiseren en in te plannen, zodat deze niet afhankelijk was van handmatige acties. Door de automatisering werd de release op dinsdag en donderdag vroeg in de ochtend op de staging server gezet, klaar voor de acceptatietest die door Caroline (QA/QC) werd uitgevoerd.
Het volgende knelpunt dat we tegenkwamen was Caroline. Zij is verantwoordelijk voor het afronden van de release, maar die dag had ze het erg druk met het managen van de vertalers om alles vertaald te krijgen van de vorige release. We hebben ons vertaalproces verbeterd, wat een heel ander verhaal is, zodat Caroline meer tijd zou hebben om zich op het testen te richten. Ik hoor je denken: waarom huren we geen extra tester in? Op dat moment hadden we geen budget om een extra tester in te huren. Het gebruik van targets voelt als een plausibele oplossing voor het probleem, maar het inhuren van extra mensen is geen echte procesverbetering.
Na twee maanden en veel kleine verbeteringen zijn we erin geslaagd om twee releases per week uit te brengen.
Voor de volgende doelconditie richtten we onze aandacht op verschillende onderdelen van het ontwikkelproces. Naarmate we ons werkproces verbeterden, stroomden er steeds meer verhalen door het ontwikkelproces. Als gevolg daarvan werden de releases groter. Grotere releases kosten meer tijd. Soms konden we een release niet afmaken voordat de volgende release klaar was. Hierdoor misten we de doelvoorwaarde van twee releases per week.
Hoe we van twee naar vier releases per week gingen
Om dit probleem op te lossen, moesten releases kleiner worden. We besloten de volgende doelvoorwaarde te stellen op het doen van een release als er vier stories klaar waren voor release. Dit resulteerde in frequentere, kleinere releases. Onlangs hebben we de lat hoger gelegd en het aantal stories in een release verlaagd naar twee. We zitten nu bijna op een single item deploy.
Om van twee releases om de twee of drie weken naar vier releases per week te gaan is een enorme vooruitgang. Om dat te bereiken hebben we heel veel kleine verbeteringen doorgevoerd en een paar grotere, zoals het automatiseren van bijna alle acceptatietests.
Cyclustijd
Als gevolg van deze doelvoorwaarden hebben we de cyclustijd van een verhaal teruggebracht van 32 dagen naar zes dagen.
Onderweg definieerden en verbeterden we de beschrijving van de doelconditie, leerden we veel en verminderden we veel verspilling. Als gevolg van die doelvoorwaarden brachten we de cyclustijd van een story terug van 32 dagen naar zes dagen - met code van betere kwaliteit, minder afleiding, bijna geen hotfixes en tevredener mensen.
Wat betekent dit voor onze bedrijfscultuur?
We zeggen altijd dat falen niet erg is, zolang je er maar iets van leert. Als we een doel voor ogen hebben, weten we wanneer we falen en wat we moeten leren. Falen leidt dus tot leren.
We zijn fervente leerlingen. Hebben we aan alle doelvoorwaarden voldaan? Dan hebben we niet genoeg geleerd en moeten we een nieuwe, strengere, uitdagendere doelvoorwaarde stellen, waardoor we opnieuw falen. Hierdoor leren we voortdurend.
Leren is voor ons de belangrijkste doelvoorwaarde om een succesvol en duurzaam bedrijf te zijn. Leren verbeteren is de eerste stap van deze leercurve.
Benieuwd naar onze speciale werkcultuur? Verken onze Werken bij Easy LMS sectie voor meer informatie!
Ga naar werken bij Easy LMS
