Kanban-System: Ursprünge, Prinzipien und PMO-Einführung für gemischte Portfolios
Kanban ist einer der am häufigsten missverstandenen Begriffe im Projektmanagement, vor allem weil zwei sehr unterschiedliche Dinge denselben Namen tragen. Das Kanban-Board ist ein visuelles Werkzeug, Spalten und Karten, bekannt von der Wand fast jedes zweiten Software-Teams. Das Kanban-System ist der Rahmen um dieses Werkzeug: Richtlinien, WIP-Limits, Flusskennzahlen, Feedbackschleifen und die sechs Praktiken, die aus Kanban eine Disziplin machen statt einer Whiteboard-Übung. Beides zu verwechseln ist der Grund, warum so viele Kanban-Einführungen stagnieren: Das Team bekommt das Board, aber nie das System. Dieser Artikel erklärt, was das Kanban-System wirklich ist, woher es stammt, wie es sich von einem Kanban-Board unterscheidet, wann man es Scrum vorzieht und wie ein PMO Kanban über ein gemischtes Portfolio hinweg einführt. Er richtet sich an Projektleiter und PMO-Analysten, die Kanban im organisatorischen Kontext zum Laufen bringen müssen, nicht nur das Board eines einzelnen Teams moderieren.
Wichtigste Erkenntnisse:
- Das System ist mehr als das Board: Ein Kanban-Board ist ein einzelnes visuelles Artefakt, doch das Kanban-System ergänzt WIP-Limits, explizite Richtlinien, Flusskennzahlen und Feedbackschleifen. Die meisten Einführungen stocken, weil Teams das Board bekommen und das System nie installieren.
- Es entstand bei Toyota: Kanban begann als Pull-basierte Signalmethode in den Produktionslinien von Toyota und gelangte später in die Softwareentwicklung und die Wissensarbeit. Die Kernidee trägt: Zu viel angefangene Arbeit zerstört den Fluss.
- Sechs Praktiken machen daraus eine Disziplin: Arbeit visualisieren, WIP begrenzen, Fluss steuern, Richtlinien explizit machen, Feedbackschleifen betreiben und gemeinsam verbessern. Zusammen verwandeln sie einen bestehenden Workflow in ein gesteuertes System, ohne das Team umzubauen.
- Flusskennzahlen zeigen, ob es funktioniert: Zykluszeit, Durchlaufzeit, Durchsatz und das kumulative Flussdiagramm zeigen, wie schnell und vorhersehbar Arbeit voranschreitet. Sie ersetzen Meinung durch Belege, wenn ein PMO die Lieferung überprüft.
- Kanban und Scrum lösen unterschiedliche Probleme: Scrum passt zu vorhersehbarer, iterationsbasierter Feature-Arbeit, während Kanban zu kontinuierlichem, serviceorientiertem oder unterbrechungsgetriebenem Fluss passt. Ein PMO betreibt oft beides über ein gemischtes Portfolio hinweg.
Was ist das Kanban-System
Das Kanban-System ist ein Rahmenwerk zur Workflow-Steuerung, das die visuelle Darstellung der Arbeit, WIP-Limits, den Pull-basierten Aufgabenfluss und die kontinuierliche Verbesserung zu einem stimmigen Betriebsmodell für Teams in der Wissensarbeit verbindet. Es ist keine Projektmanagement-Methodik im Sinne von Scrum: Kanban schreibt keine Rollen, Zeremonien oder festen Iterationen vor. Es schreibt eine Reihe von Praktiken vor, die jeder bestehende Workflow übernehmen kann, ohne das Team umzustrukturieren, Positionsbezeichnungen zu ändern oder neue Meetings anzusetzen. Deshalb verbreitete sich das Kanban-System von der Fertigung über die Software bis hin zu Marketing, Personalwesen und IT-Betrieb: Es legt sich über das, was ein Team ohnehin bereits tut.
Das System hat vier Kernmechaniken, die zusammenwirken. Die Visualisierung macht Arbeit auf einer gemeinsamen Darstellung sichtbar (physisch oder digital), sodass alle denselben aktuellen Stand sehen. WIP-Limits begrenzen die Menge angefangener Arbeit in jeder Workflow-Phase und zwingen das Team, Aufgaben abzuschließen, bevor neue begonnen werden. Pull ersetzt Push: Arbeit rückt nur vor, wenn stromabwärts Kapazität frei wird, statt von demjenigen hineingedrückt zu werden, der sie erzeugt. Flusskennzahlen messen, wie schnell und vorhersehbar Arbeit durch das System läuft, und machen Engpässe sichtbar, bevor sie zu Verzögerungen werden.
Die Ursprünge: von Toyota zur Wissensarbeit
Kanban entstand im Toyota-Produktionssystem der 1940er- und 1950er-Jahre. Das japanische Wort kanban bedeutet Schild oder Karte, und in Toyotas Fabriken war eine Kanban-Karte ein physisches Signal: Sie autorisierte die Produktion oder den Nachschub eines Teils erst dann, wenn stromabwärts tatsächlich Bedarf bestand. Das kehrte die übliche Logik um. Statt Teile auf Vorrat zu produzieren und Lager anzuhäufen, zog jede Station Arbeit erst heran, wenn die nächste Station bereit war. Das Ergebnis waren geringere Bestände, kürzere Durchlaufzeiten und Probleme, die früh sichtbar wurden.
Der Sprung in die Wissensarbeit kam Jahrzehnte später. In den 2000er-Jahren übertrug David J. Anderson dieselben Prinzipien auf Softwareentwicklung und IT und formulierte Kanban als Methode zur evolutionären Veränderung. Die Erkenntnis blieb dieselbe: Zu viel gleichzeitige Arbeit zerstört den Fluss, und sichtbare Grenzen stellen ihn wieder her. Genau deshalb funktioniert dasselbe Muster von Autoteilen über Softwarefunktionen bis zu Marketingkampagnen.
Kanban-System und Kanban-Board: die entscheidende Unterscheidung
Die häufigste Verwechslung in Kanban-Diskussionen besteht darin, Board und System als Synonyme zu behandeln. Das sind sie nicht. Das Kanban-Board ist ein einzelnes visuelles Artefakt, Spalten stehen für Workflow-Phasen, Karten für Arbeitselemente. Das Kanban-System ist das vollständige Rahmenwerk: Das Board ist eine Komponente, neben WIP-Limits, expliziten Richtlinien, Flusskennzahlen, Kadenzen (regelmäßige Meetings und Reviews) und den sechs Praktiken. Ein Team kann ein Kanban-Board ohne ein Kanban-System haben, und der Unterschied zeigt sich in den Ergebnissen.
Man stelle sich vor, was passiert, wenn ein Team nur das Board einführt. Jemand erstellt Spalten mit den Bezeichnungen zu erledigen, in Arbeit und erledigt, alle verschieben ihre Karten, und äußerlich sieht es nach Kanban aus. Doch ohne WIP-Limits füllt sich die Spalte in Arbeit weiter, ohne explizite Richtlinien deutet jeder erledigt anders, und ohne Flusskennzahlen weiß niemand, ob sich die Lieferung verbessert oder verschlechtert. Das Board macht die Arbeit sichtbar, aber erst das System macht sie steuerbar. Deshalb geht es beim Wechsel vom Board zum System nicht um bessere Software, sondern um Richtlinien, Grenzen und Messung.
Unser Kanban-Workflow-Leitfaden und Kanban-Board-Leitfaden behandeln das Board und seine Nutzung ausführlich; dieser Artikel konzentriert sich auf das System, das es umgibt.
Erleben Sie Projektsteuerung auf neuem Niveau mit fortschrittlicher PPM-Software, jetzt kostenlos.
Die sechs Praktiken eines Kanban-Systems
Ein Kanban-System ruht auf sechs Kernpraktiken. Zusammen machen sie den Unterschied zwischen einem Team, das ein Board benutzt, und einem Team, das einen Fluss steuert. Jede Praktik ist für sich einfach; ihre Wirkung entsteht daraus, dass sie gemeinsam angewendet werden.
Arbeit visualisieren
Die gesamte Arbeit wird auf einem gemeinsamen Board sichtbar gemacht, sodass jeder denselben Stand sieht. Sichtbarkeit allein deckt bereits Engpässe, blockierte Elemente und ungleiche Auslastung auf, die in Aufgabenlisten verborgen bleiben.
Angefangene Arbeit begrenzen
Jede Phase erhält ein WIP-Limit, eine Obergrenze für die Zahl gleichzeitig laufender Elemente. Grenzen zwingen das Team, Angefangenes zu beenden, bevor Neues begonnen wird, und genau dadurch beginnt Arbeit schneller und vorhersehbarer zu fließen.
Fluss steuern
Das Team beobachtet, wie Arbeit durch die Phasen läuft, und greift dort ein, wo sie ins Stocken gerät. Ziel ist ein gleichmäßiger, vorhersehbarer Fluss, nicht die maximale Auslastung jeder Person.
Richtlinien explizit machen
Die Regeln des Systems, was erledigt bedeutet, wann eine Karte weiterwandern darf, wie Prioritäten gesetzt werden, werden ausgesprochen und aufgeschrieben. Explizite Richtlinien beenden stille Meinungsverschiedenheiten und machen das System lehr- und verbesserbar.
Feedbackschleifen einrichten
Regelmäßige Kadenzen, tägliche Abstimmung, Fluss-Review und Retrospektive, geben dem System Gelegenheiten, sich selbst zu überprüfen und zu korrigieren. Ohne Schleifen wird ein Board statisch und driftet von der Realität ab.
Gemeinsam verbessern
Veränderung erfolgt schrittweise und auf Basis von Belegen, nicht durch große Umbrüche. Das Team nutzt seine Kennzahlen und Beobachtungen, um kleine Experimente durchzuführen und zu behalten, was den Fluss messbar verbessert.
Kernkennzahlen eines Kanban-Systems
Kanban ersetzt Meinung durch Belege, und die Belege kommen aus vier Kennzahlen. Sie beantworten die Fragen, die jedes PMO zur Lieferung stellt: Wie lange dauert Arbeit, wie viel schaffen wir und wo staut es sich.
Zykluszeit und Durchlaufzeit
Die Zykluszeit misst, wie lange ein Element von Arbeitsbeginn bis zur Fertigstellung braucht. Die Durchlaufzeit misst länger, vom Moment, in dem eine Anfrage eintrifft, bis zur Lieferung, und umfasst damit auch die Wartezeit vor Arbeitsbeginn. Kunden erleben die Durchlaufzeit; Teams steuern die Zykluszeit.
Durchsatz und kumulatives Flussdiagramm
Der Durchsatz zählt, wie viele Elemente pro Zeitraum abgeschlossen werden, und ist die einfachste Grundlage für Prognosen. Das kumulative Flussdiagramm stellt die Arbeit je Phase im Zeitverlauf dar; sich verbreiternde Bänder zeigen wachsende Warteschlangen, und der horizontale Abstand zwischen den Bändern zeigt die Durchlaufzeit auf einen Blick. Zusammen verwandeln diese Kennzahlen ein subjektives Gefühl, wie es läuft, in belastbare Zahlen.
Kanban und Scrum: welches Rahmenwerk wählen
Kanban und Scrum werden oft gegenübergestellt, doch sie lösen unterschiedliche Probleme. Scrum ist iterationsbasiert: Arbeit wird in Sprints festgelegt, das Team liefert an Sprintgrenzen und arbeitet mit festen Rollen und Zeremonien. Kanban ist kontinuierlicher Fluss: Arbeit läuft durch den Workflow, sobald Kapazität frei wird, ohne feste Iterationen, und schreibt Praktiken statt Rollen vor. Keines ist überlegen; sie passen zu unterschiedlichen Arbeitsformen.
Scrum passt gut zu vorhersehbarer Feature-Arbeit, die sich sinnvoll in Sprints planen lässt, etwa der Aufbau eines Produkts entlang einer Roadmap. Kanban passt zu kontinuierlicher, serviceorientierter oder unterbrechungsgetriebener Arbeit, bei der sich Prioritäten täglich verschieben, etwa Betrieb, Support oder Wartung. Viele reife Organisationen betreiben beides nebeneinander, und ein PMO, das ein gemischtes Portfolio steuert, muss selten eines für alle wählen. Die praktische Frage lautet nicht Kanban oder Scrum, sondern welches Rahmenwerk zu welcher Art von Arbeit passt.
Unser Scrum-Methodik-Leitfaden behandelt das Rahmenwerk ausführlich.
Ein Kanban-System im PMO-Kontext einführen
Ein einzelnes Team von einem Board zu einem System zu bringen, ist eine Sache. Kanban über ein Portfolio hinweg im PMO-Kontext einzuführen, ist eine andere, denn nun geht es um mehrere Teams, unterschiedliche Arbeitsformen und den Bedarf an einem einheitlichen Überblick. Hier zahlt sich der Unterschied zwischen Board und System am stärksten aus.
Klein anfangen: von der Visualisierung zum vollständigen System
Der zuverlässigste Weg beginnt mit einem Team, das echten Schmerz mit dem Fluss hat. Zuerst wird dessen Arbeit visualisiert, dann werden WIP-Limits ergänzt, dann Richtlinien explizit gemacht und schließlich Kennzahlen eingeführt. Ist das System bei einem Team verankert, dient es als Vorlage für die nächsten, statt allen gleichzeitig einen Prozess überzustülpen.
Portfolio-Sicht für das PMO
Ein PMO braucht mehr als einzelne Team-Boards; es braucht einen Überblick, der zeigt, wie Arbeit über Projekte und Abteilungen hinweg fließt. In FlexiProject visualisiert das Kanban-Board Aufgaben nach Organisationsabteilungen und macht Engpässe und ungleiche Auslastung auf Portfolioebene sichtbar. So sieht das PMO nicht nur den Status einzelner Projekte, sondern das Muster der Lieferung im gesamten Portfolio.
Einheitliche Richtlinien, lokale Flexibilität
Die Kunst besteht darin, genug zu standardisieren, dass das Portfolio vergleichbar bleibt, und genug Freiraum zu lassen, dass jedes Team seine Arbeit abbilden kann. Gemeinsame Definitionen von erledigt, gemeinsame Kennzahlen und eine gemeinsame Kadenz geben dem PMO ein belastbares Gesamtbild, während jedes Team seine eigenen Spalten und Limits behält.
Wenn Teams für ihre Kanban-Arbeit bereits Jira nutzen, importiert die FlexiProject-Jira-Integration ihre Aufgaben unter Beibehaltung von Status, Verantwortlichem und Typ, sodass die PMO-Ansichten aktuell bleiben, ohne dass die Teams das Werkzeug wechseln.
Bringen Sie Ihre Projekte mit fortschrittlicher PPM-Software voran, FlexiProject 30 Tage gratis.
FAQ: das Kanban-System
Was ist der Unterschied zwischen Kanban und Scrum?
Scrum ist iterationsbasiert: Arbeit wird in Sprints festgelegt (typisch zwei Wochen), und das Team liefert an Sprintgrenzen. Kanban ist kontinuierlicher Fluss: Arbeit läuft durch den Workflow, sobald Kapazität es zulässt, ohne feste Iterationen. Scrum schreibt Rollen (Product Owner, Scrum Master, Entwicklungsteam) und Zeremonien vor. Kanban schreibt Praktiken vor, aber keine bestimmten Rollen oder Ereignisse. Scrum passt zu vorhersehbarer Feature-Arbeit; Kanban zu kontinuierlicher, serviceorientierter oder unterbrechungsgetriebener Arbeit.
Wie berechnet man WIP-Limits?
Es gibt keine allgemeingültige Formel; der praktische Ansatz ist empirisch. Ein verbreiteter Ausgangspunkt liegt nahe der Teamgröße oder etwas darunter, sodass nicht jeder gleichzeitig an mehreren Dingen arbeitet. Danach passt man das Limit anhand der Beobachtung an: Staut sich Arbeit ständig an einer Grenze, ist die vorgelagerte Phase zu locker; laufen Menschen leer, ist das Limit zu streng. Das Limit ist ein Steuerungsinstrument, kein fester Wert.
Braucht man spezielle Software für ein Kanban-System?
Nein. Ein Kanban-System lässt sich mit Haftnotizen an einer Wand betreiben, und viele Teams beginnen genau so. Software wird wertvoll, sobald Arbeit über mehrere Teams verteilt ist, Kennzahlen automatisch erfasst werden sollen oder ein PMO einen Portfolioüberblick braucht. Dann liefert ein Werkzeug wie FlexiProject Board, WIP-Limits und Flusskennzahlen an einem Ort.
Lässt sich Kanban mit Scrum kombinieren?
Ja. Der verbreitete Ansatz, oft Scrumban genannt, behält die Kadenz und Rollen von Scrum bei und ergänzt WIP-Limits und Fluss-Steuerung aus Kanban. Er hilft Teams, die in Sprints arbeiten, aber unter unvorhersehbaren Zuflüssen leiden, etwa gemischte Feature- und Support-Arbeit.
Das System, nicht nur das Board
Das Kanban-System ist das vollständige Rahmenwerk um das, was die meisten meinen, wenn sie Kanban sagen: nicht nur ein Board, sondern WIP-Limits, Flusskennzahlen, explizite Richtlinien, Feedbackschleifen und sechs Praktiken, die aus einem visuellen Werkzeug eine Betriebsdisziplin machen. Die Unterscheidung vom Kanban-Board ist entscheidend, weil die meisten Einführungen auf der Board-Ebene stagnieren: Teams bekommen die Visualisierung, installieren aber nie das System, und die versprochenen Flussverbesserungen bleiben aus. Die Ursprünge in der Toyota-Fertigung erklären die Mechanik: Zu viel angefangene Arbeit zerstört den Fluss, Sichtbarkeit plus Grenzen stellen ihn wieder her, und das Muster trägt über alle Kontexte hinweg. Für ein PMO, das ein gemischtes Portfolio steuert, liegt der eigentliche Gewinn nicht im Board, sondern in einheitlichen Richtlinien, gemeinsamen Kennzahlen und einer Portfolio-Sicht, die zeigt, wie Arbeit im gesamten Unternehmen fließt. Wer Kanban einführt, sollte das Board als Ausgangspunkt sehen und das System als Ziel.
