WiP Limits and Velocity

I recently presented at a conference on the topic of Work in Progress (WiP) limits, and in particular Little’s law.  As part of I gave a demonstration and from it drew the conclusion that WiP limits have no direct bearing on velocity.

This caused some controversy so I’ll try to explain again here.

little

Applying Little’s Law

Mathematically speaking we can increase the speed with which we get served in two ways:

  1. We reduce the number of people in the queue (We limit WiP)  or
  2. We increase the speed each person is served (We increase Throughput – in this case by adding more people, or installing faster equipment)

Note:  When mathematically applying Little’s law the pre-condition is that the variables are independent, the assumption is that number of people in the queue does not impact on how quickly the server works.  This works in mathematics, but maybe not so much with people in reality.

The principle is that WiP and Throughput are two independent variables and changing one does not change the other, only cycle time is impacted.

The wider impact of WiP limits

Of course the goal of my talk was to illustrate that whilst you may feel you are getting more done by not limiting your WiP, and having a whole bunch of work in progress this has no bearing on your actual throughput which is governed by your bottle neck.

When using Little’s Law in a controlled environment we can show that limiting WiP doesn’t impact throughput (unless we limit it to less then our bottleneck and starve it – say two servers and limiting the queue to 1 person). What limiting WiP does do is reduce cycle-time enabling you to be more flexible and more responsive and to have more reliable forecasts.

Work in Progress Limits will directly impact Cycle-time

Contradictory Claims

Unfortunately this contradicted one of my other claims in the presentation where I said that Limiting WiP helps increase throughput of the team.

The confusion of course is understandable, when using a mathematical example there is no cost for context switching and the example was to show the impact of WiP on a stable system isolating variables to demonstrate what happens.  The real world is far more complex and there are many more variables.

In the real world

Generally speaking the ability to focus on less things means less multi-tasking, reduced cycle time means you have less things on the go at once, and for less time. These help you be more productive and thus indirectly the throughput will go up, but this is a result of you being able to focus not as a direct impact of the WiP limits.

There are many indirect benefits of using WiP limits,  but Cycle-time is the prime beneficiary, the rest is a bonus or an indirect consequence.

 

 

 

Advertisements

New Kanban Game Available

Around two years ago I was introduced to a Kanban board game which we used as part of a training program and I really enjoyed it, it was a great learning tool but it had three major drawbacks.

  1. First it was heavily scripted and so it was only suitable for a single play through, you couldn’t replay it and get more out of it.  It was not a game in that sense, it was much more of a training tool/prop.
  2. The second issue was that the exercise was taking 3 or more hours to run and whilst Kanban is a critical aspect of the training the return on investment was not sufficient.
  3. Finally it didn’t effectively address Little’s Law or the Theory of Constraints, there were aspects of that in the game but the heavy scripting meant that the learning was masked or even lost.

motorcity_Board-1

A New Kanban Game

It got me thinking and so I created a couple of workshop games that addressed this in more detail.   One of those workshop games was such good fun that I expanded it and combined it with training. For the last year or so I have been running workshops using it and continually looking to find improvements and modifications to make it more fun or to emphasize the learning aspects.

I have now presented this at a number of Lean/Agile conferences and have had a lot of great feedback, including a lot of encouragement to publish it as a board game.

Rulebook_cover

And so Herbie* – the affectionate name for the workshop game, became Motor City a Kanban based board game.  That is first and foremost fun to play and re-play, but the game is under-pinned with an understanding of Kanban, Little’s Law and the Theory of Constraints.  You can play the game without any knowledge of those and it will still be fun, but people that instinctively apply those practices or use them as a result of understanding will fare better playing the game.

*Herbie was named after the character from the book The Goal, by Eli Goldratt.

box_bottom

Game Prototype (Early Access)

The game is now in prototype, with a small number published for evaluation and for use in training and conferences, with the intent to publish the game more widely after getting feedback from the prototype.

motorcity_logo

To purchase the game…

The game is provisionally priced at $150 but for early access to the prototype it will be charged at $120
I’d love to hear of anyone that uses this as part of a training program or just as a fun game for your team to play.

If you would like a copy of the prototype board game for evaluation and feedback, please contact me.

Similarly if you are interested in training on the Theory of Constraints or Kanban and would like to use this game as part of that training, I would be happy to offer guidance on how to incorporate the training into a workshop.

Thank you

Thank you to those that have supported and encouraged me, I can assure you that board game design is far more complicated, costly and time-consuming than I ever imagined. In particular thank you to Toby Gerber who has helped with the graphic design and turning my ideas into reality, I could not have done it without him.

boxbase sm

Understanding cycle-time in software

Cycle-time and Lead-time and even Little’s Law are terms that have migrated over into the software development context and are becoming more widely used, but I am not sure they are fully understood so I’ll attempt to clarify my understanding of the terms.

How does cycle time differ from lead time?

In manufacturing:

There are two different ways I have seen to express Cycle-time:

“Cycle Time” is the overall amount of elapsed time taken to create an item. Measured from the point when work starts until item is delivered.

or

“Cycle Time” is the average amount of time between each delivered item.  e.g. 7 items delivered in a week is a cycle time of 1 day

Lead-time seems to be consistent

“Lead Time” is the amount of elapsed time from which the order was first requested by the customer until the customer has received it.

Note: The different uses of cycle time cause confusion and I prefer the first description in a software context, as the second one ignores the impact of WiP. 

Clearly both of these are more complicated in software terms as the boundaries are not as clear.

cycletime

Cycle-time

Cycle-time is generally considered to be the point when a backlog item is committed and the item is “in progress” through our development cycle, in Kanban terms this is likely time counted from when it moves out of the ‘backlog’ column. We stop counting when it is moved to the ‘done’ column.   There can be a whole debate about what ‘done’ means and that is for another topic. But for simplicity the ‘cycle’ ends when your team will stop work on it (ideally it will be in the hands of the customer).

In Scrum cycle-time is typically fixed at a sprint length, we commit at the start of the sprint and deliver at the end.  But that is not universally true, some teams do not always deliver and there will be effort later to deploy as part of a scheduled release, and some teams deliver as soon as a story is complete.

Note: Cycle-time is sometimes called delivery time. But again this get confused with lead-time because of the non-linear manufacturing to software conversion.

Lead-time

Lead-time is a bit more complicated, it may be counted from the point a need is first identified by a customer to when it is resolved but this is rarely a one-to-one mapping, or it may be considered from the point when the need is identified and refined into a backlog item that will be worked on and delivered.

But really for agile backlogs we generally don’t work in a linear fashion, just because a request has been on the backlog longer doesn’t mean it will be delivered sooner. We prioritize and so a request identified last week may be delivered sooner than one from last year.

As a result Lead-time is generally not used as frequently as Cycle-time, not because we can’t measure it but because it is not as meaningful or useful.

Throughput

Another often used term is “Throughput” this is simply the number of units that have passed though the system (units completed) in a given period.  e.g.  Our throughput is: 10 stories per week, or 5 customers per hour.

Unless stated otherwise you can usually assume that it is an average (mean) or the most recent time period.

Little’s Law

Cycle time is a trailing measurement and we are able to come up with metrics and averages from historic results.  But a mathematician from MIT – John Little  devised a mathematical formula for predicatively calculating Cycle-time from the number of units in the system.

Average Cycle Time =  Average Number of items in progress / Average Throughput

Projected Cycle Time   =  Number of items currently in progress  / Average Throughput 

picture1

e.g. So let’s say you have 50 items in progress and on average you complete 10 per week.

picture2

Number of items currently in progress (50)  / Average Throughput (10 per week)

Projected Cycle Time:   50/10  =  5 weeks

What this tells us is that for the new units entering the system, on average it will be 5 weeks before each of them is completed.

If we want to reduce Cycle-time we have two options we can either reduce the amount of work in progress, or we can increase throughput.  Often our throughput is limited by other factors and so may be harder to change, such as team size or equipment availability. But work in progress (WiP) is typically more within our discretion.

Lets say we reduce the work in progress to just 20.

picture3

Number of items currently in progress (20)  / Average Throughput (10 per week)

Projected Cycle Time:   20/10  =  2 weeks

What this tells us is that for the new units entering the system, on average it will be 2 weeks before each of them is completed.

What you see here is that our throughput is the same, we are still delivering the same amount but by reducing work in progress we are able to deliver the same amount in a shorter elapsed time, and in a desire to have more agility then a shorter cycle time enables us to change direction sooner.  Less work in progress does not increase our throughput, however, it makes us more dynamic and more adaptable to change.

The less work you have in progress the sooner it will get done.

Yorke’s motto

In essence – the less work you have in progress the sooner it will get done, that is the lesson that should be taken from this.

But there does become a point where you can reduce the work in progress to a point where throughput is impacted (the system can become starved) and thus there is a trade-off.
In some situations cycle-time is a critical factor so an element of slack time is desirable, say urgent need to see a doctor, compared to a regular appointment.
But in most other cases we would aim to limit our WiP as much as we can to the point where throughput is not impacted.

Other less used terms

Then we come to the fun ones, these terms come from manufacturing but are used much less frequently in a software context but may be useful to be aware of as it can help understand the composition of cycle-time and where you can take action to tighten up your process.

  • Process Time
    • This is the time when someone is working on creating something: writing code, documents, design, tests, etc.
  • Move time
    • In software terms this would the time to move from one user to another or from one action to another and so would include, compilation, building, deploying and hand over/knowledge sharing
  • Inspection time
    • This might be QA time or code reviews, demonstration to Product Owners or stakeholders, but this may overlap with process time as this is still value added work.
  • Queue time
    • This is time when a unit(story/task) is in progress but no worked on, say blocked, or waiting to be code reviewed waiting for QA waiting for Demo, any time work is paused for any reason before it is done.
  • Wait time
    • This is the time a request spends in the backlog before we commit to work on it, e.g. the time from when a customer identifies a feature/function or bug until we start work on it.
  • Value added time
    • Any time in the system where activity that adds value is happening e..g not queuing, waiting.

Summary

Cycle-time and Little’s Law are becoming much more frequently used and whilst they are not complicated to understand the basics of they do bring a new set of terms and associated confusion.

For example I have seen a number of times recently people advising that reducing cycle-time increases throughput.  Mathematically speaking this is incorrect, (although the reverse is true increased through put should reduce cycle-time). Anecdotally less context switching does increase throughput.
What they are advising is good advice – reduction of Work In Progress. However, their expectation and  reasoning is wrong and adds to yet more confusion.

Cycle-time is not a measure of quantity of output, but a measure of the duration it is in the system. It is important to remember that throughput and cycle-time are different measures.

Cycle-time is not a measure of quantity of output, but the duration it is in the system.

I hope this helps and I’d be happy to add any further clarification if there are parts that are unclear.