May 182017
 

My mother is going to laugh a lot at the fact that I’m writing this post, even if she’ll never admit it to me.  The idea that her son — who always used to get home late, sometimes knocking over the pots and pans that his father had set up against the door to announce his late arrival — is writing about time is a bit ironic.

But here we go. My good friend and excellent Agile Team Guide David A. Koontz (really, he’s an artist with teams; you should try to hire him) wrote an excellent article about Lead Time vs. Cycle Time, and the difference between how long we take to do a job vs. how long the customer waits for the results.

I’ve been working with Lean Kanban Inc. since last year, and I appreciate the sharp point they’ve put on terms around this issue. Here they are in a picture:

1. Customer Lead Time

The time from when we accept the customer’s request until deliver that request to the customer.

That’s it. Plain and simple. This is all the customer cares about!  The item could be “done” 5 minutes after the order is taken, but if it sits in a warehouse for a month before the customer gets it, the customer is still gonna be peeved.  Or as in David’s example, the item could sit around for a month and only take a few minutes to actually deliver. Either way the result is the same.

2. System Lead Time

The time from when we accept the customer’s request until the request reaches the first unbounded queue in the system.

This is a metric we care about when it comes to measuring and improving systems. Notice the Work In Process (WIP) limits in the picture above.  That last state, “Done” has no WIP limit. It’s potentially infinite. Even though we serviced the customer’s request at the end of Process C, it could sit around in a queue forever.

The reason we measure this only up to the point of the infinite queue is because we can only design and control systems that have WIP limits in them. Sometimes we can’t control what happens in that “Done” queue, so we can only work to improve everything up until that point. (At first. Once we get that under control, it’s time to have some conversations with the people in “Done.”)

This is why it’s important to have WIP limits on all work queues and buffers: if you don’t, then you don’t really have a pull system, and your ability to predict delivery is shot.

The actual LKI term for this metric is “Kanban System Lead Time.”  But if the first unbounded queue in your system is the Request buffer, guess what — you don’t have a kanban system. This, right here, is the most common pain I see when I’m asked to help with Agile delivery: a great Scrum engine with tightly-controlled WIP (from Sprint Planning), and a whole chain of unbounded queues upstream of it.

PRO TIP: your biggest predictability problem in this case is NOT your development process. :)

3. Time In Process (TIP)

The time that a particular request spends in a given process state.

This is what David called “cycle time,” and it’s a pretty common usage of the term. I prefer Time In Process because it’s clearer. “Lead Time” and “Cycle Time” can get confusing, so we just throw one term out. Yep, we don’t actually ever say “Cycle Time.” (Well, I try not to — old habits die hard.)

What about the time from Process A to Process C?  Easy, that’s just “the Time In Process for Process A, B, and C.” In our example above, TIP (Requests+A+B+C) for an item is the same as the System Lead Time for the item.

We use this in systems design to get a more fine-grained view of the system than System Lead Time.  And we use it day-to-day to meet our Service Level Expectations.  Do we expect most requests to spend 7 days TIP in Process B? Is this request here currently 6 days TIP? Then maybe we better get a move on and get it out of here — or think about renegotiating the customer request.

4. Working Time

Time spent on actually increasing the value of the item. Also called Touch Time.

In David’s example, this was also what he called “Cycle Time;” the time spent installing the basketball hoop. Often, the Working Time represents only a small fraction of the total Lead Time for the item. Which brings us to…

5. Waiting Time

Time where the item is not being actively worked on.

This is often a large portion of the total Lead Time (System, or Customer) for an item. This is where high WIP limits (or no WIP limits!) kills us. This is where multitasking kills us.  So much of the customer’s total wait time is just the request sitting around, or being shuttled back and forth from one person to another.  Which brings up…

6. Flow Efficiency

The ratio between total Working Time and total Waiting Time, expressed as a percentage of System Lead Time.

And here’s the second most common pain I see when asked to help with Agile delivery: poor flow efficiency.  In the example above, we take the customer’s order, and then it sits for a bit.  Then we start Process A and finish quickly… but it sits for a bit until it gets to Process B. Same thing happens with Process B. Process C is better; mostly we work on the request, with one brief interruption.

For systems with lousy flow efficiency, changing the system to reduce waiting times is going to be a huge bang for the buck — much more than improving the actual working processes. You’ll get faster delivery, and more focused, happier people who aren’t task-switching all the time.

One Last Distinction

In my recent AgileIndy talk, I made a call for 21st-century management to raise the game: we need to get better at managing systems, and leading people.

We sometimes use the terms above to refer to an individual request. “What’s the Time-in-Development for this FooBar Story? Is that going to affect our SLE?”  That’s valid. That’s the kind of question you’d hope to hear within the team, not from a manager.

If we are managing the systems, we use the terms I’ve outlined here to refer to requests in the aggregate — which really means referring to the system as a whole. “How can we get the System Lead Time down by 30% for all standard requests?” That’s also valid. And that’s the kind of question I really like to hear from management. 

Let the workers self-manage the work. Manage the systems. Lead the people.

  4 Responses to “On Time”

  1. You’ve started a conversation about time. You have not mentioned Doctor Who, a TARDIS or a timeline of any nature. This must be corrected… and to help I give you one of these as a starter… I’m sure you can spruce it up at bit… Long Distance Communication Timelines

    http://agilecomplexificationinverter.blogspot.com/2010/12/long-distance-communication-timeline.html

  2. I was just in a review of Reinertsen’s Principles of Prod. Dev Flow chapter on Batch Size today at lunch with a group of scrumy humans. The topic of batch size in Don’s view is from the customer’s finished product stand point. So I question if counting stories in a sprint (say 8) is a batch size of 8. Now if (big F-ing iF) the stories are valuable and released at the end of the sprint to the customer – then yeah, batch size is 8. But that’s not the case a company X (like Malcom X – name to be withheld). Here Features that a customer desire are decomposed into multiple stories, many times split across component teams, and delivered when all stories are integrated maybe months in the future. So Mr On Time… what’s the batch size for these scrumy teams? Can it be a fraction? Let’s assume Feature ‘Needed by Xmas’ has 47 stories and starts decomposition in July. Team Santa’s Little Helper has 6 of those stories and 2 bugs to fix in sprint 28.2017. For 3 points and the golden calf of time mantel statue that Carol is holding…. is the answer 6/47 stories?

  3. I see this more often than not, David. I coach that evaluating effective delivery requires we consider batch size as Reinertsen suggests: the batch is delivered when the customer gets value, not when we say we’ve done something. It’s often the same I-did-my-tasks-but-you’re-still-unsatisfied argument as when Stories first showed up, writ large.

    What I think you’re looking for here is “Work Item Type.” Your Features are work item types that are composed of multiple ‘Story’ work items. And both might have a batch size/lead time.

    Considering the batch size/throughput/lead time of the ‘Story’ work items isn’t useless; it can actually be very helpful for amplifying team learning and reducing waste. But its a first-order effect. The same metrics for the work item type that the CUSTOMER cares about are the second-order effects we’re trying to get achieve.

    (Also, I’ll never use Dr. Who references. Star Trek maybe.)

  4. Captain Kirk jumps a shark every time he travels in time. That show broke that … whatever it is … the 4th dimensional wall in the theater countless times. They even had a spinoff with the time-space voyage as a basic premise and it failed to adequately deal with the concept. So in order to pick a really good fight – I assert that the Doctor has the Sci-Fi moral time-space high ground.

Your thoughts?