Digital Operating Models and Agile Delivery

Introduction

Digital transformation is not achieved by installing new software, creating a mobile application, or completing a collection of technology projects. It is achieved when an organisation changes how it creates value, makes decisions, serves customers, manages risk, and continually improves its capabilities. The operating model is the bridge between strategy and execution: it specifies how people, processes, technology, information, governance, and performance management are arranged to deliver value.

Traditional operating models are often organised around functions such as marketing, operations, finance, and information technology. Work moves between departments through formal hand-offs, annual planning cycles, project approvals, and sequential delivery stages. Such arrangements can be effective in stable environments, but they become slow and expensive when customer needs, regulation, competitors, and technologies change rapidly.

A digital operating model is designed around persistent value streams, empowered teams, reusable platforms, data-enabled decisions, and rapid learning. Agile delivery is one of its principal mechanisms. However, agile methods do not automatically create agility. An organisation may conduct daily stand-ups while retaining annual funding, functional silos, excessive approvals, and project-based accountability. The result is agile activity without an agile operating model.

This chapter examines how managers design product-centric operating models using agile, DevOps, cross-functional teams, product management, minimum viable products, continuous discovery, and scaled delivery. It also distinguishes genuine transformation from isolated projects and evaluates the governance, measurement, technology, ethical, and organisational implications of these choices.

Learning Objectives

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

1. Explain the relationship between business strategy, operating models, value streams, products, and platforms.
2. Distinguish project-centric, functional, and product-centric operating models.
3. Design cross-functional product teams and clarify the roles of product management, engineering, design, data, security, and operations.
4. Explain how agile, DevOps, continuous discovery, and minimum viable products support iterative value delivery.
5. Select appropriate metrics for flow, reliability, customer outcomes, and business value.
6. Evaluate scaling approaches and identify when scaling frameworks may create unnecessary bureaucracy.
7. Diagnose why an organisation is conducting agile projects without achieving digital transformation.
8. Address governance, risk, ethics, compliance, and workforce implications in an agile operating model.

1. From Strategy to Operating Model

An operating model describes how an organisation consistently converts resources and capabilities into outcomes. It is more specific than a strategy and broader than a process map. A useful operating-model analysis considers six connected elements:

• Value proposition: the customer or stakeholder problem being solved.
• Value streams: the end-to-end activities through which value reaches the customer.
• Organisation and decision rights: who owns outcomes and who may make which decisions.
• Processes and ways of working: how work is prioritised, designed, built, released, and improved.
• Technology and data: platforms, applications, architecture, information, and automation.
• Governance and performance management: controls, funding, risk management, and measures.

A strategy such as “provide fast, personalised digital lending” has little practical force unless the organisation can form teams around the lending journey, access reliable customer data, automate credit decisions responsibly, release software safely, and measure outcomes such as approval time and repayment quality.

Projects, products, and platforms

A project is a temporary endeavour with a defined scope, budget, and end date. Projects are useful for bounded changes, such as constructing a facility or implementing a legally mandated system. They are less suitable when the problem, solution, and technology will evolve through learning.

A product is a sustained capability that serves a defined customer or business need. It has a lifecycle, a product strategy, users, owners, investment, and measurable outcomes. A product may be external, such as a banking application, or internal, such as an employee identity service.

A platform is a reusable technical or organisational capability that enables multiple products. Examples include identity management, payments, cloud infrastructure, analytics, and customer-data services. Platforms should reduce duplication and accelerate safe delivery, but they can become technology empires if they are not accountable to internal consumers and organisational outcomes.

The distinction is not absolute. A major transformation may begin as a project, but it should establish enduring product and platform ownership if the capability will require continuous improvement.

2. The Product-Centric Operating Model

In a product-centric model, persistent teams own products or value streams rather than merely completing temporary project tasks. Funding, accountability, architecture, and performance measures are aligned with outcomes. Product teams are expected to discover valuable problems, deliver usable solutions, operate them reliably, and learn from evidence.

The model usually contains three levels:

1. Enterprise strategy: defines strategic themes, constraints, risk appetite, and investment priorities.
2. Value streams and product portfolios: translate themes into customer journeys, products, platforms, and measurable outcomes.
3. Persistent teams: continuously discover, build, release, operate, and improve capabilities.

Product-centric does not mean that every team works independently. Shared architecture, security, legal, procurement, finance, data governance, and talent systems remain important. The design challenge is to preserve enterprise coherence while placing decisions close to the work.

Product management as an integrating discipline

Product management connects customer insight, business strategy, technology feasibility, and economic value. A product manager is not simply a requirements writer or project coordinator. Core responsibilities include:

• articulating the product vision and target users;
• understanding customer problems through qualitative and quantitative research;
• maintaining a transparent outcome-oriented roadmap;
• prioritising opportunities under capacity and risk constraints;
• coordinating experiments and release decisions;
• defining success measures and learning goals; and
• balancing customer value, business value, technical sustainability, security, accessibility, and compliance.

The product manager should not unilaterally control every decision. Effective product management is a collaborative practice involving design, engineering, data, operations, risk, and customers. The product manager owns product outcomes, while technical and design leaders retain professional accountability for engineering quality and user experience.

Team topology and cross-functional capability

A cross-functional product team contains the skills required to make meaningful progress without waiting for a long chain of external approvals. Typical capabilities include product management, user research, interaction and service design, software engineering, quality engineering, data analysis, security, and operational expertise.

The team need not contain every specialist full time. Specialists may support several teams through enabling or platform structures, provided that their allocation does not recreate a queue of functional hand-offs. Team boundaries should follow customer journeys, business capabilities, or coherent technical responsibilities rather than the historical organisation chart.

A practical team charter should specify:

• the customer or internal user served;
• the product or capability owned;
• the outcome measures;
• decision rights and escalation paths;
• dependencies and service-level expectations;
• technical and regulatory constraints; and
• the team’s approach to discovery, delivery, operation, and learning.

3. Agile Delivery as a Learning System

Agile is best understood as a management and delivery philosophy based on empirical learning, incremental value, close collaboration, and adaptation. Scrum, Kanban, Extreme Programming, and related methods provide practices, but no framework substitutes for sound judgement.

Agile delivery uses short feedback cycles. A team forms a hypothesis about a customer problem, develops the smallest responsible intervention, observes behaviour and outcomes, and adjusts its direction. This reduces the risk of investing heavily in an incorrect solution.

Discovery and delivery

Continuous discovery is the systematic and recurring investigation of customer problems, context, desirability, feasibility, viability, and risk. Activities may include interviews, observation, usability testing, service blueprinting, data analysis, prototyping, and experiments.

Continuous delivery is the ability to keep software in a releasable state through automation, small changes, quality controls, and repeatable deployment. Continuous delivery does not require releasing every change immediately. It means that the organisation can release when a product and risk decision authorise it.

Discovery and delivery should overlap rather than occur as separate phases. Discovery without delivery produces attractive concepts with no operational value; delivery without discovery produces efficient production of the wrong thing.

Minimum viable products and minimum viable experiments

A minimum viable product (MVP) is the smallest product version that can generate valid learning or deliver a meaningful initial outcome to a defined user group. “Minimum” refers to scope, not quality. An MVP must meet necessary standards for security, accessibility, reliability, legal compliance, and user safety.

An MVP should not be used to excuse poor service or transfer testing to customers. In some contexts, a prototype, concierge service, limited beta, or simulation is more appropriate than production software. The relevant question is: what is the least costly and least risky intervention that can test the critical assumption?

A good experiment identifies:

• the assumption being tested;
• the target population;
• the intervention;
• the expected behaviour or outcome;
• the observation period;
• ethical and legal safeguards; and
• the decision rule for continuing, changing, or stopping.

Prioritisation

Prioritisation should consider expected value, urgency, risk reduction, learning value, effort, and dependencies. Frameworks such as cost of delay, opportunity scoring, weighted shortest job first, and impact-versus-effort matrices can support discussion, but they should not create false precision.

A useful conceptual relationship is:

This is a decision heuristic, not a scientific law. The numerator contains judgement-based scores, and the denominator may represent relative team effort. It is meaningful only when the scoring scale is defined consistently within the portfolio. It should not be used to compare unrelated products mechanically or to conceal strategic choices behind a numerical ranking.

4. DevOps and the Build–Run Connection

DevOps is a socio-technical approach that integrates development, operations, security, quality, and business responsibility across the product lifecycle. Its central idea is shared accountability for delivering and operating valuable, secure, and reliable services.

Important DevOps practices include:

• version control for application code, infrastructure, configuration, and policy;
• automated build, test, security scanning, and deployment pipelines;
• infrastructure as code and reproducible environments;
• observability through logs, metrics, traces, and meaningful alerts;
• small, reversible changes;
• progressive delivery, such as feature flags and canary releases;
• incident response, post-incident learning, and blameless improvement; and
• explicit reliability targets and error budgets.

DevOps is not synonymous with a toolchain. Purchasing a pipeline product does not create shared ownership. Organisational incentives, skills, architecture, controls, and leadership behaviour must support the desired flow.

Reliability and error budgets

A service-level objective (SLO) defines a target level of service, such as availability or latency, over a specified period. The error budget is the amount of unreliability permitted by the SLO. If an SLO requires 99.9% availability over a 30-day month, the permitted unavailability is approximately 0.1% of the period. Using a 30-day month of 43,200 minutes:

This calculation assumes that the SLO is an availability target measured over the entire period and that the relevant service period is 30 days. Different definitions, exclusions, and measurement windows produce different budgets. The error budget creates a decision mechanism: when reliability is being consumed too quickly, the team may pause risky releases and invest in resilience.

5. Flow, Metrics, and Outcomes

A product operating model needs measures that reveal both delivery health and real-world value. No single metric is sufficient. Managers should avoid turning measures into individual performance targets because teams may optimise the number rather than the outcome.

Flow measures

Common measures include:

• Lead time: elapsed time from a request or commitment to delivery.
• Cycle time: elapsed time from active work to completion.
• Throughput: number of completed work items in a period.
• Work in progress: items started but not completed.
• Deployment frequency: how often a service is deployed.
• Change failure rate: proportion of deployments causing failure, rollback, or remediation.
• Mean time to restore: average time required to restore service after an incident.

A useful relationship from queuing theory is Little’s Law:

Here, L is average work in progress, λ is average throughput, and W is average time in the system. The relationship assumes a stable system over the period considered, with consistent definitions of entry and exit. For example, if a team completes 10 items per week and the average item takes 2 weeks from entry to completion, average work in progress is 20 items. The formula is descriptive, not a target-setting rule. Increasing work in progress does not automatically increase throughput and often increases waiting and switching costs.

Outcome measures

Outcome measures should connect activity to strategic value. Examples include customer activation, successful task completion, retention, revenue quality, cost to serve, fraud loss, employee productivity, accessibility, and incident impact. A balanced measurement system combines:

1. customer outcomes;
2. business and financial outcomes;
3. reliability, security, and operational outcomes;
4. flow and learning indicators; and
5. workforce health and sustainability.

A team that increases deployment frequency while increasing security incidents has not necessarily improved. Similarly, reducing call-centre costs by making digital support unusable may shift cost rather than create value.

6. Scaling Agile Delivery

Scaling becomes relevant when multiple teams must coordinate around a product, value stream, platform, or enterprise change. It should not be the default response to every problem. Before adding a scaling framework, leaders should examine whether team boundaries, architecture, priorities, and decision rights are clear.

Scaling mechanisms may include:

• a shared product vision and outcome roadmap;
• quarterly or periodic cross-team planning;
• dependency mapping and architectural coordination;
• communities of practice;
• platform teams and enabling teams;
• integrated testing and release governance;
• a common definition of done; and
• portfolio-level investment and risk review.

Frameworks such as large-scale Scrum, the Scaled Agile Framework, and other models offer vocabulary and coordination practices. Their value depends on context. A framework can improve transparency, but it can also reproduce hierarchy, create excessive ceremonies, and encourage teams to optimise local milestones rather than customer outcomes.

A useful scaling principle is minimum viable governance: establish only the coordination, control, and standardisation necessary to manage material risk and interdependence. Teams should be allowed to vary practices where variation does not create unacceptable risk or fragmentation.

7. Governance, Risk, and Responsible Digital Delivery

Agile does not eliminate governance; it changes when and how governance occurs. Traditional governance often concentrates scrutiny at the beginning and end of a project. Digital governance should distribute appropriate controls throughout discovery, development, release, and operation.

Important controls include:

• privacy-by-design and data minimisation;
• threat modelling and secure development practices;
• segregation of duties where legally or operationally necessary;
• accessibility testing and inclusive design;
• model risk management for AI-enabled decisions;
• audit trails and change records;
• resilience and disaster-recovery testing;
• third-party and cloud-risk assessment; and
• human escalation for consequential automated decisions.

Teams should know which decisions they can make autonomously and which require specialist or executive review. A control that takes weeks for a low-risk change may encourage workarounds; a control that is absent for a high-impact algorithm may expose customers and the organisation to serious harm.

AI can support discovery through research synthesis, generate test cases, assist coding, detect anomalies, and personalise services. However, generated code and content require review. AI systems may reproduce bias, expose confidential information, hallucinate facts, or make decisions that cannot be adequately explained. Human accountability, data governance, model monitoring, and appropriate impact assessment remain essential.

8. Transformation versus Isolated Agile Projects

An organisation is undergoing transformation when changes are systemic, sustained, and linked to strategic outcomes. Indicators include persistent product ownership, changed funding and incentives, empowered cross-functional teams, modern engineering practices, outcome-based planning, redesigned governance, and measurable improvement in customer and operational results.

An isolated agile project may use Scrum ceremonies while retaining:

• temporary teams assembled from departments;
• fixed scope and annual business cases;
• hand-offs to separate testing and operations groups;
• success defined as on-time delivery of requirements;
• project closure immediately after launch; and
• no authority to change the product based on evidence.

Such a project may still deliver useful software, but it has not necessarily changed the operating model. Transformation should therefore be assessed at multiple levels:

9. Illustrative Case: Northstar Bank’s Digital Lending Transformation

Background

Northstar Bank, a fictional regional bank, had a strong branch network and a profitable lending portfolio. Its digital lending application was built through sequential projects. Marketing defined campaigns, risk defined rules, IT built software, operations reviewed applications, and a separate vendor managed parts of the platform.

Problem

Customers waited up to five business days for a decision on simple personal loans. The bank launched periodic digital enhancements, but each release required extensive coordination. Abandonment was high, employees performed manual data entry, and risk leaders were concerned that proposed automation would create unfair outcomes.

Analysis

An operating-model assessment identified four root causes:

1. No persistent team owned the end-to-end lending journey.
2. Funding rewarded project completion rather than customer and portfolio outcomes.
3. Operations and risk were consulted late, creating rework and resistance.
4. Deployment and monitoring practices made small, frequent releases difficult.

The bank also discovered that its most serious constraint was not the customer interface. It was fragmented identity, income, and decision data.

Approach

The executive committee created a lending value stream with a persistent product team. The team included a product manager, service designer, engineers, data specialists, a risk representative, an operations representative, and a security adviser. A platform team improved identity verification, audit logging, and deployment automation.

The team began with discovery interviews, application-journey analysis, and review of abandonment data. It formed a hypothesis that customers would complete more applications if identity verification were simpler and eligibility information were presented earlier.

Instead of building a complete automated lending system, the team ran a controlled MVP: a limited customer segment received a redesigned application flow, clearer explanations, and an assisted fallback when automated verification failed. The MVP retained human review for consequential decisions and monitored completion, approval quality, complaints, fraud signals, accessibility, and demographic disparities.

Deployment used automated tests, feature flags, and a gradual release. The team established a service-level objective for the application and reviewed incidents weekly. Product funding was renewed quarterly based on evidence and risk review rather than a fixed list of features.

Outcome

After two quarters, the bank reported materially faster application completion, fewer manual re-entries, and improved visibility of failure points. The team did not simply celebrate conversion. It stopped one proposed automation feature after monitoring revealed inconsistent outcomes for a customer subgroup. The bank invested instead in better data quality and clearer human escalation.

The most important result was organisational. Lending became a continuously managed product rather than a sequence of disconnected projects. Some legacy dependencies remained, and the bank still required formal controls for credit risk, privacy, and financial reporting. Transformation was therefore incomplete but directionally credible.

Learning points

• The product boundary should follow the customer journey and accountable outcome.
• An MVP can be controlled and high quality; minimal scope does not mean minimal safeguards.
• Risk, compliance, and operations should participate early rather than act only as approval gates.
• Platform investment is valuable when it removes repeated friction for product teams.
• Transformation is demonstrated by changed funding, ownership, capabilities, and measures—not by agile vocabulary alone.

10. Implementation Roadmap for Managers

A practical transition can proceed through the following sequence:

Diagnose the current system

Map value streams, decision delays, dependencies, architecture, funding, skills, and measures. Interview customers and frontline employees. Identify where work waits and where accountability is unclear.

Define target outcomes

Translate strategy into a small number of measurable outcomes. Specify customer, financial, operational, risk, and workforce constraints. Avoid defining the target model only as a list of ceremonies or tools.

Establish product boundaries

Choose products and platforms that have coherent users, capabilities, and outcomes. Assign accountable product leaders and persistent teams. Remove or clarify overlapping ownership.

Pilot responsibly

Select a strategically important but manageable value stream. Protect the pilot from excessive project interference while maintaining enterprise security, privacy, and regulatory controls.

Change funding and performance management

Move progressively from feature-based funding to capacity and outcome-based investment. Evaluate leaders on system and customer results, not merely utilisation or local delivery volume.

Improve engineering and platform capabilities

Invest in automated testing, observability, deployment safety, architecture, data quality, and technical skills. Architecture should enable team autonomy without sacrificing resilience and interoperability.

Scale through learning

Share evidence across teams, standardise only what must be standardised, and retire practices that add cost without improving outcomes. Scaling should follow demonstrated need.

Challenges and Limitations

Product-centric operating models have significant limitations and risks. Persistent teams may become protective of their products or duplicate capabilities. Outcome measures may be difficult to attribute because many factors influence customer behaviour. Autonomous teams can make inconsistent architecture or data decisions. Continuous delivery may increase operational load if staffing and support models are weak.

Agile methods also work less well when requirements are genuinely fixed, the work is highly repetitive, safety certification requires a prescribed sequence, or the organisation lacks access to users and reliable feedback. In these cases, iterative planning may still help, but the degree of flexibility must reflect the context.

Transformation can create anxiety about roles, status, employment, and professional identity. Workforce transition should include reskilling, transparent communication, fair selection processes, and attention to psychological safety. Automation should augment human capability where possible and should not be introduced solely to externalise risk or reduce headcount without examining service and social consequences.

Chapter Summary

A digital operating model aligns strategy, value streams, persistent teams, technology, data, governance, funding, and measures around continuous value creation. Product-centric organisations distinguish enduring products and platforms from temporary projects and assign teams accountability for discovery, delivery, operation, and improvement.

Agile provides an empirical learning approach, while continuous discovery tests whether the organisation is solving a valuable problem. MVPs reduce uncertainty when they are deliberately scoped and still meet appropriate quality, safety, accessibility, privacy, and regulatory standards. DevOps integrates development and operations through shared ownership, automation, observability, reliable release practices, and learning from incidents.

Flow metrics such as lead time, throughput, work in progress, deployment frequency, change failure rate, and restoration time should be combined with customer, business, reliability, risk, and workforce outcomes. Little’s Law can illuminate the relationship between work in progress, throughput, and time, but metrics must be interpreted within their assumptions and should not become simplistic targets.

Scaling requires coordination, not necessarily a large framework. Effective governance is risk-based and continuous. Genuine transformation changes ownership, funding, incentives, capabilities, architecture, and decision rights; an isolated agile project changes delivery practices without changing the surrounding system.

Key Terms

Operating model: The arrangement of capabilities, processes, people, technology, data, and governance used to execute strategy.

Digital operating model: An operating model designed for digitally enabled, data-informed, continuously improving value delivery.

Value stream: End-to-end activities that produce a customer or stakeholder outcome.

Product: A sustained capability serving a defined user or business need.

Platform: A reusable capability that enables multiple products or teams.

Product management: The discipline of connecting customer problems, strategy, technology, value, and risk.

Cross-functional team: A team containing or accessing the capabilities needed to deliver meaningful outcomes.

Agile: An adaptive approach based on incremental delivery, collaboration, feedback, and empirical learning.

Continuous discovery: Ongoing investigation of customer needs, solution desirability, feasibility, viability, and risk.

Minimum viable product: The smallest responsible product version capable of generating valid learning or initial value.

DevOps: A socio-technical approach integrating development, operations, security, quality, and business responsibility.

Continuous delivery: The capability to keep software releasable through repeatable, automated, controlled practices.

Observability: The ability to understand system behaviour from outputs such as logs, metrics, and traces.

Service-level objective: A target level of service performance measured over a defined period.

Error budget: The permitted unreliability implied by a service-level objective.

Lead time: Elapsed time between a defined work-entry point and completion or delivery.

Throughput: The number of work items completed in a specified period.

Outcome measure: An indicator of the effect or value produced, rather than merely activity completed.

Minimum viable governance: The least coordination and control necessary to manage material risk and interdependence.

Digital transformation: Sustained systemic change in how an organisation creates value and operates through digital capabilities.

Review Questions

Short Answer Questions

1. What distinguishes a product from a project?
2. Why should product teams be cross-functional?
3. Define continuous discovery.
4. What is the purpose of an error budget?
5. Why is deployment frequency alone an insufficient measure of performance?

Long Answer Questions

1. Explain how a product-centric operating model connects strategy, value streams, teams, platforms, and governance.
2. Compare project-centric and product-centric funding and accountability.
3. Discuss how DevOps changes the relationship between software development and operations.
4. Explain the appropriate use and limitations of MVPs in regulated industries.
5. Evaluate the advantages and risks of scaling agile delivery across a large enterprise.

Analytical / Application Questions

1. A company has agile ceremonies but annual fixed-scope funding, separate testing, and project teams that disband after launch. Diagnose why this is not yet an agile operating model and propose three interventions.
2. A digital service has high deployment frequency but rising incidents and customer complaints. Which measures and governance changes would you introduce, and why?
3. Design a product-team charter for a digital lending, healthcare, or public-service value stream. Include its users, outcome measures, decision rights, dependencies, and responsible experimentation approach.

Multiple Choice Questions with Answers

Question 1

Which characteristic most clearly distinguishes a product-centric operating model from a project-centric model?

A. All work is performed by the information technology department.

B. Persistent teams own outcomes and continuously improve a capability.

C. Every initiative has a fixed scope and end date.

D. Requirements are approved only at the beginning of the initiative.

Correct Answer: B. Persistent teams own outcomes and continuously improve a capability.

Question 2

What is the primary purpose of continuous discovery?

A. To eliminate the need for software testing.

B. To ensure that teams continuously investigate customer problems and solution assumptions.

C. To guarantee that every proposed feature is released.

D. To replace product strategy with customer interviews.

Correct Answer: B. To ensure that teams continuously investigate customer problems and solution assumptions.

Question 3

Which statement about a minimum viable product is most accurate?

A. It is a deliberately low-quality product released without safeguards.

B. It is the largest feature set that can fit within an annual budget.

C. It is the smallest responsible intervention capable of generating useful learning or initial value.

D. It is a prototype that can never be used by real customers.

Correct Answer: C. It is the smallest responsible intervention capable of generating useful learning or initial value.

Question 4

Which practice is most closely associated with DevOps?

A. Separating development and operations into independent accountability structures.

B. Using manual deployment approvals for every code change regardless of risk.

C. Sharing responsibility for delivery, operation, reliability, and improvement.

D. Transferring software to an operations team immediately after development.

Correct Answer: C. Sharing responsibility for delivery, operation, reliability, and improvement.

Question 5

A service has an availability SLO of 99.9% over 43,200 minutes. What is its approximate error budget?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 4,320 minutes

Correct Answer: B. 43.2 minutes

Question 6

In Little’s Law, what does L represent?

A. Average work in progress in the system

B. Average labour cost per item

C. Maximum permitted latency

D. The number of product teams

Correct Answer: A. Average work in progress in the system

Question 7

Which measure is an outcome measure rather than a flow measure?

A. Cycle time

B. Throughput

C. Customer task completion rate

D. Work in progress

Correct Answer: C. Customer task completion rate

Question 8

What is the main danger of adopting a scaling framework without examining organisational context?

A. It always eliminates the need for governance.

B. It can add ceremonies and hierarchy without resolving dependencies or unclear ownership.

C. It prevents all teams from using automation.

D. It guarantees that product teams become too small.

Correct Answer: B. It can add ceremonies and hierarchy without resolving dependencies or unclear ownership.

Question 9

Which governance approach is most consistent with responsible agile delivery?

A. Apply no controls until the product is complete.

B. Use the same approval burden for every change.

C. Embed risk-based controls throughout discovery, delivery, release, and operation.

D. Allow product managers to override all privacy and security requirements.

Correct Answer: C. Embed risk-based controls throughout discovery, delivery, release, and operation.

Question 10

Which is the strongest evidence that an organisation is undergoing digital transformation rather than merely running agile projects?

A. It holds daily stand-up meetings.

B. It uses a project-management application.

C. It has changed funding, ownership, capabilities, governance, and measures toward sustained outcomes.

D. It has renamed project managers as product owners.

Correct Answer: C. It has changed funding, ownership, capabilities, governance, and measures toward sustained outcomes.