[HN Gopher] Limiting Work in Progress (2020)
___________________________________________________________________
Limiting Work in Progress (2020)
Author : xo5vik
Score : 50 points
Date : 2021-04-10 08:24 UTC (14 hours ago)
(HTM) web link (truemped.github.io)
(TXT) w3m dump (truemped.github.io)
| mikesabbagh wrote:
| 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
| kqr wrote:
| 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.
| mjfisher wrote:
| 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.
| truemped wrote:
| 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...
|
| You are right though: go read The Goal everyone!
| occz wrote:
| The Goal was actually the primary inspiration for The Phoenix
| Project, iirc. I think it was mentioned at the end of the book.
| truemped wrote:
| Indeed. Both, The Phoenix Project and The Unicorn Project are
| heavily inspired by The Goal.
| planet-and-halo wrote:
| 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.
| mjfisher wrote:
| Perfect, thank you - just ordered it.
| kqr wrote:
| 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.
| choeger wrote:
| 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?
| quickthrower2 wrote:
| 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.
| osmarks wrote:
| It seems like the model in this is assuming the conclusion of the
| post.
| TeeMassive wrote:
| 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.
| Animats wrote:
| _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.
|
| [1] https://www.allaboutlean.com/lot-size-part-1/
|
| [2] https://youtu.be/Dk306ZkNOuc
| xupybd wrote:
| There is a fantastic novel that explains this in a
| manufacturing context.
|
| As it explained through a fictional story it's an easy read and
| a great audiobook.
|
| The Goal by Eliyahu M. Goldratt
|
| I didn't fully grasp the problem of too much WIP until I read
| that book.
| truemped wrote:
| 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.
| quickthrower2 wrote:
| Do you mean you are the author of that book or an author in
| general?
| grzm wrote:
| 'truemped is the author of the submitted post, "Limiting
| Work in Progress".
| truemped wrote:
| I did not write The Goal ;)
| grzm wrote:
| Fortunately not, otherwise you wouldn't have been able to
| provide us with this submission :)
| billfruit wrote:
| Some of such analysis forms part of a now obscure discipline
| called 'Work Study'.
| whatshisface wrote:
| Or a less obscure discipline called "operations research."
| sbayeta wrote:
| This is why SMED was developed
| elevation wrote:
| 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.
|
| [3]: https://www.mercurynews.com/2018/12/17/steve-jobs-wanted-
| to-...
| cortesoft wrote:
| Playing Factorio helps to demonstrate this.
|
| 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.
| jkhdigital wrote:
| Backpressure is _the_ most important force in any production
| process. Now if only I could figure out how to apply it to my
| personal life...
| beaconstudios wrote:
| 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.
| xo5vik wrote:
| 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."
|
| This articles also references: Why limiting work-in-progress
| works. https://lethain.com/limiting-wip/
|
| Discussed previously
| https://news.ycombinator.com/item?id=19186456
| kqr wrote:
| 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.
| erokar wrote:
| I'm surprised Kanban is only mentioned cursorily. Limiting work
| in progress is one of, if not the, point of Kanban.
| chaoz_ wrote:
| 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".
|
| Why do literature review.
| jon_adler wrote:
| 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.
|
| [1] Principle #6 - Visualize and limit WIP, reduce batch sizes,
| and manage queue lengths -
| https://www.scaledagileframework.com/visualize-and-limit-wip...
|
| [2] Little's Law - https://en.wikipedia.org/wiki/Little%27s_law
___________________________________________________________________
(page generated 2021-04-10 23:00 UTC)