In diesem Blogpost versuche ich mal eine Sammlung der verschiedenen Sichtweisen auf das Thema agile Skalierung (also der Organisation von agiler Entwicklung, wenn mehr als ein Team notwendig ist).
Scaled Agile Framework™ (SAFe)
Das Methodenframework SAFe von Dean Leffingwell erfährt im Moment viel Beachtung und ist höchst umstritten:
- Video, das SAFe in 7 Minuten erklärt: http://www.agilerescue.de/safe-in-7-min/ (Anmerkung von mir: Das, was in dem Video als „Scrum“ beschrieben ist, deckt sich in relevanten Teilen nicht mit dem, was ich als „Scrum“ kenne.)
- Webseite: http://scaledagileframework.com
- Kritik von Ken Schwaber: Der Scrum-Erfinder argumentiert ähnlich wie Jutta und weist darauf hin, dass man – wenn man sich für SAFe entscheidet, sehr genau die business-relevanten Fortschritte überwachen sollte, die man sich von Agilität verspricht.
- Kritik von David Anderson: Der Software-Kanban-Erfinder sagt, dass SAFe bereit seit langem bekannte Praktiken anderer Autoren zusammengestellt hat und dass durch diese methodenhafte Zusammenstellung das genaue Gegenteil von dem gemacht wird, wofür Kanban steht: schrittweise Verbesserung. David meint, dass schrittweise Verbesserung a la Kanban besser in die aktuelle Zeit passt.
- Kritik von Jutta Eckstein: Jutta argumentiert, dass Agilität ein Kulturwandel bedeutet und dass SAFe zu prozesslastig sei, um diesen Wandel zu unterstützen.
- Ron Jeffries: SAFe – Good But Not Good Enough
- Ron Jeffries: Issues with SAFe
- Dave Snowden: SAFe – the infantilism of management
- Chris Matts: SAFe vs. Theory of Constraints
- Daniel Gullo: SAFe SPC Training: A Reflection
- Tobias Mayer meinte auf Twitter über SAFe: „Decent way of managing dependencies across teams. It misses the better question though: how do we not have dependencies.“
- Ilja Preuss auf Twitter: „I always had the hunch that SAFe is for those who want to „do agile“ without having to give up waterfall…“
- Peter Stevens hat SAFe mit anderen Ansätzen wie DAD und LeSS verglichen.
- Sallyann Freudenberg: A retrospective on using the Scaled Agile Framework at Travis Perkins
Die deutschsprachigen SAFe-Protagonisten, mit denen ich selbst gesprochen haben, stimmen der o.g. Kritik interessanterweise im Wesentlichen zu. Sie argumentieren aber, dass SAFe trotzdem ein erster Schritt hin zu ein ganz klein wenig mehr Agilität sein kann, dass man SAFe sowieso nicht so implementieren würde, wie es beschrieben ist und dass man direkt nach der Implementierung damit anfangen müsste, es sofort zu ändern (überspitzt: wieder zu demontieren).
Ein SAFe-Trainer meinte, er sähe die größte Gefahr von SAFe darin, dass viele SAFe-Trainer und Coaches Agilität nicht verstanden hätten und daher keinen sinnvollen Einsatz von SAFe sicherstellen könnten. Wer sich tatsächlich für SAFe entscheidet, sollte also viel Aufwand darin stecken, den agilen Erfahrungshintergrund der Trainer/Coaches intensiv zu durchleuchten (das gilt natürlich generell für die Auswahl von Coaches/Trainern). (Vielleicht sollte man sogar prinzipiell immer jemanden mit an Board holen, der SAFe für Unsinn hält 🙂
Disziplined Agile Delivery (DAD)
DAD von Scott Ambler hat lange nicht die Aufmerksamkeit wie SAFe erreicht. Das erklärt vielleicht auch, warum es deutlich weniger Kritik dazu gibt.
- Webseite: http://disciplinedagileconsortium.org
- Peter Stevens hat DAD mit SAFe und LeSS verglichen.
Large Scale Scrum (LeSS)
LeSS von Craig Larman und Bas Vodde ist eigentlich gar keine echte eigene Methode, weil schlicht das Scrum-Framework für die Skalierung interpretiert wird.
- Einführungsartikel
- Peter Stevens hat LeSS mit SAFe und DAD verglichen.
Agility Path
Agility Path von scrum.org liefert im Gegensatz zu SAFe, DAD und LeSS keine Struktur für skalierte Agilität, sondern definiert den Prozess, wie man zu dieser Struktur kommt. Ähnlich wie SAFe und DAD ist es direkt kommerzialisiert.
- Webseite: http://www.agility-path.com
Auch bei Agility Path könnte man diagnostizieren „im Westen nichts Neues“. Das, was Agility Path ausmacht, haben Ken Schwaber und andere agile Praktiker schon vor Jahren beschrieben. Man begleitet die Einführung und Ausbreitung von agil kontinuierlich und setzt dafür ebenfalls Inspect&Adapt ein (häufig bildet man ein Transitionsteam dafür).
Enterprise Transition Framework™ (ETF)
Das ETF von Agile42 scheint mir im Grunde fast identisch mit Agility Path zu sein. Vielleicht ist einer der Gründe für die Existenz, dass Agile42 die Scrum-Zertifizierungen der Scrum Alliance anbietet und ein Gegenpol zu Agility Path von der Konkurrenz-Zertifizierungsorganisation scrum.org schaffen wollte.
We don’t need no new methods
Und dann gibt es noch die Gruppe derjenigen, die meinen, dass man für agile Skalierung keine neuen Methoden braucht und schon gar keine mit Trademarks. Die Prinzipien, die wir für die agile Skalierung brauchen, kennen wir bereits seit Jahren. Die Praktiken für die Skalierung sollten schrittweise passend zum Unternehmen gefunden werden. Inspirieren sollte man sich bei der Suche nach geeigneten Praktiken von der Praxis (z.B. bei anderen Unternehmen) und nicht von Methoden. (Dieser Gruppe gehöre ich selbst an).
- Webseite mit Skalierungsprinzipien: http://scaledprinciples.org
- it-agile dazu: http://www.it-agile.de/agile-skalierung
- Scrum Sense dazu (inkl. Vergleich mit SAFe, DAD, LeSS): http://www.scrumsense.com/blog/scaling-scrum-organisation
- Skalierungsprinzipien von Arlo Belshee
- Skalierung bei Spotify
- Skalierung bei Nielsen Media Research
- Skalierung bei Jimdo
- Skalierung bei Wooga
Was fehlt?
Wenn Ihr noch Ressourcen kennt, die das Bild vervollständigen, hinterlasst mir einen Kommentar zu diesem Artikel. Ich werde den Artikel dann ergänzen.
Stefan Roock 
Hinterlasse einen Kommentar