Mehrere Feature-Teams, aber keine Versionskontrolle; Wie kann man die Lieferung skalieren?

TL;DR

Bei Nexus geht es um Integration. Es ist sehr schwierig, die Integration ohne eine angemessene Toolchain gut durchzuführen, aber die Befolgung des Nexus-Frameworks sollte es Ihnen ermöglichen, die Integrationsfähigkeit Ihres Unternehmens iterativ zu verbessern. Ihre größte Herausforderung scheint entweder zu sein:

• Ein Missverständnis darüber, wie die Nexus Product Backlog-Elemente teamübergreifend verfeinert, visualisiert und ausgewählt werden.
• Fehlende Product Backlog-Elemente im Zusammenhang mit der Entwicklung der Fähigkeiten, die für die tatsächliche Integration des integrierten Inkrements erforderlich sind.

In beiden Fällen kann die Prozessseite des Problems während der Nexus Refinement- und Nexus Sprint Planning-Veranstaltungen angesprochen werden.

Den Product Backlog effektiv in Nexus nutzen

Das Folgende ist eine Wiederholung Ihrer Interpretation von Nexus in Bezug auf Ihre Situation:

Ein Wechsel zu Nexus bedeutet, dass Teams die Storys mit der höchsten Priorität auswählen sollten, selbst wenn dies bedeutet, dass alle Teams mit der Arbeit am selben Code beginnen, dh alle Teams würden gleichzeitig an der Integration von Telefonkonferenzen arbeiten.

Dies ist eine verständliche Fehlinterpretation, die auf der gängigen Scrum-Praxis basiert. Es ist jedoch aus drei Gründen falsch. Die Gründe sind:

1. Es wird erwartet, dass Scrum-Teams innerhalb von Nexus um Subsysteme herum strukturiert sind.

   Obwohl dies im Leitfaden nicht klar angegeben ist, enthält das Framework dennoch diese Anleitung:

   In dem Maße, in dem Anforderungen, das Wissen der Teammitglieder und Code-/Testartefakte denselben Scrum-Teams zugeordnet werden, kann die Abhängigkeit zwischen Teams verringert werden.

   Wenn die Softwareentwicklung mit Scrum skaliert wird, sollten diese Abhängigkeiten von Anforderungen, Domänenwissen und Software-/Testartefakten die Teamorganisation vorantreiben.

   Denken Sie daran, dass es bei Nexus nur um Integration geht und nicht um das Hinzufügen weiterer Ressourcen zu denselben Aufgaben. Die Strukturierung Ihrer Scrum-Teams um Feature-Sets oder Subsysteme herum, die integriert werden müssen, mit dem Ziel, teamübergreifende Abhängigkeiten zu minimieren, ist ideal.

2. Das Nexus-Framework erfordert, dass das Nexus-Integrationsteam das Product Backlog verfeinert, um Abhängigkeiten zwischen Teams zu beseitigen oder zu minimieren.

   Das Product Backlog muss zerlegt werden, damit Abhängigkeiten identifiziert und entfernt oder minimiert werden. Product-Backlog-Elemente werden in dünn geschnittene Funktionsteile verfeinert, und das Team, das wahrscheinlich die Arbeit erledigen wird, sollte so früh wie möglich identifiziert werden ... Nur wenn die Product-Backlog-Elemente ausreichend unabhängig sind, können sie ausgewählt und ohne übermäßige Konflikte zwischen Scrum bearbeitet werden Teams in einem Nexus.

   Hier geht es nicht wirklich darum , Teams Arbeit zuzuweisen . Vielmehr unterstützt es die Vorstellung, dass die Teams an lose gekoppelten Bereichen arbeiten sollten, die täglich in den Nexus integriert sind. Dies ist viel einfacher, wenn Teams um Feature-Sets oder Subsysteme herum gebildet werden.

3. Das Product Backlog in Nexus soll nicht in streng linearer Reihenfolge bearbeitet werden.

   Anstelle einer streng linearen oder sequentiellen Reihenfolge soll ein Nexus-Produkt-Backlog zusätzliche Informationen enthalten, um die Auswahl von Elementen während der Nexus-Sprint-Planung zu leiten. Betrachten Sie die folgenden Aussagen:

   • Während die Product Backlog-Elemente verfeinert und fertig gemacht werden, werden Indikatoren dafür, welches Team die Arbeit innerhalb eines Sprints erledigen wird, sichtbar gemacht.

   • Product-Backlog-Elemente werden in dünn geschnittene Teile von Funktionen verfeinert, und das Team, das wahrscheinlich die Arbeit erledigen wird, sollte so früh wie möglich identifiziert werden.

   • Der erste Teil des teamübergreifenden Refinements sollte damit verbracht werden, Product Backlog-Elemente in genügend Details zu zerlegen, um zu verstehen, welche Teams sie in welcher Reihenfolge in den kommenden Sprints liefern könnten.

   Während der Nexus-Sprint-Planung wählt jedes Team die Arbeit für den Nexus auf Scrum-ähnliche Weise aus, aber die Teams sollten die obersten Backlog-Elemente auswählen, die ihr spezifisches Sprint-Ziel innerhalb des übergeordneten Nexus-Sprint-Ziels unterstützen. Jede zusätzliche Verfeinerung oder Neuordnung kann vom Product Owner bei Bedarf spontan vorgenommen werden.

Indem Sie sicherstellen, dass Ihre Scrum-Teams funktionsübergreifend, aber so locker wie möglich mit anderen Teams gekoppelt sind, erreichen Sie mit größerer Wahrscheinlichkeit Größe. Ihre Nutzung des Product Backlogs muss diese Organisationsstruktur unterstützen und für teamübergreifende Verfeinerung und Integration optimiert sein.

Fügen Sie dem Product Backlog fehlende Integrationsgeschichten hinzu

Das Ziel von Nexus ist es, Scrum für die Integration zwischen Subsystemen zu skalieren. Wenn Ihr Prozess oder Ihre Toolchain keine Integration unterstützt, müssen Sie iterieren, bis dies der Fall ist.

Die Rolle des Nexus-Integrationsteams besteht darin, zu ermitteln, was getan werden muss, um die Integration zu erleichtern. Wenn die Integration schwierig ist, weil Ihnen die Tools oder die Infrastruktur für eine ordnungsgemäße Integration fehlen, sollte das Nexus-Integrationsteam mit den Scrum-Teams und dem Product Owner zusammenarbeiten, um Integrationselemente im Product Backlog zu erstellen und zu priorisieren.

Dies ist nicht nur ein Ideal; es ist eigentlich eine Anforderung des Nexus-Frameworks. Der Leitfaden sagt ausdrücklich:

Das Nexus-Integrationsteam übernimmt alle Integrationsprobleme. Es ist verantwortlich für die erfolgreiche Integration aller Arbeiten aller Scrum-Teams in einem Nexus. Die Integration umfasst die Lösung aller technischen und nicht-technischen teamübergreifenden Einschränkungen, die die Fähigkeit eines Nexus beeinträchtigen können, ein konstant integriertes Inkrement bereitzustellen.

Wenn der Product Owner oder die Stakeholder keine Priorisierung der Integration zulassen, wird die Nexus-Implementierung wahrscheinlich scheitern. Nexus als eine Möglichkeit zu behandeln, Ressourcen zu skalieren, ohne sich mit der Integration zu befassen, verfehlt den gesamten Sinn des Frameworks.