Manufacturology

How small batches improve product development

The idea of lean prod­uct devel­op­ment (LPD) came nat­u­rally when lean pro­duc­tion evolved into the more gen­eral con­cept of “lean thinking”.

Prod­uct devel­op­ment is dif­fer­ent from man­u­fac­tur­ing because, as soon as you tar­get non–trivial devel­op­ment tasks, they will con­tain a degree of risk that intro­duces vari­a­tion. You can’t remove this vari­a­tion, because eco­nomic rewards in prod­uct devel­op­ment are linked to tak­ing accounted risks. You add no value what­so­ever if you develop the same design twice!

“Lean­ness” is, as I see it, a mea­sure of how well a process man­ages to oper­ate with a lim­ited amount of work in process, WIP (see this post). Kan­bans, CONWIP, or any other con­trol sys­tem that set an upper limit on the amount of WIP can be used to cre­ate flow. The rate of flow improves when the limit (“WIP–cap”) is low­ered, but at the same time the flow becomes more sen­si­tive to vari­a­tion. In order to improve pro­duc­tion flow, you seek to elim­i­nate variation.

In prod­uct devel­op­ment, WIP trans­lates to design in process (DIP). In LPD, you improve flow by set­ting lim­its on DIP.

But you can’t make prod­uct devel­op­ment lean by remov­ing vari­a­tion because then you remove all value added. You have to live with vari­a­tion, and still avoid accu­mu­la­tion of DIP. Small batch devel­op­ment helps a great deal to accom­plish that goal.

Rein­ert­sen dis­cusses the role of batch size in prod­uct devel­op­ment thor­oughly. He shows how small batch devel­op­ment results in smaller changes, bet­ter qual­ity, faster feed­back, faster cycle time, and bet­ter econ­omy. The same ben­e­fits hold for lean pro­duc­tion sys­tems where rapid changeovers and in–process qual­ity con­trol (jidoka) allows small batch pro­duc­tion in a con­tin­u­ous flow.

At the same time batch size should not be reduced infi­nitely. One piece flow is not the goal in prod­uct devel­op­ment. Rein­ert­sen uses soft­ware devel­op­ment as an exam­ple: Soft­ware should not be tested after each new line of code.

Soft­ware devel­op­ment seems to be a pop­u­lar exam­ple of how lean prin­ci­ples can be used in prod­uct devel­op­ment. This is prob­a­bly because soft­ware can be highly struc­tured, mod­u­larised, and auto­mat­i­cally tested. A cou­ple of recent blog posts are rep­re­sen­ta­tive: Hunter talks about how auto­mated test­ing improves qual­ity since it acts as a mis­take proof­ing or poka yoke mech­a­nism. Groen­eveld argues that tests are use­ful, but that the use of high–level lan­guage con­structs rep­re­sents a more sophis­ti­cated and reli­able form of mis­take proofing.

I think that both are right, because auto­mated test­ing of a prod­uct that is com­posed of ready–tested and reli­able mod­ules facil­i­tates that devel­op­ers make very fre­quent deliv­er­ies of small batches of work­ing code. Rein­ert­sen, again, says that “when we reuse a sub­sys­tem, we also reuse test­ing, doc­u­men­ta­tion, system–level inter­ac­tions, and reliability–related learning.”

My con­clu­sions are:

1. Automa­tion of test­ing is equiv­a­lent to
   • in–process qual­ity con­trol (jidoka), with the test act­ing as a sort of fool proof­ing or poka yoke mechanism,
   • setup time reduc­tion because auto­mated tests reduce the high trans­ac­tion cost that is tra­di­tion­ally asso­ci­ated with small batches.
2. Mod­u­lar prod­ucts, stan­dard parts, high–level pro­gram­ming lan­guages and com­po­nent based soft­ware, allow devel­op­ment work to be par­ti­tioned into small batches with fast cycle times and improved quality.

The two approaches com­ple­ment each other. It’s easy to see that small batch devel­op­ment is a great thing. How­ever, the need for mod­u­lar­i­sa­tion and par­ti­tion­ing of the devel­op­ment work using well defined inter­faces can be prob­lem­atic. Mod­u­lar­i­sa­tion is almost always pos­si­ble with soft­ware, but it seems to me that prod­uct devel­op­ment and inno­va­tion in man­u­fac­tur­ing, process indus­tries, or edu­ca­tion, is much messier.

For exam­ple, how can the fun­da­men­tal mate­ri­als sci­ence research, lab­o­ra­tory tests, full scale pro­duc­tion tests, and the required process inno­va­tion that is involved in the devel­op­ment of a new steel grade be par­ti­tioned into small batches with clear inter­faces in a sim­i­lar way? I think I’ve got myself a good two–year research project there just to get started…

Be Socia­ble, Share!

•