Pull- vs. Push-Systeme
Das grundlegende Verständnis der Umstellung von zugewiesener Arbeit zu selbst gezogener Arbeit.
1Push: Traditionelle Arbeitszuweisung
In einem Push-System wird Arbeit Personen zugewiesen. Ein Manager oder System entscheidet, wer was wann macht.
Merkmale von Push:
- Zentrale Autorität trifft Zuweisungen
- Arbeit wird in Warteschlangen vor Mitarbeitern geschoben
- Mitarbeiter bearbeiten, was in ihrer Warteschlange landet
- Überlastung bleibt unsichtbar bis zur Krise
Probleme mit Push:
- Berücksichtigt nicht die tatsächliche Kapazität
- Erzeugt lokale Überlastungen
- Keine Rückkopplungsschleife zur Nachfragequelle
- Fördert das Beginnen statt das Beenden
2Pull: Das Kanban-Modell
In einem Pull-System nehmen sich Mitarbeiter das nächste Element, wenn sie Kapazität haben. Arbeit wird durch nachgelagerte Nachfrage durch das System „gezogen".
Merkmale von Pull:
- Mitarbeiter wählen das nächste Element selbst basierend auf Priorität
- WIP-Limits verhindern Überlastung
- Kapazität bestimmt das Tempo
- Nachfrage wird natürlich geglättet
So funktioniert es:
- Entwickler beendet eine Aufgabe und schafft Kapazität
- Entwickler schaut in die „Ready"-Spalte und zieht das nächste priorisierte Element
- Dies schafft Kapazität in „Ready", die wieder aufgefüllt wird
- Signal breitet sich stromaufwärts aus und begrenzt die Aufnahme neuer Arbeit
Die zentrale Umstellung: nichts beginnt, bis etwas beendet ist. Das setzen WIP-Limits durch.
Pull-Systeme regulieren sich selbst. Wenn die Kapazität sinkt (jemand ist krank, schwieriges Problem), verlangsamt das System automatisch die Aufnahme. Push-Systeme erzeugen Staus.
3Der Signalmechanismus
In Toyotas Fabriken erzeugten physische Kanban-Karten das Signal: „Ich habe dieses Teil verwendet, schickt mehr."
In der Wissensarbeit ist das Signal: Platz in der nächsten Spalte.
Wenn die Code-Review-Spalte Kapazität hat (WIP nicht am Limit), signalisiert sie, dass Development etwas beenden und hinüberschieben kann.
Wenn die Code-Review-Spalte voll ist (am WIP-Limit), signalisiert sie, dass Development entweder bei Reviews helfen oder keine neue Dev-Arbeit beginnen sollte.
Deshalb sind WIP-Limits essenziell – ohne sie gibt es kein Signal. Arbeit häuft sich einfach an.
4Pull in der Praxis umsetzen
Pull zum Funktionieren bringen:
-
Klare Prioritäten: Was kommt als Nächstes beim Ziehen? FIFO innerhalb der Klasse? Am wirkungsvollsten? Teams brauchen gemeinsame Kriterien.
-
Sichtbare Kapazität: Das Board zeigt, wann Kapazität existiert (Spalte unter WIP-Limit).
-
Team-Vereinbarung: Alle ziehen; niemand schiebt. Manager weisen nicht zu – sie können Prioritäten hervorheben, aber Mitarbeiter ziehen.
-
Psychologische Sicherheit: Ziehen erfordert Handlungsfähigkeit. Wenn Menschen Angst haben, falsch zu wählen, warten sie auf Zuweisungen.
Die Rolle von Product Ownern/Managern:
- Prioritäten setzen (was sollte zuerst gezogen werden)
- Das Backlog schützen (was ins System kommt)
- Keine Arbeit an Einzelpersonen zuweisen
Übergang von Push zu Pull:
- Beginnen Sie damit, Zuweisungen sichtbar zu machen, nicht sie zu eliminieren
- Schrittweise zur Selbstauswahl übergehen
- Manager vom Zuweisen wegcoachen
- Erfolgreiche Pulls feiern
Dev beendet ein Feature. Schaut in die Spalte „Ready for Dev". Drei Elemente sind dort. Zieht das oberste (höchste Priorität, laut Team-Vereinbarung). Verschiebt Karte zu „In Dev". Das ganze Team kann sehen, dass dies geschehen ist.
Team behauptet, Kanban zu machen. Aber der Team Lead schreibt Entwicklern per DM „arbeite als Nächstes an X". Das Board zeigt Pull, aber die Realität ist Push. Signale sind kaputt.
- Push-Systeme weisen Arbeit zu; Pull-Systeme lassen Mitarbeiter Arbeit nehmen
- WIP-Limits erzeugen das Signal, das Pull ermöglicht
- Pull reguliert sich selbst – wenn Kapazität sinkt, verlangsamt sich die Aufnahme
- Der Übergang von Push zu Pull ist kulturell, nicht nur mechanisch