Das sogenannte Referenzmodell in Scrum@Scale ist ein sehr wichtiges Konzept, das Ihnen auch helfen kann, selbst wenn Sie kein Scrum@Scale nutzen. Es besagt Folgendes: Wenn Sie eine Organisationstransformation oder ein Change Management durchführen, können Sie das als Big-Bang-Transformation angehen – also einen plötzlichen Wandel von Alt auf Neu. Im Rahmen von Scrum würde das zum Beispiel bedeuten, mit 200 Teams gleichzeitig zu starten. Genau das passiert häufig – und scheitert ebenso häufig. Scrum@Scale sagt daher: Das macht keinen Sinn. Wenn wir eine Transformation machen, sollten wir stattdessen mit zwei bis drei Teams starten – nicht mit allen 200 oder 2000 Teams auf einmal.

Dafür gibt es drei Gründe. Der erste Grund: Wir haben so die Möglichkeit, die besten Leute in diese Teams zu stecken. Stellen Sie sich vor, Sie starten mit 200 Teams, ohne jemals zuvor Scrum eingeführt zu haben. Woher bekommen Sie 200 gute Scrum Master? 200 gute Product Owner? Wie trainieren Sie sie alle? Das ist ein gigantischer Aufwand. Statt die Ressourcen zu verstreuen, konzentrieren Sie die besten Leute auf zwei oder drei Teams. So sichern Sie die Qualität sowohl auf der Personal- als auch auf der Methodenseite und schaffen eine starke Referenz. Daher auch der Name: Diese Teams dienen als Referenzmodell für alle Teams, die später folgen. Sie zeigen, wie hochwertiges Team-Level-Scrum aussieht und was möglich ist. Andere Teams können sich daran orientieren.

Der zweite Grund: Transformation ist immer auch politisch. Mit zwei oder drei exzellent geführten Teams können Sie schnell erste Erfolge erzielen, die sich dann intern zeigen und kommunizieren lassen. Das schafft Vertrauen und Unterstützung von weiteren Stakeholdern. Wenn Sie hingegen mit 200 oder 300 Teams gleichzeitig starten, entsteht zunächst Chaos – und es dauert sehr lange, bis sich vorzeigbare Ergebnisse einstellen. Kleine, gut funktionierende Teams ermöglichen schnelle, sichtbare Erfolge und helfen, mehr Rückhalt in der Organisation zu gewinnen.

Der dritte und wichtigste Grund: Wenn Sie eine Transformation starten – insbesondere mit Scrum – werden Sie zwangsläufig in Impediments hineinlaufen. Für Scrum-Leute ist das völlig normal: Impediments sind keine Störung, sondern eine Chance zur Verbesserung. Es gibt dabei verschiedene Arten von Hindernissen. Kleine Impediments, wie ein defekter Drucker, kann ein Team meist selbst lösen. Aber es gibt auch große, strukturelle und organisatorische Impediments – zum Beispiel eine Urlaubsregelung, bei der Urlaub zu einem festen Stichtag verfällt. Das führt in vielen Unternehmen regelmäßig zu Problemen, etwa kurz vor großen Releases, wenn viele Mitarbeitende gleichzeitig Urlaub haben.

Wenn Sie direkt mit 200 Teams starten, laufen alle Teams gleichzeitig in diese strukturellen Hindernisse hinein. Besser ist es, wenn zwei bis drei Teams zunächst als Vorhut starten – ähnlich wie im Militär, wo eine Speerspitze die Lage sondiert, Probleme erkennt und Zeit verschafft, um Lösungen zu entwickeln. So verhindern Sie, dass alle 200 Teams gleichzeitig gegen dieselben Wände laufen. In Scrum geht es sehr stark um die Beseitigung von Impediments. Manche davon sind gravierend, und man möchte nicht, dass die gesamte Organisation gleichzeitig davon betroffen ist.

Diese drei Punkte sind der Grund, warum das Referenzmodell in Scrum@Scale so viel Sinn ergibt – und zwar auch dann, wenn Sie gar kein Scrum@Scale verwenden. Selbst mit anderen Methoden ist es klug zu überlegen, ob ein Big Bang wirklich sinnvoll ist oder ob man nicht besser mit einer kleinen, starken Vorhut beginnt.

Wenn Sie mehr über Scrum@Scale oder Business Agilität im Allgemeinen erfahren möchten, biete ich regelmäßig Seminare zu diesen Themen an. Weitere Informationen dazu finden Sie auf Team Flow.