KanBan: Limiting WIP….But To What End?


The Kanban technique is popular within software development circles.  It borrows from the world of manufacturing where the original Kanban method is used to govern and regulate the production by any one operation so that it works in tandem with the overall production process and plan.  This article looks at how Kanban limits work in process inventory in software development and seeks to understand the value of doing this.

Work in Process in Manufacturing

In manufacturing Kanban is used to limit WIP inventory in manufacturing processes. But why is this done?  What’s the problem with WIP inventory in manufacturing? Isn’t having enough work and supplies for the next operation in line a good thing?

The answer centers on cost.  Excessive amounts of WIP inventory in manufacturing cost money.  Kanban isn’t about getting faster, or delivering a better quality product…it’s about not wasting materials, machine cycles and time creating something that won’t be needed. Overproduction of WIP inventory creates these costs:

1. Spoilage – too much work in process inventory can result in wasted goods ( especially food production ) because the downstream operation doesn’t need all the WIP inventory that was produced.

2. Overproduction / over purchasing of a part – If an operation in a manufacturing plant routinely produced more widgets than were needed by the next operation using them then the purchasing department is probably acquiring more raw material for that one operation than is actually needed by the overall production schedule.  This would result in the company having extra raw materials, which are often ordered in large lots for price optimization.

3. Wasted Operator Time  – This cost is a bit of a paradox.  Look at an operation that overproduces and it may appear in isolation that it is productive by a simple ratio of units produced/hours worked.  But, in truth the operation is just wasting the operator’s time because what he/she is creating isn’t needed.  The operator could be used elsewhere in the plant doing other productive work or even be sent home to help reduce labor costs ( assuming they are paid by the hour or unit produced ).  The wasted operator time may actually cause overstaffing as well.

4. Wear and Tear / Unecessary Maintenance on Machinery. – overproduction means we use our machinery unnecessarily for anything over the necessary production level.  The additional maintenance and wear and tear on the machinery can get expensive depending on the operation.

5. Increased Storage Costs – Excessive WIP inventory may need to be stored somewhere beyond the immediate operating space for a particular operation.  This usually means stocking the excessive WIP in a warehouse.  Warehouses cost money to build, operate and maintain.  By limiting WIP and adjusting cycle time and throughput through a plant you can eliminate the need for a warehouse and move toward a JIT system with your suppliers.

Does Limiting WIP inventory in Software Have a Similar Corolary?

First, what is WIP inventory in software development?  In a very thorough article on InfoQ WIP for software development is considered to be “tasks actively being worked on”.  It’s interesting to note how Kanban flips scrum upside down.  In Scrum we size the work to fit a time-boxed iteration.  In Kanban we size the time to fit a work-boxed unit.

But what are the costs associated with overproduction of WIP inventory in software development?  Are there any?  Let’s model this from the manufacturing world first and then see if we can find other costs that may be unique to the application development space:

1. Spoilage – It’s hard to say a requirement, feature, task, or idea would ever become ‘spoiled’ in the strict definition of that word.  You might be able to say that a requirement is no longer relevant or needed.  So perhaps there is some cost associated with the business analyst over-soliciting enhancement requests that will never be built.  But most new software development efforts have some baseline set of requirements that must be produced for the system to be coherent.  So letting the Business Analyst work ahead to get those nailed down in an efficient and comprehensive way that speaks to designing a ‘whole system’ is probably worth the expense.  Further, software development is not manufacturing.  It’s new product development and has an element of creativity.  This element of creativity requires some waste.  All creative efforts do.

2. Overproduction / over purchasing – If the developers over produce on tasks, resulting in a large WIP for the QA team, does this in turn cause a business analyst to generate even more requirements?  Maybe. If you’re Facebook and you’re always adding new features to your product then software development can be seen as a production line.  It’s a never ending stream of work for Facebook which probably requires some regulation of workflow to balance necessary resources.  But if you’re Pepsi and you have a simple capital project that will end when the funding runs out…then there is probably a finite set of requirements and you run no risk of overproducing on those requirements.

3. Wasted Operator time – There may be cost here if the business analyst, programmer, or QA professional are working on requirements of no real value or the requirement is not needed.  Does this happen?  Sure.  But I don’t see how Kanban prevents this from occurring.  Sometimes low value or worthless features are requested, everyone agrees they should be built, and it doesn’t become obvious until after completion that the feature should never have been added.

4. Wear and Tear / Unecessary Maintenance on Machinery –  This cost is hard to visualize for software development.  What would be the equivalent? Too much pounding on the keyboard?  Too much use of the CPUs?  Given that the computer would probably be used for something else if it were not being used by the developer/qa professional in association with their direct work; it seems there is a very minute wear and tear cost.

5. Increased Storage Costs – I can’t think of any storage costs that would be born with tasks that are not completed.  It costs virtually nothing to save these on whatever storage device houses them.  In fact the cost of storing anything in memory has been going down for decades.  Further, it’s likely the storage costs are spread across many budgets as more than one system probably shares the storage space.

So, some minor cost savings may come from limiting WIP in software development, but what should be very clear to any business professional is that Kanban in software development isn’t focused on achieving the same goals it achieves in manufacturing.

Kanban in manufacturing is seeking to limit the costs associated with overproduction of WIP.  Inventory costs are significant in manufacturing and need to be controlled, managed to limit their cost in the final product.  Kanban is a proven technique for this.

Kanban in software is seeking to limit WIP, but not for cost reasons.  The major cost in software development isn’t inventory.  It’s hours worked by people.  That cost comprises 90-95% of the cost for a finished software product.  So does Kanban in software limit hours worked?

Continuous Flow?

Software Kanban models the production flow of tasks associated with a software development effort.  Rules are established for production.  As an example:  the development team might set a limit of 3 done tasks as their kanban.  In other words they won’t produce any more tasks until at least one of the 3 done tasks is taken by the QA team for review.  This is a pull system.  Downstream processes determine the production of the upstream processes.

What makes this model successful in manufacturing is something called ‘cycle time’.  Cycle time is the normalized time required to produce a widget.  In most manufacturing processes cycle time for any one operation is well known.  This makes a pull process ideal.

In software development cycle time for any one task is variable.  This means setting a work in process limit on tasks will not necessarily guarantee continuous flow.  Further, in manufacturing a widget sent to a downstream operation is ‘complete’.  It’s not waiting on any further refining by the upstream process or any additional widgets.  In software development a task that is done isn’t necessarily testable.  It may require execution of a 2, 5, or 10 tasks for a piece of work to be testable.  So even though the QA team accepts additional work tasks from development, they may not be able to do anything with them.

Thinking through those points, it doesn’t appear that Kanban would limit hours worked by anyone.  In fact, it may actually do the opposite and increase the cost of the software development process as upstream operations wait until the downstream process completes work.  This idle time, might be seen as valuable in  allowing a team of developers, business analysts, or testers to switch to another project while waiting for completion of downstream tasks on an existing project.  But this then brings up the question of context switching and introduces even deeper complexities, entanglements into the production process.

Visibility of Workflow…the Real Value

So if Kanban doesn’t necessarily yield a more efficient development effort then what is the value?  Is there any?  The Kanban board is used to model the production flow of software development through its major person roles:   business analysis, development, QA, acceptance testing, and release management.  This board is visual and if kept up to date gives an interesting view for anyone hoping to manage the software development process.   At a quick glance the team can easily see where things are potentially bottle-necked and begin to focus on how best to free up that bottleneck.  This is the strongest value Kanban offers to software development: kaizen on the flow of tasks.


Does this article suggest Kanban is misguided in its implementation in software development?  Not at all.  Attempting to borrow techniques from other industries that have been successful is a useful, pragmatic approach.  Modeling the flow of tasks between processes has value in just opening up questions about why something isn’t done and what’s blocking completion.  However, this article does suggest that hoping to see significant, immediate cost savings in your development process using Kanban may be a false hope.  The true value will be unlocked by continually focusing on how best to increase the number of requirements produced per hour by the team.

Two Agiles

We all know this.  But it sometimes gets lost in the haze of execution.  There are two agiles.  The first is the philosophy, the belief system which is represented by the agile manifesto.  The second is the agile practices that were an outgrowth of the agile manifesto: scrum, xp, crystal, dsdm, etc.  Commonly, when people talk about agile…they’re talking about one of the practices that were an outgrowth of the manifesto.

What should be clear, but often isn’t, is that the agile manifesto doesn’t mandate the use of scrum, xp, waterfall, or one of the others.  In  fact, by blindly adopting one of these without considering the context of your project…you’re being anti-agile.

Predictive *AND* Adaptive Planning


If you’ve managed projects for any length of time you understand the truth.  It’s almost never the case that a project is completely predictive ( waterfall ) or completely adaptive ( agile ).  It’s a mix.  There are needs for both in any project.  Those project managers, companies, and consultancies that integrate both approaches into their project management efforts are hybridizing the agile movement and shaping the reality of the future.  Let’s look at some examples that are well known, visible, historical and outside the IT market.  Why?  I want to defuse the agile vs waterfall debate for a moment and abstract things away from technology to help us see the broader picture.

Example 1: Lewis & Clark Expedition

The expedition by Lewis and Clark to navigate the Missouri River and map the western territories was an immense, RISKY, long term project entertained by a focused project team of professionals.  This is a startup.  Their goal was to map a water born ( river ) path to the Pacific Ocean.  To accomplish this goal some level up front planning was required.  You simply couldn’t plop two guys down in St. Louis and say: “For the next two weeks go up the Missouri River, then have a retrospective on what you learned, share that learning with your sponsor in Washington D.C. and plan for the next two weeks of river navigation.”

Lewis & Clark needed supplies, people who knew the land, logistical expertise, some plan up front to start the mission. But while an up front plan was necessary, much was not known.  This is where adaptive planning comes in.  They would need to adapt as maps, events, and people turned out to be unreliable or poorly understood: winters were more severe, the Missouri didn’t go all the way to the Pacific and great Mountain chain blocked their path to the ocean, and accidentally injuries and sickness delayed progress.

While not having an up front plan could have delayed and increased the cost of their project…not being able to adapt along the way would have killed it.  It was an experiment, a gamble, and to make it work required flexibility and persistence.

Standish group would have called Lewis & Clark a failure because they exceeded their baseline schedule.

Example 2:  Apollo missions to the moon.

The missions to land men on the moon and safely return them during the late 1960s and early 1970s in the United States were massive projects of unknown risk and horrible complexity.  Failure would bring down a nation and a philosophy ( democratic freedom).  They closely mirror big ERP implementations or suitably large custom software development efforts in Fortune 500 businesses today.

Could these have succeeded without predictive planning?  It’s hard to imagine they would have.  There were so many variables and unknowns that were required to be nailed down before implementation to ensure success.  In fact, predictive planning to the Nth degree is what made this possible and successful.  Accounting for every risk, having a mitigation plan for every risk, and carefully coordinating all the sub-projects to the common goal would have been hard to accomplish via strict adaptive planning.

This isn’t to say that adaptive planning didn’t play a role in adjusting and dealing with risks/issues along the way ( think Apollo 13 ), but this project was almost completely predictive by necessity at the top-level.  There was too much at stake ( human life and a nation’s perceived status in the world ).

Even though the Apollo moon missions proved to the world that the U.S. was the preeminent technology leader vs the U.S.S.R  and would be revered for decades to come….this project, using Standish’s metrics, would have been deemed ——-> FAIL.

Example 3: Building a Table in Garage with Your Woodworking Equipment.

A more personal, and human project…building a table is something that’s been done many times in the past.  This is like building a new e-commerce site for a company.  It’s been done before, they could have just bought a vended product, but for some business reason they want to build their own.

Ok, since it’s been done before there’s a pattern, and we borrow from it.  We download the diagram, purchase our materials, and define our plan.  This is predictive.  As we begin to execute we discover flaws in the plan or the procurement process.  Wrong nails were purchased or the leg supports were cut too small.   These events require us to adapt.

After building the table we’d dust off our hands and say “Wow, that’s a little over budget and it took some extra time, but I got what I wanted.”   We’d call it a success.  Standish would call it a failure.


I could go on.  What about Michelangelo’s works?  How about building the Dubai Tower?  Great human efforts ( projects ) are vision building.  Successful completion and delivery requires a range of approaches and a commitment to the end goal.


Hopefully you can visualize the adaptive *AND* predictive elements in these projects.  It wasn’t one or the other.  It was a gradient.  That’s where the present is and the future will continue to be.  Hybridization is good.  It isn’t about agile vs waterfall. It’s about achievement, belief, and success.

Stop Agilizing Everything


Agile universities, certifications, agile consulting, traveling coaches, planning poker card sets, agile software products, agile modeling, agile arm bands, countless agile books and the crazed cycle of agile conferences.


The buzz cycle is in overdrive and it’s electrocuted the business world with the promise of faster, better and cheaper.  This article is a plea to stop.  Stop all the hype, the opportunistic profiting, and the marketing.

Good Intentions Turned Ugly

What started out as a challenge to the software development community to think outside the box ( invent, create ), abandon a one size fits all model to approaching software development and execute your projects in a pragmatic fashion that takes account of the context you’re working in….has turned into a marketing machine of horrible dimensions.

There was a time when people talked agile and you knew they were on the vanguard; trying to solve the real problems.  They cared.  They were passionate, deliberate, and informed.  Now, when you hear a colleague professing agile…they’re most likely drinking the kool-aid poured by the snake-oil agile coach from Denver or San Fran.  The formulaic response to the core problems is all too familiar and draining:

  • Poor Requirements – You need user stories and iterations.
  • Defects in Software – Continuous integration and TDD will solve that.
  • Bad estimation – Use planning poker.  It always works.
  • Change Management – Break it up into iterations and embrace the changes given in iteration reviews.

I’m not knocking these techniques.  Many are novel inventions that do have their place in SD/AD.  But instead of being offered as potential options, patterns, techniques to solving a problem among many other potential solutions; they have become a sales pitch by the opportunist preying on desperate CIOs.  Buyer beware.  Bubbles pop and my gut says the needle to prick this balloon is getting very sharp and close.

Let’s stop agilizing everything. Good ideas, tools, and techniques don’t need the word ‘agile’ pre or post fixed to be worthwhile.

Come Back Home

So turn off the scrum-o-matic. Wipe the agile makeup from your face, and put the kanban sequin dress away. There are still problems to solve.  We haven’t unraveled this thing called software development.  It’s devilishly vexing and we need good minds focused on it.  Become neo-software-amish, come back home to the forest of software trolls and invent/create again.

NEWS ITEMS: Knowing the Solution & Risk Management in Software Development

Some of my recent news items on InfoQ……..check them out