Warum Kanban funktioniert – und woran Sie erkennen, ob Ihr Team bereit dafür ist

Die meisten Teams führen Kanban ein, weil jemand einen Blogartikel gelesen hat. Die klügere Frage lautet, ob die Probleme, die Kanban löst, tatsächlich die Probleme Ihres Teams sind.

Es gibt einen Moment, den die meisten Teams kennen, meist ab etwa acht oder neun Mitarbeitenden. Die Arbeit wird erledigt – E-Mails werden verschickt, Features ausgeliefert, Kunden betreut –, aber niemand hat ein klares Bild davon, was alle anderen gerade tun. Projekte stapeln sich. Dinge werden zugesagt und dann stillschweigend vergessen. Vor jedem Meeting verbringen Sie zwanzig Minuten damit herauszufinden, wo eine Aufgabe eigentlich steht. Die Antwort lautet meistens: „irgendwo“.

Genau dieses Problem sollte Kanban lösen. Nicht das Problem, eine Strategie festzulegen, die richtigen Leute einzustellen oder eine Kultur aufzubauen – sondern das konkrete, zermürbende operative Problem, zu wissen, woran Ihr Team arbeitet und was ihm im Weg steht.

Für etwas, das so viel Aufmerksamkeit bekommen hat, ist es ein überraschend bescheidenes Werkzeug. Kanban behauptet nicht, Ihre Organisation zu reparieren. Es macht Arbeit nur sichtbar. Und es zeigt sich, dass Transparenz, konsequent angewandt, erstaunlich viel weiter unten in der Kette verändert.

Woher Kanban eigentlich kommt

Das Wort ist japanisch – es bedeutet „Schild“ oder „Tafel“ –, und das System wurde Ende der 1940er-Jahre von Toyota entwickelt, um den Bestand in den Fertigungswerken zu steuern. Die Idee war einfach: Statt Teile nach festem Plan zu produzieren, fertigte die Fabrik sie nur dann, wenn eine nachgelagerte Station signalisierte, dass sie sie brauchte. Eine physische Karte – das Kanban – wanderte als Anforderung die Linie zurück. Nichts wurde auf Verdacht hergestellt. Nichts stapelte sich unnötig.

Toyotas Einsicht, die später Softwareteams übernahmen: Die meiste Ineffizienz in einem System entsteht nicht dadurch, dass Menschen zu langsam arbeiten, sondern dadurch, dass die falsche Arbeit zur falschen Zeit erledigt wird. Zu viele Dinge werden gleichzeitig begonnen. Engpässe fallen erst auf, wenn es zu spät ist. Fertige Arbeit liegt an einer Stelle, während der nächste Schritt anderswo überlastet ist.

Softwareentwickler, besonders bei Unternehmen wie Microsoft Anfang der 2000er-Jahre, begannen, diese Ideen für Wissensarbeit zu adaptieren. Aus den Karten wurden Aufgaben. Aus den Fabrikstationen wurden Phasen in einem Workflow. Und aus dem Schild wurde ein Board – zuerst physisch, dann digital –, auf dem jeder im Team auf einen Blick sehen konnte, was in Arbeit ist, was wartet und was erledigt ist.

Was ein Kanban-Board Ihnen tatsächlich zeigt

Ein einfaches Kanban-Board hat drei Spalten: To do, In Arbeit und Erledigt. Das reicht für viele kleine Teams und ist ein guter Startpunkt. Der eigentliche Wert entsteht aber, wenn Sie diese Phasen an den tatsächlichen Arbeitsfluss anpassen – nicht an den, den Sie sich wünschen.

Ein Content-Team könnte verwenden: Idee, Briefing, Im Entwurf, Im Review, Geplant, Veröffentlicht. Ein Softwareteam könnte „In Arbeit“ in getrennte Spalten für Entwicklung, Code-Review und QA aufteilen. Ein Beratungsteam könnte Discovery, Angebot, Aktiv, Wartet auf Kunde und Abgeschlossen abbilden. Die Phasen sollten echte Übergaben und echte Wartezeiten widerspiegeln – Stellen, an denen Arbeit den Besitzer wechselt oder liegt, bis etwas anderes passiert.

Achten Sie auf die Karte in der mittleren Spalte – der Bericht zum Lageraudit, seit acht Tagen offen, als blockiert markiert. In einem System ohne Board könnte diese Aufgabe noch zwei weitere Wochen liegen, bevor jemand merkt, dass sie nicht vorankommt. Jemand wartet auf einen Dritten. Oder es braucht eine Entscheidung von einer Führungskraft, die nicht weiß, dass sie der Engpass ist. Das Board macht die Blockade sichtbar. Das ist der Großteil der Arbeit.

Die Regel, die es wirksam macht: WIP-Limits

Wenn ein Konzept Teams, die Kanban richtig nutzen, von Teams mit einer bloß hübscheren To-do-Liste unterscheidet, dann sind es Work-in-Progress-Limits – kurz WIP-Limits. Die Idee: Jede Spalte darf nur eine maximale Zahl von Einträgen gleichzeitig enthalten. Ist eine Spalte voll, kann keine neue Arbeit hinzukommen, bevor etwas abgeflossen ist.

Das fühlt sich widersinnig an. Wird nicht mehr erledigt, wenn mehr Aufgaben gleichzeitig laufen dürfen? Nein. Wenn Menschen an zu vielen Dingen gleichzeitig arbeiten, dauert in Wahrheit alles länger. Kontextwechsel sind teuer. Halbfertige Arbeit erzeugt Abstimmungsaufwand. Und wenn zehn Dinge „in Arbeit“ sind, lässt sich kaum erkennen, welche tatsächlich vorankommen und welche nur unmarkiert feststecken.

Ein WIP-Limit von drei in der Spalte „In Arbeit“ bedeutet: Wenn die vierte Aufgabe auf dem Tisch landet, muss jemand im Team entscheiden, welche bestehende Aufgabe zuerst fertig wird. Das erzwingt Priorisierung. Es erzwingt Gespräche. Und es führt tendenziell dazu, dass einzelne Aufgaben schneller abgeschlossen werden, auch wenn das Tempo beim Starten neuer sinkt.

Kanban versus Scrum: die Frage, die Teams immer stellen

Wer sich mit Softwareteams oder modernem Operations-Denken beschäftigt hat, ist vermutlich auf Scrum gestoßen – das Framework, das Arbeit in feste Zwei-Wochen-Sprints gliedert, mit Planungssitzungen, Retrospektiven und definierten Rollen wie Scrum Master und Product Owner. Viele Teams sehen Scrum und Kanban als konkurrierende Methoden und glauben, sich entscheiden zu müssen. Der Unterschied ist eigentlich einfacher.

Viele Teams – besonders solche, die keine reinen Softwareentwicklungsteams sind – empfinden Scrums Zeremonien als schwerfällig und die feste Sprint-Struktur als sperrig für laufende operative Arbeit. Marketing-, Customer-Success- und Operations-Teams sowie Gründer, die alles gleichzeitig managen, haben selten Arbeit, die sauber in Zwei-Wochen-Zyklen passt. Kanbans kontinuierliches Flussmodell passt meist besser zu ihnen.

Das heißt nicht, dass man sich entscheiden muss: Viele Teams kombinieren beides. Sie nutzen sprintartige Planungszyklen für die Produktentwicklung und führen ein Kanban-Board für die operative und Support-Arbeit, die unabhängig vom aktuellen Sprint hereinkommt. Das ist ein völlig vernünftiger Hybrid.

Die drei Fragen, die Ihr Board in dreißig Sekunden beantworten sollte

Ein Kanban-Board ist am nützlichsten, wenn Sie es ansehen und – ohne mit jemandem zu sprechen – rasch diese drei Fragen beantworten können: Woran arbeitet das Team gerade? Wo bleibt Arbeit hängen? Gibt es etwas, das erledigt werden sollte, aber noch nicht begonnen wurde?

Wenn Sie nicht alle drei innerhalb von dreißig Sekunden nach einem Blick auf das Board beantworten können, wird es wahrscheinlich nicht richtig gepflegt. Das häufigste Fehlermuster ist ein Board, auf dem Aufgaben angelegt, aber nie verschoben werden – es wird zum Friedhof guter Absichten statt zur Live-Karte der tatsächlichen Arbeit. Ein Board, das nicht aktuell ist, ist schlimmer als gar keins, denn es vermittelt ein falsches Gefühl von Transparenz.

Die Disziplin, die es braucht, um ein Board zu pflegen, ist nicht zu unterschätzen. Aufgaben müssen sich bewegen, wenn sich die Arbeit bewegt. Blockierte Einträge müssen markiert werden, sobald sie stocken, nicht erst zwei Wochen später. Karten brauchen klare Verantwortliche, und die Verantwortlichen müssen ihre Karten aktualisieren. Nichts davon kostet viel Zeit – eine gut geführte Kanban-Praxis kostet vielleicht fünf bis zehn Minuten pro Person und Tag –, aber es erfordert Konsequenz. Am meisten profitieren die Teams von Kanban, die das Board als Single Source of Truth behandeln, nicht als zusätzliche Dokumentationsübung.

Was Kanban nicht leistet

Kanban ist kein Strategiewerkzeug. Es hilft Ihnen nicht herauszufinden, woran Sie arbeiten sollten – nur dabei, das zu steuern, wofür Sie sich bereits entschieden haben. Hat Ihre Organisation ein Priorisierungsproblem, ein Problem mit unklarem Mandat oder das Problem „wir starten zu viele Projekte, bevor wir alte beenden“, das im Führungsverhalten statt im Prozess wurzelt, wird ein Kanban-Board diese Probleme offenlegen, aber nicht lösen.

Es ersetzt auch keine gute Führung. Ein Board ersetzt keine Einzelgespräche, keine überlegte Delegation und keine klare Kommunikation darüber, warum bestimmte Arbeit wichtig ist. Teams führen manchmal Prozesswerkzeuge ein in der Hoffnung, der Prozess übernehme die zwischenmenschliche und organisatorische Arbeit, die eigentlich Aufgabe der Führungskraft ist. Das tut er nicht.

Was es tut: Es verringert die diffuse Unsicherheit, die die meisten Teams ausbremst. Die Fragen „Wer arbeitet woran“, „Ist das fertig“ und „Was nehme ich als Nächstes“ erzeugen in Organisationen ohne gemeinsames, sichtbares System enorme Mengen an wenig wertschöpfender Kommunikation. Kanban beseitigt den Großteil dieses Rauschens. Und für Teams, bei denen dieses Rauschen das Hauptproblem ist, macht das einen deutlichen Unterschied.

So starten Sie – ohne dreitägigen Workshop

Die besten Kanban-Einführungen, die ich gesehen habe, begannen klein und entwickelten sich weiter. Die schlechtesten umfassten einen Berater, ein zweitägiges Offsite und ein wunderschön gestaltetes Board, das in Woche drei niemand mehr nutzte.

Starten Sie mit Ihrem Team, wie es wirklich ist, und der Arbeit, die Sie wirklich haben. Legen Sie drei Spalten an: Backlog, In Arbeit, Erledigt. Verbringen Sie dreißig Minuten mit Ihrem Team damit, jede aktuelle Aufgabe auf eine Karte zu bringen. Einigen Sie sich auf eine einzige Regel: Was Sie anfangen, kommt aufs Board. Bewegt sich etwas, verschieben Sie die Karte. Tun Sie zwei Wochen lang sonst nichts.

Nach zwei Wochen schauen Sie sich das Board gemeinsam an. Wo haben sich Dinge gestaut? Was blieb im Backlog, obwohl alle sagten, es sei eine Priorität? Was ging schneller voran als erwartet? Was blieb stecken, und warum? Nutzen Sie Ihre Beobachtungen, um die Spalten zu verfeinern und zu präzisieren. Vielleicht muss „In Arbeit“ in „In Arbeit“ und „Wartet auf Externe“ geteilt werden. Vielleicht brauchen Sie eine Spalte „Im Review“, weil dieser Schritt ständig untergeht. Lassen Sie das Board sich nach dem entwickeln, was Ihre tatsächliche Arbeit zeigt, nicht nach dem, was ein Methodenbuch vorschreibt.

Die längere Perspektive: Flow-Kennzahlen

Sobald ein Kanban-System läuft, erzeugt es Daten, die die meisten Teams nie nutzen. Die wichtigste ist die Durchlaufzeit (Lead Time) – die Gesamtzeit von der Anlage einer Aufgabe bis zu ihrem Abschluss. Liegt Ihre durchschnittliche Lead Time für eine typische Aufgabe bei zwölf Tagen und soll auf fünf sinken, haben Sie jetzt eine Zahl, an der Sie arbeiten können, und ein Board, das Ihnen zeigt, wohin die zusätzlichen sieben Tage gehen.

Die Zykluszeit (Cycle Time) misst nur die aktive Bearbeitungsphase, ohne die Zeit, die eine Aufgabe im Backlog liegt. Der Durchsatz (Throughput) misst, wie viele Einträge Ihr Team pro Woche abschließt. Keine dieser Kennzahlen erfordert Spezialsoftware, wenn Sie diszipliniert festhalten, wann Karten angelegt und wann sie geschlossen werden. Zusammen ergeben sie ein deutlich ehrlicheres Bild der Kapazität Ihres Teams als jede schätzungsbasierte Planung.

Die meisten kleinen und mittelgroßen Teams kommen nie so weit. Sie nutzen Kanban als Transparenzwerkzeug – was für sich genommen wertvoll ist – und gehen nicht weiter. Das ist in Ordnung. Wenn Sie aber Stakeholdern verbindliche Zusagen machen wollen, wann etwas fertig ist, oder verstehen möchten, warum manche Arbeit dreimal so lange dauert wie erwartet, sind die Kennzahlen da, wenn Sie sie brauchen.