Höhere Business Agility durch den aktiven Umgang mit Push- und Pull-Systemen im Value Stream

Im Rahmen agiler Transformationen entstehen häufig starke Reibungsflächen in der Ablauforganisation. Ein verbreitetes Beispiel ist das Aufeinandertreffen klassischer Projekt- bzw. Budgetplanungen auf der einen und einer agilen Arbeitsweise in den operativen Teams auf der anderen Seite.

Unter solchen Reibungsverlusten leidet die Reaktions- und Innovationsfähigkeit des gesamten Unternehmens. Anders formuliert: Die Business Agility ist reduziert. Um die Reibung zu verringern, gibt es zwei besonders relevante Perspektiven.

Die erste Perspektive fokussiert sich auf den Prozess an sich. Hier manifestiert sich die Reibung in schmerzhaften Übersetzungsschritten. Überall dort, wo zwei verschiedene Sprachen gesprochen werden, erhöht sich die Wahrscheinlichkeit von (teuren) Missverständnissen. So treten in der oben beschriebenen Situation häufig enorme Abweichungen zwischen anfänglichen Schätzungen und tatsächlichen Kosten auf. Als wäre das nicht schlimm genug, werden auch vereinbarte Meilensteine und Deadlines häufig verfehlt. Steuerung und Risikomanagement werden dadurch zum Glücksspiel.

Die zweite Perspektive hat die betroffenen Mitarbeiter:innen im Blick. Diese erleben die systemische Reibung als Spannungen zwischen den persönlich Beteiligten. Diese Spannungen wirken sich schnell auch auf andere Bereiche der Zusammenarbeit aus. Hält dieser Zustand zu lange an, kann sich die aufgestaute Frustration in einer höheren Fluktuation niederschlagen. Die resultierende Unruhe in den Teams und der gleichzeitige Wissensverlust verschärfen die Lage weiter.

Der negative Effekt auf die Wertschöpfung ist aus Sicht eines Unternehmens enorm problematisch. Je zentraler der Prozess ist bzw. je mehr Abhängigkeiten es zu anderen Unternehmensbereichen gibt, desto kostspieliger die Auswirkungen. Der Umgang mit solchen Reibungsflächen muss deshalb aktiv gestaltet werden.

Wie kann ein solcher Umgang konkret aussehen? Um Antworten aufzuzeigen, ist es wichtig, vorher eine gemeinsame Sprache zu etablieren. Außerdem lohnt es sich, einen kurzen Blick auf einen weit verbreiteten Lösungsansatz zu werfen und warum dieser nicht ausreichen kann.

Push- vs. Pull-Systeme

Viele der beschriebenen Situationen lassen sich durch den Unterschied zwischen “Push”- und “Pull”-basierten Systemen verstehen. Ganz grundsätzlich liegt die Differenz darin, wie darüber entschieden wird, wann das nächste Arbeitspaket angegangen wird.

In Pull-basierten Systemen liegt die Entscheidung bei den Leuten, die jeweils für den nächsten Arbeitsschritt zuständig sind. Sobald sie Kapazitäten haben, wird neue Arbeit angenommen und umgesetzt. Eine vom Team vorgenommene Sprint-Planung ist ein Beispiel für einen Pull-basierten Ansatz. Im Rahmen der Kapazität des Teams nimmt es eine  bestimmte Anzahl von Stories an und verspricht die Umsetzung.

Im Gegensatz dazu wird der Takt in Push-basierten Systemen größtenteils von der Anforderungsseite vorgegeben. Beispielsweise werden Projekte mit einem gewissen Budget und einer Deadline geplant und bei einem Team dann in Auftrag gegeben. Sobald hier eine Zusage geschehen ist, erwarten die Auftraggeber:innen (verständlicherweise), dass das Team Budget und Zeit einhält.

Der zugrundeliegende Konflikt zwischen beiden Systemen liegt in der unterschiedlichen Ziellogik. Zugespitzt betonen Pull-Systeme die Notwendigkeit von Flexibilität und Anpassungen auf neue Gegebenheiten. Um das zu gewährleisten, wird die Autonomie der Umsetzungsteams erhöht. Push-Systeme dagegen stellen die Planbarkeit in den Mittelpunkt.

Die Folgen einer Kollision zwischen Push- und Pull-Systemen lassen sich über den Fluss von Arbeitspaketen verstehen. Pull-Systeme leben davon, dass es einen geordneten Stapel gibt, von dem das Team (bei verfügbarer Kapazität) die nächsten Aufgaben nimmt. Push-Systeme nehmen aber strukturell wenig Rücksicht auf geordnete Stapel, sobald Ergebnisse geplant oder versprochen wurden. Stattdessen baut sich im Zweifel eine Welle von Arbeitspaketen auf, die über dem operativen Team bricht. Während das Team versucht wieder zu Atem zu kommen, ist jede Form von Planbarkeit weggespült.

Erweiterte Planung ist zu kurz gesprungen

Die übliche Reaktion auf solche Kollisionen liegt darin, die Push-Logik in die operative Seite „hinein zu koordinieren". So werden beispielsweise erfahrene Entwickler:innen in den Planungsprozess mit einbezogen. Diese müssen sich dann mit der Anforderung auseinandersetzen, verlässliche Schätzungen abzugeben.

Das stellt die Entwickler:innen vor ein Dilemma. Entweder schätzen sie so gut wie möglich und hoffen, dass sich die Annahmen hinter der Schätzung bis zur Umsetzung nicht ändern. Alternativ können sie die Aufwände systematisch überschätzen, um die spätere Rechtfertigung für verfehlte Schätzungen zu vermeiden. Beides ist nicht im Interesse eines Unternehmens.

Im Fall der “echten” Schätzung entsteht ein verstecktes Risiko durch alle Unsicherheiten, die während der Schätzung nicht berücksichtigt werden können. Werden aus Unsicherheiten greifbare Probleme, sind beschlossene Budgets und Zeitrahmen obsolet. Je weniger Puffer im Gesamtsystem vorhanden ist, desto stärker wirkt sich der Eintritt eines Risikos aus. Im schlimmsten Fall entsteht ein Dominoeffekt, der sich bis auf die strategische Ebene hinauf auswirken kann.

Im Fall der systematischen Überschätzung fällt die Qualität der getroffenen Entscheidungen. Das liegt an der verzerrten Kosten-Nutzen-Kalkulation. Vielversprechende Ideen werden zu teuer bewertet und gar nicht erst angegangen. Das Team wirkt nach außen zudem weniger leistungsfähig als es in Wirklichkeit ist.

Beide Ausprägungen sind aus Organisationssicht dysfunktional. Die oft gehörte Forderung, dann eben “genauer zu schätzen” löst dieses Dilemma nicht, da viele Probleme erst bei der Umsetzung auftreten. Statt also die Reibung selbst anzugehen, wird nur der Wärmeverlust steigen.

Transformation sollte oben beginnen – tut sie aber oft nicht

Ein kurzer Schritt zurück. In einer idealen Welt würden diese Reibungsflächen nicht oder kaum vorkommen. Würden Transformationen konsequent und auf strategischer Ebene beginnen, würden Berührungspunkte zwischen verschiedenen Welten frühzeitig adressiert werden. Systemische Reibungsflächen wären dann nur zeitlich befristete Übergangsstadien.

Diesem idealisierten Bild stehen häufig zwei Einschränkungen entgegen. Die erste Einschränkung ist, dass diese Reibungen vor allem auf operativer Ebene fühlbar sind. Änderungen am Prozess oder der Zusammenarbeit liegen aber häufig außerhalb der Einflusssphäre der operativen Teams. Die zweite Einschränkung ist die, dass in eigentlich allen Unternehmen einzelne Teams für sich bereits beschlossen haben, ihre Arbeit als Pull-System zu organisieren. Die Frage, ob man nicht lieber von oben starten sollte, ist damit hinfällig geworden. 

Mit dieser Ausgangslage im Hinterkopf kann es nur darum gehen, pragmatische Schritte zu finden, um mit diesen bereits existierenden Reibungsflächen umzugehen. Diese Schritte lassen sich in zwei Phasen untergliedern: kurzfristige Mitigation und mittelfristige Überwindung.

Kurzfristig muss der Übergang entschärft werden

Die kurzfristigen Schritte lassen sich alle unter “Entschärfung” zusammenfassen. Die relevantesten Punkte hier sind Rollen, Workflow und explizite Arbeitsregeln. Allen gemeinsam ist das Ziel, Transparenz zu erhöhen, auf die dann mittelfristig aufgebaut werden kann. Sie richten zudem den Fokus aller Beteiligten weg von persönlichen Konflikten und hin zum gemeinsamen Organisationsziel.

1. Es braucht eine Rolle, die die Übersetzung zwischen den Systemen so auffangen kann, dass die Reibung sich nicht auf große Teile der Wertschöpfungskette auswirkt. Das kann bedeuten, in Sprints erzielte Fortschritte auf Projektplanungen zu mappen oder (so gut es geht) Planungs- und Budgetierungsprozesse für das Team in Dosis und Aufwand zu steuern. Wichtig dabei ist allerdings, diese Übersetzungsleistung transparent darzustellen. Es darf kein reibungsloser Ablauf vorgetäuscht werden.

2. Im Workflow haben sich zwei Maßnahmen bewährt. Die erste Maßnahme ist die Einführung eines Puffers, der den Zufluss ins Team-Backlog reguliert. Nur aus einem beherrschbaren Backlog kann sinnvoll neue Arbeit gezogen werden. Der Füllstand dieses Puffers (und seine Veränderung) gibt unmittelbar Feedback über die Arbeitslast und den konkreten Bedarf, Prioritäten zu setzen. Die zweite Maßnahme kann das Einführen einer “Push-Regel” für besonders dringliche Arbeiten sein. Das kann eine Möglichkeit sein, um (für eine Übergangsphase) keine vollständigen Umbruch erzwingen zu müssen.

3. Explizite Regeln für die Zusammenarbeit sind immer eine gute Idee, aber besonders wichtig an diesen Übergängen. Besonders Erwartungen an und Zugänge in das Umsetzungsteam sind zentral und müssen klar kommuniziert werden. Das bedeutet auch, dass es von außen transparent nachzuvollziehen sein muss, wie das Team mit Prioritätskonflikten (z.B. zwischen Dringlichkeit und bestehenden Commitments) umgeht. Es zeigt aber auch, wie produktiv ein Team bereits ist.

Alle diese Maßnahmen nehmen akuten Druck aus der Spannungssituation und schaffen die Basis für echte, d.h. nachhaltige Veränderung.

Die neu eingeführte Rolle (1) entschärft die Reibungen zwischen beiden Systemen durch aktive Kommunikation und Übersetzungsleistungen. Ein Zwischenlager (2) im Workflow stellt sicher, dass die Push-Logik vor dem Pull-System bewusst aufgefangen wird. Das bewusste Einführen von Regeln (3) besonders an den Übergabestellen schafft Transparenz und ermöglicht einen konstruktiven Dialog über spätere Anpassungen und Verbesserungen.

Mittelfristig muss eine systemische Lösung etabliert werden

Die kurzfristige Entlastung darf nicht mit einer Dauerlösung verwechselt werden. Mittelfristig muss die Reibungsfläche stattdessen grundsätzlich angegangen werden. Wichtig zu betonen an dieser Stelle: der Bedarf zu koordinieren und das Ringen um die richtigen Prioritäten wird immer ein Bestandteil von Organisationsprozessen sein. Es wird also immer Reibung geben, aber sie muss konstruktiv und an den richtigen Stellen entstehen.

Mit der kurzfristig geschaffenen Sichtbarkeit lassen sich nun die zugrunde liegenden Probleme faktenbasiert angehen. Wie voll ist der Puffer tatsächlich? Wie verändert sich das über die Zeit? Welche Arbeiten werden schnell gezogen, welche bleiben liegen? Und am wichtigsten: Wie passt der beobachtete Arbeitsfluss zur Produkt- bzw. Unternehmensstrategie? Ist er dazu geeignet, in der notwendigen Geschwindigkeit und Qualität Wert zu schaffen? Aus den Antworten auf diese Fragen lassen sich Entscheidungen darüber treffen, in welche Richtungen das Pull-Prinzip ausgebaut werden muss und in welchem Tempo.

Stellt man beispielsweise fest, dass an vielen Themen gleichzeitig gearbeitet wird, sollte sich der Blick vor allem nach oben richten. “Oben” bedeutet in diesem Fall die nächstgrößere Arbeitseinheit. Analysiert man ein Entwicklungsteam, lohnt sich der Blick auf die Projektebene. Betrachtet man einen Bereich, kann die höhere Ebene das Level von strategischen Initiativen sein.

Bemerkt man vor allem Probleme in der Liefergeschwindigkeit, sollte man die Aufmerksamkeit auf eine Erweiterung nach vorne richten. “Vorne” bezieht sich dann auf die vorgelagerten Schritte in der Wertschöpfung. Das kann je nach Workflow die Aufwandsschätzung oder die Priorisierung sein.

Im Gegensatz zu kurzfristigen Maßnahmen hängt der mittelfristige Ansatz stärker von Kontextfaktoren ab. Es gibt beispielsweise keinen Wert von Geschwindigkeit “an sich”, sondern nur von Geschwindigkeit relativ zu den Anforderungen des jeweiligen Marktes und der Organisation. Statt sich also das wichtigste Thema von Managementmoden oder Titelblättern vorgeben zu lassen, geht es darum, evolutionär das jeweils größte Problem (in diesem Fall den schmerzhaftesten Übergang) zu identifizieren und anzugehen.

Die beiden Phasen am konkreten Beispiel

Nehmen wir zur Zusammenfassung noch einmal das am Anfang zitierte Beispiel: klassische Projektplanung trifft auf agile Teamarbeit. Wie würde das beschriebene Vorgehen in diesem Fall aussehen?

Der erste Schritt ist die Stärkung einer Rolle, die sich die Prozessverbesserung auf die Fahnen schreibt. Das kann je nach vorhandenem Setup die PO oder der Scrum-Master sein. Wichtig ist, dass diese Rolle nicht “miterledigt”, sondern klar erwartet und gelebt wird. Mit diesem Schritt gibt es eine Person, die explizit die Aufgabe hat, beide Seiten ausreichend verstehen zu können, um Übersetzungsleistungen zu erbringen. 

Diese Person kann sich dann um die Einführung eines Puffers im Workflow kümmern. Das ist beispielsweise in JIRA leicht umsetzbar. Außerdem muss klar gekennzeichnet werden, welche Stories ins Team gepusht wurden und warum. Diese beiden Anpassungen entlasten das Team in der Umsetzung und schaffen eine empirische Gesprächsgrundlage über die momentan gelebten Abläufe.

Mit diesen Grundlagen ausgerüstet kann die Vereinbarung von expliziten Regeln beginnen. Dabei müssen die Stakeholder transparent mit eingebunden werden. Zentral ist dabei, dass der evolutionäre Charakter dieser Regeln betont wird. Anders formuliert: Es geht nicht darum, irgendjemanden festzunageln. Es geht darum, gemeinsam den bestmöglichen Prozess für alle Beteiligten zu finden und nach Bedarf immer wieder nachzujustieren.

Vereinfacht kann man sich diesen Prozess in drei Phasen vorstellen:

1. In der Ausgangslage dominieren gegenseitige Spannungen die Zusammenarbeit. Den einen wird vorgeworfen, dass sie einfach immer mehr fordern, den anderen, dass sie zu langsam oder zu unzuverlässig arbeiten.

2. In der zweiten Phase werden die beschriebenen Ansätze eingeführt, um die Grundlage für eine bessere Zusammenarbeit und Organisation zu schaffen.

3. Das Ziel ist eine auf klaren Regeln basierte, gemeinsame Vorstellung des angemessenen Workflows für den jeweiligen Service bzw. das Produkt.

Über die Zeit wird die gemeinsame Basis immer breiter werden, da immer mehr bewusste Erfahrungen gesammelt wurden. Der Blick wird immer stärker darauf gerichtet sein, wie der Prozess als Ganzes verbessert werden kann. Wenn diese Perspektive ausreichend gestärkt ist, kann gemeinsam ein Blick auf nächste Schritte geworfen werden. 

Nehmen wir in unserem Beispiel an, dass vor allem die Anzahl paralleler Projekte als Hauptursache für Ineffizienzen und Reibungsverluste identifiziert wird. In diesem Fall muss das System nach oben erweitert werden. Ein naheliegender Schritt wäre es hier, die Wichtigkeit und Reihenfolge von Projekten von allen Stakeholdern gemeinsam besprechen zu lassen. Damit wird der Blick darauf gelenkt, wie ein bestimmter Value Stream für die Organisation als Ganzes optimal genutzt werden sollte.

Ein Nebeneffekt kann sein, dass man eine Differenz zwischen der aktuellen Kapazität und dem Bedarf feststellt. Sollte das der Fall sein, sind die notwendigen Diskussionsgrundlagen und -runden bereits etabliert. Es kann gemeinsam daran gearbeitet werden, die Lücke zu schließen.

Take-Aways und Zusammenfassung

Übergänge zwischen Push- und Pull-Systemen verlangen einer Organisation und ihren Mitarbeiter:innen sehr viel ab. Tatsächlich lassen sich Reibungsverluste dieser Übergänge aber in drei Schritten konstruktiv auflösen:

1. Gemeinsam anerkennen, dass System-Übergänge ein Problem sind und angegangen werden müssen.

2. Transparenz und explizite Regeln schaffen, um kurzfristig den Druck zu reduzieren.

3. Gemeinsam mit allen Beteiligten evolutionär die Wertschöpfung optimieren.

Um diese Schritte konsequent umzusetzen, ist Klarheit über das Ziel und ein gewisses Durchhaltevermögen notwendig. Wer beides aufbringt, wird aber mit einer sich konstant verbessernden Wertschöpfung belohnt. Und diese wiederum ermöglicht die hohe Reaktions- und Innovationsgeschwindigkeit, die Unternehmen heutzutage zum Überleben brauchen.