Fallacy of the Week - Use and Misuse of Goodhart's Law

Goodhart's Law states when a feature of the economy is picked as an indicator of the economy, then it inexorably ceases to function as that indicator because people start to game it. 

Without a Macro Economics context, the Law is misstated and misused by many in the agile community to suggest that setting goals, assigning units of measure to those goals, and managing work in the presence of uncertainty creating risk to cost, schedule, and technical performance goals lays the groundwork for business failure. 

From #NoEstimates advocates to simple and simple-minded claims that goal setting is the basis of failure, the lack of understanding of how a closed-loop control system is the basis of all success.

There is no doubt metrics are misused and abused.  

But the first fallacy is we confuse the symptom with cause. What are the root causes of the misuse of metrics? Root Cause Analysis requires we find:

• The conditions that allow the cause to exist
• The actions that were taken by the participants in the failure in the presence of the Conditions

Before any control system can be effective, we must find the Root Cause(s) of the undesired performance. And only then, by taking corrective and preventive actions to eliminate or reduce the conditions and prevent the actions can improvements be made.

To assess if these corrective and preventive actions are effective, we need measures and goals to apply the measure to.

So when you hear Goodhart's Law When the Measure Becomes the Target, It Ceases to be a Good Measure is not only nonsense, it willfully ignores the immutable principles of Closed-Loop Control Systems where information flows around a feedback loop from the process to the sensor to the transmitter to the controller to the actuator and back to the process.

This measure-decide-actuate sequence-known as closed-loop control-repeats as until the desired process condition is achieved. 

That process condition is a GOAL. 

• Keep the living room at 74℉
• Keep my car speed at 70 MPH on I-70 headed to Vail, so we don't miss the start of racing for our kids
• Keep the airliner flying at 28,000 at Mach .75 so we arrive at LAX as scheduled
• Peddle faster to catch up with our planned time on the Boulder Triathlon course to hold our position overall
• Keep delivering the planned list of Features in this release of software so we can make the integration and test date for the test chamber we've reserved at Ball Aerospace across town.

Now since all processes operate in the presence of uncertainty - reducible (Epistemic) and irreducible (Aleatory) our system, its control, and its measurement mandate we have cost, schedule, and technical margin for those irreducible uncertainties and buy down activities for those reducible activities, which a part of the SYSTEM in the picture below.

But those actions (corrective and preventive) for Epistemic uncertainty and Margin Burndown for Aleatory uncertainties require we measure their effectiveness and performance to be assured they are in fact keeping us on track for success.

No non-trivial (de minimus) activity  (project, system, or process) can be successful in the absence of a close loop control system. That system must have a goal, feedback on the performance to date toward that goal, and the corrective and preventative actions needed to keep the outcomes of our efforts on the plan toward that goal. 

To say that Goals are not needed or Goals will cause failure willfully ignores the principles of Closed Loop Control, which starts with the Reference Input - The Goal, measures the current system state in comparison to that reference or Goal, takes corrective actions in the Controller to influence the System to comply with the Goal, then senses the current state of the system to confirm or deny if the output of the controller has in fact made the right commands to keep the systems compliant with the Goal.

Every organization asks the question: 

• Do we know the units of measure of the result we desire - their effectiveness and performance?
• Are we achieving the results we desire?
• If not, what corrective or preventive actions are needed to get in compliance with the results we desire?
• How often do we sample the system to confirm we are getting the results we desire? This is a Nyquist Sampling Principle question - how often do we need to sample "progress to plan" to have a credible closed-loop control system?

So when Goodhart's Law is misused and abused like When a Measure Becomes Target, It Ceases to be a Good Measure and there is no domain or context stated, it's a fallacy.

1. "Beyond Objects: A Software Design Paradigm Based on Process Control," Mary Shaw, CMU-CS-94-154
2. "Software Engineering Meets Control Theory," Antonio Filieri, et al
3. "Organizing Software Project Control Practices," Rohaya Ahmad, Hasmiah Kasimin, Maryati Mohd Yusof,
   and Abdul Razak Hamdan, International Journal of Information and Electronics Engineering, Vol. 1, No. 2, September 2011.
4. "Is There an Underlying Theory of Software Project Management?" Glen B. Alleman, Version 5.0, 29 June 2015.
5. "Using Metrics to Demonstrate the Value of Project Management," Susan O'Hara and Ginger Levin, Project Management Institute Annual Seminar, 2000