Sample of practitioners' opinions

• 1: Paweł Huryn
• 2: Kevin Bendeler
• 3: Sam Haynes
• 4: Luca Minudel
• 5: Yves Hanoulle

1 - Paweł Huryn

Paweł Huryn comments in his post on various aspects of SAFe, where he notes that

• SAFe adopts a Waterfall approach to requirements
• SAFe processes and roles show a lack of trust and autonomy of development teams
• SAFe focus is on plans and output more than on outcomes and feedback
• SAFe version of Scrum deviates from the real Scrum making it worse. He concludes by suggesting that with SAFe an organisation doesn’t feel the need to change anything substantial, but with it, they feel they can call themselves “Agile.”

References:

• https://www.phuryn.com/watch-out-waterfall-ahead-the-truth-about-safe/

2 - Kevin Bendeler

Kevin Bendeler after working several years with SAFe comments on 7 flaws he noticed in the framework’s adoption:

• In SAFe extensive front-loaded planning encourages ineffective larger batch size work
• Technical debt tends to increase in SAFe organisations
• SAFe Program Increment (PI) cycle time is unfit for teams that need to be responsive
• SAFe roles and structure may discourage teams collaboration that’s an Agile value
• SAFe approaches to estimation is more predictive than empirical as in Agile
• SAFe focus more on output and volume than the value created and delivered
• SAFe doesn’t have enough focus on the feedback loop and related learnings. He concludes by saying he thinks that trying to scale Agile up by applying heavyweight, top-down methodologies is antithetical and counterproductive.

References:

• https://kevinbendeler.medium.com/i-dont-like-safe-9a003773e42c

3 - Sam Haynes

Sam Haynes, based on his observations of SAFe implementations thinks that:

• SAFe’s ask for excessive time to developers for estimations and metrics is demotivating
• SAFe requirement of starting by getting everyone SAFe trained and certified is suspicious
• SAFe “branded agile” risk to discredit genuine Agile
• PI Planning tries to manage dependencies instead of having a loosely coupled architecture
• PI Planning cadence doesn’t allow to timely react/adapt to changing customer needs
• PI Planning and Release Trains are inferior to on-demand planning and Continuous Delivery. He wonders why anyone with a genuine Agile mindset would be using SAFe in the first place.

References:

• https://levelup.gitconnected.com/safe-a-waterfall-pig-with-agile-lipstick-dd13a200b008

4 - Luca Minudel

Luca Minudel analyses various aspects of the framework and comments on their practical implications noting that:

• The 12-step SAFe Implementation Roadmap is like a 1-size-fits-all Waterfall programme
• SAFe Budgeting and Portfolio management don’t solve the problems of annual budgeting and planning due to the prescriptive, top-down, rigid nature of most SAFe implementations
• SAFe Requirements Model is a pre-Agile deliverable-oriented hierarchical decomposition of the work mirroring the hierarchy of the roles in SAFe, it reinforces a top-down approach
• SAFe Roles add more bureaucracy, disempower the teams, and make collaboration harder
• PI Planning hinders business-tech collaboration, accommodates dependencies instead of removing them, and perpetuates a top-down pre-Agile approach
• Release Trains is a very inefficient pre-Agile practice inferior to all the modern alternatives
• Overly complicated SAFe contradicts the Agile principle of simplicity and emergence Following his observations, he concludes that SAFe violates all four Agile values.

References:

• https://www.smharter.com/blog/2020/06/17/my-opinion-on-the-scaled-agile-frameworks-and-safe-and-related-facts/

5 - Yves Hanoulle

When I first heard of SAFe, I was hearing the same kind of negative things as I heard when I first heard of Scrum. (From people doing XP) or Kanban (from people doing scrum). So I decided to look for a SAFe project to experience it myself. As I did not want to just have an opinion based on theory. After that project, my general feeling was: SAFe goes further than the companies implementing it want to go and does not go as far as what the companies really need. I saw that at best it was a gateway drug to agile. Yet in most companies, it just gives a new name to an old way of working. A nice example is dependencies, instead of making dependencies transparent to start working on removing them, they at best visualise them so show them as reality. I used to think it was nice they showed many different techniques to a large audience. Now I see that not only do they explain them badly and give practitioners a bad start with a new technique, but they also try to copyright techniques from agile friends. The sentence “this is not agile”, is not agile in itself, yet calling a cat a dog, does not make it bark.