Is the SAFe framework outdated?

  • Updated: 04 October 2024
  • 6 minutes
Article written by

Agile antithesis, Kafkaesque bureaucracy, rigid framework... The unflattering qualifiers are sometimes numerous when it comes to talking about SAFe, the leading framework for scaling Agility company-wide. But are these criticisms justified, or is SAFe the victim of bad press, fueled by certain preconceived ideas? To find out, we asked several Thiga experts about their experiences in the field and their advice for maximizing the benefits of this framework.

London, March 2024. Carlos González De Villaumbrosia, founder of Product School, stirs up controversy at the ProductCon conference by openly criticizing the Scaled Agile Framework (SAFe). According to him, while the framework is well-meant, it has become too complex, too focused on delivery rather than impact, neglecting the critical phases of discovery and Go-To-Market.

A criticism regularly amplified by influential voices such as Marty Cagan. Why the hate? Let's look back at SAFe's main fundamentals to deconstruct the myths surrounding it and offer insights useful for any transformation project.

🧑‍🍳 SAFe à la carte: the ingredients are up to you

SAFe 6.0 is defined by its founders as a "knowledge base composed of integrated and proven principles, practices and skills for achieving Business Agility using Lean, Agile and DevOps."

That choice of words is striking. For SAFe primarily documents proven practices that existed before and will continue to exist afterward. It brings together areas that often tend to work in silos, such as user experience and Product Management, versus DevOps. It serves as a reference framework and common language to align teams on a transformation roadmap and shared competencies while allowing for the flexibility and adaptability needed in a constantly evolving market.

"Often, business speaks business, IT speaks IT, and marketing speaks marketing. SAFe has the advantage of providing a common vocabulary that facilitates dialogue and avoids misunderstandings", says Romain Pabot, Product Coach and Transformation Lead at Thiga..

People often think that you have to apply everything in SAFe to succeed in your transformation. But using SAFe is primarily about making choices. Choices between different practices tied to specific competencies, such as Design Thinking, Scrum, or the OKR method. You choose the relevant skills and draw from the toolbox to develop them.

"Take from SAFe what interests you. If you have a convergence and alignment issue, for example, perhaps the concept of a "train"- the Release Train (ART), a virtual train made up of self-organized multidisciplinary teams that plan, organize, and execute their work together - might be relevant for you. In that case, adapt it based on value and user feedback", explains Romain Pabot. 

SAFe is a model of change management through practice, with the advantage of being quickly implementable. A wealth of literature and numerous community experiences are available to rapidly implement the practices and tools. Take, for example, PI Planning, key events for aligning the work of different teams around common goals. From decision-making to implementation and first results, little time passes. From the first PI Planning, consensus on strategic choices is reached within a few hours, accelerating decision-making processes. This is significant in a context of complex and costly transformation.

According to Renaud Chevalier, Partner at Thiga and certified SPC (SAFe Program Consultant) since 2015, "SAFe is especially useful for large companies still operating in a MOA/MOE project mode, where urgency is pressing due to post-covid economic challenges and time to market misaligned with business needs." This relates to SAFe’s "burning platform" concept, using the metaphor of a burning oil rig where urgency forces joint, radical, and swift decisions.

So, where to start when choosing the right SAFe practices for your context? You can begin by assessing your Agile and Product maturity using a matrix to identify the key skills to develop in the next PI, enabling employees to be effective. The goal is to transition from a mechanical SAFe to a professionalizing SAFe.

SAFe adoption must be thoughtfully tailored to each company’s specific context. As Marty Cagan often points out, processes and tools are not universal or applicable in the same way everywhere. It’s essential to ensure that the behaviors and skills accompanying them are aligned with the transformation’s context and objectives. In short, SAFe is not a magic solution but a powerful framework when adapted to your needs.

🤨 A matter of mindset

What exactly is SAFe blamed for? For some, the framework imposes rigidity that contradicts the very principles of Agility. These critics argue that SAFe becomes too procedural, creating bureaucracy that slows decision-making processes. This can lead to a loss of flexibility and resistance to change.

Without strong sponsorship, SAFe implementation is doomed to fail.

Indeed, SAFe is a framework, and like any framework, people need to follow the same rules and speak the same language to work together. The rigidity some attribute to SAFe is not inherent to the framework itself but often stems from poor change management. If SAFe deployment becomes rigid, it’s usually because teams have not received adequate support to internalize these practices across different phases of change. The ADKAR change management model is an excellent guide for defining action plans and supporting teams through the different phases of transformation:

  • A for Awareness : Explaining why change is necessary. 
  • D for Desire: Motivating individuals to get involved in change.
  • K for Knowledge: Communicating the information needed to explain how to operate the transformation.
  • A for Ability: Ensuring that teams have the necessary skills. 
  • R for Reinforcement : Strengthening change to ensure its sustainability over time. 

According to Peak Product consultant Kai Hansen, many of SAFe’s smart ideas are overshadowed by rules and processes. Companies often apply the framework without understanding why, preventing alignment on common goals. He suggests fostering the right mindset by focusing on principles rather than rules. Tools and processes can then be selected to operationalize those principles.

"SAFe offers a hierarchy of roles that may encounter pitfalls, but it has the merit of putting people at the center. It's not perfect, but it offers regular assessments, surveys, retrospectives, continuous improvement, which is powerful," adds Élodie Dufour, Agile consultant and coach at Thiga. While Agility requires a cultural transformation, considering the human factor in change is essential. According to Renaud Chevalier, "middle management, which has not yet found its place in SAFe, must be integrated. Without strong sponsorship, SAFe implementation is doomed to fail." The first step: truly integrating them into the change management team to make them active participants.

"SAFe emphasizes the need for cross-functional people, which becomes critical as you scale, says Romain Pabot. This can help middle management envision themselves in a "servant leader" role, serving teams who, in turn, serve the customers."

The key to successful change management is for leaders to encourage a deep understanding of Agile principles while providing the freedom to adapt SAFe to specific needs. SAFe does not dictate a rigid way of working: the culture you establish will enable teams to retain their capacity for innovation.

🚨 Spoiler alert: SAFe is a Product organization!

SAFe is criticized for being focused solely on delivery and developments, rather than on impact and value. Is it suffering from a "feature factory" syndrome?

The framework centers its approach on Business Architecture, which structures and aligns work with the company’s objectives and user needs. A key concept is "value streams," which organize development around the stages a product or service goes through to deliver value to the user. For example, for a bank loan, this includes steps like loan evaluation, decision-making, and loan management. These stages form a value chain representing all activities needed to provide these services to users.

Today, some companies build their Agile teams based on cognitive limitations. For instance, the principle that team size should be limited to seven to reduce and optimize the number of interactions. The risk: multiplying Product teams, creating silos, and ultimately forming the infamous "feature factory" focused on frequent feature delivery at the expense of common strategic issues. While considering team size is important, it’s vital to ask the right questions when forming trains: What are my company’s services? What actions will my users be able to carry out?

"To support SAFe implementation in a Business Architecture context, it’s important to use concrete examples and templates to help stakeholders understand the concepts", says Renaud Chevalier, who has helped La Poste group identify its value chains. For example, in a large public organization, trains are structured around the HR process chain to develop the necessary systems and skills: payroll, personnel management, replacements... This results in minimized dependencies and better involvement of key functional areas. The structure allows for a rational number of stakeholders on the IT side and involvement in co-constructing key features and budget planning.

As Romain Pabot points out, "just because you follow SAFe by the book doesn’t mean you'll succeed. You need intimate knowledge of the market and must ground your decisions in a solid business strategy; being an expert in Product processes isn't enough." It’s also crucial to launch gradual, measurable initiatives to assess the benefits of this new organization through the company’s major business indicators and operational metrics like DORA metrics (DevOps Research and Assessment):

  • DF (Deployment Frequency): the frequency with which code is deployed to production.
  • MLTC (Mean Lead Time for Changes): the average time between the start of development and deployment to production.
  • CFR (Change Failure Rate): the percentage of production deployments that result in incidents.
  • MTTR (Mean Time To Recovery): the time required to restore stable service after an incident.

These four major DORA metrics allow the organization to identify continuous improvement opportunities and measure the operational excellence of changes made, treating Agile transformation as a product.

Misinterpreted or poorly implemented, SAFe can indeed create rigidities. Many fail by focusing solely on operational aspects and processes, neglecting change management. The key is aligning on a common strategy and objectives, integrating and training teams and sponsors, and continuously evaluating practices. When adapted to the company’s context, SAFe offers a solid structure for successful large-scale Agile transformations. It’s up to you to find what you’re looking for.

If you have a question or would like some guidance, contact our expert Product organization team.
cover_pm-1

La newsletter Product Management.

Contenus exclusifs, actualités, humeurs, devenez incollables en Produit