So having read the article, why does limiting work-in-progress work? Because it allows you to finish more work that you start? I struggled a little bit initially with the generic concepts used for modeling. But I suppose the real insight is that, focusing only on these 3 basic parameters (work started, work finished, and number of developers), you can get wildly different results. Is that a fair reading?<p>This is a topic to which I've given a fair deal of attention in leading software development teams using scrum. Especially after reading Donald Reinertsen's Principles of Product Development Flow, where he approaches this topic in more depth:<p><a href="https://www.goodreads.com/book/show/22586058-the-principles-of-product-development-flow" rel="nofollow">https://www.goodreads.com/book/show/22586058-the-principles-...</a><p>Limiting work-in-progress was a major principle in Reinertsen's book. Another related one which I've applied successfully in practice: limit batch size. In my case using scrum, this meant keeping user stories within a certain size range (2-5 points).<p>This has an important benefit: it controls scope creep. It does this a couple ways: 1. It's helps during planning avoid overlooking complications or other costly delays before works gets started. 2. When a story starts to creep during development, you tend to catch it sooner and control it more effectively.<p>Which helps get stuff done, which helps limit WIP, which as the article suggests helps get stuff done.