Since full adoption of Kanban at Toyota by 1962 and well into 2025 the best management advice remains the same - "Stop starting, start finishing" or "Minimise Work In Progress".
Many business leaders think they are smarter than the system and can get better results by "doing more faster". This is similar to trying to water the garden faster by putting more water into the hose where the physics of pressure and flow will quickly prove you wrong.
The science of team productivity is very close to the science of flow velocity and pressure. By throwing more into the funnel when your team is at peak throughput, you don't increase value delivered, you increase pressure on the team and reduce actual throughput. Exceeding capacity doesn't just add pressure - it actively decreases output due to friction/resistance.
Why Too Much Work In Progress Is Bad - Simple Analogies
If your goal is to produce as much value as possible, as efficiently as possible, too much work in progress is bad. If your goal is to see how far you can push the team or system before it implodes, more work in progress might help, but this article is not for you.
Imagine you are a builder paid by the hour, and it takes you an hour to unpack your equipment, an hour to pack up your equipment and some time to travel between destinations. Given you have 4 projects to complete across 4 weeks, would you rather complete them sequentially week by week or work on all 4 in parallel across the 4 weeks? Do you think you'd complete them on time if you worked on all 4 in parallel?
Imagine you're a writer with many ideas. Would you consider writing 10 books in parallel?
Most people will respond with "Don't be silly, of course I want to finish one thing before the other!" in these scenarios, yet when it comes to software development, they will happily throw 10 big changes to 3 rewiewers and expect it to yield quality results for the user, fast and cheap.
Sequential Iterations Beat Parallel Chaos, Even When Requirements Change
The counterintuitive truth: completing work sequentially and then adapting is more efficient than trying to handle changing requirements across multiple parallel streams. When you finish Change A completely before starting Change B, you gain several advantages:
- Clear learning: You understand what worked and what didn't because your users already got their hands on the feature
- Clean adaptation: Further adjustments to Change A can be made with complete knowledge of the system
- Reduced complexity: Only one set of requirements is changing at a time
- Faster pivots: A completed feature can be modified fast, managing shifting requirements across multiple incomplete features is slow
Even if Change A needs adjusting after completion, the total time is typically less than managing evolving requirements across Changes A, B, and C simultaneously. Sequential work creates clean decision points where teams can incorporate new learning without the cognitive overhead of tracking multiple moving targets.
Requirements will always change - but managing change of something done and dusted is infinitely easier than juggling five changes.
Humans Thrive on Sequential Work and Flow States
Human cognitive architecture is fundamentally designed for sequential focus, not parallel processing. Mihaly Csikszentmihalyi's research on flow states shows that meaningful work requires sustained attention periods of 2-4 hours to reach peak performance and satisfaction. When we work sequentially, we build momentum. Each completed task provides psychological reward and reduces cognitive load for the next task. Every additional concurrent work stream occupies precious mental bandwidth that could be used for creative problem-solving and quality work.
Need help minimising work in progress?
Why 10 Value Streams By 4 People In Parallel Is a Problem
When the same people spread across multiple value streams simultaneously, simple context switching is only one of the problems they face:
Conflicting Priorities:
Different value streams often have competing deadlines, quality standards, and expectations. Team members get caught in the middle, unable to optimize for any single outcome effectively. Ironically, there is usually an implied top priority which gets delayed along with all other work.
Communication Overhead:
Each additional value stream requires separate comments, status updates, discussions, and coordination. Remember that communication complexity grows exponentially, not linearly, with each additional stream.
Quality Degradation:
Divide people's attention - and each value stream will receive less attention and consideration. The team will produce consistently mediocre work across all streams rather than excellent work in fewer areas.
Change Integration Further Limits Capacity
Shipping software has a minimum two capacity limits (we will leave other limits for later):
- capacity to make changes,
- capacity to making said changes work with other changes - integration.
When adding a new feature or shipping a fix, most companies expect that other features and fixes will continue working, that is the latest change integrates well into the existing system. Ensuring successful integration of individual changes is an effort of its own and has a capacity limit.
- How many product flow changes can your product team handle without confusing the end user?
- How many integration and end to end test pipelines can your setup handle?
- Are your APIs, rate limits and internal consulers mature enough to handle changes?
- How fast can you make system changes given contractual notice requirements?
What Happens Above Capacity?
- Your team spends energy on context and task switching instead of work that adds value,
- Quality decreaces and results in more rework,
- Communication overhead increases exponentially,
- Some work actually flows backward -gets undone/redone or ends up on the ever-growing backlog.
The physics are unforgiving. The most efficient team is like a water pipe - just like forcing too much water through a pipe creates turbulent flow that reduces net throughput, exceeding team cognitive capacity creates "workflow turbulence." Teams don't just slow down, research shows teams pushed beyond capacity often complete 30% fewer items than their sustainable pace, while working longer hours and producing lower quality work. The extra pressure doesn't create extra output - it creates negative efficiency.
Admit That Context Switching Isn't Free
You may wish that team members can switch contexts without impact on their abilities. You can also wish that your internet connection is faster than the speed of light. Limits proven by science will disappoint you in both cases.
Context switching has cognitive cost that has been measured and your team is not exempt. Sophie Leroy's research on "attention residue" (the link offers the shortest and simplest summary) shows that part of your brain stays stuck on the previous task even after switching. Even brief interruptions can increase task completion time by 25%.
Our brains treat each context switch like a small trauma - they have to rebuild mental models, remember where we left off, and recreate the flow state. This "switching tax" compounds with each additional concurrent work stream.
When Is Context Switching Acceptable?
If you work in a consultancy and have multiple workstreams (from multiple clients) with objectively separate goals and outcomes, you can build the cost of content switching into the workflow.
For example,
- Ramp up and work on Project A for 3 hours (after a natural break of a new day)
- Wrap up Project A, context reset and ramp-down for 1 hour
- Work on Project B for 3 hours
- Wrap up Project A, context reset and ramp-down for 1 hour
- The overhead of ramp-up and ramp-down is constant, regardless of holw long you work on one client project.
Successful context switching requires engineering the switching cost into your system rather than pretending it doesn't exist. Most development teams attempt context switching without accounting for the overhead, then wonder why everything takes longer than expected.
Once you accept that the overhead of ramp up and down is constant, you will naturally want to context-switch less and less. If there is moneraly value in 3-4 switches a day and you're willing to accept the overhead, consider the impact on your people and whether there is a more optimal business model.
Optimize for Human Efficiency, Not Machine Efficiency
As long as we rely on teams for coordination, decision-making, quality control, and creative problem-solving, we must optimize work patterns for cognitive efficiency of that team, not abstract "resource utilization".
Humans are not CPUs that can context-switch without cost. We're not parallel processors that can maintain equal focus across multiple threads. We're sequential thinkers who build momentum, create flow states, and produce our best work through sustained concentration.
The goal isn't to keep every team member "utilised" at all times - it's to create an environment where they can do their best work. Sometimes this means deliberate downtime, focused sprints, or accepting that certain skills will be temporarily underutilized.
Until AI agents can handle all coordination, quality decisions, and creative problem-solving autonomously, the primary constraint is how your team's brains work. Optimize for that and reduce Work In Progress.