Part 038 — Goodhart's Law, Gaming, Vanity Metrics, Cargo-Cult Scrum, and Systemic Failure Modes

Positioning

Scrum dan metrics dapat membantu delivery.

Namun ketika ritual dan angka menjadi tujuan, organisasi dapat terlihat “agile” sambil:

• kehilangan outcome;
• menyembunyikan risk;
• mendorong gaming;
• dan memperburuk sistem.

Core thesis: ketika metric menjadi target atau Scrum event menjadi ritual tanpa inspection dan adaptation, transparansi berubah menjadi theater.

1. Goodhart's Law

A common formulation:

When a measure becomes a target, it ceases to be a good measure.

Why?

Because people adapt behavior to the metric.

Examples:

• inflate story points;
• split tickets artificially;
• delay start dates;
• avoid logging defects;
• and release trivial changes to raise frequency.

2. Campbell's Law

The more a quantitative indicator is used for decision and pressure, the more it becomes vulnerable to corruption.

The issue is not malicious people.

It is incentive design.

3. Metric Gaming

Metric gaming occurs when behavior improves the number without improving the underlying system.

Examples:

• close and reopen tickets;
• count partial work as Done;
• exclude incidents from cycle time;
• move blockers outside board;
• and reduce test scope to improve completion.

4. Intentional versus Emergent Gaming

Intentional

People knowingly manipulate.

Emergent

People adapt rationally to incentives.

Example:

If velocity affects evaluation, teams learn to estimate larger.

Focus on system incentives, not only individual morality.

5. Proxy Metrics

A proxy stands in for a desired outcome.

Examples:

• velocity as productivity proxy;
• commits as contribution proxy;
• uptime as customer success proxy;
• meeting attendance as engagement proxy.

Proxies become dangerous when treated as the outcome itself.

6. Vanity Metrics

Vanity metrics look impressive but do not support action.

Examples:

• total commits;
• total test count;
• total story points;
• dashboard views;
• and cumulative tickets closed.

Ask:

What decision changes because of this number?

7. Metric Weaponization

Metric weaponization occurs when system data is used to:

• rank individuals;
• punish teams;
• or enforce arbitrary targets.

Consequences:

• hiding;
• risk avoidance;
• and trust loss.

8. Individual Productivity Metrics

Dangerous examples:

• lines of code;
• tickets closed;
• story points completed;
• PR count;
• review comments;
• online hours;
• and message count.

Software delivery is collaborative and system-dependent.

9. Velocity Misuse

Valid:

• local historical planning input.

Invalid:

• cross-team comparison;
• target growth;
• performance evaluation;
• and contractual commitment.

Velocity target leads to point inflation.

10. Story-Point Inflation

Symptoms:

• same work gets more points;
• velocity rises without throughput;
• estimates become political.

Root cause:

• velocity used as success metric.

11. Ticket-Splitting Gaming

Artificial splitting can increase throughput count.

Healthy splitting:

• coherent value;
• lower risk;
• faster feedback.

Gaming:

• separate trivial technical steps solely to raise counts.

12. Cycle-Time Gaming

Examples:

• start clock later;
• pause clock during blocker;
• mark Done before validation;
• exclude difficult work;
• and reset ticket.

Countermeasure:

• stable definitions;
• audit workflow behavior;
• and use multiple signals.

13. Deployment-Frequency Gaming

Examples:

• deploy trivial changes;
• count non-production environments;
• split deployment artificially.

Deployment frequency only matters with:

• value;
• quality;
• and stability.

14. Change-Failure Gaming

Examples:

• redefine incident;
• avoid rollback classification;
• hide hotfix;
• and downgrade severity.

Need clear definition and safe reporting culture.

15. Defect-Metric Gaming

Examples:

• do not log bugs;
• reclassify as enhancement;
• close as cannot reproduce;
• and count defects against reporter.

Result:

• worse quality with better dashboard.

16. Test-Coverage Gaming

Examples:

• tests without assertions;
• testing trivial getters;
• excluding difficult code;
• and maximizing percentage over behavior.

Coverage is diagnostic, not proof.

17. SLA Gaming

Examples:

• close ticket before real resolution;
• restart SLA;
• provide superficial first response;
• and avoid accepting ownership.

Measure customer outcome, not only timer.

18. RAG Status Gaming

Green status persists until deadline.

Why:

• red status punished;
• escalation seen as failure;
• and evidence unclear.

Healthy culture rewards early amber/red.

19. Dashboard Theater

Signs:

• many charts;
• no decisions;
• stale data;
• and no owner.

Dashboard is not transparency if no one trusts definitions.

20. Metric Cascade Risk

Leadership target is translated down into increasingly local proxies.

Example:

Goal:
Faster customer value

Becomes:
More releases

Becomes:
More deployments

Becomes:
More commits

At each step, meaning is lost.

21. Composite Score Risk

A single delivery-health score can hide trade-offs.

Weighting:

• subjective;
• easy to game;
• and hard to interpret.

Prefer a small balanced set with narrative.

22. Benchmark Misuse

Comparing teams may ignore:

• product age;
• architecture;
• regulation;
• support load;
• and work type.

Benchmark systems, not people.

23. Target versus Threshold

Target

Desired optimization.

Threshold

Boundary requiring attention.

Some metrics are better as guardrails than targets.

Example:

• change failure below threshold;
• not “zero failures at all cost”.

24. Zero-Defect Target

A zero-defect target may encourage:

• underreporting;
• low-risk avoidance;
• and slow delivery.

Aim for:

• risk-based quality;
• fast detection;
• and learning.

25. 100% Utilization

High utilization increases queue time.

A system with no slack cannot absorb:

• review;
• incident;
• and variation.

100% utilization is not healthy efficiency.

26. 100% Sprint Completion

If teams are punished for carry-over, they may:

• undercommit;
• split late;
• hide scope;
• and lower quality.

Sprint forecast is not a contract.

27. Deadline Hit Rate

Hitting dates may be achieved by:

• cutting scope;
• cutting quality;
• delaying reporting;
• or working unsustainably.

Always inspect what changed.

28. Scrum Theater

Scrum theater means Scrum terminology and events exist, but empirical control does not.

Signs:

• Planning without real forecast;
• Daily Scrum as status;
• Review as demo theater;
• Retrospective without action;
• Product Owner without authority;
• and Definition of Done ignored.

29. Cargo-Cult Scrum

Cargo-cult Scrum copies practices without understanding purpose.

Examples:

• using story points because “Scrum requires it”;
• enforcing three Daily Scrum questions;
• creating a Scrum Master as meeting secretary;
• and treating Sprint as mini-waterfall.

30. Scrum Is Not a Ticket System

A board can support Scrum.

But Scrum is about:

• goals;
• empiricism;
• self-management;
• and value.

A perfectly updated board can coexist with poor product outcomes.

31. Sprint as Mini-Waterfall

Pattern:

Days 1–5: analysis
Days 6–8: development
Days 9–10: QA

Consequences:

• late feedback;
• carry-over;
• and phase handoff.

32. Planning Theater

Symptoms:

• scope pre-assigned;
• capacity ignored;
• velocity target imposed;
• goal invented afterward;
• and no risk discussion.

33. Daily Scrum Theater

Symptoms:

• each person reports to manager;
• no plan changes;
• blockers repeat;
• and Sprint Goal never mentioned.

34. Refinement Theater

Symptoms:

• stories read aloud;
• no examples;
• no slicing;
• no dependency readiness;
• and estimates forced.

35. Review Theater

Symptoms:

• only polished happy path;
• no stakeholders with authority;
• no feedback;
• no backlog adaptation;
• and limitations hidden.

36. Retrospective Theater

Symptoms:

• same template;
• vague actions;
• no owner;
• no follow-through;
• and sensitive topics avoided.

37. Product Owner Theater

A Product Owner title exists, but:

• cannot order backlog;
• decisions require committee;
• and stakeholder pressure bypasses role.

This creates queue and ambiguity.

38. Scrum Master Theater

Scrum Master becomes:

• meeting scheduler;
• ticket police;
• and status collector.

Instead of:

• improving Scrum effectiveness;
• coaching;
• and removing systemic impediments.

39. Self-Management Theater

Team is called self-managing, but:

• manager assigns work;
• architecture approves every decision;
• and estimates are overruled.

Autonomy without decision rights is theater.

40. Cross-Functional Team Theater

Team includes multiple roles, but work still flows through:

• analysis handoff;
• development handoff;
• QA handoff;
• and release handoff.

Presence of roles does not equal collaboration.

41. Definition of Done Theater

DoD exists in a document but:

• testing omitted under pressure;
• observability deferred;
• and integration happens later.

A standard not applied is not a real standard.

42. Goal Theater

Sprint Goal exists, but:

• is a list of tickets;
• never used in Daily Scrum;
• and does not guide scope changes.

43. Backlog Theater

Backlog contains:

• hundreds of stale items;
• no ordering rationale;
• and hidden engineering work.

A large backlog is not product clarity.

44. Ceremony Compliance

Success is measured by:

• attendance;
• meeting completion;
• and template usage.

The purpose of each event is forgotten.

45. Process over Outcome

Signs:

• “we followed Scrum” after failed product outcome;
• no adaptation;
• and process defended regardless of evidence.

Process is a means.

46. Outcome without Process Discipline

The opposite anti-pattern:

• occasional success through heroics;
• no repeatability;
• and hidden risk.

Outcome alone does not validate unsafe process.

47. Hero Culture

Hero culture rewards:

• emergency rescue;
• after-hours work;
• and knowledge concentration.

It hides:

• brittle systems;
• poor planning;
• and weak ownership distribution.

48. Bus-Factor Theater

Organizations claim shared ownership, but:

• one person reviews;
• one person releases;
• and one person handles incidents.

Map actual dependency.

49. Agile Theater with Fixed Everything

If:

• scope;
• date;
• capacity;
• and quality

are all fixed, Sprint adaptation is impossible.

The language may be agile, but control model is not.

50. Water-Scrum-Fall

Pattern:

• upfront project planning;
• Scrum-like implementation;
• big-bang release and governance.

Local Scrum cannot overcome system-level batch constraints.

51. Fake Empowerment

Team is told to own outcome, but lacks:

• product access;
• environment;
• deployment rights;
• and decision authority.

Accountability without authority creates frustration.

52. Hidden Work

Engineering work done outside backlog leads to:

• invisible capacity;
• stakeholder surprise;
• and distorted metrics.

Transparency requires all material work visible.

53. Shadow Backlog

Separate private lists for:

• debt;
• bugs;
• architecture;
• and incidents.

These may be useful views, but must connect to product decisions.

54. Capacity Theater

Capacity is calculated precisely, but ignores:

• support;
• meetings;
• incidents;
• and coordination.

The result looks scientific but is false.

55. Estimation Theater

Symptoms:

• long debates;
• no better forecast;
• points used as commitment;
• and estimates manipulated.

Estimate only when it supports a decision.

56. Forecast Theater

A deterministic date is reported despite:

• unstable scope;
• dependency;
• and no historical data.

Confidence and assumptions are omitted.

57. Risk Theater

Risk register exists, but:

• statuses stay green;
• no trigger;
• no fallback;
• and no owner.

A risk without action is reporting theater.

58. Escalation Theater

Symptoms:

• many people copied;
• no decision ask;
• blame language;
• and no deadline.

Escalation should move authority, not emotion.

59. Incident Theater

Processes exist, but:

• no role clarity;
• no timeline;
• no CAPA follow-through;
• and repeat incidents.

Postmortem documents alone do not create reliability.

60. Reliability Theater

SLOs exist, but:

• do not reflect user journey;
• no error-budget policy;
• and no delivery decision changes.

61. Security Theater

Examples:

• checklists without threat context;
• approvals without evidence;
• and compliance status used as proof of security.

Security requires actual controls and validation.

62. Quality Theater

Examples:

• high coverage;
• flaky tests;
• manual reruns;
• no failure testing;
• and frequent hotfixes.

Quality must be observed in outcomes.

63. Platform Theater

Platform team builds many capabilities, but:

• adoption is low;
• consumers still file tickets;
• and support burden rises.

Platform output is not platform value.

64. Architecture Theater

Symptoms:

• many diagrams;
• centralized approval;
• no operational ownership;
• and architecture disconnected from delivery.

65. Documentation Theater

Documents exist, but:

• stale;
• duplicated;
• and no one uses them.

Documentation value is in decision and execution support.

66. Remote-Work Theater

Remote-first is claimed, but:

• decisions happen in calls;
• timezones are ignored;
• and online presence is monitored.

67. Psychological-Safety Theater

Leaders say “speak up,” but punish:

• bad news;
• red status;
• and disagreement.

Behavior, not slogan, determines safety.

68. Blameless Theater

Postmortem says “blameless,” but action focuses on:

• retraining one person;
• and stricter personal compliance.

True blamelessness analyzes system conditions.

69. Continuous-Improvement Theater

Retro actions exist, but:

• no capacity;
• no owner;
• and no measurement.

Improvement becomes ritual.

70. Learning Theater

Training sessions are frequent, but:

• no real practice;
• no changed behavior;
• and no product connection.

71. Metric Smell Catalog

Single metric dominates

Behavior distorts.

Target without baseline

No context.

Metric without owner

Decay.

Metric without decision

Vanity.

Metric without denominator

Misleading.

Metric without segmentation

Hidden variation.

Metric tied to compensation

Gaming risk.

Metric definition changes silently

Invalid trend.

72. Process Smell Catalog

Repeated carry-over

Likely WIP or slicing issue.

Last-day testing

Phase-based flow.

Many blockers

Dependency or ownership problem.

Review queue

Knowledge bottleneck.

Frequent hotfix

Release or quality problem.

Same retro topic

No follow-through.

Endless backlog

No product focus.

73. Systemic Failure versus Individual Failure

Before attributing failure to a person, inspect:

• policy;
• incentives;
• workload;
• information;
• tooling;
• and authority.

Individuals still have accountability, but system factors matter.

74. Incentive Mapping

Ask:

What behavior does this policy reward?
What behavior does it punish?
What will a rational team do?
What will be hidden?

75. Local Optimization

Examples:

• developer maximizes ticket completion;
• QA maximizes defect detection;
• operations minimizes change;
• product maximizes scope.

The whole system may worsen.

76. Queue Hiding

Teams hide queues by changing labels:

• “Ready for QA”;
• “Awaiting acceptance”;
• “Technically done”.

If value is not Done, the system still has WIP.

77. Dependency Externalization

Saying:

Blocked by another team.

may hide:

• late request;
• unclear contract;
• no fallback;
• and weak escalation.

Inspect the full relationship.

78. Quality Externalization

Saying:

QA missed it.

hides shared responsibility.

Inspect:

• acceptance;
• testability;
• review;
• and environment.

79. Product Externalization

Saying:

Product changed scope.

may hide:

• weak discovery;
• no goal;
• or unclear decision rights.

80. Architecture Externalization

Saying:

Architecture blocked us.

may hide:

• no pre-read;
• late review;
• or high-risk decision.

Also inspect whether governance itself is a bottleneck.

81. Anti-Pattern Detection through Contradictions

Look for contradictions:

• “self-managing” but tasks assigned;
• “quality first” but tests cut;
• “remote-first” but decisions verbal;
• “blameless” but individuals ranked;
• “outcome-focused” but velocity target;
• “continuous delivery” but monthly integration.

82. Corrective Principle: Reconnect to Purpose

For every practice, ask:

What purpose does it serve?
What evidence shows it works?
What happens if we stop?
What is the smallest useful form?

83. Corrective Principle: Use Balanced Signals

Pair optimization metrics with guardrails.

Examples:

• faster delivery + change failure;
• higher throughput + cycle time;
• more releases + customer outcome;
• lower incidents + reporting safety.

84. Corrective Principle: Separate Measurement from Evaluation

Use metrics for:

• system improvement;
• and forecasting.

Avoid using the same metric for:

• individual reward;
• and diagnostic learning.

85. Corrective Principle: Make Bad News Safe

Early red status should be rewarded with support.

If red status is punished, green status becomes fiction.

86. Corrective Principle: Stable Definitions

Document:

• start;
• end;
• scope;
• exclusions;
• and data source.

Audit changes.

87. Corrective Principle: Review Incentives

Before introducing a KPI:

• simulate gaming;
• identify guardrail;
• and define review date.

88. Corrective Principle: Retire Metrics

Metrics should be removed when:

• decision no longer exists;
• behavior is stable;
• data cost exceeds value;
• or gaming dominates.

89. Corrective Principle: Inspect Outcomes

Ask:

• Did customer outcome improve?
• Did risk decrease?
• Did quality remain healthy?
• Did sustainability worsen?
• Did team capability grow?

90. Scrum Recovery: Planning

Restore purpose:

• define Sprint Goal;
• inspect capacity;
• and create a forecast.

Remove:

• manager assignment;
• velocity target;
• and hidden fixed scope.

91. Scrum Recovery: Daily Scrum

Restore purpose:

• inspect goal;
• manage WIP;
• adapt plan.

Remove:

• status reporting;
• and person-by-person control.

92. Scrum Recovery: Review

Restore purpose:

• inspect Increment;
• gather stakeholder evidence;
• and adapt backlog.

Remove:

• polished theater;
• and passive audience.

93. Scrum Recovery: Retrospective

Restore purpose:

• inspect system;
• choose experiment;
• and follow through.

Remove:

• vague actions;
• and blame.

94. Scrum Recovery: Product Backlog

Restore:

• ordering;
• outcome;
• engineering work visibility;
• and risk.

Remove:

• stale inventory;
• and proxy priority.

95. Anti-Pattern Intervention Ladder

1. Observe.
2. Gather evidence.
3. Name the pattern neutrally.
4. Explain consequence.
5. Propose small experiment.
6. Measure.
7. Escalate systemic constraint if needed.

96. Neutral Pattern Language

Use:

The current process rewards ticket completion over Sprint Goal completion.

Not:

The team is gaming velocity.

Use:

Review latency indicates decision authority is concentrated.

Not:

The architect is blocking everyone.

97. Senior Engineer Role

A senior engineer should:

• identify system contradictions;
• challenge metric misuse;
• explain incentives;
• and propose evidence-based experiments.

They should not become cynical or reject all process.

98. Senior Engineer and Metrics

Responsibilities:

• clarify definitions;
• prevent misuse;
• expose blind spots;
• and connect metrics to decisions.

Avoid:

• dashboard worship;
• or refusing measurement entirely.

99. Senior Engineer and Scrum Theater

Help restore:

• goal;
• empiricism;
• and adaptation.

Do not police ceremony mechanically.

100. Senior Engineer and Psychological Safety

Model:

• bad-news reporting;
• honest uncertainty;
• and willingness to challenge harmful KPI.

101. Senior Engineer and Leadership

When escalating metric misuse:

Observed behavior:
Metric/incentive:
System consequence:
Evidence:
Alternative:
Experiment:

102. Worked Example: Velocity Target

Policy

Increase velocity 20%.

Emergent behavior

• inflated estimates;
• more tickets;
• no faster delivery.

Evidence

• story points rise;
• throughput stable;
• cycle time worsens.

Intervention

Remove target.

Use:

• throughput distribution;
• Sprint Goal outcome;
• and quality guardrails.

103. Worked Example: Green Status Culture

Pattern

All projects green until final week.

Incentive

Red status triggers blame.

Consequence

No options remain when risk is acknowledged.

Intervention

• define amber triggers;
• reward early escalation;
• require mitigation and owner;
• and review forecast confidence.

104. Worked Example: Review Theater

Pattern

Every Review shows UI happy path.

Missing

• operational evidence;
• stakeholder decision;
• and backlog adaptation.

Intervention

Use:

• Product Goal context;
• limitations;
• feedback classification;
• and decision log.

105. Worked Example: 100% Utilization

Policy

Everyone must be fully assigned.

Outcome

• high WIP;
• review queue;
• slow incidents;
• and long cycle time.

Intervention

• team-level WIP limit;
• review-first policy;
• and explicit capacity buffer.

106. Worked Example: Test Coverage Target

Target

95% coverage.

Behavior

• trivial tests;
• meaningful integration gaps;
• and slow suite.

Intervention

Use:

• critical-path coverage;
• mutation testing for domain logic;
• escaped defects;
• and test feedback time.

107. Worked Example: Scrum Event Compliance

Organization

Tracks whether every event occurred.

Missing

• goal quality;
• decisions;
• and adaptation.

Better approach

Inspect:

• Sprint Goal success;
• Review backlog changes;
• Retro action completion;
• and blocker resolution.

108. Worked Example: Hidden Incident Work

Pattern

Incident response excluded from Sprint metrics.

Result

Team appears to miss commitment repeatedly.

Intervention

• make unplanned work visible;
• update capacity;
• and use historical incident reserve.

109. Anti-Pattern Diagnostic Template

## Observed Pattern

## Intended Purpose

## Actual Behavior

## Incentive

## System Consequence

## Evidence

## Proposed Experiment

## Guardrail

## Review Date

110. Metric-Risk Checklist

Before using a metric:

• Can it be gamed?
• What behavior will it reward?
• What will be hidden?
• Is it team/system level?
• Is a guardrail needed?
• Is definition stable?
• Is it tied to compensation?
• Can it be retired?

111. Scrum-Health Checklist

Planning

• Goal-first?
• Capacity real?
• Scope flexible?
• Quality included?

Daily Scrum

• Adaptation occurs?
• WIP visible?
• Blockers owned?

Review

• Stakeholders engaged?
• Increment inspected?
• Backlog adapts?

Retrospective

• System focus?
• Experiment selected?
• Follow-through?

112. Delivery-Anti-Pattern Checklist

• High WIP?
• Long queues?
• Repeated hotfix?
• Hidden work?
• Centralized decision?
• Fixed everything?
• Hero culture?
• Metric gaming?
• Customer outcome absent?
• Sustainable pace ignored?

113. Internal Verification Checklist

Metrics

• Which metrics are targets?
• Which affect evaluation or compensation?
• Are teams compared?
• Are definitions documented?
• What gaming has been observed?

Scrum

• Are events used for their intended purpose?
• Does Product Owner have authority?
• Is Sprint Goal meaningful?
• Does Review change backlog?
• Are retro actions followed?

Culture

• Is red status safe?
• Are defects reported openly?
• Is after-hours heroism rewarded?
• Can teams challenge KPIs?
• Is psychological safety measured through behavior?

Governance

• Are dashboards decision-oriented?
• Can metrics be retired?
• Are guardrails used?
• Are process exceptions documented?
• Are leadership incentives aligned?

114. Practical Exercises

Exercise 1 — Goodhart analysis

Choose one current metric and predict how it could be gamed.

Exercise 2 — Scrum-theater audit

Assess each Scrum event by intended purpose versus actual behavior.

Exercise 3 — KPI rewrite

Replace one activity target with a balanced system signal.

Exercise 4 — Incentive map

Map policy, rewarded behavior, hidden behavior, and system consequence.

Exercise 5 — Anti-pattern experiment

Design a small intervention for one recurring delivery smell.

Exercise 6 — Metric retirement

Identify one metric whose reporting cost exceeds decision value.

115. Part Completion Checklist

You are done if you can:

• explain Goodhart's Law;
• identify proxy and vanity metrics;
• detect gaming and weaponization;
• recognize Scrum theater;
• distinguish local from system optimization;
• analyze incentives;
• restore event purpose;
• and design safer balanced measurement.

116. Key Takeaways

1. Measures change behavior.
2. Metrics become dangerous when treated as targets.
3. Individual software productivity metrics are misleading.
4. Velocity should not compare teams.
5. Scrum events without inspection and adaptation are theater.
6. Ceremony compliance is not agility.
7. Early bad news must be safe.
8. Balanced signals and guardrails reduce gaming.
9. Senior engineers should challenge incentives, not reject measurement.
10. Internal KPI and Scrum practices must be verified.

117. References

Conceptual baseline:

• Goodhart's Law, Campbell's Law, systems thinking, and incentive-design concepts.
• General Scrum anti-pattern, Agile transformation, flow, quality, and delivery-governance practices.
• Psychological safety, blameless learning, and engineering-measurement principles.

These concepts do not describe internal CSG processes.