Nachdem ich bereits im Artikel zur Skalierung von Agilität eine erste Bewertung mit Experten für agile Rahmenwerke vorgenommen habe und auch im Dialog mit Boris Gloger die Rahmenwerke kritisiert worden sind, habe ich mich auf gemacht, die Rahmenwerke zusammenzutragen und diese zu beschreiben. Im Folgenden finden Sie also eine Übersicht über Methoden, welche sich mit der Frage befassen: Wie kann man eigentlich Scrum skalieren?
Scrum skalieren mit Frameworks
Unter den Rahmenwerken für agile Entwicklung ist Scrum weit verbreitet. 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. Im Folgenden finden Sie eine Übersicht über relevante Rahmenwerke, sowie eine Bewertung der Maßnahmen und Kosten. Zur einfacheren Bewertung habe ich jeden Mitarbeiter mit Kosten von 100 Euro pro Stunde genommen. Es ist also so, als würden Sie jeden Mitarbeiter als Freelancer einkaufen. Jedes Framework versucht auf seine eigene Art und Weise eine Antwort auf die Frage: „Wie kann man Scrum skalieren“ zu finden. Am Ende habe ich mit agilen Coaches und Boris Gloger Dialoge geführt, um sagen zu können, wie sich Scrum skalieren lässt.
Scrum skalieren mit Scrum of the Scrums
Der einfachste Ansatz zur Skalierung von Scrum ist Scrum of Scrums. Stellen Sie sich ein Projekt mit sechs Teams vor. Jedes Team besteht wiederum aus 8 Teammitgliedern. Alle Teams halten ihr eigenes Daily Scrum Meeting ab. Somit wird ein weiteres Scrum Team, bestehend aus dem Scrum Master des ersten Teams gebildet. Erfahrungsgemäß zeigt sich aus unserer Erfahrung, dass grundlegend eine Scrum of Scrums Ebene pro 6 Teams, wie in der Abbildung gezeigt, gebildet werden sollte.
Scrum of Scrums klingt einfach, jedoch ist dieser Ansatz weit mehr als eine simple Aufteilung der Teams, da Arbeit erfahrungsgemäß oft redundant sein kann und kein ganzheitlicher Blick auf das Projekt gewährleistet ist. Eine Best-Pratice ist, die Teammeetings zeitlich versetzt abzuhalten, um jedem Team zu ermöglichen, die Arbeit der anderen Teams zu begutachten und anschließend in einem Meeting aller Teams das ganze Projekt zu besprechen (Scrum of Scrums). Hier tauschen sich z.B. alle Scrum Master über die teamübergreifenden Prozesse aus. Auch dieses Team hat einen Scrum Master der Scrum Master. Unabhängig dazu empfiehlt es sich ebenfalls, die Dailys versetzt abzuhalten, damit jedes Team das Daily des Anderen besuchen kann und somit Informationen anderer Teams erhält. Im anschließenden Scrum of Scrums werden die teamübergreifenden Probleme besprochen.
Insgesamt ist Scrum of Scrums ein guter Ansatz zur leichtgewichtigen Skalierung von Scrum. Ein Kritikpunkt ist, dass die Stärken eines Scrum of Scrums hauptsächlich im Austausch und Koordination zwischen Teams liegen und weniger in einer übergreifenden Planung. Ein Scrum of Scrums ist kein Planungsprozess im eigentlichen Sinne, sondern ein stetiger Austausch. Wird ein konsolidierter Plan benötigt, so muss dieser gesondert erstellt werden. Meine Erfahrung zeigt, dass dieses leichtgewichtige Konzept für bis zu 6 Teams durchaus funktioniert, jedoch bei mehr Teams in ein zu hohes Abstraktionslevel (scrum of scrums of scrums of scrums) abgleitet. Somit ergibt sich wenig Aufwand für die Einführung, aber ein hohes Risiko, dass es zu Problemen bei der Skalierung mit mehr als 6 Teams führt.
Insgesamt setzt Scrum of Scrums folgende Maßnahmen voraus: Bildung von Koordinationsteam sowie ein Coaching dieser Teams der Scrum Master. Dies verursacht je nach Größe unterschiedliche Transaktionskosten. Diese Kosten sind jedoch im Verhältnis zum Aufwand bis zu 6 Teams recht gering, da jeder Scrum Master hier einige zusätzliche Meetings abhalten muss. Bei mehr Scrum Ebenen, also Scrum of Scrums of Scrums, sind weitere Vollzeitscrummaster nötig, um diese Teams zu koordinieren. Somit verursacht Scrum of Scrums bei 6 Teams einen Mehraufwand von einem Team. Bei 100 Euro Stundensatz, wären das pro 6 Teams (8 Personen) Kosten von 128.000 und 12 Teams von 384.000 Euro (2 Scrum of Scrums of Scrums Team + eine weitere Ebene). Der Aufwand steigt also bei mehr als 6 Teams extrem stark an und steht deswegen im Kosten/Nutzen Verhältnis nur bei maximal 6 Teams noch im gesunden Verhältnis. Für weiterführende Informationen, beachten Sie auch das Buch von Gloger.
Scrum skalieren mit SAFe – Scaled Agile Framework
Das Scaled Agile Framework (SAFe) lässt sich als komplexes Rahmenwerk definieren, welches seine besondere Stärke in der Einbettung von Scrum in klassische Unternehmensbereiche hat. Komplex wird dieses Rahmenwerk, da es über viele Rollen, Prozesse und Praktiken verfügt. Den Kern von SAFe bildet die stabile Organisationstruktur. Ingsesamt basieren die Überlegungen auf dem Lean House von Toyota (Respect, Flow, Kaizen). Das Rahmenwerk selbst unterteilt sich in Team, Programm und Portfolio Ebene. Die Teams organisieren sich „fast wie gewohnt“ nach einem leicht abgewandelten Scrum auf der Basis von XP-Praktiken in der Größe von fünf bis neun Mitgliedern, einem Product Owner sowie einem Scrum Master.
SAFe fasst Teams in der Programmebene in den sogenannten Agile Release Trains (ART) zusammen. Fünf bis zehn Teams (ca. 50-125 Mitglieder) arbeiten in einem Train zusammen und bearbeiten die Herausforderungen eines sogenannten Programms.
Die letzte Ebene ist die Portfolio Ebene, welche die Programme aus Überlegungen der Unternehmensstrategie und Investitionsabsichten mit Budget und Zielvorgaben (Epics) versorgt. Es wird zwischen Business Epics (kundenorientiert) und Enabler Epics (technische Lösungen) unterschieden.
SAFe ist für kleine und mittlere Projekte nicht geeignet. Es bringt eine Vielzahl konkreter Lösungen aus Managementebene und einen hohen Aufwand für die Einführung mit sich. Jedoch kann es eine hohe Zahl an Teams koordinieren und mit den Release Trains auch sehr große Releases problemslos meistern. Für eine kleine Teamanzahl würde ich jedoch von einen schwergewichtigen Rahmenwerk wie SAFe abraten. Hier ergibt sich ein hoher zeitlicher Aufwand bei der Einführung durch die hohe Komplexität. Die Einführung von SAFe lohnt sich in der Regel bei einer langfristigen Umsetzung in der gesamten Organisation.
Um das SAFe Rahmenwerk umzusetzen sind tiefgreifende Maßnahmen nötig. Während auf der Teamebene kaum Kosten entstehen, müssen jedoch im Programm Level Gremien und Sonderteams für den Release Train gebildet werden. Außerdem müssten Metriken zur Messung der Teamebene und des Release Trains festgelegt werden sowie ein weiteres Team zur Integration des Produkts. In der Portfolio Ebene sind weitere Gremien sowie die Einführung von Kanban Teams nötig. Dies sind nur einige der nötigen Maßnahmen. Es stellt sich schnell heraus, dass ein massives Change Management nötig ist und sich dieser Aufwand bei 12 Teams wohl auf ein zusätzliches Release Team, ein Portfolio Team sowie 1 Program Team und ein extra Gremium sowie 2 Change Management Teams und massiven Konzeptionsaufwand verteilt. Alleine diese Teams würden Kosten von mehr als 500.000 Euro (bei einem Team aus Experten mit 100 Euro pro Stunde) in Anspruch nehmen ohne nötigen Aufwand in der Konzeption einzurechnen. Aus diesem Grund steht das Rahmenwerk für 12 Teams in keinem Kosten/Nutzen Verhältnis, da noch eine nicht schätzbare Menge an Changekosten hinzukommen wird. Wie man auf vielen Webseiten lesen kann, lohnt sich das Rahmenwerk jedoch bei einer hohen Anzahl (50-100) an Teams. Hier geht es zur Homepage des Rahmenwerks. Schauen Sie für mehr Informationen in das Buch von Leffingwell.
Scrum skalieren mit LeSS – Large Scale Scrum
Die Grundidee des Large Scale Scrum ist es, Sprintzyklen einzuhalten und wichtige Scrum Events, wie die Sprint Planung Eins und das Sprint Review gemeinsam durchzuführen. Jedes Team hat zwar seine eigene Restrospektive aber darüber hinaus gibt es eine gemeinsame Retrospektive aller Teams. Zur horizontalen Koordination gibt es gemeinsame Product Backlog Refinements und eine Inter-Team-Koordination (z.B. Scrum of Scrums). Das Standardrahmenwerk für bis zu 8 Teams definiert nur einen Product Owner, welcher den Gesamtüberblick behalten soll. Für eine weitere Skalierung wurde das Hugh LeSS Rahmenwerk konzeptioniert. Dieses beinhaltet zusätzlich Area Product Owner, welche dem Main Product Owner berichten.
LeSS definiert also 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 stützt auch mehr als 8 Teams problemlos. Der Scrum of Scrums Ansatz wird mit der hierachischen Struktur der Product Owner erweitert und liefert somit eine schnelle Einführung für bis zu 16 Teams, nach meiner Erfahrung, relativ problemlos.
Die Maßnahmen zur Implemetierung von hugh LeSS sind die Etablierung der gemeinsamen Sprint Teams sowie eines Teams, welches die Integration am Sprintende unterstützt – auch zusätzliche Product Owner sind für die Umsetzung notwendig. Bei 12 Teams sind erfahrungsgemäß 4 zusätzliche Product Owner und ein gesamtverantwortlicher Product Owner nötig. Somit sind Kosten von 80.000 Euro für die Product Owner und 128.000 Euro für das zusätzliche Team nötig. Hier gehts zur Homepage von LeSS. Schauen Sie für mehr Informationen in das Buch von Vodde und Larman.
Scrum skalieren mit Nexus, DAD, …
Insgesamt existieren neben den genannten Rahmenwerken noch weitere Frameworks wie u.a. Ken Schwabers Nexus und das disciplined agile delivery von IBM. Nexus ist grundlegend nur als Guideline bzw. offenes Rahmenwerk und das Framework von IBM nur als Sammlung von Best-Practices zu verstehen. Aus diesem Grund werden diese vernachlässigt. Schauen Sie für mehr Informationen in das Buch von IBM.
Und welches nehme ich jetzt? Wie kann ich Scrum skalieren?
Im Zuge der Forschung zu Agilität habe ich mich mit diesen Skalierungsframeworks eingehend befasst und mich gewundert, sie eigentlich selten im Einsatz zu sehen – Unternehmen scheinen Scrum damit kaum zu skalieren. Ich habe die Frameworks anschließend gemeinsam mit agilen Coaches evaluiert und kam zu einem überraschenden Ergebnis: Eigentlich wurden diese Rahmenwerke von den Coaches als reine Marketingframeworks beschrieben. Menschen würden in ein Framework gedrängt und die eigentliche Freiheit, die Scrum bieten muss, war nicht mehr gegeben. Aus diesem Grund wurde die Einführung solcher Frameworks nach Aussage der Coaches oft auf halber Strecke wieder abgebrochen und es wurde nach neuen Lösungen und Ansätzen gesucht. Auch Boris Gloger hat mir in einen Dialog folgendes gesagt:
Genderhinweis: Seit Anfang 2022 achte ich darauf, dass ich immer genderneutrale Formulierungen verwende. Vor 2022 habe ich zur leichteren Lesbarkeit die männliche Form verwendet. Sofern keine explizite Unterscheidung getroffen wird, sind daher stets sowohl Frauen, Diverse als auch Männer sowie Menschen jeder Herkunft und Nation gemeint. Lesen Sie mehr dazu.Ich habe bei meiner Arbeit immer wieder die Erfahrung gemacht, dass nach agilen Prinzipien gemanagte Großprojekte zu deutlich besseren Ergebnissen führen. Hinter Scrum steckt allerdings mehr als nur ein paar wenige Prinzipien. Somit hat sich herausgestellt, dass agile Rahmenwerke wie SAFe®, LeSS und Co. sehr kompliziert sind. Scrum soll jedoch einfach sein und mit wenigen Schritten auskommen (Boris Gloger).
Rechtschreibung: Ich führe diesem Blog neben dem Job und schreibe viele Artikel in Bahn/Flugzeug oder nach Feierabend. Ich möchte meine Gedanken und Ansätze als Empfehlungen gerne teilen. Es befinden sich oftmals Tippfehler in den Artikeln und ich bitte um Entschuldigung, dass ich nicht alle korrigieren kann. Aber Sie können mir helfen: Sollten Sie Fehler finden, schreiben Sie mich gerne an! Lesen Sie mehr dazu.
Helfen Sie meinem Blog, vernetzen Sie sich oder arbeiten Sie mit mir
Sie haben eigene, interessante Gedanken rund um die Themenwelt des Blogs und möchten diese in einem Gastartikel auf meinem Blog teilen? – Aber gerne! Sie können dadurch Kunden und Fachkräfte ansprechen.Ich suche aktuell außerdem Werbepartner für Bannerwerbung für meinen Blog. Sollte es für Sie spannend sein Fachkräfte oder Kunden auf Ihre Seite zu leiten, dann bekommen Sie mehr Informationen hier.
Tipp: Ich vergebe auch über den Blog eine gratis Zertifizierung zum Digital & Agile Practioner!
Vernetzen Sie sich in jedem Fall auf Xing oder LinkedIn oder kontaktieren Sie mich direkt für einen Austausch, wenn Sie gleich mit mir ins Gespräch kommen wollen. Werfen Sie auch einen Blick in meine Buchvorschläge zur Digitalisierung, vielleicht wollen Sie mir auch ein Buch empfehlen?
Ich arbeite gerne mit Unternehmen zusammen. Sie können mich ebenfalls gerne bezüglich folgender Punkte anfragen:
- Sehen Sie übersichtlich alle Möglichkeiten zur Zusammenarbeit
- Halten von Vorträgen zu Arbeit, Führung und Agilität
- Veröffentlichung von Gastartikeln
- Content Marketing & Texterstellung
- Workshops und Seminare
- Softwareentwicklung für Unternehmen
- Whitepaper für B2B Leads
- IT-Administation AWS, Kubernetes, Ansible, Cloud und Terraform
- Public Relations (PR) für Unternehmen
- Influencer Marketing
- Whitepaper für B2B Leads
