I'm not familiar with lean and kanban used in this manner, but I would say it is a mis-characterization to invoke Toyota. Toyota's original system was associated with manufacturing, and was quite different from this. Honestly the only cross over I see are the little yellow boxes.<p>In the "old way", all the parts for a product were made in large runs at one time. It was expensive and time consuming to setup machines for different parts, so better to make them all at once right?<p>The downside is that you have a pile of inventory to be moved around, stored, kept track of, and the economics of having money tied up in parts inventory is terrible. Not to mention if you make a mistake on all of the parts, you have to throw them all away and make new ones (this happens more than you'd think).<p>Waste abounds.<p>With lean manufacturing, the goal was to minimize inventory (waste). The first steps were lowering changeover time on machines, transit time from suppliers, and overall cycle time. You don't need inventory if you can make new parts quickly enough. Not only did it make everything cheaper because there was less inventory, but intangible benefits included catching mistakes earlier and being able to make people accountable. It is a lot easier to call up a supplier and ask what they did differently yesterday to make a bad batch of parts, than to ask them what they did 6 months ago to make a bad batch of parts.<p>Notice the kanban hasn't come in yet. The kanban is all about information flow. In the old way, someone was making a top down schedule. This assembly line should make this many of these parts on this day, and so on. They had to guess not only efficiency and production time, but demand for the end product. If you suddenly needed extra cars, too bad you had to wait for next year because we have literally no more parts and it takes months to go through the whole dance of making runs of parts again.<p>In the new way, demand drives everything. The sub-assemblies don't get made until the final production area needs more, the parts don't get made until the sub-assembly area needs more, etc. The information flow is not top down, but basically bottom up or end back.<p>The kanban helps with that, basically the kanban is a note from people downstream saying we need more of what you make! Make it!<p>A simple example. Imagine a factory that makes syringes (not morbid, just simply one factory that showed me their implementation of lean manufacturing/kanban). You have one room making plastic parts and one room making metal needels, one room assembling the parts, and one room shipping them. Roughly 25 machines involved, 20 people, and a few million needles a day.<p>The shipping people get orders, and grab boxes from a small inventory, maybe there are 3 pallets of needles kept there and when they get down to 1, they grab a kanban and walk it back to the assembly area. The kanban is a simple magnet.<p>When the assembly people get a kanban, they place it on the appropriate machine and pull baskets of parts off the wall. They might have 5 baskets of plungers, 10 of bodies, etc. When they get down to a predetermined number they walk a kanban back to the plastic extrusion room and slap it onto a machine.<p>The guys in that room start making the appropriate part and filling up bins. They might have 200 or 300 kanbans in the factory that are just little magnets telling people what to do today.<p>There are no more schedules or even management telling people what they should be doing, the people on the floor are doing that in real time as orders dictate. It is simple, elegant, and works amazingly well.<p>However, I don't really see the connection to project management or software development. Someone please enlighten me (not being sarcastic, I just really don't get it). I push lean and kanban in manufacturing all the time - I'm a huge believer - but I would love to extend it into engineering/design if someone knew a way.