Es gibt mittlerweile zwei Frameworks für Scrum im Großen:
Dean Leffingwell und seine Firma haben 2011 das recht ausführliche SAFe oder Scaled Agile Framework online gestellt und schieben nummerierte Updates nach. Es illustriert eine sehr elaborierte große agile Organisation.
Bas Vodde und Craig Larmann folgten 2014 mit LeSS oder Large Scale Scrum, welches auf ihren sehr hilfreichen Büchern von 2009 „ Scaling Lean und Agile Developement: Thinking and Organizational Tools for Large-Scale Scrum“ und 2010 „Practices for Scaling…“ basiert. Das ist ein sehr schlankes Framework, das die Bücher nicht ersetzt, sondern eher einen guten Einstieg in alle Themen bietet.
In den letzten Monaten werde ich immer häufiger gefragt, ob man ein solches Framework bei der Einführung von Scrum in großen Organisationen verwenden soll. Dahinter stehen Fragen wie ob es einfacher wird, kostengünstiger, man weniger lesen muss, oder gar ob man es fertig kaufen kann und nur noch ausrollen lassen muss.
Gerade der Ansatz von SAFe suggeriert dies: es ist bewährt, oft erfolgreich angewendet worden. Und das Ausrollen in einer beliebig großen oder komplexen Organisation erfolgt durch eine Serie von zertifizierten Trainings durch zertifizierte Trainer, die es praktischerweise in vielen Ländern gibt.
Drei Schritte: Training für die internen Coaches, Training für das Management, dann für die Teams – als komplette Release-Trains innerhalb von 5 Tagen. Und fertig? – Na ja, da braucht man für viele Situationen dann doch noch erfahrene externe Coaches, denn gelernt ist ja nicht wirklich gekonnt, und was man noch nicht selbst angewendet hat, kann man auch schlecht coachen.
Ich weiß noch, wie viel und wie lange wir diskutiert haben bei der Einführung von Scrum in unserer großen und verteilten Organisation. Dabei hatten wir viele Voraussetzungen schon im Laufe der Vorbereitungen geschaffen, z.B. Testautomatisierung für den bestehenden Code erhöht, häufigere Builds, und Informationen über vorhandene technische Schulden gesammelt und ins Backlog integriert. Aber schon allein die Tatsache, dass die Verteilung der Organisation über die verschiedenen Standorte ganz anderen Kriterien folgen musste als vorher, da wir ja gemischte Teams wollten, die ganze Features entwickeln und testen können, hat schon viel Kopfzerbrechen verursacht. Es sollten viele Leute in anderen Rollen arbeiten als zuvor. Einige Rollen hatten wir an bestimmten Orten zum ersten Mal. Wie viele Feature Areas sollten wir bilden, und wer war für welche Feature Area als Area Product Owner geeignet? Alle diese Dinge kann man entscheiden, wenn man sich schon eine Weile damit auseinander gesetzt hat und erfahrene Sparringspartner hat.
So ein Framework kann einem dabei helfen, alle Gebiete zu finden, über die man nachdenken muss. Es kann einem ein paar Lösungen zeigen, die sich schon bewährt haben – was natürlich wieder in bestimmten Organisationen mit bestimmten Kontexten und Randbedingungen war. Die Bücher von Vodde und Larman haben uns damals sehr geholfen, weil sie nicht als Bibel daher kamen, sondern mit Mustern, die man unter bestimmten Umständen sinnvoll anwenden kann, die aber unter anderen Umständen heftig scheitern können. Manchmal haben sie sogar empfohlen, Muster die sie zuvor als falsch und un-agil dargestellt hatten, in bestimmten vertrackten Situationen dennoch als Workaround einzusetzen.
Auch im Scaled Agile Framework haben wir einige interessante Lösungen gefunden, z.B. das Verhältnis zwischen Kundenfeatures und technischen Features und wer dafür sorgt, dass beide hoch genug priorisiert werden – siehe Program Backlog. Man muss eben nur auch hier alles als Anregung sehen, was in bestimmtne Kontexten funktionieren kann.
Meinen Erfahrungen entspricht, was im LeSS Framework zum Ausrollen gesagt wird: Eine agile Transition funktioniert weder nur top-down noch nur bottom-up, sondern es muss immer in beide Richtungen gehen. Lieber anfangs eine kleine Abteilung oder ein kleines Produktteam umstellen, und das richtig tief, dabei wirklich gut experimentieren und lernen – und dann in der größeren Organisation ausbreiten und mehr lernen. Viel mit Freiwilligen machen, so dass Selbstorganisation auch zum Ausrollen der Selbstorganisation verwendet wird!
Mit einem solchen Ansatz ist die Verwendung eines Frameworks für Scrum im Großen sinnvoll. Die eigentliche agile Transition bleibt dabei immer in den Händen der Organisation, die sie tun will, und die ja auch die Verantwortung für ihre wirtschaftlichen Ergebnisse, ihre Experimente und ihr Lernen hat. Die externen Coaches können nur unterstützen.
– Vor einigen Tagen haben sich übrigens ein paar Freiwillige aus verschiedenen Firmen zusammen gefunden, um das Large Scale Scrum Framework ins Deutsche zu übersetzen. Wer Interesse hat, dabei mit zu machen, kann gerne der Xing-Gruppe beitreten und mich kontaktieren! https://www.xing.com/communities/groups/large-scale-scrum-8e98-1052168
Andrea's Agile Reflections 