Die Minimierung von Abhängigkeiten kostet viel Zeit.
Wie effektiv Teams in der skalierten Produktentwicklung arbeiten können, hängt von ihrer Fähigkeit ab, Abhängigkeiten zu beseitigen. Nur die Reduzierung von Abhängigkeiten vereinfacht die Integration. Scrum Master, die ihren Teams helfen, effizient teamübergreifendes Refinement durchzuführen, sparen ihren Scrum Teams Zeit und somit dem Unternehmen viel Geld.
Im Folgenden gebe ich dir 8 Tipps, wie du das Cross-Team-Refinement facilitieren kannst, damit sich deine Teams auf das Wesentliche konzentrieren können: die Abhängigkeiten zu eliminieren!
Tipp #1: Führe einen Feature-Basar durch
Beim Feature-Basar schlagen die Scrum Teams vor, an welchen Einträgen im Product Backlog sie arbeiten wollen.
Zu Beginn des Feature-Basars stellt der Product Owner die neuen Features vor. Danach wählen die Teams die Themen aus, an denen sie sich vorstellen können zu arbeiten. In meiner Arbeit mit Teams hat es sich bewährt, dass jedes Feature von mindestens zwei Teams ausgewählt wird. Das erhält die Flexibilität bei der Priorisierung des Product Backlogs.
Durch die Zuordnung der Teams zu den Features ist schnell ein erster Überblick für das Cross-Team-Refinement erstellt.
Tipp #2: Stelle sicher, dass das Cross-Team-Refinement-Board täglich aktualisiert wird
Wie der Sprint Backlog im Daily Scrum täglich aktualisiert wird, wenn neue Abhängigkeiten im aktuellen Sprint auftreten, so sollte auch das Cross-Team-Refinement-Board täglich aktualisiert werden.
Nur wenn das Cross-Team-Refinement-Board ein Echtzeitbild aller bekannten Abhängigkeiten darstellt, ist es für die Teams einfach, diese aufzulösen.
Tipp #3: Lade die Vertreter der Teams zum Cross-Team-Refinement ein
Beim Product Backlog Refinement in einem Team ist mein Ratschlag, alle Teammitglieder einzuladen. Dadurch können neue Einsichten schnell geteilt werden und jeder im Team ist auf dem gleichen Wissensstand.
Für teamübergreifendes Refinement trifft dieser Ratschlag nicht mehr zu.
Es ist weder möglich noch sinnvoll, alle Entwickler ins Cross-Team-Refinement einzuladen, wenn etwa 8 Teams gemeinsam an einem Produkt arbeiten. Deshalb solltest du, um fokussiert vorgehen zu können, nur Vertreter der einzelnen Teams einladen. Dabei sollten die Scrum Teams ihre Vertreter eigenständig wählen. Hierbei sollte auf keinen Fall die Seniorität des Entwicklers darüber entscheiden, ob er sein Team vertritt, sondern die zu verfeinernde Arbeit. Fachliche und technische Kenntnisse sind gute Auswahlkriterien, um schnell geeignete Teammitglieder zu identifizieren.
Tipp #4: Setze sowohl Team-Refinement-Termine als auch Termine für teamübergreifendes Refinement an
Cross-Team-Refinement und teaminternes Refinement haben einen unterschiedlichen Zweck.
Beim teamübergreifenden Refinement werden teamübergreifende Abhängigkeiten aufgedeckt und beseitigt und es werden Prognosen darüber erstellt, welches Team wahrscheinlich an welchem Product-Backlog-Eintrag arbeiten wird. Im Gegensatz dazu werden beim Team Refinement die Product-Backlog-Einträge aufgeschlüsselt, detailliert und geschätzt.
Häufig werden beim Team-Refinement neue teamübergreifende Abhängigkeiten festgestellt. Um diese Abhängigkeiten möglichst schnell zu beseitigen, ist ein ständiger Wechsel zwischen Team- und Cross-Team-Refinement sinnvoll.
Tipp #5: Mache teamübergreifendes Refinement zu einem regelmäßigen Termin
Warum sollte das Daily Scrum immer zur gleichen Zeit am gleichen Ort sein?
Dies vermeidet Koordinationsaufwand.
Um den Entwicklern keine weiteren Aufwände zu verursachen, ist eine einfache Möglichkeit, die teamübergreifende Verfeinerung immer am selben Tag durchzuführen.
Beginne damit, einen Nachmittag pro Woche für das Cross-Team-Refinement zu reservieren. Scheue dich auch nicht davor, das Meeting frühzeitig zu beenden, wenn aktuell keine weiteren Abhängigkeiten mehr bearbeitet werden müssen.
Tipp #6: Erinnere die Teams daran, die Abhängigkeiten nicht nur zu visualisieren, sondern auch zu eliminieren
Die Abhängigkeiten durch Visualisierung im teamübergreifenden Sprint Backlog transparent zu machen, ist nur der erste Schritt.
Der entscheidende Schritt ist die konsequente Beseitigung von Abhängigkeiten zwischen den Teams. Möglichkeiten zur Beseitigung von Abhängigkeiten sind:
- Features zwischen Teams tauschen
- Product-Backlog-Einträge zerkleinern
- fehlendes Wissen im Team aufbauen
- die wahrscheinliche Bearbeitungsreihenfolge im Product Backlog ändern
Tipp #7: Schaffe ein Bewusstsein für Abhängigkeiten
Idealerweise sollten die Entwickler in ihrer täglichen Arbeit ständig ein Auge auf mögliche Abhängigkeiten haben.
Werden neue Abhängigkeiten entdeckt, sollten diese im teamübergreifenden Refinement Board transparent gemacht werden und Möglichkeiten gesucht werden, um sie frühzeitig zu beseitigen. Zum Beispiel indem das Team auf die Teammitglieder des anderen Teams, mit dem die Abhängigkeit besteht, zugeht.
Sollte das noch nicht der Fall sein, dann unterstütze die Entwickler dabei: Erinnere sie daran, dass die Minimierung von Abhängigkeiten nur gelingen kann, wenn jeder seinen Teil dazu beiträgt. Langfristig schafft dies innerhalb der Teams ein Bewusstsein für die Auswirkungen von teamübergreifenden Abhängigkeiten. Bei der Skalierung von Scrum mit Nexus nennen wir die Gruppe, die dafür die Verantwortung übernimmt, das Nexus Integrations Team. Im Training dazu erinnere ich die Teilnehmer auch immer noch mal daran, dass wir nie vergessen sollten:
Abhängigkeiten sind der Feind von Agilität, da sie die Reaktionsfähigkeit des Unternehmens einschränken.
Tipp #8: Tappe nicht in die Wasserfall-Falle: Die Teams sollten nicht zu weit im Voraus planen, sondern sich auf den nächsten Sprint konzentrieren
Softwareentwicklung ist komplex.
Es gibt unzählige Unbekannte. Daher ist es unmöglich, alle Abhängigkeiten im Voraus zu erkennen, ganz gleich, wie lange die Teams mit der Planung ihrer Arbeit verbringen. Um unnötige Zeitverschwendung zu vermeiden, ist es meiner Erfahrung nach nicht sinnvoll, mehr als die nächsten ein bis drei Sprints im Voraus zu verfeinern.
Als Scrum Master sollten wir uns immer vor Augen führen:
Der Versuch, die Umsetzungsreihenfolge des Product Backlogs vorherzusehen, ist wie ein Wasserhahn: Je weiter man ihn aufdreht, desto näher kommt man dem Wasserfall.