Software Dev and the analogy of Manufacturing
I’m a fan (if that makes sense) of the Theory of Constraints and I believe that ToC can usefully be applied to software development — but so, so often we form the analogy wrong, apply ToC incorrectly and risk detrimental changes.
The wrong analogy is that developing software is like a manufacturing plant. The engineers move software through the plant, adding value, ensuring quality, ideally never passing work back down the line and consistently outputting quality software; look to maximise throughput whilst minimising inventory and running cost.
However, couldn’t the software itself also be thought of as a manufacturing plant? It has input, output, a chain of value adding functions arranged in varying orders; It scales according to demand and we do in fact already look to maximise its throughput whilst minimising inventory and running cost.
If the software is the plant then the development team are the plant managers. And in ToC plant managers run the 5 steps of the Process of Ongoing Improvement: identify, exploit, subordinate, elevate, repeat
This makes so much more sense! Consider:
- A great deal of effort is spent working out what to do next — this is because identifying a system’s constraint is hard. N.B pure software constraints are easy; IME 99% of the time the constraint we’re trying to identify is tied up with people; usually our customers/users
- Effective backlogs are short and dynamic — because predicting a system’s future constraints in priority order is nigh-on impossible to do accurately
- Maybe the drive to control WIP isn’t because we should minimise inventory; it’s because (a) ToC says a system has one bottleneck at a time (b) multitasking is cognitively hard and (c) multitasking delays finishing the first thing
- Each new piece of development is unique; because each improvement remains in the system — (as opposed to a production line pumping out thousands of identical items)
- … which is why collaborative team work is effective; because each piece of work is a new problem to solve
- … and why with attempts to break work out into functions/stages the flow is never one directional
It’s much more accurate to think of a product development team as plant managers than the shop floor.
