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.