Die Anwendung von Scrum als Projektmanagementmethode unterliegt jedoch zunächst einigen Einschränkungen. Scrum beschränkt u. a. die Teamgröße auf 9 Projektmitglieder mit verschiedenen Skills wie Entwickler, Architekt oder Tester. Es setzt weiterhin voraus, dass diese an einem Produkt (Projekt) arbeiten. Diese Beschränkungen führen damit zur Notwendigkeit, eine Skalierung von Scrum zu schaffen, d. h. eine Nutzung über diese Grenzen hinaus zu gestalten.
Hier den Newsletter IT und IT Recht 2015 herunterladen
Die Skalierung von Scrum muss dabei die systemimmanenten Restriktionen beachten. Das bedeutet, die agilen Prinzipien aus einem überschaubaren Rahmen in einen ganzheitlichen, unternehmensweiten Ansatz zu überführen, ohne die Vorteile eines agilen Vorgehens zu verlieren. Dieser Beitrag befasst sich konkret mit der Gestaltung eines erweiterten Einsatzes von Scrum. Es wird davon aus gegangen, dass in einem Unternehmen erste Erfahrungen mit Scrum als Projektmanagementmethode vorliegen.
Welche Gründe für Skalierung existieren?
Die Gründe für eine Skalierung von Scrum sind vielfältig. Die drei wichtigsten sollen kurz erläutert werden:
- Größe der Organisation: Scrum ist im Kern nur für Teams bis zu 9 Mitgliedern beschrieben, die an einem Projekt arbeiten. Daher kann Scrum bspw. nicht ohne Anpassung angewendet werden, wenn ein größeres Projekt mit mehreren Teams besetzt ist, d. h. wenn eine Vielzahl von Projektmitgliedern agil arbeitet.
- Anzahl der Projekte: Scrum ist wie schon beschrieben nur für ein Team entwickelt worden. Sollten mehrere Teams nach Scrum (parallel) arbeiten oder auch eine unternehmensweite, agile Ausrichtung im Fokus stehen, reichen die Ausführungen des Scrum Guides nicht mehr.
- Umfeldanforderungen nach „klassischen“ Prinzipien: Oftmals trifft eine Nutzung von Scrum als Projektmanagementmethode auf Unternehmensrahmenbedingungen wie Stabilität, Governance, starre Projektmanagementvorgaben oder eine vorherrschende „klassische“ Unternehmenskultur.
Grundsätzlich gilt bei allen Ansätzen zur Skalierung von Scrum: Je einfacher und passender solche zusätzlichen Konzepte sind, desto flexibler agiert die Organisation. Ergänzend genutzte Methoden sollten den agilen Grundprinzipien nicht widersprechen, d. h. es sollten also insbesondere keine oder nur sehr wenig zusätzliche Hierarchien eingeführt oder die Selbstorganisation zu stark eingeschränkt werden.
Welche Ansätze gibt es?
Bei einer Skalierung von Scrum hilft es nicht, einen an anderer Stelle erfolgreichen Ansatz (Best-Practice) für die eigene Skalierung zu kopieren. Stattdessen müssen die agilen Prinzipien möglichst durchgängig angewendet werden und mit den Anforderungen aus der eigenen Organisation sinnvoll kombiniert werden, um den eigenen Weg zu finden. Diese Forderung basiert auf der Basis von Scrum, nämlich einer empirischen Prozesssteuerung. Diese bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden.
Schaut man sich zum Thema „Skalierung von Scrum“ einmal um, so wird sehr häufig in der agilen Fachliteratur Scrum aus sich heraus skaliert und dieser Weg als einzige Möglichkeit dargestellt. An dieser Stelle sollen daher neben dieser Variante („Enterprise Scrum“) drei weitere dargestellt und bewertet werden.
Paralleles Miteinander
Die einfachste und naheliegende Möglichkeit, Scrum zu skalieren ist es, weitere dezentrale Scrum Teams zu schaffen. Diese werden ohne weitergehende Vorgaben und Regelungen begleitet und zentral unterstützt. Diese Dienstleistung durch entsprechende Organisationseinheiten (ggfs. Personen aus dem ersten Scrum Team) bedeutet keine Steuerung. Vielmehr ist Unterstützung in Form von Dokumentationen, Bereitstellung eines Wikis oder der Organisation von Communities of Practice sinnvoll. Weiterhin kann eine zentrale Implementierung der Toolunterstützung oder die Verhandlung von Einkaufsverträgen mit externen Lieferanten hilfreich sein.
In der Praxis ist diese Variante aus meiner Einschätzung recht häufig an zutreffen, weil u. a. noch keine konkreten Ansätze zu Skalierung unternommen wurden oder der Nutzen einer gesteuerten und geleiteten Skalierung noch nicht auf der Hand liegt. Teilweise sind in diesen Organisationen nur Teilbereiche in dieser Richtung aktiv, da mangelndes Verständnis und Silodenken eine umfassende Nutzung von Scrum verhindern. Eine Synchronisation zwischen parallelen Projektteams ist nur schwach ausgeprägt.
Enterprise Scrum
Wie schon angedeutet, findet sich diese Möglichkeit zur Skalierung recht häufig in der agilen Fachliteratur als zielgerichtete und zentral gesteuerte
Weiterentwicklung einer agilen Vorgehensweise auf Basis von Scrum. Dabei werden neue Rollen (z. B. Company Scrum Master), zusätzliche Artefakte (z. B.Company Product Backlog) und weitere Ereignisse (z. B. Scrum of Scrums und Product Owner Daily Scrum) definiert und das Framework Scrum für mehrere Projekte und eine praktisch unbegrenzte Anzahl von Projektmitgliedern nutzbar gemacht. Das geschieht allein durch die Ausweitung der im ScrumGuideTM beschriebenen Prinzipien und Vorgaben wie dem Pull-Prinzip oder dem Commitment des Teams.
In der Praxis ist dieses Vorgehen dort häufiger anzutreffen, wo das Unternehmen mit Scrum gestartet und gewachsen ist. Insbesondere Unternehmenmit einem starken Fokus im Geschäftsmodell auf Applikationsentwicklung und IT-Angeboten nutzen diese Möglichkeit bzw. haben schon langjährige Erfahrungen.
Frameworks zur Skalierung
Ergänzend zu Scrum haben sich drei Frameworks entwickelt, die für sich in Anspruch nehmen, Scrum zu skalieren. Im Einzelnen sind das
- Scaled Agile Framework (SAFe)
- Disciplined Agile Development (DAD)
- Large Scale Scrum (LeSS)
Diese Frameworks schaffen für die Scrum-Teams einen strukturierten Überbau. Sie sind unterschiedlich in ihrer Ausprägung und der Beibehaltung
bzw. Unterstützung von agilen Prinzipien. So werden teilweise abweichende Werte beschrieben (SAFe ignoriert bspw. kontinuierliches Lernen und das Prinzip „Menschen über Prozesse“) oder agile Praktiken wie das Pull-Prinzip eingeschränkt. In unserem Fallbeispiel würden die Erfahrungen mit dem ersten Scrum-Team umfangreicher ausgedehnt. Neben weiteren Scrum Teams würde zugleich der organisatorische Rahmen mittels eines der Frameworks geschaffen.
In der Praxis ist die Anwendung eines der genannten Frameworks eher selten anzutreffen. Die Zahl der zertifizierten Berater und Schulungsangebote steigt jedoch. Ein lesenswerter Vergleich findet sich unter www.scrum-breakfast.com.
Hybrides Projektmanagement Im hybriden Projektmanagement werden herkömmliche Projektorganisationen mit einem agilen Ansatz verknüpft. Agile Methoden werden in Teilprojekten genutzt und die Kommunikation mit geeigneten Schnittstellen zwischen beiden Welten und passenden Berichtswegen ergänzt. Die resultierende enge Vernetzung der agilen Arbeitsteams mit den angrenzenden klassischen Projektfunktionen führt zu einem eng abgestimmten Vorgehen. So wird eine schrittweise Einbettung der agilen Projektteams in die klassische Projektmanagementorganisation erreicht. In unserem Beispiel wäre schon eine klassische Projektmanagementstruktur vorhanden, die nun mit mehr agilen Projektteams stärker ausgeprägt und institutionalisiert wäre.
In der Praxis ist dieses Vorgehen bei einer starken Reglementierung des Unternehmens bedingt durch Branche oder gesetzliche Vorschriften (Banken, Versicherungen, Chemie- oder Pharmaindustrie) notwendig. Es ist auch dort anzutreffen, wo ein klassisches Projektmanagement eine starke Verankerung in internen Richtlinien und Vorgehensmodellen hat.
Wie sind die Ansätze zu bewerten?
Jede Organisation, die eine Skalierung von Scrum prüft und bewertet, muss die individuellen Rahmenbedingungen vergleichen. Eine ungeprüfte Übernahme einer der dargestellten Ansätze widerspricht einfachsten Managementregeln und den agilen Prinzipien. Die oben beschriebenen Möglichkeiten sollen daher anhand verschiedener Kriterien beurteilt und abgewogen werden:
Kompatibilität der Ansätze
Will man die bestehende Scrum-Nutzung durch einen weiteren Ansatz skalieren, spricht dies sicherlich eher für die Varianten 1 (Paralleles Miteinander) und 2 (Enterprise Scrum). Es muss kein zusätzliches Konzept genutzt bzw. angewendet und in einem Einführungsprojekt adaptiert werden.
Umsetzbarkeit und Nutzen im Unternehmen
Jedes Unternehmen hat das eigene Business, d. h. eine unverwechselbare und einzigartige Identität (Mitarbeiter, Kunden, Produkte, Fertigung, Historie, Kultur, Branche ...). Die Skalierungsmethode muss diesen Punkt angemessen berücksichtigen und abbilden. Ein allgemeiner Blueprint kann diese Anforderung nicht erfüllen, so dass eine Bewertung an dieser Stelle schwierig ist.
Wird das hybride Modell bei großen klassischen Organisationen verwendet, entwickeln sich häufig Probleme aus Anforderungen von Zentralabteilungen wie dem Qualitätsmanagement, einem Projektmanagement Office oder dem Controlling. Diese erhöhen oft nicht den Wert des Ergebnisses und kollidieren mit den Scrumregeln.
Anforderung an handelnde Personen und das Veränderungsprojekt
Agilität und Scrum zu skalieren ist eine komplexe und herausfordernde Aufgabe. Die Realität wird immer wieder von Plänen abweichen, so dass die Einführung iterativ erfolgen sollte und häufiger einen Qualitätsaspekt wie „Inspect and Adapt“ erfordert. Das spricht gegen die Variante 3 mit einem neuen Framework, weil dafür wenige Erfahrungen vorliegen. Wenn in der Organisation kein klassisches Projektmanagement etabliert ist, dann trifft dieser Grund auch gegen die Variante 4 (Hybrides Projektmanagement) zu.
Zielsetzung bei der Skalierung
Wichtig bei der Bewertung ist auch die Zielsetzung, mit der skaliert werden soll. Ist das Ziel, einzelne dezentrale Scrum-Teams zusammen zu führen oder von „oben“ aus einer übergeordneten Unternehmenssicht eine agile Projektvorgehensweise zu etablieren? Bei der agilen Skalierung ist noch stärker als bei der Einführung von Scrum für ein Team moderne Führung gefragt. Führungskräfte geben dabei eine Richtung vor und setzen Randbedingungen, in denen sich Selbstorganisation entfalten und die passende Organisationsstruktur entwickeln kann. Dieses Argument spricht entweder für die Varianten 1 und 2 wenn diese moderne Führung schon erfolgreich praktiziert wird oder für die Varianten 3 und 4, wenn eine Führung eher klassisch hierarchisch agiert.
Gesamtagilität der Skalierung
Agil bedeutet Kulturwandel: Agiles Projektmanagement verlangt einen Wandel in Richtung Offenheit, Kooperation und Teamorientierung. Diese Änderung kann nicht von oben verordnet oder durch einen vorgegebenen Prozess herbeigeführt werden. Die neue Kultur basiert auf schrittweisem Wachstum und Entwicklung. Daher sollte agile Skalierung in einem überschaubaren Ausschnitt beginnen und dann langsam im Unternehmen ausgebreitet werden. Diese Sichtweise spricht eher für die Varianten 1 und 2, da diese im Kern die Erfahrungen mit Scrum im Unternehmen nutzen. Benötigt die agile Kultur jedoch einen festen akzeptierten Rahmen, könnte dieser durch ein hybrides Projektmanagement bereitgestellt werden.
Umfang der Koordination der Teams untereinander
Je stärker eine Koordination der einzelnen Projektteams untereinander erforderlich ist, desto wichtiger ist eine etablierte und akzeptierte Struktur. Arbeiten alle Projektteams an einem Produkt (bspw. einer Applikation) muss die Skalierungsmethode die bisherige Organisation stärker berücksichtigen. Ist also das Unternehmen bisher eher klassisch organisiert, sollte man eine der Varianten 3 oder 4 bevorzugen.
Was ist zu empfehlen?
Eine abschließende Empfehlung für eine der erwähnten Skalierungsmethoden kann an dieser Stelle nicht erfolgen. Dazu sind die individuellen Rahmenbedingungen in der Praxis zu wichtig für einen Erfolg. „Best practice“ muss gegen „empirische Prozessteuerung“ abgewogen werden. Die verlockende Idee, eine erfolgreiche skalierte Struktur eines anderen Unternehmens als Grundlage zu verwenden und zu kopieren wird nicht die beste Lösung ergeben, sondern eher zu einem Projektfiasko führen.
Die Wahl der Skalierungsmethode ist grundlegend sowie richtungsweisend und muss daher immer eine individuelle Entscheidung und von den Faktoren im Unternehmen abhängig sein. Vielzitierte agile Beispiele zur Skalierung wie die von Spotify sind nicht anwendbar auf DAX-Konzerne mit anderem Geschäftsmodell (Automobilkonzerne, Chemieunternehmen oder Maschinenbauer), anderer Führungskultur und abweichender Historie im Projektmanagement.
Aus den oben genannten Ausführungen lassen sich lediglich Tendenzen ableiten. Hat eine Organisation gute Erfahrungen mit Scrum und empirischer Prozesssteuerung, dann kann Enterprise Scrum (Variante 2) bevorzugt werden, ggfs. mit einem Zwischenschritt über Variante 1. Möglich wäre dann auch eine Kombination mit klassischen Ansätzen, d. h. einem hybriden Projektmanagement.
Wenn das Unternehmen aus dem klassischem Umfeld kommt und im bestehenden Gesamtprojektmanagement daher klassisch agiert, dann könnte das hybride Projektmanagement sinnvoll sein (Variante 4), ggfs. auch mit einem Übergang über die Variante 1, d. h. einem parallelen Miteinander. Dieser Übergang könnte auch genutzt werden, das Ziel der Skalierung nochmals zu schärfen und aus der Variante 1 die Skalierung mittels Enterprise Scrum zu wählen und einen Kulturwandel im Unternehmen langfristig zu etablieren.
Autor: Dierk Söllner, Senio Berater. Vereint erfolgreich Business und IT | XING
Hier den Newsletter IT und IT Recht 2015 herunterladen
