Das sekundäre Team blockiert das primäre Team aufgrund fehlender qualitätsorientierter Entwicklung und WIP-Limits

Dass Team A Kanban und Team B Scrum nutzt, ist wohl nebensächlich. Grundsätzlich haben die beiden Teams eine unterschiedliche Einstellung zur Qualität ihrer Arbeit und deren Auswirkungen auf ihre Kunden. Neben der Beeinträchtigung der Leistung von Team A können sie sich auch auf ihre externen Kunden auswirken, was dem Management möglicherweise nicht einmal bewusst ist.

Die langfristige Lösung besteht darin, Team B die Auswirkungen ihrer Schlamperei zu zeigen. Vielleicht kann die Support-Organisation eine Analyse der Support-Tickets für das Unternehmen zeigen und sehen, ob die Arbeit von Team B tatsächlich Auswirkungen auf die Kunden hat. Vielleicht gibt es Daten zur Markteinführung von Produkten, an denen beide Teams arbeiten, um zu zeigen, dass die Produkte von Team A häufiger auf den Markt kommen und sich somit positiv auf die Einnahmen des Unternehmens auswirken. Auf der Grundlage dieser Nachweise muss sicherlich eine Intervention des Managements erfolgen, um Team B zur Verbesserung zu motivieren.

Kurzfristig könnten jedoch auch einige andere Schritte funktionieren.

Eine Möglichkeit, dies zu tun, wäre natürlich, dass Team A ein offenes Gespräch mit Team B führt, um ihre Situation zu erklären und zu sehen, ob sie etwas tun können, um die Veröffentlichung des Videoplayers rechtzeitig zu erreichen. Wenn sie diese Botschaft irgendwie vermitteln können, würde das Team A helfen. Sie könnten sogar einen externen Coach/Trainer engagieren, der ihnen bei dieser Aufgabe hilft.

Zweitens kann Team A angesichts der bisherigen Leistung von Team B vorhersagen, wann es realistischerweise tatsächlich eine fehlerfreie Version des Players erhalten wird, und dies in seine eigenen Veröffentlichungspläne einbeziehen. Daher können bestimmte Aufgaben und Funktionen, die in den Player integriert werden, früher im Veröffentlichungszyklus ausgeführt werden, sodass die Integrationsbemühungen beginnen können und alle von Team A gemeldeten Fehler von Team B behoben werden können. Vielleicht können einige Zyklen dieser Tests ausgeführt werden im Voraus geplant und in den Veröffentlichungsplan von Team A aufgenommen werden. Unabhängig davon können alle anderen Funktionen der Version von Team A fortgesetzt werden (diejenigen, die nicht von der Player-Integration abhängen) und parallel zum Testen, Debuggen und der endgültigen Veröffentlichung des Video-Players und seiner Integration in das Produkt von Team A abgeschlossen werden. Diesen Weg, Sie können weiterhin Releases gemäß ihrem Plan erstellen und gleichzeitig die Überarbeitung von Team B in ihren Plan einbeziehen. Das Bild unten hilft hoffentlich, meinen Standpunkt zu veranschaulichen :)

Bei Bedarf müssen die beiden Teams möglicherweise mehrere Iterationen durchführen.

Leichter gesagt als getan natürlich! Offensichtlich hat Team B Probleme in Bezug auf Teammanagement, Teamdynamik, individuelle Motivation usw., die dazu führen, dass sie weiterhin so funktionieren, wie sie es tun. Wenn diese nicht angegangen werden, einschließlich eines eventuellen Wiederaufbaus des Teams mit etwas frischem Blut und Ideen, wird dies weiterhin die Ressourcen, Einnahmen und Gewinne des Unternehmens schwächen – ebenso wie die allgemeine Mitarbeitermoral.

HTH. Viel Glück!

Option 1. Team B kann versuchen, die Qualität der neuen Releases auf der Grundlage früherer Releases vorherzusagen. Ich gehe davon aus, dass sich Team A nicht wesentlich verbessert, da dies bei mehreren Gelegenheiten passiert ist. Wenn Team B also die Anzahl der Fehler früherer Versionen und die Zeit kennt, die Team B benötigt, um sie zu beheben, kann Team A sich auf spätere Veröffentlichungstermine festlegen.

Option 2. Team B eskaliert und wenn ihre Entlassung wegen Team A verspätet ist, wenden sie sich an das Management und schlagen Team A vor, sich zu verbessern.

Option 3. Team B geht zu Team A-Demos, probiert dort Dinge aus und wenn das Produkt fehlerhaft ist, akzeptieren sie den Sprint nicht, daher muss Team A die Fehler vor der Veröffentlichung beheben.

Option 4. Team B delegiert Entwickler an Team A, um ihnen zu helfen, qualitätsorientierter zu sein.

Option 5. Team B könnte nächtliche Releases von Team A entgegennehmen und Vorabprüfungen der kommenden Versionen durchführen und frühzeitig Feedback geben.

Option 6. Verwenden Sie einen anderen Spieler (ich weiß, dass dies sehr unwahrscheinlich ist, aber immer noch eine Option).

Dies ist einer der Gründe, warum idealerweise agile Teams alle Personen enthalten, die für die Lieferung eines Produkts erforderlich sind. Wenn Sie eher funktionale als Feature-Teams haben, erstellen Sie sofort Abhängigkeiten.

Die ideale Lösung wäre die Schaffung eines oder mehrerer funktionsübergreifender Teams, die sich mit End-to-End-Feature-Anfragen befassen.

Eine alternative Lösung wäre, dass Team A und Team B enger zusammenarbeiten. Hoffentlich würde ein Teil der Qualitätsphilosophie auf Team B abfärben.

Eine letzte Option, die nicht wirklich im Sinne von Agilität ist, wäre, dass Team A Akzeptanztests für eine Media-Player-Version durchführt. Wenn die Mediaplayer-Komponente nicht von ausreichender Qualität wäre, würden sie die Freigabe ablehnen.