Deutschen Scrum 2012 und Scaling Agile

Deutsche Scrum 2012

Die diesjährige Deutsche Scrum fand am 15. und 16. November in Darmstadt bei der Telekom / Products & Innovations statt. Ich hatte dort die Gelegenheit an einer Diskussionsrunde zum Thema „Scaling Scrum“ („Scaling Agile“ wäre ggf. passender gewesen) teilzunehmen und ein Open Space zum Scaled Agile Framework anzubieten.

Die Problemstellung Agilität zu skalieren und mit einem häufig traditionell geprägten Umfeld in Einklang zu bringen zog sich durch diverse Vorträge. Im Rahmen einer Diskussionsrunde zum Thema „Scaling Scrum“ wurde die Problemstellung näher betrachtet.

Diskussionrunde „Scaling Scrum“

Zunächst wurde die Aufgabenstellung bei der Skalierung von Agilität („scaling agile“) diskutiert und auf die Herausforderungen hingewiesen. Ein kurzer Hinweis auf die Ergebnisse der Studie „SwissQ Agile 2012“ (laut der ca. 50% aller Unternehmen mit dem Stand der Agilisierung und den Ergebnisse unzufrieden sind) zeigte, dass die Einführung von Agilität in Unternehmen stets mit vielen Herausforderungen verbunden ist. Hinweis: Mit dieser und anderen Studien beschäftigt sich der Artikel „Studien: Erfolg agiler Methoden„.

Andererseits war doch der eine oder andere der Meinung, dass es gar nicht so schwierig sei …

In einem zweiten Schritt wurden einige bekannte Faktoren (vgl. u.a. Scott W. Ambler, „Agile Scaling Factors„) benannt, die helfen den Grad der Skalierung zu ermitteln. Faktoren sind beispielsweise die Anzahl an Teams, die geografische Verteilung der Teams und Team-Mitglieder, Komplexität der fachlichen und technischen Domäne, der Unternehmenskontext, das Produktportfolio (1 Produkt und 100 Produkte?).

In einem dritten Schritt wurden Ansätze diskutiert, wie Agilität skaliert werden kann.

Deutsche Scrum 2012

Die diesjährige Deutsche Scrum fand am 15. und 16. November in Darmstadt bei der Telekom / Products & Innovations statt. Ich hatte dort die Gelegenheit an einer Diskussionsrunde zum Thema „Scaling Scrum“ („Scaling Agile“ wäre ggf. passender gewesen) teilzunehmen und ein Open Space zum Scaled Agile Framework anzubieten.

Die Problemstellung Agilität zu skalieren und mit einem häufig traditionell geprägten Umfeld in Einklang zu bringen zog sich durch diverse Vorträge. Im Rahmen einer Diskussionsrunde zum Thema „Scaling Scrum“ wurde die Problemstellung näher betrachtet.

Diskussionrunde „Scaling Scrum“

Zunächst wurde die Aufgabenstellung bei der Skalierung von Agilität („scaling agile“) diskutiert und auf die Herausforderungen hingewiesen. Ein kurzer Hinweis auf die Ergebnisse der Studie „SwissQ Agile 2012“ (laut der ca. 50% aller Unternehmen mit dem Stand der Agilisierung und den Ergebnisse unzufrieden sind) zeigte, dass die Einführung von Agilität in Unternehmen stets mit vielen Herausforderungen verbunden ist. Hinweis: Mit dieser und anderen Studien beschäftigt sich der Artikel „Studien: Erfolg agiler Methoden„.


Deutsche Scrum 2012: Scaling Scrum Panel Discussion

Andererseits war doch der eine oder andere der Meinung, dass es gar nicht so schwierig sei …

In einem zweiten Schritt wurden einige bekannte Faktoren (vgl. u.a. Scott W. Ambler, „Agile Scaling Factors„) benannt, die helfen den Grad der Skalierung zu ermitteln. Faktoren sind beispielsweise die Anzahl an Teams, die geografische Verteilung der Teams und Team-Mitglieder, Komplexität der fachlichen und technischen Domäne, der Unternehmenskontext, das Produktportfolio (1 Produkt und 100 Produkte?).


Agile Scaling Factors

In einem dritten Schritt wurden Ansätze diskutiert, wie Agilität skaliert werden kann.

Scrum of Scrums

Der bekannteste Ansatz – Scrum of Scrum – fand sehr unterschiedlichen Zuspruch, da mit diesem sowohl sehr positive („haben erfolgreich 6 teams damit koordiniert“) als auch sehr negative Erfahrungen („hat überhaupt nichts gebracht“) gemacht wurden. Einigkeit herrschte darüber, dass Scrum of Scrum das Problem der Koordination adressiert und nur bedingt für die vorausschauende teamübergreifende Planung hilfreich ist.

Enterprise Scrum

Die Interpretationen, was unter Enterprise Scrum verstanden wird, waren recht unterschiedlich. Einige Teilnehmer verwiesen darauf, dass unter „Enterprise Scrum“ die Einführung von Agilität im Rahmen einer Transition verstanden wird (wie in dem entsprechenden Buch von Ken Schwaber behandelt), anderer verstehen darunter die kontextspezifische Zusammenstellung von Ansätzen (Best Practices) für die Skalierung agiler Methoden.

Content Authority & Alignment als Basis für Skalierung?

In einem letzten Schritt stellte Jens Korte seine Idee eines Skalierungsansatzes vor: Ausgehend von übergeordneten Zielsetzungen werden untergeordnete Ziele abgeleitet, die geschieht durch eine Abstimmung der beteiligten Product Owner. Die betrauten Teams sind weitgehend autark in der Umsetzung, ein Alignment findet implizit über den Kontext (worüber wir aus Zeitgründen nicht mehr reden konnten) und vor allem über die abgestimmte Zielsetzung statt.

Dieses Grundprinzip („Content Authority“) findet sich auch im Scaled Agile Framework (SAFe), welches jedoch noch weitergehende Ansätze formuliert. Eine Vorstellung des SAFe konnte aus Zeitgründen im Rahmen der Diskussionsrunde nicht mehr geschehen. Aus diesem Grunde wurde eine Open Space Session zum Thema Scaled Agile Framework für den zweiten Tag vereinbart.

Open Space Session am zweiten Tag

Am zweiten Tag der Deutschen Scrum 2012 wurden viele interessante Sessions angeboten. Im Raum „München“ kristallisierte sich eine Session-Reihe heraus, die sich aus verschiedenen Blickwinkeln dem Thema „Skalierung von Agilität“ näherte:

  • Agile Scaling Fractals & Patterns
  • Diskussion Scaled Agile Framework
  • Agil arbeiten in „großen“ Wasserfall-Projekten

Vorstellung & Diskussion Scaled Agile Framework (SAFe)

Die zweite Session in dieser Reihe war die Vorstellung des Scaled Agile Frameworks (SAFe). Statt gleich zu Beginn mit dem voll entwickelten „Big Picture“ von SAFe zu arbeiten, hatten wir uns dazu entschlossen bewusst die wichtigsten Elemente von SAFe Stück für Stück zu erarbeiten.

Ausgehend von der Team-Ebene mit den agilen Teams wurde die Programm- und Portfolio-Ebene diskutiert. Interessante Meinungen wurden zum Thema Content Authority (Portfolio > Program >Team) und vor allem rund um Informationsrückfluss (wie stelle ich sicher, dass Informationen aus den Teams auch in der Portfolioplanung berücksichtigt werden können) ausgetauscht.

Die unterschiedlichen Rollen von Product Owner und Produkt Management waren ebenfalls ein Thema, genau wie die Schwierigkeiten die damit verbunden sind, überhaupt das Programm „schneiden zu können“ (Identifikation von Wertschöpfungsketten und das Aufsetzen von dazu passenden Programmen). Die Vorausplanung für ein PSI/Release (im Allgemeinen 4-6 Sprints) stieß bei den Anwesenden auf viel Skepsis. Das Release-Planungs-Meeting konnte leider nicht wirklich besprochen werden, da hierzu etwas mehr Zeit aufgewendet werden muss. Allen Beteiligten war klar, dass in einem sehr dynamischen Umfeld diese relativ lange Vorausplanung an Grenzen stoßen wird.

Die grundlegenden Werte von SAFe: Code Qualität, Ausrichtung auf eine Zielsetzung (Alignment), Transparenz und Programm-Ausführung (Program Execution) sind sehr wichtig, konnten allerdings aus Zeitgründen ebenfalls nur sehr oberflächlich diskutiert werden.

Einigkeit herrschte darüber, dass das Scaled Agile Framework kein „Silver Bullet“ oder „Goldener Hammer“ ist, sondern lediglich ein Framework / Modell.

Für das Scaled Agile Framework gilt wie für alle anderen Modelle auch:

Alle Modelle sind falsch.

Mache der falschen Modelle sind nützlich.

Für mich ist das SAFe ein sehr nützliches Modell, um Agilität im Großen zu strukturieren und die mit Skalierung verbundenen Herausforderungen zu meistern. Es ersetzt jedoch nicht nachdenken und bewusst durchgeführte Inspect & Adapt Zyklen.

Ergebnisse der Open Space Sessions

Ganz zum Schluss wurden die Open Space Sessions bzw. deren Ergebnisse nochmals vorgestellt. Ziemlich beeindruckend, welches Themenspektrum durch die Teilnehmer abgedeckt wurde.

https://twitter.com/AgileRescue/status/270581952166363136

Scrum of Scrums

Der bekannteste Ansatz – Scrum of Scrum – fand sehr unterschiedlichen Zuspruch, da mit diesem sowohl sehr positive („haben erfolgreich 6 teams damit koordiniert“) als auch sehr negative Erfahrungen („hat überhaupt nichts gebracht“) gemacht wurden. Einigkeit herrschte darüber, dass Scrum of Scrum das Problem der Koordination adressiert und nur bedingt für die vorausschauende teamübergreifende Planung hilfreich ist.


Die üblichen Ansätze zur Skalierung von agilen Teams

Enterprise Scrum

Die Interpretationen, was unter Enterprise Scrum verstanden wird, waren recht unterschiedlich. Einige Teilnehmer verwiesen darauf, dass unter „Enterprise Scrum“ die Einführung von Agilität in Rahmen einer Transition verstanden wird (wie in dem entsprechenden Buch von Ken Schwaber behandelt), anderer verstehen darunter die kontextspezifische Zusammenstellung von Ansätzen (Best Practices) für die Skalierung agiler Methoden.

Content Authority & Alignment als Basis für Skalierung?

In einem letzten Schritt stellte Jens Korte seine Idee eines Skalierungsansatzes vor: Ausgehend von übergeordneten Zielsetzungen werden untergeordnete Ziele abgeleitet, die geschieht durch eine Abstimmung der beteiligten Product Owner. Die betrauten Teams sind weitgehend autark in der Umsetzung, ein Alignment findet implizit über den Kontext (worüber wir aus Zeitgründen nicht mehr reden konnten) und vor allem über die abgestimmte Zielsetzung statt.

Dieses Grundprinzip („Content Authority“) findet sich auch im Scaled Agile Framework (SAFe), welches jedoch noch weitergehende Ansätze formuliert. Eine Vorstellung des SAFe konnte aus Zeitgründen im Rahmen der Diskussionsrunde nicht mehr geschehen. Aus diesem Grunde wurde eine Open Space Session zum Thema Scaled Agile Framework für den zweiten Tag vereinbart.


Vereinfachte Darstellung des Scaled Agile Frameworks

Open Space Session am zweiten Tag

Am zweiten Tag der Deutschen Scrum 2012 wurden viele interessante Sessions angeboten. Im Raum „München“ kristallisierte sich eine Session-Reihe heraus, die sich aus verschiedenen Blickwinkeln dem Thema „Skalierung von Agilität“ näherte:

  • Agile Scaling Fractals & Patterns
  • Diskussion Scaled Agile Framework
  • Agil arbeiten in „großen“ Wasserfall-Projekten

Deutsche Scrum 2012: Open Space Sessions!

Vorstellung & Diskussion Scaled Agile Framework (SAFe)

Die zweite Session in dieser Reihe war die Vorstellung des Scaled Agile Frameworks (SAFe). Statt gleich zu Beginn mit dem voll entwickelten „Big Picture“ von SAFe zu arbeiten, hatten wir uns dazu entschlossen bewusst die wichtigsten Elemente von SAFe Stück für Stück zu erarbeiten.


In der Open Space Session erarbeitete Darstellung des Scaled Agile Framework

Ausgehend von der Team-Ebene mit den agilen Teams wurde die Programm- und Portfolio-Ebene diskutiert. Interessante Meinungen wurden zum Thema Content Authority (Portfolio > Program >Team) und vor allem rund um Informationsrückfluss (wie stelle ich sicher, dass Informationen aus den Teams auch in der Portfolioplanung berücksichtigt werden können) ausgetauscht.

Die unterschiedlichen Rollen von Product Owner und Produkt Management waren ebenfalls ein Thema, genau wie die Schwierigkeiten die damit verbunden sind, überhaupt das Programm „schneiden zu können“ (Identifikation von Wertschöpfungsketten und das Aufsetzen von dazu passenden Programmen). Die Vorausplanung für ein PSI/Release (im Allgemeinen 4-6 Sprints) stieß bei den Anwesenden auf viel Skepsis. Das Release-Planungs-Meeting konnte leider nicht wirklich besprochen werden, da hierzu etwas mehr Zeit aufgewendet werden muss. Allen Beteiligten war klar, dass in einem sehr dynamischen Umfeld diese relativ lange Vorausplanung an Grenzen stoßen wird.

Die grundlegenden Werte von SAFe: Code Qualität, Ausrichtung auf eine Zielsetzung (Alignment), Transparenz und Programm-Ausführung (Program Execution) sind sehr wichtig, konnten allerdings aus Zeitgründen ebenfalls nur sehr oberflächlich diskutiert werden.

Einigkeit herrschte darüber, dass das Scaled Agile Framework kein „Silver Bullet“ oder „Goldener Hammer“ ist, sondern lediglich ein Framework / Modell.

Für das Scaled Agile Framework gilt wie für alle anderen Modelle auch:

Alle Modelle sind falsch.

Mache der falschen Modelle sind nützlich.

Für mich ist das SAFe ein sehr nützliches Modell, um Agilität im Großen zu strukturieren und die mit Skalierung verbundenen Herausforderungen zu meistern. Es ersetzt jedoch nicht nachdenken und bewusst durchgeführte Inspect & Adapt Zyklen.

Ergebnisse der Open Space Sessions

Ganz zum Schluss wurden die Open Space Sessions bzw. deren Ergebnisse nochmals vorgestellt. Ziemlich beeindruckend, welches Themenspektrum durch die Teilnehmer abgedeckt wurde.

0 Gedanken zu „Deutschen Scrum 2012 und Scaling Agile