Can you have your cake and eat it? Combining SAFe and V XT.
Thoughts on the coexistence of SAFe and other development methodologies.
The other day, in one of our internal knowledge sharing sessions at virtual7, my colleague Dr. Felix Herold talked about the SAFe framework and the SAFe essential model. SAFe is a methodology for scaling agile processes to larger teams and to enable big enterprises adopt an agile mindset. In the discussion, a question came up that intrigued me. This post is my attempt at answering that question.
SAFe - the scaled agile framework and its limitations
For larger organizations, SAFe often appears as the promise of finally bringing the entire enterprise together under a single agile operating model. The idea is not merely to have agile development teams, but to create a fully agile organization—even in a large-scale, enterprise context.
Put simply, SAFe (the Scalable Agile Framework) extends agile principles with additional layers for coordination, planning, and governance. While these layers resemble Scrum-like patterns, they operate on different time horizons and abstraction levels. The intent is to transfer the benefits commonly associated with Scrum to the enterprise scale, in particular:
- customer focus,
- built-in quality,
- transparency, and
- lean thinking.
SAFe aims to achieve this by establishing fixed rhythms for planning, synchronization, and reflection across all levels of the organization. In theory, this ensures that employees share a common understanding of company and product goals, as well as how to achieve them - much like a Scrum team shares a common understanding of its product, roadmap, and objectives.
At least, that is the theory.
As with Scrum, my experience has shown that SAFe works only as well as the people driving it. Most developers are primarily motivated by building and shipping software, not by rituals and ceremonies. It is therefore the responsibility of Scrum Masters, Product Owners, and technical leaders to create an environment in which these ceremonies are meaningful - where teams actively engage, collaborate, and align around shared goals.
With strong leadership, Scrum can work extremely well. Without it, Scrum easily degenerates into a tedious sequence of meetings that add little value to either the product or the development work. Most of us have encountered such situations at some point - and, if we are honest, many of us have contributed to them.
In one or two teams of eight to ten developers, a small number of strong process drivers may be sufficient to keep things on track. As organizations grow, however, teams tend either to become increasingly siloed or to drift away from agreed-upon processes over time.
Now consider what happens when, as envisioned by SAFe, we are no longer talking about one or two teams, but about Agile Release Trains (ARTs) consisting of about ten teams. An ART is a long-lived, cross-functional team of teams that plans, builds, tests, and delivers value together on a fixed cadence. It aligns multiple agile teams around a shared mission, backlog, and Program Increment to deliver integrated solutions predictably.
In addition to their regular team-level ceremonies, developers are suddenly expected to participate in SAFe events operating on a different cadence—and often at a much larger scale. A two-day PI Planning event with more than one hundred participants is not uncommon.
For individual developers to remain focused, constructive, and engaged in such settings requires more than stamina and enthusiasm for processes. It requires skilled facilitation and leadership to create an atmosphere in which each participant genuinely feels that their contribution matters to the product and the organization.
SAFe in regulated environments
There is, however, another factor that can undermine a SAFe transformation in large organizations. Any organization employing more than one hundred developers on a single product did not emerge overnight. Such organizations inevitably have existing processes—some originating long before “agile” became fashionable, others driven by regulatory or compliance requirements.
Does this mean that organizations with strict standards, long-established processes, or deeply rooted structures are excluded from the benefits SAFe promises? What about the public sector?
SAFe is certainly not off-limits for such organizations. However, adopting it often requires either significant reshaping of existing processes - or a more nuanced, hybrid approach to SAFe itself.
Consider an organization that, for regulatory reasons, has established a non-Scrum development process. Such organizations exist, even if parts of the tech community prefer to assume that Scrum is the only viable way to build software today. The good news is that, from a SAFe perspective, the specific team-level development methodology used within an Agile Release Train is largely irrelevant.
At the enterprise level, it matters little whether a frontend team runs Scrum ceremonies or follows a different structured process. What matters is that the team can respond effectively to portfolio- and PI-level planning and deliver within that cadence. ARTs and PIs operate on a different abstraction layer than day-to-day engineering. As long as clear interfaces exist between these layers, SAFe can coexist with alternative development processes.
A concrete example is the V-Model XT, which is widely used by regulated German government agencies where Scrum is often considered too indeterministic (and yes, we Germans do appreciate thorough planning). In V-Model XT, the “XT” stands for eXtreme Tailoring. Its core idea is to rethink the classical V-model by shifting the focus from activities to well-defined products, each with explicit structure and quality criteria.
Crucially, V-Model XT is explicitly designed to be tailored. This flexibility makes it compatible - within limits - with iterative and even Scrum-based approaches. More importantly, V-Model XT explicitly embraces change and iteration throughout the development lifecycle.
These characteristics make it a viable candidate for organizations aiming to adopt SAFe in regulated environments. That said, making the two frameworks work together requires careful consideration.
How to get the best of both worlds
First and foremost, responsibilities must be clearly separated:
- SAFe governs funding, cadence, coordination, and transparency at the enterprise level.
- V-Model XT governs engineering, verification, and compliance within the teams.
Second, both frameworks must be tailored to the specific organizational context. Out-of-the-box SAFe will not fit out-of-the-box V-Model XT. Accepting this reality is essential. Achieving a workable hybrid will take time, iteration, and adjustment.
Organizations - and their developers - must also accept that they are neither “doing SAFe” nor “doing V-Model XT” in their pure forms. One of the most critical alignment challenges is the definition of an “increment.” In SAFe, an increment is typically defined as potentially shippable value. In V-Model XT, an increment is a verified and documented product state.
In practice, this means that, on the SAFe side, stakeholders must accept smaller but thoroughly verified increments. On the engineering side, teams must learn to size their increments so that they fit into SAFe’s cadence and feedback loops.
Velocity and story points can no longer serve as the primary currency. Instead, planning and commitment need to be framed in terms of requirement coverage, test specifications, and verification outcomes. Teams do not commit to “x story points,” but to delivering a specific, verifiable feature or capability within an iteration. This then caters to the v-model’s definition of “iteration” rather than the typical agile approach.
While aligning these perspectives is entirely feasible, the greatest risk lies not in mapping terminology, but in creating a “Zombie SAFe” environment—one that uses SAFe language and artifacts without embracing its core principles, particularly inspect-and-adapt, joint planning, and real commitment. You could describe SAFe as commitment to agile principles on the enterprise scale. So if you cannot commit to an agile mindset on the most granular level in your enterprise, the development team level, you should ensure that principles like lean thinking and the agile mindset in general are rooted as deep in your organization’s DNA as possible. This will not eliminate the risk of creating a “Zombie SAFe” but this thinking can reduce the risk as far as possible.
Then again, this risk of a verbal commitment to agile without following it in depth is not unique to SAFe or its combination with non-agile development methods. The very same failure modes can already be observed in the smallest Scrum teams - whenever the people driving the process lose touch with the sentiments and realities of the team.
Key takeaways
- SAFe can coexist with V‑Model XT (or other non‑Scrum processes) if interfaces between enterprise and team layers are clear.
- Separate responsibilities: SAFe for funding/cadence/coordination; V‑Model XT for engineering, verification, and compliance.
- Tailor both frameworks to your context, out‑of‑the‑box SAFe and V‑Model XT rarely fit perfectly together.
- Define increments in mutually meaningful terms (shippable value vs. verified product state) and agree on sizing and cadence.
- Replace story‑point velocity as needed with measurable commitments: requirement coverage, test specs, and verification outcomes.
- Ensure traceability and compliance artifacts (test reports, acceptance criteria, trace matrices) map to SAFe planning and PI reviews.
- Invest in skilled facilitation and leadership to keep large ceremonies engaging and purposeful.
- Watch for “Zombie SAFe”: avoid using SAFe terminology without practicing inspect‑and‑adapt, joint planning, and real commitment.
- Iterate, measure, and adjust, expect the hybrid to evolve over time through feedback and continuous improvement.
A german version of this post can be found on the virtual7 Blog
References:
Photos: