Unter den Frameworks für agile Entwicklung hat sich vor allem Scrum weit verbreitet. Beim Einsatz von Scrum profitieren gerade kleine und mittelständische Unternehmen in technologienahen Märkten von einer verkürzten Time-to-Market und von hoher Flexibilität - gegenüber Kundenanforderungen und der Variabilität des Marktes. Inzwischen versuchen immer mehr etablierte Konzerne, es ihnen gleichzutun.

Auch sie wollen durch Scrum mehr Flexibilität und Innovationskraft gewinnen und ihre Marktanteile sichern. Die Herausforderung dabei: Scrum beruht auf der Arbeit eines kleinen Teams und liefert zunächst keine Lösungen für den Einsatz in einer großen Organisation mit einer Vielzahl von Teams. Aus diesem Bedarf heraus sind in den letzten Jahren verschiedene Ansätze zur Skalierung von agilem Vorgehen entstanden. Dazu zählen Frameworks wie das Scaled Agile Framework (SAFe) oder Large-Scale Scrum (LeSS) sowie Ansätze wie der Agile Scaling Cycle und auch populäre Best Practice-Beispiele wie bei Spotify. Auch wenn es wichtige Gemeinsamkeiten gibt, zeigt die nähere Betrachtung doch, dass nicht jedes Skalierungsframework für jeden Bedarf gleich gut geeignet ist.

Skalierung als Herausforderung für agile Entwicklung

In großen Organisationen beschränkt sich die Implementierung agiler Methoden zur Produktentwicklung häufig noch auf Softwareentwicklung und -tests. Oft sind dabei schon Produktmanagement und oberes Management kaum noch eingebunden. Ein klassisches Anforderungsmanagement ist der Entwicklung vorgelagert und beschränkt die Möglichkeit, umfassenden Nutzen aus agilen Vorgehensweisen zu ziehen. Analog bestehen Schranken auch in Richtung klassischer Unternehmensbereiche wie etwa Finance oder Budgeting & Controlling sowie in Richtung interner wie externer Stakeholder. Auch die Koordination mehrerer paralleler Entwicklungsteams, die von einer gewissen Organisationsgröße an nötig wird, ist oft nur unzureichend gelöst.

Im Video: Agile Softwareentwicklung - die Phasen eines Scrum-Projekts (1/2)

(Quelle: video2brain, Trainer: Udo Wiegärtner)

Die Gemeinsamkeit: Lean Thinking

Aus diesem praktischen Bedarf heraus sind in den vergangenen Jahren verschiedene methodische Ansätze und Frameworks entstanden, die die Skalierung agilen Vorgehens in großen Organisationen zu lösen versuchen. Diese Frameworks unterscheiden sich zum Teil erheblich in Ansatz, Ausgestaltung und im Grad der spezifischen Beschreibung. Bemerkenswert ist aber, dass sie alle auf ähnlichen Ideen und Prinzipien beruhen, die letztlich aus dem Bereich des Lean Thinking stammen. Dazu gehören die Fokussierung auf Werthaltigkeit, Wertströme, Flussorientierung, Pull-Prinzip und Qualität - all dies basierend auf einem hohen Stellenwert des Menschen. Zudem weisen selbst ganz verschiedene agile Skalierungsansätze große Ähnlichkeiten bei den grundlegenden Organisationsstrukturen auf, die durch sie definiert werden.

Der Markt der Skalierungsframeworks: Large-Scale Scrum und mehr…

Im Folgenden wollen wir vier Ansätze zur Skalierung vorstellen, um anschließend zu diskutieren, für welchen Bedarf sie sich eignen.

1. Das Scaled Agile Framework (SAFe) lässt sich als komplexes Framework zur Einbettung agiler Entwicklung in eine große Organisation unter Einbindung der klassischen Unternehmensbereiche beschreiben. SAFe ist komplex in dem Sinne, dass es die folgenden Bestandteile definiert:

eine Aufbauorganisation in Form von Strukturen, Rollen und deren Abhängigkeiten

einen Prozess sowie Artefakte, die zu definierten Zeitpunkten erstellt werden

Methoden und Praktiken.

Den Kern von SAFe bildet eine über die Zeit stabile Organisationsstruktur, die die Arbeit mehrerer an einem (Teil-)Produkt beteiligten Teams zusammenhält und koordinative Rollen definiert. Die Teams selbst folgen einer erweiterten, angepassten Form von Scrum. Das SAFe Framework der Scaled Agile Inc. ist durch mehrere Bücher von Dean Leffingwell sowie eine inhaltsreiche Website (www.scaledagileframework.com) beschrieben, und eine starke Community wird aktiv betreut. Daneben existiert ein Trainings- und Zertifizierungsprogramm. All dies ergibt den Eindruck eines aktiv vermarkteten Produkts.

2. Large-Scale Scrum (LeSS) definiert vor allem zwei Aspekte:

Eine einfache Struktur, die zum größten Teil aus Scrum-Teams und einer Hierarchie aus Product Ownern besteht, wobei der Verantwortungsbereich eines Product Owners auf tieferen Hierachie-Ebenen kleiner wird.

Einen einfachen, ebenfalls weitgehend auf Scrum basierenden Ablauf pro Team mit einzelnen Koordinationsmechanismen zwischen den Teams wie Scrum-of-Scrum oder teamübergreifenden Retrospektiven.

LeSS basiert auf der Arbeit von Craig Larman und Bas Vodde, die die beiden Autoren zunächst in Form zweier Bücher publiziert haben. Auch für LeSS sind inzwischen eine inhaltsgetriebene Website (http://less.works) sowie ein Trainings- und Zertifizierungsprogramm verfügbar.

• 3. Der Agile Scaling Cycle definiert im Gegensatz zu SAFe und LeSS weniger ein Framework für die Aufbau- und Ablauforganisation als ein Vorgehen zur Entwicklung einer solchen Organisationsform für die jeweilige Umgebung. Dies ist Kanban, dem Ansatz zur Produktionsprozesssteuerung, nicht unähnlich: auch Kanban beschreibt Schritte zur Definition eines situationsgerechten, individuellen Prozesses, nicht aber den Prozess selbst. Näher ausgeführt wird der Scaling Cycle in einzelnen Blogposts und Vorträgen, unter anderem von Stefan Roock (https://stefanroock.wordpress.com).

• 4. Die Spotify Engineering Culture beschreibt die Organisationsstruktur der Produktentwicklung beim schwedischen Musikstreaming-Dienst Spotify mit einem Fokus auf der Aufbauorganisation. Es lässt sich dabei weniger von einem Framework als vielmehr von einem gelebten Praxisbeispiel sprechen - in einer leichtgewichtigen Organisationsform mit Fokus auf Strukturierung und Koordination von Teams. Auffälliges Merkmal des Best Practice-Beispiels von Spotify ist eine "Tribe" genannte stabile Struktur, die als koordinierende Organisationsform dient. Im Tribe werden mehrere agile Teams - Squads genannt - zusammengefasst. Die vom Berater Henrik Kniberg geprägte Spotify Engineering Culture wird in sehr populären Beiträgen im Spotify Labs Blog (https://labs.spotify.com) beschrieben.

Zwei Dimensionen zur Auswahl des Frameworks

Steht man vor der Aufgabe, einen dieser vier Ansätze für die eigene Organisation auszuwählen, erweisen sich zwei Dimensionen als ausschlaggebend: einerseits ist dies die Größe der Entwicklungsorganisation und andererseits die Komplexität von Produkt und Markt sowie die Größe der Gesamtorganisation. Diese beiden Aspekte sind die wesentlichen Einflussfaktoren dafür, welchen Bedarf an Steuerungs- und Kontrollmechanismen es in Aufbau- und Ablauforganisation gibt. Es empfiehlt sich also, vor allem auf die Unterschiede in der Komplexität der Frameworks, im Detailgrad der definierten Strukturen, im Umgang mit Komplexität und in den teamübergreifenden Koordinationsmechanismen zu achten.

Für den Auswahlprozess sollte man sich folgende Fragen stellen:

Dimension: Produkt, Markt und Umgebung

• Welche Kontrollinstanzen habe ich? Bewege ich mich in einem regulierten Bereich? Oder liegen besondere regulatorische Anforderungen vor?

• Ist mein Geschäft eher produkt- oder projektorientiert?

• Wie komplex sind Produkte, Projekte oder Aufgaben? Wie groß sind Unsicherheiten?

• Wie groß ist die Gesamtunternehmung?

Dimension: Organisation

• Wie groß ist die Entwicklungsorganisation?

• Wie ist das Unternehmen aufgebaut? Muss die agile Entwicklung in das Gesamtunternehmen und in klassische Unternehmensfunktionen eingebettet werden, und welche Möglichkeiten der Anpassung bestehen?

• Wie viel Erfahrung mit agilen Methoden gibt es bereits? Ist dies neu für das ganze Unternehmen, gab es fehlgeschlagene Versuche, oder ist die agile Entwicklung erfolgreich und es fehlt nur noch an den Schnittstellen?

Grenzen bei größerer Komplexität: Spotify und Scaling Cycle

Ein Ansatz wie der Agile Scaling Cycle lässt sich grundsätzlich unabhängig von der Größe der Entwicklungsorganisation einsetzen - er selbst definiert noch keine feste Struktur und keinen Prozess. Mit zunehmender Komplexität der Gesamtunternehmung, des Produkts und des Markts haben allerdings diejenigen Ansätze Vorteile, die bereits konkrete Lösungen liefern. Dies gilt zumal dann, wenn die Organisation wenig Erfahrung mit agilem Vorgehen hat. Eine hohe Komplexität induziert eine Vielzahl an Rollen im Unternehmen, an internen und externen Stakeholdern, und auch etwaige Reglementierungen erfordern konkrete Lösungen. Das Praxisbeispiel von Spotify definiert zwar eine für mittelgroße Unternehmen durchaus geeignete Aufbauorganisation, aber dennoch bringt die Spotify Engineering Culture nur wenig prozessuale Unterstützung mit.

Im Video: Scrum - Sprint, die Taktfrequenz des Projekts (2/2)

(Quelle: video2brain, Trainer: Udo Wiegärtner)

Für mittelgroße Komplexität und nicht zu große Entwicklungsorganisationen: LeSS

LeSS definiert ein einfaches, kaum von Scrum abweichendes Vorgehen und eine skalierbare Struktur. Der Fokus auf eine Hierarchie aus Chief Product Owner, Area Product Owner sowie Product Owner auf Teamebene wird jedoch ab einer gewissen Größenordnung an Grenzen stoßen: Der Kommunikations- und Koordinationsbedarf wird in dieser Struktur stark ansteigen. LeSS betont, dass der Schnitt der Anforderungen wie auch der Teams entlang kundenrelevanter Features entscheidend ist - und nicht entlang technischer Module oder Schichten. Die dadurch angestrebte Unabhängigkeit der Anforderungen untereinander und der Teams voneinander ist ab einer gewissen Größe aber nicht mehr ausreichend, um den Koordinationsbedarf zu decken. Product Owner auf den unteren Hierarchie-Ebenen tragen kaum noch Produktverantwortung.

Auf der sicheren Seite mit SAFe

SAFe hingegen ist in seiner definierten Form für kleinere Unternehmen eher zu mächtig. Es bringt aber eine Vielzahl konkreterer Lösungen auf prozessualer Ebene und eine skalierungsfähige Aufbauorganisation mit, die eine hohe Zahl an Teams koordinieren kann und verschiedene Stakeholder und klassische Unternehmensbereiche einzubinden vermag. Während die Anwendung beispielsweise des Agile Scaling Cycle es durchaus erlaubt, funktionierende Lösungen auch für größere Unternehmen zu entwickeln, zeigt die Projekterfahrung, dass sich auf Basis von SAFe auch gut einfachere Strukturen für mittelgroße Organisationen entwickeln lassen.

Das richtige Framework für den konkreten Bedarf

Auch wenn sich alle hier diskutierten Frameworks in Ansatz, Detailgrad und Vollständigkeit unterscheiden, basieren sie doch alle auf gemeinsamen, grundlegenden Prinzipien - und sie haben alle ihre Berechtigung. Welches Framework für eine bestimmte Aufgabenstellung geeignet ist und den konkreten Bedarf einer Organisation für die Skalierung agiler Verfahren am besten erfüllt, hängt von mehreren Faktoren ab. Mitunter können sich auch komplexe Frameworks als besonders geeignet erweisen: Sie geben einen Rahmen vor und bieten so gute Orientierung, lassen aber durchaus viel Raum für Anpassungen. Fest steht: Märkte und Kundenanforderungen verändern sich in immer kürzeren Zeiträumen. Mit dem geeigneten agilen Skalierungsframework können auch große Organisationen die Flexibilität gewinnen, darauf mit der nötigen Geschwindigkeit zu reagieren.