Book cover: Tame your Work Flow

Tame your Work Flow

Self-knowledge is valuable to keep yourself reigned in, I really think Little’s Law is important. This week I needed to make sure I did not go overboard in discussing the ramifications of the theorem (I will include links at the end of this week’s re-read for those who want to go into depth). Chapter 3 of Tame your Work Flow is incredibly important for understanding the overall book. In your re-read spend the time needed understanding how the themes noted in the chapter title Flow Efficiency, Little’s Law and Economic Impact inter-relate.

As with previous chapters, the authors begin topics by ensuring that you understand the language they are using. In this case, they begin with three terms:

  1. Touch Time – is the time that work is performed on the work item. For example, writing code for software or keyboarding writing an article.  
  2. Wait Time – is the time (after work is pulled to be worked on) that the work item sits around after it is in process. For example, the time the code sits waiting for the next keystroke while you are at that all-hands meeting.
  3. Flow Time – is the sum of Touch and Wait Time.

Steve and Daniel explicitly exclude time before work is pulled and after. The time waiting in the backlog or in story refinement is excluded in TameFlow. A slightly over the top example to highlight Wait and Touch Time is as follows:

If I pull a work item at 8 AM, work on it for 30 minutes, at noon stop, and then finish it in 30 minutes of work between 7:30 and 8 PM. The task has been in process for 12 hours with 1 hour of Touch Time and 11 hours of Wait Time.

While the example feels silly, I can remember two or three occasions in the past six months when very similar scenarios happened due to interruptions or impromptu meetings. We will use the example again when we calculate flow efficiency.  

The authors point out that Touch Time, which definition is inside the process, is always within our span of control (we can act on how we work). This is one of the reasons they explicitly exclude measuring activity outside the process for flow efficiency. Adding activities outside of the span of control distorts our interpretation of flow efficiency. Activities outside our span of control are at best within our sphere of influence and often we can not exert any influence on them. This means that we need to have a clear and unambiguous distinction about what is in and what is out of the process. 

A second topic that the authors spend time on is the idea of whether we want to work faster (reduce Touch Time) or deliver sooner (often the largest impact is to reduce Wait Time). As most of the readers will recognize, Touch Time is almost always far less than the amount of Wait Time. If we use our earlier example, if we worked faster and reduced both coding sessions by 50%, we would complete the work item in 11.5 hours (approximately a 4% improvement in flow time).  

Flow efficiency is defined mathematically as (total touch time/flow time) * 100. Using our example to show the calculation. Before improvements, flow efficiency was 8.3% and then after improvement, it fell to 4.3%. An apparent paradox because the Waiting Time was unaffected by the improvement. As a veteran of many process improvements projects almost every change affecting Touch Time requires investment tools, training, and/or more people all of which are expensive. Reducing Wait Time rarely requires changing how work is done (therefore it avoids the expense of changes to Touch Time). In our example, if we reduced Wait Time be six hours, flow efficiency would of the improved process improves to 9.1%. 

Daniel and Steve use this section to point out that any non-continuous flow approach to work will generate lots of Wait Time. The term “inflationary” is used to describe the impact. They point out that sprints, iterations, phases, and program increments all reduce flow efficiency. 

Two additional concepts are introduced in Chapter 3.  Little’s Law (for more depth see Kanban: Software Development Kanban and Little’s Law and our re-read of Actionable Agile Metrics). Little’s Law is a mathematical observation that the number of customers in a system equals the average arrival rate multiplied by the average time the customer is “in” the system. The authors use the formula in the following format:

Throughput = Work In Process/Flow Time

Little’s Law is mainly used to monitor and highlight the need to reduce Flow Times (teams also find it very useful for predicting when they will deliver and to plan their work). The Theory of Constraints (ToC) on the other hand is more focused on finding constraints to increase throughput. 

The final concept introduced in this chapter is the idea of financial throughput which can be summarized as how much money the organization makes per unit of time. Daniel and Steve use the formula below to define:

Return on Investing = (Financial Throughout – Operating Expenses) / Investment

In conversations with other lean and agile coaches about the book, the idea of throughput accounting is often offputting. I think the word accounting is the issue however throughput accounting ties Little’s Law and improving flow to be the organization’s bottom line.  For-profit organizations invest in a change so to improve their returns. Using the ideas of financial throughput and throughput accounting allows changes to be weighed against the bottom line.

Remember to buy a copy of Tame your Work Flow to support the authors and blog!

Week 1: Logistics and Front Matter –

Week 2: Prologue (The Story of Herbie) –

Week 3: Explicit Mental Models –

Week 4: Postpone Commitment –