Lean Metrics for Agile Software Configuration Management

This month we take an "agile" slant on metrics for software configuration management (SCM), including the SCM process itself. Agile software development is supposed to be people-centric and value-driven. So any metrics related to agility should, at least in theory, provide some indication of the effectiveness of the value-delivery system and how well it supports the people collaborating to produce that value.

We borrow heavily from the concepts of Lean Production  and a little from the Theory of Constraints . Let's see where it takes us ....

Back to Basics: Agility is People-centric and Value-driven
I'm a big fan of rhyme & reason for metrics, and I value the essence of Victor Basili's GQM paradigm (Goal-Question-Metric) in providing the rational behind a metric. One of the more famous quotes from TOC founder Eliyahu Goldratt goes something like " Tell me how you will measure me, and I will tell you how I will behave! " That's a very appropriate source for this column because much of Agile methods borrowed heavily from the concepts of Lean and TOC, so it makes sense to see what they have to say on the subject of metrics for Agile CM environments.

Agility, at its core, is predicated on the rapid delivery & production of business value via the power of the people who produce it! In terms of what to do, and what to stop doing, both Lean and TOC have a similar and relentless focus:

• Lean focuses ruthlessly upon "flow", and the elimination of waste (or what it calls "muda")
• TOC focuses on "throughput", and the elimination of constraints/bottlenecks

To the extent that "flow" and "throughput" are talking about the same thing, both Lean and TOC seem (almost) perfectly aligned. The question is, what is the "flow" whose "throughput" needs to be maximized and optimized? David J. Anderson in his book and related articles suggests that Agile, Lean and TOC converge and complement each other when we consider business-value as the "thing" whose flow and throughput are to be optimized. The first of the principles behind the agile manifesto states:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. "

and the Agile Project Leadership Network 's project management declaration of interdepedence describes results they strive for by leading them off with:

"We increase return on investment by making continuous flow of value our focus. "

That pretty much settles it for me: the overarching goal is the continuous delivery of working software that realizes maximal business value and ROI. So the ideal for a metric about the CM process would be to actually measure and report the overall ROI of CM to the business. This elusive CM ROI measurement is highly sought after by many CM practitioners, some might even call it a "silver bullet" for proving the worth of CM. We won't be quite so ambitious in this column, but we will look at how to measure aspects of CM for their impact on the overall value delivery system.

Cumulative Flow and Throughput Accounting
How do we attempt to measure business value and its flow for product development? For software development it would mean measuring the "value" of the software that was delivered. And that value is determined by how much the customer will pay for it at the time of delivery -- such value can depreciate over time, making time-to-market (lead-time) a critical concern in product feature definition and development. David Anderson actually proposes a throughput accounting system for software management and also writes of managing lean software development with cumulative