
Why limiting work-in-progress works - ahyattdev
https://lethain.com/limiting-wip/
======
closeparen
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).

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.

~~~
xiphias2
I have seen this change when I was working at Google. The key problem was that
the PM to Engineer ratio increased in the company, and we were getting a lot
of extra work from the PMs that looked nice on paper, were easy to understand,
but didn't have a real positive impact on the customer. This extra work
completely blocked us from improving the performance of the product.

~~~
JoshTko
As a PM I'm curious what type of work that falls into this category. Also
curious if this was specifically coming from the PM or if it was coming from
above.

~~~
xiphias2
It usually came from sales and other teams. The big difference that I saw is
that in the past to give an engineering team work from another team meant that
the other team's TL had to convince the TL of the team to take the work, and
the TL had enough context to push back (which I believe is the best thing to
do in most of the cases).

In the old Google PMs were working on promoting the work of engineering teams
and communicating with sales/ops, but didn't have a strong power over the
direction of the work of the engineering teams. Their time was a scarce
resource to be used by the team, not extra bosses. In the new Google, PMs have
a lot of time that they are using for fighting with each other to have some
feature implemented that they are pushing.

Also the best PMs in the old Google had some engineering background, and were
doing log analysis without asking help from the engineers for every question.

------
klenwell
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-...](https://www.goodreads.com/book/show/22586058-the-principles-
of-product-development-flow)

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.

~~~
marcosdumay
> So having read the article, why does limiting work-in-progress work?

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.

~~~
donmcc
Looking through past posts, it looks like the author used this:
[https://lethain.com/systems-jupyter-notebook/](https://lethain.com/systems-
jupyter-notebook/)

~~~
marcosdumay
Oh, thanks.

So the article just postulates that started WIP projects slow down developers
on a linear basis. So when he takes away that slow-down, things get faster.

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

~~~
williamdclt
Actually...

I've had this exact problem (~30min CI and slow CR) on my current project. For
a while I've sucked it up and did concurrent work as you say.

After a while it becomes apparent that this concurrent work is making us lose
a lot of time:

\- PRs still aren't merged several days (2 on average, regularly more) after
being open. The longer they stay the more expensive they become (regular
rebasing, context-switching, CRs being more and more exigeant and enlarging
the scope of the PR) \- Bugs appear. Doing several things in parallel leads to
a loss of quality. \- We're not improving, this unideal situation becomes the
norm.

So I'm trying something else: we're not starting a new ticket before the last
one is done. That means waiting for CR, waiting for the CI. That means having
times where my employer pays me to wait for tests to run. Well, the result:

\- We're actually faster. The context switching + rebasing cost is far higher
than waiting 30min for tests to pass. \- Now, the problem that the CI and the
CRs are slow is _visible_ (I'm visibly not doing anything), which means that
we can _work on it_ and improve! That's a basis of lean manufacturing: make
problems visible. \- We chase people to get reviews, so the lead time of each
ticket significantly decrease. Also I'm automatically available to help people
review my code (if it's a complex bit or it's a junior reviewing). \- We take
tickets to improve our CI and our testing perfs

All in all, doing one thing at a time was already more efficient, and in
addition we can make our process more and more efficient.

The main pushback on this is generally "but we need to context-switch to
review PRs", but in the end you do way more context switching when working on
several things at once.

------
overgard
Im unconvinced. Making sciency charts doesnt mean there's well grounded
research.

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?

~~~
overgard
By the way here's what actually happens when you set in place WIP limits. I
think most of us adult professionals realize that a person has a few things on
their plate and a thing can be "in progress", but waiting on something, and
they probably don't have the patience to move it around on your JIRA board
every couple hours. So your task management essentially becomes a narrative.
So you get people to lie to you and pretend like they're super focused on this
one priority. It's a ridiculous game. Just don't play it.

