Safe and unsafe words…

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.

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