Agile Skalierung und ihre Herausforderungen

Heutzutage ist Scrum als agiles Framework in der Softwareentwicklung kaum mehr wegzudenken. Viele Unternehmen haben verstanden, dass ein Wandel der eigenen Organisation notwendig ist, um den veränderten Bedingungen in unserer Arbeitswelt zu begegnen, und haben es sich zum Ziel gesetzt, durch agile Entwicklung mit einer höheren Effizienz Produkte an ihre Kundschaft auszuliefern, wozu je nach Größe verschiedene Frameworks genutzt werden, die wir euch an dieser Stelle vorstellen möchten.

Scrum, das bekannteste der Frameworks, verspricht, bei korrektem Einsatz den Weg in die Agilität zu ebnen. Unserer Ansicht nach ist Scrum jedoch mittlerweile zu einem Schlagwort avanciert, das oft verwendet wird, obwohl Vorgehensweise und Konsequenzen nicht ausreichend verstanden wurden. Dabei ist noch nicht berücksichtigt, dass Scrum als ein Framework zur optimalen Ausrichtung auf ein explizites Team erdacht worden ist. Heute sind Produkte in der Regel so groß und komplex, dass üblicherweise mehrere effektiv zusammenarbeitende Teams benötigt werden, die alle das agile Framework und seine Techniken verwenden können, um die der Kundschaft oder der Userinnen und User zur Verfügung gestellten Produkte nachhaltig zu verbessern.

Die Organisation dieser interdisziplinären agil arbeitenden Teams hinsichtlich der Strukturen, Schnittstellen und Absprachen nennen wir agile Skalierung, durch die bedeutsame Veränderungen entstehen.

Auch für die agile Skalierung lassen sich mittlerweile verschiedene gut beschriebene Frameworks, Methoden und Best Practices finden. Auszuwählen, ob eines dieser Angebote auf die eigene Organisation, die Rahmenbedingungen, die beteiligten Menschen und die Situation passt, ist oftmals schon ein Projekt für sich, da die agile Skalierung die Erweiterung der agilen Prinzipien über Abteilungsgrenzen und -ebenen hinweg erfordert, was wiederum zu enormen Herausforderungen führt. Unserer Erfahrung nach ist jedes System, ob Individuum, Team, Skalierung oder ganze Organisation, immer wieder völlig anders, mit eigenen Bedürfnissen und Prozessen, so dass wir bisher noch keine Methode gefunden haben, die wir uneingeschränkt empfehlen. Oftmals schlagen wir eine Kombination aus Best Practices und Teilen von etablierten Frameworks oder Methoden aus der agilen Welt vor, die in Kombination wiederum eigene Mehrwerte erzeugen. Dazu führen wir im Vorfeld Gespräche mit möglichst vielen beteiligten Personen des Systems. Hierbei interessieren primär die Ideen und Vorstellungen des Managements, deren Hauptfokus in der Regel die Geschäftsfähigkeit ihrer Produkte betreffen.

Betrachten wir aber nun gezielt das „Verlangen“ und die Herausforderungen agiler Skalierung, die überwunden werden müssen, um für eine Organisation eine Mehrheit zu generieren.

Agile Skalierungsframeworks kurz skizziert

Jeff Sutherland, einer der Schöpfer von Scrum, erkannte die Herausforderungen in Organisationen schon frühzeitig und erweiterte das Scrum Framework um das Scrum of Scrums. So entstanden weitere agile Frameworks und Methoden, die sich kontinuierlich etablierten, um nahezu passgenaue Lösungen für verschiedenste Organisationen bereitzustellen und ihre „Roadmaps“ genauer zu skalieren:

Scrum@Scale: Das von Jeff Sutherland geschaffene Meta-Level-Framework zielt darauf ab, Scrum in größeren Organisationen zu skalieren. Es besteht aus einem Scrum Master Cycle und dem Product Owner Cycle, für die es vordefinierte Fragen gibt, deren Beantwortung das „normale“ Scrum anpassen soll.

Scaled Agile Framework® (SAFe®): Das Scaled Agile Framework definiert sich als Wissensbasis bewährter, integrierter Prinzipien, Praktiken und Kompetenzen zur Erwirkung von geschäftlicher Agilität durch Lean, Agile und DevOps. SAFe ist ein zuverlässiger Ansatz zur agilen Skalierung, der die Planung auf diversen Organisationsebenen beinhaltet. Dazu nutzt SAFe den Agile Release Train (ART), um somit Teams in Summe von bis zu 125 Personen in der Planung, Entwicklung, Implementierung und Freigabe zu koordinieren.

Disciplined Agile (DA): Disciplined Agile ist ein von Scott Ambler ausgearbeitetes Framework, das sich hauptsächlich mit Entscheidungsprozessen befasst und auf den vier Prinzipien „Menschen zuerst“, „Lernorientierung“, „Agilität“ und „Hybridität“ aufbaut. Entscheidungen müssen getroffen werden, um im Nachgang eine klare Qualität zu erreichen. Wie diese ausfallen muss, wird durch DA nicht definiert, stellt jedoch alle Entscheidungen zielorientiert zusammen, um eine Skalierung erfolgreich durchzuführen.

Large-Scale Scrum (LeSS): Wie der Name bereits sagt, widmet sich das von Craig Larman und Bas Vodde entwickelte Framework LeSS der Grundidee, so einfach und klein wie möglich im groß angelegten Kontext angewandt werden zu können. Man könnte auch sagen, dass LeSS lediglich die Frage auswirft, was man zu Scrum noch hinzufügen müsste, um die Arbeit mit mehreren Teams funktional zu gestalten.

Die Bedeutung agiler Skalierung

Agiles Vorgehen in einer Organisation ist in der Regel Scrum und damit auch das aile Manifest und basiert auf den Werten „Individuen“ und „Interaktionen“, „Zusammenarbeit mit den Kundinnen und Kunden“, „Reagieren auf Veränderungen“ und „Funktionelle Produkte“. Daher bezieht sich die agile Skalierung im Sinne von SAFe auf die Annahme, Scrum auf größere Einheiten, bestehend aus fünf bis elf Mitgliedern pro Gruppe, übertragen zu können.

Bei der agilen Skalierung sollten jedoch mehrere Faktoren einbezogen werden, um effektiv und effizient Produkte entwickeln zu können, um diese erfolgreich und richtig im Unternehmen zu etablieren, auf die wir in der Kürze nur rudimentär eingehen können und wollen. Stichworte sind an dieser Stelle: Benutzerrolle, Product Owner, Release Definition, Teamgröße, Spezialisierung, Iterationslänge oder Ähnliches.

Die Frage nach den Kompetenzen

Haben wir zum Beispiel einen Product Owner, können wir erste Überlegungen zu den Umsetzungsteams anstellen. Der Product Owner bringt die User- und/oder fachliche Sicht auf das Produkt.

Gegebenenfalls gibt es im Unternehmen auch Architektinnen oder Architekten, deren Aufgabe es ist, die technischen Ausprägungen innerhalb des Unternehmens gezielt zu konsolidieren, „up to date“ zu halten und Neuerungen zu etablieren. Diese holen wir ebenfalls gerne in diese Diskussion zu den benötigten Kompetenzen für das Umsetzungsteam dazu.

Neben Architektinnen und Architekten können natürlich auch versierte und interessierte Mitarbeitende, sowohl aus fachlicher als auch aus technischer Sicht, die Diskussion zur optimalen Teamzusammensetzung unterstützen. Üblicherweise versuchen wir Führungskräfte an dieser Stelle nicht einzubinden, da es im ersten Schritt noch nicht um konkrete Mitarbeitende gehen soll.

Die Frage nach den Kapazitäten

Haben wir die grundsätzlichen Kompetenzen, stellt sich direkt die Frage nach den Kapazitäten. Wie wir aus Scrum wissen, fällt die mögliche Performance eines Teams mit weit mehr als neun Mitgliedern schnell wieder zusammen. Daher raten wir, hier darüber nachzudenken, mehrere Teams aufzustellen. Der Overhead der Abstimmung zwischen schlagkräftigen kleinen Teams ist wesentlich kleiner als die Abstimmungen innerhalb eines zu großen Teams.

Haben wir uns für mehrere Teams entschieden, sollten wir die Kompetenzen zwischen den Teams so verteilen, dass jedes dieser Teams innerhalb seines Sprints möglichst selbstständig und alleinverantwortlich arbeits- und im besten Fall releasefähig ist.

Die Praxis zeigt, dass es oftmals in Organisationen spezielle Sonderrollen gibt, deren Expertise wir zu Teilen in unterschiedlichen Teams benötigen, aber nicht für jedes Team solche Mitarbeitenden vorhalten können. In diesen Fällen empfehlen wir die Sonderrolle zwischen den Teams springen zu lassen, aber als Arbeitsauftrag immer den Wissenstransfer mitzugeben. Auf diese Weise können die Teams kleinere, weniger komplexe Sonderthemen mit der Weile selbstständig lösen, ohne die Sonderrolle bemühen zu müssen, somit wächst ihre Autarkie.

Teamzusammensetzung

Wenn wir nun also auf dem Papier bereits die Kompetenzen und Kapazitäten für die Teams bestimmt haben und der Product Owner mit seiner Verantwortung platziert wurde, gibt es verschiedene Möglichkeiten, nun aus dem Pool der Mitarbeitenden der Organisation das Staffing der Teams durchzuführen.

Nicht zuletzt gilt die Empfehlung, bei der Auswahl der Kompetenzträgerinnen und -träger für die Teams die Charaktere der jeweiligen Personen stark zu berücksichtigen. Es hilft uns am Ende nicht, wenn zwar theoretisch alle notwendigen Kompetenzen im Team vorhanden sind, diese aber nicht abgerufen werden können, weil zwischenmenschliche Schwierigkeiten im Wege stehen.

Eine beliebte Methode ist die Selbstorganisation. Sie bewirkt, dass sich im Ergebnis in der Regel ein Konsens einstellt, der auch längerfristig bei allen Teams Zufriedenheit über die Teamaufstellung gewährt. Der Rat ist an dieser Stelle zu einer größeren Veranstaltung mit den verfügbaren Mitarbeitenden. Zur Einstimmung empfehlen wir dem Product Owner, eine Produktvorstellung vorzubereiten. Hierbei sollte der Fokus auf dem Mehrwert für die potenziellen Nutzenden liegen, um die Mitarbeitenden bestmöglich zu motivieren diesen Mehrwert zu erschaffen.

Dieser Zuordnungsprozess kann je nach Anzahl an Teams, die gebildet werden müssen, länger oder kürzer sein. Empathische Kolleginnen und Kollegen der Organisation können hier als Ansprechpartnerinnen und -partner und Ratgebende durchaus sehr hilfreich sein.

Womit wir auch zu den Scrum Mastern, Kanban Mastern und Team Coaches kommen (je nach Framework des Teams). Die unterschiedlichen Bezeichnungen spielen hier jedoch keine Rolle, da der Auftrag in allen Fällen derselbe ist: die Effektivität des Teams fördern und kontinuierlich steigern. Der Einfachheit halber sprechen wir in der Folge nur noch vom Scrum Master.

Die Auswahl des passenden Scrum Masters für ein Team kann ebenfalls im Workshop stattfinden, da eine gewisse Sympathie zwischen allen Teammitgliedern gewährleistet sein muss. Gibt es im Pool der Mitarbeitenden noch keine ausgebildeten Scrum Master, ist es dringend erforderlich, sich über den Aufbau dieser Kompetenz Gedanken zu machen. Gegebenenfalls wird diese Kompetenz von außen eingekauft oder es gibt im Pool Kolleginnen und Kollegen, die eine Umorientierung in diese Rolle anstreben.

Arbeitsorganisation

Bevor ein Team oder hier in diesem Fall ein ganzes System anfangen kann, produktiv Aufgaben für das Produkt zu bearbeiten, muss eine Struktur sowohl innerhalb jedes Teams als auch in der übergreifenden Abstimmung zwischen den Teams für das gesamte System ersichtlich definiert werden, was schlussendlich auch von dem verwendeten Framework abhängt und diverse Herausforderungen birgt. Dazu werden wir euch im nächsten Beitrag zu diesem Thema mehr erläutern.