Scaled Agile: Scrum Inc veröffentlicht Scrum@Scale Guide

Bild: Wikimedia Commons / Richard Bartz - CC BY-SA 2.5

Die einfachsten und häufigsten Arten der Zusammenarbeit mehrerer Scrum Teams sind das so genannte Scrum of Scrums-Meeting (SoS) zur regelmässigen Absprache und die Einrichtung von Meta-Teams, in denen Delegierte der Einzelteams an übergreifenden Zielen arbeiten. Wie die Zusammenarbeit in SoS und Meta-Teams genau aussieht schwankt von Fall zu Fall, genau wie die Frage wie sie in die umgebende Organisation eingebettet werden. Jeff Sutherland (einer der Gründer von Scrum) versucht zwar seit einiger Zeit unter dem Namen "Scrum@Scale" die Begriffsverwendung zu strukturieren, allerdings ohne daraus ein schriftliches Regelwerk zu machen. Bis jetzt.

Vor wenigen Tagen hat Scrum Inc. (Sutherlands Firma) erstmals einen Scrum@Scale-Guide veröffentlicht, in dem die Begriffe klarer definiert werden als bisher. Der ist zwar kein offizieller Teil von Scrum, genau wie das Nexus-Framework des anderen Scrum-Gründers Ken Schwaber hat er aber allein durch seinen Urheber eine gewisse Autorität. Und mit der definiert er Folgendes:

Separate Skalierung für Scrum Master und Product Owner

Das Scrum of Scrums wird nicht mehr nur als Meeting verstanden sondern als Organisationsform, in der die Scrum Master der Teams gemeinsam an der Beseitigung organisatorischer Blocker und Hindernisse arbeiten. In großen Organisationen kann es mehrere davon geben, die sich dann wiederum in einem "Scrum of Scrums of Scrums" (SoSoS) koordinieren. Gespiegelt dazu gibt es eine vergleichbare Organisation der Product Owner, die MetaScrum-Teams (die auch auf weiteren Ebenen so heißen, Meta-MetaScrum-Teams gibt es nicht). Die jeweils höchste Skalierungsebene heisst "Executive Meta Scrum" für die POs und "Executive Action Team" für die Scrum Master. Diesen beiden Teams können ggf. die selben Personen angehören.

Fraktaler Aufbau

Auf jeder Ebene sind die Scrums of Scrums und MetaScrums als Scrum Teams organisiert, mit Sprints, Backlogs, Scrum-Events, Scrum Mastern und Product Ownern. Diese Rollen können von Mitgliedern der beteiligten Teams übernommen werden, ggf. aber auch Vollzeitstellen sein. Bei den POs wird hier der Begriff des Chief Product Owner (CPO) übernommen, allerdings mit unklaren Kompetenzen: er soll den POs keine User Stories vorgeben, aber trotzdem ein übergreifendes Backlog verantworten und priorisieren. Um eine Verwirrung um den Begriff "Scrum of Scrums" zu vermeiden bezeichnet er nur noch die Teams, die Meetings werden in "Scaled Daily Scrum" umbenannt.

Querschnittsteams

So genannte "Knowledge & Infrastructure Teams" können gebildet werden wenn es von bestimmten Spezialisten nicht genug gibt um sie in jedes Team zu setzen. Sie sollen weiterhin in ihren eigentlichen Scrum Teams bleiben, bilden aber zusätzlich dazu ein "virtuelles Scrum Team", das Aufgaben für die gesamte Organisation wahrnimmt.

Jedes Team ist ein Scrum Team, auch ausserhalb der Produktentwicklung

In einzelnen Fällen kann es Spezialisierungen geben die so stark von den Tätigkeiten der anderen Teams abweichen, dass sie nicht in die oben genannten Strukturen integriert werden können. Als Beispiele werden Customer Relations, Legal, Compliance und HR genannt. Auch diese Teams sollen nach Scrum organisiert sein.

---

So weit, so gut ...

Was man diesem Ansatz lassen muss ist, dass er unternehmensweites Scrum konsequenter umsetzt als jeder andere. Gleichzeitig lässt er aber auch bewusst Lücken: das Verhältnis von Product Owner und Chief Product Owner ist nicht genau geklärt, die Entstehung übergreifender Architekturen, Coding- und Dokumentationsstandards wird nicht angesprochen und die Mehrfachbelastung durch Mitarbeit in mehreren Ebenen wird nicht thematisiert. Die empfohlene Lösung für derartige Punkte ist ein so genanntes "Referenzmodell", mit dem jede Organisation ihren eigenen Weg definieren und für sich verbindlich machen soll. Es wäre spannend zu sehen wie diese Fragen in der täglichen Zusammenarbeit einer Scrum@Scale-Implementierung gelöst werden.