A great Kaizen technique is to drive towards lot size one. In manufacturing this means that each part goes through the process separately. It usually also means that you can interpserse different parts in the production process. For instance, in the case of the injection molding supplier for Porsche that I mentioned previously, it meant figuring out how to paint each part separately instead of in batches of twenty parts. Some of the advantages of lot size one are immediately apparent. Say your color is off slightly. If you paint twenty at a go, you will have to either repaint twenty (which requires a lot of manual intervention) or scrap them altogether. With lot size one, you have at most one part that requires rework. Lot size one also supports greater variety. Suppose Porsche wants to offer some colors of which they expect to sell only a few, then producing them in batches of twenty would result in a lot of extra inventory. Finally, lot size one is the precondition to on-demand manufacturing. Porsche in fact has switched most of its production to be on demand pretty far back up the supply chain. So one of these injection molded parts in a particular color is now made only when someone orders a Porsche in that color.

What does lot size one mean for software development? We tend to think of software features and code as consisting of unique parts, so it would seem to be lot size one by definition. It is easy to see the parallels though. Letting developers work for days or even weeks without checking their code back in, without integration testing and without running builds, is the equivalent of having large batch sizes. If someone is making mistakes, they will go unnoticed for a long time and a lot of “rework” will be required. This is especially true when multiple developers keep code checked out for long durations and on different schedules. If that is done, the overall system – meaning all the code that is under development – is effectively never in a working state. That makes it virtually impossible to be responsive to “on demand” feature requests that may come from the business side. Lot size one for software development then means nightly builds with everyone checking in all their code every day.

A great Kaizen technique is to drive towards lot size one. In manufacturing this means that each part goes through the process separately. It usually also means that you can interpserse different parts in the production process. For instance, in the case of the injection molding supplier for Porsche that I mentioned previously, it meant figuring out how to paint each part separately instead of in batches of twenty parts. Some of the advantages of lot size one are immediately apparent. Say your color is off slightly. If you paint twenty at a go, you will have to either repaint twenty (which requires a lot of manual intervention) or scrap them altogether. With lot size one, you have at most one part that requires rework. Lot size one also supports greater variety. Suppose Porsche wants to offer some colors of which they expect to sell only a few, then producing them in batches of twenty would result in a lot of extra inventory. Finally, lot size one is the precondition to on-demand manufacturing. Porsche in fact has switched most of its production to be on demand pretty far back up the supply chain. So one of these injection molded parts in a particular color is now made only when someone orders a Porsche in that color.

What does lot size one mean for software development? We tend to think of software features and code as consisting of unique parts, so it would seem to be lot size one by definition. It is easy to see the parallels though. Letting developers work for days or even weeks without checking their code back in, without integration testing and without running builds, is the equivalent of having large batch sizes. If someone is making mistakes, they will go unnoticed for a long time and a lot of “rework” will be required. This is especially true when multiple developers keep code checked out for long durations and on different schedules. If that is done, the overall system – meaning all the code that is under development – is effectively never in a working state. That makes it virtually impossible to be responsive to “on demand” feature requests that may come from the business side. Lot size one for software development then means nightly builds with everyone checking in all their code every day.