8. Agile, Lean and DevOps Engineering

Introduction and Context

Software engineering has moved from a predominantly sequential activity to a discipline concerned with rapid learning, continuous delivery, operational resilience, and organizational adaptability. Traditional development models remain useful when requirements are stable, compliance obligations are explicit, or physical dependencies make change expensive. However, many contemporary software products operate in uncertain markets, depend on distributed platforms, and must evolve continuously after release. In such settings, success depends not only on producing correct code but also on shortening feedback cycles, controlling work in progress, automating delivery, and operating services reliably.

Agile, Lean, DevOps, and Site Reliability Engineering (SRE) are related but distinct responses to these demands. Agile emphasizes iterative development and close collaboration with users. Lean focuses on maximizing customer value while reducing waste and improving flow. DevOps integrates development and operations through shared responsibility, automation, and continuous feedback. SRE applies software engineering practices to operations, especially reliability, observability, incident response, and capacity management.

These approaches are not merely collections of ceremonies or tools. They represent socio-technical systems involving organizational structure, incentives, architecture, governance, technical practices, and professional judgment. A team can conduct daily stand-ups and still be non-agile; it can install a continuous integration server and still lack DevOps capability. Critical application therefore requires understanding why the practices exist, what trade-offs they create, and how they should be adapted to context.

Learning Objectives

After studying this chapter, students should be able to:

• explain the relationships and differences among Agile, Lean, Scrum, Kanban, Extreme Programming, DevOps, and SRE;
• analyze software work using concepts such as value, waste, flow, feedback, work in progress, and batch size;
• select and adapt Agile and Lean methods for different organizational contexts;
• design a DevOps delivery pipeline incorporating automation, security, observability, and governance;
• apply service-level objectives, error budgets, and incident-management principles;
• evaluate metrics without encouraging dysfunctional optimization;
• diagnose common implementation failures and propose sustainable improvements.

From Iterative Development to Continuous Operations

Agile development emerged partly as a response to the limitations of predictive processes in environments where requirements change during development. Its central insight is that software value is discovered through frequent collaboration and usable increments, not fully specified at the beginning. Iteration reduces the cost of being wrong and creates opportunities for stakeholders to revise priorities using evidence.

Lean thinking originated in production but has been adapted to knowledge work. Software is unlike manufactured goods because its primary cost lies in learning, coordination, and change. Nevertheless, Lean principles remain valuable: identify customer value, map the value stream, establish smooth flow, use pull rather than excessive pushing, and pursue continuous improvement. In software, waste may appear as partially completed features, excessive handoffs, delayed approvals, avoidable defects, unused functionality, context switching, or long queues.

DevOps extends these ideas across the boundary between development and operations. Historically, developers were rewarded for releasing features while operations teams were judged by stability. This separation encouraged conflict: developers sought change, whereas operations sought protection from change. DevOps attempts to make delivery and operation a shared system, supported by infrastructure automation, version-controlled configuration, automated testing, continuous integration, deployment automation, and production feedback.

SRE is a disciplined operational approach associated with the idea that service operations should be treated as a software engineering problem. SRE teams define reliability targets, automate repetitive work, manage risk through error budgets, and use incidents as sources of organizational learning. SRE does not eliminate operations; it changes how operational work is engineered and governed.

Agile Frameworks as Systems of Empirical Control

Agile methods rely on empiricism: decisions are based on observation, experience, and adjustment rather than on an assumption that all future conditions can be predicted. Three conditions support empirical control: transparency, inspection, and adaptation. Work and quality must be visible; progress and outcomes must be examined; and plans or practices must change when evidence indicates that they are no longer effective.

Scrum

Scrum organizes work into timeboxed Sprints, commonly lasting between one and four weeks. A Product Owner is accountable for maximizing product value and ordering the Product Backlog. Developers create the increment and are responsible for producing a usable result. The Scrum Master supports effective use of Scrum, removes impediments, and helps the organization understand the framework.

The Product Backlog is an ordered, evolving set of work. During Sprint Planning, the team establishes a Sprint Goal and selects work it believes can be completed. The Daily Scrum is a short event for Developers to inspect progress toward the goal and adapt their plan. The Sprint Review examines the increment with stakeholders and informs future priorities. The Sprint Retrospective examines the team's way of working and identifies improvements.

Scrum does not guarantee agility. Common distortions include treating the Sprint Backlog as a contract that cannot change, measuring individual utilization, converting the Daily Scrum into a manager's status meeting, or allowing the Product Owner role to become a requirements clerk. The Sprint Goal should provide coherence while allowing the team to negotiate details as learning occurs.

Kanban and Flow Management

Kanban is a method for improving the flow of work through visualization, explicit policies, pull-based replenishment, and limits on work in progress (WIP). A Kanban board may represent stages such as discovery, development, testing, deployment, and validation. WIP limits prevent new work from entering a congested stage merely because someone is available upstream.

Flow metrics provide a more useful picture than activity counts. Lead time measures the period from a customer's request to delivery; cycle time measures the period from work starting to completion. Throughput measures completed items per unit of time. Work-in-progress age identifies items that are becoming unusually old. Little's Law, expressed as WIP = Throughput × Average Cycle Time, explains why increasing unfinished work generally increases the time required to complete each item when throughput is stable.

Kanban does not require iterations or prescribed roles. It can be used by support teams, product teams, and organizations that need continuous delivery. Its flexibility is a strength, but weak policies can make a board merely decorative. Explicit definitions of workflow states, entry and exit criteria, classes of service, and escalation rules are essential.

Extreme Programming

Extreme Programming (XP) concentrates on engineering practices that enable rapid, safe change. Its practices include test-driven development, pair programming, continuous integration, refactoring, simple design, collective code ownership, small releases, and close customer collaboration. XP treats technical quality as a prerequisite for agility rather than an optional activity after feature development.

Test-driven development commonly follows a short cycle: write a failing test, implement the smallest behavior that makes it pass, and refactor the design while preserving the tests. The method encourages executable specifications and frequent design feedback, although it does not replace system-level testing or thoughtful test selection. Refactoring manages the internal design of a system without changing its externally visible behavior. Without refactoring, rapid delivery can accumulate technical debt that later slows every change.

Lean Reasoning: Value, Waste, and Improvement

Lean begins with a question: which activities create value from the customer's perspective, and which merely consume time or resources? In software, value is not always equivalent to feature count. A small reliability improvement may create more value than a large unused feature. Similarly, eliminating a recurring manual approval may improve delivery more than adding another developer.

Typical forms of software waste include:

• partially completed work that creates inventory but no customer value;
• unnecessary features built on assumptions rather than evidence;
• defects and rework caused by inadequate quality practices;
• waiting for environments, decisions, reviews, or specialist teams;
• excessive handoffs and communication overhead;
• task switching that reduces concentration and increases coordination cost;
• underused skills and insufficient team autonomy.

Lean improvement is not equivalent to indiscriminate cost reduction. Removing testing, documentation, or security controls may reduce visible effort while increasing downstream risk. The relevant question is whether a control produces value or prevents a larger loss. Techniques such as value-stream mapping, root-cause analysis, the Five Whys, and Plan-Do-Study-Act cycles help teams investigate systemic causes rather than blaming individuals.

DevOps as a Socio-Technical Delivery Capability

A DevOps capability connects source code, infrastructure, testing, security, deployment, and operations into a traceable flow. Continuous integration means that changes are integrated into a shared codebase frequently and verified through automated checks. Continuous delivery means that software is maintained in a releasable state and can be deployed through a controlled process. Continuous deployment goes further by automatically deploying qualifying changes to production.

A typical pipeline includes source control, build and dependency resolution, static analysis, unit and integration tests, packaging, security checks, environment provisioning, deployment, smoke testing, monitoring, and feedback. The exact sequence varies. The principle is to make the path from change to operational evidence fast, repeatable, and visible.

Infrastructure as Code represents infrastructure configuration in version-controlled, reviewable definitions. It improves reproducibility and reduces configuration drift, but it also means that infrastructure code requires testing, access control, and secure handling of secrets. Containers and orchestration platforms can increase portability and deployment consistency, but they do not automatically provide sound architecture or reliability.

Deployment strategies manage release risk. A blue-green deployment maintains two production environments and shifts traffic between them. A canary deployment exposes a small proportion of users or traffic to a new version before wider rollout. Feature flags separate deployment from feature activation, allowing controlled experimentation or rapid disabling. These mechanisms require disciplined flag management, clear rollback criteria, and protection against incompatible database changes.

DevSecOps integrates security into the delivery system rather than treating it as a final inspection. Secure dependency management, threat modeling, secrets scanning, code analysis, vulnerability remediation, identity controls, and audit trails should be proportionate to risk. Automation supports security, but it cannot replace architectural judgment or accountability.

Reliability Engineering and Operational Feedback

Reliability is the probability that a system performs its required function under stated conditions for a specified period. In distributed software, reliability also includes availability, durability, correctness, recoverability, and acceptable performance. A system may be available but unreliable if it returns incorrect results; it may be correct but unusable if latency is excessive.

SRE distinguishes service-level indicators (SLIs), service-level objectives (SLOs), and service-level agreements (SLAs). An SLI is a measured aspect of service behavior, such as successful request proportion or latency at a defined percentile. An SLO is the target for that indicator over a stated period. An SLA is an external or contractual commitment that may include consequences for failure. Confusing these terms leads to vague reliability discussions.

An error budget is the amount of unreliability permitted by an SLO. If an SLO promises 99.9 percent successful availability over a period, the remaining fraction is the error budget. The budget creates a decision mechanism: when reliability is comfortably within target, the organization may accept more release risk; when the budget is exhausted, feature delivery may be slowed while reliability work receives priority. An error budget is useful only when product and engineering leaders agree on how it affects decisions.

Observability concerns the ability to infer internal system state from externally visible outputs. Logs provide event records, metrics provide numerical measurements, and traces show request paths across components. High-quality observability includes meaningful context, correlation identifiers, consistent severity levels, privacy protection, and actionable alerts. Monitoring a large number of signals does not necessarily make a system observable; the signals must help answer operational questions.

Alerting should be tied to user impact or imminent service risk. Alerts that are frequent, ambiguous, or impossible to act upon create alert fatigue. A dashboard may support diagnosis, whereas an alert should usually indicate that human attention is required. Synthetic transactions, real-user monitoring, capacity indicators, and dependency health checks complement application telemetry.

Incident Response and Learning

An incident is an event that threatens or degrades service quality. Effective incident response establishes roles and communication patterns before a crisis. Depending on scale, roles may include an incident commander, technical lead, communications lead, and operations or scribe support. The incident commander coordinates decisions and prevents uncontrolled parallel activity; the technical lead investigates and implements mitigation.

Response generally proceeds through detection, triage, containment or mitigation, recovery, and review. During an incident, restoring acceptable service usually takes priority over discovering the ultimate root cause. Rollbacks, traffic reduction, feature disabling, failover, or temporary capacity increases may be appropriate. Changes made during a crisis should be recorded because they form part of the evidence.

A blameless post-incident review does not mean that standards are abandoned. It means that analysis focuses on conditions, decisions, interfaces, incentives, and safeguards rather than treating an individual as the sole cause of a complex failure. A useful review identifies customer impact, timeline, contributing factors, what went well, what failed, and specific actions with owners and deadlines. Repeated incidents often indicate that corrective actions are too vague or that organizational incentives discourage preventive work.

Choosing and Combining Methods

Scrum, Kanban, XP, DevOps, and SRE should not be treated as mutually exclusive brands. Scrum may provide planning and review cadences; Kanban may expose and limit flow within or across Sprints; XP may provide engineering discipline; DevOps may connect development to deployment; and SRE may govern production reliability. The combination should be designed around the organization's constraints and the nature of its work.

For exploratory product development with uncertain requirements, short Scrum cycles and XP practices may be appropriate. For a service desk with unpredictable incoming work, Kanban with explicit classes of service may be more suitable. For a regulated banking platform, continuous delivery may still be possible, but it must include traceability, segregation of duties where justified, automated evidence, and controlled approvals. For a safety-critical system, speed cannot override hazard analysis, verification, and mandated assurance.

Transformation should begin with a problem rather than a framework. Leaders should ask where value is delayed, where defects escape, why deployments are risky, and which operational pain is repeated. A small but representative value stream can then be measured, improved, and used to build organizational learning. Changing job titles or introducing ceremonies without changing decision rights, architecture, incentives, and feedback loops rarely produces durable results.

Metrics and the Risk of Local Optimization

Useful measures should illuminate outcomes and support learning. Four widely used delivery measures are deployment frequency, lead time for changes, change failure rate, and time to restore service. They should be interpreted together. Increasing deployment frequency while change failure rate and restoration time worsen is not improvement.

Other useful measures include escaped defects, cycle-time distribution, WIP age, availability, latency, customer satisfaction, incident recurrence, and the proportion of capacity devoted to unplanned work. Metrics should be used for system improvement, not simplistic ranking of individuals or teams. If developers are rewarded for lines of code, they may produce unnecessary code; if teams are rewarded only for velocity, they may inflate estimates or sacrifice quality. Measurement design is therefore a governance issue as well as a technical one.

Illustrative Case: Recovering a Digital Payments Service

Background

A fictional company, MeridianPay, operates a digital payments platform used by retail merchants. Its product team releases new payment features monthly, but deployments are large and infrequent. Development, security, database administration, and operations are separate departments. The service has experienced repeated payment delays and several emergency rollbacks.

Situation and Problem

Customers report intermittent transaction failures, while internal reports show that the average release takes three weeks to pass through approvals and environment preparation. Engineers work on many features simultaneously. Operations receives incomplete release information, and alerts frequently fire without indicating customer impact. Management initially proposes increasing release frequency by requiring teams to “work faster.”

Analysis

A value-stream analysis identifies waiting for test environments, manual regression testing, late security review, and database-change coordination as major delays. The team also discovers that its availability dashboard measures server health but not successful payment completion. WIP is high, and unfinished features are frequently carried across releases. Incident reviews focus on the person who made the final change rather than on missing safeguards.

Approach

MeridianPay forms a cross-functional product team containing development, testing, security, and operations expertise. It introduces a Kanban board with WIP limits and separates urgent production work from standard feature work through explicit policies. The team establishes continuous integration, automated unit and contract tests, infrastructure definitions in version control, and automated dependency checks.

For deployment, the team uses feature flags and canary releases. It defines SLIs for successful payment completion, latency, and authorization failures, then sets SLOs based on customer expectations. Alerts are tied to material degradation rather than every infrastructure fluctuation. An incident commander model and blameless reviews are introduced. The team also reserves capacity for reliability improvements and uses an error-budget policy to pause risky feature releases when reliability declines.

Outcome

The principal improvement is not a particular tool but a shorter feedback loop. Developers receive test results earlier, operations sees deployment evidence, and product managers can evaluate features incrementally. When a canary release increases authorization failures, automated monitoring stops the rollout before full exposure. Some delivery speed is sacrificed during reliability recovery, but later releases become smaller and less disruptive.

Learning Points

The case illustrates that delivery performance is a system property. More individual effort could not solve queues, large batches, weak observability, and conflicting incentives. Flow limits, automation, reliability targets, and shared ownership address different causes of the same organizational problem. It also demonstrates that continuous delivery is not synonymous with uncontrolled change; it is controlled change supported by evidence.

Challenges, Governance, and Professional Responsibility

Agile and DevOps initiatives can fail through superficial adoption, excessive tool focus, or unrealistic expectations. Teams may be told to self-organize without receiving authority over architecture or priorities. Continuous delivery may become continuous pressure if leadership ignores sustainable pace. SRE may be reduced to an operations team that absorbs every reliability problem without authority to change product design.

Technical debt is another challenge. Debt is not simply old code; it is a design or implementation choice that creates future cost or risk. Some debt is deliberate and economically rational, but it should be visible, monitored, and repaid when its carrying cost becomes significant. Reliability debt, security debt, and observability debt deserve the same attention as code debt.

Governance must preserve accountability without recreating unnecessary queues. Regulated environments require evidence of authorization, testing, segregation of duties, data protection, and change history. These controls can be automated through pipeline records and policy checks, but exceptions must be reviewed. Privacy principles require that logs and traces avoid unnecessary personal or financial data. Access to production systems should follow least privilege, strong authentication, and auditable procedures.

Ethically, engineers have a duty to communicate material reliability and security risks honestly. Product pressure does not justify concealing known defects or weakening safeguards without informed authorization. Blamelessness must not become an excuse for negligence; it should support truthful learning while maintaining professional standards.

Emerging Directions

Platform engineering is developing as an organizational response to the complexity of cloud-native delivery. Internal platforms provide reusable pathways for deployment, observability, identity, and compliance, allowing product teams to work independently while preserving organizational standards. The platform must be treated as a product with users, service levels, documentation, and feedback.

Progressive delivery increasingly combines canary analysis, feature flags, automated rollback, and experimentation. Artificial intelligence is being applied to code assistance, test generation, anomaly detection, incident summarization, and capacity forecasting. These applications can reduce toil, but generated code and automated recommendations require review, security assessment, data governance, and awareness of false positives or misleading correlations.

Software supply-chain security is gaining importance as systems depend on open-source packages, build services, container images, and third-party APIs. Provenance records, signed artifacts, dependency controls, reproducible builds, and rapid vulnerability response are becoming components of engineering maturity. At the same time, sustainability is entering delivery decisions: unnecessary compute, excessive data retention, inefficient pipelines, and overprovisioned environments create environmental as well as financial costs.

Best-Practice Principles

A mature Agile, Lean, and DevOps environment generally follows these principles:

1. Start with customer and operational outcomes, not ceremonies or tools.

2. Keep work small, visible, and limited so that problems surface early.

3. Build quality, security, and operability into the delivery process.

4. Automate repetitive, deterministic work while retaining human judgment for ambiguity and risk.

5. Measure flow and outcomes across the whole value stream rather than optimizing departmental activity.

6. Define reliability targets explicitly and use error budgets to balance innovation with stability.

7. Make deployments reversible or safely progressive where technically feasible.

8. Treat incidents as learning opportunities and assign concrete improvement actions.

9. Give teams appropriate autonomy together with clear accountability.

10. Improve the system continuously through evidence, experimentation, and reflection.

Chapter Summary

Agile, Lean, DevOps, and SRE form a connected set of approaches for managing uncertainty, improving flow, delivering software safely, and operating reliable services. Scrum provides an empirical framework for iterative product development; Kanban manages flow through visualization, pull, and WIP limits; XP strengthens the engineering practices that make frequent change safe. Lean identifies value and waste across the value stream. DevOps integrates development and operations through shared responsibility, automation, and feedback. SRE applies engineering discipline to reliability through SLIs, SLOs, error budgets, observability, and incident learning.

The chapter has emphasized that methods succeed only when supported by suitable architecture, incentives, governance, skills, and decision rights. Metrics must be interpreted systemically, and automation must include security and accountability. The central professional challenge is to create a delivery system that learns quickly without sacrificing reliability, ethics, or sustainable work.

Key Terms

Agile: An adaptive approach that delivers value incrementally through collaboration, feedback, and change.

Scrum: An empirical framework using roles, events, artifacts, and timeboxed Sprints to develop products.

Product Backlog: An ordered and evolving list of work that may improve a product.

Kanban: A flow-management method based on visualization, pull, explicit policies, and WIP limits.

Work in Progress (WIP): Work that has started but is not yet completed.

Lead Time: Time from a customer's request or commitment to delivery.

Cycle Time: Time from the start of active work to its completion.

Extreme Programming: An Agile approach emphasizing engineering practices such as TDD, pairing, integration, and refactoring.

Lean: A management philosophy focused on customer value, flow, waste reduction, and continuous improvement.

DevOps: A socio-technical approach integrating development, delivery, security, and operations.

Continuous Integration: Frequent integration of code changes with automated verification.

Continuous Delivery: Maintaining software in a deployable state through an automated, controlled process.

Infrastructure as Code: Managing infrastructure through version-controlled, executable definitions.

Observability: The ability to infer internal system behavior from outputs such as logs, metrics, and traces.

Service-Level Indicator (SLI): A measured aspect of service performance or reliability.

Service-Level Objective (SLO): A target value or range for an SLI over a specified period.

Error Budget: The permitted amount of unreliability implied by an SLO.

Site Reliability Engineering: An engineering discipline that applies software methods to service operations and reliability.

Blameless Post-Incident Review: A structured examination of an incident that focuses on system conditions and learning rather than individual blame.

Feature Flag: A mechanism that controls whether functionality is exposed independently of deployment.

Review Questions

Short Answer Questions

1. What is the relationship between transparency, inspection, and adaptation in empirical Agile work?

2. Define WIP and explain why WIP limits can improve flow.

3. Distinguish continuous delivery from continuous deployment.

4. What is an error budget, and how can it influence release decisions?

5. Why are logs, metrics, and traces collectively important for observability?

Long Answer Questions

1. Compare Scrum and Kanban in terms of planning, workflow, roles, timeboxing, and suitability for different types of work.

2. Explain how XP practices support rapid change while controlling technical debt and defect risk.

3. Describe the components of a secure and reliable DevOps delivery pipeline.

4. Explain the SRE model of SLIs, SLOs, and error budgets with an appropriate service example.

5. Discuss why Agile and DevOps transformations frequently fail when they focus on ceremonies and tools rather than organizational systems.

Analytical / Application Questions

1. A team completes many tasks but releases little customer value. Its board contains large queues in testing and approval. Use Lean and Kanban concepts to diagnose the problem and propose interventions.

2. A service meets its availability target but customers experience slow and failed transactions. Design a set of SLIs, SLOs, alerts, and incident practices that would reveal and address the problem.

3. An organization wants daily deployments but operates in a highly regulated environment. Propose a delivery model that combines progressive delivery, automated evidence, security controls, and appropriate human governance.

22. Multiple Choice Questions with Answers

Question 1

A team has many items started simultaneously, while cycle time continues to increase. Which intervention most directly addresses the likely flow problem?

A. Increase the number of items started each week

B. Introduce or tighten WIP limits

C. Measure individual lines of code

D. Lengthen the planning meeting

Correct Answer: B. Introduce or tighten WIP limits

Question 2

Which statement best distinguishes a service-level objective from a service-level agreement?

A. An SLO is a measured target, whereas an SLA is generally an external or contractual commitment

B. An SLO is always legally enforceable, whereas an SLA is internal

C. An SLO measures source-code quality, whereas an SLA measures team productivity

D. There is no meaningful distinction between them

Correct Answer: A. An SLO is a measured target, whereas an SLA is generally an external or contractual commitment

Question 3

A team deploys a new version to five percent of users, monitors payment failures, and stops expansion when failures increase. This is an example of:

A. Blue-green development

B. Canary or progressive delivery

C. Batch requirements analysis

D. Pair programming

Correct Answer: B. Canary or progressive delivery

Question 4

Which practice is most closely associated with Extreme Programming?

A. Large annual releases

B. Strict separation of developers and testers

C. Test-driven development and continuous integration

D. Approval of every code line by a central committee

Correct Answer: C. Test-driven development and continuous integration

Question 5

Why does an error budget help balance feature delivery and reliability?

A. It converts all reliability concerns into financial costs

B. It defines permitted unreliability and provides a basis for release-risk decisions

C. It guarantees that incidents cannot occur

D. It eliminates the need for service monitoring

Correct Answer: B. It defines permitted unreliability and provides a basis for release-risk decisions

Question 6

Which alert is most likely to be actionable?

A. A warning for every debug message

B. An alert whenever any server uses more than one percent CPU

C. An alert showing that successful customer transactions have fallen below the service objective

D. A daily message listing every application log

Correct Answer: C. An alert showing that successful customer transactions have fallen below the service objective

Question 7

In a blameless post-incident review, the primary analytical focus should be on:

A. Identifying and punishing the person who made the last change

B. System conditions, decisions, safeguards, and contributing factors

C. Removing all future changes from production

D. Increasing the number of status meetings

Correct Answer: B. System conditions, decisions, safeguards, and contributing factors

Question 8

Which statement best reflects Lean thinking in software engineering?

A. Every possible feature should be implemented before customer feedback is collected

B. Feature count is the only valid measure of value

C. Waiting, rework, unnecessary features, and excessive handoffs may represent waste

D. Testing is waste because it does not directly create features

Correct Answer: C. Waiting, rework, unnecessary features, and excessive handoffs may represent waste

Question 9

A product team uses Scrum events, Kanban WIP limits, XP engineering practices, and SRE error budgets. Which conclusion is most accurate?

A. These approaches are inherently incompatible

B. They can be combined when each addresses a distinct organizational or technical need

C. Using several approaches removes the need for governance

D. Only the Scrum Master can decide how production reliability is managed

Correct Answer: B. They can be combined when each addresses a distinct organizational or technical need

Question 10

Why should delivery metrics such as deployment frequency and change failure rate be interpreted together?

A. A single metric may encourage local optimization and hide deterioration elsewhere

B. Deployment frequency is unrelated to software delivery

C. Change failure rate cannot be measured

D. Combined metrics eliminate the need for professional judgment

Correct Answer: A. A single metric may encourage local optimization and hide deterioration elsewhere