A practical look at SAFe, LeSS, Scrum@Scale, Disciplined Agile, Nexus, and custom hybrid models for enterprise IT organizations using Jira, Jira Service Management, and Confluence Cloud.

---

Scaling Agile in the Enterprise: The Question Nobody Really Wants to Answer

For many organizations, Agile starts small and local. A few teams adopt Scrum, delivery improves, visibility increases, and stakeholders begin to ask the obvious next question: How can we scale this?

That is exactly where things become more complicated.

Scaling Agile is not just about multiplying ceremonies, creating more boards, or coordinating more stand-ups. Once an organization operates across multiple teams, products, tools, geographies, or business units, the challenge shifts from team execution to enterprise coordination, governance, architecture, value flow, and decision-making. PMI makes this point very clearly: while Agile works well for small teams and projects, organizations that want to apply it enterprise-wide or in large, complex initiatives need to deliberately address scale and choose an approach that fits their context rather than simply replicating team-level Scrum everywhere (for more details, see: Scaling agile, What Does It Mean to Scale Agile).

That distinction matters. PMI also notes that Scrum of Scrums technique can be useful when teams need to collaborate, but it can be insufficient on its own because cross-team challenges are fundamentally different from intra-team ones (ref.: Practice: Scrum of Scrums). At the same time, PMI’s Disciplined Agile perspective emphasizes that organizations should choose and evolve their own Way of Working, combining practices from different approaches in a context-sensitive manner. And yet, despite the abundance of frameworks on the market, one uncomfortable truth remains: there is no universally superior scaling framework!

In support of this statement, a large empirical study comparing teams using SAFe, LeSS, Scrum of Scrums, custom approaches, and no explicit scaling approach examined data from 15,078 Agile team members, 4,013 teams, and 1,841 stakeholders to assess team effectiveness and stakeholder satisfaction (link.springer). One of the key premises of that work is especially revealing: we should not necessarily expect substantial differences in effectiveness across scaling approaches.

That changes the conversation. Instead of asking, “Which framework is best?” a more mature question is: Which operating model is most effective, sustainable, and implementable in our context, with our processes/constraints, our culture, and our toolset? If your environment is built around Jira, Jira Service Management, and Confluence Cloud, that question becomes even more practical and the next sections of this article offer a possible answer to it.

---

What Global IT Organizations Are Actually Using

Before comparing the different solutions and discussing recommendations, adoption data across industry surveys tells a consistent story, even if the exact figures vary based on survey design, category aggregation, and whether organizations report their official framework or their actual practices.

Among scaled Agile approaches, SAFe remains the most widely adopted enterprise framework. A recent empirical study cites an industry survey placing SAFe at an approximate 53% market share (link.springer). At the same time, summaries of the 17th State of Agile report show a lower but still dominant figure, with about one quarter of respondents identifying SAFe as their enterprise Agile framework (agilelab). The difference depends largely on survey design and categorization, but the conclusion is stable: SAFe is the market leader.

The second major cluster is Scrum@Scale/Scrum of Scrums, often reported at around 20% of organizations in more conservative summaries (agilelab), and up to 28% where the two categories are aggregated (16th-annual-state-of-agile-report-safe-is-still-the-market-leader).

Then comes an important category that is often underappreciated in formal discussions: custom or hybrid operating models. Historical survey commentary points to a visible ~12% adoption level for explicitly custom approaches (16th-annual-state-of-agile-report-safe-is-still-the-market-leader). But in my opinion the more important insight comes from Digital.ai 17th State of Agile Report interpretation: medium-sized and larger organizations are far more likely to embrace custom software development strategies that combine multiple frameworks.

After that, other frameworks adoption drops significantly:

• LeSS typically appears in the 4%–6% (Do Agile Scaling Approaches Make A Difference? An...)
• Disciplined Agile in the 3%–4% (Do Agile Scaling Approaches Make A Difference? An...)
• Nexus around 3% (link.springer)

The numerical picture matters, but not only because it tells us what is popular. It also reveals a structural pattern: as organizational complexity grows, strict framework purity becomes less common, and hybridization becomes more likely.

---

The Main Scaling Agile Approaches: A Quick Introduction and Comparison

Having mapped the market landscape, it is worth examining the main frameworks from a different angle: how effective are they in practice, and how well do they fit a global enterprise context?”

SAFe: The Enterprise Standard

Scaled Agile Framework (SAFe) is the most established and recognizable scaling framework in the market. It is the enterprise standard for a good reason: It explicitly addresses portfolio management, program governance, and business-IT alignment in a way that team-centric frameworks do not. PMI credits it with an important contribution: reframing Agile at scale from a purely bottom-up team collaboration model into a more business-driven enterprise approach with clearer roles then other frameworks do (see: SAFe: The Good, the Bad, and the Ugly). The cost is equally real: significant overhead, more roles and artifacts, and a well-documented risk of bureaucratization. Results depend heavily on implementation quality, not just framework adoption. SAFe is strong in environments with complex governance, multiple portfolios, high dependency density, strong business–IT alignment needs and regulatory or compliance pressure. But the trade-off is equally well known to result in higher overhead, more roles and artifacts, greater implementation effort, a real risk of bureaucracy masquerading as agility. SAFe can be very effective, but only when an organization is ready to support the operating discipline it requires.

Scrum@Scale/Scrum of Scrums: The Natural Extension

Scrum@Scale offers a natural evolutionary path for organizations already using Scrum. They are easier to understand, easier to explain, and often easier to implement than a full enterprise framework. Their limitation is scope: they address team coordination but leave portfolio governance, architectural alignment, and value stream design largely unresolved. A useful starting point, but rarely a sufficient end state for complex enterprises. They work well when teams already use Scrum consistently, where dependencies exist, but are still manageable and when the organization wants to scale gradually. But PMI’s caution is important here: this model can be insufficient by itself in large enterprise contexts (see: Practice: Scrum of Scrums): It helps coordination, but it does not automatically solve for portfolio governance, systemic risk, architecture, funding, or value-stream design.

LeSS: Minimalist and Principle-Driven

Large Scale Scrum (LeSS) remains influential despite its relatively low adoption. PMI includes it among the three major scaling frameworks worth examining Scaling agile, and practitioner sources consistently describe it as a lightweight framework based on simple rules and principles. LeSS is compelling when an organization wants high fidelity to Agile and Lean principles, fewer roles and less process overhead, a strong single-product mindset and genuine simplification rather than framework layering. In fragmented, multi-domain global environments, those conditions are hard to create, which likely explains its relatively low adoption despite its conceptual strength.

Disciplined Agile: Context Over Prescription

Disciplined Agile (DA), now part of PMI, is less a framework and more a decision toolkit for choosing ways of working based on context. It draws from Scrum, Kanban, SAFe, Lean, and others, guiding tailoring decisions based on team size, domain complexity, and organizational maturity. Its low adoption figure reflects how difficult it is to market a “choose your own way” approach, not a lack of practical value. It also distinguishes between tactical agility at scale and strategic agility at scale, explicitly framing Agile not just as a team concern but as an enterprise design concern (Agility at Scale). Disciplined Agile is especially relevant in heterogeneous organizations, where different parts of IT do not and should not operate identically. It is a strong fit conceptually, but it requires maturity. Without governance and coaching discipline, “tailoring” can quickly become “everyone does something different.”

Nexus: Useful, But Narrower

Nexus is a solid option for scaling Scrum across a limited number of teams. It is as most suitable for roughly 3–9 teams, with a strong emphasis on integration. That makes it useful in product-centric environments of moderate scale, but less compelling as a global enterprise operating model: for global organizations managing dozens of teams across multiple products and geographies, it was simply not designed to cover the full scope of the problem.

Custom / Hybrid: The Real-World Enterprise Pattern

A well-designed custom or hybrid model deserves to be treated with the same seriousness as any named framework! With possible combination of team-level Scrum, Scrum of Scrums technique coordination, SAFe-inspired quarterly planning, and Disciplined Agile tailoring principles , is not methodological compromise: it is deliberate design, and it is exactly what PMI’s Disciplined Agile toolkit is built to support. The 12% explicit adoption figure almost certainly understates how many organizations are running this pattern in practice. If anything, hybrid models are often more representative of what global organizations actually run than formal framework labels suggest. Indeed, PMI’s Disciplined Agile perspective gives that choice conceptual legitimacy (What Is Disciplined Agile?).

---

What Works Best with Jira, Jira Service Management, and Confluence

As noted above, one key factor in choosing the right scaling approach is the toolset your organization already has in place. Now comes the practical question: If your organization uses Jira, Jira Service Management, and Confluence as its primary IT toolset, the choice of scaling model cannot be made independently of those tools. So, which scaling approaches are the best fit for a global IT organization that already runs on these tools? Which scaling model is the most realistic?

My answer is straightforward: The best overall fit is a custom/hybrid model built on the Scrum of Scrums technique, with some selected SAFe-light practices and Disciplined Agile thinking.

Why not go straight to a full enterprise framework? Because while highly structured frameworks are strong conceptually, they also demand a substantial amount of coordination, governance modeling, and reporting discipline. With Jira, JSM, and Confluence, many of these needs can absolutely be supported, but the most sustainable results usually come from keeping the operating model pragmatic rather than over-engineered.

By contrast, Scrum@Scale/Scrum of Scrums maps much more naturally onto the Atlassian stack:

• Jira supports team backlogs, boards, issue hierarchies, filters, dashboards, and basic dependency tracking
• Confluence supports planning pages, decision logs, governance templates, release notes, and shared documentation
• Jira Service Management supports intake, request routing, triage, change flows, support interactions, and service-oriented work

This makes Scrum@Scale/Scrum of Scrums the easiest model to implement.

But “easiest” is not the same as “best.” PMI’s own guidance reminds us that a not structured and well coordinated Scrum of Scrums is often helpful but can be incomplete Practice: Scrum of Scrums. That is why the better answer is not Scrum@Scale/Scrum of Scrums alone, but a hybrid operating model that supplements it.

To summarize what was analyzed above in one last short recommendation, based on adoption data, empirical research, and tool compatibility (particularly when Jira, Jira Service Management, and Confluence are already in place) here is how the approaches rank for a global enterprise IT organization still building its Agile culture and scaling maturity:

The clearest practical path is to start with Scrum of Scrums technique as the coordination mechanism from Scrum@Scale, add lightweight SAFe-inspired planning cadences, use Disciplined Agile principles to guide tailoring decisions, and connect everything through Atlassian tools and practices. That is a possible hybrid model, and it reflects how many effective global IT organizations actually operate (regardless of what framework name they report using).

Differently, more mature organizations with a well-established Agile culture may consider a fuller SAFe implementation, supported by Jira Align to best operationalize it within the Atlassian ecosystem. Given the significant investment that such a path requires, in terms of tooling, training, and organizational change, the recommendation is to work through the intermediate adoption steps outlined above before committing to that level of complexity.

---

Conclusion: In Global IT, Hybrid Is Often the Most Mature Choice

SAFe is the most widely adopted enterprise scaling framework for good reasons. PMI recognizes its value in aligning business and delivery at scale (SAFe: The Good, the Bad, and the Ugly). But evidence consistently shows that framework name alone does not drive effectiveness. What drives effectiveness is how well the operating model is designed, implemented, and evolved in the specific context of that organization: the evidence shows that framework brand alone does not determine effectiveness.

In practice, larger organizations increasingly need models that are context-sensitive, tool-compatible, and operationally sustainable.

That is why, for many global IT organizations, the most mature choice is not strict framework purity, but a well-governed hybrid model built around the tools and processes they actually use.

Because scaling Agile is not really about adopting a label but it is about designing a system that helps teams deliver value together.

---

These Solutions are Engineered by Humans

Did you find this article interesting? Does it match your skill set? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth IT Italy.