Let’s Acknowledge SAFe For What It Is… And Move On

WRITTEN BY Mike Cottmeyer

It seems this week more SAFe related stuff than usual made it across my desk… some positive, some negative… some old, some new… but all asking the same fundamental questions. Is SAFe the savior of all things software development? Is SAFe really agile or merely the second coming of RUP? Will SAFe survive or be relegated to the ever growing list of failed approaches that have come and gone over the past 30 years.

Here is my take… it doesn’t matter.

Agile as it was defined 14 years ago is basically a lightweight framework for building software. Agile is predicated on the notion of small teams, colocation, onsite customers, lightweight documentation and frequent opportunities for feedback. These teams need to be sufficient for solving the problem they are formed to solve, they need to have clear backlog, and they need to be able to produce a working tested increment on some predetermined interval.

If you go one level deeper, agile teams need to work within a code base that is well architected, wrapped in tests, and safe to make changes. That code base needs to be supported by a team with autonomy to decide how best to solve the problems they are formed to solve. That team needs to be tightly aligned with the business objectives of the organization they are formed to support. They must have some degree of independence from the rest of the organization.

Let’s be clear…most organizations can’t form teams like this.

Most organizations have tightly coupled, non-autonomous teams….

Most organizations have poor alignment to the business…

Most organizations don’t have good tests…

Most code bases are not safe to make changes….

Most organizations are staffed as matrixes…

Should I go on?

So here is the deal. You either create the conditions to do agile well… agile as it was defined 14 years ago… or you do something else. SAFe is that something else. SAFe is a mechanism for wrapping the complexity of organizations that won’t reduce that complexity. SAFe encapsulates a larger, more enterprise focused value stream, a value stream that really does exist in most large organizations and can’t be ignored.

So… I want to say this one more time for emphasis… either you create the conditions to do agile well… or you do something else. SAFe is that something else.

We can say that SAFe is a cop out… or isn’t really agile… or that it’s the second coming of RUP… but don’t underestimate the complexity, the risk, or the cost of totally refactoring an enterprise to be the kind of organization that can really do agile at any kind of scale. Some organizations simply can’t or won’t invest in this. At the end of the day small batches are better than big batches. Iterative and incremental is better than waterfall, even if it isn’t agile.

I personally don’t think that SAFe is bad… or that SAFe undermines what we are trying to do with agile in the larger scheme of things… I do believe that SAFe will be better for some companies, some of the time. SAFe isn’t the way that I’ve chosen to tackle the enterprise problem. I want to work with companies that do want to fundamentally decouple themselves and have a shot at doing agile as it was originally envisioned…

But I’m pragmatic enough to know that can be a long road.

So… where does that leave us?

I think we should acknowledge SAFe for what it is and move on. Like I said, SAFe will work better for some companies, some of the time. It will be better than waterfall. I think it will be better than RUP as commonly practiced. I think it will be better than trying to do agile in companies that aren’t willing to create the conditions to do agile well. There will be some of us for which SAFe won’t be good enough, but that is okay too. SAFe will be better for lots of folks.

It all depends on what you value. Ron Jeffries said one time… ‘how good do you want to be, and how fast do you want to get there’?

Even though we don’t teach SAFe at LeadingAgile, I think for some SAFe can be a valid part of the journey toward greater agility… it might not get everyone as agile as we’d like them to be… but that’s probably okay too.

leave a comment

Leave a comment

Your email address will not be published. Required fields are marked *

19 comments on “Let’s Acknowledge SAFe For What It Is… And Move On”

  1. Steve Colasinski

    Our company is in the process of trying to adopt SAFe. I was not part of that decision but was asked to come along for the ride. Surprisingly, the team is still trying to define an internal process based on SAFe with part time resources. That effort is going very slow. Outcome at this time is unpredictable. It appears that the company was looking for an in depth structure to follow.

  2. Declan Whelan

    Great post Mike. I think your pragmatism is right on the mark. I see SAFe as helping many organizations although I would not choose it for my own :).

  3. Paul Boos

    Great post, I’d add that few people seem to explore the issues and even more importantly the assumptions frameworks like SAFe are based on…

    At the last ACCUS I facilitated a session on this topic with interesting results. We didn’t try to bash SAFe, but rather understand more of the underpinnings it rests on in order to determine if it applies. You can see the results here: session here: http://paulmboos.com/2014/10/05/acc-us-session-how-to-practice-agile-scaling-wo-a-condom-un-safe-agility/

  4. Cherie

    Your post makes me proud. Lets just do the right thing for who we are and where we are right now and keep our eyes on continuous improvement.

  5. Derek Neighbors

    SAFe is a path to mediocrity. Most large organizations are okay with mediocrity because they have enough cash to think it doesn’t matter. Until it does. The best reasons are the worst excuses.

    If you are involved with an organization that wants to implement SAFe and you want to be anything more than mediocre run like hell.

    • Mike Cottmeyer

      Hey Derek, thanks for the comment. What do you do if a company is willing to make the changes required to do agile well, but is in a large complex systems architecture, doesn’t have the right alignment, doesn’t have good tests, etc.? Could SAFe be a viable intermediate state while they get their problems worked out? I’m not a SAFe apologist, and like I said, it’s not my desired end state and inclined to agree with your comment…. That said, can SAFe have any place at all in a transitioning organization?

      • Viktor Grgic

        Hi Mike, There are much better “intermediate states”. I like your article very much, except that conclusion is a false dichotomy. There are many examples of traditional companies gradually becoming truly Agile with only Scrum. E.g. Large Scale Scrum (LeSS – http://less.works) helps further with many typical issues in such endeavour. So, there a better ways to deal with complex and large enterprises, although none of them promises a fast solution, since there isn’t one.

        • Mike Cottmeyer

          The only thing I would change in the blog post Viktor is where I said “SAFe is that intermediate state”. I wish I would have said “an” intermediate state or something like that. I still think the point of the post is valid. If you are using Scrum only, then the conditions to do agile well existed. Same goes for LeSS. If you are in transition and shooting toward those end states, then you have an organization that is creating the conditions for success, they are willing the make the investment. If you get stuck on SAFe as the intermediate state, by definition you are in a company that does not have the right conditions and isn’t willing to invest to create them.

      • Derek Neighbors

        I think SAFe could potentially be an transition step. However, I have yet to meet an organization that has successfully used it as that. Most of them see it as a destination not a journey.

  6. Kurt Jaeger

    I am happy with that post, because it build pragmatic bridges. SAFe fits good for customers we talk with, like Deutsche Bahn, compuGroup Medical , aMADEUS, So even big enterprises are able to make wins out of agile and lean as John P. Kotter predict in his book and video XLR8 see also https://www.youtube.com/watch?v=Pc7EVXnF2aI

  7. Martin van Langen

    Well written. I experienced this also in my last two assignments. They feel it’s a shortcut to agility without taking the pain.

  8. James

    I think SAFe points to an important topic that was understated in agile: requirements engineering.

    Extreme programming drove our attention towards quality practices such as test-driven-development, continuous integration, pair programming, etc.

    Scrum placed the emphasis on project management with practices such as intensive planning meetings, regular review cycles, reporting with burn-down charts, etc.

    What about user needs and requirements management? Will SAFe teach us the value of well analyzed and defined requirements? How will it integrate with other requirements engineering practices such as behavior-driven-development or specification-by-example?

    How will tools such as FitNesse (http://fitnesse.org) and Concordion (http://concordion.org) support agile teams to specify collaboratively?

  9. Rick Vance

    I like this post. Very pragmatic in the challenges around SAFe. I believe that if we had agile teams, (co-located, autonomous teams who are using good technical practices) then we probably wouldn’t need SAFe. Good program management would probably suffice. Trying to implement the framework without agile teams will probably have little benefit. SAFe makes the assumption that we have agile teams… it’s the foundation that the whole framework is built on….. or just maybe, we can use the framework to sell the need for creating agile teams :-)

  10. Luke Majewski

    Although I agree with the premise that SAFe does not provide a magic bullet, I find it amusing when people talk about doing “agile really well and focusing on co-located, autonomous teams exercising good engineering practices”. If that worldview gives you coordination across 40 teams on the same value stream then that’s great. Agile is not a set of methodologies – it’s a set of principles. In my experience many principles begin to break down at scale. Whether it is SAFe or something else, it it too head in the clouds to just say otherwise. Every scaling effort requires additional coordination – SAFe is just one implementation. When Ken destroyed SAFe in his blog I noticed it wasn’t long after that he came up with his own scaling paradigm. I’m sure it sticks 100% to all elements of the manifesto.

  11. Dennis Elenburg

    I’m a newly certified SA, so maybe I need more experience so see SAFe through a non-agile lens, but I view SAFe as being highly dependent on good agile practice, Scrum in particular, at the team level. I work with large banking and telecom customers who span the spectrum from traditional waterfall to thinking they are agile (and not) to being highly sophisticated in their agile practices. The organizations that cannot do agile well at the team level struggle mightily in trying to use SAFe. The teams that are disciplined in team level agile, tend to excel with SAFe. That’s been my experience.

  12. Martin Burns

    Mike, this is a very worthwhile attempt to see the world from a different perspective, and to understand how the world works when you are at a very different starting point.

    You’re right: SAFe is most effective where the Entire Product Organisation cannot simply be <10 people in a single room who can define all practises in a greenfield. And that's reality for many, many software-intensive products.

    But I think there's a whole range of organisations where your criteria may be possible, but not today. The starting point is elsewhere, but with work, perhaps they can get there. Or at least: a hell of a lot closer than they are today.

    Is SAFe used as a destination? Yes, in some organisations. If they have half-way effective coaches, by the time they arrive there, they will see that as no more than a staging post, even if it's taken 5 years to get there.

    SAFe is highly effective (for example) at turning highly coupled delivery systems with little business alignment into strongly business aligned, loosely coupled "team of teams" systems. At teaching managers and executives to let go of control. At preaching engineering excellence practises to stakeholders who would have dismissed them previously.

    You perfectly have the right to define that as 'Not Agile' however, I don't agree. I very much prefer Dan North's idea of Agility as a Centred Community, not a Bounded one. One where you are constantly 'heading towards'. To my thinking, the most important words in the Manifesto are about "uncovering better ways by doing and helping others" – which has to be a contextual question.

    So is SAFe Agile, or Something Else? Well, it depends on where you start. Just like the Couch to 5k programme: is that endurance training? For a fatty like me, yes. To an existing marathon runner, not really.

    So the question is: given the constraints you very effectively identified as starting conditions, what would you do first to reduce them and progress towards the ideal?

  13. Sven Thiergen

    Just had my first look at SAFe and now it’s 2017. This article was written in 2105 and SAFe may have been (a bit) different then so apologies if I miss on some points …

    I think the article is right about that lot of companies can’t change enough to allow true agility. Which is why agile teams disfunction to some smaller or larger degree and you come to the point asking yourself “does it really make sense to do agile here or should we look for something else”?

    “Something else” with less potential than Agile but fitting better thus getting better results in the end.

    So far so good, but SAFe really isn’t just another “something else”. Definitely not defending SAFe here, but pointing out an important difference … SAFe is based upon true agility!

    In SAFe there is everything you know from traditional Agile: Scrum Masters, Product Owners, Scrum Teams, even Scrum itself (or Kanban). Plannings, Demos, Retros etc.

    SAFe in fact adds (at least) one additional organizational layer by introducing the team-of-team idea. Put simply, a bunch of scrum teams with 50-125 developers working on the same product with a common product backlog.

    With additional roles that operate on the multiple team level like UX designers, architects or a Scrum master who acts as the “chief scrum master” for the team scrum masters.

    Whether SAFe is good or bad in that is another discussion. I think most of their ideas are reasonable; I used to work for a company with this exact scenario and we applied many SAFe ideas just without calling it like this.

    So that’s why I disagree with the statement “if you cannot do real Agile you need to do something else; SAFe just is another of this something else”.

    SAFe e.g. does not seem to make any sense at all if you don’t have at least 20-30 people working on the same product. And this is the case for a lot of companies which struggle with Agile nonetheless and need “something else”.

  14. Steve VanArsdale

    Thanks, again, Mike. After two years, in 2017, this is still a relevant and articulate opinion on SAFe and all other approaches for Agile on a large scale. Growing agile practices to the size of the organization is an effort worthy of a defined process. The quote from Ron Jefferies is a focal point.
    IMO: This is a scaffolding for the art of Agile, a three-dimensional framework, that allows / preserves / makes safe “bubbles” of agility in organizations that are dedicated to the systematic, predictable, and reliable supplying of people, materials, and capital to we enthusiasts… safely ensconced in our bubbles of agile development. For my money and career, a scaled agile framework is more than acceptable to Make Good, as fast as I can get there.