Two of the most under-appreciated insights in software engineering: concurrent work in progress has a productivity cost, and team size has a productivity cost (The Mythical Man Month).<p>If you ever want to see cognitive dissonance in action, try talking about this with engineering managers at a hypergrowth company. They will smile and nod and agree and go right back to pushing for ever increasing scope + headcount and and acting surprised when they don’t get linear-plus returns. There’s a really persistent belief that you can just grow the team faster than the backlog and everything will be fine.
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.
Slow CI and/or Code Review makes concurrent work a bit of a necessity. Context switching certainly has a cost, but it's cheaper for my employer than paying me to wait for tests to run.
Im unconvinced. Making sciency charts doesnt mean there's well grounded research.<p>The only place i worked that had a WIP limit... i never got the point. Like agile seems to be largely about visibility for management or clients, so the idea of artificially restricting people from reporting what theyre doing... like why?