The first and most important question of course is to understand that having too much WIP is in fact bad.
This is a well-understood concept in factories.
Not enough people today have ever been in a factory.
It's a classic problem with manufacturing plants that make a large number of different items. There, it's obvious - you have racks or piles or bins of partially finished product sitting around. Yet you can't avoid some of that, because machines have setup and teardown times. So you make a thousand stampings of thing A, which then wait for the next step. If you only made a lot of 100, there would be less work in progress, but more time the stamping machine wasn't running while the dies were changed. If you made a lot of 10,000, the stamping machine's efficiency would be higher but you'd have more work in progress. So, what's the optimal lot size?
This is a classic business school problem.[1] There's a whole theory of this, dating back to 1913.
Apple is famous for having botched this with their Macintosh factory in Fremont.[2] They centered their factory around an automated storage and retrieval system. This meant they could buffer a lot of work in process without making a visible mess. Wrong approach.
At its core, Factorio is about turning a few base materials into useful things, with many intermediate parts. Everything you build, then, is eventually competing with those few basic as materials.
The first time I played, I would see some base part being produced faster than it was consumed, and my thought was I should store the excess product, so that the factories creating those products would not back up and stop functioning. This would let me have a buffer, and keep those intermediate material producing machines running at full capacity.
Now that I had this buffer of intermediate materials that was growing, I would try to add more factories that used those materials for the next intermediate material.
However, the next intermediate material would also need other intermediate materials, so I would have to expand the number of factories producing raw materials to feed those other producers. However, additional raw materials were also consumed by the factories that were ALREADY overproducing. This lead to an attempt at a delicate balancing act, to get the number of factories for each type exactly right. I would add some to one material, then have to add more to another. It was impossible.
What I finally learned is that I had to let the factories over producing backup and stop producing. That way, more raw materials would be leftover for the things I was short on. This back pressure allowed the factory to self balance.
Increasing the buffer on something is only useful if the usage is highly variable. Then, you need a small buffer but not too big of one.
Yeah same here! I'm just thinking aloud, but let's consider time and money as our scarce resources.
We can perhaps put backpressure on time-sink activities, such as endless scrolling Netflix, and open up those time resources for creative hobbies. This essentially boils down to replacing a consumer habit/mindset with one of creativity and self-expression.
Similarly, living in a small apartment and not paying for a storage unit can put backpressure on material acquisitions.
Well... the main difference is that backpressure in a mechanized system will always be respected, but a willful human can choose to ignore it. I can choose to live in a small apartment and then proceed to make myself miserable by cramming it so full of junk that I can barely move around...
Production in Dwarf Fortress plays with the same supply chain dynamics.
The spatial organization of the workshops, raw material stockpiles, output bins, consumption points, and transit time between them must be tuned, otherwise the settlement collapses. The settlement always collapses, but the extrapolation of entropy is almost the point (and entertainment) of the game.
Factorio would be a better model of the problem if backstuffed factories would keep consuming power despite being idle. This would be analogous to having idle workforce that still has to be paid
Author here. I loved the book and encourage everyone to read it. Use the Theory of Constraints to identify your bottleneck and then "limit wip" or elevate it.
I watched the video in [2]. I saw the automated retrieval system, some pick-and-place machines, some final-acceptance testing -- all aspects of the modern manufacturing processes. Aside from having a few more humans in the loop than you'd need with modern machinery, nothing there looks "botched."
This article [3] suggests that Apple simply didn't have enough demand to make the factory successful. Success would have required additional automation such as adding pick and place for the larger components, automating the acceptance testing.
The same problem arises in logistics, job queues in programming, and elsewhere. The study of stocks (aka buffers) and flows (aka processes) is the domain of system dynamics. Its a rather interesting field of study.
If anyone wants a much more in-depth look at the concepts behind this, I can't recommend "The Goal" by Eliyahu M. Goldratt enough. It's a bit like The Phoenix Project, in that it's a novel about improving flow in delivery processes, but it's much, much better, and goes into way more practical depth. You'll learn about not just WIP, but floating bottlenecks, buffers, batch sizes, etc. that turn out to be universally useful concepts. The audiobook is especially good - easily the most practically applicable book in the field I've come across. Go read it/listen to it.
Less known but even more applicable to software is "Principles of Product Development Flow." I learned about that book from the talk "Architecture Without an End State" and it's one of the most thoughtful things I've read on the topic. It references "The Goal" but builds out its ideas even more, mixing in a bunch of queue theory and taking lessons from many other areas such as statistical economics.
Reinertsen's Principles is an amazing book. The way he combines lean, network engineering and all the rest to create an actually meaningful and coherent picture of product development is genius.
Author here. I loved "The Goal" even more than the Unicorn Project. Use the Theory of Constraints to identify your bottleneck and then limit WIP at the bottleneck or elevate it. By hiring, optimizing...
I had misunderstood this idea as minimising the WIP, but it's about optimisation.
Quotes:
"How can I find out what the ideal WIP limit is for the system I am in?"
"After a few iterations and having recorded the learnings in retrospectives, we collectively decided to increase the WIP."
Well, there are two important limiting cases when it comes to minimising WIP: zero and one.
Assuming your work is productive in the first place, zero WIP would be bad.
One WIP, known as "single piece flow" is actually the ultimate optimisation in production. So from that perspective, optimising and minimising is the same thing.
I think term "Kanban" is misused so often, that nobody understands what is really means.
Totally agree with your point, especially funny how author rediscovers that "Limiting work-in-progress is the tool every manager and leader needs to have in their tool belt. This is the one super power that over time will allow moving faster to the desired goal".
Guilty. I had no idea Kanban was about this. At my place it's a virtual board and you pick things off the top right (highest priority work needing review) and move left (bottom left is lowest priority work not yet started).
I find the SAFe framework describes the brilliance of Kanban nicely [1]. I’m surprised there isn’t some discussion on queuing theory such as Little’s Law [2] either, as I feel it is also relevant.
I think what is important is the gratification when a team delivers a feature. If a team can produce x amount of work, if this is divided over large number of WIP, the team will deliver much less features and will be less happy and satisfied.
but if the team work on a smaller number of features, the team will complete and deliver more features and be happier and more excited to work more
Sure, gratification is important, but what really drives both gratification and everything else is feedback.
When you have less simultaneous work you get done faster, which means you make decisions based on less old information.
Imagine trying to... I don't know, play soccer where your body movements have a five-second delay. It'll feel awful because by the time you decide to move your body you know it's going to be too late for any detailed knowledge so you'll have to make do with some very primitive heuristics like "flail in the direction of the ball and hope to get lucky".
That's what too much WIP is. Limiting it is starting to move and react in real time to changes.
You should ask yourself where the WIP comes from. Are there people in your org (job description ending with "nager") that get paid for creating new tasks?
Be suspicious of any activity added to workload that hasn’t been scrutinised. A pet peeve of a nager isn’t necessarily the most valuable thing to work on. Neither is necessarily the work that makes the salespersons job a bit easier to sell the product.
I’d add to this that, from the perspective of a manager or the sales team, the opportunity cost of a feature request is almost always zero, while the opportunity cost to the team implementing it can be huge. The best features are ones where the requester has skin in the game. How often have I said “yes I can do B, but then you won’t get A” - suddenly, B becomes a lot less important.
I never truly realized that doing things in parallel was WIP itself, even if I have read the Phoenix Project. I mean now it just makes sense and I kinda feel dumb.
This is spot on. I have been a student of Eli’s work since about 1995. He was an amazing individual.
An important point not always noticed is that restricting WIP improves both flow and quality in organizations. I see flow and quality as “mutually co-arising” attributes of thoughtful management of organizations.
I also like the work done by Dave Snowden with his Cynefin framework. Anyone else share this view?
WIP seems also detrimental to me on a less-accountable but often perceptible way: motivation. AFAIK most human beings benefit from (maybe even need to) periodically see something useful resulting from their work.
This is a well-understood concept in factories. Not enough people today have ever been in a factory.
It's a classic problem with manufacturing plants that make a large number of different items. There, it's obvious - you have racks or piles or bins of partially finished product sitting around. Yet you can't avoid some of that, because machines have setup and teardown times. So you make a thousand stampings of thing A, which then wait for the next step. If you only made a lot of 100, there would be less work in progress, but more time the stamping machine wasn't running while the dies were changed. If you made a lot of 10,000, the stamping machine's efficiency would be higher but you'd have more work in progress. So, what's the optimal lot size?
This is a classic business school problem.[1] There's a whole theory of this, dating back to 1913.
Apple is famous for having botched this with their Macintosh factory in Fremont.[2] They centered their factory around an automated storage and retrieval system. This meant they could buffer a lot of work in process without making a visible mess. Wrong approach.
[1] https://www.allaboutlean.com/lot-size-part-1/
[2] https://youtu.be/Dk306ZkNOuc