In vielen Unternehmen, die sich mit der Entwicklung von Produkten beschäftigen, arbeiten heutzutage Teams mit agilen Methoden. Häufig benutzen diese Teams Scrum. Scrum gibt mit der Definition von Rollen, Artefakten und Ereignissen einen methodischen Rahmen, mit dessen Hilfe Teams ihre Arbeit agil planen und koordinieren können (siehe hierzu auch Scrum – eine Einführung, Projekt Magazin 21/2009)

Beispiel: Bei dem Unternehmen Robota arbeitet eine Produktabteilung an der Entwicklung eines Roboters, der Pakete in der Umgebung ausliefern kann. Zur Abteilung gehören sechs Teams, die jeweils aus Hardware- und Softwarespezialisten zusammengesetzt sind. Die sechs Teams verwenden seit einem Jahr erfolgreich Scrum und bauen Stück für Stück die Funktionalität des Roboters aus.

Agile Frameworks wie z.B. Scrum sind auf die Teamarbeit zugeschnitten (ca. drei bis neun Personen). Wenn in einem Unternehmen mehrere agile Teams zusammen an einer größeren Produktentwicklung arbeiten, stellt sich die Frage, wie diese gemeinsame Arbeit ebenfalls agil koordiniert werden kann.

Scaled Agile: Agile Zusammenarbeit im großen Maßstab

Eine solche teamübergreifende Zusammenarbeit sollte auch auf den agilen Prinzipien und Techniken aufbauen, damit die Koordination im Großen zu Werten, Kultur und Haltung der Teamarbeit passt. Solche Herangehensweisen mit entsprechenden Rollen, Artefakten und Ereignissen für mehrere agile Teams nennt man "Scaled Agile" oder auch "Agilität im Großen".

In vielen Fällen liegt über den agilen Teams eine historisch gewachsene, hierarchische Managementstruktur. Hier gibt es oft Reibungspunkte, weil zwischen den agilen Teams und dem Management die Vorgehensweisen und Erwartungshaltungen bezogen auf Kommunikation, Reporting, Koordination und auch Entscheidungsfindung nicht zusammenpassen. Diese Hürde gilt es bei der Einführung von agilen Techniken auf der übergeordneten Ebene zu überwinden.

Beispiel: Bei Robota funktioniert das agile Arbeiten in den Teams gut, während es in der Zusammenarbeit der Teams große Probleme gibt. Gemeinsame Probleme der Teams wie eine instabile Entwicklungsumgebung, hohe Testaufwände und fehlende Integration während der Sprints werden zurzeit nicht systematisch adressiert. Den Teams fehlen eine gemeinsame Vision und eine Abstimmung untereinander. Das höhere Management gibt Entwicklungspläne vor, die angesichts des tatsächlichen Entwicklungsfortschritts nicht realistisch sind. Da die Teams mit Scrum gute Erfahrungen gemacht haben, schlagen sie vor, ähnliche Techniken auch zur Koordination der Teams untereinander und zum Management der Anforderungen über alle Teams hinweg zu etablieren.

Es beginnt mit der Gewaltenteilung

Ein wichtiges Element von Scrum ist die Gewaltenteilung. Statt eines Projektleiters definiert Scrum drei sorgfältig ausbalancierte Rollen. So ist der Product Owner für ein erfolgreiches Produkt, das Entwicklungsteam für funktionierende Produktinkremente und der Scrum Master für wirksames Arbeiten verantwortlich. Der Vorteil der Gewaltenteilung: Durch die Balance kommt es zu austarierten Entscheidungen, die dem Unternehmen als Ganzes wirtschaftlich besser nutzen. Bei "Scaled Agile" setzen Unternehmen deshalb die Gewaltenteilung auch auf einer höheren Ebene fort, z.B. der Abteilungsebene. Statt eines Abteilungsleiters oder Programm-Managers gibt es einen Chief Product Owner und einen Chief Scrum Master - und natürlich die Teams.

Der Chief Product Owner (CPO) ist für alle Anforderungen eines Produkts verantwortlich. Bei kleinen Einheiten (z.B: mit nur drei Teams) kann er diese Arbeit alleine durchführen - es gibt dann nur einen (Chief) Product Owner für alle Teams. Bei größeren Einheiten (z.B: mit sechs Teams) ist diese Arbeit in der Regel zu umfangreich für eine Person. In diesem Fall hat häufig jedes Team einen "eigenen" Product Owner. Diese arbeiten mit dem Chief Product Owner als Team zusammen. Sie priorisieren die Anforderungen an das Produkt und stellen sicher, dass die Teams immer an den Anforderungen mit der höchsten Priorität arbeiten. Ebenso sorgen sie dafür, dass das Product Backlog zusammen mit Stakeholdern kontinuierlich detailliert und gepflegt wird (Product Backlog Refinements) und jeweils die wichtigsten Anforderungen enthält.

Der Chief Scrum Master (CSM) ist für den Gesamtprozess verantwortlich. Er moderiert insbesondere alle teamübergreifenden Ereignisse wie z.B. eine gemeinsame Planung. Mehrere Scrum Master unterstützen die Entwicklungsteams. Darüber hinaus arbeiten sie zusammen mit dem Chief Scrum Master in einem Team. Gemeinsam identifizieren und beseitigen sie z.B. teamübergreifende Behinderungen, strukturieren den Gesamtprozess (z.B. gemeinsamer Takt), moderieren "große" Ereignisse mit vielen Teilnehmern und bringen die Organisation immer weiter in Richtung einer agilen Organisation voran.

Die Entwicklungsteams schätzen den Umfang der Anforderungen und bestimmen, wie viel sie zusammen in einem Sprint umsetzen können ("Pull"). Sie planen die Sprints. Sie entwickeln, integrieren und liefern das gemeinsame Produktinkrement.