Pull vs Push: warum Kanban auf Pull setzt und was sich damit ändert

Push: Arbeit wird im Voraus zugewiesen, basierend auf einem Plan oder einer Schätzung. Am Montag bekommt das Team eine Liste, was bis Freitag fertig sein soll. Das System optimiert auf die Sicht der Planer:in. Pull: Arbeit wartet im Backlog. Menschen ziehen die nächste Karte, wenn die aktuelle fertig ist - kein Commitment darüber hinaus. Das System optimiert auf die echte Rate, die das Team aufnehmen kann. Gleiche Arbeit, anderer Mechanismus, sehr unterschiedliche Folgen.

Push wirkt für Führungspersonen intuitiv und ist für Teams elend. Drei Gründe, warum es bleibt: es gibt der Planer:in Kontroll-Gefühl; es erzeugt einen sauberen Wochen-Status; es passt zur Form, in der nicht-produktive Arbeit (Ankündigungen, Kunden-Zusagen) auftaucht. Der Preis ist für die Planer:in unsichtbar: wenn der Plan kippt (die meisten Wochen), trägt das Team den Misserfolg - durch Überstunden, durch Qualitäts-Abstriche oder durch leise Absorption in den Plan der nächsten Woche. Der Optimismus des Boards wird zur unbezahlten Überstunde des Teams.

Kalender-Ehrlichkeit. Ein Pull-System kann nicht über den Durchsatz lügen, weil die Rate sich daraus ergibt, was das Team wirklich fertig macht - nicht aus einem Wunsch. Niedrigere Blocker-Raten. Pull-Systeme geben dem Team die Macht, Arbeit mit strukturellen Lücken (fehlender Input, unklares Briefing) zu verweigern; Push zwingt zum Anfangen. Bessere Erholung nach Störungen. Wird jemand krank, verlangsamt sich ein Pull-System gleichmäßig; ein Push-System rappelt, weil die zugewiesenen, jetzt unbesetzten Karten zur Krise werden.

Zwei Fälle, in denen Push richtig ist. Harte Kunden-Deadlines, die unabhängig von der internen Kapazität existieren (ein Hochzeits-Datum verschiebt sich nicht, weil das Team eine langsame Woche hatte). Der Termin ist extern; das Team muss strecken oder die Arbeit ablehnen - es kann das Datum nicht pull-pacen. Funktions-übergreifende Übergaben mit festen SLAs: ist dein Team der Input für ein anderes, braucht das zweite Team eine feste Zusage zur Planung. Der ehrliche Zug dort: realistische SLAs aus beobachtetem Durchsatz verhandeln und gegen die pushen, nicht gegen Wünsche.

{PRODUCT} ist ein Pull-förmiges Board. Das Dashboard zeigt "nächste freie Karte" pro Phase, abhängig von Owner-Verfügbarkeit und WIP-Kapazität; das Team zieht aus dem Backlog, statt eine Woche vorab zugewiesen zu bekommen. WIP-Limits erzwingen die Pull-Disziplin - Karten lassen sich nicht in eine Phase am Cap drücken, die Planer:in kann das Limit nicht überschreiben, die echte Team-Rate setzt den Takt. Harte Kunden-Deadlines werden über ein Liefer-Datum und durch Top-Sortierung im Backlog beachtet, damit sie nie versehentlich nach hinten rutschen.