Is SAFe Agile? The Case for SAFe

I’m new to Agile, relatively speaking. I first heard of it only five years ago. Up until now, I had little to no exposure to SAFe (Scaled Agile Framework). I did have some informal conversations with other Agilists about the framework at meetups and conferences. Having now completed SAFe for Teams, I have a few thoughts on the framework.

What is SAFe?

Basically, it’s a project management methodology. Project management is a noble endeavor and a robust, involved field of study. A talented project manager is hard to find, and good project management brings tremendous value to an organization. SAFe offers a set of rules that can help provide airtight, fool-proof project management.

Does SAFe get a bad rap?

It seems so. In a highly unscientific survey, I searched the web for “does SAFe get a bad rap.” I found a litany of criticisms from many accredited Agile content providers. When I searched for “the case for SAFe,” the SAFe website dominated the results. To be clear, I think SAFe gets a bad rap, but that it’s undeserved.

What’s wrong with SAFe?

I believe SAFe is mislabeled and miscategorized. It’s not Agile. By that, I mean it does not conform to the principles and values in the Agile Manifesto. In particular, SAFe emphasizes following a plan at the expense of responding to change. It places adherence to process over individuals and interactions. This clashes with two value statements from the Agile manifesto. I like SAFe, but I  don’t see much overlap between SAFe and Agile.

If anything, I take issue with the fact that the acronym contains the word Agile. I’d rather call it SFe (scaled framework), though that wouldn’t be as catchy as SAFe. To make an analogy, I enjoy chocolate cake and I enjoy pizza, but I would never categorize pizza as a type of chocolate cake. That’s no knock on pizza. But if you categorize it as chocolate cake, you are miscategorizing it.

What’s right with SAFe?

Agile Manifesto aside, I’ve seen great things happen when teams adopt and embrace Scrum, XP, Kanban, and a DevOps mindset. SAFe loudly endorses these frameworks, methodologies, and philosophies for individual teams and I like that. There are also many other concepts in the SAFe literature that I believe are very helpful such as customer-centricity and improving the flow of work.

SAFe’s breakdown of work into value streams and Agile Release Trains (ARTs) and the workshop known as PI planning are all nothing to sneeze at. If everyone does their part and follows all of the rules, I expect SAFe to work well. It is a little process-heavy and PI planning inevitably marries us to a longer-term plan, which gets in the way of responding to change, but I don’t think those are bad things if your development effort has minimal uncertainty.

The Bottom Line

SAFe may be unsafe in certain cases, especially in environments with a high level of uncertainty. In these situations, teams need agility and more room for adaptation than this framework provides. However, when customers know what they need and just want it built, SAFe looks to be a good way to keep teams aligned, on track, and ultimately delivering on time.

Interested in learning more about our thoughts on Agile? Check out our Agile blogs to learn more on the topic.