10 Principles of SAFe
- Take an economic view
- Apply systems thinking
- Assume variability; preserve options
- Build incrementally with fast, integrated learning cycles
- Base milestones on objective evaluation of working systems
- Make value flow without interruptions
- Apply cadence, synchronize with cross-domain planning
- Unlock the intrinsic motivation of knowledge workers
- Decentralize decision-making
- Organize around value
Criticisms of SAFe (from Microsoft Copilot)
The Scaled Agile Framework (SAFe) is often criticized by proponents of more traditional or purist Agile methodologies. While SAFe aims to bring Agile principles to large enterprises, critics argue that it introduces complexity and bureaucracy that can undermine Agile’s core values. Here are some of the most commonly cited issues:
🔄 Deviation from Agile Principles
- Too prescriptive: SAFe introduces many roles, ceremonies, and artifacts, which some feel contradicts the Agile Manifesto’s emphasis on simplicity and individuals over processes.
- Top-down control: Critics argue that SAFe leans toward command-and-control structures, which can stifle team autonomy and self-organization.
🏢 Enterprise Bureaucracy
- Heavyweight structure: SAFe includes layers like Solution Trains, Release Train Engineers, and Portfolio Management, which can feel like traditional project management in disguise.
- Overhead: The framework can require significant training, tooling, and coordination, which may not yield proportional benefits.
🧩 Misalignment with Agile Culture
- Waterfall in Agile clothing: Some implementations of SAFe resemble a rebranded waterfall model, with long planning cycles and rigid timelines.
- Focus on compliance: Organizations may adopt SAFe to “check the Agile box” rather than to embrace Agile values, leading to superficial transformations.
📉 Team-Level Disempowerment
- Reduced team autonomy: Teams may feel constrained by centralized planning and decision-making.
- Role confusion: The introduction of many new roles can blur responsibilities and dilute accountability.
🧠 Learning Curve and Complexity
- Difficult to implement well: SAFe’s complexity can lead to poor implementations that miss the intended benefits.
- Training dependency: Organizations often rely heavily on certified consultants and training programs, which can be costly and time-consuming.
🧪 Empirical Feedback Loops
- Longer feedback cycles: Compared to Scrum or Kanban, SAFe may introduce longer cycles between planning and delivery, reducing the ability to adapt quickly.
Despite these criticisms, some large organizations find SAFe useful for coordinating across many teams and aligning business and IT. The key is how it’s implemented—some companies tailor SAFe to preserve agility while gaining the benefits of scale.
Would you like a comparison between SAFe and other scaling frameworks like LeSS or Spotify Model?
My own thoughts
What is problematic about these principles?
Take an economic view
Delivering the ‘best value and quality for people and society in the shortest sustainable lead time’ requires a fundamental understanding of the economics of building systems.
Its not explicit, but the “economic” framing suggests literally evaluating work based on perceived dollar value. The disincentivises work that is harder to quantify in those terms (i.e. anything that is concerned with longer-term stability of the system)
Apply systems thinking
A surface-level read of this isn’t immediately problematic, and is actually the opposite.
Assume variability; preserve options
Traditional design and life cycle practices encourage choosing a single design-and-requirements option early in the development process. Unfortunately, if that starting point proves to be the wrong choice, then future adjustments take too long and can lead to a suboptimal design. A better approach is to maintain multiple requirements and design options for a longer period in the development cycle. Empirical data is then used to narrow the focus, resulting in a design that creates optimum economic outcomes.
Not immediately problematic, although the phrasing does suggest more concrete “design” and by extension more time spent on upfront design. Not at odds with how I think about agile as such, but I prefer the “last responsible moment” framing.
The last responsible moment makes sense for decisions which are costly to change, but everything that can be rolledback thanks to encapsulation and information hiding is already abstracted away enough.
Lean Tools: the Last Responsible Moment
Build incrementally with fast, integrated learning cycles
Again, not immediately problematic on a surface-level read. But then…
Since the ‘system always runs,’ some increments may serve as prototypes for market testing and validation; others become minimum viable products (MVPs).
This sets off some alarm bells because we’ve already established that work is prioritised based primarily on their perceived dollar value to the business. Is hardening an MVP system that’s already been shipped likely to be seen as more valuable than moving on to the next feature? Probably not.
Base milestones on objective evaluation of working systems
This one seems to be talking about showcases in a roundabout way. Okay.
Make value flow without interruptions
Surface-level reading seems fine.
Apply cadence, synchronize with cross-domain planning
I guess this is where