Hoe spreek je Verbetering Kata

We beoefenen het Improvement Kata nu al een tijdje, maar we worstelen nog steeds met de betekenis van de verschillende termen, en hoe ze toe te passen. Na het lezen van dit artikel zou je een duidelijk beeld moeten hebben van de onderdelen van het Improvement Kata, wat ze betekenen en hoe ze toe te passen. 

Laten we beginnen!

Proces vs. resultaat

Voordat we in de details van de Improvement Kata taal kunnen duiken, moeten we beginnen met een onderscheid te maken tussen het proces en het resultaat. Dit is misschien wel het moeilijkste deel van het Improvement Kata. We zijn gewend om te denken over doelen en resultaten en wat we willen bereiken. We willen onze productiecijfers halen. We zijn gericht op het resultaat. Met het Improvement Kata richten we ons op het proces dat leidt tot een resultaat. We moeten het proces in de schijnwerpers zetten en het resultaat is het resultaat van het proces. Ik probeer het altijd op deze manier uit te leggen:

• Je kunt geen doel of resultaat uitvoeren.

• Maar je kunt wel een proces uitvoeren.

Waarom is dit moeilijk?

Deze mentaliteitsverandering is het moeilijkste deel van het Improvement Kata. Van jongs af aan is ons geleerd om te denken in uitkomsten en resultaten. We moeten ambitieuze doelen stellen en naar de sterren reiken. Het is niet ingebakken in onze cultuur om na te denken over het proces. Dus moeten we deze mentaliteitsverandering maken om dit onderscheid te leren maken en ons te richten op het proces.

Verbetering van het dagelijkse werk is belangrijker dan het dagelijkse werk. Maar het komt niet in de plaats van dagelijks werk.

Voordat we beginnen, een overzicht

Dit is een schematisch overzicht van het Improvement Kata proces. Ik zal de verschillende onderdelen in dit artikel bespreken, je kunt deze afbeelding als referentie gebruiken.

Het ware noorden - onze visie voor het bedrijf

We willen een rustig bedrijf zijn. En we geloven dat we dat kunnen bereiken door deze vier dingen na te streven in onze processen:

• Een enkelvoudige productstroom, op volgorde en op aanvraag.

• Nul defecten.

• 100% toegevoegde waarde.

• Veiligheid voor mensen.

Laten we ze verder onderzoeken.

Stroom van afzonderlijke items, op volgorde en op aanvraag

Dit is een van de overkoepelende principes van de Improvement Kata. Voordat we iets anders doen, moeten we een proces, welk proces dan ook, dichter bij een enkelvoudige flow brengen, in volgorde en on-demand. Maar waarom?

We willen een stabiel en voorspelbaar proces. We willen een schaalbaar proces en een proces zonder veel verspilling. Om daar te komen moeten we de knelpunten in dat proces zien. De overstap naar een single item flow laat die knelpunten zo snel mogelijk zien. En duidelijker. Je moet ze oplossen, anders kan er niets door het proces stromen.

Als we een opeenvolgend proces van één itemstroom hebben, kunnen we niet de kantjes eraf lopen en dingen versnellen om dingen gedaan te krijgen. We moeten een knelpunt in het proces verwijderen voordat we verder kunnen. Zolang we daar niet zijn, kunnen we valsspelen. Als je het knelpunt in een proces duidelijk kunt zien, kun je het gaan oplossen en het proces verbeteren, wat leidt tot betere resultaten.

Nul defecten

Elke keer dat een proces niet werkt zoals gedefinieerd, hebben we een defect. Een defect is dus gericht op het proces, niet op het resultaat. Elk defect moet worden onderzocht om ervan te leren.

Veel problemen is gelijk aan een tevreden baas.

100% toegevoegde waarde

Alles wat we doen in een proces moet waarde toevoegen aan het eindresultaat van het proces. Als we dingen in ons proces doen die geen waarde toevoegen, moeten we ze niet doen. Dit wordt ook wel het verwijderen van verspilling uit een proces genoemd.

Veel 'lean' discussies richten zich op het wegwerken van verspilling. De veronderstelling is dat het wegwerken van verspilling een doel is van lean zijn, terwijl het wegwerken van verspilling eigenlijk een resultaat is van de Improvement Kata. Het is geen doel op zich.

Veiligheid voor mensen

Alles wat we doen moet aan dit principe voldoen. Wanneer we een uitdaging, doelvoorwaarde of procesbeschrijving instellen, moeten we altijd controleren of het binnen deze limiet valt.

Mensen maken fouten. De systemen die we hebben moeten die helpen voorkomen of, als ze toch gebeuren, de gevolgen van een fout beperken. Het zou veilig moeten zijn om fouten te maken. Ze zouden niet moeten leiden tot catastrofale gebeurtenissen. En als er een catastrofale gebeurtenis of minder catastrofale gebeurtenis plaatsvindt, moeten we de systemen verbeteren.

Veiligheid voor mensen betekent ook dat iedereen zichzelf kan zijn op het werk. We moeten ons kunnen uitspreken, feedback geven en kennis delen. Zo leren we als mensen en als organisatie.

Huidige toestand

Als we het hebben over de huidige toestand, hebben we het over het proces dat we willen verbeteren. In een perfecte wereld zou dit proces een duidelijke beschrijving moeten hebben. Deze beschrijving moet vertellen hoe we willen dat het proces werkt. De beschrijving moet het volgende bevatten

• Alle stappen van het proces.

• De tijd die elke stap mag duren.

  Hoeveel mensen aan een stap werken.

• Alle kwaliteitsgegevens van deze stap.

• Hoeveel inventaris per stap is toegestaan.

• De totale cyclustijd van het proces.

Het kan ook een beschrijving bevatten van de kenmerken van dit proces. Eventuele zorgen met betrekking tot de veiligheid voor mensen moeten worden vermeld en tot slot moet er een uitkomstmaat worden opgenomen.

Voor een nieuw proces kan deze beschrijving gaandeweg worden gemaakt. Terwijl we werken aan het verbeteren van het proces ontdekken we hoe het proces zou moeten werken. Dit kan en moet worden opgeschreven zodat het kan worden gebruikt als documentatie over het proces. En terwijl we het proces veranderen en verbeteren, moet deze documentatie bijgewerkt worden. Je zult zien dat hoe langer je aan een proces werkt, hoe verfijnder het proces wordt.

Waarom is dit moeilijk?

Om over te kunnen gaan op single item flow en niet te eindigen met lokale optimalisaties moeten we streven naar één proces. Kijk uit voor het beschrijven van een proces als een op zichzelf staand proces, dat eigenlijk onderdeel is van een groter proces, en dus een subproces op zichzelf is.

Toen we begonnen met het toepassen van de Improvement Kata hadden we een ontwikkelproces, een testproces en een documentatie-, vertaal- en communicatieproces. Ik vond het moeilijk om ontwikkeling ervan te overtuigen dat we het testproces moesten opnemen als onderdeel van de totale ontwikkelingspijplijn. Want door de ontwikkelcyclus te verbeteren, maar niet in staat te zijn om stories te testen en in te zetten, hadden we verspilling gecreëerd.

We moeten het geheel optimaliseren.

Voorbeeld

Laten we een voorbeeld gebruiken om dit te illustreren. Ons proces om waarde te leveren aan klanten bestaat uit de volgende subprocessen om een functie online te krijgen:

• Beslis wat u gaat bouwen - 3 weken

  • Verzamel informatie over functieverzoeken (op aanvraag).

  • Rangschik functieverzoeken op prioriteit (in volgorde).

  • Deze functie beschrijven en plannen voor ontwikkeling.

• Een verhaal ontwikkelen - 3 dagen

  • Bespreken met de producteigenaar.

  • Ontwerp, bouw, code review.

    Refactureer de code.

  • Test met het team.

• Een story testen en implementeren - 3 uur

  • Het story bouwen in staging.

  • Acceptatietests uitvoeren.

  • Test een story.

  • Merge story.

  • Deployeer naar productie.

• Vertaal - 1 dag

  • Maak één itempakket voor dit story voor vertalers.

  • Verstuur het pakket naar de vertalers.

  • Translators vertalen de labels voor dit verhaal.

• Documenteren en communiceren - 3 dagen

  • Releaseopmerkingen schrijven.

  • Helpartikelen schrijven, bijwerken en publiceren.

    Communiceren met relevante klanten.

We hebben veel documentatie voor elke stap die beschrijft aan welke kwaliteit je je moet houden, hoeveel stories in een bepaalde stap mogen zitten, hoeveel iteraties zijn toegestaan en hoeveel defecten in een story zijn toegestaan. Dat zou een artikel op zich zijn.

De belangrijke les die je hieruit kunt trekken is dat je om het geheel te optimaliseren alle stappen in één proces moet hebben en ze moet meten. Als je het niet op deze manier doet, zal een optimalisatie in de ene stap tot verspilling leiden in een andere stap.

Resultaat metric

De uitkomstmetriek beschrijft wat een proces produceert. Dit is het resultaat van het proces. We meten de uitkomstmeting af en toe om te controleren of het proces nog steeds op schema ligt om het gewenste resultaat aan het bedrijf te leveren. Dit is wat andere bedrijven gebruiken als doelen of targets.

Waarom is dit moeilijk?

Wat we moeilijk vinden, is een duidelijk onderscheid maken tussen resultaten (uitkomstmaat) en proces. En als je eenmaal een uitkomstmaat hebt gedefinieerd, lijkt het ineens een doel. Dat we moeten halen en teleurgesteld zijn als we het niet halen. Het enige doel van de uitkomstmaat is om te kunnen meten of je dichter komt bij waar je wilt zijn.

Voorbeeld

Het resultaat van ons ontwikkelingsproces is dat we elke drie maanden een functie van $100 per team willen uitbrengen. We denken dat het elke maand uitbrengen van zo'n functie die waarde levert aan onze klanten ons de groei zal geven die het bedrijf nodig heeft om een rustig bedrijf te worden.

Uitdaging

De uitdaging beschrijft de toekomstige staat van je proces die je wilt bereiken. Het moeilijke hierbij is om in gedachten te houden dat we het over het proces hebben, niet over het resultaat. Je moet beschrijven hoe je wilt dat het proces werkt en niet een doel of resultaat. Een uitdaging kan ver weg liggen met een lange tijdlijn, ergens tussen zes weken en een jaar. Als je al weet hoe je daar moet komen, is het te dichtbij. De uitdaging geeft richting en wordt opgesplitst in kleinere doelvoorwaarden.

De beste plaats om te beginnen met het definiëren van de uitdaging is het verkrijgen van de single item flow. Daarna moet je streven naar opeenvolging en het laatste deel moet over de vraag gaan. Het kostte ons twee jaar om de single item flow en in sequence te bereiken.

Waarom is dit moeilijk?

Nogmaals, dit komt neer op denken in processen en niet in resultaten. Voor veel mensen is het moeilijk om te gaan met de onzekerheid dat je niet weet hoe je er moet komen.

Voorbeelden

Toen we begonnen met de Improvement Kata hadden we de uitdaging om over te stappen op een single item flow voor het vrijgeven van een story. Dus, als een story klaar was, moest hij online komen.

Een ander voorbeeld is het subproces voor vertalingen. We hebben de uitdaging als volgt gedefinieerd:
Binnen drie maanden komen tot een single item flow voor vertalingen, met een cyclustijd van één dag, zonder tijd te besteden aan het beantwoorden van vragen.

Doelconditie

Een doelconditie is de eerste stap die je dichter bij je uitdaging brengt en die haalbaar is binnen drie tot zes weken. Dit is de toekomstige staat van het proces waar we naar streven. De doelconditie geeft ons een gevoel van richting voor onze verbeteringen. Hoe? We meten ons werkproces terwijl we werken. Telkens wanneer we een afwijking hebben van het proces zoals beschreven in de doeltoestand, moeten we daarnaar kijken. We noemen dat een 'root cause analysis' (afgekort RCA). Door de RCA's uit te voeren, krijgen we informatie over ons knelpunt.

Voorbeeld

Voor de uitdaging over de vertalingen hebben we deze eerste doelvoorwaarde gedefinieerd:
Bepaal en meet de tijd die het kost om één item naar alle talen te vertalen. We willen per taal meten.

Knelpunt

Soms noemen we dit een obstakel. Maar het woord knelpunt is veel beter geschikt om te beschrijven wat het is. Een proces kan maar één knelpunt hebben (maar vele obstakels). De bottleneck is wat ons verhindert om onze doeltoestand te bereiken.

Als je naar een zandloper kijkt, is het deel dat het kleinst is de bottleneck. Het vergroten van de zandloper voor of na het knelpunt verhoogt de doorstroming niet. Het verbeteren van iets anders dan de bottleneck is verspilling. Het knelpunt voorkomt dat het item ononderbroken door het proces stroomt, of is dat deel van het proces met de laagste doorvoer.

Alleen het verbeteren van het knelpunt zal je dichter bij je doeltoestand brengen. We lossen het knelpunt op door een PDCA-cyclus uit te voeren (waarover later meer).

Waarom is dit moeilijk?

Het moeilijkste is om de bottleneck te definiëren. Wanneer je begint te verbeteren en het onder de knie krijgt, zie je veel dingen die verbeterd kunnen worden, maar niet het knelpunt zijn. De drang om die dingen op te lossen is moeilijk te weerstaan, vooral als het kleine dingen zijn die je kunt doen. Vasthouden aan het oplossen van de bottleneck is moeilijk en vergt enige discipline. Aan de andere kant, hoewel de theorie zegt dat er maar één knelpunt is, is iets oplossen altijd beter dan zoeken naar het knelpunt en niets oplossen. Door een verbetering door te voeren, kunt u de RCA- en PDCA-cycli oefenen.

Verbeter wat verbeterd moet worden, niet wat verbeterd kan worden.

Voorbeeld

Voor ons vertaalvoorbeeld hebben we het eerste knelpunt als volgt gedefinieerd:
Niet weten waaruit een item bestaat. We hebben een item niet gedefinieerd en we weten niet welke labels en pagina's die vertaald moeten worden deel uitmaken van dat item.

RCA

Zoals ik al heb uitgelegd, is RCA steno voor 'root cause analysis'. Elke keer dat we een afwijking hebben van onze doelconditie doen we een RCA om de hoofdoorzaak te vinden. Het vinden van de hoofdoorzaak toont je het knelpunt.

Waarom is dit moeilijk?

Een afwijking van de doelconditie gebeurt nooit op een geschikt moment, meestal moet je mensen storen om samen te komen om de RCA te doen. We doen de RCA graag zo dicht mogelijk bij het moment waarop de afwijking plaatsvindt, zodat het spoor van informatie niet koud wordt. Het doen van de RCA is dus een afweging tussen niet in flow werken en dagelijks verbeteren.

Ik had laatst een discussie met Maarten, Front-End Developer & UX Designer, over een functie die lang op zich liet wachten om online te komen. Het ging als volgt:

Maarten: We hebben eindelijk het verhaal dat automatisch de afbeeldingen genereert voor de documentatie online. Het heeft ons twee RCA's en veel werk gekost om het voor elkaar te krijgen.
Me: Maak je geen zorgen dat het langer heeft geduurd dan gepland, want we hebben veel geleerd tijdens het proces.
Maarten: Ja, de RCA's die we hebben gedaan hebben mijn mindset veranderd van 'dit proces is instabiel' naar 'waarom is dit proces zo instabiel?'.

Met deze mentaliteitsverandering kun je naar de hoofdoorzaak gaan kijken en oplossingen bedenken. Met de vorige mindset raak je alleen maar geïrriteerd en gefrustreerd en dat zal niets verbeteren.

We moeten vertragen om sneller te gaan.

PDCA

PDCA is een afkorting voor 'Plan, Do, Check, Act'. Het proces om een knelpunt in kleine stappen te verbeteren. De uitdaging hier is om een kleine stap te bedenken om het proces te verbeteren. Iets wat je vandaag al kunt doen. Voor sommige dingen hebben we duidelijk meer tijd nodig. Bijvoorbeeld als we iets moeten ontwikkelen of automatiseren. Maar we moeten altijd proberen om dingen kleiner te maken. Kunnen we een verbetering eerst met de hand doen, zodat we kunnen zien of het ons dichter bij de doeltoestand brengt? Als dat het geval is, kunnen we dan automatiseren? Een kleine verbetering verschuift ons blikveld en verhoogt onze kennisdrempel. Na de verbetering zien en weten we meer.

Een te grote verbetering kan leiden tot verspilling omdat het ons niet dichter bij de uitdaging brengt. Daarom moeten we verbeteringen klein houden. We kunnen maar één verbetering per proces per dag doen. Anders weten we niet of de verbetering echt iets verbeterd heeft.

Waarom is dit moeilijk?

Meestal zien we veel dingen die verbeterd kunnen worden. En die willen we uit de weg ruimen, denkend dat daarmee alle problemen opgelost zijn, zodat we verder kunnen met ons werk. Maar we weten niet of al die problemen nog steeds bestaan als we wat kleine verbeteringen aanbrengen.

Het is ook moeilijk om niet te ver vooruit te denken en alle obstakels op de weg te zien. Je weet niet of die obstakels er ook echt zullen zijn als we er zijn. En of dat obstakel eigenlijk de bottleneck is. We weten het dus pas als we er zijn.

Kleine stappen nemen is het werk dat nog niet gedaan is maximaliseren. We komen er wanneer we er zijn.

Gezichtsveld of kennisdrempel

Het gezichtsveld of de kennisdrempel is wat we op dit moment weten en wat we kunnen zien. In dit gezichtsveld zijn veel verbeteringen mogelijk. De uitdaging geeft ons een richting voor onze verbeteringen. Als we een kleine verbetering aanbrengen, verschuiven we ons gezichtsveld (blauwe lijn) en verhogen we onze kennisdrempel in de richting van de uitdaging. Na deze verschuiving weten we meer en kunnen we andere verbeteringen en stappen zien die we kunnen nemen om onze uitdaging te bereiken.

Waarom is dit moeilijk?

We geven onszelf de schuld dat we niet eerder verbeteringen hebben gezien. Je kunt iemand betrappen op de uitspraak "waarom hebben we dit vorig jaar niet gedaan?".

Ik moet hier de beroemde Nederlandse voetballer Cruijff citeren:

Je gaat het pas zien als je het doorhebt.