Scaling Agile and Managing Complex Portfolios

Introduction

Agile methods were initially designed for a small, cross-functional team working closely with a customer. Scaling becomes necessary when a product, platform, or enterprise requires many teams, specialist capabilities, shared architecture, regulatory controls, or coordinated investment. Scaling, however, is not simply the multiplication of Scrum teams. It introduces coordination costs, architectural dependencies, competing priorities, governance obligations, and portfolio-level economic decisions.

The central management challenge is to increase organisational capacity without replacing empirical learning with prediction, local ownership with command-and-control, or customer value with activity measurement. A scaled Agile system should therefore be judged not by the number of ceremonies it adopts, but by whether it improves the flow of valuable, usable outcomes while maintaining transparency, inspection, adaptation, quality, and sustainable working practices.

This chapter critically compares Scrum of Scrums, Nexus, Large-Scale Scrum (LeSS), the Scaled Agile Framework (SAFe), and disciplined hybrid models. It also examines coordination across teams, architecture and dependencies, funding, portfolio priorities, governance, metrics, and the conditions under which each approach is appropriate.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain why scaling Agile creates distinct organisational and technical problems.
2. Compare Scrum of Scrums, Nexus, LeSS, SAFe, and disciplined hybrid models.
3. Design mechanisms for coordinating teams, dependencies, architecture, and integration.
4. Evaluate portfolio prioritisation and funding approaches using economic and strategic reasoning.
5. Distinguish useful governance from bureaucratic control.
6. Diagnose common failure modes in scaled Agile transformations.
7. Recommend a context-sensitive scaling design while preserving Agile principles.

1. Why Agile Scaling Is Difficult

A single Scrum team can often maintain a shared Product Backlog, one Product Owner, one Definition of Done, and a short feedback loop. At scale, several teams may work on one product or on a connected product ecosystem. Complexity arises from at least five sources:

• Coordination complexity: teams must align goals, sequencing, interfaces, and releases.
• Technical complexity: components may be tightly coupled, and integration may occur late.
• Organisational complexity: teams may report through functional departments with conflicting incentives.
• Portfolio complexity: multiple products compete for scarce people, capital, suppliers, and executive attention.
• Institutional complexity: security, safety, privacy, procurement, audit, and regulatory obligations affect delivery.

Scaling also creates a structural tension. Local teams need autonomy to make rapid decisions, whereas the enterprise needs coherence in architecture, investment, risk, and strategic direction. Effective scaling does not eliminate this tension; it makes decision rights explicit and places decisions at the lowest competent level.

A useful distinction is between product scaling and organisational scaling. Product scaling concerns multiple teams contributing to a common product or value stream. Organisational scaling concerns multiple products, business units, portfolios, and governance systems. A framework that works for the first may be unnecessarily elaborate—or insufficient—for the second.

2. Principles for Scaled Agile Design

Several principles provide a basis for evaluating scaling approaches.

2.1 One product goal and integrated increments

Teams should understand the outcome they are jointly pursuing. If each team optimises a component without a shared product goal, local progress can conceal system-level failure. A potentially releasable integrated increment is stronger evidence than completed tasks or team-level velocity.

2.2 Transparency of work and dependencies

Dependencies should be made visible early, preferably through product decomposition, team interaction mapping, dependency boards, integrated planning, and frequent integration. Visibility is not an end in itself; it must support decisions and adaptation.

2.3 Decentralised execution with strategic alignment

Strategic goals, investment boundaries, architectural guardrails, and risk tolerances may be set centrally. The detailed design and sequencing of work should generally remain with the teams closest to the problem.

2.4 Flow over utilisation

Maximising the utilisation of every specialist can increase queues and delay. A system with some spare capacity can respond more rapidly and reduce the cost of blocked work. Work-in-progress limits, smaller batches, and cross-functional teams often improve total throughput.

2.5 Technical excellence as a scaling mechanism

Continuous integration, automated testing, observability, modular architecture, trunk-based development, and continuous delivery reduce the need for coordination meetings. Technical practices are therefore not merely engineering preferences; they are mechanisms of organisational scalability.

2.6 Governance by evidence

Governance should inspect outcomes, risk, quality, customer impact, and economic assumptions. It should not rely exclusively on conformance to plans, percentage completion, or utilisation reports.

3. Principal Scaling Approaches

3.1 Scrum of Scrums

A Scrum of Scrums is a coordination pattern in which representatives from several Scrum teams meet to discuss cross-team impediments, dependencies, integration, and near-term risks. It is not, by itself, a complete scaling framework. The representatives may be Scrum Masters, developers, or other people selected according to the issue being addressed.

Its strengths are simplicity, low adoption cost, and compatibility with existing Scrum. It is useful when teams are relatively independent and only a modest amount of coordination is needed. Its weaknesses are equally important: representatives can become status reporters; decisions may be deferred to the meeting; and the pattern does not define product ownership, portfolio governance, architecture, or integrated planning.

A mature Scrum of Scrums focuses on questions such as:

• What impediment prevents another team from progressing?
• What integration or interface change may affect other teams?
• What decision must be made, by whom, and by when?
• What evidence shows that the integrated product is improving?

It should not become a manager-only meeting or a substitute for direct team-to-team collaboration.

3.2 Nexus

Nexus is a framework for developing and integrating a product through approximately three to nine Scrum teams. It retains Scrum while adding a Nexus Integration Team, cross-team refinement, Nexus Sprint Planning, a Nexus Daily Scrum, and a Nexus Sprint Review. Its defining concern is the production of an integrated increment.

Nexus is particularly valuable where teams contribute to one product and integration risk is significant. It encourages a single Product Backlog, a common Sprint, shared quality expectations, and explicit attention to dependencies. The Nexus Integration Team supports integration but should not become a permanent separate testing department that receives unfinished work at the end of the Sprint.

The framework is comparatively lightweight, but its effectiveness depends on technical capability. If teams cannot integrate frequently, additional events will not solve the underlying problem.

3.3 Large-Scale Scrum (LeSS)

LeSS extends Scrum with the principle of “more with less”: fewer specialised coordination roles, fewer management layers, and a strong emphasis on feature teams. A single Product Backlog, one Product Owner, one Definition of Done, and a common product focus are central. LeSS Huge introduces additional structures for larger environments while retaining the same emphasis on product and organisational simplification.

LeSS seeks to reduce organisational fragmentation by redesigning teams around customer-facing features rather than technical components. This can improve learning and reduce hand-offs, but it may require difficult changes to departments, career paths, architecture, and specialist identities.

LeSS is most appropriate where the organisation is willing to simplify rather than layer new coordination mechanisms over an existing functional hierarchy. It is less suitable when legal, safety, or business structures require extensive formal separation—although it can still provide useful design principles within those constraints.

3.4 SAFe

SAFe provides a broad operating model covering team, program, large-solution, and portfolio levels. Common elements include Agile Release Trains, Program Increments, roles such as Release Train Engineer and Product Management, Lean Portfolio Management, architecture guidance, portfolio epics, and participatory budgeting.

Its major advantage is coverage. SAFe offers explicit structures for coordinating many teams, suppliers, architecture, compliance, strategy, and investment. This can be valuable in a large enterprise moving from project-based funding and annual planning.

Its principal risks are complexity and mechanistic adoption. Organisations may implement ceremonies, roles, and boards while retaining annual command-and-control budgeting, component teams, stage-gate approvals, and output-based measurement. In that case, SAFe becomes an additional bureaucracy rather than an Agile operating model. SAFe should therefore be treated as a configurable body of practices, not as a universal prescription.

3.5 Disciplined hybrid models

A disciplined hybrid combines practices from multiple approaches, but it is not an arbitrary collection of ceremonies. It begins with a defined problem, establishes design principles, specifies decision rights, and tests whether each practice improves flow, quality, learning, or strategic coherence.

For example, an organisation might use Scrum teams, Nexus-style integrated reviews, LeSS-inspired feature teams, and SAFe-like portfolio guardrails. Such a model can fit a complex environment, but it creates a risk of conceptual inconsistency. Teams may face multiple backlogs, overlapping roles, contradictory cadences, or duplicate planning events.

A hybrid model should document:

1. the product or value-stream boundary;
2. the authoritative backlog and prioritisation authority;
3. the cadence and purpose of each event;
4. the Definition of Done and integration standard;
5. decision rights for product, architecture, risk, and funding;
6. measures used to inspect outcomes; and
7. the process for removing practices that do not create value.

4. Comparative Evaluation

No framework is inherently “more Agile” in every context. The critical question is whether the chosen design reduces delay and improves learning without imposing unnecessary control.

5. Coordinating Teams, Dependencies, and Architecture

5.1 Dependency management

Dependencies are relationships in which one team cannot complete or validate work without another team, system, supplier, decision, or external approval. They should be classified because different types require different responses:

• Knowledge dependency: one team needs information or expertise.
• Flow dependency: work must occur in a particular sequence.
• Resource dependency: scarce people or environments are shared.
• Technical dependency: interfaces or components must change together.
• External dependency: a supplier, regulator, customer, or platform is involved.

The best solution is often to remove the dependency through team redesign, modular architecture, automation, or a clearer product boundary. Scheduling and escalation are secondary responses. A dependency board can expose relationships, but it does not reduce them by itself.

5.2 Architecture and emergent design

Agile architecture is neither “no architecture” nor complete up-front design. It combines intentional decisions about high-cost or difficult-to-reverse constraints with emergent design based on validated learning. Examples of intentional decisions include safety boundaries, data protection controls, integration standards, and technology constraints. Examples of emergent decisions include refinements to user interaction, internal module structure, or implementation details revealed through experiments.

Architecture should be represented in working software, automated tests, operational telemetry, and explicit decision records. An Architecture Decision Record can state the context, decision, alternatives, consequences, and review conditions. This supports organisational memory without requiring a large design document before learning begins.

5.3 Cadence and synchronisation

A shared cadence can simplify integration and forecasting, but synchronisation should not force every team to perform identical work. Teams may plan within a common Sprint while retaining local refinement practices. The larger the system, the more important it is to separate coordination cadence from delivery cadence: portfolio reviews may be quarterly, product planning may occur every few weeks, and deployment may occur many times per day.

5.4 Flow and Little’s Law

A useful relationship for analysing queues is Little’s Law:

Here, L is the average work in progress, measured in work items; λ is the average throughput, measured in items per unit of time; and W is the average cycle time, measured in the same unit of time. The relationship assumes a stable system over the period analysed, with work entering and leaving at approximately the same average rate.

For example, if a value stream contains an average of 24 items in progress and completes 6 items per week, the average cycle time is:

This is not a promise that every item takes four weeks. It is a long-run average. If an organisation wants to reduce cycle time while throughput remains stable, reducing work in progress is a mathematically coherent intervention. Adding more simultaneous projects may therefore worsen, rather than improve, delivery speed.

6. Portfolio Prioritisation and Funding

6.1 From projects to persistent value streams

Traditional project funding often creates temporary teams, annual business cases, and incentives to complete scope even when expected value has declined. Product-oriented funding assigns persistent capacity to a product, customer journey, platform, or value stream. Investment can then be adjusted as evidence changes.

This does not mean that all initiatives receive unlimited funding. It means that funding decisions are made around outcomes, capacity boundaries, risk, and strategic hypotheses rather than merely around a fixed list of activities.

6.2 Cost of delay and economic sequencing

Cost of Delay (CoD) represents the economic impact of postponing a decision or delivering later. A simplified weighted-shortest-job-first score is often expressed as:

CoD may be estimated as the sum of relative user-business value, time criticality, and risk reduction or opportunity enablement. Job Size is a relative estimate of the work required. The score is a prioritisation aid, not a claim of precise financial truth. It is most useful when estimates are comparable, assumptions are visible, and decision-makers revisit them as evidence changes.

Suppose three initiatives have the following relative estimates:

Initiative B has the highest relative WSJF and would normally be considered first, subject to legal obligations, technical sequencing, capacity, and risk constraints. The calculation does not override mandatory compliance work or create certainty where the inputs are unreliable.

6.3 Portfolio governance

Effective portfolio governance answers four questions:

1. Which strategic outcomes matter?
2. How much capacity and risk capital can be allocated?
3. What evidence supports continuing, changing, or stopping an initiative?
4. Who has authority to make the decision?

Useful portfolio measures include outcome achievement, lead time, product quality, customer impact, operational risk, predictability ranges, and investment allocation. The number of initiatives started, hours booked, or features completed may be reported, but these are weak proxies for value.

7. Governance, Risk, and Compliance

Agile delivery does not remove governance obligations. It changes how evidence is produced and reviewed. A regulated organisation can embed controls in the Definition of Done, automated pipelines, traceability records, threat modelling, peer review, segregation of duties where genuinely required, and independent assurance at risk-based points.

Governance becomes harmful when every decision requires central approval, when compliance evidence is reconstructed after delivery, or when documentation is valued independently of its decision-making purpose. Governance becomes weak when teams cannot explain how risks are identified, controlled, monitored, and escalated.

Important ethical issues include:

• transparent prioritisation when benefits and harms are distributed unevenly;
• protection of personal and sensitive data;
• accessibility and non-discrimination in product design;
• responsible use of predictive analytics and AI;
• avoidance of performance metrics that encourage gaming or unsafe speed;
• honest communication of uncertainty to sponsors and customers.

AI tools may assist with backlog analysis, dependency discovery, test generation, forecasting, and technical documentation. However, generated outputs require human review, especially where confidential data, intellectual property, safety, discrimination, or regulatory accountability is involved. AI should reduce administrative effort and improve learning, not become a mechanism for surveillance or automated prioritisation without accountable judgment.

8. Measuring a Scaled Agile System

Metrics should be interpreted as signals within a system, not as targets to be optimised in isolation. A balanced measurement system may include:

• Flow: lead time, cycle time, throughput, work in progress, blocked time.
• Quality: escaped defects, change failure rate, rework, automated test reliability.
• Product outcomes: adoption, task success, retention, revenue, cost reduction, safety outcomes, or customer satisfaction, depending on the product.
• Team health: sustainable workload, psychological safety, learning, and capability development.
• Portfolio health: investment allocation, strategic outcome progress, risk exposure, and initiative survival decisions.

Metrics can distort behaviour. For example, rewarding teams for velocity may encourage inflated estimates; rewarding utilisation may increase queues; rewarding feature counts may promote low-value scope. A good metric has a clear decision use, a known limitation, and a review process for unintended consequences.

9. Applied Case: Northstar Health Services

The following is a fictional illustrative case.

Background

Northstar Health Services is developing a digital referral and appointment platform used by patients, clinicians, laboratories, and insurers. Eight teams work across mobile applications, clinical workflows, identity, payments, analytics, and infrastructure. The organisation operates under privacy and healthcare regulations and relies on two external suppliers.

Problem

The teams use Scrum, but releases are delayed. The identity team is a bottleneck, test environments are shared, and the analytics team often discovers breaking interface changes late. Executives respond by adding a weekly status meeting and requiring each team to provide a percentage-complete report. Local velocity rises, but integrated releases become less reliable.

Analysis

The problem is not a lack of meetings. The system has component teams, a shared environment, late integration, unclear decision rights, and project-based funding that encourages each department to protect its own backlog. The percentage-complete measure hides queue time and integration risk.

Approach

Northstar adopts a disciplined hybrid design:

1. The eight teams are grouped around two customer-oriented value streams, while a small platform team provides enabling services.
2. A single product goal and integrated Product Backlog are established for each product boundary.
3. Nexus-inspired cross-team refinement and integrated Sprint Reviews replace the status meeting.
4. Teams adopt a common Definition of Done, trunk-based development, contract testing, and automated deployment to disposable test environments.
5. Architecture decisions are recorded and reviewed by a lightweight architecture group; the group sets guardrails but does not approve ordinary implementation decisions.
6. Funding moves from annual component projects to quarterly capacity envelopes for the two value streams, with explicit risk and compliance reserves.
7. Portfolio review uses outcome evidence, cost of delay, operational risk, and customer research to continue, change, or stop initiatives.
8. Measures shift from velocity and percentage complete to cycle time, blocked time, deployment reliability, patient task success, and unresolved privacy risk.

Outcome

After several planning cycles, Northstar reduces cross-team hand-offs and identifies integration problems earlier. Delivery performance improves gradually rather than immediately because teams must first repay technical debt and redesign interfaces. Executives gain better visibility into risk and learning, while teams gain greater authority over sequencing and design.

Learning points

The case demonstrates that scaling is a system-design problem. A framework label cannot compensate for component-team boundaries, weak technical practices, or inappropriate funding. The hybrid is disciplined because every mechanism has a stated purpose, decision owner, and inspection point. It remains Agile because teams deliver integrated increments, priorities are revisable, and investment follows evidence.

10. Common Failure Modes and Best Practices

Failure modes

• Ceremony multiplication: adding coordination events without reducing dependencies.
• Framework cargo cult: adopting names, roles, and artefacts without the underlying principles.
• Component ownership: assigning teams to technical layers and creating queues between them.
• Proxy Product Owners: giving product roles responsibility without decision authority.
• Annual commitment disguised as Agile planning: fixing scope, date, and budget while calling the plan iterative.
• Velocity comparison: treating a local estimation measure as an enterprise productivity metric.
• Architecture as an approval gate: delaying delivery while central experts review ordinary decisions.
• No integrated increment: declaring success when teams complete their own pieces.
• Ignoring suppliers: planning as if external work has the same cadence and controllability as internal work.

Best practices

Start with the product and value-stream boundary, not with a framework diagram. Make the smallest organisational change that addresses the dominant constraint. Invest in technical integration early. Establish one authoritative source of priorities. Define decision rights and escalation paths. Use funding that permits reprioritisation. Review metrics for behavioural effects. Treat compliance as a design constraint and continuous evidence activity. Remove practices that do not improve outcomes.

Chapter Summary

Scaling Agile involves coordinating a network of teams, technologies, stakeholders, suppliers, and investments while preserving empirical learning and local ownership. Scrum of Scrums is a lightweight coordination pattern; Nexus concentrates on integrated delivery across several Scrum teams; LeSS emphasises organisational simplification and feature teams; SAFe offers extensive structures for enterprise coordination, architecture, governance, and portfolio management; and disciplined hybrids tailor mechanisms to context while making their design logic explicit.

Successful scaling reduces dependencies, strengthens technical integration, clarifies product and portfolio decision rights, and funds persistent value streams rather than merely temporary projects. Cost of Delay and WSJF can support sequencing, but their estimates are relative and must not replace judgment. Little’s Law shows why excessive work in progress increases cycle time when throughput is stable. Governance should generate useful evidence for risk and strategic decisions, while metrics should focus on flow, quality, outcomes, and sustainable capability. The decisive test of a scaled Agile design is whether it enables better decisions and more valuable integrated outcomes—not whether it conforms to a particular framework.

Key Terms

Agile scaling: Extending Agile principles and practices across multiple teams, products, or organisational levels.

Scrum of Scrums: A coordination pattern in which representatives of Scrum teams address cross-team issues and dependencies.

Nexus: A framework for coordinating multiple Scrum teams developing and integrating one product.

LeSS: Large-Scale Scrum, an approach emphasising product focus, feature teams, and organisational simplification.

SAFe: Scaled Agile Framework, an enterprise framework covering team, program, solution, and portfolio concerns.

Disciplined hybrid: A deliberately designed combination of practices selected to address a defined context.

Integrated increment: A usable product increment in which the contributions of participating teams work together.

Value stream: The sequence of activities and capabilities that delivers value to a customer or stakeholder.

Dependency: A relationship in which one activity, team, or decision relies on another.

Feature team: A cross-functional team capable of delivering customer-valued functionality across relevant technical layers.

Definition of Done: Shared criteria specifying when work is complete and meets the required quality standard.

Cost of Delay: The economic or strategic impact associated with delaying an outcome or decision.

WSJF: Weighted Shortest Job First, a relative prioritisation method using Cost of Delay divided by Job Size.

Little’s Law: The queueing relationship L = λW, linking work in progress, throughput, and cycle time in a stable system.

Portfolio governance: Decision-making concerning strategy, investment, risk, outcomes, and capacity across initiatives.

Architecture runway: Technical capability or infrastructure prepared to support near-term functionality and evolution.

Flow efficiency: The proportion of elapsed time in which work is actively progressing rather than waiting.

Empirical governance: Governance based on transparent evidence, inspection, adaptation, and explicit risk decisions.

Review Questions

Short Answer Questions

1. Why is scaling Agile more than multiplying the number of Scrum teams?
2. What is the principal purpose of a Nexus Integration Team?
3. State one strength and one limitation of Scrum of Scrums.
4. What assumptions apply when using Little’s Law in delivery analysis?
5. Why can velocity be a poor enterprise productivity metric?

Long Answer Questions

1. Critically compare Scrum of Scrums, Nexus, LeSS, and SAFe for a regulated organisation developing one integrated product.
2. Explain how team topology and technical architecture influence dependency management at scale.
3. Discuss the advantages and risks of moving from project funding to persistent value-stream funding.
4. Design a governance model that provides regulatory assurance without imposing central approval on every team decision.
5. Explain why disciplined hybrid models can be useful and identify controls needed to prevent them becoming incoherent.

Analytical / Application Questions

1. A value stream has 40 items in progress and throughput of 8 items per month. Estimate its average cycle time using Little’s Law. What operational intervention would you investigate first if cycle time is unacceptable?
2. Three initiatives have Cost of Delay and Job Size estimates of A: 24 and 8, B: 15 and 3, and C: 30 and 15. Calculate each WSJF score and recommend a sequencing order, stating at least two constraints that could modify the recommendation.
3. An enterprise has ten component teams, annual project budgets, late integration, and a requirement for frequent releases. Recommend whether to begin with Scrum of Scrums, Nexus, LeSS, SAFe, or a disciplined hybrid. Justify the recommendation through product boundaries, dependencies, funding, governance, and technical practices.

Multiple Choice Questions with Answers

Question 1

Which characteristic most clearly distinguishes Nexus from a basic Scrum of Scrums?

A. Nexus defines an explicit concern for producing an integrated increment across teams.

B. Nexus eliminates the need for a Product Backlog.

C. Nexus requires every team to use a different Sprint cadence.

D. Nexus is primarily a portfolio budgeting method.

Correct Answer: A. Nexus defines an explicit concern for producing an integrated increment across teams.

Question 2

An organisation has average work in progress of 24 items and throughput of 6 items per week. Using Little’s Law, what is the average cycle time?

A. 2 weeks

B. 4 weeks

C. 18 weeks

D. 144 weeks

Correct Answer: B. 4 weeks

Question 3

Which condition is most consistent with LeSS?

A. Many additional management layers and specialised coordination roles

B. A single product focus with an emphasis on feature teams and simplification

C. Independent product backlogs for every technical component

D. Portfolio funding as its primary defining mechanism

Correct Answer: B. A single product focus with an emphasis on feature teams and simplification

Question 4

What is the principal danger of adopting SAFe mechanically?

A. It prevents any form of portfolio governance.

B. It removes all architectural decision-making.

C. It can add roles and ceremonies while preserving command-and-control behaviour.

D. It requires teams to stop integrating their work.

Correct Answer: C. It can add roles and ceremonies while preserving command-and-control behaviour.

Question 5

If an initiative has Cost of Delay of 18 and Job Size of 6, what is its WSJF score?

A. 0.33

B. 3

C. 12

D. 108

Correct Answer: B. 3

Question 6

Which response most directly reduces a technical dependency?

A. Adding a weekly status meeting

B. Increasing the number of managers

C. Redesigning interfaces and automating contract tests

D. Increasing the percentage-complete reporting frequency

Correct Answer: C. Redesigning interfaces and automating contract tests

Question 7

What is the most appropriate use of portfolio metrics in an Agile environment?

A. To compare team velocity and rank teams

B. To support decisions about outcomes, risk, flow, and investment

C. To guarantee that every original feature is delivered

D. To replace product discovery with numerical scoring

Correct Answer: B. To support decisions about outcomes, risk, flow, and investment

Question 8

Which statement best describes a disciplined hybrid model?

A. It is an unplanned mixture of ceremonies from several frameworks.

B. It combines practices intentionally, with explicit purposes, decision rights, and inspection.

C. It avoids defining a product boundary.

D. It requires all frameworks to be implemented in full.

Correct Answer: B. It combines practices intentionally, with explicit purposes, decision rights, and inspection.

Question 9

Why can maximising specialist utilisation increase delivery time?

A. It necessarily increases product quality.

B. It creates queues and reduces the system’s ability to absorb variability.

C. It eliminates all dependencies.

D. It guarantees continuous integration.

Correct Answer: B. It creates queues and reduces the system’s ability to absorb variability.

Question 10

Which governance practice best preserves Agile principles in a regulated environment?

A. Reconstructing all compliance evidence after release

B. Requiring central approval for every implementation choice

C. Embedding controls, traceability, testing, and risk-based assurance into delivery

D. Ignoring regulation until the product has validated demand

Correct Answer: C. Embedding controls, traceability, testing, and risk-based assurance into delivery