March 28, 2014

Safe and unsafe words…

A look at online reviews and discussions about the Scaled Agile Framework®

The worldwide Agile community is debating these days mostly about one single thing, and this is the Scaled Agile Framework® or SAFe™ as it's commonly known. We have studied extensively the subject both in the fields and as part of our Enterprise Transition Framework (ETF) approach which may include SAFe as a component according to the organization needs.

We will publish something very soon but as an end-of-week read we suggest you a selection of a few posts by popular leaders in the Agile and Lean community who have weighted on this Framework from their own points of view.

Pillow fight

It's worth starting with a slightly older (August 2013) comment from Ken Schwaber (early proponent of the Agile Manifesto and Scrum). Ken takes issue with SAFe from an historical point of view, since it looks to him like a rehashing of older practices:

The boys from RUP (Rational Unified Process) are back. Building on the profound failure of RUP, they are now pushing the Scaled Agile Framework (e) as a simple, one-size fits all approach to the agile organization. They have made their approach even more complicated by partnering with Rally, a tools vendor. Consultants are available to customize it for you, also just like RUP.

Also David J Anderson, the proponent of the Kanban Method, wrote last year about it in the same fashion of "something old":

SAFe is delivered as a framework that must be tailored. Ideally you pay an expert or team of experts to do this. They design your solution from elements within SAFe and then they manage a transition initiative to "install" the process solution in your organization. This approach fits right in with the requirements in CMMI ML3 for process tailoring. It could be straight out of a 1990s textbook on process engineering.

Most recently, the online discussion has been kickstarted by Dave Snowden in a strong worded blog post titled  SAFe: the infantilism of management where he writes "brutally SAFe seemed to be PRINCE II camouflaged in Agile language". The post has been heavily commented and shared on Twitter and other social networks.

My strong and increasingly passionate argument was that SAFe is not only a betrayal of the promise offered by AGILE but is a massive retrograde step giving the managerial class an excuse to avoid any significant change. OK its a obey making machine but the same applies to snake oil salesmen and the South Sea Bubble. People will get damaged by this nonsense and it needs to be hamstrung at least, garrotted at best.

Such excuses abound and allowing these false linear models to perpetuate themselves is a form of infantilism, a failure to carry through on the need for change. In particular the failure to realise that software development needs to be seen as a service and as an ecology not as a manufacturing process.

Other commenters have participated, usually in the last weeks, to SAFe introductions and classes and they started discussing on finer points. We already linked Peter Saddington's comprehensive review of what he's witnessed in the training and his insights into the methodology from the point of view of an experienced Agile practitioners.

“I have no crystal ball. I can’t tell the future. One thing I can see happening is this: The SAFe model is the lowest barrier to entry for scaled agile work at the current moment.”

Ron Jeffries took a training as well, and he sees both good things and bad things in the approach.

I recently took the SAFe SPC training, with instructors Jennifer Fawcett and Al Shalloway. My bottom line assessment is that it will be a marketing success, organizations trying it will see improvement, and some will see great improvement.

And I don’t like it. SAFe isn’t really Agile in its heart. It does have many good elements, which I’ll talk about here. And I still don’t like it. I’ll talk about that as well.

SAFe will be successful in the market. People will benefit. They just won’t benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.

SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.

Ron tackles a specific aspect which is, in fact, the main reason for SAFe:

SAFe’s fundamental assumption is “You’re large, therefore you need to ‘scale’, therefore organize like this and impose this approach.” That turns out to be wrong.

First of all, you’re probably not large, you’re probably kind of biggish. If you’re a Fortune 1000 company full of programmers, well, maybe. If you only have a few thousand programmers, probably not.

Second, most of your projects are not really very large. Most of them can be handled by a single Agile team, or a few Agile feature teams. All of these can be handled in the standard Scrum or Agile fashion, with an empowered Product Owner to guide them and a few joint meetings to keep coordinated.

Daniel Gullo wrote a very detailed report on his SAFe class from the point of view of a Certified Scrum Trainer.

As long as I am able to work with a client implementing “SAFe” and we are allowed to tailor it to include the helpful parts and throw out the harmful parts, I don’t see anything really evil or wrong with SAFe here.  What we are left with is doing precisely what I have already been doing for the last 8 years:  looking for how to instill the values and principles Agile and Lean in the culture of an organization so that a paradigm shift toward continuous innovation and customer delight happens.  The net result is that they understand why they are following the practices they choose to follow and not just blindly implementing methodologies.

If the ultimate answer [to most questions] is “It depends…” then I don’t see that SAFe is adding any value beyond what is already in the toolkit of most experienced Agile coaches.  There is a definite marketing bent toward the middle tier of management since Scrum does not provide a prescription for or limit on what middle management can or should do during an Agile transformation.  In fact, this targeting of middle tier management was made clear on the first day.  There are references made to centralizing some decisions and decentralizing others; i.e. making strategic decisions in business and management and more tactical, delivery decisions at the team level… just like in Scrum.  It’s the classic “what” vs “how” distinction.

What's your opinion? Please share in the comments!

Photo "Pillow fight" by docpop

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks
blog comments powered by Disqus
Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Latest Posts

Niels Verdonk, new Certified Scrum Trainer in the Netherlands

Niels Verdonk has qualified as a Scrum Alliance Certified Scrum Trainer

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.

Sponsoring Manage Agile 2017

agile42 is a sponsor of Manage Agile 2017 conference in Berlin for managers in agile companies

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Joanne Perold keynote at Regional Scrum Gathering 2017

Coach Joanne Perold presenting at SGZA17, the Regional Scrum Gathering South Africa 2017

Image of peterhundermark

Peter Hundermark

Peter has worked with iterative and incremental software development processes since 1999, focusing on Scrum and Agile practices since 2006. In 2007 he started Scrum Sense in South Africa. He has introduced Scrum into scores of development teams locally and in Brazil. He leads certified Scrum training classes in South Africa and elsewhere. He is a Certified Scrum Coach and Certified Scrum Trainer.

Scrumtisch January 2018

The Berlin Scrum User Group meets on January 24th at SAP in Rosenthaler Str.

Image of aballer

Alexandra Baller

agile42 Team Assistant

Coaching structures in Tampere

Martin von Weissenberg delivered a presentation about Coaching Cards and the agile42 Coaching Structure at Tampere Goes Agile 2017

Image of mvonweis

Martin von Weissenberg

Martin helps people understand agile and lean thinking and coaches teams and organizations in the use of agile methods and practices. He is a Scrum Alliance Certified Enterprise Coach (CEC) and is working on a PhD on how to manage and organize for agility.