Abhängigkeiten zwischen Teams managen: Von Big Room Planning bis Schnittstellenvereinbarung

Abhängigkeiten zwischen Teams managen Sie in vier Stufen: reduzieren, sichtbar machen, gemeinsam planen und Schnittstellen verbindlich vereinbaren. Welche Stufe zählt, richtet sich nach der Zahl der beteiligten Teams und nach der Häufigkeit, mit der Arbeit die Teamgrenze überquert. Wer die Wartezeit an den Übergaben misst, erkennt, wo Abhängigkeiten tatsächlich Lieferzeit kosten.

Abhängigkeiten sind der häufigste Grund, warum Vorhaben länger dauern als geplant, auch wenn jedes einzelne Team zügig arbeitet. Ein Team wartet auf eine Zulieferung, ein anderes auf eine Entscheidung, ein drittes auf einen Zugang zu einem System. Jede dieser Wartezeiten ist für sich klein, in der Summe bestimmen sie die Durchlaufzeit. Dieser Beitrag ordnet die Arten von Abhängigkeiten, vergleicht die gängigen Verfahren und gibt Kriterien an die Hand, welches Verfahren bei welcher Größe der Organisation zu wählen ist.

Welche Arten von Abhängigkeiten gibt es zwischen Teams?

Zwischen Teams gibt es vier Arten von Abhängigkeiten: Reihenfolge, Wissen, Ressourcen sowie Schnittstellen. Eine Abhängigkeit der Reihenfolge liegt vor, wenn ein Team erst beginnen kann, nachdem ein anderes ein Ergebnis geliefert hat. Eine Abhängigkeit des Wissens entsteht, wenn nur eine Person oder ein Team ein System oder eine Fachregel versteht und alle anderen nachfragen müssen. Ressourcenabhängigkeiten betreffen knappe Spezialisten, Testumgebungen oder Freigaben, die mehrere Teams gleichzeitig brauchen. Schnittstellenabhängigkeiten schließlich bestehen, wo das Ergebnis des einen Teams technisch oder fachlich zum Eingang des anderen passen muss.

Die Unterscheidung hat praktischen Wert, weil jede Art ein anderes Mittel verlangt. Reihenfolgen lösen Sie durch Planung, Wissen durch Verteilung und Dokumentation, Ressourcen durch Zuordnung oder Aufbau von Kapazität, Schnittstellen durch Vereinbarungen. Wer alle Abhängigkeiten mit einer Planungsrunde behandeln will, löst höchstens die erste Art.

Ursprung vieler Abhängigkeiten ist die Aufbauorganisation selbst. Melvin Conway beschrieb 1968, dass Organisationen Systeme entwerfen, die ihre eigene Kommunikationsstruktur abbilden. Ist die Arbeit nach Funktionen geschnitten, etwa Analyse, Entwicklung, Test sowie Betrieb, muss jedes Vorhaben alle Funktionen durchlaufen, und an jeder Grenze entsteht eine Übergabe. Wie sich Teams anders schneiden lassen, beschreibt der Beitrag zu Team Topologies.

Wie viel kosten Abhängigkeiten tatsächlich?

Abhängigkeiten kosten Lieferzeit, und sie lässt sich mit einer einfachen Rechnung beziffern. Sie zählen für ein typisches Vorhaben die Übergaben zwischen Teams, schätzen die mittlere Wartezeit je Übergabe und vergleichen die Summe mit der reinen Bearbeitungszeit. Das folgende Beispiel ist illustrativ. Ein Vorhaben benötigt zehn Arbeitstage reine Bearbeitung und durchläuft sechs Übergaben mit je vier Arbeitstagen Wartezeit. Die Durchlaufzeit beträgt dann 34 Arbeitstage, und der Anteil der Arbeitszeit an der Durchlaufzeit liegt bei rund 29 Prozent. Mehr als zwei Drittel der Zeit liegt die Arbeit still.

Diese Kennzahl, in der Fachsprache Flow Efficiency, zeigt an, wo sich Verbesserung lohnt. Halbiert die Organisation die Zahl der Übergaben von sechs auf drei, sinkt die Durchlaufzeit auf 22 Arbeitstage, ohne dass jemand schneller arbeitet. Welche Kennzahlen zur Messung taugen, zeigt der Beitrag zu den Flow Metrics.

Welche Verfahren eignen sich für welche Größe?

Das passende Verfahren richtet sich nach der Zahl der Teams, die an einem Vorhaben zusammenarbeiten, und nach der Häufigkeit der Übergaben. Bei bis zu drei Teams genügt die direkte Absprache, unterstützt durch ein gemeinsames Board. Bei vier bis sieben Teams empfiehlt sich ein regelmäßiger Austausch der Teamvertreter, bekannt als Scrum of Scrums, sowie eine gemeinsame Abhängigkeitsübersicht. Ab etwa acht Teams, die ein gemeinsames Ergebnis liefern, lohnt eine gemeinsame Planungsveranstaltung für alle Beteiligten, das Big Room Planning.

Big Room Planning ist die verbreitete Bezeichnung für die Planung eines Program Increment im Skalierungsrahmen SAFe, die in der Regel an ein bis zwei Tagen alle acht bis zwölf Wochen stattfindet. Alle beteiligten Teams planen dort gemeinsam in einem Raum, stellen ihre Abhängigkeiten auf einer Tafel dar und klären sie im direkten Gespräch. Die Stärke des Verfahrens liegt in der Gleichzeitigkeit: Fragen, die sonst wochenlang zwischen Teams wandern, sind an einem Nachmittag beantwortet. Die Schwäche ist der Aufwand. Rund hundert Personen für zwei Tage zu binden kostet Kapazität, und ohne Vorbereitung durch klare Prioritäten wird die Veranstaltung zur Terminsuche.

Wie sieht eine gute Schnittstellenvereinbarung aus?

Eine gute Schnittstellenvereinbarung hält schriftlich fest, was ein Team liefert, in welchem Format, bis wann und wer bei Änderungen entscheidet. Sie ist kurz, einseitig lesbar und beschreibt sowohl die Lieferung als auch die Erwartung an den Empfänger. Beim Zusammenspiel von Software lässt sich die Vereinbarung als Beschreibung der technischen Schnittstelle führen, bei fachlichen Übergaben als Checkliste mit Eingangskriterien. Wo ein Team Leistungen für viele andere erbringt, etwa eine Plattform, ergänzt eine Servicebeschreibung die Vereinbarung, die Reaktionszeiten und Ansprechpersonen nennt.

Team Topologies unterscheidet dazu drei Formen der Zusammenarbeit: enge gemeinsame Arbeit über einen begrenzten Zeitraum, die Nutzung eines Teams als Dienst mit klarer Schnittstelle und die befähigende Unterstützung, in der ein Team einem anderen Wissen vermittelt. Die Wahl der Form legt fest, wie viel Abstimmung dauerhaft nötig ist. Ein Dienst mit stabiler Schnittstelle verursacht nach der Einrichtung kaum Koordinationsaufwand, enge Zusammenarbeit dagegen bindet beide Teams, solange sie währt.

Ein Fehler, der häufig vorkommt, ist die Vereinbarung ohne Änderungsprozess. Anforderungen ändern sich, und eine Schnittstelle, die sich nur durch Eskalation anpassen lässt, erzeugt genau die Wartezeiten, die sie vermeiden sollte. Legen Sie fest, wer eine Änderung beschließt, wie früh sie angekündigt wird und wie lange die alte Fassung gilt.

Abhängigkeiten reduzieren statt verwalten

Die nachhaltige Lösung besteht darin, Abhängigkeiten zu verringern, bevor man sie verwaltet. Dazu dienen drei Hebel. Der erste ist der Teamzuschnitt entlang von Wertströmen, sodass ein Team ein Ergebnis vom Anfang bis zum Ende liefern kann. Der zweite ist der Aufbau fehlender Fähigkeiten im Team, etwa Testkompetenz, damit nicht jede Lieferung auf ein zentrales Testteam wartet. Der dritte ist die Reduktion gemeinsam genutzter Ressourcen durch Selbstbedienung, zum Beispiel automatisch bereitgestellte Testumgebungen.

Bei Vorhaben, die abgegrenzt in einem festen Zeitraum liefern sollen, kann auch das Arbeitsmodell Abhängigkeiten begrenzen. Der Beitrag zu Shape Up zeigt ein Modell, das Teams ein Vorhaben als Ganzes zuweist, und der Beitrag zur Release-Planung erklärt, wie Termine gehalten werden, wenn mehrere Teams zuliefern.

Abhängigkeiten managen mit Niehues Consulting

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen und in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management und Organisationsdesign arbeitet er als Delivery Manager, Projektmanager oder Product Owner genau an den Stellen, an denen Arbeit zwischen Teams liegen bleibt.

Das Vorgehen folgt dem Niehues Delivery Model mit drei Phasen. Für Abhängigkeiten zählen zwei Prüffragen: Wer entscheidet, wer liefert, wer nutzt? Welche Rollen, Entscheidungswege und Schnittstellen braucht der Betrieb? Wo diese Fragen offen sind, entstehen die Wartezeiten, die der Rechenweg oben sichtbar macht. Den Einstieg bildet eine kostenfreie Erstberatung von 30 Minuten, die Sie über den Kontakt vereinbaren.