In quest of making project management lean and mean, project managers are trying to adopt Kan-ban principles. But what is Kan-ban anyway? How Kan-ban can be adopted for software projects?
In traditional manufacturing, people used to keep inventory at strategic locations through out their supply chains. The assumption was that, in case of emergency (machine failure, accident, rushing for a spike in demand etc.), these piles of inventory will come handy. Slowly people realized the drawbacks of keeping inventory. Excess inventory used to lead to inventory obsolescence, inventory damage, capital tied up in form of inventory etc. Then they thought how to eliminate the need to have excess but handy inventory piles. Research at the Japanese car companies (Toyota etc.) resulted in the concept of Kan-ban.
In traditional manufacturing, apart from excess inventory piles, there is also the concept of safety stock and safety stock level. When at any inventory keeping location, the amount of inventory reaches to this safety stock level, the stock keeping person will order additional inventory for that location. Until the fresh stock of inventory used to reach that location, the manufacturing process would keep using inventory from that safety stock. That meant some inventory was still remained from the old stock even when the fresh stock arrived.
This arrangement had 2 drawbacks. First, utilization of inventory was not efficient. And second, there was always chances of damage to inventory in handling. At the same time, there was a cost associated with keeping the inventory.
Toyota Car Company decided that they should eliminate inventory completely. They also realized the problem of damage to inventory in handling. They then asked all their parts suppliers to provide inventory just-in-time (JIT). JIT is also known as Kan-ban. They facilitated so that all their suppliers moved closer to their manufacturing plants. The suppliers also started carrying parts very near to location where they were needed. The suppliers thus were made responsible to manage their own inventory and that Toyota will not keep or manage any inventory. This arrangement is better known as vendor managed inventory (VMI).
These initiatives ensured that Toyota was free of inventory and the drawbacks of keeping inventory. This immensely benefited Toyota in cutting costs as well improving quality of their cars. This is how Kan-ban originated as we very well know.
Essentially Kan-ban means one at a time. Through various signs, a work center signals that it needs inventory. The supplying agency sees this sign and provides the next piece (or small batch) of inventory.
So how we can use Kan-ban concepts on software projects. Well, presently agile software projects are executed without taking into account the Kan-ban concept and thus may be working with more than one requirement at a time. Under Kan-ban, the project team will take just one requirement at a time and go through the entire process of building the software feature which corresponds to this software requirement. There should absolutely be no other requirements which the project team should be working simultaneously with this requirement. Once the complete iteration is complete then the project team should take the next requirement and again go through the complete iteration.