How SAFe® Is More Leading Edge than Some Would Have You Believe

November 15, 2013 — Posted by Al Shalloway

I have been doing Scrum & XP for 13 years, Lean for 9, Kanban for 6 and SAFe (if you include our parallel version that predates SAFe) for 6. All methods/frameworks have challenges.  People have been taking easy potshots at SAFe, but here are some things it pays attention to several things that no other approach does.  Thought I'd list them here:

  • teams & managing WIP are important (Scrum stresses teams, Kanban Method stresses managing WIP)
  • the portfolio level drives the program level drives the team
  • shared backlogs, defined at the program level, is a powerful method to keep teams coordinated
  • quality code is important (thank goodness Scrum is coming back to this, but SAFe attends to it a lot more)
  • enterprise architecture is important
  • cadence across the enterprise is important
  • attend to cost of delay when deciding priorities
  • recognize that the structure within which people work has a significant impact on the quality of their work

There are probably more, but I'll leave it at this for now.

If you want to learn more - attend our free A Day of the Scaled Agile Framework.

Also, we have two courses on SAFe, one in Seattle and one in Atlanta.  Check them out on our public courses page.  And, of course, contact me if you want to bring one in onsite.

Al Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


An associate and friend (although we rarely see each other due to the pond in our way) is Toby Gyllebring, better known as drunkcod (shortened drunkcoder) on twitter. I have always loved Toby's perspective and insights.  He recently tweeted about this blog and said: "this isn't leading edge, this is taking what the community already knows to be true and putting it in a sellable box."

On reading that I realized, he is absolutely correct.  These ideas have been around for years.  I've been discussing them for years myself.  The challenge is that they haven't been adopted by the frameworks/methods that have been most successful in attracting clients. In my mind, that makes them leading edge. :)

Perhaps the viral nature of SAFe being discussed (what has been called great marketing when in fact there is virtually no marketing taking place outside of free educational webinars/seminars) is an indication of another issue, not relating to SAFe at all.


First, Al, thanks for those very kind words. Hope our paths cross soon again.

I think we, the community, has failed miserably at selling what we do and how it fits into a greater context. I'm still very much of the opinion that it's not a flaw in any method, framework or process that it doesn't encompass all the things that we might consider valuable, and at times, indispensable.

I've tried to formulate the idea a few times (causing much heat in the process) that small methods, with clear boundaries are to me, more valuable than big monolithic frameworks. This means clearly communicating both applicability and equally giving suggestions what other things to plug into it.

Early Scrum literature actually did this well, clearly marking some problems, like how to actually be a PO, as "good methods exists for this, you go find them", this message somehow didn't make it into the training materials.

So I *want* my methods to be incomplete, that keeps them focused and reusable. As a practitioner that's very valuable, to me. But it does give raise the problem of outsiders, and those less inclined to spend much time on research, not knowing how and what to piece together in order to get something that actually works.

There we've failed. And there I can see how SAFe can, in some circumstances help a lot of people.

There is an effort underway to describe Scrum in terms of the small composable patterns that make it up. Scrum, as documented in the Scrum Guide, is a snapshot in time of an evolving pattern-language. Using the Alexandrian approach to talking about organizational methods is useful because it is based on the idea that "big" frameworks are just one pathway through a language of smaller patterns. And pattern languages are never done, they are always in a state of growth/repair.

Have a look if you haven't already:

Evan Leonard

Thanks for the reference.

While I commend the attempt at patterns being done at, they are definitely not Alexandrian in nature.  Alexandrian patterns require a context in which they are useful.  Also, Alexander emphasizes that the patterns aren't really important, rather it is what they have made visible (see my article - Can Patterns Be Harmful).   On page 545 of his 549 page book - Timeless Way of Building, Alexander says:

At this final stage, the patterns are no longer important:
the patterns have taught you to be receptive to what is real

In this context, it means, the definition of Scrum is not important. What is important is what is real - Lean product development flow, managing WIP, incremental learning, avoiding delays in workflow and delays in feedback.  Scrum is an instance of how to do that.  It is not the essence of how to do that.  While I believe Scrum is a very powerful team approach, it is not effective in all contexts.  This has been demonstrated in many different areas. 

Unfortunately, few (any?) Scrum thought leaders, or I should say, those who are responsible for defining Scrum, ever acknowledge that there is a context in which Scrum will not succeed. 

Alexandrian patterns need to:

  • specify the context in which they are applicable
  • indicate the forces underneath the patterns that the patterns are resolving

There has been a long history in the Scrum community of resisting explaining Scrum in terms of Lean.  So, this hasn't been done too much either. For information on that, see my blog Cross Functional Teams Elmiante Waste and Manifest Lean.  In my opinion, it is Scrum's manifestation of Lean product development flow more than Scrum's focus on self-organization that explains why Scrum works at the team level.

In any event, describing Scrum as a series of patterns of activity is good.  But it is not the creation of patterns based on resolving forces - the essence of Alexandrian patterns.


Toby, thanks for the insights. I believe you may have nailed a critical insight. We need frameworks that are truly frameworks and then well defined methods within them. Frameworks need defined scope (e.g., Scrum is for the team) and methods have specific contexts in which it works.

SAFe is a combination of both framework and methods embedded into it. It is this combination that I like, but admit I haven't made this distinction explicit. That looks like a good thing for the future.

As far as completeness goes, i agree methods shouldn't be complete.  But perhaps we disagree on the scope of our bigger framework within which we work. I like to know the different things I need to work with.  I don't need to have it all figured out, but I need to be aware of those things that will prove useful even if I don't know how to do them.  That is, i should know what I don't know.  The alternative is having a challenge and being blind to it.

In this way I want a mindset/framework that provides me with potential solutions that I can use when the situation calls for it, assuming I know them, or learn them when they do. 

Probably a lot more thinking needed here but a nice distinction - framework with methods.  Frameworks need to acknowledge when their scope is limited and which methods pretty much always be in them.  Methods need to recognize that they will only work best in particular contexts.

Al Shalloway

In the alexandrian form each pattern begins with a starting context to make clear where it applies, and ends with a resulting context to make clear where it leaves off (and leaves open which patterns might apply next).

Evan Leonard

I do not consider SAFe to be a patterns language, nor even a collection of patterns.  However, I do agree that creating such a language would be useful.  In fact, I am working on this with the Lean-Agile project.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban