Taking an lean-agile slant on metrics for configuration management, the authors focus on ways to measure the value CM and SCM adds to the project and product and how to measure flow and waste.
This month we take an "agile" slant on metrics for CM, including the CM process itself. Agility 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 performance and 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, a.k.a. TOC). Let's see where it takes us.
Back to Basics: Agility Is People-Centric and Value-Driven
I'm a big fan of rhyme and 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."
"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 flow.
I'll let readers pore through those articles rather than repeat them here. The basic gist is still the same, namely treating software/product development as a continuous flow of value through a value-delivery stream and applying basic throughput accounting (from TOC) and Lean techniques (such as cumulative flow diagrams).
CM in the Value-Stream
Now is the time to discuss the role of CM in the value-delivery stream of software development. Lean uses a lot of Japanese terms, and Mary Poppendieck once told me in an email correspondence that CM was vitally important in Lean - if it had been assigned a single word name and meaning in the "Lean vocabulary" then she thinks it probably would have translated to the word "order" (others in the CM world might prefer the term "integrity").
CM ensures product integrity by establishing & maintaining an orderly flow of the value stream and its evolution. That value stream begins with the process for assessing, approving, and authorizing requests (for projects/products and their changes); and it ends with the delivery of value that has been realized by reliably integrating and assembling it in repeatable, reproducible and traceably transparent fashion!
So two of the most prominent places where CM plays a role in the value stream are the front-end process for managing requests, and the back-end process for establishing baselines and managing their build/integration/assembly. And of course if we are delivering value "continuously" then we are also continuously performing request management/prioritization as well as build/integration management. Let's take a look at how some of the concepts of Lean apply to these portions of the Agile development process and the metrics that are suggested by them!
Being ever so Takt-full
One very obvious metric well aligned with lean is average end-to-end cycle-time for realizing the value of a request. The clock starts ticking when the request first arrives and stops when the implemented solution for that request is delivered to the requesting customer. ITIL circles might recognize this as resolution cycle-time. Closely related to the average resolution-rate is the metric for the average arrival-rate of requests. The intent is to apply them to the end-to-end scale to achieve a closed-loop with the customer.
These can additionally be applied internally to a CM group managing requests to build/integrate/release a version of the product or system. When multiple levels of integration are required, this can (and probably should) be applied to the entire integration pipeline, starting from the lowest-level integration/build request and ending when the complete (top-level) product or system has been baselined and released.