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 & 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:
- Extra/Unused features (Overproduction)
- Partially developed work not released to production (Inventory)
- Intermediate/unused artifacts (Extra Processing)
- Seeking Information (Motion)
- Escaped defects not caught by tests/reviews (Defects)
- Waiting (including Customer Waiting)
- 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:
- "Kanban" or "pull-systems" and their measurements
- Measurements from Queuing Theory (including those already mentioned) such as average arrival-rate, service-rate, utilization-rate, average wait-time, etc.
- Process Cycle Efficiency
- Traceability, Visibility and the Order of Pipeline events
- Supplier, Input, Process, Output & Customer (SIPOC) Metrics