Metrics Misuse - Goodhart's Law

Now, metrics are not bad. But, they are often used in bad ways.

It might help to be aware of some of the side effects of mismanagement of metrics. From inadvertently creating behaviors that actively work against our best interest, to altering the meaning of the metric, mismanagement can do more harm than good.

Goodhart’s Law

Charles Goodhart is an economist and former advisor to the Bank of England. In 1975, Goodhart delivered two papers to a conference at the Reserve Bank of Australia. In those papers, Goodhart was discussing research and theory related to monetary policy and control in the United Kingdom. In the years leading up to 1975, existing monetary targets and the controls used to achieve the goals were no longer producing the results desired or expected. There had been what most considered to be evidence of a stable money demand in the United Kingdom. It was believed that the growth of money could be controlled through the setting of short-term interest rates. Higher interest rates correlated with lower money growth.

Goodhart warned, however, that policies and practices based on specific targets were flawed. Goodhart stated,

“Any statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”

Any statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
— Charles Goodhart

A common paraphrasing is, “When a measure becomes a target, it ceases to be a good measure.” When I talk about this, I tend to add, “And the target therefore no longer means what you think it does.”

Goodhart’s law is a critical piece of information when we think about metrics. No matter how tempting it might be, the moment we set a target for a measure, we’ve changed the system, thereby changing what the measurement means, thereby changing what the target means.

The lesson here is pretty simple. Don’t set targets for metrics. And please don’t give teams incentives towards targets if you do set them. I know. I know. Management 101 says this works. But, science says it doesn’t. Seriously. Setting targets and providing incentives for knowledge work lowers performance. Don’t do it.

Instead, provide guidelines to the teams. My favorite guideline for metrics is, “Monitor trending. Dig in when the trend changes and you aren’t absolutely certain why.”

This article is an excerpt from the book, “Escape Velocity”, available on LeanPub, Amazon, and elsewhere.

Refactor - You Keep Using That Word…

I stumbled upon a thread recently where the question was posed, “What are some common mistakes when refactoring code?”

The answers were interesting. The more I read, the more I realized that folks weren’t talking about the same thing. They were all saying “refactor”, but many were describing scenarios that sounded more like a rewrite rather than a refactor. This is not uncommon. I’ve encountered this on multiple forums, in slack discussions, in blog posts, and in actual human to human conversation (it happens).

Metric Misuse - The Hawthorne Effect

Now, metics are not bad. But, they are often used in bad ways.

It might help to be aware of some of the side effects of mismanagement of metrics. From inadvertently creating behaviors that actively work against our best interest, to altering the meaning of the metric, mismanagement can do more harm than good.

The Hawthorne Effect

Western Electric had commissioned an extensive study that ran from 1924 to 1932 at their Hawthorne Works in Cicero, IL. The intent of the study was to determine the impact of ambient lighting on worker productivity. Would employees be more productive under high levels of light or low levels of light? The workers in the factory were divided into two groups based on physical location within the plant. For one group, the lighting was increased dramatically while for the other group (the control) lighting levels remained the same. Researchers found that productivity improved among the group for whom lighting changed whereas the control group had no statistically significant change.

Employee working conditions were then changed in other ways. Working hours were adjusted, rest breaks were changed, floors were rearranged, workstations were kept cleaner, and several other adjustments were made, including returning the lighting back to normal levels and changing practices and policies back to original standards.

With every change, productivity made small improvements. By early 1932, and the end of the studies, the factory productivity was at an all-time high and employee attendance and retention were at record-setting levels. Some groups seemed to do better than others, but across the factory, all measures were improved.

When the studies ended, productivity, attendance, and retention soon returned to original levels.

The key takeaway from the Hawthorne studies is - that which gets measured will improve, at least temporarily. “The Hawthorne Effect” is described as the phenomenon in which subjects in behavioral studies change their performance in response to being observed.

This, at first, seems like a precious nugget of management gold.

  1. Measure productivity.

  2. Make it known.

  3. Ka-Pow! Increased productivity.

The perfect management formula.

But the reality was (and is), that while that which is being measured shows improvement, it does not mean the overall system has improved. Working longer hours can lead to employee fatigue and burn out, as well as lower quality. Lack of attention in areas not measured, such as quality or workplace safety, can lead to other negative outcomes.

If your team is slacking so significantly that merely measuring their velocity can result in a marked increase in velocity with no ill- effects, then you’ve a more serious issue at play than velocity.

What’s more, there is no guarantee that the thing being measured has actually improved. Velocity might have gone up because the team inflated story points. We should rephrase the key takeaway to that which gets measured will (appear to) improve.

This article is an excerpt from the book, “Escape Velocity”, available on LeanPub, Amazon, and elsewhere.

Remediating Technical Debt

I no longer believe we can return to the original, healthy and helpful definition of Technical Debt. Nor do I think we’re going to shift away from it to a better metaphor.

But maybe we can talk about remediation of Technical Debt in a way that helps us make better decisions.

The way I see it, Technical Debt Remediation is nothing more than Maintenance. Maintenance is to keep in an existing state (as of repair, efficiency, or validity) or to preserve from failure or decline.

Technical Debt Remediation (Maintenance) comes in different categories – Preventative, Deferred, and Repair.

The Experiment Canvas

In the past few years, we at OnBelay have had the honor of working with companies who are looking to improve their engineering culture.

One key tool we use today is the Experiment Canvas. My partner, Diane Zajac, and I co-developed the canvas. It is based heavily on our experience with A3s. It is still a work in progress, but I want to share with you where we are to date. Please feel free to use it and give us feedback.

Thoughts on Refactoring

Thoughts on Refactoring

I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.

Delivering Value

A while back, Jason Yip, tweeted about delivery of value and started an interesting thread.

Much of the discussion was about the definition of “value”. Is it specifically about revenue generation or direct customer benefit? Is it more generally about any form of value such as revenue, progress, or learning?

Troubleshooting Velocity

Troubleshooting Velocity

Recently, on a private forum, a member posted a query about their team’s recent drop in Velocity. Concerned about how their boss would respond, this individual wanted to know how to troubleshoot velocity issues.

After spending over an hour crafting a response, I decided I would also add it to my public blogs in case there are others who have similar questions about velocity.

Velocity Anti-Patterns - Attempts to show increased velocity

Velocity Anti-Patterns - Attempts to show increased velocity

When leadership asks for an increase in velocity, there are a few common behaviors that occur. Each of them are an attempt to satisfy the potentially unrealistic ask.

It is intriguing to me how often a manager will make a change such as this to a system of work and then later proclaim that the team is gaming the system. This is simply not the case. In fact, the gaming of the system is the improper application of targets or goals for lagging indicators. The rest is just natural consequence.

You can find more on the topic of velocity and metrics for agile teams in my book, "Escape Velocity".