Beter kanbannen met process theory

This is lean

Een bekende voor kenners: het boek ‘This is Lean’ van Niklas Modig (op Bol of Amazon te koop). Dat boek schept orde in de (deels tegenstrijdige) claims over wat ‘lean’ nu eigenlijk is. In eerste instantie was ik heel enthousiast, maar toen ik er wat dieper over na ging denken kreeg ik steeds meer vragen over of het nou eigenlijk wel allemaal klopt wat er in staat. Ik ben toen behoorlijk diep de proces theory ingedoken (o.a. op Coursera), dus het vakgebied van hoe je processen in een grote fabriek optimaliseert. Over wat ik daarbij geleerd heb vertel ik in deze blogpost.

Resource efficiency en flow efficiency

Er zijn twee verschillende manieren om naar efficiency te kijken. Het ene perspectief, dat van de resource efficiency, is waar je denk ik het eerst aan denk als je aan een klassieke fabriek denkt: je hebt grote dure machines en wilt die zo efficient mogelijk benutten. De formule voor efficiency is de tijd dat je waarde toevoegt, gedeeld door de totale tijd. Als een machine 1 uur insteltijd nodig heeft, vervolgens 4 uur produceert en daarna 3 uur schoongemaakt moet worden, is de resource efficiency dus 50%.

Het andere perspectief is dat van de flow efficiency. Daarbij neem je juist het ding dat wordt gemaakt of bewerkt onder de loep, de flow unit, en kijk je hoeveel procent van de tijd die flow unit waarde ontvangt. Bijvoorbeeld, mijn zoontje gaat eens in de paar maanden naar het ziekenhuis voor controle. Daarbij wordt hij langs verschillende artsen en onderzoeken geloodst. Hier zie je zijn schema voor zo’n dag:

Rechts heb ik toegevoegd hoe lang ieder van de onderdelen duurt. Je ziet dat de totale tijd dat we een arts zagen of een onderzoek deden 90 van de 120 minuten was (die tijden heb ik links uitgelijnd), oftewel een flow efficiency van 75%. Je maakt per activiteit of proces een keuze op welke van deze twee je wilt focussen. Je kunt ervoor kiezen om vooral je machine 100% aan het werk te hebben, dan ben je resource efficient, en zit je boven in deze efficiency matrix:

Of je kunt ervoor kiezen om je flow unit zo soepel mogelijk door je proces te laten gaan, dan ben je flow efficient en zit je hier rechts op de efficiency matrix. Zoals je ziet heb ik een aantal voorbeelden op de grafiek gezet, ik zal die even toelichten.

• Spreekuur dierenarts: Mijn dierenarts heeft van 19:00 tot 22:00 uur spreekuur, zonder afspraak. Dus wie het eerste komt is het eerste aan de beurt. In de praktijk stroomt om 18:45 zijn wachtkamer vol. Dit proces scoort hoog op resource efficiency, want de arts heeft de ene patient na de andere zonder te wachten. Maar het scoort laag op flow efficiency, want mensen zitten (met hun huisdier) uren te wachten totdat ze aan de beurt zijn.
• Toiletten bioscoop: Een bioscoop heeft tientallen toiletten, zodat in de pauze alle mensen die uit de zaal komen snel naar het toilet kunnen. Dit proces scoort laag op resource efficiency; de toiletten staan immers het grootste deel van de dag ongebruikt. Maar het scoort hoog op flow efficiency, want in de pauze kan een zeer groot aantal mensen tegelijk gebruik maken van de toiletten, met kleine wachtrijen.
• Kassa Jumbo: De Jumbo heeft als belofte dat de 4e klant in de rij zijn boodschappen gratis krijgt. Als er dus 3 mensen in de rij staan, wordt er snel een kassa bijgedraaid. Daar wordt bijvoorbeeld het meisje van de vleeswaren voor ingeschakeld of de jongen van het brood. Dit proces scoort hoog op resource efficiency, want het is niet zo dat er altijd veel kassa’s open zijn, met wachtende caissières. De extra kassa’s worden pas geopend als het nodig is. En het scoort ook hoog op flow efficiency, want klanten hoeven niet lang te wachten.
• Start-up: Een start-up heeft doorgaans nog weinig processen, en is veel bezig met ad-hoc reageren op situaties. Het scoort dus laag op resource efficiency (het wiel wordt drie keer opnieuw uitgevonden, er is weinig afstemming), en waarschijnlijk ook op flow efficiency (geen snelle reactie op klantvragen, geen soepele productielijn).

De ‘perfect state’ zit rechtsboven: een perfecte flow in combinatie met volledig gebruik van de resources. Om te zien waarom die ‘perfect state’ een utopie is, moeten we wat gedetailleerder kijken naar hoe processen in elkaar zitten.

Wat zijn de kenmerken van een proces?

Een proces is een serie handelingen of stappen vanuit het perspectief van de flow unit. Dus in de voorgaande voorbeelden is zijn het de aardappelen die friet worden, of de patiënt die door al zijn checkups gaat. Je bepaalt zelf waar je de grenzen van het proces stelt. Dus in het geval van het ziekenhuisbezoek, zou je ook kunnen beginnen op het moment dat je het terrein van het ziekenhuis oprijdt, tot het moment dat je de parkeerplaats weer verlaat. Of zelfs vanaf het moment dat je thuis weggaat tot het moment dat je weer terugkomt. Dit heeft natuurlijk invloed op de flow efficiency. En je hebt gezien dat er twee verschillende types activiteiten zijn: er zijn activiteiten die waarde toevoegen, dus helpen om de directe behoefte te voldoen (bijvoorbeeld een consult); en er zijn activiteiten die dat niet doen, zoals transport, wachten, etc.

Maar let op: er is ook nog een heel gemene categorie van activiteiten die lijken alsof ze waarde toevoegen, maar eigenlijk strikt genomen niet nodig zijn. Bijvoorbeeld een patiënt bellen om een afspraak te verzetten omdat de arts uitgelopen is: dat was niet nodig geweest als de arts een optimale resource efficiency had gehad. Maar daarover later meer.

Drie proces-wetten

Wat maakt nou dat een proces flow heeft? Of andersom gezegd: wat hindert de flow in een proces? Daarvoor moeten we kijken naar de drie wetmatigheden die op een proces van toepassing zijn.

Wet 1: Little’s law is een heel intuïtieve relatie tussen inventaris, doorlooptijd en flow rate (dus de snelheid waarmee flow units door het systeem komen)

doorlooptijd = inventaris / flow rate

Als er 1000 mensen vóór je staan in de Python (de inventaris), en er vertrekt iedere minuut een karretje met 20 mensen (de flow rate), dan duurt het 50 minuten voordat je aan de beurt bent. De doorlooptijd is dus 50 minuten. Andersom kun je met Little’s law ook berekenen hoeveel inventaris je hebt: als je weet dat er iedere minuut 20 mensen uit de Python komen, en je weet dan die mensen er 50 minuten over gedaan hebben, dan zit er kennelijk 1000 stuks inventaris in het systeem.

Wet 2: de Law of Bottlenecks stelt dat ieder proces, hoe goed het ook loopt, minimaal één beperkende factor heeft. Als je die opspoort en oplost, zie je de volgende bottleneck. Je herkent de bottleneck op een Kanban bord aan het opstapelende werk in die kolom (of ervoor, als je je aan de WiP-limits houdt), en lege kolommen erachter.

Wet 3: de Law of Effect of Variation is complexer dan de voorgaande wetten. Het toont aan welk effect variatie op een proces heeft, in relatie met de hoeveel slack je hebt. Deze wet vond ik zelf het moeilijkst te begrijpen, maar dat kwam ook deels omdat de illustratie die in het boek stond niet klopte (naar mijn bescheiden mening). Hieronder zie je mijn eigen, herziene, versie:

Laten we eerst naar de blauwe lijn kijken. Die gaat er vanuit dat er geen enkele variatie is in het proces, dus dat bijvoorbeeld iedere bloedafname exact 10 minuten kost. Nooit meer, nooit minder. De onderste as is de utilisation (eigenlijk hetzelfde als resource efficiency), dus hoe vol je de verpleegkundige boekt. Als er geen enkele variatie is, kun je hem of haar 6 patiënten per uur geven, dus 100% utilisation. En ontstaan geen wachttijden, want iedere patiënt staat na 10 minuten weer buiten.

Maar stel nou dat er een klein beetje variatie is, de groene lijn. Sommige patiënten hebben een paar minuten meer nodig, of de spuiten zijn op en moeten even gehaald worden. Dan kom je in de problemen als je haar helemaal volboekt, want dan ontstaat er een wachtrij. En die wachtrij wordt iedere keer als een patiënt uitloopt, een stukje langer. Want na 10 minuten staat patiënt 2 alweer voor de deur, terwijl de verpleegkundige nog niet klaar is met patiënt 1. (NB: dit middelt niet uit wanneer de patiënten gemiddeld 10 minuten behandeltijd hebben. Want als de eerste patiënt in 8 minuten klaar is en de tweede duurt 12 minuten, dan is de gemiddelde behandeltijd nog steeds 10 minuten, maar haal je de 2 minuten die je hebt gewacht op de tweede patiënt nooit meer in. De enige manier om dit te ondervangen is door met buffers te werken.) Dat wil zeggen: de wachttijd loopt op indien je de verpleegkundige helemaal volboekt (dus helemaal rechts op de x-as). Want als je niet 6 patiënten per uur inplant, maar slechts 5, dan kun je die kleine variaties wel opvangen. Tot ongeveer 80% utilisation is er dan helemaal geen probleem, pas daarna loopt de wachttijd op.

De rode lijn toont het effect als de variatie nog groter wordt: je komt dan eerder in de problemen, dus al bij een lagere utilisation. Je hebt dan dus veel meer slack nodig om de variatie op te vangen.

Concluderend stelt deze wet:

• als je de resource efficiency hoog wilt houden moet je de variatie beperken. Maar dat is in veel situaties onmogelijk. Bijvoorbeeld bij de Kiosk op het station kun je weinig doen aan de variatie in aantal klanten gedurende de dag.
• of je kunt variatie opvangen door je resources minder vol te plannen. Als je dat niet doet, dan krijg je een steeds langere wachttijd.

Over waste

We hebben nu gezien welke wetmatigheden van toepassing zijn op een proces: Little’s Law, de Law of Bottlenecks, en de Law of Effect of Variation. Laten we nu eens gaan kijken wat het effect in de praktijk is.

Zeg dat je een hoge utilisation hebt. Omdat het vrijwel onmogelijk is om variatie te voorkomen, zal dit leiden tot een langere doorlooptijd (wet 3, remember?). Als de doorlooptijd lang is, zullen er nieuwe, secundaire behoeftes ontstaan. Bijvoorbeeld: als ik een hele stapel todo’s heb, gaan mensen vragen ‘Dirk, heb je dit-of-dat al gedaan?’ Die vraag is een secundaire behoefte: daar hadden we geen tijd aan hoeven besteden als ik mijn todo’s sneller afgehandeld had. Of je hebt een poll uitgezet in welk restaurant mensen willen eten, maar tegen de tijd dat iedereen gereageerd heeft is dat restaurant al vol: het ‘window of opportunity’ is gesloten. Je moet dan opnieuw opzoek naar een restaurant, een nieuw poll, etc. En als iets langer duurt zijn er meer overdrachten en moet je je telkens opnieuw inlezen. Al deze dingen leiden tot ‘waste’: activiteiten waarmee je druk bent, maar die niet nodig waren geweest als je een goede flow gehad had. Omdat je tijd moet besteden aan deze waste, heb je minder tijd voor je echte werk, wat weer lijdt tot langere doorlooptijden, etc, etc, etc.

Een ander effect van een langere doorlooptijd is dat je meer inventaris hebt. Daar zitten specifieke gevaren aan, die heb ik in het blokje eronder gezet. Zo kan een inventaris verborgen problemen bevatten. Als je al 1000 stuks van een bepaald onderdeel gemaakt hebt voordat je erachter komt dat het niet past in de auto die je aan het bouwen bent, dan moet je veel weggooien. Het beheren zelf kost tijd: je moet de onderdelen netjes opbergen, verder transporteren (omdat je een groter magazijn hebt), bent langer om een specifiek onderdeel te zoeken, etc. Bovendien, wat hier niet expliciet op staat: inventaris kost geld. Ook in software-ontwikkeling: daar bestaat je inventaris uit alle code die nog niet op productie staat.

3 tips voor software ontwikkelaars

Wat betekent dit alles nou voor ons, als software ontwikkelaars? Nou, best wel veel. 3 tips die je vanaf morgen kunt gaan doen en die meteen iets opleveren:

• Beperk het aantal tickets: dan hou je veel makkelijk overzicht en bovendien brengt iedere geïnvesteerde euro sneller geld op. Durf van een overvolle backlog alle die oude tickets weg te gooien, daar ga je toch nooit aan toekomen. En gebruik de WiP-limits op het Kanban-bord om ervoor te zorgen dat je niet met teveel tickets tegelijk bezig bent.
• Elimineer waste: want alle tijd die je aan waste besteed is ehh, zeg maar: waste. Dit klinkt heel triviaal, maar sommige vormen van waste lijken heel erg op ‘werk’. Als hetzelfde ticket voor de tweede keer besproken moet worden in een refinement-meeting dan is dat waarschijnlijk waste. Idem voor managementrapportages: maak je proces zo transparant dat aparte rapportages niet nodig zijn.
• Focus op de bottleneck: de neiging is heel groot om ‘aan de gang’ te willen blijven. Maar stel dat bijvoorbeeld je testkolom een grote bottleneck is, waar tickets dagenlang blijven hangen. Dan kun je wel nóg een ticket oppakken, maar die wordt uiteindelijk toegevoegd aan de wachtrij vóór de testkolom en staat daar eerst nog een tijdje te verouderen voordat ie opgepakt wordt. In de tussentijd is de developer al vergeten waar het ook al weer over ging, heb je grotere kans op merge-conflicten, en heeft de tijd die erin gestoken is geen waarde opgeleverd. En dan heb je ook nog de kans dat de ticket inmiddels ingehaald is door de werkelijkheid of domweg te laat is. Alles, maar dan ook echt alles dat helpt om de bottleneck te ontlasten heeft meer waarde dan nieuwe tickets oppakken. Gebruik je tijd dus liever om het proces te verbeteren. Tegenintuïtief genoeg kan zelfs ‘niets doen’ productiever zijn dan doorwerken. Want ‘verse’ code kost minder tijd om te testen, en belast de bottleneck capaciteit minder dan code die inmiddels een paar weken staat te wachten. Je kunt dan dus beter later beginnen aan een ticket, en erop mikken dat ie nét klaar is op het moment dat de tester klaar is om ermee aan de slag te gaan.

Als afsluiter wil ik je nog deze meegeven:

Alleen code die op productie staat brengt geld op. De rest is alleen maar risico.

Ons advies is: hou deze quote in je achterhoofd bij al je beslissingen. Focus op code naar productie brengen, want alleen dan voegt het waarde toe. Dat betekent overigens niet dat je moet overhaasten, maar vooral dat je geen stuwmeer aan ‘onderhanden werk’ moet creeëren.

Heb je vragen of opmerkingen? Neem dan contact met me op of reageer op dit artikel. Leuk om van je te horen!