|
|
|
|
|
|
by klenwell
2682 days ago
|
|
|
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. |
|
|
I imagine his models are those code blocks just above the images.
A reference to the language those are written on would be great, and would let we check if the code is really realistic. But it's lacking, so I can't explain why the article claims this.
Limiting WIP happens to work on practice, and is the basis of the kanban process (both the one we use in software development, that doesn't even have a kanban, and the industrial one). Scrum does give you some tools you can repurpose into managing WIP, but those are not as robust.