In the Flow

Neil Davidson has an interesting post questioning the logic of trimming the fat in economic downturns. His isn’t the first blog post I’ve seen recently on the applicability of Lean to software development. As someone with an Industrial / Manufacturing Engineering background who now does programming, I bristle when I see production line concepts applied to software development, so I thought I would chime in on the topic.

There has been a push in recent years (mostly by consultants) to extend concepts from Lean and Six Sigma to service-based industries, but for the most part it doesn’t make sense. Production is deterministic. Work orders are scheduled, raw materials are pulled from stock and production workers have a standardized set of instructions for manufacturing a sub-component or finished good.

The typical work flow for a knowledge worker is not deterministic. You can’t pull a programmer’s brain from stock, run it through a 1-ton arbor press, and squeeze out code to fill an empty software kanban. And even in manufacturing there is a difference between high-volume, low-mix assembly and low-volume, high-mix assembly. Many of the techniques used in Lean, such as value stream mapping, don’t apply well to low-volume, high-mix production, let alone to non-manufacturing.

Another problem is the misuse of ‘Lean’, ‘Six Sigma’, and the combined ‘Lean Six Sigma’.

Lean is an offshoot of the Toyota Production System, created by Taiichi Ohno. He boiled it down to shortening the time between getting an order and getting cash by eliminating the seven common causes of waste in the process. This has been misinterpreted as cutting staff, as in “running a lean operation”. They’re not the same thing. The next time you see a CEO announcing that they are going to cut jobs as part of their Lean Six Sigma adoption, you can be pretty sure they have no clue what they are talking about.

I’ve seen other piss poor analogies of Lean applied to software as well. To give one example, some claim that rarely used features or commented out code are wastes of over-production. In manufacturing, when a new product is introduced, first it gets designed by an engineer. If it is a high-volume, low-mix environment, there’s typically a pre-production run to iron out the kinks. If it is a low-volume, high-mix environment, it often gets prototyped by one or more technicians, assembly workers, and engineers. If you have waste in a process, the prototyping stage is where you want to discover it – before production is ramped up – so it can be identified and eliminated. The problem with the software / Lean-waste analogy is that most code development is more like the prototyping stage than the manufacturing stage. You don’t write code once, then create the exact same code over and over again.

Six Sigma is a collection of tools for problem solving and quality improvement. Central to it’s theme is DMAIC – define, measure, analyze, improve, and control, and it relies heavily on statistical analysis. While it has been applied successfully to service based organizations where the procedures are very standardized, such as healthcare, it’s bit of a stretch to apply it to software development.