Lean Metrics for Agile Software Configuration Management


Those metrics are probably nothing new to veteran practitioners. However, another closely related concept in Len might very well be, and that is the concept of Takt time. Blogger Peter Abilla writes many informative articles about Lean concepts and theory(go see his series of articles on Lean/TPS and Queing theory). Abilla describes Takt-time as follows:

Takt time comes from a German word 'takt', which means rhythm or beat. Takt time is not the same thing as Cycle Time or Lead Time, though Takt Time has a very real relationship to both. Takt Time must be measured through a simple calculation:

(Takt Time) = (Net Available Time per Day / Customer Demand per Day)

Takt time is measured as (Time/Piece), not the other way around. This is important because the operator knows that he or she only has so much time per x. ... to a large measure, Takt Time is about the maintenance of 'Flow', which is very important in queueing efficiency.

The 'Batch' is back!
Also from Lean production come the notions of process-batches and transfer-batches (especially batch processing-time versus batch transfer-time). The time to "process" a batch (batch processing time) is the amount of time it takes to create or produce the elements in the batch. The batch "transfer-time" is the amount of time it takes to transfer one or more "batches" into the value-stream. A "transfer batch" may encompass more than one "processed batch", but the alleged ideal is when the transfer batch-size is equal to the process batch-size (a concept called single-piece flow). When the batch transfer-time approaches the batch processing-time, then single-piece-flow no longer produces optimal results.

One of the conclusions of Lean is that small "batch-sizes" are key to optimizing the flow of the value-delivery stream. For software development, this is basically saying iterative & incremental development utilizing evolutionary delivery is a critical success factor (nothing new here). A "batch" can take many forms: a "batch" of features for an iteration, a "batch" of changes for a build, a "batch" of modifications for a change, etc. We'll discuss applicability to some of those a bit later in this article.

Measures of Continuous and Reliable Flow
The word "continuous" keeps popping up in discussions of Agile development. We have continuous integration, continuous flow, continuous value-delivery, continuous testing/review, etc. In most cases, these activities aren't truly continuous, they are just always ongoing with very high frequency. But continuous has another meaning here besides ultra-high frequency; it also means always "ready", as in always available, serviceable, or of "shippable quality." This relates to being "agile" in response to changes in the (business) environment.

So in addition to measuring and monitoring the "frequency" of those things that are supposed to be continuous (like integration), concepts and measures of system availability, reliability and survivability also apply:

  • If the build is broken, it is akin to a "system outage" of the integration codeline used by developers
  • If the request/order processing queue is blocked for any reason, the development & implementation process may starve from a lack of timely requirements input

Identifying Waste and Bottlenecks
Measuring value and its "flow" isn't enough. If we wish to improve and optimize that process, we need insight into what is impeding the flow of value and what is not adding value (and hence producing waste). According to Mary and Tom Poppendieck, the seven forms of "muda", or waste, in lean production map to the following seven forms of software waste:

  1. Extra/Unused features (Overproduction)
  2. Partially developed work not released to production (Inventory)
  3. Intermediate/unused artifacts (Extra Processing)
  4. Seeking Information (Motion)
  5. Escaped defects not caught by tests/reviews (Defects)
  6. Waiting (including Customer Waiting)
  7. Handoffs (Transportation)

So to the extent that we can identify or measure these in our value-stream, we can identify opportunities for improvement:

  • Waiting, handoffs, and information seeking can often be identified by measuring time spent in or between various "states" of change/request workflows in a corresponding change/request tracking system.
  • Decision-making time for assessment, acceptance, authorization, prioritization, and project/release selection are also forms of waiting or motion in the change/request management system
  • Inventory can be measured by looking at existing "work-in-progress" that has not yet been integrated or synchronized.

Of course defining and instituting such workflows must be done in such a way as minimize the "friction" upon the value-creation process.

There are other applicable Lean concepts and measures, as well:

Those are all interesting applications to investigate. For the remainder of this article we will focus on specific application of concepts already mentioned to version-control, and change-request management.

Request-queues as the "Value-Supply-Chain" for Development
For the part of CM that is viewed as “the front-end,” the value-supply chain is the request/change approval pipeline. Lean's view of Queuing theory and Little's law would apply. There would be overall cycle-time from concept-to-realization of a request/change, and some drill-down into segments in order to measure/identify & eliminate the various forms of software waste:

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!