Sunday, December 17, 2017

It’s a pull system – not “work on whatever you like”

In some circles, the term “Pull-System” has become a synonym for “My boss doesn’t tell me what to do, I can decide myself.” For me this completely ignores the fact that the term refers to a system and it’s properties, not to the way people in that system can behave.

Let’s assume a simple workflow consisting of four states:

| Ordered | Design | Accept | Done |
|         |        |        |      |
|         |        |        |      |
|         |        |        |      |
|         |        |        |      |

When we push items into the system they will pile up in the state before the bottleneck in the system. This might look like this:

| Ordered | Design | Accept | Done |
|         |        |        |      |
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |        |  [ ] |
|         |  [ ]   |        |  [ ] |
|         |  [ ]   |        |  [ ] |
|         |  [ ]   |        |      |
|         |  [ ]   |        |      |

In this case “Accept” seems to be the bottleneck. So whatever you do the system will not be faster than the speed of the “Accept” column. No amount of “pushing” work into the system will make it faster. On the contrary - the more work piles up in the “Design” column, the longer it will take for new items to get through the system.

We don’t know yet how much work is completed, so lets make that visible by putting an “x” on completed items

| Ordered | Design | Accept | Done |
|         |        |        |      |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|         |  [x]   |        |  [ ] |
|         |  [x]   |        |  [ ] |
|         |  [x]   |        |      |
|         |  [x]   |        |      |

Looks like 5 items in the “Design” column are just waiting to be processed. (Items in the “Ordered” column are always done, in the example there is no doing in the “Ordered” column). Pushing another Item into this system will only increase the amount of work not done - like this:

| Ordered | Design | Accept | Done |
|         |        |        |      |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|  [x]    |  [x]   |        |      |
|         |  [x]   |        |      |

One simple way to convert this system to a pull system would be to limit the number of items per column - for example like this. (We’ll ignore how to come up with these numbers for the moment that would be the topic for another post)

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |
|         |        |        |      |
|         |        |        |      |

Having these limits on the columns, the system could never exceed the following situation – Non-withstanding the question whether the work items are done or not:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |        |  [ ] |
|         |        |        |  [ ] |
|         |        |        |  [ ] |
|         |        |        |  [ ] |

Filling this system with done work and moving excepted work into the next done column we might find the following situation

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [ ]   |  [x] |
|  [x]    |  [x]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

And even though it is not yet visible to the naked eye this system already is a pull system if we add the simple rule that as soon as there is less work in a column than allowed by the limit we fill the column up to that limit.

Step one:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [x] ---> [x] |
|  [x]    |  [x]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

Step two:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x] ---> Pull  |  [x] |
|  [x]    |  [x]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

Step three:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x] --->  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [ ]   |  [x] |
|  [x]    |  Pull  |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

Step four:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [ ]   |  [x] |
|  Pull   |  [ ]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

which leaves the system in the state where there is an open pull request to pull more orders from outside the system.

Looking at pull systems this way shows that the term "pull" does not imply that in each pull system individuals can randomly choose what they want to do next, but describes one of the properties of the system itself. The level of autonomy –and how much each person is able to work on the stuff they would like to work on– can also be a property of the system, but it is a different property.

Having "pull" brings numerous advantages: better predictability, a better balance between throughput and utilization, and a more sustainable workload.

till next time
  Michael Mahlberg

P.S.: Of course this topic is way more complicated than outlined here and the relationship between limiting WIP and pull is not quite as one-dimensional as pointed out by Donald Reinertsen himself on Twitter. There is also a nice write-up on the topic from FactoryPhysics when it comes to the more intricate details of this matter.

No comments: