Speaking on SAFe: Thoughts from my Leading Scaled Agile Framework course

By | 2014-07-14T09:22:29+00:00 July 14th, 2014|Process|3 Comments

It isn’t exactly agile, and it isn’t quite lean, but it is probably better than what you’re doing right now.

Over the last year or so, I’ve read and heard a lot about the Scaled Agile Framework, and I just finished taking the Leading SAFe course (SAFe Agilist certification pending) from Al Shalloway, CEO of Net Objectives. I was very lucky to be able to take this course from an industry leader in this space who has been a part of multiple SAFe adoptions, not just someone who’d been through the requisite training but had no hands-on experience. So a big thanks to Al for putting on a great course! After gaining a pretty solid understanding of SAFe, I think it is time to throw my own 2 cents into the ring.

Let’s start with a disclaimer: I’ve never implemented SAFe, or consulted with a company that has. I have however been a part of multiple agile adoptions at enterprise scale, and trained hundreds of students on lean, agile, Scrum, Kanban and other topics. So take the below with a grain of salt, and if you see any errors I’d love to hear from you in the comments.

The Scaled Agile Framework isn’t really anything new. At its core it is attempting to put structure around the Epic => Feature => Story flow that already exists in some shape or form in most large organizations. The patterns and practices it promotes have mostly been around for a few decades now; where it really adds to the conversation is the structured application of a particular set of agile-ish and lean-ish practices into a semi-coherent whole. Most consultants talk about an agile-toolbox – SAFe empties that toolbox into a single piece of graphic art:

Scaled Agile Framework Big Picture

In a moment I’ll go through what I like and dislike about SAFe, but I’d like to take a moment to emphasize what is for me it’s #1 selling point: the Scaled Agile Framework is about managing the flow of value through a system. Whether the methods employed to achieve this aim are effective or ineffective at this point is almost arbitrary. If your organization can make the shift from managing utilization and local optimization to holistic system level thinking you’ve already won; the rest is just perseverance and adaption through experimentation. I think those of us who live and breath lean/agile sometimes forget this point and get caught up in the details.

I’d also like to express my joy that a major framework is finally attempting to adopt (and promote) Donald Reinertsen’s canonical work: The Principles of Product Development Flow. This work should be required reading for all managers, coaches and pretty much anyone else involved with product development. If you think you’re qualified to change any agile framework and you haven’t read this (or don’t understand it) you’re probably making the wrong choices. Ok, rant over!

The Good

Shalloway made an alteration to the recommended course, and I think I’ll follow his lead because I agree with it. So I’ll start at the Portfolio level. In SAFe, value is driven from the Portfolio level. This is a recognition of reality that irks agile purists. Large pieces of software consist of features sets that we build through user stories. And yes, user stories are individual units of value. However, a good piece of software has alignment and purpose. It is all to easy to lose that alignment when teams are adding small pieces of value without consideration of the whole. This path leads to feature bloat and Pareto-ification. Someone has to be ensuring that the pieces of value we’re adding to our software aren’t just intrinsically valuable in and of themselves, but contribute to the value of the system as a whole.

Which brings me to my next point, SAFe isn’t for everyone, and they seem to recognize this. Or at least Al Shalloway was very clear on this point; I’m dubious that the legion of budding SAFe certified consultants (SPCs) will continue to recognize this. If your product (or products) are simple enough that they can be effectively delivered by a single agile team, or are well-architected enough that a set of agile teams can build and maintain them with minimal dependencies on each other, you don’t need SAFe. The stark reality is however, that most existing software systems requiring 5+ agile teams to maintain aren’t architected this way and dependencies exist between the teams that need to be dealt with. This is where SAFe shines. (The obvious caveat to this is if you’re doing greenfield, don’t build a system that requires something SAFe-like to maintain…)

Speaking of architecture, SAFe takes a practical approach in this domain that is enormously refreshing. Yes, in a perfect world your architecture would evolve merely as a bi-product of the pieces of value that you were adding to the system. When major reworks were required, say as in migrating to a new language that worked on a supported operating system, they would be evaluated against other features based on business value and prioritized accordingly. Unfortunately, reality steps in and now you’re staring at all this VB6 code wondering where the world went wrong. You can spend the next ten years trying to force “the business” to understand the importance of migrating to a new code base, or you can do as SAFe suggest and build an architectural runway, allocate 20% or so of your development capacity to it and be done with it. Again, if you’re greenfield and building in the new hotness good for you, some of us don’t have that luxury.

A cross-functional organization structure is built into SAFe. You organize around, manage, and build value-streams through Agile Release Trains. In my class there was a group that represented the BI department of a major US company that kept asking questions on how SAFe applied in their environment that Al had some difficulties answering. Why? Because having a separate BI group is insane, and trying to fit it into a framework concerned primarily with value-streams just doesn’t make sense. SAFe, unfortunately mostly through implication, was highlighting a fundamental issue with their org structure; BI is part of the product, not a value-stream in and of itself (in this instance, there are probably caveats where it would make sense). Scrum drove the importance of cross-functionality at the team level, SAFe (and pretty much every consultant worth her salt in this industry) drives cross-functionality at the value stream level as well.

I really, really dislike the entire concept of a “software project.” In fact, I don’t believe there is a single more damaging paradigm the IT world has ever adopted. Which is why I’m quite happy to report the complete lack of “projects” in SAFe. You organize around, fund and incrementally deliver value to products. Why? Because unless you plan on abandoning your customers and going out of business, software development is about building products. They don’t magically end. The world doesn’t stand still because you’ve delivered your project. You must adapt continually as business needs evolve. There is almost never a one-off in our world. SAFe forces a funding model and organization structure that recognizes this fact.

Which brings me to planning products, and the PSI planning event. SAFe calls is a “Potentially Shippable Increment” planning event, but given their espoused philosophy of “build on cadence, release on demand” there is an inherent contradiction here (more on that in The Not So Good section below), so I’ll just refer to it as a PSI and ignore what it stands for. The idea: once a quarter you get everyone involved in the value stream into the same room, make them work on the same problems, and attempt to achieve alignment. This is so obviously a good idea, that it is hard to express exactly why. You talk. You find dependencies. You collectively commit to shared responsibility for the delivery of value. You “ra-ra” and team build. You make the decisions for the value-stream transparent. Bottom line – you become part of the value stream team.

One final point on the good side before we dive into the bad: SAFe embraces good development practices. Yep, you really need to do test first, continuous integration, and pair programming. You really do need to build an architecture based on managing future changes to the code-base. You really do need to build code that is simple to test. And yes, you really do need to automate portions of your test suite. If you thought you didn’t, sorry but you’re wrong.

The not-so-good

Let’s start with one of the big ones: there is an incredible amount of room for abuse in SAFe. The PSI cycle done naively could quickly devolve into short-cycle waterfall. The product management at the program level can easily usurp the power of the Product Owner role. Defined architectural hierarchy devolves into ivory-tower architecting. There are more, but I think you get the idea. The good/bad news is, this room for abuse doesn’t really have much to do with SAFe and everything to do with insufficient understanding of lean/agile principles. Any framework that attempts to resolve enterprise scale by managing the dependencies between teams, rather than explicitly removing them, will fall into this category. Unfortunately, reality implies the cost of removing these dependencies may not be worth the gain in agility. So we’re stuck with the potential for abuse.

Another significant hole in the Scaled Agile Framework is the under-utilization of kanban, especially at the program and team levels. Kanban is an incredibly powerful tool for managing flow through systems. Unfortunately SAFe only pays lip-service to its power with a half-baked implementation solely at the portfolio level. This is a significant oversight that should really be addressed. I’ve never heard a good argument for not using kanban to manage flow through any system with variability so I’m baffled at the seemingly intentional omission.

Next up, SAFe hardly mentions devops, and doesn’t really take into account the operational needs of a large product. Rather it is just kind of assumed that somehow environments are getting built and managed, the product is being monitored appropriately and someone somewhere is performing tech support. The regular maintenance type work that originates from this feedback loop is not addressed well either.

Ok, this next one might be a little semantic of me, but there is an inherent contradiction between “potentially shippable increment” and “build on cadence, deliver on demand.” This feels like a response to the early criticisms of SAFe that it stuck you into a quarterly release cycle, so they thought they would add a nice phrase into the training that sounded more agile. Look, either you’re building potentially shippable increments (of about a quarter in length), in which case you can release at most once a quarter. Or you can deliver on demand, in which case your code base is always potentially shippable. You can’t really do both.

Which brings me to my last point in this section, and it’s the big one. The potential for believing SAFe is the end and not the beginning. We see this a lot with organizations who say they are doing “Kanban”. They put up a board, put some stickies on it, add WIP limits that are high enough that they never reach them anyways, and poof! We’re AGILE! Sorry to burst everyone’s bubble, but there is no utopian land of agility you’ll one-day achieve where everything is unicorns and rainbows bathed in sparkling sunlight. This kind of thinking, while dangerous at the team level, is disastrous at the enterprise level. Good teams mitigate it by being honest with one-another, but organizations tend to built institutions that last for decades. If you adopt SAFe and three years from now you’re doing the exact same flavor of SAFe that you started out with, you’re doing it horribly, horribly wrong. As Al Shalloway put it: SAFe doesn’t mean you don’t have to think. Your process must evolve as your business evolves, or you will stagnate and die. Read Reinertsen. Keep learning. Keep thinking. Keep evolving.


First, let me just say that at some point we have to quit with the waterfall bashing. Seriously agile consultants, we waste an amazing amount of everyone’s time with it. Just stop. The point has been made, and better than you’re currently making it. Get to the meat.

Okay, so my bottom line: I wouldn’t recommend that you do the Scaled Agile Framework. But I might recommend you use something like SAFe as the starting point for your organization’s agile transformation. It doesn’t replace thinking and understanding lean/agile. But it does give you a place to start. When used appropriately, implemented intelligently, and viewed as a starting point, SAFe is a good tool for an organization beginning their agile journey.

About the Author:


  1. Ron Jeffries July 18, 2014 at 6:21 am

    Nice review, Andrew. Very accurate and fair, in my opinion.

  2. Felix Rüssel July 19, 2014 at 8:23 am

    Really like your article! I also keep saying to my customers that SAFe is just another step (or the beginning) and not the end of the journey. I see the benefits when it is done with the agile values in mind and I see the danger when it is used just to hide the status quo with some agile labels.

  3. Andrew Clear July 23, 2014 at 5:19 pm

    Thank you, and thank you for emphasizing that SAFe is just a step in the right direction, not a destination. We need more people carrying this torch!

Leave A Comment