Defending SAFe®

August 16, 2013 — Posted by Al Shalloway

I am not going to get embroiled in the current diatribes that Ken and David have been throwing SAFe's way. But after being asked by so many people about it, I decided I should at least respond to any material charges made.  Turns out there weren't many. 

Ken's Blog

I copied Ken's blog UnSAFe at Any Speed, into Word and removed the diatribe, personal attacks and his explanations about Scrum that didn't relate to SAFe and got only the following statements of dissent:

  • They are now pushing the Scaled Agile Framework (e) as a simple, one-size fits all approach to the agile organization
  • They have made their approach even more complicated by partnering with Rally, a tools vendor.

That was it. Well, SAFe is not a simple, one-size fits all approach.  SAFe deals with a complicated problem and therefore does provide a complicated solution.  But, it's a framework that allows for tailoring as needed.  And, it turns out, the key objectives of SAFe are required by all companies:

  • work on the right things
  • limit how much work hits the development groups
  • organize from a portfolio, program, team level
  • have a high-level architectural view
  • handle cross-team dependencies
  • integrate on a cadence
  • attend to code quality
  • more ...

SAFe acknowledges that large scale Agile development requires a core set of practices and perspectives.

Regarding partnering with a tool vendor, Rally is one of many Scaled Agile Partners.  Net Objectives is another. At scale one needs tools.  Rally is only one of many tools you can use. Ken seems to forget his former/current partnering with tool vendors as well, so I'm not sure what the point is here.

David's Blog

I did the same with David's blog Kanban - the anti-SAFe for almost a decade and got this:

SAFe - a collection of proven techniques (including kanban systems)

SAFe appears to collect together a number of techniques from software development processes from the 1990s and 2000s. It offers these as one large framework. Individually, these techniques are considered successful and there are positive case studies showing their adoption and benefits. It is assumed that the collected set of successful practices will also be successful in aggregate.


Where SAFe really differs from Kanban and why I chose the title for this blog post, is in a combination of the delivery mechanism and the underlying assumptions about how to drive and manage change in knowledge work and creative industries. SAFe is delivered as a framework that must be tailored. Ideally you pay an expert or team of experts to do this. They design your solution from elements within SAFe and then they manage a transition initiative to "install" the process solution in your organization.

There is an underlying assumption that the consultant knows best and change is imposed from outside and its adoption is managed using a planned approach within a project framework.

And, I was glad to see that David at least acknowledged "To be honest, I don't know a great deal about SAFe"

Let's go through these two points - SAFe as a collection [from the 1990s and 2000s.  Since Scrum was created in the mid-90s and since that is a part of SAFe, that backdating is true.  However, SAFe is actually driven by Don Reinertsen's The Principles of Product Development Flow. I've taken both David's and Don's class and I can tell you that Dean talked more about Don in the first 2 hours than David did in his entire course.

It also is not "assumed that the collected set of successful practices will also be successful in aggregate."    Instead, SAFe is a holistic view of things.  The aggregate has been accomplished by looking at the big picture and then finding what fits into them, not starting with things and glomming them together as David is suggesting.

The assumption about needing consultants to drive change from the outside is just 180 degrees opposite of what is so.  The entire Scaled Program Consultant program is set up so companies can have internal consultants use SAFe.  This is a dramatic break from past certifying bodies that have limited the number of folks who can provide training and consulting and who often require adherence to some particular mindset.  I can state unequivocally that Dean has encouraged my opinions and extensions to SAFe.


I find it interesting that neither Ken nor David asked someone like myself - "why do you support SAFe?"  I have always liked Stephen Covey's maxim - first seek to understand then seek to be understood.  If they had asked, I would have responded something like I did in my blog Why Net Objectives Supports the Scaled Agile Framework (SAFe).

I have been an early proponent of XP, Scrum, Lean, Kanban and the Kanban Method.  I use all of these where appropriate.  I support SAFe even though we've had our own method for achieving Agility at scale because I find SAFe to be well ahead of everything else out there - definitely not a collection of old ideas.

If you have questions about SAFe, its value or its dangers please send me a question. Happy to help.

Al Shalloway
CEO, Net Objectives

Note: For more information, watch the webinar Understanding the Scaled Agile Framework which explains how SAFe follows Lean principles.







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.


To be forthcoming, I just deleted a comment re this blog. The reason is that it was a personal attack on me and did not discuss any issues.  I look forward to conversations about the issues, not personalities.  Personal attacks have no place in this industry.

We're using SAFe pretty effectively at a program level. We have two release trains going right now, without much overlap. However, there are some teams that participate in both trains. This works out okay - they just reserve a % of their capacity for each train, plus some reserve for the unexpected. It's not ideal, and it's probably a sign that we still haven't organized our teams quite right (we still have a tendency to form component teams, not cross-functional product teams).

Anyway, my real comment was that after reading "Lean from the Trenches" (Kniberg), I got to thinking about SAFe and wishing that we could operate more like Kniberg's process. My summary of that process is a program level Kanban flow of features, with feature teams using Scrum to execute (with team ownership of a feature).

The truth is that, even if we had total commitment from leadership to that style of process, we are years away from the capability. We have around 20 Scrum teams, and 13 years of legacy apps with messy dependencies. We're trying hard to shore up our architecture and reduce dependencies, but we're not there yet. It's extremely difficult to form "feature teams" that can change any component needed for a feature. So, all in all, SAFe's release planning approach tends to fit us better than the continuous feature flow of enterprise Kanban. (Not that Kanban prevents enterprise planning...)

My goal is to try to shape our SAFe implementation to slowly shift away from fixed PSIs towards a focus on the flow of prioritized features. I don't know if I'll succeed, but the model appeals to me. I really don't think it's practical unless you can create true end-to-end "feature teams"...

Todd:Thanks for the insights. I agree with your intentions.  People often mis-interpret SAFe as an endpoint.  It isn't. It's a framework to get folks started.  Once you've got folks aligned, you can make a lot of improvement. Th initial start of SAFe is typically a 'quickstart'.  Not a 'quick end'.  So, as you are saying, see where you are then adjust and improve.  I tend to think of SAFe as the scaffolding that's necessary for flow.  It solves many problems large organizations have coordinating lots of Scrum teams.  But, flow is really the name of the game.

I believe those who will be successful with SAFe will be those that drive it from a Lean perspective using Kanban at different levels as needed. As you solve the dependencies problem (which is a code quality issue) you'll have much more flexibility in scheduling.

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