A few thoughts on SAFe

I often get asked what my general stance on this framework is, hence I would like to share my personal opinion with you.

The short answer is: “We don’t live in Cockaigne. Making the world slightly better sure beats dreaming up how it would be perfect. Still, that’s not an excuse to get up on the wrong foot.”

The long answer is this post.

Why use SAFe?

Being an enthusiast agilist, people sometimes ask me how I can support this framework. To me, that’s quite easy to answer – although the answer decomposes into a large number of facets.

Premade decisions

Some organizations have decided to implement SAFe before I get involved with them. I see my responsibility to help organizations find better ways of working, and regardless where they stand, I can do this. SAFe can be a vehicle for simplifying portfolio processes, adopting more reliable development practices, remove pointless status meeting and many other things. Is that local optimization? Could be. But it makes peoples’ lives better.

Where SAFe helps

I know that many agilists will cringe at the idea of actively suggesting SAFe. I don’t see SAFe nearly as much as the problem as the wrong expectations associated with it. Depending on where you currently stand, SAFe can be a stepping stone to a simpler, more effective organization with faster, more flexible decision processes. Which portion of SAFe is needed for that? That totally depends on which problem you want to solve. Don’t use a 40t truck to bring a fork from the kitchen to the dinner table – but when you’re stuck with a gigaton of organizational process mud, Scrum just won’t cut through the problems faster than they accumulate.

Getting out of discussion loops

SAFe’s high market penetration and widespread acceptance cuts short a lot of discussions whether certain concepts are “esoterical” or “applicable in Enterprises”. Pointing to SAFe as a resource collection can break stalemates caused by people who didn’t yet spend time familiarizing themselves with lean and agile mindset. Probably the most common concept that’s incredibly difficult to crack without having a chance to demonstrate is that teams need to be told and controlled in regards to “what to do when” in order to get results.

The SAFe Big Picture

I think that SAFe’s Big Picture is a stroke of genius, because it’s a handy diagram that can be used as a discussion starter to point out what is currently amiss, overcomplicated or ill implemented. Having a deep understanding to explain these concepts to the client is – in my opinion – essential to ensure that we don’t just go about implementing something that meets the form and actually solves the problem at hand. Implement SAFe as per picture is an entirely different issue.

SAFe concepts

True to one of Dean Leffingwell’s favorite Bruce Lee quotes, “Take whatever works, and take it from wherever you find it”, there are a lot of great ideas and concepts included in SAFe. While steering clear of mindlessly applying changes to an organization in places where it doesn’t help, SAFe’s comprehensive practice catalog is a great way to focus discussions with people who have never heard about these concepts before.

Common practice

Arguably, there’s nothing new to SAFe. Everything is “common practice” that has been used time and again in many organizations. Applying SAFe principles and practices will neither make you an industry leader nor a thought leader, but it may get companies unstuck and modernized. This, I think is the main value of SAFe.

What to expect from SAFe?

Expectation management is an important aspect of any change initiative. Agilists who expect a simple, flexible organization where teams have full technical and procedural autonomy will find themselves sorely disappointed by SAFe – because environments where that makes sense aren’t the target audience for SAFe.

SAFe addresses complex organizations where teams are bound by higher-order dependencies, either due to the complexity of the product itself or due to the sheer size of the value stream. A single team can easily build a web platform used by millions – and still, that same team would find themselves overchallenged if said platform was just a part of a much larger ecosystem: There’s a reason why companies like Amazon have more than ten developers.

Staying in the Amazon example, that’s an example of a company with Information Technology in their DNA – they know how to create software, build digital value streams and decouple subsystems. Many enterprises have a DNA where IT is just a fulfilment agency of non-digital business models. It would be a category error to treat these enterprises exactly like a Digital Unicorn. SAFe won’t get you there, either – what it can do, though, is set the change process in motion.

SAFe and the meta endgame

Let’s talk about the digital endgame for a bit. Many organizations struggle with survival. Former market leaders fade to insignificance or disappear into bankruptcy because they don’t understand digital product development. Talk about Kodak, Sears, Blockbuster or recently Thomas Cook. Non-digital giants are in their own endgame already. Unless they change massively, they will disappear.

For such organizations, a good implementation of SAFe can bring them closer to finding their place in a constantly disrupted marketplace. Then, they must move on lest they get stuck in a new status quo.

SAFe and success

A SAFe organization would approach enterprise initiatives differently than traditional Project / Program / Portfolio management. Cutting beyond labels, an “Epic” or “Initiative” (whatever agilists prefer) is still a kind of project. An ill-defined Epic won’t fare better in the face of change than a traditional project. There’s a lot to be said about “How” and “Why” we would even want to use an Epic Portfolio. Organizations that fail to address how they go about scoping, budgeting or implementing software will find very limited benefit in SAFe.

To be more successful with SAFe, it has to go far beyond IT. Portfolio management happens at senior management level, and it must be aligned with non-IT business units. Finance must be on board - accounting must change. We must move away from defining scope and content upfront and become rigorous at examining incremental value and axing initiatives when a value hypothesis turns out to be invalid. This requires a level of courage that many organizations lack. Culture must change as well.

SAFe and developers

A common gripe that many developers have with SAFe is that it leads to higher pressure and doesn’t address the fundamental problems. They therefore claim that either nothing has improved or things got even worse. From a developer’s perspective, and having seen many poor SAFe implementations myself, I could even agree.

I need to put this into perspective, though: Some companies I worked with will state that SAFe has cut their time-to-market in half and significantly reduced the failure rate of critical initiatives. What the developers don’t see – these successes that are totally outside their field of vision have secured their paychecks for many months.

To make SAFe a positive for experience for developers, the organization must work on many topics that may elude many managers: putting developers into control of their own work, providing clear, transparent objectives and meaningful work, improving the working environment and becoming an attractive employer across the board. This must be scoped in the transformation as well.

SAFe and massive change

Put bluntly, if you don’t require massive change, SAFe probably isn’t for you. And with this, I don’t mean a giant (maybe intercontinental) shuffling of the Org Chart. SAFe requires you to make drastic changes at every level, in every way. The organizational change is the easy, simple – and shockingly – insignificant part.

You have to rethink what value is, how you create it, how your organization supports it. You have to rethink which structures work, which don’t, what is local optimization and what is global. You have to rethink the importance explicit, implicit and tacit knowledge have for you. You have to rethink what “knowledge work” is and how you treat your workforce. You have to rethink how management works. How leadership works. How accounting works. How controlling works. How customer satisfaction in a digital environment works. How small things affect the Big Picture. And you have to put all of these pieces of the puzzle together to end up with a sustainable organization.

Key Challenges

SAFe has a number of challenges to overcome that aren’t automatically addressed by the implementation – they are inherent to how traditional organizations tick. I believe that these challenges can be overcome by the right people, given time and patience.

Break the Glass Ceiling

SAFe’s big picture is palatable for people who have zero agile experience, and this picture can be used to provide a satisfactory answer for every potential question one could ask. This gives decision-makers the confidence that this approach will work. Unfortunately, this gives them so much confidence that they will gladly delegate the transformation to members of their organization or consultants who are engaged. This delegation means that “the glass ceiling” is often maintained, i.e. that senior management observes, rather than changes themselves. 

The solution? As a manager, get involved. Be part of the transformation: “be the change that you want to see in the world”.

Mind the Context

To quote H.L. Mencken, “For every complex problem there is an answer that is clear, simple, and wrong”. SAFe has many such answers, and why the answer is wrong isn’t because the answer itself is wrong, but because SAFe doesn’t address your local context. Whether an  answer makes sense, and the action is useful in context or a different approach would be more appropriate – isn’t answered by SAFe. The more confident an organization is that SAFe has the right answers, i.e., the more blindly they trust in SAFe, the less Lean and Agile they will become. 

You require highly educated systems thinkers to solve problems at enterprise level.

Learning Culture

SAFe has a highly complex learning portfolio. Many organizations feel overwhelmed by this and simply skip most of it. Only the managers that lead Release Trains go to Leadership training, SAFe for teams costs too much, and SAFe DevOps is “for when we have extra money”.

This creates a catch-22 situation for SAFe: It’s so complex that you need to invest a lot of time and money to understanding it. And because organizations who want SAFe are usually in search of ways to save time and money, this learning doesn’t happen.

As the proverb goes, “you pay the price for learning one way or another”. Most managers opt for the invisible way of lost productivity, because they don’t understand how massive this cost actually is and because of the way organizations are set up: When developers are struggling with productivity for months, that can be argued easier than getting an extra training and coaching budget.

You need to be serious on learning, not only SAFe, but also Lean Management and Agile Development Practices, to get any sensible result out of any kind of “Agile Transformation”.

Question your setup

When I ask managers which elements from SAFe they need, they take seconds to reply: “Everything”. Asking for specific aspects, like the System or Shared Service Team, the answer is “Of course”. Without looking into all of the details of the framework, these elements, as well as the concept of team-level Product Owners, the functional separation of RTE and Scrum Masters, having multiple Business Owners and many other things create counterproductive dynamics that can reduce an organization’s flexibility, their ability to deliver value and speed of decision making.

These mechanisms address challenges that enterprises may have, but they should be applied with utter caution and avoided if possible. As organizations move further in their agile journey, they will find that these mechanics eventually become impediments to organizational agility and the delivery of value.

The introduction of new concepts should be taken with caution – which it often isn’t. New mechanisms should be implemented only to address a significant, well-understood problem.

Engage middle managers

Managers, traditionally, keep themselves out of operative details lest they be called “micromanagers”. Under the umbrella of “team autonomy”, they disengage even further from the work of the teams. What sounds good is actually SAFe’s biggest problem, because managers don’t learn how the work really works. Even after a prolonged period of time, managers thus often face two key problems: First, they lack the understanding and insight to spot and resolve local optimization. Second, as team autonomy increases and interaction with managers is actively reduced, teams lose trust in management decisions: proximity creates trust!

At a minimum, managers need to start “walking gemba” and experiencing how people work. Even better, they need to get into the trenches and engage deeper and more often with teams, without having their “manager hat” on, so that they can get unfiltered firsthand information of what the new way of working actually is like.

Start thinking agile

Just like there is no pill that turns a couch potato into an athlete, maintaining agility requires constant change and attention. With its undoubtedly huge suggestion catalog and massive training portfolio, SAFe may create an illusion that by following down this road, one becomes agile. In my perspective, by following all the suggestions of SAFe, one does become a SAFe organization – but this organization will not be agile unless people ask tough questions and challenge the assumptions of the framework.

An organization must learn to scrutinize everything it does, regardless of where the idea came from, and rigorously cut down on complexity wherever and whenever possible. This is the only way to avoid accumulating the same kind of “technical debt” in their structure and processes that a piece of un-refactored code would have. Constant, small changes of the structure must be as integral to the work as doing this to the product.

Maybe that topic would be called “Organizational refactoring”, … something to discuss in the future.