A framework is only heavy if it prescribes more than what is needed to get the most value for the effort expended. While SAFe can be used in an overly-heavy way, that is not the intent nor the best practice. This article discusses what in SAFe is definitely needed and what may be optional based on.

Main Points

• There are circumstances under which a framework can become too heavy.
• There are signs that indicate SAFe is becoming “heavy.”
• You can to minimize the risk of being too heavy.

“Heavy” Means “Beyond What’s Beneficial”

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.

Signs a Framework Has Become Too Heavy

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

How the Signs of Heaviness Relate To SAFe

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

1. SAFe doesn’t call for it (e.g., separate 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)

How to Avoid Committing “Heavy SAFe”

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.

Summary

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 aspects of any approach.