Wozu brauchen wir Frameworks für Scrum im Großen wie #LeSS und #SAFe ?

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.

LeSS works

– 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

Scaling Agile with Frameworks – a SAFe path to LeSS work?

Ok, I admit right away that am just fooling around with the names of the two known large scale agile frameworks in the title – SAFe is the Scaled Agile Framework by Dean Leffingwell and company, and LeSS is Large Scale Scrum by Bas Vodde and Craig Larman.

The first book I read about scaling agile was from Dean Leffingwell, in 2007. I met Bas Vodde at my first Scrum Gathering in Stockholm 2008, and after I heard him talk about feature teams, I bought the book about scaling agile by him and Craig Larman as well, and of course we tried to apply much of that during our agile transition at Siemens Healthcare SYNGO. The book came very helpful since it clarified many of the questions behind the simple mechanics of agile, e.g. which effects queues have on you development organization, or how should the organization structure adapt to agile, and which other topics or areas beyond R&D are concerned.

In the last couple of months various people kept asking me about “Should we apply a large-scale framework to our agile transition?” – and asking back I get the underlying questions, of course, will we be faster, safer, cheaper, avoid start-up problems, will we have to read less stuff and discuss less if there are solutions available online and even people rolling out the one or the other framework licensed by the respective framework’s prophet(s)?

OK, let’s see if they themselves come with a warning message, like the drugs do in Germany, a little paper full of text that is in each box.

 

LeSS

„LeSS is not “new and improved Scrum.” Rather, it is regular Scrum, an empirical process framework in which you can inspect and adapt to any method and work in a group of any size. Large-scale Scrum is a set of additional rules and the set of tips that we have seen work in large multi-team, multisite, and offshore agile development initiatives. These tips are experiments to try in the context of the classic Scrum framework.“ (http://less.works/less/principles/large_scale_scrum_is_scrum.html)

 

SAFe

The Scaled Agile Framework (SAFe) is a proven knowledge base for implementing agile practices at enterprise scale.” “We, the contributors, offer this web version to the market in the hope that it will help all software development practitioners and team – as well as their employers – enjoz the satisfaction that comes from delivering ever-higher quality software at ever-faster speed” (http://www.scaledagileframework.com/about/)

OK, sounds good, but how can people start using it?

Now I switch to the “Implementation” page of SAFe: (http://www.scaledagileframework.com/implementing/)

Implementation is done in three steps, which come with lots of training and certification with trained and certified SAFe trainers: step 1 Change Agents, step 2 Management & Executives, step 3 teams and agile release trains – challenging, in 5 days per train, 8-12 Scrum teams per release train. Maybe it is intended for different kinds of enterprises than those I know, which have a lot of legacy to reflect about: structures, processes, products, codebases… and include properly into their new setup, so that they can go on delivering something to their customers.

 

So what do the LeSS guys say about implementation?

“These principles are crucial to an organizational LeSS adoption:

  • deep and narrow over broad and shallow
  • top-down and bottom-up
  • use volunteering”

“Prefer applying LeSS in one product really well over applying LeSS in many groups poorly.

Focus LeSS adoption effort on one product group, give them all the support they need, and ensure they work really well. This minimizes risk and if you fail it triggers a focused learning opportunity. And when you succeed it creates a positive “word on the floor” that’s vital nourishment for further adoption.”

And so on. I could not have phrased it better.

It reminds me of what a manager from another big company reported last year: lean and agile transitions worked great in their organizations which had self-chosen to transition with a mixed bottom-up/top-down approach, and where there were convinced local coaches. It did not work at all in organizations that were made “lean” through a big top-down rollout.

Frankly, I cannot imagine that any internal coaches who have neither seen nor done any agile work themselves, in product development teams on the ground, can be of much use in a large-scale rollout. So you need to start small, experiment, learn your own lessons.

By the way: yes, the LeSS guys are also offering trainings and even certifications. I would recommend to send people there who are already such local agile practitioners and have either worked in an agile team themselves for at least one year, or have been active participants in a transition team at smaller scale for at least the same time, and take the course in order to know more and improve, or roll out to a larger part of their organizations.

Don’t get me wrong: I think the SAFe framework can also a great source of inspiration and hints for solutions for organizations going agile in small or large-scale. I remember that we had a problem with making the product owner team feel responsible for prioritizing technical debt and technical improvements high enough, and we found a good example in SAFe how this can be solved: by agreeing on a percentage of the organization’s velocity dedicated to technical improvements by mutual agreement between architects and product owners, and then prioritization of actual technical backlog items by the architects.

Then only thing that I am very convinced about is that you cannot buy a large-scale agile transition, you do have to do it yourselves.