Compliance Metrics

July 01, 2020

People will try their best to follow a framework, especially if it is prescribed by someone who is seen as an expert. Though the framework can itself be useful, religious compliance to the framework's metrics can distract from the goals that the framework is supposed to help with.

Velocity, throughput, cycle time and any other metric should be subject to this scrutiny. If the goal is to continuously deliver value to your customers then the evaluation of value must happen outside the framework's scope. The framework's metrics are at best a weak proxy to the value delivered. We may be following a particular process very well but the process may not generate the required outcomes.

This is a fundamental issue in adopting any framework whether it be on the manufacturing floor, software delivery, or professional services. In software delivery, throughput can be a dangerous metric to evaluate value delivered because it measures whether something was delivered, not whether people are using the feature.

GAAP provides a framework of guidelines on how to report financial results. How well we are able to reflect reality within GAAP's constructs is what is seen to be the financial state of a company. The nicety of GAAP is that it is considered "generally acceptable" and those who evaluate the results (e.g., auditors, analysts) share a common understanding of the nuances of reporting. This is in sharp contrast to software delivery metrics where there is high variability in how people understand the metrics and even higher variability in how they perceive the metrics can be moved in the "right" direction.

GAAP is an excellent example of how a framework has created shared understanding and practices while allowing for leeway in reporting and interpretation. To me, there is no equivalent in the software industry.