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?

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:

https://www.goodreads.com/book/show/22586058-the-principles-...

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).

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.

Which helps get stuff done, which helps limit WIP, which as the article suggests helps get stuff done.