Abhängigkeiten [Skalierung]

8 Übungsfragen mit Lösung und Erklärung.

✌️ MultiWelche Arten von Abhängigkeiten macht Nexus sichtbar? (Mehrere richtig)
❌Abhängigkeiten vom Urlaubsplan der Teammitglieder.
✅Abhängigkeiten von Anforderungen, die mehrere Teams betreffen.
✅Abhängigkeiten von Fachwissen und Fähigkeiten einzelner Personen.
✅Abhängigkeiten zwischen Software-Komponenten und Schnittstellen.
Die Reihenfolge der Bearbeitung ist entscheidend: Am billigsten ist es, eine Abhängigkeit durch anderen Zuschnitt aufzulösen – erst danach lohnt sich das Koordinieren.
☝️ SingleWas ist die wirksamste Strategie im Umgang mit Abhängigkeiten zwischen Teams?
✅Sie möglichst zu beseitigen, etwa durch anderen Zuschnitt der Einträge oder der Teams, statt sie nur zu verwalten
❌Ein zentrales Koordinationsgremium einzurichten, das alle Abhängigkeiten steuert
❌Die Sprints der Teams zeitlich zu versetzen
❌Für jede Abhängigkeit einen eigenen Backlog-Eintrag anzulegen
Versetzte Sprints verschlimmern die Lage: Sie erzeugen Wartezeiten und machen ein gemeinsames integriertes Increment unmöglich.
☝️ SingleWarum sind Feature-Teams in einem Nexus Komponenten-Teams meist vorzuziehen?
✅Weil ein Feature-Team eine Anforderung eigenständig durchgängig liefern kann, während Komponenten-Teams zwangsläufig voneinander abhängen
❌Weil Feature-Teams keine Spezialisten benötigen
❌Weil Komponenten-Teams keine Definition of Done haben
❌Weil Feature-Teams kleiner sind
Der Preis ist höher Lernaufwand und breitere Qualifikation. Dafür entfällt der größte Teil der Koordination – und Koordination ist der eigentliche Kostentreiber der Skalierung.
✍️ OffenBeschreiben Sie, wie ein Nexus mit Abhängigkeiten zwischen Teams umgeht – von der Erkennung bis zur Auflösung.
Musterantwort: Die Erkennung beginnt im Cross-Team Refinement, also bevor Arbeit in einen Sprint aufgenommen wird. Dort betrachten Vertreter der Teams gemeinsam die anstehenden Einträge des einen Product Backlog und prüfen, welche Einträge mehrere Teams berühren, welches Fachwissen wo liegt und welche technischen Berührungspunkte bestehen. Diese frühe Betrachtung ist der wirksamste Punkt im gesamten Ablauf, weil hier noch der billigste Hebel zur Verfügung steht: die Veränderung des Zuschnitts. Ein Eintrag, der so geschnitten wird, dass ein Team ihn allein liefern kann, erzeugt gar keine Abhängigkeit mehr. Was sich nicht auflösen lässt, wird sichtbar gemacht. Im Nexus Sprint Planning wird festgelegt, welches Team welche Arbeit übernimmt und in welcher Reihenfolge abhängige Teile entstehen müssen; das Ergebnis erscheint im Nexus Sprint Backlog, das genau diesem Zweck dient. Während des Sprints ist das Nexus Daily Scrum der Ort, an dem Vertreter der Teams prüfen, ob die geplanten Übergaben funktionieren und wo neue Abhängigkeiten aufgetaucht sind; die Ergebnisse fließen in die Team-Dailys ein. Mittelfristig gehört die wiederkehrende Ursache auf die Tagesordnung der Nexus Sprint Retrospective. Häufig liegt sie im Teamzuschnitt: Komponenten-Teams erzeugen Abhängigkeiten systematisch, während breiter aufgestellte Feature-Teams sie strukturell verringern. Die Reihenfolge lautet also stets: beseitigen, wenn möglich; sichtbar machen, wenn nicht; koordinieren als letzte Stufe.
☝️ SingleWelche Abhängigkeitsart ist am schwersten aufzulösen?
✅Die Abhängigkeit von Wissen einzelner Personen, weil sie nicht durch Zuschnitt beseitigt, sondern nur durch Wissensaufbau verringert werden kann
❌Die Abhängigkeit von Testumgebungen
❌Die Abhängigkeit von gemeinsamen Anforderungen
❌Die Abhängigkeit zwischen Softwarekomponenten
Komponenten- und Anforderungsabhängigkeiten lassen sich durch anderen Zuschnitt auflösen. Wissensinseln verschwinden nur durch gemeinsame Arbeit – Pair Programming, Rotation, Mob Programming.
☝️ SingleEin Nexus stellt fest, dass die Integration jeden Sprint mehrere Tage kostet. Was ist der richtige Ansatz?
❌Die Integration einem dauerhaften Integrationsteam übertragen
✅Die Ursachen technisch angehen – Continuous Integration, automatisierte Tests, gemeinsame Umgebungen – statt mehr Zeit dafür einzuplanen
❌Einen eigenen Integrationssprint je Quartal einführen
❌Die Sprint-Länge verlängern, damit die Integration hineinpasst
Alle drei Alternativen behandeln das Symptom und verfestigen die Ursache. Integrationsaufwand ist ein technisches Problem mit technischer Lösung.
☝️ SingleFünf Teams arbeiten an einem Produkt und stellen im Nexus Sprint Planning zahlreiche Abhängigkeiten fest. Welche Maßnahme wirkt an der Ursache?
✅Den Zuschnitt der Teams prüfen: Abhängigkeiten entstehen überwiegend durch Schnitt entlang technischer Komponenten statt entlang von Wertströmen
❌Die Sprints der Teams zeitlich versetzen, damit Zulieferungen rechtzeitig vorliegen
❌Die Abhängigkeiten in einem gemeinsamen Werkzeug erfassen und nachverfolgen
❌Einen wöchentlichen Abstimmungstermin aller Teamvertreter einführen
Die anderen drei Maßnahmen verwalten Abhängigkeiten, statt sie zu verringern; versetzte Sprints erzeugen sogar zusätzliche Wartezeit. Teams, die entlang von Wertströmen geschnitten sind, können mehr Arbeit ohne Zulieferung abschließen.
✍️ OffenEine Organisation will von einem auf vier Scrum Teams an einem Produkt wachsen. Beschreiben Sie, worauf Sie vor und während der Skalierung achten.
Musterantwort: Vorher würde ich prüfen, ob die Voraussetzung überhaupt erfüllt ist. Liefert das bestehende Team zuverlässig ein fertiges Increment je Sprint, ohne Nacharbeit und ohne externe Freigabeschleifen? Ist das nicht der Fall, vervielfacht Skalierung die vorhandenen Probleme, statt Kapazität zu schaffen. Ebenso würde ich prüfen, ob das Produkt die zusätzliche Kapazität überhaupt rechtfertigt oder ob nur Personal untergebracht werden soll. Beim Zuschnitt ist die zentrale Entscheidung, entlang welcher Linie geteilt wird. Teams entlang von Wertströmen oder Nutzergruppen können jeweils eigenständig Wert liefern; Teams entlang technischer Komponenten erzeugen dauerhaft Abhängigkeiten und Übergaben. Der zweite Weg wirkt anfangs einfacher, weil er der vorhandenen Fachlichkeit folgt, und ist die häufigste Ursache späterer Koordinationslast. Unverändert bleiben ein Product Backlog, ein Product Goal und ein Product Owner. Ergänzende Rollen dürfen zuarbeiten, aber nicht über die Gesamtreihenfolge entscheiden. Ebenso braucht es eine gemeinsame Definition of Done als Untergrenze, sonst entsteht kein integriertes Increment. Technisch ist die Integrationsfähigkeit der Engpass. Vor dem Wachstum sollten kontinuierliche Integration, automatisierte Prüfungen und automatisierte Bereitstellung stehen. Wer erst skaliert und dann integrieren will, landet bei einem Integrationssprint am Ende, also bei einem Hardening Sprint. Während der Skalierung würde ich schrittweise vorgehen: erst ein zweites Team, Wirkung beobachten, dann weiter. Als Beobachtungsgrößen eignen sich der Anteil der Sprints mit integriertem Increment, die Zahl der teamübergreifenden Abhängigkeiten je Sprint und die Durchlaufzeit, denn bei schlechter Skalierung steigt Letztere trotz mehr Personal. Schließlich würde ich die Erwartung offen ansprechen: Vier Teams liefern nicht das Vierfache. Wird das nicht vorab gesagt, gilt die Skalierung später als gescheitert, obwohl sie normal verlaufen ist.
Bewertet werden: Voraussetzung eines zuverlässig liefernden Einzelteams + Zuschnitt nach Wertstrom statt Komponente + ein Backlog, ein Product Goal, ein Product Owner + gemeinsame Definition of Done + Integrationsfähigkeit vor Wachstum + schrittweises Vorgehen mit Beobachtungsgrößen + realistische Erwartung an den Kapazitätsgewinn.
← Alle ThemenIm Quiz üben