Having issues with SAFe? Considering DA? Tell us about it…

In our travels working with clients around the world we have run into many companies that have tried SAFe but are now struggling and looking for alternatives.  Last week we learned about a large bank that is abandoning SAFe and has chosen the Disciplined Agile (DA) toolkit to replace it across the board.  They have already trained over 700 employees on DA and roughly half of them have become certified.  Given this and other similar accounts, Scott and I have been thinking that we should write a blog on common SAFe pains and how DA can help.  We are not advocating getting rid of SAFe altogether, as it makes sense in some situations.  However, it must be said that SAFe is a set of prescribed decisions as a pattern applicable primarily for tackling very large development initiatives.  While most large organizations have hundreds of initiatives, very few, if any need to be delivered as program increments in a large batch fashion. Indeed from what we see most of these companies have far more small to medium sized initiatives for which SAFe makes no sense.  DA, on the other hand, is an inclusive hybrid of methods and practices that can be used as an overall framework, applicable in all situations, for initiatives of all sizes due to its adaptability.  So it makes more sense to use DA as the toolkit, and apply the SAFe pattern if and when appropriate, not the other way around.  This was the rationale for this bank’s decision and we have seen similar made elsewhere.

We are asking for your help with our upcoming blog outlining why organizations are backing away from SAFe.  We know it is happening, but our knowledge is limited to our own experiences, our DA partners, as well as stories passed on by members of the DA Advisory Council.  Despite the marketing propaganda, case studies, and admittedly commanding market share, there is another side to this story.  We are asking for your insights regarding your experiences with your SAFe adoptions.

For thought starters, here are some observations about SAFe adoptions that we have made:

  • SAFe is expensive to implement
    • SAFe mandates that ALL team members be trained, using SAFe materials, by a certified instructor
    • Leading release trains is hard.  RTEs often come from consulting companies and are quite expensive.  Most companies don’t have the skills or experience to execute SAFe as specified resulting in huge consulting costs
    • Big room planning is very expensive and difficult from a logistics perspective, especially for distributed teams
    • The certification and partner programs are very expensive.  This cost is ultimately passed on to you the customer
    • For these reasons and others, we are seeing a lot of “SAFebut” out there, or “SAFe in name only” (SINO)
  • SAFe is risky to implement
    • Effective execution of a SAFe requires all teams in a release train to deliver reliably due to the dependencies between teams. Any team that falls “off the rails” jeopardizes the delivery of the program increment.  In our experience finding a set of teams that all deliver reliably is a rare thing.
  • Quarterly delivery of program increments is not very agile
    • Although the SAFe diagram refers to “release on demand” to support the lean enterprise movement, in reality we have not seen this in practice due to the work in progress and dependencies across teams. (Please let us know if you are seeing this actually happening as we may be missing it)
  • SAFe has a tremendous amount of process waste baked in
    • By our calculations there is 35%+ process waste built into planning and executing SAFe.  Despite its claim, SAFe is not very lean.
  • There is increasing backlash from the agile and lean community
    • We all know that a criteria for high performance teams is high morale and enthusiasm.  Many very skilled and experienced agilists feel that they are stuck in the SAFe “system”, due to a decision made by a C-level exec who liked the SAFe picture.  We are seeing people leave organizations for others that use a more lean approach to agile that allows them to truly leverage their agile skills.  This is a downward spiral as the best agile talent leaves SAFe shops, and often take their teams with them.

If you have seen situations where you or someone you know are struggling with SAFe, and would be willing to share your experiences, please comment here.  If you would like to discuss privately, you can reach out to me at mark [at] scottambler [dot] com.

Thanks in advance for helping us get a better feel for what is really going on.  We know that consultants love SAFe (wonder why?).  But how do customers really feel?

Mark & Scott

Have any Question or Comment?

4 comments on “Having issues with SAFe? Considering DA? Tell us about it…

Matt Everard

I was part of the leadership team of a global agile transformation that selected DA. I’ll be honest, at first many of us were disappointed at the choice. We didn’t know anything about DA, but it didn’t have the marketing shine of SAFe or the radical sexiness of Nexus. As I learned more about the core values behind DA, the pragmatic and flexible approach, it’s ability to incorporate a number of methodologies, and the focus on being enterprise aware, I became convinced that DA is really the best approach for large organizations. As Scott and Mark point out above, SAFe is good in some contexts, but if you have hundreds (or thousands) of teams across the globe, SAFe becomes all the things listed above – expensive, risky, not very agile or lean, and engenders legitimate complaints from truly agile teams who have broken their backs to create a CI/CD pipeline within the beast.

I will add one more observation: the organizational antibodies tend to reject the prescriptive nature of SAFe. If you tell a CIO with a large portfolio that all her teams have to go SAFe, you will see many pockets of resistance. With DA you can empower your teams to choose the way that works best for them.

Michael Kogan

Talking about scaling, SAFe’s PI planning seems very compelling as it brings together everyone involved in the execution. This is akin to an iteration planning meeting where everybody involved in the execution is in the same room. DA, on the other hand, advocates for only the teams’ representatives (a.k.a. the Leadership team) to be involved in a scaled planning. This can result in miscommunication which is so dangerous to execution.
Having said that, the drawbacks of SAFe’s PI planning, mentioned above, are considerable.
I think one should use common sense and take the best of both worlds, adjusted to context.


Michael, you seem to have a misunderstanding about DA. If you read a bit deeper you’d find that we suggest a range of choices. Several of the choices that the framework covers are based on strategies from Agile Modeling. For example, we’re pretty clear (I think) about the value in getting people together physically for modeling and planning sessions. We’re also very clear about strategies such as Active Stakeholder Participation (where stakeholders are not only present but are actively involved with the modeling/planning effort) being more effective than representative-based (e.g. a PO or BA) participation. In fact, AM was describing strategies such a “big room planning”, we called it Agile Modeling sessions, long before SAFe adopted the same practice and renamed it.

But, having said that, we are in the process of explicitly adding “Big Room Planning” as an option to Coordinate Activities to make it blatantly clear to people.

Michael Kogan

Hey Scott, how are you?

As you might remember I have started a discussion in our LinkedIn group on the matter of scaling in DA as I was unable to find anything substantial in the flagship book (please refer me to the right chapter(s) if I missed). I was referred to this excellent article: http://disciplinedagiledelivery.com/wp/agility-at-scale/large-agile-teams/.
There, in the Large Team section, several large-scale strategies are discussed. However, I could find a discussion on which forum to engage only in “Strategy #1. Do a bit more up-front requirements exploration”. Nothing more appears in any other section with regards to who should participate in cross-team discussions. I found that the Leadership Team idea is prevalent all over this article, which actually advocates for representatives from teams rather than a larger (including all-hands) forum.
So obviously I have missed some of the resources. I will be grateful if you can point me in the right direction.



Leave a Reply

Your email address will not be published. Required fields are marked *