Kanban einfach erklärt: Arbeit sichtbar machen und im Fluss bleiben

Kanban wird oft auf „ein Board mit Spalten” reduziert. Das greift zu kurz. Kanban ist eine Management Methode, um Arbeit sichtbar zu machen, den Fluss zu steuern und einen bestehenden Prozess Schritt für Schritt zu verbessern — ohne ihn vorher komplett umzukrempeln.

01 · HerkunftWoher Kanban kommt

Seinen Ursprung hat es in der Produktion bei Toyota, wo Kanban-Karten den Materialfluss steuerten. Jahrzehnte später übertrug David J. Anderson dieses Prinzip auf die Wissensarbeit und die Softwareentwicklung. Aus einem Werkzeug der Fertigung wurde die Methode, wie wir sie heute in Teams nutzen. Der Grundgedanke blieb derselbe: Arbeit sichtbar machen, den Fluss steuern, Überlastung vermeiden.

02 · PrinzipienBeginne dort, wo du stehst

Der vielleicht wichtigste Unterschied zu Scrum: Kanban verlangt keinen Big Bang. Wo Scrum als Rahmenwerk auf einmal eingeführt wird, geht Kanban den umgekehrten Weg — kontinuierliche Verbesserung in kleinen Schritten. Anderson stellte dazu drei Prinzipien an den Anfang:

Genau das macht die Einführung so niedrigschwellig: Du musst nichts abschaffen, um zu beginnen.

03 · KernpraktikenDie sechs Kanbankernpraktiken

Auf diesen Prinzipien bauen sechs konkrete Praktiken auf. Erst zusammen ergeben sie ein Kanban-System — und machen aus dem Board mehr als eine bebilderte Aufgabenliste.

1. Visualisiere: Mach zuerst den Prozess sichtbar — den Weg, den die Arbeit durch dein Team nimmt — und dann die Arbeit, die gerade darauf unterwegs ist. Nicht jede Kleinigkeit gehört aufs Board; es geht um den Fluss, nicht um eine Aufgabenliste. Erst was sichtbar ist, lässt sich steuern.
2. Begrenze die parallele Arbeit (WIP): Frag dich, wie hoch der Stresspegel ist, wenn du fünfzehn Dinge gleichzeitig bearbeitest — und wie hoch bei fünf. Weniger Gleichzeitigkeit senkt die Durchlaufzeit. Wer zu viel parallel offen hält, wird langsamer, nicht schneller. Klare WIP-Limits legen bewusst fest, wie viel gleichzeitig in Arbeit sein darf.
3. Steuere den Fluss: Kümmere dich um die Stellen, an denen Arbeit ins Stocken gerät — die Engpässe. Ein Engpass verschwindet nie ganz: Hast du einen aufgelöst, wird der nächste Schritt zum begrenzenden. Fluss steuern heißt deshalb, sich fortlaufend um den jeweils engsten Punkt zu kümmern.
4. Mache Regeln explizit: An jedem Schritt hängen Regeln, wie Arbeit hinein- und wieder herauskommt. Zwei verbreitete Beispiele: die Definition of Ready (wann ist eine Anforderung startklar) und die Definition of Done (wann ist etwas fertig, in welcher Qualität). Solche Regeln werden ausgesprochen, definiert und nicht stillschweigend vorausgesetzt.
5. Etabliere Feedback-Schleifen: regelmäßige Termine (Kadenzen), in denen Team und Beteiligte auf ihre Arbeit schauen und nachsteuern (siehe unsere Retrospektiven-Reihe). Sie halten die Verbesserung in Gang.
6. Verbessere gemeinsam, entwickle experimentell: Verbesserung passiert nicht per Anordnung, sondern als Folge kleiner, gemeinsam gesetzter Experimente — ausprobieren, beobachten, behalten oder verwerfen.

04 · BoardDas Kanban-Board

Das Board ist der sichtbare Kern der Methode — ob als physisches Whiteboard oder digitales Tool. Jede Spalte steht für einen Schritt im Arbeitsablauf, von links (offen) bis rechts (fertig). Jede Aufgabe wird zu einer Karte, die von Spalte zu Spalte wandert. So zeigt das Board jederzeit, wo eine Aufgabe steht — und Muster im Ablauf fallen sofort auf: Wo sich Karten stauen, siehst du auf einen Blick, an welcher Stelle es klemmt.

05 · PullPull statt Push

Kanban ist ein Pull-System: Arbeit wird nicht zugeteilt, sondern gezogen – anhand der freien Kapazität. Eine neue Aufgabe kommt erst dann ins System, wenn Kapazität frei wird — das Team holt sich die nächste selbst. So entsteht keine Überlastung, und ein Stau wird sichtbar, statt kaschiert zu werden.

06 · KennzahlenFluss messen und vorhersagen

Die Kapazität wird gesteuert über WIP-Limits — sichtbar gemacht wird der Fluss über Kennzahlen: den Durchsatz (wie viel pro Zeitraum fertig wird), die Durchlaufzeit (wie lange eine Aufgabe vom Start bis fertig braucht) und den WIP selbst. Diese drei hängen über Little’s Law zusammen: Je mehr gleichzeitig offen ist, desto länger dauert im Schnitt jede einzelne Aufgabe. Die Kennzahlen zeigen, ob der Prozess stockt, und machen Durchlaufzeiten planbar — ohne dass jede Aufgabe einzeln geschätzt werden muss.

07 · PriorisierungServiceklassen: nicht alles ist gleich dringend

Nicht jede Arbeit verlangt dieselbe Behandlung. Eine dringende Störung folgt anderen Regeln als eine geplante Weiterentwicklung oder eine Aufgabe mit festem Liefertermin. Solche Kategorien heißen Serviceklassen – sie sind nichts anderes als gemeinsam definierte Priorisierungsregeln. Das Team einigt sich vorab, was Vorrang hat und wie verschiedene Arten von Arbeit behandelt werden. So wird Priorisierung zur abgestimmten Regel — und nicht zur Frage, wer am lautesten ruft.

08 · VergleichKanban und Scrum

Scrum und Kanban sind keine Gegner, sondern unterschiedliche Antworten auf unterschiedliche Situationen. Scrum ist ein Rahmenwerk mit festen Takten, klaren Verantwortlichkeiten und Events. Kanban ist eine Methode, die sich über den bestehenden Prozess legt und ihn nach und nach verbessert. Damit bringt Kanban die geringste Startschwelle mit — und beides lässt sich sogar verbinden und wir dann gerne als Scrumban oder Kanrum bezeichnet.

09 · EinordnungWofür und für wen sich Kanban eignet

Ziel von Kanban ist nicht, mehr zu arbeiten, sondern ruhiger und klüger: weniger Gleichzeitigkeit, kürzere Wege, ein stabiler Fluss. Weil das ohne Umbau des Prozesses funktioniert, ist die Hürde niedrig. Und es passt überall dort, wo Arbeit durch mehrere Schritte fließt — vom Entwicklungsteam bis in die Verwaltung. Kanban hilft dem Team, den eigenen Fluss sichtbar zu machen, statt ihn nur zu behaupten.

Eine Frage zum Schluss: Wo in deinem Berufsalltag bleibt Arbeit am häufigsten liegen — und was würde passieren, wenn du dort die Zahl paralleler Aufgaben halbierst?

Über den Autor

Stefan Mönk

Gründer der Guided Agile Community (GAC), PSM III-zertifiziert und Dozent an der Universität Hildesheim. Stefan begleitet Praktiker:innen dabei, agiles Wissen iterativ und praxisnah im Berufsalltag zu verankern.

Mehr über Stefan auf LinkedIn