I studied Kanban, as it applies to manufacturing, some time ago. I have no idea how it could apply to software development. It seems a poor fit for it. Kanban

I studied Kanban, as it applies to manufacturing, some time ago. I have no idea how it could apply to software development. It seems a poor fit for it. Kanban is not a queueing system, it is a system for identifying bottlenecks in a supply chain and at all times minimising the amount of components that need to be manufactured. One of the key revolutionary features was that the supply chain extends to each component so different departments become suppliers to others. What typically happens is that there are a certain number of kanban cards for each component. Each card represents one component. When a client takes a completed component from the stock, the associated kanban card goes to the start of the queue. Someone picks up the card and starts work on the component and the card follows the manufacturing process until the component has been completed. The card stays with the completed component until a client takes the component and the cycle begins again. The purpose is that by counting the number of cards at the start (number of items requested by clients) and at the end (number of items constructed but not yet claimed by a client) it becomes trivial to identify bottlenecks. Apart from this then-revolutionary pull-based process, Toyota's process had two other key findings. 1) the same worker should stay with each component until completion. One kanban card = 1 worker. If someone is assembling a car door, they don't half-complete a door and pass it on to someone else, they follow it from the time they pick up all the components to the time that it is completed. They found that this was the most productive way of working. 2) You do not deliver a faulty component to a client. That is, each component must be tested before going on to the next stage.