How Many Metrics do You Need to Effectively Govern the Software Process?
A Simple Metrics-Driven Software Governance Framework Based on Jim Highsmith’s Agile Triangle Framework
In my recent Cutter Blog post entitled Three Governance Metrics I recommended using just three metrics:
- Value
- Cost
- Technical debt
The heart pf this recommendation is that all three can be expressed in dollar terms as depicted in the figure above. An apples-to-apples comparison is made through the common denominator – $$. For example, something is likely to be either technically, methodically or governance-wise wrong if the technical debt figure exceeds the cost figure for a prolonged period of time. One can actually characterize such a situation as accruing debt faster than building equity.
I am often asked about adding metrics to this simple governance framework. For example, should not productivity be included in the framework?
‘Less is more’ is my usual response to such questions. IMHO value, cost and technical debt address the most important high level governance considerations:
- Value –> Why are we doing the project?
- Cost –> Can we afford the project?
- Technical debt –> Is the execution risk acceptable?
Please pay special attention to the unit of measure of any metric you might add to this simple governance framework. As long as the metric is a dollar-based metric, the cohesion of the governance framework can be maintained. However, metrics which are not expressed in dollars will probably superimpose other frameworks on top of the simple governance framework. For example, you introduce a programming framework if you add a productivity metric which is measured in function points per man month. Sponsors who govern using value, cost, technical debt and productivity will need to mentally alternate between the simple governance framework and the programming framework whenever they try to combine the productivity metric with any of the other three metrics.
The Agile Executive 
The measure that I want to see here is time, but that may be implicit. The cycle time for releasing value is at the heart of Lean and Kanban, and I’m hesitant to let it go.
It may be implicit though in this, that “Value” is grown for a whole system of features.
Also, the NPV that will depreciate over time, in what Don Reinertsen calls a “cost of delay” curve.
Finally, I would suggest that TechDebt, unless specifically dealt with, increase over time because of the network effect described in Metcalfe’s Law – basically the more pieces the more entropy.
So perhaps if we see each of these three legs as a function of time we could conclude (all else remaining the same):
* NPV over time degrades (sometimes dramatically)
* Cost over time stays about the same
* TechDebt over time would increase
Cheers,
John
John Heintz
May 19, 2010 at 1:11 pm
It is not without a reason that they say “time is money…”
Specifically:
NPV is indeed likely to decline if the project slips. It might also change due to reassessment of the business case. Such a change could be either upward or downward.
Cost will grow over time. Some work must be done even if the product is in maintenance mode. And, as John points out, software decays over time.
Technical debt is an intriguing measure. One would hope that the sum {cost+technical debt} will remain constant for periods of time. Technical debt is converted to cost during such periods.
A ton of insights can indeed be gained by plotting the three (value, cost, technical debt) as a function of time. In particular, interesting things happen when the curves intersect. I have no doubt either John or I will soon publish more on the subject.
Stay tuned!
Israel
israelgat
May 19, 2010 at 1:56 pm
[…] As dev and ops are joined in the hip through the code, and even more so through its quality, technical debt is well suited to serve as the core of a boundary object around which the two department share […]
Beyond Devops « The Agile Executive
August 11, 2010 at 5:11 am
[…] is in the output of the software process. The ability to measure code quality enables effective governance of the software process. Moreover, Statistical Process Control methods can be applied to samples of technical debt […]
What 108M Lines of Code Tell Us « The Agile Executive
September 28, 2010 at 6:41 am