Actionable Agile Metrics Review - Part 2: Flow Metrics

5 minute read

This is the second installment of my review of Dan Vacanti’s book Actionable Agile Metrics for Predictability, An Introduction. At the end of the first chapter we saw how actionable agile metrics are fundamental to TameFlow as they support the two fundamental patterns of Unity of Purpose and Community of Trust. In this post we will examine what Dan has to say in his next chapter.

Chapter 2 — The Basic Metric of Flow

Dan explains that the measurement of Work in Progress (WIP) is a very good predictor of performance. Yet it is not obvious to agree on exactly what is work and when that work should be considered in progress. A suitable unit of work must be used (like user stories), and used consistently. Even more critical is to define where the boundaries of the process are located. A queuing metaphor is convenient, with clearly demarcated points of arrival, service and departure.

In TameFlow we exercise a lot of care in managing WIP. However — and this is a valuable lesson — in TameFlow we have not been so explicit about defining what is work and under what circumstances it should be considered in progress. Those notions have been taken for granted. With this respect (and in many other subsequent points of the book) Dan might appear to be pedantic and almost overly concerned with hair splitting precision in definition; but it turns out there are two very good reasons for this. First: Having agreed upon a precise definition of what is work and where the process starts and ends is really important to arrive at reliable predictability. Second: Clarity in definitions and agreement on terms is positively constructive of the essential TameFlow pattern of Unity of Purpose. For these two reasons alone, it is of essence to assimilate Dan’s intent to get clarity and agreement on what WIP is, and when it is considered in progress.

It is of extreme importance to decide where the process starts and where it ends. In a pull-system, the starting point can easily be made to coincide with the first point where the work is actively pulled into the system — it corresponds effectively to the point of commitment. Clear and simple! In a push-system, such starting or commitment points are really a matter of opinion. This is where we can make another connection with TameFlow: push-systems are thus not only unreliable, but also sources of disharmony which undermine the Unity of Purpose pattern. This implies the important corollary: TameFlow works only with a pull system. Push-systems are intrinsically opposing Unity of Purpose.

Dan explains that, likewise, it is important to define where the process ends — typically this is when the work reaches the customer. Once the entry and exit points have been defined, measuring WIP becomes very simple: it is the count of all work items that have entered the process and not yet exited. There is no need to make any distinction between different size, complexity or level of effort of the different work items. WIP is simply the count of all work items that are inside the process.

Dan describes how the decision of where to place the entry and exit points also affect the measurement of Cycle Time (CT): they tell when to start and stop measuring CT. It is important to realize that CT is the actual elapsed time that a work item needs to get from the start to the end of the process, including all waiting times and all delays. Again, this is very simple, and it resonates with customer’s viewpoint.

Another aspect that is of interest to the customer is that elapsed time helps to predict cost. This can be put in relation to TameFlow, where Throughput Accounting is used to manage Financial Flow. From the TameFlow perspective, the amounts incurred as salary of knowledge-workers are considered as Operating Expense.

Curiously, as salaries are based on time periods (e.g. monthly salary), elapsed time is proportional to Operating Expense. When reasoning in terms of Throughput Accounting, you accept that you have to pay salaries whether people are producing value or not: you will incur the same Operating Expense. This might be hard to accept for project managers or accountants who are so accustomed to do earned value or cost allocation calculations. The emphasis on elapsed time is a good proxy for the Operating Expense of Throughput Accounting — without the psychological hurdle of overcoming all objections that typically are raised when it is suggested to forsake earned value or cost allocations. Focusing on elapsed time will thus support making the same kind of decisions which would derive from reasoning in terms of Throughput Accounting, but without having to counter all (unfounded) objections that originate from an allocation mindset. Striving to reduce Cycle Time (i.e. elapsed time) goes in the same direction of decreasing Operating Expense in terms of Throughput Accounting. From the viewpoint of TameFlow this is a most welcome consequence or coincidence!

Dan also observes how reducing elapsed time will shorten the customer feedback loop, and that it is also a general indicator of the process’s overall health. In particular he relates this to the Flow Efficiency metric (the ratio between touch time and elapsed time). Flow efficiency is a strong driver to reduce inactive time, and is entirely embraced by TameFlow too.

Finally Dan describes Throughput, which is simply the speed at which work is completed per unit of time, or how many work items exit the process per unit of time. This speed of delivery can also be compared to the Arrival Rate in order to gain important insights about the process. These metrics and arguments are entirely consistent with TameFlow which, however, further examines the impact of constraints that might be present in the process

From the TameFlow perspective, after reading this second chapter, the importance of this book is even greater. There are two lessons of great value. Specifically: the need to have clarity in defining the start and end points of the process and (consequently) the importance of focusing on actual elapsed time (Cycle Time) that WIP takes to get through the process. If you are a TameFlow practitioner, this book is highly recommended.


Links:

Updated:

Leave a Comment