What Is It That Can Make SAFe® Heavy?

September 27, 2014 — Posted by Al Shalloway

Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe 

Many of the detractors of SAFe say it is heavy. But it is only heavy if it is more than is needed. For example, prior to 3.0, SAFe had a Hardening, Innovation and Planning Sprint.  People would say "hardening" (i.e., when you just work on bugs) is not an Agile concept.  I would say, "when you need it, it is."  In other words, SAFe wasn't prescribing hardening, but if you needed to do it, do it. And, continuously improve your process so you don't need to.  

Many companies jumping to SAFe are not Agile prior to the jump.  They lack automated testing, continuous integration and other practices that need to happen.  Pragmatism dictates that one doesn't just assume one is Agile.  Pragmatism dictates you do what you need to do while you become Agile.  Attacking SAFe for recognizing this is silly.

Instead of just laying the claim that SAFe is heavy, let’s start by considering what it means to have a heavy process. Bureaucracy clearly comes to mind. But SAFe is not bureaucratic.  Every SAFe practice has a meaningful purpose. SAFe is based on Lean and explicitly discusses the removal of delay and managing WIP which causes waste.  So, if SAFe is heavy, it has to contain practices other than bureaucracy.

I would suggest that being heavy is relative.  That an overweight process is overweight if it calls for more than is needed.  Most of the slurs that have been directed at SAFe have been unfounded because they assumed that people would do something uncalled for.  My own experience with Dean Leffingwell and all of the SAI trainers I have met is that they are very pragmatic and don’t believe in doing anything that is wasteful.

So I had to ask myself the question – “when is a framework or process overly heavy?”  Here are some of the answers I came up with:

  • Batches of work are too large
  • Phased development with one group handing off their work to another
  • Delays injected into system as a result of the framework/process
  • Planning via push
  • Separates test from development
  • Planning that:
    • Makes decisions before they need to be made
    • Takes the attitude of elaborating on dependencies instead of trying to eliminate them
    • Has commitments for teams made by management not the teams
    • Assumes teams can build independently of each other and then integrate at the end with no challenges
    • Plans further out than needed
    • Requires more detail than needed

Regarding SAFe, these items fall into one of three categories:

  1. SAFe doesn't call for it (e.g., separates test from development)
  2. SAFe may have you do it if you follow SAFe's practices regardless of your situation (always plan out 8-12 weeks when your train is small and doesn't require that much planning)
  3. The non-Agile practice may result if you improperly use SAFe (SAFe can become a push model in the same way Scrum often does)

The point isn't whether SAFe can become too heavy, most anything can. The point is how do you stop it from becoming heavy. Because SAFe is explicitly based on Lean principles, one can avoid SAFe being heavier than it needs to be.  Of course, this requires understanding Lean.  Admittedly, I think few people promoting SAFe do understand Lean well enough.   But I would not call that a challenge with SAFe or a misdeed of the SAI (Scaled Agile Inc).  SAI has done more lean training than virtually all of the other agile trainers put together in just a couple of years.

Where I have seen SAFe misapplied is with large organizations whose trains were small. High maintenance organizations are often like this in that you have lots of little things going on scattered across lots of people. But even here, SAFe provides value by creating the bigger picture of what to work on.  If one lightens up SAFe planning event here, one can coordinate teams with cadence and synchronization but not over plan.  I remember a favorite line by Dr Dan which is very appropriate here - "you don't have to be stupid."  As a CST I respect, he would dismiss arguments against Scrum when people were doing idiotic things with it in the name of it. I would suggest you could say the same about SAFe.

The biggest argument against SAFe I can see is that it can be readily abused because a lot of money is involved in large organizations.  This is certainly true.  Then one should attack the misapplication of SAFe.  As a long time Agilist (16+ years) I have worked with many promoters of Agile and Lean approaches relating to XP, Scrum, Lean and Kanban. Of the many organizations I have been in, I can certify that the SAFe community is easily the most open for improvement and new ideas. In the long run, that's one of the most important aspect of any approach.

Please discuss these on the Lean Systems Society Discussion Group.

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.


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