Waarom Kanban werkt — en hoe je weet of je team er klaar voor is

De meeste teams nemen Kanban aan omdat iemand een blogpost las. De slimmere vraag is of de problemen die Kanban oplost daadwerkelijk de problemen zijn die uw team heeft.

Er is een moment dat de meeste teams herkennen, meestal rond het moment dat ze meer dan acht of negen mensen hebben. Werk wordt gedaan — e-mails worden verzonden, functies verschepen, klanten worden beheerd — maar niemand heeft een duidelijk beeld van wat iedereen anders doet. Projecten stapelen zich op. Dingen worden beloofd en dan stilletjes vergeten. U besteedt twintig minuten voor elke vergadering om uit te zoeken waar een stuk werk werkelijk is. Het antwoord is meestal "ergens".

Dat is het probleem waarvoor Kanban is ontworpen. Niet het probleem van het bepalen van strategie, of het inhuren van de juiste mensen, of het opbouwen van een cultuur — maar het specifieke, slepende operationele probleem van weten wat uw team aan het doen is en wat in de weg zit.

Het is een verrassend bescheiden tool voor iets dat zoveel aandacht heeft getrokken. Kanban claime niet uw organisatie op te lossen. Het maakt werk zichtbaar. En het blijkt dat zichtbaarheid, consistent toegepast, een opvallend aantal dingen downstream verandert.

Waar Kanban werkelijk vandaan komt

Het woord is Japans — het betekent "bord" of "uithangbord" — en het systeem is in de late jaren 1940 door Toyota ontwikkeld als een manier om voorraden in hun fabrieken te beheren. Het idee was eenvoudig: in plaats van onderdelen op een vast schema te produceren, zou de fabriek ze alleen produceren wanneer een stroomafwaarts station signaleerde dat het ze nodig had. Een fysieke kaart — de kanban — zou naar boven gaan als een verzoek. Niets werd speculatief gemaakt. Niets hoopte zich onnodig op.

Het inzicht dat Toyota had, en dat softwareteams later leenden, is dat de meeste inefficiëntie in een systeem niet voortkomt uit mensen die te langzaam werken, maar uit het verkeerde werk dat op het verkeerde moment wordt gedaan. Te veel dingen tegelijk gestart. Knelpunten die niemand opmerkt totdat het te laat is. Werk dat klaar zit op één plaats terwijl de volgende stap ergens anders wordt overweldigd.

Softwareontwikkelaars, met name in bedrijven zoals Microsoft in het begin van de jaren 2000, begonnen deze ideeën voor kenniswerk aan te passen. De kaarten werden taken. De fabrieksstations werden stadia in een workflow. En het bord werd een board — fysiek eerst, dan digitaal — waar iedereen op het team in één oogopslag kon zien wat in uitvoering was, wat wachtte en wat klaar was.

Wat een Kanban-bord eigenlijk toont

Een basis Kanban-bord heeft drie kolommen: To Do, In Progress, en Done. Dat is voldoende voor veel kleine teams en een prima plaats om mee te beginnen. Maar de echte waarde ontstaat wanneer u die stadia begint aan te passen aan hoe uw werk werkelijk stroomt — niet hoe u wenst dat het zou stromen.

Een inhoudssteam kan gebruiken: Idea, Brief, In Draft, In Review, Scheduled, Published. Een softwareteam kan "In Progress" opsplitsen in aparte kolommen voor development, code review en QA. Een consulterend team kan Discovery, Proposal, Active, Awaiting Client en Closed volgen. De fasen moeten echte handoffs en echte wachttijden weerspiegelen — plaatsen waar werk van hand verandert, of waar het zit totdat iets anders gebeurt.

Let op de kaart in de middelste kolom — het magazijninspectatierapport, acht dagen in, gemarkeerd als geblokkeerd. In een systeem zonder bord, die taak zou nog twee weken kunnen zitten voordat iemand zich realiseert dat het niet beweegt. Iemand wacht op een derde partij. Of er is een beslissing nodig van een manager die niet weet dat zij de blocker zijn. Het bord maakt de blokkade zichtbaar. Dat is het meeste werk.

De regel die het werkend maakt: WIP-limieten

Als er één concept is dat teams scheidt die Kanban correct gebruiken van teams die gewoon een mooiere takenlijst hebben, zijn het work-in-progress limieten — WIP-limieten kortom. Het idee is dat elke kolom een maximaal aantal items heeft dat er tegelijk kan zijn. Wanneer een kolom vol is, kunt u niet meer werk toevoegen totdat iets eruit gaat.

Dit voelt contra-intuïtief. Stel, in staat zijn om meer taken in uitvoering te zetten betekent meer wordt gedaan? Dat is het niet. Wat werkelijk gebeurt als mensen tegelijk aan te veel dingen werken, is dat alles langer duurt. Context switching is duur. Half afgewerkt werk creëert coördinatieoverhead. En als tien dingen "in voortgang" zijn, is het erg moeilijk om te zien welke daadwerkelijk bewegen en welke gewoon vast zitten maar niet zijn gemarkeerd.

Een WIP-limiet van drie in uw In Progress kolom betekent dat wanneer het vierde ding op iemands bureau aankomt, iemand op het team een beslissing moet nemen: welke bestaande taak is eerst klaar? Het forceert prioritering. Het forceert gesprek. En het produceert meestal sneller completion van afzonderlijke items, zelfs als het tempo van het starten van nieuwe items vertraagt.

Kanban versus Scrum: de vraag die teams altijd stellen

Als u enige tijd rond softwareteams of modern operational thinking hebt doorgebracht, bent u waarschijnlijk Scrum tegengekomen — het framework dat werk in vaste twee-wekse sprints organiseert, met plannningssessies, retrospectief en gedefinieerde rollen zoals Scrum Master en Product Owner. Veel teams beschouwen Scrum en Kanban als concurrerende methodologieën en voelen zich gedwongen om te kiezen. Het onderscheid is eigenlijk eenvoudiger dan dat.

Veel teams — vooral die geen zuivere software engineering teams zijn — vinden Scrum's ceremonieel zwaar en de vaste-sprint structuur moeilijk toe te passen op doorlopend operationeel werk. Marketing teams, customer success teams, operaties teams en oprichters die alles beheren, hebben zelden werk dat netjes in twee-wekse cycli past. Kanban's continue flow model past beter bij hen.

Dat zei dat veel teams beide combineren. Ze gebruiken sprint-stijlplanning cycli voor productontwikkeling terwijl ze een Kanban-bord draaien voor het operationele en ondersteuningswerk dat binnenstroomt ongeacht welke sprint u bent. Dat is een volkomen redelijke hybride.

De drie vragen die uw bord in dertig seconden moet beantwoorden

Een Kanban-bord is het handigst als u ernaar kunt kijken en zonder met iemand te spreken snel antwoord kunt geven op deze drie vragen: Waar werkt het team momenteel aan? Waar raakt werk vast? Zit er iets dat moet worden gedaan dat niet is gestart?

Als u niet binnen dertig seconden na kijken naar het bord allemaal drie kunt beantwoorden, wordt het waarschijnlijk niet goed onderhouden. De meest voorkomende fout is een bord waar taken worden gemaakt maar nooit verplaatst — het wordt een kerkhof van goede bedoelingen in plaats van een live kaart van werkelijk werk. Een bord dat niet actueel is, is erger dan geen bord, omdat het een vals gevoel van zichtbaarheid creëert.

De discipline die nodig is om een bord te onderhouden is echt. Taken moeten verplaatsen wanneer het werk verplaatst. Geblokkeerde items moeten onmiddellijk worden gemarkeerd, niet twee weken later. Kaarten moeten duidelijke eigenaren hebben, en eigenaren moeten hun kaarten bijwerken. Niets hiervan vereist veel tijd — een goed uitgevoerde Kanban praktijk kan vijf tot tien minuten per persoon per dag duren — maar het vereist consistentie. De teams die het meeste baat hebben bij Kanban zijn degenen die het bord als de bron van waarheid behandelen, niet als een aanvullende administratieve oefening.

Wat Kanban niet doet

Kanban is geen strategisch hulpmiddel. Het helpt u niet om uit te zoeken wat u moet doen — alleen het beheren van wat u al hebt besloten te doen. Als uw organisatie een prioriteitsprobleem heeft, of een onduidelijk mandaatprobleem, of een "we starten te veel projecten voordat oude klaar zijn" probleem geworteld in leidersgedrag in plaats van process, zal een Kanban-bord die problemen onthullen maar niet oplossen.

Het is ook geen vervanger voor goed management. Een bord vervangt geen one-to-ones, of doordachte delegatie, of duidelijke communicatie over waarom bepaald werk belangrijk is. Teams nemen soms processtools aan in de hoop dat het proces het relationele en organisatorische werk doet dat werkelijk de taak van de manager is. Dat zal het niet doen.

Wat het zal doen is de omgevingszekerheid verminderen die de meeste teams vertragen. De vragen van "wie werkt aan wat," "is dit gedaan," en "wat zou ik volgende kunnen oppikken" genereren enorme hoeveelheden lage waarwaarschijnlijke communicatie in organisaties die geen gedeeld, zichtbaar systeem hebben. Kanban elimineert het meeste van die ruis. En voor teams waar die ruis het dominante probleem is, is het verschil significant.

Hoe te beginnen — zonder een driedaagse workshop

De beste Kanban-implementaties die ik heb gezien, begonnen klein en evolueerden. De slechtste betrokken een consultant, een twee-daagse offsite, en een mooi ontworpen bord dat niemand tegen week drie gebruikte.

Begin met uw team zoals het werkelijk is, met het werk dat u werkelijk hebt. Maak drie kolommen: Backlog, In Progress, Done. Besteed dertig minuten met uw team om elk huidig werkitem op een kaart te zetten. Ga ermee akkoord met één regel: wanneer u iets begint, gaat het op het bord. Wanneer het beweegt, verplaatst u de kaart. Doen niets anders gedurende twee weken.

Na twee weken, kijk samen naar het bord. Waar stapelden dingen op? Wat bleef in Backlog dat iedereen zei was een prioriteit? Wat bewoog sneller dan verwacht? Wat zat vast en waarom? Gebruik wat u observeert om de kolommen te verfijnen en specifieke toe te voegen. Misschien moet "In Progress" zich splitsen in "In Progress" en "Waiting on External." Misschien hebt u een kolom nodig genaamd "In Review" omdat die stap blijft verloren gaan. Laat het bord evolueren in reactie op wat uw werkelijke werk onthult, niet in reactie op wat een methodologieboek zegt dat het zou moeten uitzien.

Het langere spel: stroommetriek

Zodra een Kanban-systeem draait, genereert het gegevens die de meeste teams nooit gebruiken. Lead time — de totale tijd van wanneer een taak wordt gemaakt tot wanneer deze is voltooid — is het belangrijkste. Als uw gemiddelde lead time voor een typische taak twaalf dagen is, en u wilt het vijf, hebt u nu een getal om tegen te werken en een bord dat laat zien waar die extra zeven dagen heen gaan.

Cycle time meet alleen de actieve werkperiode, exclusief de tijd dat een taak in de backlog zit. Doorvoer meet hoeveel items uw team per week voltooit. Geen van deze metriek vereist speciale software als u gedisciplineerd bent over het noteren wanneer kaarten worden gemaakt en wanneer zij sluiten. En samen geven zij u een veel eerlijker beeld van uw team's capaciteit dan elk op schatting gebaseerd planningsproces kan.

De meeste kleine en middelgrote teams komen hier nooit. Ze gebruiken Kanban als een zichtbaarheidstool — wat op zichzelf waardevol is — en gaan niet verder. Dat is prima. Maar als u merkt dat u zich aan stakeholders moet verbinden over wanneer iets klaar zal zijn, of wil begrijpen waarom sommige werk drie keer zo lang duurt als verwacht, zijn de metriek hier wanneer u ze nodig hebt.