Built-in quality for the agile release train: the missing piece in your SAFe agile framework
In this article
Summary
This article explains why enterprise organizations often experience friction and slow execution despite following the SAFe methodology and practices to the best of their ability, and why software quality lies at the root of the problem.
SAFe’s Built-in Quality practice acknowledges the importance of code quality and architecture, but stops short of defining what to measure, how to measure it, or how to steer on it across the Agile Release Train (ART). The result is a framework that optimizes for visible outputs: features shipped, Program Increment (PI) objectives met, while technical debt accumulates invisibly beneath the surface. This is the most overlooked reason why SAFe implementations slow down PI-over-PI.
Four dimensions require continuous measurement to close this gap: maintainability, architecture quality, security, and open-source risk. Each has a clear owner: the RTE, the System Architect, and the development teams. Each should be integrated into PI Planning, the ART Planning Board, team retrospectives, and the Inspect and Adapt cycle. The same applies beyond the single ART: at the Solution Train and Lean Portfolio Management level, unmeasured technical dependencies are among the most costly and hardest-to-fix sources of delivery failure.
If you want to understand what this means for your organization, feel free to reach out. We would love to help.
SAFe agile framework: global adoption and growing friction
SAFe (the Scaled Agile Framework) is a popular set of organizational and workflow patterns for implementing agile practices at enterprise scale. Since 2011, it has spread steadily across large enterprises and governments, growing from a relatively simple structure into the comprehensive framework it is today, while incorporating practices like continuous integration and deployment along the way. According to the 17th State of Agile Report by digital.ai, SAFe is now used by 1 out of 4 organizations, making it the most widely adopted scaling framework globally.
Successful adoption examples of the SAFe agile framework
There are plenty of examples of organizations that have adopted it successfully; for example, Mercedes-Benz, Phillips, and Nordea Bank have achieved successful outcomes after implementing the framework: better alignment, stronger collaboration between cross-functional teams, and more consistent delivery.
And yet, frustration with the framework has grown just as steadily.
Common challenges of adopting the SAFe agile framework
The complaints are familiar: too complex, too rigid, too slow. Certainly, the way the framework has been implemented plays a role here, where leadership often fell into the pitfall of expecting Agile to fix their existing organizational issues, a trend we see again today with AI.
But there is a greatly overlooked problem lying at the root of the friction experienced by so many in SAFe organizations: software quality and technical debt.
Generally speaking, when technical debt goes unmanaged inside a SAFe organization, it acts as a slow drag on the agile release train. Stories take longer than they should. Tests fail in ways nobody predicted. Defects appear unexpectedly. Teams slow down. Program increment (PI) objectives slip. Often, engineering teams know about this but lack the means or visibility to bring it to the attention of management.
Deloitte’s 2026 Global Technology Leadership Study puts a number on the scale of the problem: technical debt accounts for 21–40% of an organization’s total IT spending.
Technical debt management is one of the most important challenges for organizations to tackle and something that Software Improvement Group (SIG) has studied across hundreds of enterprise software portfolios
What does built-in quality mean in the scaled agile framework?
To be fair, SAFe does address quality. As software development is a key part of organizations using SAFe, it is not surprising that the framework pays attention to quality. As part of Team and Technical Agility, SAFe defines Built-in Quality: “a set of practices to help ensure that the outputs of Agile teams in business and technology domains meet appropriate quality standards throughout the process of creating customer value.”
It goes further, too, referencing non-functional requirements, including code quality, architecture quality, and security. Few frameworks go that far. But this guidance is marked as Extended Guidance, and it is relatively recent. Earlier versions of SAFe pointed to peer reviews and testing and left it there.
The key point here is that SAFe does not make it explicit how code quality (maintainability) and architecture can be objectively measured, how to know whether the teams are on track, or whether the architect should set explicit targets during PI Planning.
Quality becomes something the teams are expected to care about. Which is not the same as something the ART actually steers on.
Why agile at scale stalls without software quality measurement
In general, steering happens based on what is visible and what gets tracked.
- PI Planning tracks objectives
- Teams manage capacity and iteration goals
- The Program Board maps functional dependencies
- Inspect and Adapt reviews business value.
Looks great. However, none of that includes software quality. Without it, the ART will focus on the visible and optimize for shipping features, while slowly incurring the invisible: a foundation that is slowly getting brittle and complex.
McKinsey recently found that actively managing technical debt frees engineers to spend up to 50% more of their time on work that supports business goals, shifting capacity from maintenance firefighting back to the innovation that agile transformation was meant to deliver.
This explains a pattern I see consistently. The first program increments after a SAFe rollout look promising. Teams are energized, and delivery is moving. Then, gradually, it gets harder. PIs start to slip. Estimates get less reliable. The frustration that ends up in online forums, the sense that SAFe promised more than it delivered, is often rooted in technical decay that nobody measured and nobody addressed.
The uncomfortable truth is that software quality is not just a team concern. It is a long-term business value. When it is treated as such, owned at the ART level, balanced against feature delivery, and steered deliberately, the ART becomes more predictable. When it is not, the slowdown is only a matter of time.
What to measure in your SAFe agile framework implementation
So what does “measure quality” actually mean in practice? ISO/IEC 25010 defines software quality across multiple characteristics. Some of those apply to running systems: reliability, performance. However, given today’s cybersecurity threat landscape, security and open-source risk should also be measured as often as possible. This gives us four aspects that should be measured continuously:
- Maintainability: how fast the code can be understood, adapted, and tested.
- Architecture: how many teams can work in isolation, and how easily the application can be functionally extended.
- Security: whether potential weaknesses and vulnerabilities exist in the code.
- Open source: whether the software used contains vulnerabilities or license risk.
These four dimensions need a clear owner at each level.
- The Release Train Engineer (RTE) should own overall measurement and outcomes across the ART.
- The System Architect sets the targets.
- The teams take responsibility for achieving them.
The sections below explain what that looks like in practice.
PI Planning
Before PI Planning begins, the RTE should verify that the Architect has access to current baseline measurements and has defined targets accordingly. Quality cannot be an afterthought in the planning agenda. The Architect needs to present the current state, explain the targets, and give the ART a clear rationale for what will need to be prioritized.
That is how quality targets make it into PI Objectives and contribute concretely to the SAFe implementation roadmap.
Completing the ART Planning Board view
A strong element of the SAFe framework is the ART Planning Board used during PI Planning, showing “dependencies” between features and teams:
The lines between teams and features are called dependencies, making it clear that the work of one team depends on the earlier work of another team. In other words, the program board’s main job is to show when and where teams cannot work in isolation and when careful coordination is necessary. Otherwise, delays and possibly confusion occur.
While this tool is very powerful and gives management the option to reduce the dependencies to improve the flow of the ART. There’s something important, but it does not show: What is happening at the technical layer?
So, while SAFe maps functional dependencies. The architecture underneath remains invisible.
Architecture quality
Software architecture describes how a system is structured: how many components it has, and which of those components talk to each other. Those connections are dependencies too, technical ones, and they matter just as much to planning as the functional kind.
Take a simple example. If team A is working on the platform while team B works on extensions, and the platform has a direct dependency on the extensions layer, Team A cannot move freely. That dependency belongs on the ART Planning Board. Without it, teams discover the constraint mid-PI, and by then, the damage to delivery is done.
Architecture also changes over time, and not always by design. Most organizations start a SAFe implementation with a documented architecture. Development begins faithfully. But the implemented architecture tends to drift from the original over time. Components get coupled in ways the document never intended, and the technical layer becomes more complex.
Here we see an example of a much more complicated picture with multiple connections. When four individual teams are working across a system that looks like this, the dependencies between them are no longer as obvious. Missing that complexity in the planning board means the PI will find it instead, causing delay and potentially unmet objectives as a result.
Team ownership
The teams should take ownership of the quality of the software they work on, meaning that they should have visibility into the current state and be accountable for improvement toward the target.
That starts with estimation. When a team is working in an area of the codebase with poor maintainability or tangled architecture, the effort involved is higher, and the story points should reflect that.
It is best practice to use Continuous Integration (CI) to provide early, automated feedback on what the teams are working on. This way, teams can improve code quality before they mark a story or task as complete.
Definition of Done
The Definition of Done for the teams should include a Boy Scout Principle: leave code quality better than how you found it when working with existing code, and adhere to the team’s coding standards for new code.
Team Retrospective
During the Team’s Retrospective, the team should review the quality of the software they worked on and reflect on whether they achieved the target.
Completing the Innovation and Planning iteration
The PI closes with the IP iteration and most importantly an Inspect and Adapt event, a structured review of how the ART performed, covering both qualitative and quantitative dimensions.
Renovate in the IP iteration
The last iteration in the PI gives room for innovation and research. This time can also be used for larger technical quality improvements that did not fit in the regular iterations. Using this PI-over-PI improves the fitness of the whole ART.
System Demo
During the System Demo, the ART software quality should also be presented. This makes management and Business Owners aware of the importance and current state. It also shows whether the teams collectively contribute towards the set targets.
Evaluating the PI
Quality metrics belong in the quantitative review alongside velocity and predictability. Trends on maintainability, architecture, security, and open-source risk across the PI tell a story. So does the balance between feature work and technical investment. If the ART delivered everything it committed to, but quality declined, that is worth naming.
When conducting a problem workshop, quality should be on the table as a potential root cause. The RTE is well placed to lead that conversation, coaching Scrum Masters to bring it into their teams’ thinking.
For the improvement backlog, software quality-related items should also be included next to the typical process items.
RTE and system architect ownership
Ownership of the actual Built-In Quality of the ART is shared between the RTE and the System Architect.
The RTE is responsible for the Flow of the ART. Unmanaged software quality negatively impacts ART Flow. So, the RTE has a vested interest in taking ownership of software quality measurement and improvement to guard ART Flow.
The System Architect owns the quality of the solution itself. That means producing quality reports for the PI evaluation in Inspect and Adapt, giving the rest of the ART and management a clear view of where the system stands.
Solution Train and portfolio management
Everything above applies at the ART level. But the same principle extends further, and the stakes get higher as you scale.
The importance of software quality measurement for effective SAFe execution extends beyond a single ART. If a Solution Train shares a software solution across ARTs, the dependency mapping becomes even more important. Delays that emerge during execution, rather than surfacing in planning, are both costly and hard to unwind.
Software quality measurement is equally necessary in Lean Portfolio Management. Making investment and prioritization decisions should also take into account the required level of technical effort. Incorporating these measurements gives a more realistic view of the time and investment needed to materialize a portfolio epic.
Better enterprise agility through software quality governance
Incorporating software quality measurement improves the SAFe practice as a whole. Firstly, cross-team dependencies surface during planning and not during execution. PI Planning therefore improves, also due to better team plans, as their estimates are grounded in actual software health. This remedies the gradual slowdown occurring PI-over-PI and leads to higher PI predictability.
Incorporating quality measurement into your agile transformation roadmap pays off in predictability, trust, and the ability to make explicit trade-offs. As a result, leadership;
- Gains confidence in a more predictable ART.
- Finally has the visibility to make an informed choice between delivering more features and investing in the technical foundation.
Sigrid®, our software portfolio governance platform, addresses this gap directly: making it easy to establish a baseline, set targets, provide early feedback to developers, and give the RTE and management insight across the ART.
At Software Improvement Group, I speak with clients regularly who are navigating exactly these challenges, and there is often more confusion around SAFe implementation than people expect. If you want to understand what this means for your organization, feel free to reach out. We would love to help.
About the author
Ravish Gopal
Ravish is Solutions & Advisory Director at SIG.
He helps boards and senior executives close the gap between technology ambition and governance reality. With two decades of international experience spanning M&A due diligence, AI governance, and enterprise transformation, he specialises in the questions that matter most but get asked too late.
Frequently asked questions
What is the SAFe agile framework?
SAFe (the Scaled Agile Framework) is a set of organizational and workflow patterns for implementing agile practices at enterprise scale. It provides structure for aligning cross-functional teams across multiple levels: team, program, large solution, and portfolio. First released in 2011 and now at version 6.0, it is the most widely adopted scaling framework globally, used by 26% of organizations practising scaled agile according to the State of Agile Report.
What is an agile release train (ART)?
An agile release train is the primary organizational construct in SAFe. It is a long-lived team of agile teams (typically 50 to 125 people) that plans, commits, and delivers together on a common cadence called the Program Increment (PI). The ART aligns teams around a shared mission and synchronizes their work through PI Planning, the ART Planning Board, and regular Inspect and Adapt cycles.
Why do SAFe agile transformations slow down over time?
The most common and overlooked reason is unmanaged technical debt. SAFe’s Built-in Quality practice acknowledges code quality and architecture but does not define how to measure them or integrate measurement into the ART’s planning and governance cycles. Without visibility into software quality, teams optimize for shipping features while technical debt accumulates invisibly, slowing delivery, increasing defect rates, and reducing PI predictability over time.
What should be measured to achieve built-in quality in SAFe?
Four dimensions should be measured continuously across the ART: maintainability (how fast code can be understood, adapted, and tested), architecture quality (how independently teams can work and how easily the system can be extended), security (whether vulnerabilities exist in the code), and open-source risk (whether third-party components carry vulnerabilities or license exposure). These map to the characteristics defined in ISO/IEC 25010 and should be integrated into PI Planning, team retrospectives, and the Inspect and Adapt cycle.
How does technical debt affect agile transformation roadmap planning?
Technical debt makes estimates unreliable and delivery unpredictable. When teams plan features without visibility into the health of the underlying codebase, they consistently under-estimate effort, and the gap widens as debt compounds. Incorporating software quality measurement into your agile transformation roadmap gives teams a realistic baseline, enables better PI Planning, and allows leadership to make explicit trade-offs between feature delivery and technical investment rather than discovering the cost mid-PI.
What is a SAFe implementation roadmap?
A SAFe implementation roadmap is the sequence of steps an organization follows to adopt the Scaled Agile Framework, from training and launching the first agile release train through to full portfolio-level governance. Scaled Agile provides a reference implementation roadmap covering training, ART launch, and portfolio governance. A common gap in most implementations is the absence of software quality measurement. Without it, the ART lacks the visibility needed to steer on technical health alongside functional delivery.
How does software quality measurement support enterprise agility?
Enterprise agility depends on the ability to deliver reliably at scale, adapt quickly to change, and make confident investment decisions. All three are undermined by unmanaged technical debt. When software quality is measured continuously and integrated into planning and governance cycles, cross-team dependencies surface earlier, estimates become more accurate, and leadership gains the visibility needed to balance feature delivery with technical investment, the foundation of sustainable enterprise agility.