Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.”

—W. Edwards Deming

Build incrementally with fast, integrated learning cycles

—SAFe Principle#4


Built-in Quality

Built-in Quality practices ensure that each Solution element, at every increment, meets appropriate quality standards throughout development.

The enterprise’s ability to deliver new functionality with the fastest sustainable lead time and to be able to react to rapidly changing business environments is dependent on solution quality. So, it should be no surprise that Built-in Quality is one of the four Core Values of SAFe. But built-in quality is not unique to SAFe. Rather, it is a core principle of the Lean-Agile mindset, where it helps avoid the cost of delays associated with recall, rework, and defect fixing. The built-in quality philosophy applies systems thinking to ‘optimize the whole,’ ensuring a fast flow across the entire value stream, and makes quality everyone’s job.

The Agile Manifesto is focused on quality as well: “Continuous attention to technical excellence and good design enhances agility.”[1]

Many of the practices in this article are inspired and described by eXtreme Programming (XP). These practices help Agile teams ensure that the solutions they build are high in quality, can readily adapt to change and are architected for testing, deployment and recovery. The collaborative nature of these practices, along with a focus on frequent validation, creates an emergent culture in which engineering and craftsmanship are key business enablers.

The goals and principles of built-in quality are the same for software, hardware and firmware. However, the work physics and economics are somewhat different for hardware and firmware, requiring a different set of practices. They include a more intense focus on modeling and simulation, as well as more exploratory early Iterations, more design verification, and frequent system-level integration.


When Enterprises need to respond to change, software and systems built on good technical foundations are easier to change and adapt. For a large solution this is even more critical, as the cumulative effect of even minor defects and wrong assumptions can create unacceptable consequences.

Achieving high-quality systems is serious work that requires ongoing training and commitment, but the investment is warranted by its many business benefits: higher customer satisfaction, improved velocity and delivery predictability, better system performance, improved ability to innovate and scale, and meet compliance requirements.

The following sections summarize the recommended practices for achieving built-in quality for software, hardware and firmware:

Software Practices

SAFe’s software quality practices—many of which are inspired by Extreme Programming (XP)—help Agile teams ensure that the solutions they build are high quality and adaptable to change. The collaborative nature of these practices, along with a focus on frequent validation, creates an emergent culture in which engineering and craftsmanship are key business enablers. These practices include:

  • Continuous Integration (CI)CI is the practice of merging the code from each developer’s workspace into a single main branch of code, multiple times per day. This lessens the risk of deferred integration issues and their impact on system quality and program predictability. Teams perform local integration at least daily. But to confirm that the work is progressing as intended, full system-level integration should be achieved at least one or two times per iteration.
  • Test-first – is a set of practices that encourages teams to think deeply about intended system behavior before implementing code.  Test-first methods can be further divided into two categories:  1)  Test-Driven Development (TDD), where developers write an automated unit test first, run the test to observe the failure, and then write the minimum code necessary to pass the test. 2) Acceptance Test-Driven Development (ATDD), where story and feature acceptance criteria are expressed as automated acceptance tests, which can be run continuously to ensure continued conformance as the system evolves.
  • Refactoring – is “a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.”[2] A key enabler of emergent design, refactoring is essential for agility. To maintain system robustness, teams continuously refactor code in a series of small steps, providing a solid foundation for future development.
  • Pair work – For many, pair programming is too extreme. However, in practice, there are a number of different styles of pairing work done by Agile Teams. Each has value on its own, and many can be used in combination. Some teams follow pair programming standards for all code development, as prescribed by XP. Others pair developers and testers on a Story; each reviews the other’s work as the story moves to completion. Still others prefer more spontaneous pairing, with developers pairing for critical code segments, refactoring of legacy code, development of interface definition, and system-level integration challenges. Pair work is also a great foundation for refactoring, CI, test automation, and collective ownership.
  • Collective ownership – collective ownership invites shared understanding and responsibility of a solution by all team members. “Any developer can change any line of code to add functionality, fix bugs, improve designs, or refactor.”[3] It’s particularly critical as big systems have big code bases, and it’s less likely that the original developer is still on the team or program. And even if they are, waiting for “someone else” to make a change is a handoff and a certain delay.
  • Agile architecture – enables incremental value delivery by balancing emergent design with intentional architecture.  Agile architecture is where the design and architecture of a system is built concurrent with new business functionality. This avoids Big Up-Front Design (BUFD) and the start-stop-start nature of a phase-gated approach. Architectural Runway is one of the tools SAFe uses to implement the concepts of Agile Architecture, which consists of the existing code, components and technical infrastructure necessary to support implementation of prioritized, near-term features, without excessive redesign and delay

Hardware and Firmware Practices

With respect to firmware and hardware, errors and unproven assumptions can introduce a much higher cost of change and rework over time, as compared to software, as is illustrated in Figure 1.

Figure 1. Relative cost of change over time for software, firmware, and hardware [4]
Although the cadence of iterations and Program Increments, and quality expectations, are largely the same for hardware, firmware and software, the early iterations are particularly critical for hardware and firmware because the cost of change has not yet reached the higher levels. This higher cost of change for hardware and firmware drives developers of complex systems to a number of practices that ensure quality is built-in during solution development:

  • Exploratory, early iterations – as highlighted in reference [6], even when building a Harley-Davidson, where it takes a fairly complete team to road test a new motorcycle, more frequent design cycles accelerate knowledge and reduce the risk and cost of errors discovered later.
  • Model-based systems engineering – this is the application of modeling and tools to the requirements, design, analysis, and verification activities in solution development. Model-based systems engineering provides a cost-effective way to learn about system characteristics prior to and during development. It helps manage the complexity and cost of large-system documentation.
  • Set-based design – the practice of Set-based design maintains multiple requirements and design options for a longer period in the development cycle. Empirical data is used to narrow focus based on the emergent knowledge.
  • Frequent system integration – For many software solutions, Continuous Integration is an achievable goal. However, systems with physical components—molds, printed circuit boards, mechanisms, fabricated parts, and so on—evolve more slowly and can’t be integrated and evaluated every day. However, that can’t be an excuse for late and problematic integration. That is why builders of complex and embedded systems shoot for early and frequent integration of components and subsystems.
  • Design verification – Even frequent integration is not enough. First, it can occur too late in the process because of the dependencies of the availability of various system components. Second, it can’t predict and evaluate all potential usage and failure scenarios. To address this, builders of high assurance systems perform design verification to ensure that a design meets the solution intent. This may include specification and analysis of requirements between subsystems, worst-case analysis of tolerances and performance, Failure Mode Effects Analysis (FMEA), modeling and simulation, full verification and validation, and traceability.

The Role of DevOps and Continuous Delivery Pipeline

From planning through delivery, the DevOps mindset and practices help improve the collaboration between Development and IT Operations by developing and automating a Continuous Delivery Pipeline.  This collaboration and shift in culture along with automation, increases the frequency and quality of deployments. In SAFe, this pipeline consists of four elements: Continuous Exploration, Continuous Integration, and Continuous Deployment and Release on Demand.

DevOps simply recognizes that manual processes are the enemy of fast value delivery, high quality, improved productivity, and safety. Automation also enables the fast creation of repeatable development and test environments and processes, which are self-documenting and, therefore, easier to understand, improve, secure, and audit. The entire continuous delivery pipeline is automated to achieve a fast, Lean flow of value with the highest possible quality.

The Role of the Quality Management System (QMS)

Compliance refers to a strategy, and a set of activities and artifacts that allow teams to apply Lean-Agile development methods to build systems that have the highest possible quality, while simultaneously assuring they meet any regulatory, industry, or other relevant standards.

To satisfy compliance requirements, organizations must demonstrate that their system meets its intended purpose, and has no unintended consequences that might cause harm. They must also develop the objective evidence required to prove that the system conforms to those standards. To that end, SAFe enterprises that build high assurance systems define their approved practices, policies, and procedures in a Lean Quality Management System (QMS). These systems are intended to ensure that development activities and outcomes comply with all relevant regulations and quality standards, as well as providing the required documentation to prove it.

Please refer to the Compliance article for more information.

Learn More

[1] Manifesto for Agile Software Development.

[2] Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley Professional, 1999.