The Scaled Agile Framework (SAFe) has become one of the most widely adopted approaches for scaling agile delivery across large organisations. It promises alignment, faster output, improved visibility and better coordination across complex portfolios of work.
Yet the reality is often more complicated.
Many organisations invest heavily in SAFe transformations only to find the promised benefits never quite materialise. Teams start out enthusiastic, energised by training, new roles and a fresh vocabulary. A few months later the mood often changes. Teams begin to feel overwhelmed by the framework. Leaders grow frustrated by the lack of visible progress. Agile becomes something people comply with rather than something that helps them deliver better outcomes.
So it is worth asking an honest question.
When does SAFe actually work well and why do so many organisations struggle with it?
When SAFe Works Well
Despite the criticism it sometimes receives, SAFe can be extremely effective in the right environment. Organisations that get the most value from it tend to share several common characteristics.
Large organisations with complex delivery environments
SAFe was designed for scale. It works best where dozens or hundreds of people contribute to interconnected products, platforms or services.
In these environments multiple teams must coordinate dependencies, shared components and competing priorities. Without some form of structured scaling approach, delivery can quickly become chaotic.
SAFe provides a structure for aligning those teams and managing complexity.
A strong need for organisational alignment
SAFe places heavy emphasis on alignment between leadership and delivery teams. Practices such as Program Increment (PI) Planning ensure everyone understands the broader objectives and how their work contributes to them.
When done well, these events improve transparency, surface dependencies early and create a shared understanding of priorities across large delivery groups.
Organisations that commit to real change
The organisations that succeed with SAFe treat it as an organisational change initiative rather than simply a new delivery method for technology teams.
Leadership is actively involved. Governance structures evolve. Funding models change. Portfolio decision making improves.
In other words, the organisation adapts to support the framework rather than simply layering SAFe ceremonies on top of existing processes.
Where Traditional Projects Fit in a SAFe Environment
One area that often causes confusion is how traditional projects operate within a SAFe environment.
In reality, most organisations adopting SAFe do not suddenly stop running projects. Regulatory initiatives, infrastructure upgrades, enterprise transformation programs and externally driven change still typically operate with project structures, budgets and executive sponsorship.
SAFe does not remove the need for these initiatives. Instead they need to be integrated into the broader delivery system. Many organisations operating with SAFe still maintain a traditional project management framework and a Project Management Office (PMO).
However, a common mistake occurs when projects are simply pushed into a SAFe delivery model without adapting governance.
Projects usually rely on fixed scope expectations, detailed upfront planning, rigid milestone reporting and tightly controlled funding approvals. SAFe delivery teams operate very differently. They plan iteratively, manage evolving backlogs and continuously reprioritise work.
The two models can clash.
When organisations attempt to force traditional project controls onto agile delivery teams, confusion and friction quickly emerge. Teams are asked to commit to detailed long term plans while also being told to work iteratively. Project reporting cycles clash with Program Increment planning. Delivery teams end up operating two competing planning systems.
The consequences are predictable. Decision making slows down. Teams spend more time reconciling plans than delivering value. Governance becomes heavier rather than lighter. Leaders begin to question whether agile is actually helping.
Well functioning organisations recognise that agile delivery and project governance can coexist, but only if the model is deliberately designed.
Projects often act as the container for investment, funding and accountability, while agile teams deliver the work iteratively through Agile Release Trains (ARTs). When the two are aligned, projects provide strategic oversight while agile teams focus on delivery.
Common Mistakes Organisations Make
Trying to eliminate projects entirely
Some SAFe transformations are driven by the belief that projects are outdated and should disappear completely.
This usually reflects a misunderstanding of what SAFe is trying to achieve. Agile delivery models are designed to improve how work is delivered, not remove the need for investment governance or executive accountability.
Large regulatory programs, platform transformations, mergers and infrastructure upgrades rarely fit neatly into a purely product based model.
When organisations attempt to eliminate projects entirely, they often remove the mechanisms that previously provided clarity around ownership and accountability. Funding decisions become blurred. Senior leaders struggle to understand who is responsible for outcomes. Portfolio oversight weakens because the link between investment decisions and delivery becomes unclear.
In many cases governance does not disappear at all. Instead it reappears informally through additional steering groups, executive forums and layers of reporting that sit outside the SAFe structure.
The organisation ends up with more complexity rather than less.
Running projects and SAFe in parallel without integration
The opposite mistake is keeping the traditional project model completely separate from the agile delivery environment.
In this situation project plans, milestones and reporting operate independently from the Agile Release Train. Teams deliver work through agile cycles while still reporting against fixed project schedules.
This creates constant tension.
From a governance perspective there is pressure for certainty and detailed plans. From a delivery perspective work evolves through short iterations as teams learn more.
When these two models operate independently, teams end up maintaining two planning systems. Detailed project schedules exist alongside backlogs, iteration plans and Program Increment commitments.
The result is duplication, increased reporting and a growing gap between what the project plan says will happen and what delivery teams are actually doing.
Over time this disconnect erodes confidence in both the project model and the agile delivery model.
Organisations that succeed with SAFe deliberately align the two. Governance cycles are adapted to match Program Increment planning and reporting focuses on outcomes rather than rigid milestone tracking.
Without that alignment, organisations effectively run two operating models in parallel.
Misunderstanding the role of the PMO
Another common mistake is assuming the Project Management Office (PMO) is no longer required.
In reality the opposite is often true.
Scaled environments require strong portfolio oversight, prioritisation and governance. PMO capability remains critical in ensuring investment decisions align with strategic outcomes and that delivery remains coordinated across multiple Agile Release Trains.
What often needs to change is not the existence of the PMO but its focus.
Traditional PMOs were designed around project control. Their role centred on monitoring schedules, managing stage gates, enforcing reporting standards and ensuring compliance with governance processes.
In scaled agile environments this approach becomes less effective because delivery is no longer organised around tightly controlled project plans. Work is delivered iteratively, priorities change and value is realised incrementally rather than only at the end of a project.
As a result, many organisations have begun talking about the concept of a Value Management Office (VMO).
The difference is largely one of emphasis.
A Project Management Office focuses primarily on how initiatives are delivered. A Value Management Office focuses on whether investments are delivering the intended strategic value.
However the idea that a VMO should replace the PMO entirely is another misconception.
In practice the VMO concept emerged because many traditional PMOs were effective at governing delivery but less focused on whether projects ultimately delivered the benefits expected.
Large organisations still require delivery governance. They still need coordination across complex initiatives, dependency management, risk oversight and portfolio visibility.
The most effective organisations therefore do not replace the PMO. They evolve it.
The PMO expands its role to include stronger portfolio management, value tracking and investment oversight. Whether it is called a PMO, VMO or Investment Management Office matters far less than the services it provides.
When done well, this function becomes a critical link between strategy, investment decisions and delivery performance.
Why Many SAFe Implementations Struggle
Beyond the challenge of integrating projects, several other factors commonly derail SAFe transformations.
Treating SAFe as a process rather than a mindset
Many organisations approach SAFe as a checklist of ceremonies, roles and artefacts. Teams follow the framework mechanically while the underlying ways of thinking about value, collaboration and learning remain unchanged.
The result is often a heavier version of the existing delivery model rather than a more effective one.
Trying to implement everything at once
SAFe is comprehensive. That is both its strength and its weakness.
Some organisations attempt to roll out the entire framework across the organisation simultaneously. This creates confusion, fatigue and resistance.
Successful organisations introduce it gradually, focusing first on the practices that deliver the greatest value.
Leadership behaviour does not change
One of the biggest barriers to success occurs when leadership continues operating with traditional command and control approaches.
Scaled agile relies on empowered teams, decentralised decision making and collaboration across organisational boundaries. If leaders still expect rigid control and detailed certainty, the framework becomes constrained.
Agile cannot thrive in an environment that fundamentally distrusts delivery teams.
Getting SAFe Back on Track
The good news is that struggling SAFe implementations can often be recovered. Organisations have usually already invested in training, tooling and structural changes.
What is often missing is executive clarity, delivery alignment and practical experience in making the framework work in the real world.
Revisit the purpose of the transformation
Why was SAFe introduced in the first place?
Many organisations lose sight of the original objectives. Reconnecting the framework to strategic outcomes helps refocus the transformation.
Simplify the implementation
SAFe is a framework, not a rigid prescription. It should be configured to suit the organisation.
Simplifying the model, clarifying roles and focusing on the practices that deliver the most value can significantly improve adoption.
Strengthen portfolio governance
Effective scaling requires strong portfolio oversight. Organisations need clear prioritisation, stronger alignment between strategy and delivery and more effective investment decision making.
This is where the PMO often plays a critical role.
Align projects and agile delivery
Rather than forcing a choice between agile and projects, organisations need to design a model where both operate effectively together.
This often means redefining project roles, adapting governance and ensuring portfolio oversight supports the cadence of agile delivery.
A More Honest Conversation About SAFe
SAFe is neither a silver bullet nor a dagger to the heart.
Like any framework it works well in some environments and poorly in others. The difference usually comes down to how thoughtfully, how well it’s sponsored and how willing the organisation is to evolve the way it operates.
For organisations willing to take a pragmatic approach, SAFe can provide a powerful mechanism for improving coordination, alignment and delivery at scale.
If we can help you get your scaled agile journey back on track, get in touch today!
Further Reading
Documented Cases of SAFe Failure and Contributory Factors
Organisation: Nokia (2012-2013)
Industry: Telecoms (Handset Dision)
Reported Issues / Outcomes:
Agile adoption failed to save market position. After a large-scale agile (SAFe-like) rollout, decision-making slowed and the company failed to respond quickly to the smartphone revolution, contributing to Nokia’s collapse in the mobile phone market.
Contributing Factors:
Heavy bureaucracy and rigid hierarchy blunted agility. Top leaders espoused “agility” but did not achieve true nimbleness. The organisation’s culture remained siloed and fearful of admitting problems, leading to poor communication and sluggish decision-making at the top despite attempts to be agile. Strategic priorities were misaligned and internal competition among units slowed unified action. These gaps in culture and leadership meant SAFe processes became an empty ritual rather than enabling fast strategic pivots and open communication.
Source:
Harvard Business Review analysis (via Harvard Business School case and Business History study); supporting commentary from dev.to .
Organisation: Cisco (c. 2018–2020)
Industry: Global Technology (Networking)
Reported Issues / Outcomes:
Partial SAFe implementation stalled. Cisco saw uneven results when scaling agile with SAFe. Some departments improved but others lagged significantly. The transformation failed to take hold enterprise-wide, leading to persistent bottlenecks and frustration in areas that remained traditional.
Contributing Factors:
A deeply entrenched hierarchical culture resisted change. SAFe was introduced in isolated pockets without broad leadership buy-in, resulting in inconsistent adoption across the organisation. Senior managers were reluctant to delegate decision-making, undermining the principle of team empowerment. In effect, the organisation attempted to overlay SAFe on top of its existing structure without adopting the cultural and structural changes required. This mismatch created confusion, slow approvals and a reversion to traditional behaviours in many teams.
Source:
SAFe consultant analysis referencing Cisco internal lessons (LinkedIn commentary).
Organisation: Standard Bank (South Africa, c. 2015– )
Industry: Financial Services (Banking)
Reported Issues / Outcomes:
“Stalled at pilot scale.” Africa’s largest bank introduced SAFe within a small number of pilot teams and initial projects but struggled to scale the approach across the broader organisation. Coordination problems emerged as more teams attempted to collaborate and the bank failed to realise the expected agility benefits at the enterprise level.
Contributing Factors:
Change resistance and role confusion affected the transformation. Middle managers struggled to redefine their roles as the organisation attempted to shift from traditional project management toward agile leadership models. Many continued to operate with command-and-control behaviours. Senior executives also pushed for quick results and did not always understand the longer-term nature of agile transformation, leading to inconsistent support. At the same time, surrounding functions such as compliance and the PMO continued to operate using traditional waterfall practices, creating misalignment with agile delivery teams. These factors contributed to an incomplete implementation that never gained full organisational momentum.
Source:
Academic study on SAFe in banking (Tengstrand et al., 2021)
Organisation: Large U.S. Bank (anonymous, c. 2018–2021)
Industry: Banking (Retail Finance)
Reported Issues / Outcomes:
“Agile in name but no results.” A major U.S. bank implemented SAFe by rigorously following the framework’s ceremonies and processes yet saw little improvement in customer value delivery. The transformation devolved into ceremonial agile practices while schedule delays and low innovation persisted. Ultimately the organisation abandoned SAFe and moved to a simpler Kanban-based approach.
Contributing Factors:
SAFe was applied without sufficient tailoring to the organisation’s business needs. The initiative became overly focused on process compliance rather than business outcomes. Teams concentrated on completing SAFe activities rather than delivering measurable customer value. Strategic alignment and outcome-based metrics were weak or absent, meaning SAFe routines became an end in themselves. Front-line teams also lacked genuine empowerment as decisions still required heavy executive oversight. The existing bureaucratic culture remained intact, turning the transformation into what some observers described as “agile theatre.”
Source:
CIO Magazine analysis and supporting commentary from dev.to.