Scrum@Scale: Agile Skalierung für Organisationen
Scrum gibt es seit 1993. Seitdem hat es sich als Defacto-Standard durchgesetzt, wenn es um agile Arbeitsweisen geht. Ergebnisse können schneller geliefert und Risiken besser mitigiert werden. Da Kunden bereits früh in die Produktentwicklung eingebunden sind, können sie besser auf Ergebnisse einwirken und sind zufriedener. Teams erhalten mehr Autonomie und sind motivierter bei der Arbeit.
Scrum lässt sich auch außerhalb der Produktentwicklung einsetzen. Nicht nur in einzelnen Teams, sondern über die gesamte Organisation skaliert. Im Kern beantwortet es die Frage: Wie finden wir heraus, was unsere Kunden brauchen und wie schaffen wir es, in einer angemessenen Zeit zu liefern? Gerade in einer aufkeimenden Rezession wird diese Frage für viele Unternehmen überlebenswichtig. Als Antwort auf eine Krise reicht es nämlich nicht mehr, nur Kosten zu sparen. Wenn Unternehmen keine neuen Produkte entwickeln, finden sie keine neuen Kunden.
Der Miterfinder von Scrum, Dr. Jeff Sutherland erforscht seit den 1990er Jahren diese Frage: Wie lässt sich Scrum in einer Organisation skalieren? Und zwar so, dass die Leistung der einzelnen Teams nicht durch einen hohen Koordinierungsaufwand oder Bürokratie vermindert wird.
Seine Antwort heißt Scrum@Scale. Hier geht es darum, dass Unternehmen ihren eigenen Ansatz ihrer Skalierung finden. Da Scrum auf Selbstorganisation der Teams beruht, fokussiert sich Scrum@Scale darauf, diese Selbstorganisation zu nutzen und die Organisation schrittweise zu entwickeln.
Warum ist Selbstorganisation essenziell?
Ein entscheidender Faktor, warum Projekte sich verzögern oder scheitern ist Entscheidungslatenz: Wie lange dauert es, bis in Ihrem Unternehmen eine Entscheidung getroffen werden kann? Wie lange dauert es, bis große Entscheidungen getroffen werden können? Was sind die Folgen, wenn Entscheidungen bei Ihnen nicht oder zu spät getroffen werden?
In Scrum werden Entscheidungen im Unternehmen an die Product Owner und die Teams delegiert. Product Owner pflegen einen engen Austausch mit ihren Kunden, und validieren in kurzen Zyklen, ob sie richtig entschieden haben. Teams legen selbst fest, wie sie arbeiten wollen. Wenn Entscheidungen schneller getroffen werden können, können auch schneller Ergebnisse geliefert werden.
Wenn eine starre Hierarchie zu viel Bürokratie verursacht, können Entscheidungen nicht mehr schnell getroffen werden. Daher hat Scrum@Scale das Ziel, nur eine „minimal überlebensnotwendige Bürokratie“ aufzubauen. Genauso wie in einem Scrum Team das „Was“ vom „Wie“ getrennt wird, geschieht dies auch auf Unternehmensebene.
Was ist Scrum@Scale?
Scrum ist ein sogenanntes „Meta-Framework“. Es beruht auf der Annahme, dass sich Systeme am besten entwickeln können, wenn sie „skaleninvariant“ sind. Das funktioniert gut mit einer objektorientierten Architektur. In einem objektorientierten System geht es darum, dass Module oder Komponenten miteinander kommunizieren. Der Schlüssel zur Entwicklung großer und erweiterbarer Systeme liegt eher darin, zu entwerfen wie die Module kommunizieren, als zu entwerfen, was ihre internen Eigenschaften und die Verhaltensweisen sein sollten.
Daher ist das Wesen in Scrum@Scale seine 12 Komponenten (s. Bild). Jede Komponente hat Ziele, liefert Ergebnisse (Outputs) und benötigt dafür die Ergebnisse anderer Komponenten (als Inputs). Sie funktionieren wie Blackboxes. Das Innenleben muss also nicht zentral von der Organisation gesteuert werden. So wiederum können Entscheidungen schneller getroffen werden.
Genauso wie Scrum, ist Scrum@Scale leichtgewichtig. Wenige Regeln sollen dabei helfen, dass jeder das System versteht und es verändern kann. Genauso funktioniert das mit Scrum@Scale. Hier geht es nicht vordergründig um Skalierungs-Praktiken, sondern darum, auf die wesentlichen Prinzipien zu schauen: Welches Hindernis ist gerade am wichtigsten und welche Komponente könnte dabei helfen, die Situation zu lösen?
Wie startet man mit Scrum@Scale?
Typischerweise startet ein kleiner Teil der Organisation mit Scrum, zwischen drei und neun Teams. Nach wenigen Wochen schaffen es Teams, effizienter zu liefern. Es werden Hindernisse in der Organisation transparent, die die Lieferfähigkeit der Pilotteams behindern.
Deshalb starten parallel zwei Managementteams: Ein Team, das sogenannte Executive Action Team, hat die Aufgabe, diese Hindernisse zu lösen. Es stellt sicher, dass die erste „agile Zelle“ im Unternehmen funktioniert. Es hilft dabei, dass Teams gutes Scrum machen und etwas ausliefern können, sie sich verbessern und koordinieren können, und dass sie Feedback bekommen.
Das andere Managementteam, genannt Executive MetaScrum Team, kümmert sich um die strategische Vision, aus der eine übergreifende Priorisierung abgeleitet wird. Die Priorisierung spiegelt sich in den Aufgaben der Teams und in einer Releaseplanung wider. Feedback von Kunden muss ausgewertet und die Auswirkungen auf die strategische Vision des Unternehmens müssen untersucht werden.
Diese einzelnen Themen sind Teile der zwölf Scrum@Scale Komponenten. Liefert eine Komponente nicht die benötigten Outputs, hat das systemische Auswirkungen auf alle anderen Komponenten. Der Effekt ist ein Leistungsverlust im Unternehmen.
Da wir davon ausgehen, dass sich Unternehmen nicht sofort ändern lassen, nutzen wir die Komponenten als Analysewerkzeuge. Sie geben eine einfache Orientierung, an welcher Stelle die nächste Verbesserung umgesetzt werden muss.
Nehmen wir ein Beispiel:
Drei Teams arbeiten seit wenigen Wochen mit Scrum. Die Teams werden häufig abgelenkt, es wird transparent, dass sie mit zu vielen Dingen gleichzeitig beauftragt werden. Es bleibt nicht genügend Kapazität, die wichtigen Dinge zu lösen. Es entstehen Überlasten und durch die Rüstzeiten werden Lieferungen verzögert.
Dieses Problem können die Teams zwar teilweise selbst lösen, Einflüsse von außen und Managemententscheidungen können sie allerdings nicht abfedern.
Daher kümmert sich das Executive MetaScrum (EMS) um die Themen, die in den Teams nicht selbst gelöst werden können. Ein Hinweis auf mangelnde Zeit ist immer ein Hinweis auf eine unzureichende Priorisierung. Deshalb wendet sich das EMS der Komponente „Backlog Priorisierung“ zu. In diesem Fall macht es sich eine Übersicht über alle Produkte, die geliefert werden sollen und ordnet sie in folgende Kategorien ein:
Quelle: Peter Fischbach
1. Es sind vorhandene Produkte, sie werden zur richtigen Zeit geliefert, und die Kunden sind mit den Ergebnissen zufrieden.
2. Es werden von Kunden neue Produkte nachgefragt, die Teams können zeitlich nicht liefern, daher sind Kunden auch sehr unzufrieden.
Die erste Kategorie mag auf den ersten Blick attraktiv scheinen. Langfristig werden sich jedoch hier Wettbewerber tummeln, um an diesem Markt zu partizipieren. Ein Verharren in diesem Quadranten kann auch zu einem Erstarren innerhalb des Unternehmens führen. Zukünftige Veränderungen als Reaktion auf einen sich ändernden Markt lassen sich schwer umsetzen.
Mit der zweiten Kategorie tun sich die Teams schwer. Mit neuen Produkten lassen sich Kunden gewinnen, aber es entstehen auch hohe Aufwände. Wie lässt sich eine Priorisierung finden, die die Überlast reduziert?
Das Executive MetaScrum Team, die Product Owner der Teams, und ein Chief Product Owner, der für die gesamte Priorisierung verantwortlich ist, prüfen die einzelnen Produkte und sortieren sie nach Geschäftswert und achten darauf, welchen Einfluss sie auf die übergeordneten Ziele des Unternehmens haben. Dabei fällt auf, dass Informationen aus der Komponente „Feedback“ fehlen. Es ist ungeklärt, was das wichtigste Feedback für die Teams ist und wie dieses Feedback der Kunden zurück an die Teams fließt, damit die Teams selbst wichtige Entscheidungen treffen können und nicht mehr auf Führungskräfte warten müssen.
Die Komponente „Feedback“ hat das Ziel, Annahmen zu validieren und zu verstehen, wie Kunden mit unseren Produkten interagieren, um sie zu verbessern. In dem Beispiel kümmern sich die Product Owner darum, dass Teams ausreichend qualifiziertes Feedback erhalten und daraufhin besser priorisiert werden kann, was als nächstes wichtig ist.
Wie diese Komponente ausgefüllt wird, bleibt den Unternehmen selbst überlassen. Scrum@Scale macht hier keine Vorschriften, damit Unternehmen selbst ihre beste Lösung finden können.
