TL;DR
- Limit the WIP by process step
- Finish what is started
- When “blocked” instead of picking up something new resolve the bottleneck
- The end result will be a self-optimizing system of continuous improvement in which value throughput is always increasing.
Theory
Terminology
- WIP = Work in Progress, tasks started but not ‘done’
- Limited = a constraint on how many items can be in a workflow step at a time
A simple idea: WIP should be limited and something new should be started only when an existing piece of work is delivered or pulled by a downstream function.
This doesn’t sound very revolutionary nor does it sound like it would profoundly affect the performance, culture, capability, and maturity of a team and its surrounding organization.
What’s amazing is that it does!
It’s counter-intuitive that limiting WIP to small values increases throughput to “done” precisely because of these limits.
How? When WIP is limited in a system, anything that becomes blocked for any reason clogs up the system.
These clogs expose bottlenecks, queues, variability, and waste – all which impact the performance in terms of the quantity of valuable work delivered and the cycle time required to deliver it.
WIP limits thus have the effect of focusing individuals, teams, and organizations to have conversations about these bottlenecks, to discuss candidates for change, and ultimately to collaborate on improvements that will remove these blockages, restore flow and minimize the lead time (Kanban) or maximize velocity (Scrum) to “done”
Think about it: When is the last time your customers got value out of something you started? The value in a task is not starting it, but completing it.
Get to done. So value can be delivered.
Practice
So, how does this work in practice?
In most “agile” methodologies the focus of WIP limits is on the system – the entire value chain.
However, the concept and value of WIP limits apply equally to the performance of individuals as it does to systems and teams.
Here are the core practices:
- Visual the process steps that move a task from “started” to “done”
- Explicitly set WIP limits (for the process steps, for teams, for an individual).
- Respect the limits and make the bottlenecks clearly visible in real-time for the entire process/value chain.
- Address and remove the (current) bottlenecks.
- Rinse and repeat.
The end result is a self-optimizing system of continuous, permanent improvement (kaizen) in which value throughput is always increasing.
Visualize the workflow
You can visualize the workflow process thru the JIRA “agile” boards, physical post-it note project sprint team boards.
Columns correspond to process steps of the entire value chain in the workflow. (They all end w “done.”)
What should the WIP limits be?
Excessive time should not be wasted trying to determine the “perfect WIP limit” for each step of a process.
And not every step must have a limit.
The goal is to limit what you/team is doing and take care to finish what is begun.
Pick a number that is “close enough.” Monitor time in the queue. Empirically adjust as necessary.
- Too low WIP limit => idle people => bad productivity
- Too high WIP limit => idle tasks => bad lead time
A good starting point would be in the range of 1-3 per person per process step.
But it is arbitrary. Again, what works for you, your team, your process.
What about different WIPs for Epics, Stories, Grains of Sand?
Should WIP limits vary based on task size? Or by work item type?
Probably not. I think it would be better for teams to try to get things into roughly equal-sized stories.
But keep things as simple as possible. Focus on completing tasks first, and make task size reduction and consistency a secondary concern.
Respect the Limits
There’s no blood-oath saying we will never exceed a WIP limit. The limit is a healthy constraint – not a law.
This flexibility gives us the freedom and autonomy to deal with situations as they arise.
We just need to be very aware when we are violating the constraint and that there will be penalties for completion time and quality of the items currently in-flight. So there should be an intentional decision with a concrete reason.
When exceeded WIP limits, strive as quickly as possible to get back to the WIP limit. But don’t skip the discussion about the root cause of the bottleneck… Seek balance.
When we limit our work-in-progress, we are seeking to place healthy constraints into our work economy that promotes healthy flow.
When a WIP limit has been reached and you don’t have anything else “to do” celebrate briefly and then look for a bottleneck downstream (i.e. items piling up to the right on the agile board). When a WIP limit has been reached, an impediment causes a process to stop somewhere.
If a WIP limit has been reached, and you have work that is blocked, the blocked work should not be put aside while something else is started. (No matter how motivated we may be, we’re all guilty of leaving tasks half done, or even mostly done, but not actually DONE done.) The best course of action – to maintain flow – is to pursue the impediment, track down its root cause, and resolve it. (More on that below)
If there are no bottlenecks, celebrate again for a moment, but then consider that the WIP limit might be too low…
Collaborate to optimize the whole value chain rather than just your part.
What do we do with the bottlenecks when we find them?
So WIP limits have been hit (and respected, yay!), a bottleneck has appeared and there is a backlog of work waiting to be processed.
Congratulations! Now what?
Are we capacity constrained or not?
Identify the potential throughput of that bottleneck/constraint and compare that to what is actually happening.
If the bottleneck is operating at its full capability and there is still not enough throughput, then we are “capacity constrained.”
The capability would then need to be enhanced to increase throughput. In lean/agile terminology, we need to “elevate the capacity”
But this comes with an investment cost – both in terms of time and money.
“Elevation” should be the last resort. (If you want to take a deeper dive, read up on in Andersen’s book Kanban, Chapter 17 Capacity Constraints and the Cost of Elevating a Resource)
Eliminate waste, variability, inefficiency
More likely, the bottleneck is not working at full capacity.
There is capacity, just not “now.” So we look for what would we need to change to make that happen (so the bottleneck will move somewhere else…)
- Is there waste or inefficiency that we can remove? Rework? Excessive transaction or coordination costs? Was there ambiguity in requirements? Unforeseen or poorly planned dependencies? Requests for approval for items not fully completed?
- Can we minimize or eliminate non-value-added activities required by that resource?
- Can we move the necessary non-value added activities to a resource that has some slack?
- Is the constraint a result of variation in workload – i.e., is the resource sometimes idle and just overloaded now? (Did you expect/need instant availability?) Then we need to work on damping variability, and creating a buffer.
In any event, identify, escalate, communicate, collaborate, and resolve. (See “Looking Deeper“)
Other bottlenecks will eventually emerge as system constraints move elsewhere… However, first, give the recent changes time to stabilize before attacking the new bottlenecks…
Personal WIP Limits – “Finish” before you “start.”
The majority of literature on the value of limited WIP focuses on the process and not the individual.
But WIP limits on an individual basis are surprisingly empowering!
It’s interesting that a constraint can be something that makes you free!
When there’s so much to do, limiting the number of things we do at any given time allows us to:
- Make sure what we are going to start is actually ready to be worked on
- Focus on completing what we start
- Avoid context switching and split focus
- Keep an even pace, avoid stop/go behavior, keep things flowing
- Have a clear visualization of workflow and of the definition of done
- Reduce the duration of all tasks in our queue
- Understand the value of what we choose to work on
The practice on an individual level is the same as on the process level – respect the WIP limits, uncover the bottlenecks, and work to resolve them…
When we limit our WIP, we are able to focus, complete faster (much faster), and likely have an end product of higher quality.
Learn more
Personal WIP
- Getting Results the Agile Way: A Personal Results System for Work and Life
- Personal Kanban: Mapping Work | Navigating Life
