<i>The first and most important question of course is to understand that having too much WIP is in fact bad.</i><p>This is a well-understood concept in factories.
Not enough people today have ever been in a factory.<p>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?<p>This is a classic business school problem.[1] There's a whole theory of this, dating back to 1913.<p>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.<p>[1] <a href="https://www.allaboutlean.com/lot-size-part-1/" rel="nofollow">https://www.allaboutlean.com/lot-size-part-1/</a><p>[2] <a href="https://youtu.be/Dk306ZkNOuc" rel="nofollow">https://youtu.be/Dk306ZkNOuc</a>
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, <i>much</i> 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.
I had misunderstood this idea as minimising the WIP, but it's about optimisation.<p>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."<p>This articles also references: Why limiting work-in-progress works.
<a href="https://lethain.com/limiting-wip/" rel="nofollow">https://lethain.com/limiting-wip/</a><p>Discussed previously
<a href="https://news.ycombinator.com/item?id=19186456" rel="nofollow">https://news.ycombinator.com/item?id=19186456</a>
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
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?
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.<p>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.<p>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.