Why not SAFe?

So let me get this out right away: I’m a SAFe proponent. But hang on – it doesn’t make me a “pure-Agile” non-supporter.

I have my PSM certification from scrum.org and my SPC certification from Scaled Agile Academy, so I feel comfortable enough to comment on the discussion. The discussion is not as intense as it was a few weeks ago, but I sense that the residual effect is for some to bypass SAFe as even an option to consider.

It’s too bad that what would otherwise be a healthy discussion surrounding SAFe and “pure Agile” is causing division. Peer review and feedback is the best way to ruthlessly drive things forward and evolve, but if we allow discussion to degrade into both (or one) sides digging their heels in and simply trying to convince the rest of the world that their approach is best instead of understanding each other and move forward, the value of discourse quickly dissipates.

On this front, Dean and SAFe scores the point: every time I heard Dean speak about SAFe, he has been very clear that there is a lot to be gained from being pragmatic and tolerant of other’s views. Rather than taking a polarizing “my-way-or-the-highway” stance, the creators of SAFe already has an advantage here that will work in their favor in the long run.

So what is it about SAFe that makes it worth the investment, that other Agile approaches haven’t covered well enough yet? In my view…

SAFe addresses the people not on the Agile team.

This insight by itself should be enough to pique your interest. Most Lean/Agile material I’ve seen focuses on how to implement Agile methodologies, but very little attention is paid to the stakeholders outside the team. Yes I know, there are exceptions out there, but generally I feel that we don’t pay enough attention to the folks outside the immediate development team.

SAFe addresses these stakeholders as first-class citizens, not as impediments to progress that have to be “turned around”. That’s a smart thing. Those “impediments” often sign your paycheck, and if they are not comfortable with what’s happening, your Agile Adventure will be short-lived or at least very limited in reach. Let’s invite them to contribute in a format they can relate to and be effective in.

SAFe has the right ingredients and building blocks

  • Lean principles as the leadership backdrop
  • Scrum as the proven team-level project management framework
  • XP-inspired coding practices
  • Don Reinertsen’s Principles of Product Development Flow

You may have a different set of favorites, but when I saw the above 4 ingredients in the same recipe, I definitely paid attention. Ever since I read and re-read Don’s book I’ve been on the lookout for applications of this really wonderful and clarifying set of ideas.

SAFe is for large programs.

The “S” in SAFe stands for “Scaled” – a point which I feel is lost in some of the SAFe critics. I have spent all my working life in large organizations in both software development and project/program management roles, and I can confidently say that if you want to manage anything at a scale beyond a handful of people you will need some sort of framework to keep everything aligned. Simply relying on a shared set of values and a common goal isn’t enough. Multiple teams simply won’t self-organize in a single direction. It doesn’t matter whether you are doing Agile or not – large groups of people working together is going to require alignment and guidance to enable some sort of orchestrated delivery.  As Reinertsen points out: “there is more to be achieved from overall alignment than local optimization”.

Statistically we will have some success-stories where overall alignment happens in an organic manner, but don’t count on it for your project. You N. N. Taleb fans out there know what I mean.

SAFe pulls it all together and communicates a holistic view

Again, selling Lean/Agile to folks outside the Agile teams is where you either achieve an Agile enterprise transformation, or you don’t. You don’t have to “sell” Agile to the teams themselves, they are usually the ones that get onboard first. If you want to scale Agile to the enterprise-level, you have to sell the idea to those that have the most influence.

The value of having a single-page graphic which acknowledges the various roles and the main flow of events can’t be overstated. Here, for the first time, we have a map of the world in which everyone in the existing organization can see a place for themselves in an Agile setup, post-transformation. That immediately defuses a lot of the potential friction and apprehension associated with introducing Agile to the C-level office and the middle management layer. You know, the ones who decide what you can’t and can’t do in the enterprise. Kind of important to get those folks on your side. Showing the full context of an Agile Release Train is definitely much easier than selling the idea of “Agile self-organizing” teams.

SAFe may not be for you

…and that’s ok.

If you’re starting out and introducing Agile to a small organization, you don’t need or want SAFe. If you’re working with a small set of teams, it’s probably not for you. That’s ok – SAFe starts to make sense at scale. Keep that in mind as you grow.

SAFe is not a one-size-fits-all solution. Neither would you want one. Personally I just need a model that fits my situation and environment. Most of us work in one company, and in one environment. Chances are slim that we will need a large-scale Agile solution one day and a small-team solution the next. If SAFe works for what I need to do, then that is fine. If not, then move on and find something else. But please don’t make it your mission to convince others (who you don’t even know) that some approach or other is not an option for them. SAFe is indeed an option, and so is “pure Agile” and any other variant such as DAD, but only you can decide which one is right for you.

Use SAFe (or any other model) responsibly

A lot of the SAFe criticism I’ve seen seems to assume that our teams don’t think for themselves, but rather assumes SAFe would be adopted blindly and without real-world context.

Isn’t that anti-Agile? Thinking people can understand when to apply the mechanisms offered by SAFe and when to do something else. Not all aspects of SAFe will work for you, but it would be a shame to throw out 100% of the model just because there is 10% that doesn’t work for you. Use the parts that are helpful to you, discard the rest (for now). Whatever defined approach you choose, you’ll need to tune it to your particular situation anyway. I think Dean and the SAFe crew would agree.

…which brings me to the point of this blog post

Although a polarizing discussion is entertaining and can provoke some great insights, at some point we reach diminishing returns, and instead of improving we alienate. It would be too bad if this argument causes some folks to bypass the good work done by the SAFe team. SAFe can provide a huge head-start for some companies, especially those who need to visualize a pathway out of the waterfall.

If you are rejecting SAFe on the basis of comments made by some Agile rock-stars, pause for a moment and put it all in context. What alternatives are they suggesting? In most companies, it’s not enough to simply rely on self-organization around a shared goal and scrum-of-scrums. At some point at scale you will eventually need some sort of framework and holistic planning involving the rest of the enterprise, whether it’s called SAFe or not.

If you are embracing SAFe because it looks less threatening to your existing organization and an easy fix, you should probably take a step back and ask yourself if you really understand what Lean/Agile is about. Your organization will likely have to change its ways, and it can be a difficult transformation.

Ultimately, I don’t see that SAFe competes for territory with pure Agile/Scrum but rather complements our current practices to enable larger-scale Agile projects. There is a big world out there that largely still hasn’t transitioned to Agile, and the sandbox is big enough for everyone to play. Let’s move Agile adoption forward in any way we can, even if it doesn’t fit a purist’s view of what Scrum should be.

If SAFe brings Lean/Scrum/Agile within reach for companies that would otherwise not even entertain the idea, how can that be a bad thing?