Scaled Agile Koordination agiler Entwicklungsteams

Wie organisiert man eine reibungslose Zusammenarbeit mehrerer agiler Entwicklungsteams für ein Produkt? Malte Foegen und Claudia Raak setzen auf eine Kombination aus den Skalierungsframeworks SAFe und LeSS. Wie solch eine Zusammenarbeit aussehen kann, erklären sie am fiktiven Beispiel eines Roboter-Herstellers.

Download PDFDownload PDF
Download EPUBDownload EPUB

Scaled Agile Koordination agiler Entwicklungsteams

Wie organisiert man eine reibungslose Zusammenarbeit mehrerer agiler Entwicklungsteams für ein Produkt? Malte Foegen und Claudia Raak setzen auf eine Kombination aus den Skalierungsframeworks SAFe und LeSS. Wie solch eine Zusammenarbeit aussehen kann, erklären sie am fiktiven Beispiel eines Roboter-Herstellers.

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.

Scaled Agile erweitert agile Methoden auf der Teamebene

Alle Kommentare (3)

Hans-Heinz
Maier

Genau mit dieser Methode wurde der Berliner Flughafen gebaut, ohne Projektleiter und mit zahlreichen Teams, die zu koordinieren sind, was nicht gelang, ohne Projektleiter. Dasselbe passierte bei den 60 Teams, die den Abgasskandal verursachten, weil ein Team den 8-Liter-Tank durchsetzte gegen ein Team, das den freien Raum für einen Lautsprecher verwenden wollte, auch alles ohne Projektleiter. Maier

 

Malte
Foegen

Ein Projektleiter kann sicherlich mehrere Teams koordinieren. Ich denke aber, dass dies nicht die einzige Lösung ist. Mit einem Chief Scrum Master gibt es in der agilen Organisation ja auch jemanden, der sich um die Koordination kümmert. Es ist halt eine andere Lösung.

 

Guest

Nun ja, was beim BER schiefging, hat der Spiegel ausführlich dokumentiert. Das Fehlen eines Projektmanagers macht noch keine agile Methode, weder im Großen noch im Kleinen. Wer bereit ist, regulatorische Anforderungen zu ignorieren, kann das mit jeder beliebigen Methode tun. Bei SAFe 4.5 wird die Einhaltung von Compliance-Anforderungen ausdrücklich gefordert. Klar: wer will, kann das ignorieren. Die Juristen nennen das Vorsatz. SAFe zielt auf eine nachhaltig arbeitende Entwicklungsmaschinerie, nicht auf Projekte, ein feiner Unterschied. Dass SAFe auch im Rahmen von Großprojekten funktionieren kann, ist zumindest in der Softwareentwicklung belegbar. Selbst in Abwesenheit eines "heroischen" Projektleiters. Allerdings kann in agiler Umgebung das Selbstbild eines Projektleiters leiden. Der Unterzeichner war langjährig als PM tätig und zertifiziert. Heute ist er vor allem als SPC4 (SAFe Program Consultant) unterwegs und Partner bei einem deutschen Goldpartner der SAI (Scaled Agile Inc.). Den Artikel selbst werde ich in Ruhe studieren, wird noch ein paar Tage dauern ;-)