Warum entsteht eine solche Situation mit vielen gegenseitigen Abhängigkeiten? Eigentlich sollten agile Teams crossfunktional und selbstorganisiert sein und eine End2End-Betrachtung auf ihr Produkt haben. Dass dies aber immer der Fall ist, ist realitätsfremd. Es wird immer wieder Projekt- und Produktentwicklungsteams geben, die eine Abhängigkeit zu anderen Personen oder Teams haben. Diese Abhängigkeiten können sowohl durch Kommunikation, Technologie, Ressourcen oder Produktschnitt bedingt sein.
Beispiele für kommunikative Abhängigkeiten im agilen Kontext
- Kommunikation von Anforderungen
- Abstimmungen mit Dienstleistern
- Abnahmen durch Stakeholder
Beispiele für technologische Abhängigkeiten im agilen Kontext
- Notwendige Tools werden über ein Service Center bereitgestellt
- Automatische Software-Tests und Deployments können nur nacheinander durchgeführt werden
Beispiele für ressourcenbedingter Abhängigkeiten im agilen Kontext
- Teammitglieder stehen nur teilweise zur Verfügung
- Expertenwissen liegt außerhalb des Teams
Beispiel für produktbezogene Abhängigkeiten im agilen Kontext
- Nur das aggregierte Entwicklungsergebnis von zwei Teams (z. B. pro Sprint) ergibt einen Mehrwert für den Nutzer
- Schnitt von sogenannten Layer-Teams in der Softwareentwicklung, welche zum Beispiel Frontend von der Backend-Entwicklung trennen
All dies sind Beispiele für Settings, bei denen Teams aufgrund von Abhängigkeiten gezwungen werden, zu warten. Die Auslastung wird dann meist durch einen Fokuswechsel mit anderen Aufgaben abgefangen - dies verlängert jedoch zusätzlich die Lieferzeit von Anforderungen. Es gibt zwei Strategien, um die verlorene Effizienz zurückzugewinnen:
- Modularisierung:
Es wird eine Teamstruktur mit einem Produktschnitt und einer technologischen Basis gebaut, um Abhängigkeiten größtmöglich aufzulösen. Ein Ansatz, den zum Beispiel das Spotify-Framework oder auch die Holakratie in den Fokus rücken. Auch Kanban richtet einen expliziten Blick auf übergreifende Abhängigkeiten. - Integration:
Die Abhängigkeiten zwischen Teams, Produkten und Technologien werden in Kauf genommen. Es wird einen Managementsystem darum aufgebaut, um diese zu steuern.
Beide Strategien haben neben ihren Vorteilen auch relevante Nachtteile:
Im Falle der Modularisierung wird auf vielen Management-Ebenen Überzeugungsarbeit geleistet werden müssen. Es wird auch auf Team-Ebene Change-Management notwendig sein. Tendenziell wird es Mitarbeiter:innen geben, die ihre Rolle aufgeben müssen, Investitionen in Technologie werden nötig sein und einige Unternehmensprozesse müssen überarbeitet werden.
Der Aufbau eines Management-Systems hingegen dürfte ad hoc weniger Aufwand erzeugen. Die Herausforderung besteht nur darin möglichst alle Verknüpfungen zwischen Teams, Produkten und Technologien zu identifizieren sowie ein Entscheidungs- und Steuerungsmodell aufzubauen. Genau das tun die meisten agilen Skalierungsframeworks.
Das zweite Ansatz klingt nicht nur weniger aufwändig, er ist es auch. Zumindest zu Beginn. Denn man droht bei dem Versuch des Managements von Abhängigkeiten in negative Spiralen zusätzlicher Abhängigkeiten zu geraten: