看板 — Uithangbord
Kanban (看板) is Japans. De karakters verdelen als: 看 (kan), kijken, zien, & 板 (ban): bord, plank, uithangbord. Samen: een visueel signaal bord.
Het woord is veel ouder dan het managementsysteem. Elke winkel in het Edo-periode Japan had een kanban: een houten uithangbord buiten dat aankondigde wat erin werd verkocht. Het visuele signaal was de advertentie, de voorraadmeter, & de bestelimpuls allemaal tegelijk.
Taiichi Ohno's Supermarktinzicht
In de jaren 1950 bezocht Toyota-ingenieur Taiichi Ohno Amerikaanse supermarkten. Wat hij zag veranderde de geschiedenis van de fabricage.
In een traditionele fabriek, het push-model, liep de productie volgens een schema. Een voorspelling zei "we hebben volgende maand 500 eenheden nodig," dus de fabriek maakte 500 eenheden & duwde ze naar een plank. Als de vraag fout was, stroomde de plank over. Als de vraag de voorspelling overtrof, was de plank leeg. Hoe dan ook, iemand had ongelijk.
Supermarkten werkten anders. Planken hielden een vaste hoeveelheid van elk artikel. Toen een klant de laatste pot pindakaas nam, was het lege vak zelf het bestelsingaal. Voorraadmedewerkers hoefden niet op een manager te wachten om te zeggen dat ze moesten bijbestellen: de plank zei het. Dit is het pull-model: stroomafwaartse vraag signaleert stroomopwaarts aanvulling.
Ohno bracht dit inzicht terug naar Toyota. De fysieke kaart (kanban) bevestigd aan een bak onderdelen werd het signaal: "deze bak is leeg: produceer meer." Geen voorspelling nodig. Geen centrale planner. Het werk trok zichzelf naar voren.
Push versus Pull
Het push/pull onderscheid is de basis van alles wat volgt.
Kolommen als Staten
Een kanban-bord maakt werk zichtbaar. Elk stuk werk is een kaart. Kaarten bewegen van links naar rechts door kolommen die staten vertegenwoordigen.
De klassieke kolommen zijn: Backlog → Geselecteerd → In Uitvoering → Beoordeling → Gereed
Maar de exacte kolommen doen er niet toe. Wat telt is dat elke kaart precies één huidige staat heeft, & die staat zichtbaar is voor iedereen die in dat systeem werkt.
Wat een kaart vertegenwoordigt
Een kaart vertegenwoordigt een stuk werk dat onafhankelijk kan worden voltooid. Geen project. Geen doel. Een specifiek, afgebakend iets met een duidelijke definitie van gereed.
Goede kaart: SSH-sleutels op productieservers roteren: klaar wanneer alle servers de nieuwe sleutel in authorized_keys tonen & de oude sleutel is verwijderd.
Slechte kaart: Verbeter beveiliging. (Dit is een project, geen taak. Verdeel het.)
WIP-limieten
De kolom In Uitvoering in het diagram toont een WIP-limiet: 3. Dit betekent dat niet meer dan drie kaarten tegelijk in Uitvoering kunnen zijn. Als je een vierde kaart wilt trekken, moet je eerst één afmaken.
Dit voelt als een beperking. Dat is het: opzettelijk. WIP-limieten dwingen je af te maken wat je begon voordat je iets nieuws begint. Meer over waarom dit belangrijk is in een later deel.
Werkkaarten Afbakenen
De moeilijkste vaardigheid in kanban is niet het tekenen van het bord. Het is het afbakenen van kaarten. Te groot & een kaart zit weken in Uitvoering, blokkerend ander werk. Te klein & het bord stroomt vol met herrie.
Silo's Werken Prima
Elke multidisciplinaire operatie heeft functionele werkcentra: een bakkerij heeft deegwaren, brood, hartig, & toonbank. Een productiestudio heeft ontwerp, inhoud, bouw, & ops. Een bouwproject heeft timmerwerk, loodgieterij, elektriciteit, & afwerking. Deze centra bestaan om goede redenen: diepe specialisatie vereist gericht eigenaarschap.
Kanban lost deze verdeling niet op. Het maakt handoffs daartussen zichtbaar & expliciet.
De handoff-kaart
Wanneer een stuk werk van het ene werkcentrum naar het andere gaat, zeg, een ontwerp-element dat eerst moet worden voorzien van tekst voordat de bouwer de pagina kan samenstellen, reist een handoff-kaart ermee. Het stroomafwaartse centrum ziet de kaart in hun Backlog verschijnen. Ze trekken het wanneer ze capaciteit hebben. Geen e-mail nodig. Geen vergadering om het te coördineren. De kaart is het signaal.
Wat het diagram toont
De ★ kaart begint in Ontwerp (In Uitvoering: visuele elementen). Wanneer Ontwerp hun deel voltooit, wordt een handoff-kaart gemaakt & verschijnt de ★ kaart in het Bouwcentrum's Backlog. Bouw trekt het. Dan Ops trekt het. Elk centrum heeft zijn eigen bord. Elk bord toont alleen het huidige werk van dat centrum. Maar de ★ reist door allemaal, & iedereen kan zien waar het is.
Dit is het supermarktinzicht dat op organisaties wordt toegepast: elk werkcentrum is een plank. Kaarten vullen stroomafwaartse planken alleen opnieuw als stroomopwaartswerk wordt getrokken & gebruikt.
Een Handoff Ontwerpen
De handoff-kaart is het contract tussen werkcentra. Het moet genoeg context bevatten zodat het ontvangende team kan handelen zonder een vergadering.
Stop Starten. Begin Afmaken.
WIP staat voor Work In Progress. Een WIP-limiet is een bovengrens voor hoeveel kaarten op hetzelfde moment in een bepaalde kolom kunnen zitten.
Dit voelt als een beperking. Dat is het. Dat is het punt.
Waarom limieten helpen
Telkens wanneer je een nieuwe taak begint zonder de vorige af te maken, betaal je een context-switching belasting. Je brein laadt de context van de nieuwe taak & lost gedeeltelijk de oude kwijt. Wanneer je naar de oude taak terugkeert, laad je het opnieuw. Voor kenniswerk, schrijven, debuggen, ontwerpen, beoordelen, wordt deze herlaadkost gemeten in uren, niet seconden.
WIP-limieten voorkomen de ophoping van half af werk. Ze doen ook iets waardevollers: ze brengen knelpunten aan het licht.
Knelpunten worden zichtbaar
Als de kolom Beoordeling een WIP-limiet van 2 heeft & deze staat altijd op 2, dat is een signaal: beoordeling is langzamer dan productie. Meer werk wordt voltooid In Uitvoering dan door Beoordeling kan worden verbruikt. Zonder WIP-limiet, stroomt het bord vol met 'klaar-maar-wachtend-op-beoordeling' kaarten & is het knelpunt onzichtbaar. Met WIP-limiet, kan de kolom In Uitvoering geen nieuwe kaarten accepteren, & ziet het hele team de beperking.
Dit is geen mislukking. Het is informatie. Het systeem zegt je dat je Beoordeling moet repareren, inhuren, koppelen, batchgrootte verminderen, in plaats van blindelings meer werk erdoor te duwen.
Little's Law (informeel)
Lead time (hoe lang een kaart van start tot gereed duurt) = Work In Progress ÷ Doorvoer (kaarten per tijdseenheid voltooid). Als je kortere lead times wilt zonder in te huren, verminder WIP. Minder dingen in vlucht betekent dat elk ding sneller klaar is.
R = (W × C) + T
WIP-limieten beschermen drie variabelen. Efficiëntie adviseur Brian Tracy noemde ze in 1986.
R = (W × C) + T
- R: Resultaat: de uitkomst die je wilt
- W: Duidelijkheid van doel: hoe precies weet je wat je wilt (0–10)
- C: Concentratie: intensiteit van gericht inspanning (0–10)
- T: Tijd gewerkt zonder afleidingen (ononderbroken uren)
Waarom W & C vermenigvuldigen
Duidelijkheid & concentratie zijn niet onafhankelijk. Hoge concentratie op een vaag doel veroorzaakt snelle beweging in de verkeerde richting. Perfecte doelzuidelijkheid zonder concentratie produceert niets. Ze werken samen: daarom schreef Tracy ze als een product, geen som. Een 9/10 op elk geeft R = 81 + T. Een 3/10 op elk geeft R = 9 + T. Het verschil is niet additief.
Waarom T optelt
Elk afleidingsvrij uur draagt lineair bij aan het resultaat. T kan W & C niet vermenigvuldigen: het kan alleen op het product stapelen. Dit verklaart waarom de eerste stap altijd is om W & C te verbeteren, niet om langer te werken. Meer T op een laag (W × C) product is nog steeds een slecht resultaat.
Wat het kanban-bord met elke variabele doet
- W: Een goed afgebakende kaart (duidelijke titel, meetbare acceptatiecriteria, één eigenaar) verhoogt W voordat werk begint. Vage kaarten verlagen het automatisch.
- C: WIP-limieten dwingen concentratie af. Één kaart in Actief betekent volle aandacht op één probleem. Drie kaarten in Actief betekent C is in drie verdeeld.
- T: Pomodoro-blokken & agendabescherming creëren de afleidingsvrije uren die T meet. De bordtimer is geen decoratie: het volgt T in real-time.
Tracy beweerde dat elk probleem in 30 minuten kon worden opgelost wanneer W, C, & T alle zijn geoptimaliseerd. Het kanban-bord is het instrument om alle drie tegelijk te optimaliseren.
Het Bord Lezen
Oefen het lezen van knelpunten uit bordstaat.
Niet Agile. Niet Waterfall.
Agile is een methodologie. Waterfall is een methodologie. Kanban is een systeem.
Methodologieën voorschrijven hoe je werkt. Systemen beschrijven wat waar over werk. Kanban zegt niet dat je twee-weekse sprints, dagelijkse standups, of retrospectives moet hebben. Het zegt één ding: maak werk zichtbaar, limiteer WIP, & trek.
Het probleem met methodologieën
Agile werkt goed voor teams die producten iteratief bouwen, software, meestal. Waterfall werkt goed voor projecten met vaste vereisten & bekende onbekenden, bouw, hardwarefabricage. Geen van beide past schoon op multidisciplinair werk waar een ontwerptaak & een fulfillment-taak heel verschillende cyclustijden & definities van 'gereed' hebben.
Het dwingen van een ontwerp centrum & ops centrum in dezelfde sprintritme is een categorale fout. Een twee-weekse sprint die voor inhoudscreatie werkt, produceert kunstmatige urgentie in logistiekwerk. Een standup-ritueel gebouwd voor co-located teams creëert overhead voor onafhankelijke soloartisten.
Vind gemeenschappelijk terrein over uit te voeren werk
De un benadering: vind het werk dat moet worden gedaan. Vind de mensen of partners het best gepositioneerd om het te doen. Dwing geen proces daarop: laat het werk zijn eigen proces aan het licht brengen via een gedeeld zichtbaarheidssysteem.
Dit is niet de afwezigheid van proces. Het is de juiste hoeveelheid proces: genoeg om te coördineren, niet genoeg om coördinatie overhead te creëren die groter is dan de waarde van het werk.
Bouw niet wat je kunt kopen. Koop niet wat je kunt groeien.
Vóór enige werkkaart wordt gemaakt, stel jezelf af: moet dit eigenlijk bestaan? Elk stuk werk dat je bouwt, bezit je voor altijd. Elke SaaS waarop je inschrijft, hangt je voor altijd af. Elke open-source afhankelijkheid die je forkt, onderhoudt je voor altijd.
De beslissingsstructuur: Kunnen we dit groeien? Een proces, vaardigheid, relatie die de capaciteit duurzaam produceert, geef hier de voorkeur aan. Als groeien niet haalbaar is: Kunnen we dit kopen? Een kant-en-klaar gereedschap dat 80% van het probleem oplost zonder maatwerk, geef hier de voorkeur aan. Als kopen niet haalbaar is: Bouw het. & bouw het wetende dat je het nu bezit.
De meeste organisaties keren deze volgorde om. Ze bouwen aangepaste infrastructuur voor problemen die commodity tools goed oplossen, dan hasten zich om wat ze bouwden te onderhouden. Kanban maakt dit zichtbaar: elke kaart in je Backlog is iets wat je koos om te bouwen. De eerlijke vraag is of het daar überhaupt hoort te zijn.
Bouw / Koop / Groei
Pas het raamwerk toe.
Een Bord Ontwerpen
Zet het samen. Je ontwerpt een kanban-systeem voor een specifiek multidisciplinair scenario.
Scenario
Een kleine studio lanceert hun product opnieuw met een nieuw merk. Het werk raakt vier centra:
- Ontwerp: nieuw logo, visuele identiteit, productfotografie, paginalayouts
- Inhoud: herschreven productbeschrijvingen, tekst voor landingspagina, e-mail aankondiging
- Bouw: bijgewerkte website, nieuwe checkout-flow, omleidingen van oude URL's
- Ops: bijgewerkte betalingsverwerker instellingen, fulfillment-partner briefing, analytics herconfiguratie
De herstart heeft een vaste deadline: een handelsbeurs over 45 dagen waar het nieuwe merk openbaar gaat.
Soloartisten Blijven Silo's
In de meeste organisaties bestaat kanban om werk zichtbaar te maken over een managemënthiërarchie. Managers coördineren tussen silo's. Kanban vermindert de coördinatieoverhead.
In het un model zijn er geen managers. Er zijn soloartisten. Een soloartist runt een onderneming onafhankelijk: een ontwerp solo, een bouw solo, een schrijver solo, een ops solo. Elke solo is per definitie een silo. Er is geen organigram dat ze verbindt. Geen rapportagerelatie. Geen manager om coördinatie af te dwingen.
Kanban wordt de coördinatielaag. Niet door silo's af te vlakken, soloartisten blijven volledig onafhankelijk, maar door handoffs daartussen zichtbaar & expliciet te maken. Een soloartist stuurt geen e-mail of plant geen vergadering om werk over te dragen. Ze plaatsen een kaart op een gedeeld bord. De ontvangende soloartist trekt het wanneer ze capaciteit hebben.
Dit verklaart waarom kanban beter aansluit op het un model dan agile of waterfall: het vereist geen gedeelde cadentie, geen gezamenlijke retro's, geen gesynchroniseerde planning. Elke soloartist stelt zijn eigen WIP-limieten, eigen cyclustijd, eigen definitie van gereed. Coördinatie gebeurt op kaartniveau, niet op procesniveau.