Skalierungsrahmen [Skalierung]

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

☝️ SingleWorin unterscheidet sich LeSS von Rahmenwerken, die zusätzliche Ebenen einziehen?
❌Ein Ansatz, bei dem jedes Team ein eigenes Product Backlog führt
❌Eine Erweiterung um zusätzliche Rollen und Koordinationsgremien
✅Möglichst wenige zusätzliche Regeln: ein Sprint, ein Product Backlog, ein Product Owner, ein gemeinsames Sprint Review – dafür Vereinfachung der Organisation
❌Ein eigenständiges Rahmenwerk ohne Bezug zu Scrum
LeSS folgt dem Grundsatz "more with less" und setzt auf Descaling: Statt Koordinationsschichten aufzubauen, werden organisatorische Hindernisse abgebaut.
☝️ SingleWas unterscheidet SAFe von Nexus und LeSS am deutlichsten?
❌SAFe kennt kein Product Backlog
❌SAFe ist ausschließlich für Softwareentwicklung geeignet
❌SAFe verzichtet vollständig auf Sprints
✅SAFe ist deutlich umfangreicher und führt zusätzliche Ebenen, Rollen und Planungszyklen ein, während Nexus und LeSS Scrum möglichst unverändert lassen
Die Kritik an SAFe richtet sich genau auf diesen Umfang: Zusätzliche Ebenen können bestehende Hierarchien eher bestätigen als auflösen. Die Befürworter verweisen auf die leichtere Anschlussfähigkeit großer Organisationen.
☝️ SingleWas ist der zentrale Gedanke von Scrum@Scale?
❌Scrum wird durch ein Programm-Management-Büro ergänzt
❌Die Skalierung erfolgt ausschließlich über zusätzliche Product Owner
✅Scrum wird über ein Netzwerk aus Scrum of Scrums skaliert, wobei ein Scrum Master Cycle und ein Product Owner Cycle unterschieden werden
❌Mehrere Teams werden zu einem einzigen großen Scrum Team zusammengefasst
Der Grundgedanke ist die minimal lebensfähige Bürokratie: Skaliert wird nur, was tatsächlich skaliert werden muss.
✌️ MultiWelche Anti-Pattern treten bei der Skalierung von Scrum typischerweise auf? (Mehrere richtig)
❌Alle Teams arbeiten mit einer gemeinsamen Definition of Done.
✅Die Integration erfolgt erst kurz vor der Release statt in jedem Sprint.
✅Skalierung wird begonnen, bevor Scrum auf Teamebene funktioniert.
✅Jedes Team erhält ein eigenes Product Backlog und einen eigenen Product Owner.
Skalierung ist ein Verstärker: Eine schwache Definition of Done oder unklare Product Ownership werden bei zwölf Teams nicht kleiner, sondern zwölffach teuer.
☝️ SingleEine Organisation will von drei auf zwölf Teams skalieren, obwohl die bestehenden Teams noch kein integriertes Increment je Sprint liefern. Was ist die Empfehlung?
❌Zusätzliche Scrum Master einsetzen und wie geplant vorgehen
❌Sofort skalieren, da größere Strukturen mehr Kapazität für Integration bieten
❌Ein Skalierungsrahmen ersetzt die fehlende Lieferfähigkeit
✅Zuerst die Lieferfähigkeit auf der vorhandenen Ebene herstellen, weil Skalierung bestehende Probleme vervielfacht statt sie zu lösen
Wer schon bei drei Teams nicht integriert bekommt, bekommt es bei zwölf garantiert nicht. Die Integrationsfähigkeit ist die Eintrittskarte zur Skalierung, nicht ihr Ergebnis.
✍️ OffenEin Management möchte Scrum auf fünfzehn Teams ausrollen und fragt nach dem passenden Rahmenwerk. Wie beraten Sie?
Musterantwort: Ich würde die Frage zunächst zurückstellen, weil die Wahl des Rahmenwerks selten das Problem entscheidet. Zuerst kläre ich, welches Ergebnis erreicht werden soll und wie die Ausgangslage aussieht: Liefern die bestehenden Teams bereits in jedem Sprint ein fertiges Increment nach einer gemeinsamen Definition of Done? Gibt es ein gemeinsames Produkt mit einem Backlog und einer entscheidungsfähigen Product Ownership? Sind die Teams nach Fachlichkeit oder nach technischen Komponenten geschnitten? Und existiert die technische Grundlage für häufige Integration? Fällt eine dieser Antworten negativ aus, ist das der eigentliche Arbeitsgegenstand, denn Skalierung vervielfacht bestehende Schwächen. Erst danach stellt sich die Frage nach dem Rahmen, und dabei würde ich nach dem Zuschnitt der Organisation unterscheiden. Nexus eignet sich, wenn mehrere Teams an einem Produkt arbeiten und das Hauptproblem die Integration und die Abhängigkeiten sind; es fügt Scrum nur wenig hinzu. LeSS passt, wenn die Organisation bereit ist, Strukturen tatsächlich zu vereinfachen, und bietet den geringsten Regelzuwachs. SAFe wird häufig gewählt, wenn eine große, stark arbeitsteilige Organisation Anschlussfähigkeit zu bestehenden Planungs- und Budgetprozessen braucht; der Preis sind zusätzliche Ebenen, die alte Strukturen konservieren können. Zusätzlich würde ich die Frage aufwerfen, ob fünfzehn Teams an einem Produkt überhaupt nötig sind, denn oft ist die Aufteilung in kleinere, unabhängige Produkte die wirksamere Antwort als jede Skalierung.
☝️ SingleWas ist ein "Scrum of Scrums"?
❌Ein Gremium, das über die Priorisierung mehrerer Produkte entscheidet
❌Ein Skalierungsrahmen mit eigenem Regelwerk
❌Ein Scrum Team, das ausschließlich aus Scrum Mastern besteht
✅Ein regelmäßiges Abstimmungstreffen von Vertretern mehrerer Teams zur Koordination von Abhängigkeiten
Verbreitet, aber häufig missverstanden: Es ist kein Statusbericht der Teams und ersetzt keine Verantwortlichkeit – es dient ausschließlich der Koordination.
☝️ SingleWas ist bei SAFe ein Program Increment (PI) Planning?
❌Die Abnahme des integrierten Increments
❌Die tägliche Abstimmung zwischen den Teams
❌Ein Verfahren zur Schätzung von Backlog-Einträgen
✅Ein umfangreiches gemeinsames Planungsereignis mehrerer Teams über typischerweise acht bis zwölf Wochen hinweg
Kritiker sehen darin eine Rückkehr zur langfristigen Vorabplanung, Befürworter den notwendigen Abstimmungsrahmen großer Organisationen. Für Prüfungen genügt die Kenntnis des Konzepts und beider Bewertungen.
☝️ SingleWann ist Skalierung gar nicht die richtige Antwort?
❌Wenn die Organisation bereits Scrum einsetzt
❌Wenn mehr als drei Teams beteiligt sind
❌Wenn das Produkt technisch komplex ist
✅Wenn sich das Vorhaben in kleinere, unabhängige Produkte mit eigenen Teams aufteilen lässt
Die wirksamste Skalierungsstrategie ist oft, gar nicht zu skalieren: Zwei unabhängige Produkte mit je drei Teams sind einfacher zu führen als ein Produkt mit sechs.
✌️ MultiWelche technischen Voraussetzungen braucht wirksame Skalierung? (Mehrere richtig)
✅Automatisierte Tests, die einen integrierten Gesamtstand absichern.
✅Continuous Integration über alle Teams hinweg.
❌Getrennte Codebasen je Team, um Konflikte zu vermeiden.
✅Eine gemeinsame, verbindliche Definition of Done.
Getrennte Codebasen vermeiden Konflikte im Alltag und verschieben sie geballt auf den Integrationszeitpunkt – genau das Gegenteil dessen, was Skalierung braucht.
✍️ OffenBeschreiben Sie, warum Komponenten-Teams in skalierten Umgebungen strukturell Abhängigkeiten erzeugen, und welche Alternativen bestehen.
Musterantwort: Ein Komponenten-Team verantwortet einen technischen Ausschnitt des Systems, etwa die Datenhaltung, eine Schnittstelle oder die Benutzeroberfläche. Fachliche Anforderungen verlaufen jedoch quer zu dieser Aufteilung: Fast jede nutzbare Funktion berührt mehrere Schichten. Die Folge ist, dass kein einzelnes Team eine Anforderung allein fertigstellen kann. Jede Anforderung muss auf mehrere Teams verteilt, zwischen ihnen abgestimmt, in eine Reihenfolge gebracht und anschließend zusammengeführt werden. Der Koordinationsaufwand wächst dabei überproportional mit der Anzahl der Teams, und Wartezeiten entstehen systematisch, weil ein Team auf die Vorleistung eines anderen angewiesen ist. Nach Conways Gesetz verfestigt sich diese Aufteilung zusätzlich in der Systemarchitektur, was die Entkopplung später weiter erschwert. Die naheliegende Alternative sind Feature-Teams, die durchgängig über alle Schichten arbeiten und eine Anforderung eigenständig liefern können. Der Preis sind breitere Qualifikation, höherer Lernaufwand und die Notwendigkeit gemeinsamer Standards, damit nicht jedes Team eigene Wege geht. Als Übergang eignen sich gemischte Formen, etwa Feature-Teams mit fachlichen Ansprechpartnern je Komponente, gemeinsame Code-Verantwortung statt exklusiven Besitzes sowie gezielter Wissensaufbau über Pair oder Mob Programming. Wichtig ist, den Umbau als Führungsentscheidung zu behandeln: Der Teamzuschnitt liegt nicht im Einflussbereich der Teams selbst.
← Alle ThemenIm Quiz üben