All Kanban Queues Are Not the Same - Manufacturing and Software Services Are Different

November 29, 2016 — Posted by Ken Pugh

Kanban originated at Toyota as part of the manufacturing process.  It’s been adopted to software delivery.  In both forms, there are stages of production or creation that may have queues in-between the stages.  Differences in the purpose of these queues are sometimes overlooked when describing the flow through software processes.   Along with queues, “pull” and “push” can have different meanings in terms of software.   


Kanban started a manufacturing process where downstream portions of a process signaled upstream portions to produce something they needed.   An example can clarify this.  Here’s a simple version of making a car, without any queues. 

Manufacturing Kanban without Queues

When a customer orders a car, it signals the last step in the process (“Mount Tires on Frame”) that it wants a car.  That step signals “Make Tires” and “Mount Engine on Frame” that it needs the parts that they produce.  The “Mount Engine on Frame” step in turn signals “Mount Body on Frame” that it needs that part, which then signals “Make Frame” and “Make Body”.  

In Kanban, the signal mechanism originally was a card (Kanban is Japanese for card or visual signal).  A card (the order) is sent to “Mount Tires on Frame”.  Then each step sends a card to its upstream steps.

The flow shown is without any queues between the steps.  When the order arrives, it may take some time for each step to complete its operation.   There is no partially completed inventory in this form of the process.

The processing the car order is referred to as “pull”.  The arrival of that order signals each step to pull something from its previous steps.  


Here the flow with queues between each step.   The queue holds completed parts from each step. 

Manufacturing Kanban with Queues

Now when the order comes in, “Mount Tires on Frame” pulls a part from each of the queues filled by its upstream steps.   Those queues will signal their process step when that it another part needs to be made.   The car is delivered quickly, as the time required is only that of the final process step.  

Queue Considerations

There are tradeoffs in deciding what the size of each queue should be.  It should be large enough so that a downstream step doesn’t find it empty and have to wait (as in the queue-less example).  However, it should not be so large that there are excess parts piling up, which causes financial issues as well as the possibility of those parts never being used.    There is a balance which can be found dynamically by monitoring the queue size.  

There is another consideration in queue size – the batch size that is optimal for each step.  Ideally each step could produce just one item at a time.  Setup time and transport time may require a larger batch size.  So there is another balance that is found dynamically.   For example, Toyota tried to make individual parts or small batch of parts using a reconfigurable press.   The time to reconfigure the press for different types of parts was getting in the way of producing the parts in a timely manner. So the batch size for those parts was increased. 

In an idealized Kanban process, the signals between the process steps and the queues are all that is required.   However, some process steps need a bit of look-ahead.  This look-ahead consists of an estimate of the final outputs – in this case, the number of cars that will be produced.  If there was a sudden increase in orders for cars, a queue might be emptied quickly before an upstream process could fill it.  As a common example, consider the grocery store shelves when a hurricane or snow storm is forecast.  The need for restocking is too large to handle for the normal process steps. 

Toyota gives forecasts to its upstream suppliers as to the demand for cars.   The suppliers use this information to tailor their processes with sufficient capacity to produce the needed parts.  

Software Kanban

Now let’s look at a software Kanban.  Here’s a simple example without any queues.  The model looks the same as the manufacturing process, but there are substantial differences.   When it has been decided that a new feature is to be developed, the new feature does not signal the “Deploy” stage that it should be created.   Nor does “Deploy” state signal the “Develop and Test” process to create the feature.  

Software Kanban with No Queues

Instead, the New Feature is feed into the process from the “Discover and Decide” step.   Without any queues, the “Analyze and Detail” step would begin.  When it was done, “Develop and Test” would start with “Deploy” initiated after the feature is developed.   This is more akin to a “push” flow.   However, if a step is already active completing the previous feature, then there is nowhere to push the feature.  So typically, queues are added between the steps. 

Software With Queues

With queues, the process looks like this:


Software Kanban with Queues

Now when “Discover and Decide” creates a feature, it puts it onto a queue, “Features to Be Analyzed”.   When the “Analyze and Detail” step has capacity, it pulls the feature and starts working on it.  When completed, the step places the feature onto the “Features to Be Developed” queue.  Likewise, when “Develop and Test” has completed its previous work, it pulls the feature.  When done, it places it on the “Features to Be Deployed” queue, where it waits until “Deploy” can take care of it. 

There is “pull” at each stage from the upstream queue.   But that pull is not generated by a downstream stage signal, but rather from unused capacity within a stage.  

Queue Considerations

To ensure a continual flow through the system, each stage should monitor its downstream queue.  Once again, there is a balancing issue.   If the queue is empty for a while, then downstream capacity will go unused.   On the other hand, if the queue has too many items in it, then those items will affect the overall time for a feature to go from “Discover and Decide” to “Deploy”.   The queues should be monitored and dynamically adjusted.  But the queue management is different from the manufacturing queue management.  

In manufacturing, the parts in the queues are for the most part the same (at least for the same model of car).  In software, each feature is different.   The amount of time required for each step to process a feature can vary widely.   Some guidelines suggest that features be broken down into smaller portions whose size is more consistent.   This can help the flow through the “Develop and Test” stage, but may not be applicable to the other stages.

In manufacturing, if the upstream queue is empty, the process halts and the equipment sits idles.  In software, if the upstream queue is empty, the people involved in the process may work on other steps of the process or take care of non-process related tasks.   

In manufacturing, if all queues and stages are empty, the amount of time for a car to be output is the total amount of time through the longest set of stages.   If queues are not empty, the time for a car will be the amount of time in the last stage.   In software, if all queues and stages are empty, the amount of time between deciding on a feature and deploying it will be the smallest possible amount of time for that feature.  There will be a lot of unused capacity.  (This is the equivalent of firemen waiting for a fire.  They need to respond quickly, but they are underused when there are no fires.)    With filled stages and queues, the amount of time to deploy a feature increases.  


When applying Kanban as your software process, be sure to recognize the differences between manufacturing and software.  Tips and guidelines for one do not necessarily apply to the other.   Pull means different things - downstream pull in manufacturing and unused capacity in software.  The item work size in manufacturing are fixed, while the sizes in software are variable and sometimes unpredictable. 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives ( He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban