Scrum-Leitfaden | 16. Scrum skalieren

Veröffentlicht: 2022-05-16

Das Scrum Team sollte aus bis zu zehn Personen bestehen. Aber was tun, wenn eine größere Gruppe von Spezialisten an einem Projekt arbeiten muss? Oder wenn sich die Organisation für einen agilen Führungsstil entscheidet? Um dieses Problem zu lösen, schlugen Scrum-Entwickler vor [email protected] Es ist eine skalierbare Architektur, um ganze Teams nach Scrum-Prinzipien zu organisieren.

Scrum skalieren – Inhaltsverzeichnis:

  1. Einführung
  2. [E-Mail geschützt]
  3. Das Scrum der Scrums
  4. Weitere Skalierungs- und [E-Mail-geschützte] Probleme
  5. Zusammenfassung

Einführung

Sobald eine Organisation wächst, treten neue Arten von Problemen auf. Zum Beispiel ein Rückgang der Mitarbeitereffektivität, der durch komplexe interne Strukturen, schwierige Entscheidungsfindung oder Richtungsvorgabe verursacht wird. Unternehmen, die auf der Ebene kleiner Projektteams agil arbeiten, versuchen oft, sich zu vergrößern.

Viele Unternehmen kommen gut damit zurecht, Scrum nicht zu skalieren. Selbst wenn viele Scrum-Teams gleichzeitig laufen, müssen sie nicht koordiniert werden, da die Gruppen unabhängig voneinander arbeiten. Dies bedeutet jedoch nicht, dass es sich um ein Multi-Team-Scrum handelt. Die Notwendigkeit zur Skalierung entsteht nur, wenn der größte Teil der Organisation an einem Produkt arbeitet und seine mehreren Scrum-Teams effektiv synchronisieren kann.

Die meisten Organisationen, die agile Managementmethoden in großem Umfang anwenden, entscheiden sich für das SAFE-Modell oder das Scaled Agile Framework. Heute werden wir uns jedoch nicht auf SAFE konzentrieren, sondern ein anderes Modell namens [email protected] diskutieren, da es laut dem 15. State of Agile-Bericht aus dem Jahr 2021 die zweitbeste Wahl unter Unternehmen ist, die sich für Agile entscheiden.

[E-Mail geschützt]

1996 arbeiteten die Schöpfer von Scrum, Jeff Sutherland und Ken Schwaber, an einem großen Projekt. Dabei hatten sie Probleme, kleinere Teams, die in Scrum arbeiteten, synchron zu halten. Sie fanden eine Möglichkeit, es zu skalieren, die sie schließlich [email protected] nannten.

Analog zum offiziellen Scrum Guide war der [email protected] Guide , der diese Art der Skalierungsarbeit definiert als:

Ein Rahmenwerk, in dem Netzwerke von Scrum-Teams nach dem Scrum-Leitfaden operieren, um komplexe adaptive Probleme zu lösen und kreativ Produkte mit möglichst hohem Wert zu liefern.

Die grundlegende Prämisse von [email protected] ist Einfachheit und Effizienz. Daher basiert sein Betrieb auf einer skalierbaren Architektur. Mit anderen Worten, es verwendet Scrum, um Scrum zu skalieren. Auf diese Weise wird ein Scrum-Team, das sich aus Personen zusammensetzt, die als Product Owner, Scrum Master oder Entwickler fungieren, zum Scrum of Scrums: ein Team, das aus Teams besteht.

Das Scrum der Scrums

Das Scrum of Scrums ist ein Scrum-Team mit Personen, die traditionelle Scrum-Rollen einnehmen. Da die Aufgabe von Scrum of Scrums jedoch darin besteht, die Ergebnisse der Arbeit mehrerer Scrum-Teams zu integrieren, benötigt es zusätzliche Stellen:

  • Product Owner Team – eine Gruppe von Product Ownern, die sich treffen, um Prioritäten zu vereinbaren und eine zusammenhängende Produktvision zu erstellen
  • Chief Product Owner – Der Product Owner des Scrum Teams oder eine Person, die sich ausschließlich mit Scrum of Scrums befasst
  • Scrum of Scrums Master – die Person, die die Wirksamkeit von Scrum of Scrums überwacht.

Sie treffen sich bei denselben Scrum Events und verwenden ähnliche Artefakte.

Scaling Scrum

Weitere Skalierungs- und [E-Mail-geschützte] Probleme

Die skalierbare Architektur von [email protected] ermöglicht eine mehr als einmalige Skalierung. Wenn eine Organisation Teams in noch größerem Umfang koordinieren muss, kann sie Scrum of Scrums einrichten.

Die Skalierung von Scrum hat jedoch, wie jede andere Managementmethode, ihre Mängel, und in diesem Fall ähneln sie denen der grundlegenden Scrum-Teams, nur dass sie proportional größer sind. Aus diesem Grund empfehlen wir, die Details der Zusammenarbeit innerhalb jedes Scrum-Teams auszuarbeiten, bevor Sie Scrum in größerem Maßstab starten. Wir empfehlen, Scrum für erfahrene Teams zu skalieren, die über gute Kenntnisse und ein gutes Verständnis der Werte und Funktionsweisen von Scrum verfügen.

scaling

Scrum skalieren – Zusammenfassung

Scrum zu skalieren ist kein Kinderspiel. Scrum-Teams müssen Scrum-Prinzipien kompetent anwenden und ihre Aufgaben mit anderen Scrum-Teams synchronisieren. Daher lautet die zu beantwortende grundlegende Frage: Ist eine Skalierung erforderlich? Nur weil es viele Scrum-Teams in einer Organisation gibt, bedeutet das nicht automatisch, dass deren Koordination bessere Ergebnisse bringt.

Wenn sich eine Organisation für die Erweiterung von Scrum entscheidet, erhält sie eine skalierbare Architektur, die erfolgreich weiter erweitert werden kann. Jede Erweiterung geht jedoch mit einer Zunahme der Komplexität einher, mit der sich Product Owner Team, Chief Product Owner und Scrum of Scrums Master auseinandersetzen müssen.

Wenn Ihnen unsere Inhalte gefallen, werden Sie Teil unserer fleißigen Bienen-Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 16. Scaling Scrum caroline becker avatar 1background

Autorin: Caroline Becker

Als Projektmanagerin ist Caroline Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

Alle Beiträge anzeigen

Scrum-Leitfaden:

  1. Glossar der Grundbegriffe, Rollen und Begriffe
  2. Was ist Scrum?
  3. Scrum-Werte
  4. Wie implementieren Sie Scrum in Ihrem Unternehmen?
  5. Scrum Team – was ist das und wie funktioniert es?
  6. Wer ist ein Product Owner?
  7. Die häufigsten Fehler des Product Owners
  8. Wer ist der Scrum-Master?
  9. Eigenschaften eines guten Scrum Masters
  10. Die häufigsten Fehler des Scrum Masters
  11. Welche Statistiken und Metriken sollte der Scrum Master verfolgen?
  12. Zusammenarbeit zwischen Product Owner und Scrum Master
  13. Entwicklungsteam in Scrum
  14. Die häufigsten Fehler von Entwicklern
  15. Scrum-Artefakte
  16. Scrum skalieren
  17. Sprint-Rückstand
  18. Was ist das Product Backlog?
  19. Was sind User Stories?
  20. Erstellen Sie die beste User Story mit INVEST
  21. Die häufigsten Fehler in User Storys
  22. Akzeptanzkriterien für User Storys
  23. Schätzung und Story Points in Scrum
  24. Planungspoker
  25. Team-Schätzspiel
  26. Inkrement definieren
  27. Scrum-Ereignisse
  28. Was ist Sprint in Scrum?
  29. Verpflichtungen des Scrum-Teams – Produktziel, Sprintziel und Abschlussdefinition
  30. Was ist ein Burndown-Diagramm?
  31. Wie erstellt und interpretiert man ein Burndown-Diagramm?
  32. Vor- und Nachteile des Burndown-Charts
  33. Kanban-Boards in Scrum und Scrumban
  34. Velocity in Scrum - Schnelligkeit des Entwicklungsteams
  35. Tägliches Scrum
  36. Sprint-Planung
  37. Sprint-Review
  38. Was ist eine Sprint-Retrospektive?
  39. Häufige Fehler während einer Sprint-Retrospektive
  40. Pflege des Produkt-Backlogs