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

Manage flow, not people!

Flow is King. Agility is a side-effect.

Image of mikefreislich

Mike Freislich

Double Down on Scrum Fundamentals: Help Remote Teams Thrive

Teams have moved to remote work: the great news for Scrum teams is that you already have the building blocks in place allowing you to succeed

Image of daniellynn

Daniel Lynn

Agile Coach
Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.
Image of barbara.schultz

Barbara Schultz

Complexity, Chaos, and COVID-19

Applying Cynefin & Complexity Thinking to navigate the COVID-19 crisis: a panel webinar recorded on April 2, 2020

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.

Like a breath of fresh air...

Boost your Easter weekend with Carrington-Brown's Rap for agile42

Image of marion

Marion Eickmann

I am one of the founders and the executive director at agile42. I have supported strategic product development and leadership development for longer than 15 years. Since 2007 I have been realizing local and global agile projects with agile42's international team successfully. You like to talk about: ORGANIC agility, complexity, resilience, organizational culture & Agile? Just send an email :-)