SAFe Is Not Agile

Last week I published my monthly newsletter with the post below as the content (Not on my mailing list? You should subscribe here.) As you can imagine, it stirred up quite a few feelings. Many folks reached out in support of the post. Several folks were, well, less pleased. This makes perfect sense. If the work that someone does centers around the Scaled Agile Framework my post below, attacking this framework, can feel like a personal attack. I feel this way when someone launches an attack on Lean UX so I have a bit of experience here.

One thing I pride myself on is an open mind and a growth mindset. Every single person who sent me constructive feedback (ad hominem attacks go right in the bin) critical of my thesis I invited to share their experiences, case studies not just with me but in a public forum where they can build more goodwill towards this method. Most declined. One agreed. (Stay tuned for when and where that will take place.)

To be clear, I wouldn’t share my thoughts if I felt they weren’t based on first-hand and secondary evidence. I am clearly not the only person who feels this way. There is a clear pattern of respected practitioners, thought leaders, consultants, coaches, et al who’ve given this method a try and decided it doesn’t work for them or their clients.

My main clients are large orgs. I’d say nearly all of them are attempting to implement SAFe. Some are further along than others. All of them are struggling. I’m with them on weekly and monthly basis trying to help them figure out how to make these ideas work AND add in customer-centricity, discovery, learning and course correction. Based on what they’re being taught by their SAFe trainers/consultants they are unable to see how these ideas mix together. Frankly, I don’t have any good answers for them either since moving off the framework is heresy in most cases.

Ever since the Scaled Agile Framework (SAFe for short) adopted Lean UX in version 4.5 I’ve received a steady stream of inbound questions about how, exactly, these two methods are supposed to work well together.  

The short answer is, I have no idea. 

The slightly longer answer is that all the principles we’ve built into Lean UX don’t seem to exist in SAFe. 

Continuous learning and improvement, customer centricity, humility, cross-functional collaboration, evidence-based decision making, experimentation, design and course correction — to name a few — are visibly absent from the SAFe conversation. Instead, organizations adopting this way of working focus on rigid team structures, strict rituals and events and an uneven distribution of behavior change requirements depending on how high up one sits in the organization. 

In short, SAFe is not agile. 

Given the heavy training regimen teams have to go through to become “SAFe certified” it’s no wonder they resist change. They’ve been trained to work in a very specific way — a way focused solely on predictable delivery, not learning, not course correction and certainly not agility. The activities that make teams truly agile require flexibility in planning. They require alignment on customer success, not a predetermined set of features. They require a continuous discovery process that inevitably leads to unplanned course corrections. These corrections would “derail” a Release Train in no time. 

Large organizations seeking agility realize the uncertainty that comes with it and cling to the familiarity of waterfall processes. SAFe gives the illusion of “adopting agile” while allowing familiar management processes to remain intact. In a world of rapid continuous change, evolving consumer consumption patterns, geopolitical instability and exponential technological advancements this way of working is unsustainable. 

If you work in a large organization that has adopted or is in the process of implementing SAFe, ask yourself what’s changed during this transition. Are you closer to your customers? How long does it take to learn whether you’ve delivered something of value? Even better, how are you measuring “value?” Ask yourself how easy it would be to pivot an initiative based on a new discovery? Then compare those answers to how things were before you started using terms like “big room planning”, “PI” and “release train engineer.” 

Scaling any way of working in a large organization is tricky and uneven. Attempting to apply one blanket process to the entire company, a process that is focused strictly on delivery rather than continuous discovery and course correction, only hardens traditional ways of working. SAFe is compelling because it seems to offer a one-size-fits-all recipe for agility at scale. In reality it rewards predictability, conformity and compliance while providing executives with cover for the question, “How do we become more agile?”

What’s been your experience with SAFe? Have you been successful? I’d love to hear your story.

-Jeff

P.S. I just launched a new podcast featuring some of the most creative, successful and interesting folks building and sharing their expertise in many ways. Check it out and subscribe here.