看板 — Signboard
Kanban (看板) is Japans. De tekens zijn op te delen als: 看 (kan), kijken, zien, & 板 (ban): bord, plank, sign. Samen: een visueel signaalbord.
De woorden dateren al eeuwen voor het managementstelsel. Elk winkeltje in Edo-periode Japan had een kanban: een houten sign buiten dat aankondigde wat er binnen werd verkocht. Het visuele signaal was de advertentie, de voorraadindicator & de herorderprikkel allemaal tegelijk.
Inzicht van Taiichi Ohno over de Supermarkt
In de jaren 50 bezocht Toyota-engineer Taiichi Ohno Amerikaanse supermarkten. Wat hij zag veranderde de geschiedenis van de productie.
In een traditionele fabriek werkte het push model, productie verliep op schema. Een voorspelling zei: "we zullen 500 eenheden volgende maand nodig hebben", dus de fabriek maakte 500 eenheden & duwde ze naar de verkoop. Als de voorspelling fout was, was de plank overvol of leeg. In beide gevallen was iemand fout.
Supermarkten werkten anders. De planken hielden een vaste hoeveelheid van elk artikel. Als de laatste potje pindakaas werd weggenomen door een klant, was de lege plek zelf de herorderprikkel. Magazijnmedewerkers hoefden geen manager te vertellen om opnieuw te bestellen: de plank vertelde het hun. Dit is het trekken model: eindbestaande signalen voor aanvullende herlevering.
Ohno bracht dit inzicht terug naar Toyota. Het fysieke kaartje (kanban) dat aan een doos met onderdelen was bevestigd, werd het signaal: "de doos is leeg: produceer meer". Geen voorspelling nodig. Geen centrale planner. Het werk trok zichzelf vooruit.
Duwen vs. Trekken
De push/pull onderscheiding is de basis van alles wat volgt.
Kolommen als Staten
Een kanban bord maakt werk zichtbaar. Elk stuk werk is een kaart. Kaarten verplaatsen zich van links naar rechts door kolommen die staten vertegenwoordigen.
De klassieke kolommen zijn: Backlog → Selected → In Progress → Review → Done
Maar de exacte kolommen tellen niet. Wat telt is dat elk kaart precies één huidige staat heeft, en dat die staat zichtbaar is voor iedereen die in dat systeem werkt.
Wat een kaart vertegenwoordigt
Een kaart vertegenwoordigt een eenheid van werk die independentelijk kan worden voltooid. Niet een project. Niet een doel. Een specifiek, omvanggering ding met een duidelijke definitie van gedaan.
Goede kaart: Rotatie van SSH-sleutels op productieservers: gedaan wanneer alle servers de nieuwe sleutel tonen in authorized_keys & de oude sleutel is verwijderd.
Slechte kaart: Veiliger maken. (Dit is een project, niet een taak. Verwerk het uit.)
WIP-limieten
De In Progress-kolom in het diagram toont een WIP-limiet: 3. Dit betekent dat er niet meer dan drie kaarten tegelijk In Progress mogen zijn. Als je een vierde kaart wil trekken, moet je er een eerst af hebben.
Dit voelt alsof het een beperking is. Het is: opzettelijk. WIP-limieten dwingen je om wat je begonnen bent af te maken voordat je iets nieuws begint. Meer over waarom dit belangrijk is in een later gedeelte.
Werken met Afgebakende Kaarten
Het moeilijkste vaardigheid in kanban is niet het bord teken. Het is het afbakenen van kaarten. Te groot en een kaart zit In Progress voor weken, blokkerend voor andere werk. Te klein en het bord raakt overvol met geluid.
Geïsoleerde Afdelingen Werken Prima
Elke multi-discipline operatie heeft functionele werkcentra: een bakkerij heeft taart, brood, zoet, en voorverkoop. Een productstudio heeft ontwerp, content, bouw, & ops. Een bouwproject heeft framing, leidingwater, elektriciteit, & afwerking. Deze centra bestaan om goede redenen: diepe specialisatie vereist gefocuste eigenaars.
Kanban lost deze deling niet op. Het maakt overgangen tussen hen zichtbaar & expliciet.
De handoff kaart
Wanneer een eenheid van werk van één werkcentrum naar een ander verplaatst, bijvoorbeeld een ontwerpasset dat geschreven moet worden voordat de bouwer de pagina kan samenstellen, reist een handoff kaart mee. Het downstream centrum ziet de kaart verschijnen in hun Backlog. Ze trekken het wanneer ze capaciteit hebben. Geen e-mail vereist. Geen vergadering om te coördineren. De kaart is het signaal.
Wat de diagram toont
Het ★ ticket begint in Design (In Progress: visuele elementen). Wanneer Design hun deel heeft afgerond, wordt een handoff kaart gemaakt & verschijnt het ★ ticket in de Backlog van het Build centrum. Build trekt het. Vervolgens trekt Ops het. Elk centrum heeft zijn eigen bord. Elk bord toont alleen het huidige werk van dat centrum. Maar het ★ reist door allemaal en iedereen kan zien waar het is.
Dit is het supermarktinzicht toegepast op organisaties: elk werkcentrum is een plank. Kaarten worden pas op de downstream planken geplaatst wanneer de upstream werk is getrokken en verbruikt.
Het ontwerpen van een Handoff
De handoff kaart is het contract tussen werkcentra. Hij moet voldoende context bevatten voor het ontvangende team om te kunnen handelen zonder een vergadering.
Stop met beginnen. Begin met afronden.
WIP staat voor Work In Progress. Een WIP limiet is een maximum aan het aantal kaarten dat tegelijkertijd in een bepaalde kolom mag zijn.
Dat klinkt als een beperking. Het is dat. Dat is de bedoeling.
Waarom beperkingen helpen
Elke keer dat je een nieuw taken begint zonder het vorige te voltooien, betaal je een belasting voor het schakelen tussen contexten. Je brein laadt de context van de nieuwe taak en laadt de oude gedeeltelijk. Wanneer je terugkeert naar de oude taak, laad je hem opnieuw. Voor kenniswerk, schrijven, debuggen, ontwerpen, controleren, wordt deze belasting gemeten in uren, niet in seconden.
WIP-limieten voorkomen het opstapelen van halfafgeronde werkzaamheden. Ze doen ook iets waardevollers: ze onthullen knelpunten.
Knelpunten worden zichtbaar
Als de Review-kolom een WIP-limiet van 2 heeft en het altijd is 2, is dat een signaal: review gaat trager dan productie. Er wordt meer werk afgerond in In Progress dan dat door Review kan worden verwerkt. Zonder een WIP-limiet vult het bord zich met 'afgeronde, maar wachtend op review'-kaarten en het knelpunt is onzichtbaar. Met een WIP-limiet kan de In Progress-kolom geen nieuwe kaarten accepteren en de hele team ziet de beperking.
Dit is geen mislukking. Het is informatie. Het systeem vertelt je om Review te verbeteren, personeel in te huren, samen te werken, de batchgrootte te verminderen, in plaats van blind meer werk door te zetten.
Little's Wet (informeel)
Leidtijd (hoe lang een kaart duurt van begin tot afgerond) = Werk In Progress ÷ Doorvoer (kaarten afgerond per tijdseenheid). Als je kortere leidtijden wilt zonder het inhuren, vermindert WIP. Minder dingen in de lucht betekent dat elke zaak sneller afgerond.
R = (W × C) + T
WIP-limieten beschermen drie variabelen. Efficiency consultant Brian Tracy noemde ze in 1986.
R = (W × C) + T
- R: Resultaat: het gewenste uitkomst
- W: Duidelijkheid van doel: hoe precies je weet wat je wilt (0-10)
- C: Concentratie: intensiteit van gefocuste inspanning (0-10)
- T: Gewerkt tijd zonder afleidingen (ononderbroken uren)
Waarom W & C vermenigvuldigen
Duidelijkheid en concentratie zijn niet onafhankelijk. Hoge concentratie op een vaag doel leidt tot snelle vooruitgang in de verkeerde richting. Perfect doel duidelijkheid met geen concentratie produceert niets. Ze werken samen: waarom Tracy ze schreef als een product, niet als een som. Een 9/10 op elk geeft R = 81 + T. Een 3/10 op elk geeft R = 9 + T. De verschillen zijn niet opgeteld.
Waarom T toevoegt
Elke afleidingsvrije uur voegt lineair toe aan het resultaat. T kan het product van W & C niet vermenigvuldigen: het kan alleen opstaan bovenop het product. Dit verklaart waarom de eerste beweging 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 doet aan elke waarde
- W: Een goed gescopede kaart (duidelijke titel, meetbare acceptatiecriteria, enkel eigenaar) verhoogt W voordat het werk begint. Vaag kaarten verlagen het automatisch.
- C: WIP-limieten dwingen tot concentratie. Een kaart in Active betekent volle aandacht op één probleem. Drie kaarten in Active betekent dat C verdeeld wordt over drie kaarten.
- T: Pomodoro blokken & kalenderbescherming creëren de afleidingsvrije uren T meet. De bordteller is geen versiering: het volgt T in real time.
Tracy beweerde dat elk probleem in 30 minuten kon worden opgelost als W, C, & T allemaal geoptimaliseerd waren. Het kanbord is het instrument om alle drie tegelijk te optimaliseren.
Lezen van het bord
Oefenen met het lezen van knelpunten op basis van het bordstaat.
Niet Agile. Niet Waterfall.
Agile is een methodologie. Waterfall is een methodologie. Kanban is een systeem.
Methodologieën geven aan hoe je moet werken. Systeem beschrijft wat waar is over werk. Kanban vertelt je niet dat je twee-weekse sprints, dagelijkse stand-ups of retrospectives moet hebben. Het vertelt je één ding: werk zichtbaar maken, beperk WIP en pul.
Het probleem met methodologieën
Agile werkt goed voor teams die producten iteratief ontwikkelen, voornamelijk software. Waterfall werkt goed voor projecten met vaste eisen & bekende onbekenden, bouw, hardwareproductie. Geen van beiden past soepel op cross-disciplinaire werkzaamheden waar een ontwerptaken & een uitvoeringsaanvraag geheel verschillende cyclustijden & definities van 'afgerond' hebben.
Het dwingen van een ontwerpcentrum & een operationscentrum tot dezelfde ritme van sprint is een categoriefout. Een sprint van twee weken die werkt voor contentcreatie creëert kunstmatige urgentie in logistiek werk. Een standup-ritueel gebouwd voor co-gelegen teams creëert overhead voor onafhankelijke solo's.
Vind gemeenschappelijk grondgebied op werk te doen
De un-ansatz: vind het werk dat gedaan moet worden. Vind de mensen of partners die het beste zijn geplaatst om het te doen. Impose geen proces bovenop dat: laat het werk zijn eigen proces naar boven komen door middel van een gedeelde zichtbaarheidssysteem.
Dit is niet het afwezigheid van proces. Het is het juiste aantal processen: genoeg om te coördineren, niet genoeg om coördinatie-overhead te creëren die de waarde van het werk overschrijdt.
Bouw niet wat u kunt kopen. Koop niet wat u kunt laten groeien.
Voordat er een werkkaart is gemaakt, vraag: zou dit moeten bestaan? Elk stuk werk dat u bouwt, eigen u voorgoed. Elk SaaS waar u zich voor inschrijft, bent u voorgoed afhankelijk van. Elk open-source afhankelijkheid die u vorkt, onderhoudt u voorgoed.
De beslissingsboom: Kunnen we dit laten groeien? Een proces, een vaardigheid, een relatie die de capaciteit duurzaam produceert, prefereer dit. Als groeien niet haalbaar is: Kunnen we dit kopen? Een afzetgereedschap dat 80% van het probleem oplost zonder aangepast werk, prefereer dit. Als kopen niet haalbaar is: Bouw het. En bouw het wetende dat u het nu eigendom bent.
Meeste organisaties volgen deze volgorde omgekeerd. Ze bouwen aangepaste infrastructuur voor problemen die goed worden opgelost met commodity-tools, en schieten daarna in paniek om wat ze gebouwd hebben te onderhouden. Kanban maakt dit zichtbaar: elke kaart in uw Backlog is iets dat u heeft gekozen om te bouwen. De eerlijke vraag is of het daar zou moeten zijn.
Build / Buy / Grow
Pas het beslissingsraamwerk toe.
Ontwerp een Bord
Zet het samen. Je gaat een kanban-systeem ontwerpen voor een specifiek cross-functioneel scenario.
Scenario
Een klein studio maakt hun product opnieuw met een nieuw merk. De werkzaamheden betreffen vier centra:
- Ontwerp: nieuw logo, visuele identiteit, productfotografie, pagina-indelingen
- Content: herziene productbeschrijvingen, landingpagina tekst, e-mail-aankondiging
- Build: bijgewerkte website, nieuwe checkout-stroom, doorverwijzingen van oude URLs
- Ops: bijgewerkte instellingen voor betalingsverwerking, inlichtingen voor de leveringspartner, herconfiguratie van analytische gegevens
De relaunch heeft een harde deadline: een handelsbeurs in 45 dagen waar het nieuwe merk openbaar wordt gemaakt.
Solos Blijven Silos
In de meeste organisaties bestaat kanban om het werk zichtbaar te maken over een managementhiërarchie. Managers coördineren tussen silos. Kanban vermindert de coördinatieoverhead.
In het un-model zijn er geen managers. Er zijn solos. Een solo bedrijft een onderneming onafhankelijk: een ontwerper solo, een bouwer solo, een schrijver solo, een operations solo. Elk solo is, uit definitie, een silo. Er is geen org-chart die ze verbindt. Geen rapportage-relatie. Geen manager om coördinatie te dwingen.
Kanban wordt de coördinatieslaag. Niet door silos te verfladden, solos blijven volledig onafhankelijk, maar door de overgangen tussen hen zichtbaar en expliciet te maken. Een solo stuurt geen e-mail of plannen een bijeenkomst in om werk over te dragen. Ze leggen een kaart op een gedeeld bord. De ontvangende solo trekt het wanneer ze capaciteit hebben.
Dit verklaart waarom kanban beter past bij het un-model dan agile of waterfall: het vereist geen gedeelde cadans, geen gezamenlijke retros, geen gesynchroniseerde planning. Elk solo stelt zijn eigen WIP-limieten, zijn eigen cyclustijd, zijn eigen definitie van gedaan. Coördinatie vindt plaats op kaartniveau, niet op procesniveau.