Scrum Guide und Skalierung: Teil 2 - Die Scrum Teams

The teams
Geschrieben von Peter Beck am 03.02.2015

Eine der schwierigeren Entscheidungen bei der Bildung einer agilen Produktorganisation ist die Zusammenstellung der Teams. Viele Elemente von Scrum betreffen weitestgehend die Ablauforganisation. Der Aufbau und die stete Leistungssteigerung von Scrum Teams rütteln an der bestehenden Aufbauorganisation

Das Scrum Team besteht aus dem Product Owner, dem Entwicklungsteam, sowie dem Scrum Master. Scrum Teams sind selbstorganisierend und interdisziplinär.

Schauen wir uns dieses Zitat von hinten nach vorne im Detail an.


Interdisziplinäre Scrum Teams leuchten sofort ein. Wenn ein einzelnes Scrum Team schon funktionsübergreifend besetzt sein soll, dann gilt das erst recht für eine Konstellation von mehreren Scrum Teams. Allerdings lauert hier schon ein wichtiger Fallstrick. So könnte man auch die Schlussfolgerung ziehen, dass bei einer Konstellation von mehreren Scrum Teams die einzelnen Teams jeweils innerhalb einer Disziplin besetzt sein könnten - ein Architektenteam, ein Designerteam, ein Programmiererteam, ein Testerteam usw.

Dem widerspricht allerdings die folgende Äußerung:

Scrum Teams liefern Produkte iterativ und inkrementell und maximieren somit die Gelegenheiten für Feedback.

Das bedeutet, dass jedes einzelne Scrum Team in der Lage sein muss, funktionsfähige Produktinkremente zu liefern. Wobei das gleiche auch für die übergreifende Konstellation gilt. Wir kommen später noch auf die Inhalte der Produktinkremente zurück.

Selbstorganisierte Scrum Teams arbeiten auch daher auch übergreifend sich selbst organisierend zusammen. Eine beliebte Fehlinterpretation bei der Einführung skalierter Scrum-Organisationen ist die Besetzung von Hilfsrollen, wie Projektleitern, um die Skalierungsprobleme zu managen. Genau das widerspricht dem Geist der selbstorganisierten Arbeit. Wenn sich ein einzelnes Team selbst organisieren kann, um innerhalb der vorgegebenen Rahmenbedingungen ein bestimmtes Ziel zu erreichen, so muss das auch in der Arbeit zwischen den Teams funktionieren. Daher bestehen auch skalierte Konstellationen von Scrum Teams nur aus den drei Scrum-Rollen.

Ein Scrum Team besteht aus den drei Rollen. Wenn wir die Anzahl der Entwicklungsteams skalieren, fragt sich, wie viele Rolleninhaber der jeweiligen anderen Rollen benötigt werden. Bei dem Scrum Master ist das einfach. Zu jedem Entwicklungsteam gehört ein Scrum Master. Idealerweise ein dedizierter Scrum Master pro Team, auf jeden Fall skaliert die Rolle mehr oder weniger mit der Anzahl der Entwicklungsteams. Doch wie sieht es mit dem Product Owner aus? Es soll einen einzigen Product Owner pro Produkt geben, aber jedes Scrum Team beinhaltet einen eigenen Product Owner?

2.1 Der Product Owner

In einer Konstellation von mehreren Scrum Teams gibt es unabhängig von der Anzahl der Entwicklungsteams nur einen Product Owner. Das folgt aus:

Der Product Owner ist für die Wertmaximierung des Produkts sowie die Arbeit des Entwicklungsteams verantwortlich. Wie dies geschieht, kann je nach Organisation, Scrum Team und Einzelpersonen stark variieren.

Der Product Owner ist die einzige Person, die für das Management des Product Backlogs verantwortlich ist.

Wenn mehrere gleichberechtigte Product Owner in ihren jeweiligen Scrum Teams an einem Produkt arbeiten würden, wäre diese Verantwortung nicht eindeutig einer Person zuzurechnen. Jetzt lässt sich natürlich argumentieren, dass eine einzelne Person schnell mit den Aufgaben des Product Owners für eine größere Produktentwicklung überfordert sein könnte. Das ist richtig. Der Product Owner verantwortet unter anderem das Management des Product Backlogs, also:

  • Product Backlog-Einträge klar zu formulieren;
  • Die Einträge im Product Backlog so zu sortieren, dass Ziele und Missionen optimal erreicht ?werden können;
  • Den Wert der Arbeit zu optimieren, die das Entwicklungsteam erledigt;
  • Das Sicherstellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie ?zeigt, woran das Scrum Team als nächstes arbeiten wird; und
  • sicherzustellen, dass das Entwicklungsteam die Product Backlog-Einträge im erforderlichen ?Maße versteht.

Diese Aufgaben können allerdings auch unter Einbeziehung der Entwicklungsteams oder mit Unterstützung von Mitarbeitern erfüllt werden, ohne dabei die Position des einzigen Product Owners in Frage zu stellen. Das gilt auch, wenn der Product Owner Teilbereiche des Product Backlogs an Mitarbeiter delegiert, die dann im Rahmen ihrer Vereinbarung mit dem Product Owner eigenständig über Inhalte und Prioritäten innerhalb ihres Einflussbereiches entscheiden dürfen.

2.2 Die Entwicklungsteams

Das Entwicklungsteam besteht aus Profis, die am Ende eines jeden Sprints ein fertiges Inkrement übergeben, welches potentiell auslieferbar ist. Nur Mitglieder der Entwicklungsteams erstellen das Produkt-Inkrement. 

Entwicklungsteams sind von der Organisation so strukturiert und befähigt, dass sie ihre eigene Arbeit selbst organisieren und managen.

Laut Scrum Guide gibt es eine maximal sinnvolle Anzahl von Mitgliedern eines Entwicklungsteams. Doch diese Zahlen sind nicht als absolute Maßgabe zu verstehen. In Einzelfällen gibt es auch funktionierende Entwicklungsteams mit 12 oder mehr Mitgliedern. In der Regel erfolgt an dieser Stelle spätestens eine Aufteilung. Eine skalierte Scrum-Konstellation liegt bereits vor, wenn sich zwei Entwicklungsteams untereinander abstimmen müssen. Als Ergebnis einer Aufteilung müssen wir wieder neue, funktionierende Entwicklungsteams erhalten. Die Fähigkeit zur Selbstorganisation sowie die Interdisziplinarität dürfen nicht einer - durchaus wohl gemeinten - Idee der Ressourcenoptimierung geopfert werden.

2.3 Die Scrum Master

Der Scrum Master ist die am Meisten verkannte und missachtete Rolle in Scrum. Das gilt umso mehr, wenn die Anzahl der Scrum Master - und damit ihre Kapazität zur Unterstützung der Entwicklungsteams, des Product Owners und seiner Mitarbeiter sowie der Organisation - nicht mit der Anzahl der Scrum Teams mit wächst. Das bedeutet nicht zwangsläufig ein 1:1 Verhältnis von Scrum Teams und Scrum Mastern. Doch zeigt die Auflistung der wesentlichen Dienste des Scrum Masters, dass die Aufteilung und Ausbreitung der Arbeit eines einzelnen Scrum Masters begrenzt sind:

Der Dienst des Scrum Masters für den Product Owner Der Scrum Master dient dem Product Owner auf verschiedene Arten, unter anderem durch das

  • Vermitteln von Techniken für eine effektive Verwaltung des Product Backlogs;
  • Vermitteln eines Verständnisses für die Notwendigkeit klarer, prägnanter Product Backlog ?Einträge im Scrum Team;
  • Schaffen eines Verständnisses für Produktplanung in einem empirischen Arbeitsumfeld;
  • Sicherstellen, dass der Product Owner weiß, wie er das Product Backlog so anordnet, dass es ?den größten Wert erzeugt;
  • Vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung;
  • Unterstützen bei Bedarf oder auf Anfrage bei der Durchführung von Scrum Ereignissen. ?

Der Dienst des Scrum Masters für das Entwicklungsteam Der Scrum Master dient dem Entwicklungsteam auf verschiedene Arten, unter anderem durch:

  • Coachen des Entwicklungsteams hin zu Selbstorganisation und funktionsübergreifender Teamarbeit;
  • Unterstützung des Entwicklungsteams bei der Schaffung hochwertiger Produkte;
  • Beseitigen von Hindernissen, die das Entwicklungsteam aufhalten;
  • Unterstützen bei Bedarf oder auf Anfrage bei der Durchführung von Scrum Ereignissen;
  • Coachen des Entwicklungsteams in Organisationen, in denen Scrum noch nicht vollständig ?angenommen und verstanden wird. ?

Der Dienst des Scrum Masters an der Organisation Der Scrum Master dient der Organisation auf verschiedene Arten, unter anderem durch das:

  • Leiten und Coachen der Organisation bei der Einführung von Scrum;
  • Planen von Scrum-Implementierungen innerhalb der Organisation;
  • Unterstützen von Kollegen und Stakeholdern, Scrum und empirische Produktentwicklung zu ?verstehen und umzusetzen;
  • Auslösen von Veränderungen zur Produktivitätssteigerung des Teams;
  • Zusammenarbeiten mit anderen Scrum Mastern, um die Effektivität von Scrum- ?Implementierungen innerhalb der Organisation zu verbessern.

Aus dem Scrum Guide heraus ergeben sich direkt keine Vorschriften, zu welchem Maß Scrum Master in einer skalierten Scrum-Konstellation zum Einsatz kommen. Das hängt sicherlich auch von den verfügbaren Kapazitäten, dem Ausbildungsstand und der Erfahrung der Teams ab. Viele Probleme skalierter Scrum-Implementierungen entspringen allerdings der Fehleinschätzung der Bedeutung dieser Rolle.

... Im nächsten Artikel geht es um Scrum Ereignisse ...

Andreas Schliep

Über den Autor

Andreas Schliep

Andreas Schliep ist ein Gründungsmitglied von DasScrumTeam AG. Er arbeitet als Scrum Coach und Trainer. Nach seinem Besuch der Hochschule Bremerhaven arbeitete Andreas zunächst als Softwareentwickler, Projektleiter, Teamleiter und später auch Bereichsleiter. Zu Scrum kam Andreas 2003-2004 durch seine damaligen Kollegen bei WEB.DE. Nach der Scrum Implementierung dort wechselte Andreas 2006 zur SPRiNT iT und machte sich 2008 als Coach und Trainer selbständig. Heute liegen seine Schwerpunkte neben der Einführung und dem Ausbau von Scrum insbesondere beim Qualitätsmanagement und der nachhaltigen Verbesserung von Entwicklungsteams.

  • Erfahrung mit Scrum seit Frühjahr 2004 als Scrum Master, Product Owner, Teammitglied, Coach und Trainer.
  • Einführung von Scrum bei der WEB.DE AG und ComBOTS AG
  • Betreuung von international verteilten Scrum Teams bei BenQ-Siemens
  • Betreuung von Scrum Teams bei bwin Wien Unterstützung des Übergangs von RUP zu Scrum bei UOL Brasilien
  • Weitere Scrum-Implementierungen in D/A/CH
  • Besondere Interessen: Skalierung und Verbesserungsprozesse
Yuliya Mijuk

Über den Autor

Peter Beck

Peter ist leidenschaftlicher Scrum Coach, Trainer (Certified Scrum Trainer, CST) und Moderator mit einem soliden Hintergrund im Engineering. Seit mehreren Jahren trainiert und coacht er eine große Bandbreite von Entwicklungsteams, Fachabteilungen, Projektleitern und Führungskräften in der Anwendung von Scrum, agilen Planungsmethoden und Softwareengineerings-Praktiken.
Peter hat die Österreichische Scrum Gruppe gegründet, an den Scrum Checklisten mitgewirkt, Publikationen auf InfoQ.com veröffentlicht. Er hält regelmäßig Vorträge auf agilen Konferenzen und Community Events.

  • Erfahrung mit Scrum seit 2004 als Teammitglied, ScrumMaster, Product Owner, Coach und Trainer.
  • Führen von international verteilten Scrum Teams als ScrumMaster
  • Mitgründer und Partner der DasScrumTeam AG
  • Besondere Interessen: Agile Unternehmen und Scrum beyond Software