Push- vs. Pull-Systeme - Lean Software Development

1Push und Pull definieren

Push-Systeme starten Arbeit basierend auf Prognosen oder Zeitplänen. Ein Manager weist Arbeit zu. Ein Sprint wird geplant. Arbeit gelangt ins System, unabhängig davon, ob Kapazität vorhanden ist.

Pull-Systeme starten Arbeit basierend auf Kapazität und Nachfrage. Arbeit gelangt nur dann hinein, wenn ein nachgelagerter Schritt signalisiert, dass er bereit ist. Nichts wird hineingedrückt – es wird durchgezogen.

Der Toyota-Ursprung: In einem Push-System werden Teile basierend auf Prognosen hergestellt und nachgelagert weitergegeben. In Toyotas Pull-System senden nachgelagerte Prozesse ein Signal (Kanban-Karte), wenn sie Teile benötigen. Teile werden nur auf Signal hin produziert.

In der Softwareentwicklung:

Push: Sprint Planning verpflichtet sich zu 20 Stories. Das Team arbeitet an allen 20 gleichzeitig. Am Sprint-Ende sind 12 „in Bearbeitung" und 8 abgeschlossen.
Pull: Team hat ein WIP-Limit von 3. Wenn eine Story abgeschlossen ist, ziehen sie die nächste. Am Sprint-Ende sind 15 Stories vollständig abgeschlossen.

Die Mathematik ist kontraintuitiv: weniger Items gleichzeitig, mehr Items fertiggestellt.

Der Transparenz-Unterschied

Push-Systeme verbergen Probleme. Der Stapel unerledigter Arbeit wächst unsichtbar. Pull-Systeme offenbaren Probleme. Wenn du keine neue Arbeit ziehen kannst, weil du blockiert bist, ist die Blockierung sichtbar. Diese Transparenz erzwingt Lösung.

2Warum Push-Systeme Probleme verbergen

In einem Push-System werden Probleme begraben.

Das Team hat 15 Items in Bearbeitung. Drei sind blockiert und warten auf Architekturentscheidungen. Aber die Arbeit an den anderen 12 geht weiter. Die Blockierungen sind unsichtbar inmitten der Aktivität.

Spät im Sprint sind diese 3 Items immer noch blockiert. Jetzt ist es eine Krise. „Warum hat das niemand angesprochen?" Weil das System es nicht erzwungen hat.

Push-Systeme verbergen auch Kapazitätsprobleme. Wenn du mehr Arbeit hineinschiebst, als du bewältigen kannst, häuft sich der Überschuss einfach an. Die Lead Time wächst, aber von außen betrachtet „arbeiten alle hart".

Push-Systeme optimieren auf Starten. Pull-Systeme optimieren auf Fertigstellen.

Push-Denken: „Wir haben 20 Items in diesem Sprint gestartet!" (Aber 8 fertiggestellt.) Pull-Denken: „Wir haben 15 Items in diesem Sprint fertiggestellt." (Und 15 gestartet.)

Was würden deine Kunden bevorzugen?

Push: Der überverpflichtete Sprint

Das Team verpflichtet sich basierend auf Velocity zu 20 Stories. Auf halber Strecke sind drei Stories durch eine Abhängigkeit blockiert. Die Arbeit an anderen geht weiter. Am Sprint-Ende: 8 abgeschlossen, 12 teilweise erledigt. Die 3 blockierten Items sind immer noch blockiert.

Pull: Blockierte Arbeit taucht sofort auf

WIP-Limit ist 3. Entwickler zieht eine Story, aber sie ist durch eine Abhängigkeit blockiert. Sie können nichts Neues ziehen – Limit ist erreicht. Die Blockierung ist sofort sichtbar. Team schwärmt aus, um sie zu lösen. Lead Time bleibt kurz.

3Pull schafft Verantwortlichkeit

Pull-Systeme sind schwerer zu manipulieren als Push-Systeme.

In einem Push-System kannst du produktiv aussehen, während du Schulden anhäufst. „Ich arbeite an 8 Dingen!" (Keins fertig.) „Ich habe 50 Story Points abgeschlossen!" (Aber die Hälfte steckt im Review.)

In einem Pull-System ist die einzige gültige Arbeit fertige Arbeit. Du kannst nichts Neues starten, bis etwas fertig ist. Manipulation ist schwieriger, weil das System Fertigstellung erzwingt.

Diese Verantwortlichkeit erstreckt sich auf blockierende Probleme:

Bei Push: „Das ist blockiert, aber ich arbeite an anderen Dingen." (Blockierung schwelt.)
Bei Pull: „Ich kann nichts Neues starten, bis diese Blockierung gelöst ist." (Blockierung erzwingt Aufmerksamkeit.)

Pull-Systeme richten Anreize auf Ergebnisse aus. Das System belohnt Fertigstellen, nicht Starten. Es belohnt Entblocken, nicht Umgehen von Blockierungen. Es belohnt Durchsatz, nicht Geschäftigkeit.

Das ist für manche Teams unbequem. Push-Systeme lassen dich produktiv fühlen, auch wenn du nicht lieferst. Pull-Systeme machen die Lücke sichtbar. Das ist ein Feature, kein Bug.

Pull erfordert Mut

Pull-Systeme bringen Probleme an die Oberfläche, die Push-Systeme verbergen. Manche Organisationen führen Pull ein und geben es dann auf, weil „es zu viele Probleme aufdeckt". Diese Probleme existierten immer – Pull hat sie nur sichtbar gemacht. Das Ziel ist, sie zu beheben, nicht sie wieder zu verbergen.