"Kanban im Projekt: Warum Flow wichtiger ist als der Fortschrittsbalken"

Wenn das Board voll ist, aber nichts fertig wird

Im wöchentlichen Status-Meeting sieht das Kanban-Board gut gefüllt aus: Dutzende Karten, drei Spalten, alles digital, alles sichtbar. Auf Nachfrage heißt es "läuft", "ist zu 80 Prozent fertig" oder "kommt diese Woche noch". Nur: Diese Aussage stand auch schon letzte Woche so im Protokoll. Und die Woche davor. Am Ende der Spalte "In Arbeit" stauen sich zwölf Karten, während "Fertig" seit Tagen kaum wächst.

Das Problem liegt selten an mangelndem Einsatz. Es liegt daran, dass viele Teams Kanban nur als visuelles Klebezettel-Brett nutzen – ohne die beiden Elemente, die aus einem hübschen Board ein echtes Steuerungsinstrument machen: das Pull-Prinzip und WIP-Limits. Ohne sie zeigt das Board zwar, woran gearbeitet wird. Es zeigt aber nicht, warum es nicht vorangeht.

Warum Prozentangaben das falsche Signal senden

"80 Prozent fertig" klingt nach Fortschritt, sagt aber wenig über den tatsächlichen Zustand einer Aufgabe aus. Eine Aufgabe kann wochenlang bei 80 Prozent verharren, weil sie auf eine Freigabe wartet, weil eine Spezialistin gleichzeitig an vier anderen Tickets sitzt, oder weil ständig neue, vermeintlich dringendere Anfragen dazwischengeschoben werden. Der Prozentwert misst investierte Arbeit, nicht Durchlauf.

Kanban dreht diese Logik um. Statt zu fragen "Wie weit ist die Aufgabe?", fragt die Methode: "Wie lange braucht eine Aufgabe im Durchschnitt, um das System zu durchlaufen – und wie viele schaffen es pro Woche bis ganz nach rechts?" Das ist eine unbequemere, aber ehrlichere Frage, weil sie Engpässe offenlegt, die ein Statusbericht gerne kaschiert.

Das Prinzip dahinter: Pull statt Push, und die Grenze, die schützt

Der Kern der Kanban-Methode, wie sie David J. Anderson für Wissensarbeit systematisiert hat, sind zwei einfache Regeln: Erstens wird Arbeit nicht in ein Team hineingedrückt (Push), sondern von ihm gezogen (Pull) – eine neue Karte darf erst starten, wenn dafür Kapazität frei ist. Zweitens bekommt jede Spalte im Workflow ein explizites WIP-Limit, also eine feste Obergrenze an Karten, die gleichzeitig dort liegen dürfen.

Das klingt zunächst nach einer künstlichen Bremse, ist in der Praxis aber ein Schutzmechanismus gegen die eigentliche Ursache von Verzögerung: zu viel gleichzeitig begonnene, zu wenig gleichzeitig abgeschlossene Arbeit. Wer an fünf Dingen parallel arbeitet, erledigt selten fünf Dinge schneller als jemand, der sich nacheinander auf zwei konzentriert – Kontextwechsel kosten Zeit, erhöhen die Fehlerquote und verstecken Probleme, bis sie kurz vor der Deadline auffallen.

Eine bewährte Faustregel für den Einstieg: WIP-Limit je Spalte grob an der Zahl der Personen ausrichten, die dort typischerweise arbeiten – oft ein bis zwei Karten pro Kopf, nicht mehr. Das Limit wird dabei bewusst konservativ gewählt und dann iterativ angepasst, nicht am Reißbrett final festgelegt. Wird ein Limit ständig gerissen, ist das kein Grund, es zu erhöhen, sondern ein Signal, den dahinterliegenden Engpass zu untersuchen.

Die Zahlen, die tatsächlich etwas aussagen

Drei Kennzahlen ersetzen im Kanban den Prozentbalken:

Die Durchlaufzeit (Cycle Time) misst, wie lange eine Karte im Schnitt von Start bis Fertigstellung braucht. Der Durchsatz (Throughput) zeigt, wie viele Karten pro Zeiteinheit das System verlassen. Und die laufende Arbeit (WIP) gibt an, wie viele Karten sich aktuell gleichzeitig im System befinden.

Diese drei Größen hängen über eine einfache, aus der Warteschlangentheorie stammende Beziehung zusammen, bekannt als Little's Law: WIP entspricht Durchsatz multipliziert mit Durchlaufzeit. Sind zwei der drei Werte bekannt, lässt sich der dritte berechnen – unabhängig davon, was genau bearbeitet wird. Praktisch bedeutet das: Wer die Durchlaufzeit senken will, ohne den Durchsatz zu verändern, kommt an einem Hebel nicht vorbei – weniger gleichzeitig begonnene Arbeit.

Sichtbar wird das über ein Cumulative-Flow-Diagram, das die Anzahl der Karten je Spalte über die Zeit als gestapelte Fläche darstellt. Verbreitert sich eine mittlere Spalte im Diagramm zunehmend, staut sich dort Arbeit – der Engpass lässt sich Wochen vor der ersten verpassten Deadline erkennen, nicht erst danach.

Kanban richtig einführen: eine kurze Checkliste

Wer Kanban nicht nur als Board-Tapete, sondern als Steuerungsinstrument nutzen will, geht typischerweise in dieser Reihenfolge vor: den tatsächlichen Workflow zunächst so abbilden, wie er wirklich ist, nicht wie er sein sollte; für zwei bis drei Wochen die heutige Durchlaufzeit als Ausgangswert messen, bevor irgendetwas verändert wird; anschließend bewusst niedrige WIP-Limits je Spalte setzen; das Cumulative-Flow-Diagram wöchentlich anschauen und Engpässe gezielt adressieren, statt Limits vorschnell zu lockern; und die Limits im Sinne von Kaizen regelmäßig, aber in kleinen Schritten nachjustieren.

Wichtig ist dabei die Abgrenzung zu Scrum: Kanban kommt ohne feste Sprints, Schätzungen oder Rollen aus und eignet sich besonders für Teams mit unregelmäßigem Arbeitsanfall – etwa Support, Wartung, IT-Betrieb oder Projektportfolios mit vielen kleinen, unterschiedlich priorisierten Anfragen. Für Teams, die in klar geschnittenen, planbaren Inkrementen liefern, bleibt Scrum oft die passendere Wahl; beide Ansätze lassen sich in hybriden Konstellationen auch kombinieren.

Ein typisches Beispiel

Ein mittelständisches IT-Team betreut parallel laufende Wartungstickets und kleinere Projektanfragen aus dem Fachbereich. Auf dem Board stapeln sich in der Spalte "In Bearbeitung" regelmäßig über zwanzig Karten, weil jede neue Anfrage sofort gestartet wird. Nach Einführung eines WIP-Limits von sechs Karten für diese Spalte müssen neue Anfragen zunächst in eine sichtbare Warteschlange – unangenehm für alle, die "ihr" Ticket sofort bearbeitet sehen wollen. Nach wenigen Wochen zeigt sich im Cumulative-Flow-Diagram jedoch, dass ein einzelner Freigabeschritt vor dem Release der eigentliche Engpass war. Wird dieser Schritt entschärft, sinkt die durchschnittliche Durchlaufzeit spürbar, und die anfängliche Warteschlange löst sich schneller auf als erwartet – weil das Team nun erstmals sieht, wo die Zeit tatsächlich verloren geht.

Auf den Punkt

Ein volles Kanban-Board ist kein Beleg für Fortschritt, sondern oft ein Symptom für zu viel gleichzeitig begonnene Arbeit. Wer stattdessen mit WIP-Limits, Durchlaufzeit, Durchsatz und einem Cumulative-Flow-Diagram steuert, tauscht das beruhigende, aber unscharfe Prozentbild gegen eine unbequemere, dafür belastbare Sicht auf den tatsächlichen Zustand eines Projekts.