E-Learning: Agiles Arbeiten Skalieren

Die Selbstorganisation in agilen Teams funktioniert erfahrungsgemäß nur bis zu einer bestimmten Gruppengröße. Bei Scrum wird von maximal neun Personen im Entwicklungsteam ausgegangen. In vielen Projekten hat man es jedoch mit deutlich größeren Teams zu tun. Daher stellt sich in vielen Unternehmen die Frage, wie sich das Agile Projektmanagement unter Beibehaltung der Selbstorganisation auf größere Projektteams übertragen lässt. In diesem Zusammenhang wird häufig der Begriff „Scaled Agile“ benutzt.

Die schlechte Nachricht zuerst: Eine praxiserprobte Patentlösung für alle Projekte gibt es nicht. Aber es gibt einerseits sinnvolle Ansätze, aus denen sich Ideen für die eigene Projektpraxis ableiten lassen. Und es gibt andererseits Frameworks (insbes. SAFe und LeSS), die einige Verbreitung in der Praxis haben und einen Blick wert sind.

Im Folgenden werden die wichtigsten Ansätze zur Skalierung von Agilem Arbeiten vorgestellt.

Scrum of Scrum

Die wohl naheliegendste Idee, um Scrum in einem größeren Unternehmen mit deutlich mehr als den vom Scrum-Framework vorgesehenen neun Personen im Scrum Team einzusetzen, ist die »Kaskadierung« des Scrum Prozesses über mehrere Ebenen. Diese Konstellation wird auch häufig als Scrum of Scrum bezeichnet. Auf unterster Ebene gibt es dabei eine Reihe von Scrum Teams, die parallel arbeiten. Aus jedem dieser Teams wird eine Person bestimmt, die in ein übergeordnetes Scrum Team entsandt wird. Diese übergeordnete Ebene soll dann der Aussteuerung der untergeordneten Scrum Teams untereinander dienen. Theoretisch könnte man diese Kaskadierung über mehrere Ebenen wiederholen und somit beliebig große »Scrum of Scrum«-Strukturen aufbauen.

Zur Verdeutlichung der Methode und zur Darstellung ihrer Problematik gehe ich im folgenden Beispiel von nur zwei parallelen Scrum Teams A und B mit einem übergeordneten Team AB aus.

Die Selbstorganisation der beiden Teams basiert darauf, dass jedes Team unabhängig von außen an seinen Aufgaben arbeiten kann. Dies ist nur dann vollständig gewährleistet, wenn die Aufgaben des Teams A vollkommen unabhängig von den Aufgaben im Team B sind, es somit keinerlei Abstimmung zwischen den Teams bedarf. Allerdings ist dies, vor allem dann, wenn beide Teams an demselben Produkt arbeiten, in der Praxis jedoch im Allgemeinen nicht zu gewährleisten. Zur Abschwächung des Problems kann man nun mit einem »Scrum of Scrum«-Ansatz versuchen, den Abstimmungsbedarf zwischen den Teams in ein regelmäßiges Treffen des übergeordneten Teams AB zu verlagern.

Eine ganz ähnliche Konstruktion ist die Einführung eines »gemeinsamen Product Backlog«, aus dem verschiedene (mit ihren Scrum Teams untereinander parallel arbeitende) Product Owner die Anforderungen für ihr jeweiliges Scrum Team ziehen. Ein »Gesamt-Product-Owner« (eine neue Rolle außerhalb des Scrum-Frameworks also) soll dann die Aussteuerung der einzelnen Product Owner untereinander übernehmen.

In der Praxis erweist sich diese Parallelität zumeist als sehr problematisch, da die parallelen Teams A und B letztlich an dem gleichen Produkt arbeiten und der Teufel der Abhängigkeiten im Detail steckt. Es gibt immer wieder einzelne Anforderungen, an denen ein Team gerade arbeitet, die doch irgendwelche kurzfristigen Absprachen mit dem anderen Team erfordern.

In der Softwareentwicklung versucht man, parallele Teams durch formale Softwareschnittstellen zu entkoppeln – übrigens schon seit langer Zeit, bereits lange vor dem Einzug agiler Prozesse wie Scrum. Bis zu einem gewissen Grad ist dies auch möglich. Es erfordert aber eine sehr gute Softwarearchitektur, wie sie in der Praxis eher selten anzutreffen ist. Doch selbst wenn eine gute Entkopplung durch Schnittstellen vorliegt, gibt es erfahrungsgemäß immer wieder Detailprobleme, die von den Schnittstellenabsprachen nicht erfasst wurden und ad hoc und individuell gelöst werden müssen. In Projekten außerhalb der Softwareentwicklung dürfte die Entkopplung paralleler Teams innerhalb einer gemeinsamen Produktenwicklung noch schwieriger sein.

Spotify

Der Musikstreaming-Dienst Spotify hat als Start-up in agilen Prozessen begonnen. Es musste seine agilen Entwicklungsstrukturen dann aufgrund seines Erfolges und der damit einhergehenden steigenden Entwicklerzahlen skalieren.

Die einzelnen, parallel arbeitenden agilen Teams werden bei Spotify »Squads« genannt. Eine Gruppe von Squads, die an einem gemeinsamen Produktbereich arbeiten, beispielsweise »Infrastruktur« oder »Music Player«, wird zu einem »Tribe« zusammengefasst. Die Squads in einem Tribe stehen in besonders engem Austausch miteinander. Personen, die innerhalb eines Tribes ähnliche Expertisen haben, so z. B. zur »Benutzerschnittstelle« oder »Datenbank«, tauschen sich innerhalb eines »Chapters« miteinander aus. Gruppen mit unternehmensübergreifenden gemeinsamen Themen wie z. B. »Produktqualität« werden dann noch in sog. »Guilds« zusammengeführt.

Hier liegt natürlich die Kritik nahe, dass auf diese Weise am Ende doch wieder eine Matrixstruktur aufgebaut wird. Diese Kritik vorwegnehmend spricht Spotify von einer »leichtgewichtigen Matrix«, in der es weniger um Hierarchie als um Community geht. Ob andere Unternehmen diese Strukturen für sich kopieren können, ist fraglich. Zum einen muss zunächst einmal die Akzeptanz der Strukturen bei den Mitarbeitern geschaffen werden. Dies dürfte für Start-ups, die mit sehr wenig Struktur beginnen und ihre Strukturen dann schrittweise ausbauen, wesentlich einfacher sein als für große Unternehmen, bei denen bereits eine starke klassische Struktur vorhanden ist. Zu anderen liefert Spotify mit der gleichnamigen App ein Produkt aus, das sich besonders für die oben gezeigten Strukturen eignet. Denn die Spotify-App ist sehr gut in verschiedene, voneinander relativ unabhängige Teile gegliedert.

Was natürlich eindeutig für den Ansatz von Spotify spricht, ist die Tatsache, dass er in der Praxis entstanden und erprobt ist.

LeSS

LeSS (www.less.works) steht als Akronym für Large-Scale Scrum und bezeichnet sich selbst als »leichtgewichtiges Framework«. Damit ist auch schon eine wichtige Abgrenzung zu dem im Folgekapitel betrachteten SAFe Framework gezogen, das eher als komplex bezeichnet werden kann. Die Wurzeln von LeSS liegen in den Jahren vor 2010, in denen die beiden Väter des Frameworks, Craig Larman und Bas Vodde, in großen Softwareprojekten mit der Skalierung von Scrum experimentiert haben. Im Jahr 2010 fassten sie dann erste Ergebnisse in einem Buch zusammen und gingen kurze Zeit darauf mit der offiziellen Website des LeSS Frameworks online. Seitdem wird das Framework kontinuierlich weiterentwickelt und die Beteiligten sind bestrebt, eine gewisse Einfachheit beizubehalten. Die Einfachheit des Frameworks trägt auch wesentlich zu seiner Attraktivität für kleinere und mittelständische Unternehmen bei, wo es vorwiegend verbreitet ist.

LeSS formuliert einer Reihe von Regeln und Prinzipien, mit denen Scrum auf mehrere Teams übertragen wird, die an dem gleichen Produkt arbeiten. Wesentliche Regeln und Prinzipien sind:

• Es gibt genau ein gemeinsames Product Backlog und genau einen gemeinsamen Product Owner über die verschiedenen Teams hinweg.
• Es ist möglich, optional einen gemeinsamen Scrum Master für mehrere Temas zu haben.
• Es gibt ein zweiteiliges Sprint Planning, eines gemäß Scrum pro Team und ein weiteres über die verschiedenen Teams hinweg. In letzteres kommen als Vertreter die Scrum Master und ausgewählte Team-Mitglieder aller Teams.
• Alle Teams starten und beenden ihre Sprints zum gleichen Zeitpunkt.
• Es findet ein gemeinsames Review der integrierten Ergebnisse aller Teams statt.
• Es gibt eine zweiteilige Retrospektive, eine gemäß Scrum pro Team und eine weitere über die verschiedenen Teams hinweg. In letztere kommen als Vertreter die Scrum Master, der Product Owner und rotierend ausgewählte Team-Mitglieder aller Teams. Der Fokus liegt dann auf übergreifenden Aspekten und Verbesserungsmöglichkeiten.

Während reines LeSS auf bis zu 8 (Scrum-)Teams skaliert, wurde für noch größere Teamstrukturen eine Variante LeSS Huge hinzugefügt. Bei dieser großen Variante von LeSS werden die Teams in sogenannte Requirement Areas(also vereinfacht Produktbereiche) aufgeteilt. Jede Area ist dann eine LeSS Struktur und darüber gibt es wieder ein gesamtes Backlog mit einem Product Owner. In der Beschreibung des Frameworks heißt es: „LeSS Huge adoptions take months or years, infinite patience, and sense of humor.“ Das sollte Warnung genug sein.

SAFe

Das SAFe-Framework (www.scaledagileframework.com) entstand 2011 und hat sich seit dem ständig weiterentwickelt. Insgesamt bietet es recht komplexe, fast schon klassisch matrixorientierte Strukturen mit denen das agile Arbeiten über Abteilungen oder Unternehmen hinweg skaliert werden soll. Es wundert daher nicht, dass es sich insbesondere in großen Unternehmen verbreitet hat, die eine gewisse Affinität zu komplexen Prozessen und Modellen haben. Spricht man mit Menschen, die in SAFe Projekten arbeiten, so hört man bisweilen Aussagen wie „Jetzt sitze ich nur noch in Meetings.“. Gleichwohl wird der Prozess auf höherer Unternehmensebene häufig als hilfreich erlebt. 

Bei SAFe werden zur Skalierung die vier Ebenen Team, Programm, Large Solutions und Portfolio unterschieden:

• Auf der Team-Ebene finden sich Agile Teams, die beispielsweise nach Scrum oder Kanban arbeiten.
• Auf der Programm-Ebene werden bis zu zwölf agile Teams zu sogenannten ART (Agile Release Trains) zusammengefasst. Die einzelnen Liefergegenstände bzw. Inkremente der Teams werden zu sogenannten PI (Program Inkrements) zusammengefasst.
• Muss man noch höher skalieren (weil es insgesamt noch mehr Mitarbeitende in der SAFe Struktur gibt), wird eine zusätzliche, also optionale Large-Solution-Ebene eingeführt. Diese koordiniert dann mehrere ARTs der darunter liegenden Ebene.
• Auf der Portfolio-Ebene werden die Unternehmensstrategie und daraus folgende Produktvisionen betrachtet. Zudem wird die Budgetierung mittels sogenanntem „Value Stream Management“ koordiniert.

Im Original werden die vier Ebenen als „Flow“ bezeichnet, da sie praktisch parallel laufende Prozesse bilden. Neben den hier schon erwähnten führt SAFe noch eine Reihe weiterer Spezialbegriffe ein. Auch beschreibt das Framework Rollen mit speziellen Namen. Kein Wunder, dass es umfangreiche SSAFe gibt, die der Implementierung des Frameworks in einem Unternehmen auf verschiedenen Ebenen vorangehen sollten.

Die Macher hinter SAFe sind sehr bestrebt, ein möglichst umfängliches Framework zu bieten und jeden anzusprechen. So werden in dem Framework auch Design Thinking, OKRs, DevOps, Cloud, Architektur, Agile Organisationen und KI adressiert.