Vijf Kanban Flow Metrics die teams helpen met een goede workflow te creëren. Verbeter de workflow met 5 kritische metrics en voeg waarde toe.

De belangrijkste bijdrage van Kanban in het toevoegen van waarde voor de klant door een goede workflow te creëren. Deze workflow kan je meten, beïnvloeden en verbeteren door het hanteren van Kanban Flow Metrics.

Dit artikel beschrijft de 5 kritische Metrics van een Kanban Workflow. Wil je eerst meer weten over Kanban? Dan is het artikel Wat is Kanban? interessant.

Waarde toevoegen

Het uitgangspunt van Kanban het toevoegen van waarde voor de klant en de organisatie. Een stabiele werkstroom helpt een organisatie om sneller te reageren op de markt.

De twee peilers van Kanban zijn het just in time proces en de menselijke factor, ook wel ‘autonomation’ genoemd. Beide peilers leiden naar een stabiele workflow. Door het tot stand brengen van een stabiele workflow ontstaan er succesvolle en productieve teams.

Teams moeten in staat zijn om de succesratio van de workflow te meten en daarop actie te ondernemen om deze te verbeteren. De primaire focus van dit artikel ligt dan ook op metrics van een Kanban workflow.

Metrics

Een goede Kanban kan niet zonder data en metrics. Bij voorkeur hanteert men statistisch significante data, vaak geven ‘recht toe recht aan’ tellingen al de eerste waardevolle inzichten.

Waar metrics aan moeten voldoen heb ik beschreven in het artikel 3 principes van agile metrics. Onderstaande Kanban metrics voldoen aan deze principes.

Metrics worden gebruikt om verandering te ondersteunen en het onderscheid te maken tussen goede en slechte veranderingen vanuit een objectief gegeven.  In de praktijk zie je dat teams vrijwel altijd Kanban metrics hanteren om te bepalen waar verdere verbetering kan plaatsvinden.

Het bespreken van de metrics zorgt er voor dat het team zich richt op één van de 5 aspecten van Kanban: meet en verbeter de flow.

Welke metrics te hanteren?

Kies bij het begin met Kanban een paar simpele metrics, meet en bediscussieer de uitkomsten. Bekijk dan regelmatig of de metrics nog passen bij de ontwikkeling van het team, wellicht moet je ‘oude’ metrics loslaten en ‘nieuwe’ gaan hanteren. Uiteindelijk bepaalt het team welke metrics gehanteerd worden.

Er zijn echter Kanban metrics die je sowieso dient te gebruiken, de 2 meest waardevolle metrics zijn Lead Time en Cycle Time. Dit zijn belangrijke graadmeters van het Kanban systeem.

Bovenstaande 2 metrics zijn echter slechts een deel van 5 critical metrics die een team volledig moet beheersen. Het beste is om de eerste weken deze 5 metrics te hanteren, voordat in de retrospectives allerlei varianten worden ingebracht. Dit is van belang omdat onderstaande 5 kritische metrics een basis leggen voor Continuous Improvement (CI).

5 metrics van een Kanban workflow

Met Kanban flow metrics krijg je o.a. goed inzicht in: productiviteit, efficiency en betrouwbaarheid van het productieproces. In het Engels heeft men het vaak over 5 critical metrics, productivity metrics en/of process efficiency metrics.

De vijf kritische Kanban Flow Metrics:

1. Cycle time
2. Lead time
3. Total Work In Progress (WIP)
4. Blockers
5. Througput

Heel bewust blijf ik deze metrics in het Engels gebruiken. Het is erg onhandig om deze te vertalen, men hanteert vrijwel altijd de Engelse termen.

1. Cycle time

De definitie van cycle time is: de totale tijd van het begin tot het eind van het proces. De meting start zodra de workitem geplaatst wordt in de ‘in progress” kolom en eindigt zodra de workitem geplaatst wordt in de ‘Done’ kolom.

Om de cycle time te berekenen is de volgende formule:

Cycle time = Work in Progress (WIP) / Average Completion rate

Met deze formule zijn er 2 mogelijkheden om de cycle time te verbeteren.

1. Verminder het aantal items in het proces.
2. Verbeter de average completion rate.

Van deze 2 mogelijkheden is het verminderen van het aantal items in het proces de makkelijkste. In een later stadium, als het aantal items in progress is uitgekristalliseerd, is het de uitdaging om de average completion rate te verbeteren.

Bovenstaande formule is één van de weergaven van de ‘Little’s Law for Queuing Theory’.

2. Lead Time

De Lead Time metric geeft aan hoelang het duurt dat een workitem van A naar B gaat. Dit kan gemeten worden van elk gewenst startpunt en eindpunt op het bord. Het is gebruikelijk om de hoeveelheid tijd te nemen die een work item nodig heeft om van geheel links op het bord naar geheel rechts op het bord te gaan. De meting start wanneer de workitem van de backlog op het bord geplaatst wordt en stopt wanneer de item in de ‘done’ terecht komt.

Het handigste is om op de kaart (evt. achterzijde) de datums te vermelden. Als de kaart in ‘Done’ is gearriveerd bereken je de verstreken dagen vanaf de start.

Deze meting mag ook op alle andere punten beginnen en eindigen. Dit schept vaak verwarring. Soms is Lead Time de klanten Lead Time, bij een ander de Ontwikkel Lead Time etc. etc. Zorg ervoor dat je weet wat men met deze nou exact meet, doe geen aanname. Overigens is dit tevens ook de kracht van Lead Time, een separaat stuk meten van het totale proces geeft je meer specifieke inzichten dan Cycle time.

De combinatie van Cycle Time en Lead Time geeft het team de mogelijkheid om specifiek in te zoomen op procescomponenten. Daardoor is het team beter in staat om de totale efficiency te overzien en te verbeteren.

3. Total Work in Progress (WIP)

Work in Progress (WIP) staat voor een telling alle taken op het huidige Kanban Board. Kortom, alles wat is opgestart maar waarvan de taak nog niet volledig is afgerond.

Van alle Kanban Flow Metrics spreekt WIP het meest tot de verbeelding. Vooral omdat het bepalen van de juiste WIP een kwestie is van goed meten in samenhang met het aantal beschikbare teamleden . Overigens is een basisregel: zonder WIP is het geen Kanban!

Als een team start met het meten van flow, is WIP een eenvoudige telling en het vastleggen van het aantal niet afgeronde kaarten. Hierdoor leert het team een goed begrip te krijgen hoeveel werk er onderhanden is. Het onderhanden werk heeft nog geen toegevoegde waarde.

WIP is gelimiteerd. Je kan binnen Kanban namelijk alleen iets opnemen als er iets anders af is. Het team spreekt namelijk WIP-limits af om een ideale flow te bewerkstelligen. Toch is het belangrijk om de WIP te berekenen. Het creëert een Pull systeem waar capaciteit en klantvraag met elkaar in balans wordt gebracht.

WIP = Cycle Time * Arrival Rate

WIP = Throughput * Cycle Time

Waarbij een hogere WIP een langere Cycle Time kent. Het verkleinen van de WIP verkort de Lead Time. Kortere lead times maakt het bijvoorbeeld bij software ontwikkeling mogelijk om frequenter op te leveren en dat vergroot weer het vertrouwen bij externe partijen,

Realiseer je dat WIP impact heeft op productiviteit, voorraden en teamwork. Als men het belang van WIP onderkent en deze weet te verlagen, dan verhoogd men de productiviteit. Je meet productiviteit met Cycle Time en Troughput.  

Welke meting kan je dan ook doen? 

Totaal aantal WIP / aantal members in het team < 5

Wat staat hier eigenlijk? Zorg ervoor dat het aantal taken per persoon niet te hoog oploopt. Als members meer dan 5 taken hebben is er reden voor ongerustheid.

Sommige onderzoekers claimen namelijk dat met elke extra taak 20% tijd verloren gaat. Voorbeeld: als je 100% tijd hebt voor 1 taak, dan gebruik je bij 2 taken 40% per taak. Dan gaat 20% verloren aan taak switching. Bij 3 taken is al 40% verloren etc. etc. In mijn optiek zal het verliespercentage per persoon verschillen, maar dat er bij het omschakelen tijd verloren gaat zal iedereen direct herkennen.

Waarom is WIP nog meer belangrijk? Alle work items die nog niet klaar zijn leveren geen waarde voor de klant, team of organisatie!

Het tellen van kaarten en deze cijfers vastleggen wordt na een (start) periode vaak vervangen door een cumulatief flow diagram.

4. Blockers

Een van de Kanban Flow Metrics is Blockers. Tel hoeveel items er geblokkeerd zijn. Leg ook vast hoelang deze items zijn geblokkeerd. Met dit inzicht vind het team mogelijkheden om de flow te verbeteren. Het terugdringen van het effect dat Blockers hebben op flow verbetert de efficiency.

Als een item geblokkeerd is kan deze niet naar een volgende stap in het proces. Voorbeelden van Blockers zijn: een bottleneck, een defect, een afhankelijkheid of vaardigheden die niet beschikbaar zijn. Vaak zijn interne Blockers gemakkelijker op te lossen zijn dan externe Blockers. In de praktijk worden interne en externe blockers vaak in 2 verschillende kolommen geplaatst of door een andere kleur kaart weergegeven. Dit helpt om het management zo snel mogelijk de (externe) blokkade te laten verwijderen.

Hoe dan ook, je kunt niet verder als de Blocker niet wordt opgelost. Binnen Kanban vindt dan vaak ‘Swarming’ plaats. Dit bespreek ik in een ander artikel.

Hoe ga je om met Blockers?

Het is gebruikelijk om een Blocker direct aan te geven op de work item (vaak andere kleur).

Wat schrijf je op een Blocker?

• Startdatum blokkering
• Reden van blokkering
• Einddatum blokkering

3 tips voor Blockers

Sommige teams gooien, als de Blocker is opgelost, de Blocker notering weg. Als je ze echter bewaard kan je op zoek naar patronen in de achterliggende redenen. Je onderzoek naar de blokker bestaat uit 3 standaard elementen en 1 tip.

• Frequentie: hoe vaak zijn items geblokkeerd?
• Tijdsduur: hoelang blijven Blockers geblokkeerd (gemiddelde)
• Locatie: Waar in het proces komen Blockers voor?

Tip: Daarnaast leg je vast of er nog aanvullende informatie is om in de retrospective of futurespective te bespreken.

5. Throughput

Throughput is de hoeveelheid output van een proces in een gegeven tijdsperiode. Voorbeelden in een Kanban systeem: kaarten per dag, week, maand, story points per iteratie etc.

Omdat er een tijdsperiode is kan deze metric gebruikt worden met Cycle Time. Dan is de formule:

Throughput = WIP / Cycle Time

Werkwijze bij een Throughput per week.

Tel het aantal afgeronde(Done) workitems per week. Noteer deze elke week en kijk of er veranderingen optreden. Je voorspelt dan de toekomst op basis van een trendlijn in combinatie met Cycle Time en Lead Time.

Samenvatting

De vijf Kanban Flow Metrics dient elk team te beheersen. Het team kan besluiten dat andere metrics ook van belang zijn. Er zijn namelijk nog veel meer metrics. In een ander artikel zal ik nog meer Kanban Metrics beschrijven.

Het bericht 5 Kanban Flow Metrics verscheen eerst op agile4all.

De drumbeat van Kanban bestaat uit een cadans van een aantal meetings. Hier de beschrijving van zes Kanban meetings.

In het Engels heeft men het over cadances. Dit is in het Nederlands cadans of ritmiek. Vrij vertaald is het de ‘drumbeat’ van het Kanban Systeem. Zonder ritmiek functioneert ook het Kanban systeem minder goed.

De onderstaande zes meetings mogen worden toegepast, er is echter geen verplichting om deze in je workflow op te nemen. Verplichten past niet in de Kanban filosofie. Het vinden van goed werkende overlegstructuren is een integraal onderdeel van Kanban.

De waarde om onderstaande zes meetings te kennen is dat men ze ook pro actief en ad hoc kan toepassen, want niemand zit te wachten op een extra overleg die geen toegevoegde waarde levert.

Kanban en ritmiek 

Bij Kanban is de cadans niet zo streng voorgeschreven als bij Scrum. Bij Scrum bestaan er vaste regels voor de diverse activiteiten. Een paar Scrum voorbeelden: elke 2 weken een Sprint Planning, Sprint Review en een Retrospective etc.  Gezamenlijk zorgen ze voor een consistent Scrum framework om de productiviteit te verbeteren. Stel je nou eens voor dat je deze binnen Scrum op afroep zou doen, bijvoorbeeld alleen bij impediments, dan verwatert binnen afzienbare tijd de oplevering van het increment.

Kanban staat wel toe om de cadans aan te passen, andere regels te gebruiken, een andere ritmiek te hanteren. Dit is mogelijk  omdat Kanban niet ontworpen en gestructureerd is om binnen een iteratief schema te passen. Het gaat bij Kanban om de flow, Kanban is niet iteratief. Een voorbeeld: om de 3 weken een planning meeting op vrijdagmiddag, omdat dan de stakeholders beschikbaar zijn. Mag!

Dat het hanteren van een iteratie echter heel handig is zal overduidelijk zijn. Veel van de onderstaande meetings worden dan ook vaak met een vaste interval ingepland, maar binnen het Kanban Systeem staat nergens geschreven dat deze met vaste intervallen moeten plaatsvinden.

De 6 meetings van Kanban

De meetings van Kanban kan je het beste vergelijken met een drumstel. Alle meetings kunnen separaat ingezet worden, waarbij elke drum (meeting) een ander geluid maakt. Het ritme kan daardoor complex zijn, maar harmonieus.

Als je een meeting kiest is het verstandig om na te denken over transactie kosten. Transactie kosten zijn alle kosten die nodig zijn om een activiteit te doen. Een doel voor alle teams is kosten reductie door een verbetering in de cadans om sneller, betrouwbaarder en frequenter waardevolle producten te leveren. Dit is bouwen aan vertrouwen en transparantie.

De 6 meetings in een Kanban Systeem zijn:

1. Standup Meeting
2. Replenishment Meeting
3. Operations review
4. Delivery planning meeting
5. Service delivery review
6. Risk Review

1. Standup Meeting

De Kanban Standup richt zich op vragen als: wie werkt aan wat, wie heeft hulp nodig, zijn er items blocked? Het is de meest voorkomende meeting en het doel is dat het team elkaar informeert over de status van de werkitems.

De reden dat men het doel is dat de Standup Meeting een behoefte van het team vervult. Hoe plan ik mijn eigen tijd in? Wat speelt er allemaal? Feedback krijgen en geven. Mogelijk aanwezige Stakeholders zien wat er speelt en of en hoe ze kunnen bijdragen.

De vorm is volledig vrij. Vaak staat men om de meeting korte te houden. Men scant het Kanban bord van links naar rechts volledig, vooral gericht op blockers en bottlenecks. Er is heel veel ruimte voor innovatie. Vaak gaat een deel van het team direct na deze sessie met elkaar de diepte in om oplossingen voor bijvoorbeeld een Blocker te bespreken. 

2. Replenishment Meeting

Je kunt dit vergelijken met de Sprint Planning meeting van Scrum. Er zijn echter wezenlijke verschillen.

Het doel van deze sessie is prioritering van de input. Een pull systeem zal elke keer als er ruimte komt in het proces een item van de product backlog halen. In de replenishment meeting wordt bepaald welke prioriteiten er zijn. In Kanban zijn mogelijk meerdere stakeholders direct betrokken, deze dienen gezamenlijk mee te beslissen over de prioriteitstelling.

Het nodig om over de laatste marktinformatie te beschikken om goed te kunnen bepalen welke item(s) de meeste waarde toevoegt. Als de achterliggende informatie bekend is wordt gekozen wat er in de workflow zal worden opgenomen. Deze methode zorgt ervoor dat de belangrijkste items eerst worden gedaan. Door een transparante en frequente oplevering werkt men aan vertrouwen van stakeholders later in het proces. Men vertrouwd er dan op dat er met regelmaat het juiste wordt opgeleverd.

Het bijzondere van deze meeting is dat deze zowel elke dag als een keer per jaar kan plaatsvinden. Het enige wat echt telt is dat de juiste mensen de juiste beslissingen nemen op de juiste data. De frequentie wordt veelal bepaald door de snelheid van ontwikkeling, feedback loops, omgevingsvariabelen etc.

Deze meeting start soms ook als er te weinig werktaken in de backlog staan. Dit zal echter niet vaak gebeuren.

3. Operations Review

In een organisatie werken vaak meerdere teams, afdelingen en/of tribes gezamenlijk aan de totale ontwikkeling van de organisatie. De Operations Review is een meeting om alle neuzen dezelfde kant op te krijgen. In deze meeting kijken managers van diverse units naar het totale systeem.

Een ontwikkeling staat vrijwel nooit op zichzelf. Je kunt niet verbeteren als je geen rekening houdt met andere delen van de organisatie. Een enkel team kan niet de hele flow van een niet goed functionerende organisatie goed maken. De meeste efficiency problemen vindt je in een handover situatie tussen verschillende units.

Wat je hiervoor nodig hebt is eigenlijk de informatie van alle voorgaande meetings. Op basis van deze informatie besluit het team waar de prioriteiten liggen om de efficiency in de hele flow te verbeteren.

4. Delivery Planning Meeting

In deze meeting gaat het specifiek om het oplossen van problemen tussen de diverse afdelingen. Het is nu eenmaal een feit dat de meeste afdelingen geen contact hebben met de finale afnemer of klant. De klant heeft vaak wensen over hoe, wanneer en wat er geleverd wordt. De meeste klanten stellen het zeker niet op prijs als er zonder overleg een levering plaatsvindt, overleg is vrijwel altijd noodzakelijk.

Op basis van het Kanban Bord valt vrij goed te voorspellen wanneer er een levering kan plaatsvinden. Een goed moment om dit te bepalen is de (daily) Standup Meeting. Met de input van de deelnemers die gaan afleveren kan een zorgvuldige WIP afgestemd worden. Daartoe kunnen prioriteiten verschuiven. Binnen Kanban bestaat zelfs de mogelijkheid om zo een levering van standaard naar ‘time based’ te veranderen. Zodra er in Kanban een deadline is dient een team zijn pull aan te passen en er voor zorg te dragen dat de deadline gerealiseerd wordt.

5. Service Delivery Review

In deze meeting wordt de levering bekeken vanuit het oogpunt van de klant of te belanghebbenden van de service. Het enige doel is de klanttevredenheid te verbeteren door vertrouwen te creëren door transparant te zijn.

Als een klant ontevreden is over de geleverde dienst is het helemaal niet meer belangrijk hoe goed het interne proces is geweest. Het gaat om alles waar de klant belang bij heeft, men betrekt dus medewerkers met direct klantcontact.

Je bekijkt de laatste levering, kwaliteit, SLA’s, tevredenheid, frequentie van levering, tijdige levering. Maar ook hebben we er alles aan gedaan om de beloofde of verwachte waarde te leveren of zelfs te overtreffen.

Als het fout is gegaan hebben we dan goed gecommuniceerd, hebben we eventuele belemmeringen tijden en juist opgelost. Kortom, weten we zeker dat we alles hebben gedaan om toekomstige risico’s te minimaliseren.

6. Risk Review

Deze meeting staat in het teken van falen. Het doel is de faal mogelijkheden te onderzoeken. Waar kan het fout gaan en wat gebeurt er als er iets fout gaat met componenten/afdelingen/eindgebruikers later in de flow. Deze meeting draait dus om vertrouwen en winst. Het voorkomen van fouten levert kostenbesparingen en/of inkomsten.

De makkelijkste manier om Risk Review te doen is het bekijken van fouten uit het verleden. Bekijk de blocked tasks, re-works, klachten etc. en zoek naar patronen die opgelost kunnen worden. Een andere mogelijkheid is dat men een brainstorm houdt om te speculeren over toekomstige problemen. Hoe meer disciplines hierbij betrokken zijn hoe groter de kans dat er interessante inzichten ontstaan. Andere complexere methodes zijn ook mogelijk, maar dat gaat te ver voor dit artikel.

Het resultaat van deze meeting is een betere aansluiting bij de verwachtingen in de markt. Hoe vaak deze meeting plaatsvind is volstrekt afhankelijk van de ontwikkelingen in de markt en de organisatie.

Samenvatting

Dit zijn de zes bekende en vaak toegepaste Kanban meetings. Binnen Kanban is er volop ruimte om eigen vormen te bedenken die goed passen bij de workflow in de organisatie en de klant. Het aantal mogelijkheden is groot, wellicht zijn er in jouw organisatie hele andere meetings.

Wat nog een interessante review is de Strategy Review. De Strategy Review is een populaire meeting voor o.a. hoger management en marketing managers. Het onderwerp is het zich afvragen of de huidige doelen nog goed aansluiten bij de behoeften van de klant. Het gaat hier niet meer of je het goed doet, maar of je het juiste doet. Past de strategie nog bij de marktontwikkelingen? De echte vraag is dus of de bedrijfsstrategie en de processen passen bij het strategische doel. 

Alle bovenstaande 6 meetings hebben namelijk weinig nut als een organisatie niet het juiste doet.

Het bericht De 6 Kanban meetings verscheen eerst op agile4all.

Kanban is een framework om een optimale flow in het werkproces te bereiken. De belangrijkste doelen zijn: je sneller kunnen aanpassen aan de markt en sneller kunnen produceren of opleveren. Met de flow wordt alles bedoelt wat in het (productie)proces een rol speelt: materialen, informatie etc.

De basisgedachte van Kanban is dat de Kanban methode binnen Lean productieprocessen kan worden ingezet om voorraden zo klein mogelijk te houden en een minimale Work in Progress (WIP) te bereiken. Just-in-time (JIT) . De begrippen en de voordelen worden later in dit artikel uitgelegd.

Kanban is een van de agile methodes, voor een totaaloverzicht verwijs ik je naar het artikel Wat is agile?

4 betekenissen van Kanban?

Wat best verwarrend is dat er meerdere mogelijkheden zijn om het woord Kanban te beschrijven.  Het is niet altijd direct duidelijk waar men het over heeft. Men gaat zover dat men claimt dat de schrijfwijze van het woord Kanban bepaald wat er bedoelt wordt. Grofweg hanteert men de volgende 4 mogelijkheden:

kanban, kanban systeem, Kanban Methode en Kanban Framework

• het gebruik van signaal kaarten of virtuele kaarten (kanban)
• het kanban systeem (pull systeem met signaal kaarten of virtuele kaarten)
• De Kanban Methode waarbinnen een agile team werkt. (Kanban Methode en Kanban Framework)

Het gaat mij wat ver om kleine letters of hoofdletters te laten bepalen waar je het nu precies over hebt. Waar het mij om gaat is dat er ruis in de communicatie kan ontstaan als er verschillende gedachten bestaan.

Door te weten dat er meerdere interpretatie mogelijkheden zijn voorkom je dit. In dit artikel zal ik mij verder niet bezig houden met grote en kleine letters voor Kanban.

Waar komt Kanban vandaan?

De bedenker van het Kanban systeem is Taiichi Ohno. Hij schreef in zijn boek Toyota Production System het volgende: 

‘The two pillars of the Toyota production system are just in time and automation with a human touch, or autonomation. The tool used to operate the system is Kanban.’

Kanban is oorspronkelijk bedoeld voor een productieproces van auto’s, maar de huidige methode is echter vooral bekend geworden door David J. Anderson met zijn boek: Kanban. Zijn benadering van Kanban voor de technologie business bleek een schot in de roos.

Wat je vooral zag was dat Kanban werd opgepikt door softwareontwikkelaars. In 2004 startte Microsoft namelijk met een virtueel Kanban systeem voor software ontwikkeling. De tool bleek bij uitstek geschikt om de voortgang in complexe it-processen goed te volgen. Het Kanban framework is inmiddels niet meer weg te denken als middel om een optimale flow in een proces te bewerkstelligen.

kanban

Het woord kanban is Japans voor Visueel kaart of Signaal kaart.

• kan = visueel of signaal
• ban = kaart of bord

Het belangrijkste uitgangspunt is dat elk werkitem een aparte kaart is op het bord.

Het belangrijkste doel van een kaart op het kanban bord is het visueel maken van de voortgang van het proces door de teamleden. Op elke Kanban kaart staat de belangrijkste informatie. Je kan dan denken aan een korte beschrijving, wie de taak heeft, hoeveel tijd er voor gepland staat etc.

Wat er op staat is vaak een teambeslissing, maar de eerstvolgende in het werkproces moet wel met de kaart verder kunnen. Er moet dus voldoende informatie op staan om processtappen te kunnen maken.

Teamleden kunnen op elk moment de voortgang beoordelen en daar iets van vinden. Kortom, de kaart bevat alle informatie om focus, volgtijdelijkheid, identificatie, blokkades en afhankelijkheden in één oogopslag te zien.

Kanban Systeem, Kanban Methode

Het systeem gaat over het inzetten van een pull systeem met signaal kaarten en de Kanban Methode of Kanban Framework gaat over het gehele werkproces.

Voorbeelden

Het Kanban systeem is op heel veel plekken ingevoerd en als klant heb je vaak geen idee welk proces er achter de schermen plaatsvindt. Het is leuk om direct wat voorbeelden aan te dragen, in onderstaande voorbeelden wordt het Kanban in meer of mindere mate gebruikt,.

Supermarkt

Het oorspronkelijke Kanban model gebaseerd is op het supermarktmodel. Dat is ook de makkelijkste manier om in hoofdlijnen de gedachte uit te leggen.

Supermarkten hebben niets aan een overdaad aan producten in het magazijn. In feite is alleen wat in het schap staat of ligt verkoopbaar. Waar je naar op zoek bent is dat er flow ontstaat tussen de vraag van de consument en aanbod in de supermarkt. Dat betekent dat er een flow van in- en uitgaande producten moet zijn. Efficiency in voorraadbeheer draagt zorg voor lagere voorraden op elk moment. Daardoor is een product vrijwel altijd in voorraad.

Een goede flow is een Kritisch Succes Factor om aan de klantvraag in een concurrerende markt te voldoen. Dat is een deel van het Kanban systeem wat je, als je boodschappen doet, kan waarnemen.

Fastfood keten

Burger King, KFC en Mc Donalds zijn andere mooie voorbeelden. Ik heb het nu even alleen over het deel waar de klant mee produceert in het kanban proces. Het voorbeeld is een bestelling bij de Drive of via de zuil. Zie dat eens als een kanban bord.

• Backlog: aanbieden keuzemogelijkheden,
• Selected: oppakken op basis van de klantkeuze,
• Doing: product bereiden,
• Done: product is klaar,
• Oplevering: verstrekking aan de klant. 

Alle bestellingen worden op volgorde afgehandeld. Just-in-time. Wat hierbij interessant is dat alle voordelen benoemd in dit artikel direct herkenbaar zijn.

Agile software ontwikkeling.

Eerst nog wat theorie: Kanban is een populair framework waarbij het bord een directe communicatie over de capaciteit en transparantie in het onderhanden werk verschaft. Op het kanban bord kunnen teamleden de status van elk  werk altijd en compleet overzien. Heel herkenbaar voor iedereen die al agile werkt. Ook als je nu werkt met andere frameworks.

Kanban heeft een enorme ontwikkeling doorgemaakt in agile software ontwikkeling. De reden hiervoor is simpel. Het is namelijk eenvoudig om kaartjes en een bord te hanteren. Het maakt zelfs niet uit of deze fysiek of virtueel zijn. Je hoeft alleen de basics te begrijpen en je kunt starten.

Bij agile softwareontwikkeling werkt Kanban in grote lijnen als volgt. Om de enorme hoeveelheid klantwensen en systeemeisen overzichtelijk te maken wordt elk stuk werk op een signaal kaart gezet. Afhankelijk van de capaciteit wordt o.b.v. prioriteit een kaart in circulatie gebracht.

Het team maakt afspraken hoeveel kaarten er mogen zijn in een deelproces. Pas als er ruimte is voor een nieuwe kaart wordt een nieuwe kaart opgepakt en in circulatie gebracht. Daarna volgt het proces: de kaart volgt de flow. Als het werk klaar wordt de kaart uit het systeem gehaald en gerecycled. De volledige werkmethode zal ik in een ander artikel zeer uitgebreid toelichten.

Helaas is er een veelheid aan benamingen. Er zijn 3, 4 en 5 foundations of principes. Die zijn weer verder te onderbouwen met de basis praktijken en daar zijn dan weer veel toevoegingen op. Wat de één een foundation noemt is voor de ander weer een basis praktijk, helaas worden de benamingen ook weer door elkaar gebruikt.

Ik kies ervoor om eerst de 3 ‘echte’ foundations te benoemen, maar omdat ik een later toegevoegde vierde ‘foundation’ persoonlijk een interessante benadering vind beschrijf ik deze als vierde foundation.

3 Kanban foundations

De fundering is gelegd met de volgende Kanban foundations:

1. Start met wat je weet
2. Bereik overeenstemming dat je gezamenlijk kiest voor incrementele evolutionaire verandering.
3. Respecteer het huidige proces, rollen, verantwoordelijkheden en titels.

1. Start met wat je weet

Wat je veel ziet is dat bij kiezen voor een nieuwe werkmethode geadviseerd wordt om alles anders te doen. Niet bij Kanban, bij Kanban kiest men voor een evoluerend proces. Er is geen big bang, er is geen grote ‘we doen nu ALLES anders’. Er is zelfs geen Kanban project of project managementmethode. Je start met wat je weet.

2. Bereik overeenstemming

Bereik overeenstemming dat je gezamenlijk kiest voor incrementele evolutionaire verandering. Dus Commitment.

Het team of de organisatie kiest voor een geleidelijk en zachte verandering. De redenen hiervoor zijn het voorkomen van weerstanden bij de medewerkers, maar ook het management. Het risico voor individuen wordt zo klein mogelijk gehouden. Het belangrijkste is dat er overeenstemming is dat een behoedzame, evolutionaire en incrementele benadering plaats gaat vinden. Als dit niet mogelijk is, dan is er helaas geen ruimte voor een Kanban intitiatief.

3. Respecteer het huidige proces, rollen, verantwoordelijkheden en titels.

Dit is binnen de Angelsaksische managementgedachte bijna ondenkbaar, het is dan ook van oorsprong een oosterse managementdenkwijze.

Respect voor wat er is komt voort uit de gedachte dat er allerlei zaken zullen zijn die het waard zijn om te behouden. Een van de belangrijkere drivers achter deze gedachte is om de angst voor verandering te minimaliseren.

Soms wordt een introductie van Kanban in de organisatie als nieuwe methode bewust tegenover een ‘harde’ verander methodiek geplaatst om de voordelen voor betrokkenen nog duidelijker te maken.

Bovenstaande foundations zijn de oorspronkelijke foundations en zijn ruim voldoende voor het Kanban Framework. De ontwikkeling en mogelijke veranderingen komen dan vanzelf, mits de juiste begeleiding er is. En dat is de reden waarom een aantal partijen een 4e foundation hanteren.

De 4e foundation: leiderschap

Nogmaals de bovenstaande 3 foundations zijn ruim voldoende voor het Kanban framework! En worden gezien als de ‘echte’ foundation principes. Maar, …

Het begeleiden van de verandering wordt door sommigen als vierde foundation gezien. De stelling is dat alle leiderschapsniveaus in een organisatie kunnen bijdragen aan het succes van Kanban. Men heeft het dan over begeleiden van management en andere betrokkenen. Door een facilitator, Kanban Coach, Agile Coach of een teamlid.

Kortom, men is er vrijwel altijd over eens dat ook een zachte verandering goed begeleid moet worden. Daarom hanteren een aantal partijen een vierde foundation: Het begeleiden van ‘Leiderschap op alle niveaus’.

In mijn optiek is de vierde foundation een onderdeel van de 5 core practices, die hierna beschreven worden. Toch kan ik mij goed voorstellen dat in een aantal organisaties de aandacht voor het begeleiden van leiderschap op alle niveaus zo belangrijk is dat men het als een aparte foundation wil neerzetten.

Als er gebruik wordt gemaakt van bovenstaande 3 foundation principles van Kanban dan adopteer je daarna de 5 core practices van Kanban.

Gebruik de 5 core practices (kernwaarden)

Onderstaand de 5 kernwaarden van Kanban:

1. Visualiseer de werkstroom
2. Limiteer het onderhanden werk (WIP- Work-in-Proces)
3. Help met de flow van het werk.
4. Maak procesafspraken expliciet
5. Verbeter samenwerking, door modellen en wetenschappelijke methoden te gebruiken.

1. Visualiseer de Workflow

Agile werken kenmerkt zich door het inzetten van visuele middelen, waardoor betrokkenen direct de status van het werk kunnen aflezen. In de Kanban methode gaan we uit dat het afronden van het werk in elke processtap inzichtelijk dient te zijn. Het pull systeem vraagt om afronden van processtappen om een eindstadium te kunnen bereiken. Het onderhanden werk is dus altijd inzichtelijk.

We kijken met name naar de (mogelijke) veranderingen, belemmeringen, waste en we analyseren als de situatie daarom vraagt. Het gaat dus om adequate en punctuele informatie. Dat klinkt heel mooi, maar dat zal ik later in een ander artikel tonen.

2. Limiteer WIP

Het limiteren van het onderhanden werk kan voor delen of de gehele workflow gelden. Er zijn tegenwoordig meerdere technische varianten om ‘pull’ aan te sturen. Het belangrijkste is en blijft dat er goed gekeken wordt naar de gestelde limieten en dat nieuwe informatie leidt tot het naar binnen halen (pull) van nieuw werk. De mogelijke ruimte in de workflow dient volledig te worden benut. Dit vraagt om continue zoeken naar de optimale WIP limit.

3. Help met de Flow

Het meten van de flow is een standaard activiteit, je beoordeelt of de bewegingssnelheid van één of meerdere work items snel en foutloos door het proces verloopt. Men beoordeelt  ook of de flow wel volgens de verwachting verloopt. Hierdoor worden risico’s verkleind, snel waarde gecreëerd, kosten beperkt en vertragingen voorkomen.

4. Maak procesafspraken expliciet

Hier streef je naar één doel: een rationele empirische objectieve discussie over issues. Als het niet helder is hoe dingen werken krijg je niet de juiste discussies. Dan verzand je in emotionele, subjectieve of anekdotische discussies. Dit laatste helpt een team niet verder bij het oplossen van issues.

Anderson noemt in zijn boek 3 wetenschappelijke methodes:

• Theory of Constraints (the study of bottlenecks)
• Theory of Profound Knowledge (a study of variation and how it affects processes);
• Lean Economic Model (based on the concepts of “waste” or muda, muri and mura).

Andere modellen zijn mogelijk zoals bijvoorbeeld de Real Option Theory.

Het gebruik van wetenschappelijke bewezen modellen leidt tot een beter leertraject, voor zowel de teamleden als de lerende organisatie. Wat je observeert is dat het gebruiken van een wetenschappelijk onderbouwd model leidt tot een voorspelling, of het inderdaad een verbetering te verwachten is, die daarna gemeten kan worden. Je meet de flow, voor en na de verandering. Is er daadwerkelijk een verbetering? Of niet? Emperisch denken en handelen hoort nu eenmaal bij agile werken. 

5. Verbeter samenwerking

Bij samenwerken praat je feitelijk altijd over de WIP limit! Dat lijkt raar als je het hebt over samenwerking, maar de WIP limit is vrijwel altijd het vertrekpunt. Elke verstoring van het proces heeft direct impact op de WIP limit. Een team heeft slechts een paar keuzes: de WIP-limit veranderen, het probleem negeren of de uitdaging aangaan en het probleem met elkaar bespreken.

Hier komt ‘maak procesafspraken heel expliciet’ heel nadrukkelijk naar voren. Als een team met elkaar erover eens is hoe dingen werken, zoals werk, workflow, proces, risico’s en verbeter opties en -modellen dan kunnen er gezamenlijk gedragen verbetervoorstellen worden bedacht.

Voor het laatste punt verwijs ik naar bovenstaande beschrijving van de 4e foundation, ik kan de geschreven alinea hier herhalen maar dat heeft geen zin. Zoals eerder aangegeven hoort begeleiding van het proces volgens mij bij de core practices!

Verschillen in teams, projecten en organisaties

Waarom is Kanban niet de zoveelste projecten methode? Om te beginnen is het geen projecten methode, maar een agile methode. Maar dat zal je inmiddels al duidelijk zijn.

Toch is het interessant om in hoofdlijnen te beschrijven waarom ‘one size fits all’ ontwikkelmethodes niet werken. Waarom projecten vaak spaak lopen en waarom Kanban maatwerk is. Dit kan ik wellicht het beste uitleggen aan de hand van de verschillen in teams, projecten en organisaties.

Teams beschikken over verschillen in:

• vaardigheden of vaardigheidsets
• ervaringsniveaus
• en bekwaamheden.

Projecten hebben verschillende:

• budgetten
• schema’s
• scope
• en risicoprofielen.

Organisaties hebben verschillende:

• Waardeketens
• Marktdoelstellingen.

5 Software principles

Voor software ontwikkeling  hanteert men de volgende basisprincipes:

Limiteer Work-in-Proces (WIP) en pak werk op als het team capaciteit heeft. De klantvraag is hierbij leidend.

Trek waarde door het proces met behulp van een WIP limit. Alleen werk wat klaar is heeft waarde. Door een WIP limit te hanteren gaat het proces sneller en maximaliseer je de waarde.

Visuele controle is noodzaak, dus gebruik je een transparante methode om het werk te bekijken en te organiseren.

Verbeter throughput. Zorg ervoor dat  de flow optimaal is.

Verbeter samenwerking. Kwaliteit is in het proces opgenomen en geen aparte inspectie. Het team volgt op continue basis alle principes en verbetert de werkflow.

Waar moet Kanban aan voldoen?

If there is no explicit limit to work in progress and no signaling to pull work through the system it is not a Kanban system.

David J. Anderson

Een aantal voordelen van Kanban

De gekozen voordelen gelden zowel voor organisatie en teams:

• Het helpt organisaties in het verlagen van de kosten.
• Er ontstaat een organisatie die snel kan reageren op verandering
• Het faciliteert methoden voor kwaliteitsverbetering
• Flexibiliteit in planning, geen vaste iteraties zoals bij Scrum
• Minder bottlenecks, er zit gewoonweg minder in de flow.
• Continues Delivery, opleveren is noodzaak om ruimte in het proces te creëren
• Visuele metrics, zoals kanbanbord, -kaarten, wip, metrics etc.
• Aanpassingen in klantvraag worden sneller doorgevoerd door de korte Cycle time.
• Het team heeft geen onbelangrijke zaken meer.
• Teams kunnen groeien naar high performing teams. De feedback loops zorgen voor gemotiveerde en betrokken teamleden.

Samenvattend: Kanban is een complex adaptief systeem

De 3 principes van de Kanban methode legt de basis voor een organisatie die Kanban gebruikt om te veranderen.

De grote onzekerheid is wat de uitkomst is, deze is niet te voorspellen. Het enige wat redelijk zeker is dat er verandering zal gaan plaatsvinden.

Dit systeem kan alleen werken als voornoemde 5 kernwaarden worden gehanteerd. Een continue proces van veranderen en het tweaken van verandering komt tot stand door WIP limits en workflow visualisatie aan te passen. Je bent vanaf de start met Kanban altijd op zoek naar een betere uitkomst.

Dat noem je een complex adaptief systeem.

Tot slot

Zoals je hebt kunnen lezen is Kanban inzetbaar op verschillende gebieden. Kanban is een vaak gehanteerde methode. Ik zal meerdere artikelen over Kanban gaan schrijven. Onderstaand een paar links naar andere artikelen.

De zes Kanban meetings , 5 Kanban Flow Metrics , Push vs Pull systemen

Het bericht Wat is Kanban? verscheen eerst op agile4all.