Umgang mit Abhängigkeiten mehrerer Teams

Die teamübergreifende Abhängigkeit ist ein bekanntes Problem bei Großprojekten. Wir führen ein Projekt mit vier Teams durch, die sich dieselbe Plattform teilen, und die Lösung läuft darauf hinaus, viel zu kommunizieren.

Spezifische Maßnahmen, die bei der Verwaltung dieser Abhängigkeiten zu berücksichtigen sind:

• Vermeiden Sie so weit wie möglich gegenseitige Abhängigkeiten; Es ist ein Kinderspiel, aber manchmal braucht man jemanden mit frischen Augen, um die Art und Weise zu überprüfen, wie die Plattform aufgebaut ist, um eine Entkopplung vorzuschlagen
• wenn eine Entkopplung nicht möglich ist, versuchen Sie, klare Schnittstellen zwischen Anwendungen zu haben (Technologien, wie es in Ihren Fällen scheint); Auf diese Weise gilt eine Implementierung für alle Anwendungen, solange sie sich an diese gemeinsame Schnittstelle halten
• Bewerten Sie während des Sprintplans, welche Aufgaben von mehr als einer User Story abhängig sind ; Priorisieren Sie eine Story, die von dieser Aufgabe abhängt, stellen Sie sicher, dass die anderen Storys davon Kenntnis haben (wenn Sie eine Software verwenden, um Storys und Aufgaben zu verfolgen, besteht eine einfache Möglichkeit darin, Links zwischen ihnen zu verwenden).
• Sobald eine Aufgabe, die sich auf mehr als eine Story auswirkt, Priorität im Backlog erhält, stellen Sie sicher, dass der breitere Aspekt der vorgeschlagenen Lösung berücksichtigt wird, um Situationen zu vermeiden, in denen die gelieferte Aufgabe nur auf eine Story passt, aber nicht auf alle
• Sobald die Aufgabe abgeschlossen ist, stellen Sie sicher, dass die anderen Teams darüber informiert sind . Ein Scrum of Scrums ist eine Möglichkeit, dies zu tun, aber es gibt viele ... es hängt alles von Ihrer Teamstruktur ab. Wir verwenden zum Beispiel ein Confluence-Board, das die neuesten „Kern“-Änderungen zeigt

Alles Gute!

Scrum of Scrums (SoS) ist ein leichtgewichtiger Skalierungsansatz

Im Gegensatz zu einigen anderen Skalierungsansätzen benötigen Sie bei Scrum of Scrums keine dedizierten Ressourcen für die Koordination.

Mike Cohn stellt folgende Erfahrungen mit Scrum of Scrums vor :

• Auf diese Weise haben wir Projekte mit mehr als 500 Personen bearbeitet und Projekte mit mehr als 1.000 beraten.
• Jedes Team bestimmt eine Person, die am Scrum of Scrums-Meeting teilnimmt, um die Arbeit mehrerer Scrum-Teams zu koordinieren
• In vielen Organisationen reicht es aus, zwei- oder dreimal pro Woche ein Scrum of Scrums-Meeting abzuhalten.

Ich habe Scrum of Scrums verwendet, um 4 Teams zu koordinieren. In unserem Fall trafen wir uns zweimal pro Woche und ließen jedes Team von mehr als einer Person (Architekt, Product Owner, Scrum Master) vertreten. Einige dieser Leute haben mehrere Projekte bearbeitet.

Unsere SoS-Meeting-Agenda bestand normalerweise aus zwei Hauptpunkten:

• Teamübergreifende Abhängigkeiten: Wenn ein Team beispielsweise eine Komponente erstellt, die von einem anderen Team verwendet wird.
• Ressourcenkonflikt: Wir hatten einige gemeinsame Ressourcen. Wir haben die Prioritäten ausgehandelt und wie viel Prozent der Zeit der gemeinsam genutzten Ressourcen für jedes Team verfügbar sein werden.