看板 — Anschlagtafel
Kanban (看板) ist japanisch. Die Zeichen lassen sich so analysieren: 看 (kan), zu beobachten, zu sehen, & 板 (ban): Tafel, Brett, Schild. Zusammen: eine visuelle Signaltafel.
Das Wort geht Jahrhunderte vor dem Management-System zurück. Jede Geschäft in Japan im Edo-Zeitalter hatte ein Kanban: ein holzes Schild vor dem Gebäude, das ankündigte, was im Innern verkauft wurde. Der visuelle Signal war die Anzeige, der Lagerstatus und der Auslöser für Nachbestellung.
Taiichi Ohnos Supermarkt-Insight
In den 1950er Jahren besuchte Toyota-Ingineur Taiichi Ohno amerikanische Supermärkte. Was er sah, veränderte die Geschichte der Fertigung.
In einer traditionellen Fabrik lief die Push-Vorlage, die Produktion basierte auf einem Zeitplan. Ein Prognose sagte: "Wir werden im nächsten Monat 500 Einheiten benötigen", also produzierte die Fabrik 500 Einheiten und drückte sie auf ein Regal. Wenn die Nachfrage falsch war, war das Regal überfüllt. Wenn die Nachfrage den Prognosen überstieg, war das Regal leer. In beiden Fällen hatte jemand falsch gelegen.
Supermärkte funktionierten anders. Die Regale hielten eine feste Menge an jedem Artikel. Wenn ein Kunde den letzten Dosen Joghurt genommen hatte, war der leere Platz selbst der Auslöser für eine Nachbestellung. Lagerarbeiter brauchten keine Manager, um ihnen zu sagen, dass sie nachbestellen sollten: das Regal sagte es ihnen. Das ist das Pull-Modell: Abnahmesignale lösen Gegenwart.
Ohno brachte diesen Einblick zurück nach Toyota. Die physische Karte (Kanban) an einem Korb von Teilen wurde zum Signal: "Dieser Korb ist leer: Produzieren Sie mehr." Keine Prognose war notwendig. Kein zentraler Planer. Die Arbeit zog sich selbst vor.
Push vs. Pull
Der Unterschied zwischen Push und Pull ist die Grundlage für alles, was folgt.
Spalten als Zustände
Ein Kanban-Board macht die Arbeit sichtbar. Jedes Stück Arbeit ist eine Karte. Karten bewegen von links nach rechts durch Spalten, die Zustände darstellen.
Die klassischen Spalten sind: Rückstand → Ausgewählt → In Bearbeitung → Überprüfung → Erledigt
Aber die genauen Spalten sind nicht wichtig. Wichtig ist, dass jeder Karte genau einen aktuellen Zustand zuordnet, und dieser Zustand ist für jeden, der in dem System arbeitet, sichtbar.
Was eine Karte darstellt
Eine Karte stellt eine Einheit Arbeit dar, die unabhängig abgeschlossen werden kann. Nicht ein Projekt. Nicht ein Ziel. Eine spezifische, abgegrenzte Sache mit einer klaren Definition von 'erledigt'.
Gute Karte: SSH-Schlüssel auf Produktionsservern rotieren: Erledigt, wenn alle Server den neuen Schlüssel in authorized_keys zeigen & der alte Schlüssel entfernt ist.
Schlechte Karte: Sicherheit verbessern. (Das ist ein Projekt, nicht eine Aufgabe. Teile es auf.)
Obergrenze für im Gange liegende Karten (WIP)
Die Spalte 'In Bearbeitung' im Diagramm zeigt eine Obergrenze für im Gange liegende Karten: 3. Das bedeutet, dass nicht mehr als drei Karten gleichzeitig in Bearbeitung sind. Wenn Sie einen vierten Karten ziehen möchten, müssen Sie eine vorher beenden.
Dies fühlt sich wie eine Einschränkung an. Es ist eine: durch Entwurf festgelegt. WIP-Grenzen zwingen Sie, das zu beenden, was Sie begonnen haben, bevor Sie mit etwas Neuem anfangen. Weitere Informationen dazu finden Sie in einem späteren Abschnitt.
Arbeitskarten skizzieren
Die schwierigste Fähigkeit im Kanban ist nicht das Zeichnen des Boards. Es ist das Skalieren der Karten. Zu groß und eine Karte liegt für Wochen in 'In Bearbeitung', blockiert andere Arbeit. Zu klein und das Board ist voller Lärm.
Schweröl arbeitet gut
Jede mehrdisziplinäre Operation hat funktionale Arbeitszentren: Ein Bäckerei hat Teigwaren, Brot, Würstchen und eine Vorderseite. Ein Produktstudio hat Design, Inhalte, Aufbau und Betrieb. Ein Bauprojekt hat Ausbau, Installation, Elektro und Ausbau. Diese Zentren existieren aus guten Gründen: Spezialisation erfordert gezielte Verantwortung.
Kanban löst diese Divisionen nicht auf. Es macht die Übergaben zwischen ihnen sichtbar und explizit.
Die Handover-Karte
Wenn eine Einheit an Arbeit von einem Arbeitszentrum zum anderen übertragen wird, z. B. ein Design-Asset, das geschrieben werden muss, bevor der Builder die Seite zusammenbauen kann, reist eine Handover-Karte mit. Das tiefer liegende Zentrum sieht die Karte in ihrem Backlog erscheinen. Sie ziehen sie, wenn sie Kapazität haben. Kein E-Mail erforderlich. Keine Koordination in einer Besprechung. Die Karte ist der Signal.
Was zeigt das Diagramm
Das ★-Ticket beginnt in Design (In Arbeit: visuelle Assets). Wenn Design ihre Arbeit beendet hat, wird eine Handover-Karte erstellt und das ★-Ticket erscheint im Backlog des Build-Zentrums. Build zieht es. Dann zieht Ops es. Jedes Zentrum hat seinen eigenen Board. Jeder Board zeigt nur die derzeitige Arbeit in diesem Zentrum. Aber das ★-Ticket reist durch alle von ihnen und jeder kann sehen, wo es ist.
Dies ist der Supermarkt-Erkenntnis angewendet auf Organisationen: jedes Arbeitszentrum ist eine Regal. Karten werden nur dann in die tiefer liegenden Regale nachgeladen, wenn die obere Arbeit gezogen und verbraucht wird.
Entwerfen einer Handover
Die Handover-Karte ist der Vertrag zwischen den Arbeitszentren. Sie muss genug Kontext enthalten, damit das empfangende Team handeln kann, ohne eine Besprechung zu benötigen.
Stoppen Sie mit dem Anfangen. Anfangen Sie, zu beenden.
WIP steht für Work In Progress. Eine Obergrenze für im Gange befindliche Arbeit ist eine Begrenzung auf die Anzahl von Karten, die gleichzeitig in einer gegebenen Spur sein können.
Das klingt wie eine Einschränkung. Das ist es auch. Das ist der Punkt.
Warum Obergrenzen helfen
Jede neue Aufgabe zu beginnen, ohne die vorherige zu beenden, kostet einen Zurechnungsteuerungstax. Ihr Gehirn lädt den Kontext der neuen Aufgabe und lädt den alten teilweise runter. Wenn Sie zur alten Aufgabe zurückkehren, laden Sie sie erneut. Für kognitives Arbeiten, Schreiben, Debuggen, Entwerfen, Überprüfen, wird dieser Lastenwechsel in Stunden gemessen, nicht in Sekunden.
WIP-Grenzen verhindern das Ansammeln von unvollendeten Arbeiten. Sie wirken auch auf eine wertvollere Weise: Sie sorgen für die Sichtbarmachung von Engpässen.
Engpässe werden sichtbar
Wenn der Spalte 'Review' ein WIP-Limit von 2 zugewiesen ist und sie sich immer bei 2 befindet, ist das ein Signal: Die Überprüfung ist langsamer als die Produktion. Mehr Arbeit wird im Zustand 'In Progress' abgeschlossen als von der Überprüfung verbraucht werden kann. Ohne WIP-Grenze füllt sich das Board mit 'abgeschlossenen, aber auf Review wartenden' Karten und der Engpass ist unsichtbar. Mit einer WIP-Grenze kann die Spalte 'In Progress' keine neuen Karten akzeptieren, und die gesamte Mannschaft sieht die Einschränkung.
Dies ist keine Fehlhandlung. Es handelt sich um Informationen. Das System gibt Ihnen an, 'Review' zu optimieren, zu personalisieren, zu paaren oder die Batchgröße zu reduzieren, anstelle blind mehr Arbeit durchzusetzen.
Little's Gesetz (schlüsselwortartig)
Fertigungszeit (wie lange ein Karten von Anfang bis Ende dauert) = Arbeit in Progress ÷ Durchsatz (Karten pro Zeiteinheit, die abgeschlossen werden). Wenn Sie kürzere Fertigungszeiten ohne Personalbeschaffung erreichen möchten, reduzieren Sie WIP. Weniger Dinge im Gange bedeutet, dass jede Sache schneller abgeschlossen wird.
R = (W × C) + T
WIP-Grenzen schützen drei Variable. Der Effizienzberater Brian Tracy benannte sie 1986.
R = (W × C) + T
- R: Ergebnis: das gewünschte Outcome
- W: Klarheit des Ziels: wie genau Sie wissen, was Sie wollen (0-10)
- C: Konzentration: Intensität des fokussierten Einsatzes (0-10)
- T: Arbeitstage ohne Ablenkung (unterbrochene Stunden)
Warum W und C multipliziert werden
Klarheit und Konzentration sind nicht unabhängig voneinander. Hohe Konzentration auf ein unscharfes Ziel führt zu schneller Bewegung in die falsche Richtung. Perfekte Zielklarheit ohne Konzentration erzeugt nichts. Sie wirken wechselseitig: deshalb hat Tracy sie als Produkt und nicht als Summe geschrieben. Ein 9/10 in beiden Fällen ergibt R = 81 + T. Ein 3/10 in beiden Fällen ergibt R = 9 + T. Der Unterschied ist nicht additiv.
Warum T hinzugefügt wird
Jede Ablenkungsfreie Stunde trägt linear zum Ergebnis bei. T kann W und C nicht verheben: es kann nur auf das Produkt aufgestapelt werden. Dies erklärt, warum die erste Verbesserung stets W und C betrifft, nicht die Verlängerung der Arbeitszeit. Mehr T auf ein niedriges (W × C)-Produkt führt immer noch zu einem schlechten Ergebnis.
Was der Kanban-Board zu jedem Variable tut
- W: Ein gut skaliertes Karten (klarer Titel, messbares Akzeptanzkriterium, eindeutiger Besitzer) erhöht W vor der Arbeit. Unklare Karten senken es automatisch.
- C: WIP-Grenzen erzwingen Konzentration. Eine Karte in Active bedeutet volle Aufmerksamkeit für ein Problem. Drei Karten in Active bedeutet, dass C auf drei Weisen geteilt wird.
- T: Pomodorofächer & Kalender-Schutz schaffen die störungsfreien Stunden, die T misst. Der Board-Zeitgeber ist keine Dekoration: er verfolgt T in Echtzeit.
Tracy behauptete, dass jedes Problem in 30 Minuten gelöst werden kann, wenn W, C & T optimal sind. Das Kanban-Board ist das Instrument, um alle drei gleichzeitig zu optimieren.
Das Lesen des Boards
Üben Sie das Lesen von Engpässen aus dem Board-Zustand.
Nicht agil. Nicht Wasserfall.
Agile ist eine Methode. Wasserfall ist eine Methode. Kanban ist ein System.
Methode schreiben vor, wie man arbeitet. Systeme beschreiben, was über die Arbeit wahr ist. Kanban sagt Ihnen nicht, dass Sie zweiwöchige Sprints, tägliche Standups oder Rückblicksbesprechungen haben sollten. Es sagt Ihnen nur eines: Machen Sie die Arbeit sichtbar, begrenzen Sie die Anzahl der laufenden Aufgaben und ziehen Sie sich zurück.
Das Problem mit Methoden
Agile funktioniert gut für Teams, die Produkte iterativ entwickeln, Software, meistens. Wasserfall funktioniert gut für Projekte mit festen Anforderungen & bekannten Unbekannten, Bauwesen, Hardwarefertigung. Keine der beiden passt sauber auf arbeitsteilige Tätigkeiten, bei denen ein Designaufgabe & eine Erfüllungsaufgabe vollständig unterschiedliche Zeitschritten & Definitionen von 'erledigt' haben.
Die Zwangsfestlegung eines Designzentrums & eines Betriebszentrums auf denselben Sprintrhythmus ist eine Kategorienfehler. Ein zweiwöchiger Sprint, der für Inhaltserschaffung gut funktioniert, erzeugt unnötige Dringlichkeit bei Logistikarbeit. Ein Stand-up-Ritual, das für co-ortierte Teams gebaut ist, erzeugt Überhead für unabhängige Einzelpersonen.
Finden Sie gemeinsamen Boden bei der zu erledigenden Arbeit
Das un-Ansatz: Finden Sie die Arbeit, die getan werden muss. Finden Sie die Personen oder Partner, die am besten positioniert sind, um sie auszuführen. Erzwingen Sie keinen Prozess darüber: Lassen Sie die Arbeit ihren eigenen Prozess durch eine gemeinsame Sichtbarkeitssystematik entfalten.
Dies ist kein Fehlen von Prozess. Es ist der richtige Prozess: genug, um zu koordinieren, aber nicht genug, um Koordinationsüberhead zu erzeugen, der den Wert der Arbeit übersteigt.
Bauen Sie nicht, was Sie kaufen können. Kaufen Sie nicht, was Sie wachsen können.
Bevor eine Arbeitskarte erstellt wird, fragen Sie: sollte dies überhaupt existieren? Jede Stück Arbeit, die Sie bauen, besitzen Sie für immer. Jede SaaS, bei der Sie abonnieren, hängen Sie ab für immer. Jede Open-Source-Abhängigkeit, die Sie forken, pflegen Sie für immer.
Die Entscheidungstree: Können wir das wachsen lassen? Ein Prozess, eine Fähigkeit, eine Beziehung, die die Fähigkeit nachhaltig erzeugt, bevorzugen Sie dies. Wenn das Wachstum nicht machbar ist: Können wir das kaufen? Eine fertige Werkzeug, das 80% des Problems ohne individuelle Arbeit löst, bevorzugen Sie dies. Wenn das Kaufen nicht machbar ist: Bauen Sie es. Und bauen Sie es wissen, dass Sie es jetzt besitzen.
Die meisten Organisationen invertieren diese Reihenfolge. Sie bauen eine individuelle Infrastruktur für Probleme, die günstige Werkzeuge gut lösen, und dann rennen sie, um das zu erhalten, was sie gebaut haben. Kanban macht dies sichtbar: jede Karte in Ihrem Backlog ist eine Sache, die Sie gewählt haben, zu bauen. Die ehrliche Frage ist, ob sie überhaupt dort sein sollte.
Build / Buy / Grow
Anwenden Sie das Entscheidungsframework.
Entwerfen Sie ein Board
Machen Sie es zusammen. Sie werden ein Kanban-System für einen bestimmten interdisziplinären Szenario entwerfen.
Szenario
Ein kleines Studio lanciert ihr Produkt neu mit einem neuen Branding. Die Arbeit beinhaltet vier Bereiche:
- Design: neues Logo, visuelles Identität, Produktfotografie, Seitenlayouts
- Content: überarbeitete Produktbeschreibungen, Landingpage-Text, E-Mail-Kampagnen-Text
- Build: aktualisierte Website, neuer Checkout-Flow, Umleitungen von alten URLs
- Ops: aktualisierte Einstellungen für Zahlungsdienstleister, Briefing des Fulfillment-Partners, Neukonfiguration von Analysewerkzeugen
Die Relaunch hat einen festen Termin: eine Messe in 45 Tagen, an der das neue Branding öffentlich präsentiert wird.
Solos bleiben Silos
In der Regel existiert Kanban, um die Arbeit in einer Management-Hierarchie sichtbar zu machen. Manager koordinieren zwischen Silos. Kanban reduziert die Koordinationskosten.
Im un-Modell gibt es keine Manager. Es gibt Solos. Ein Solo betreibt ein Unternehmen unabhängig: ein Designer-Solo, ein Builder-Solo, ein Schriftsteller-Solo, ein Ops-Solo. Jedes Solo ist von Natur aus ein Silo. Es gibt keine Organisationsstruktur, die sie verbindet. Keine Berichterstattung. Kein Manager, der die Koordination erzwingt.
Kanban wird zum Koordinationslayer. Nicht, indem es Silos flachert, sondern indem es die Handlungen zwischen ihnen sichtbar und explizit macht. Ein Solo sendet keine E-Mail oder plant ein Meeting, um die Arbeit zu übergeben. Sie legen eine Karte auf einem gemeinsamen Brett ab. Der empfangende Solo zieht sie, wenn sie Kapazität haben.
Das erklärt, warum Kanban besser zum un-Modell passt als agiles oder Wasserfall: Es erfordert keine gemeinsame Rhythmus, keine gemeinsamen Rückblicke, keine synchronisierte Planung. Jedes Solo setzt seine eigenen WIP-Grenzwerte, eigenen Zykluszeit, eigene Definition von Fertigstellung. Die Koordination erfolgt auf Karten-Ebene und nicht auf Prozess-Ebene.