Um den Straßenverkehr zu regulieren, gibt es zwei Wege:
Das herkömmliche System besteht aus Ampeln. Sie zeigen den Verkehrsteilnehmern, wann sie anhalten und weiterfahren sollen. Dann gibt es noch den Kreisverkehr. Dieser ist ein kreisförmiges System mit ein- und ausfahrenden Straßen. Autos fahren hinein, weichen anderen Autos aus und fahren dann wieder heraus.
Warum erzähle ich dir das?
Ampeln verkörpern für mich Regeln. Kreisverkehre stehen für Prinzipien.
Regeln sind gut für vorhersehbare Situationen. In Zeiten mit sehr wenigen oder sehr vielen Autos auf der Straße versagen jedoch Ampeln. Prinzipien hingegen bieten einen Handlungsspielraum. Dieser Raum ermöglicht mehr Selbstständigkeit, Kreativität und Verantwortungsübernahme. Bei sehr geringem Verkehrsaufkommen kannst du schnell durch einen Kreisverkehr fahren. Sind allerdings sehr viele Autos auf der Straße, solltest du sehr langsam fahren, sonst kommt der Verkehr zum Erliegen.
In Scrum haben wir beides.
Es gibt Regeln und Prinzipien. Etwa, dass das Daily Scrum nicht länger als 15 Minuten dauern darf. Und das Prinzip: „Liefere ein ‚Done‘-Inkrement in weniger als 30 Tagen.“
In den letzten Jahren habe ich in vielen Unternehmen geholfen, Scrum zu skalieren. Aufgrund dieser Erfahrungen wurde ich im Jahr 2021 als Steward für das „Scaled Professional Scrum“-Training der Scrum.org ausgewählt. Ein Fehler, der mir immer wieder begegnet ist:
Fehler 1: Scrum-Regeln skalieren
Scrum-Regeln zu skalieren ergibt wenig Sinn.
Am Sprint Review sollen Stakeholder und Entwickler zeitgleich teilnehmen. Wie soll das aber funktionieren, wenn die Mitglieder eines Teams auf der ganzen Welt verteilt sind?
Dieses Beispiel zeigt, dass die Scrum-Regeln, die für ein Team funktionieren, nur schwer auf mehrere Teams skaliert werden können. Was ist der Ausweg? Wollen wir Scrum skalieren, dann müssen wir die Prinzipien hinter den Regeln skalieren.
Hier drei Scrum-Prinzipien, die skaliert werden sollten:
- Liefere ein „Done“-Inkrement in weniger als 30 Tagen: Das Inkrement ermöglicht es, empirisch zu planen und das finanzielle Risiko zu kontrollieren.
- Gemeinsame Ziele, um während des Sprints Zusammenhalt zu schaffen: Ziele liefern Fokus auf die Arbeit im Sprint, helfen zu entscheiden, was wichtig ist und was nicht. Gemeinsame Ziele fördern auch die Motivation.
- Scrum-Teams sind interdisziplinär und managen ihre Arbeit selbst: Dies führt zu weniger Abhängigkeiten und reduziert somit Wartezeiten. Selbstmanagement eliminiert Hierarchien und fördert die Verantwortungsübernahme im Team.
Regeln helfen Anfängern, die Prinzipien zu lernen. Je besser wir Scrum meistern, desto besser verstehen wir die Prinzipien dahinter und können uns von den Regeln lösen. Beim Skalieren sollten diese Prinzipien jedoch unter allen Umständen beibehalten werden, wenn wir die Vorteile von Scrum skalieren wollen.
Was uns zum nächsten Fehler bringt:
Fehler 2: Über die Vorteile von Rahmenwerken debattieren
Betrachten wir nochmal das Prinzip:
„Scrum-Teams sind interdisziplinär und managen ihre Arbeit selbst.“
Welche Möglichkeiten fallen dir ein, dieses Prinzip über ein Scrum-Team hinaus zu skalieren?
Hier einige Ansätze:
- Definieren von gemeinsamen Zielen über Teamgrenzen hinweg
- Dezentralisierte Entscheidungsfindung fördern: etwa durch die Erstellung von Designvorlagen
- Weitere Rollen und Verantwortlichkeiten einführen (etwa Chief-Product-Owner oder Release-Train-Engineer (RTE))
- Zugang zu Ressourcen und Informationen für jeden ermöglichen (etwa durch Shared-Code-Ownership oder Inner-Open-Source-Vorgehen)
- Übergeordnetes Projekt-Management-Office etablieren
- Durchführung von teamübergreifenden „Scrum of Scrums“-Meetings
- Community of Practice (CoP): für fachspezifische Zusammenarbeit und Entscheidungen
Dir fallen bestimmt noch viele weitere Ansätze ein. Aber was ist das richtige Vorgehen, um das Prinzip „Scrum-Teams sind interdisziplinär und managen ihre Arbeit selbst“ zu stärken?
Hierzu habe ich in der Vergangenheit vier Wege beobachtet:
- Argumentieren: Unternehmen entscheiden sich für den Ansatz mit den meisten Vorteilen. Ein RTE passt möglicherweise besser in eine Unternehmensstruktur als eine CoP.
- Expertenwissen: Unternehmen vertrauen der Meinung eines Experten.
- Rahmenwerk: Unternehmen vertrauen darauf, dass etwas, was bereits bei vielen Unternehmen funktioniert hat, auch bei ihnen funktionieren wird.
- Experimentieren: Unternehmen vertrauen nicht auf Meinungen und Erfahrungen anderer, sondern sammeln ihre eigenen Daten.
Aus meiner Sicht liegt der größte Fehler darin, dass Unternehmen auf logische Argumente beim Skalieren vertrauen. „Unsere Analyse hat ergeben, dass SAFe besser ist als LeSS, da es besser mit unseren Unternehmenswerten vereinbar ist.“
Was sie stattdessen tun sollten: mit den möglichen Ansätzen experimentieren. Die richtige Frage sollte also lauten: „Welcher Ansatz skaliert am besten ein Prinzip hinter Scrum?“
Was uns zum letzten Fehler bringt:
Fehler 3: Skalieren ohne Nachweis von Erfolg
Experimentieren ist in der agilen Gemeinde in aller Munde.
Dabei wird eine Sache häufig übersehen. Einfach mal etwas zu tun und es dann im Nachhinein als Experiment zu bezeichnen, wenn es sich gut anfühlt, ist kein Experiment. Experimentieren beginnt damit, eine Hypothese zu formulieren und Metriken zu etablieren. Dann wird ein Zeitraum für das Experiment festgelegt. Am Ende dieses Zeitraums wird überprüft, ob sich die Hypothese aufgrund der Datenlage bewahrheitet hat oder eben nicht.
Ein Beispiel:
Wir glauben, dass wir mit der Einführung der Rolle eines Release-Train-Engineers das Prinzip „Scrum Teams sind interdisziplinär und managen ihre Arbeit selbst“ skalieren können. Wir liegen richtig, wenn sich drei Monate nach der Einführung der Rolle die Time-to-Market wieder auf 30 Tage reduziert.
Hierbei sollten wir nicht vergessen:
Die Skalierung von Scrum sollte nicht zum Selbstzweck geschehen. Der einzige Grund, Scrum zu skalieren, ist, dass wir mehr Wert liefern wollen. Bewahrheitet sich das nicht, sollte Scrum wieder deskaliert werden. Scrum zu skalieren ist eine Wette auf den ROI. Durch mehr Teams steigt die Innovation. Diese sollte sich positiv auf den Wert auswirken.
Hierbei kann Wert mithilfe der vier Bereiche aus dem Evidence-Based Management-Framework bestimmt werden:
- Aktueller Wert: Der gegenwärtige Wert, den ein Produkt oder eine Dienstleistung im Moment für die Kunden schafft.
- Nicht realisierter Wert: Hier wird das Potenzial bewertet, das noch nicht ausgeschöpft wurde.
- Fähigkeit zur Innovation: Dieser Bereich misst die Fähigkeit einer Organisation, Neuerungen einzuführen und sich an Veränderungen anzupassen.
- Zeit bis zur Markteinführung: Dieser Bereich misst die Effizienz und Geschwindigkeit der Prozesse, die notwendig sind, um Ideen vom Konzept bis zur Markteinführung zu bringen.
Wird Scrum erfolgreich skaliert, dann sollte sich dies in diesen Wert-Bereichen widerspiegeln.
Du willst nicht blind einer Blaupause bei der Skalierung von Scrum vertrauen?
Sondern stattdessen die Scrum-Prinzipien kennenlernen, die skaliert werden sollten? Beispiele für Experimente erfahren, die diese Prinzipien stärken? Und Metriken zur Erfolgsmessung kennenlernen? Dann empfehle ich dir den Besuch des „Scaled Professional Scrum“-Trainings.
Gemeinsam mit Peter Götz widmen wir uns dort ausführlich der organischen Skalierung von Scrum.