In SAFe / Scrum ist eine Dependency eine Abhängigkeit zweier oder mehrerer Anforderungen (User Stories). Zu beachten ist, wer für die Umsetzung der jeweiligen Anforderungen (User Story) – die zueinander in Abhängigkeit stehen – verantwortlich ist. Die Verantwortlichkeit kann innerhalb eines (Scrum) Teams liegen, bei einem der Teams des Agile Release Trains (ART) oder aber bei Personen oder Organisationseinheiten, die außerhalb des Projekt liegen.
Anmerkung: In Folgenden ist der Begriff Anforderung gleichbedeutend mit User Story.
Inner Dependency und Out Dependency – der Unterschied
Der Unterschied liegt in der Verbindlichkeit der Zusage für die Umsetzung der Anforderung (User Story), von deren Implementierung die Umsetzung einer oder weiterer Anforderungen abhängt.
Ist die Verbindlichkeit der Zusage für die Umsetzung einer Anforderung, an deren Fertigstellung wiederum eine oder mehrere andere Anforderungen hängen groß, spricht man von einer Inner Dependency. Kann man sich auf die Verbindlichkeit der Zusage nicht ganz so sehr verlassen, spricht man von einer Outer Dependency.
Im Weiteren gehen wir von folgender Annahme aus:
Die Buchstaben “A”, “B”, “C” und “D” repräsentieren vier Anforderungen (User Stories).
Anforderung (User Story) “D” hängt ab von der Umsetzung der Anforderungen (User Stories) “B” und “C” und damit diese beiden Anforderungen (User Stories) umgesetzt werden können, muss zuvor Anforderung (User Story) “A” implementiert sein.
Beispiel Inner Dependency:
In einem SAFe Projekt ist das Team Alpha für die Umsetzung der Anforderung “A” zuständig und die beiden Anforderungen “B” und “C” sind – thematisch gesehen – dem Team Foxtrot zugeordnet. Im Rahmen des PI Planning vereinbaren die beiden Teams, dass Alpha die Anforderung “A” im 1. Sprint umsetzt, damit Foxtrot die beiden Anforderungen “B” und “C” im 2. oder 3. Sprint umsetzen kann. Hier spricht man von einer Inner Dependency, weil man eigentlich darauf vertrauen kann, dass das Team Alpha die Abhängigkeit / Dependency im Sprint 1 auflösen wird.
Beispiel Outer Dependency:
Wir sind ein Scrum Team, das zu einem Agile Release Train eines in Deutschland laufenden Projekts gehört und ein paar Kollegen im fernen Indien müssten eigentlich erst eine Software-Library auf einem dort gehosteten System installieren (das wäre die Anforderung “B”) und eine in China ansässige SAP-Abteilung müsste gewissen Konfigurationseinstellungen an einem der SAP-Systeme vornehmen (das wäre die Anforderung “C”). Die Kollegen in Indien und in China gehören NICHT dem Projekt an. Sind Operations und sind komplett “Land-unter” mit Arbeit.
Ohne indischen oder gar chinesischen Kollegen zu nahe treten zu wollen, so sollte man der Vorsicht halber (Vorsichtsprinzip!) diese Dependencies als Outer Dependencies einordnen. Hier ist vielleicht mehr das Prinzip “Hoffnung” als das gute Gefühl “das machen die Termingerecht” vorherrschend.
Anmerkung der Redaktion:
Indische und chinesische Kollegen sind im vorliegenden Beispiel nur exemplarisch herangezogen worden und können auch jederzeit durch Kollegen und Abteilungen aus München oder Paris ersetzt werden. Der Autor hat viele inländische und ausländische Kollegen, mit denen er in Bezug auf deren Zusagen meist gute und manchmal auch weniger gute Erfahrungen gemacht hat.
Wie umgehen, mit Inner und Outer Dependencies?
Anforderungen, für die es Inner Dependencies gibt, sollten getrost im Rahmen eines PI Planning in einem der Sprint beplant werden. Siehe Dependency Board von Scaled Agile, Inc.
Wir bauen darauf, dass die jeweiligen Teams die Abhängigkeiten wie geplant und damit zugesagt auflösen.
Anforderungen, für die es nach unserem Bauchgefühl Outer Dependencies gibt, belassen wir im Product Backlog und planen sie erst einmal nicht für die Umsetzung im anstehenden PI (Program Increment) ein.
In Scrum wie auch in SAFe sollte man seinen Stakeholdern als verlässlicher Partner erscheinen. Sofern Objectives nicht erreicht werden, weil Outer Dependencies ein Team / den ART daran gehindert haben, wirft das kein gutes Licht auf die Verlässlichkeit des Projekts. Man würde sich zudem fortwährend in Erklärungsnot bringen.
Das soll das eine oder andere Team selbstverständlich nicht davon abhalten die eine oder andere User Story noch aus dem Product Backlog zur Umsetzung in einen Sprint zu holen, sofern dadurch der (PI) Plan nicht gänzlich durcheinander / in Gefahr gebracht wird.
Siehe dazu auch:
Conclusio:
Es hat sich gezeigt, dass Sprint-Ziele häufig wegen nicht rechtzeitig aufgelöster Abhängigkeiten erreicht wurden, für die Personen und Abteilungen verantwortlich waren, die nicht zum Projekt gehören, bei denen Weisungen eines Vorgesetzten die Umsetzung verhindert haben und das Ganze im fernen “Wo-auch-immer” eine andere, vielleicht niedrige, Priorität hat.
Brauchen Sie Unterstützung für ein “Advanced Backlog Management”, dann
