The title likely leads you to believe I'm going to discuss large enterprises, large processes and heavy bureaucracies that either don't deliver at all or they deliver poorly from every perspective except the Project Manager's metric sheet. You're right. However, the conversation is perhaps from a perspective unanticipated. What I'm discussing below is the fragile, clunky, fractured world-view evolution of historical assembly line companies into the realm of software. Any person who believes because they understand assembly line flow, they therefore understand software is a fool. Do I have your attention?
While in Israel for some classwork in 2011 I had the privilege of talking with Eli Goldratt one month before he passed away. During that meeting he candidly told me that Theory Of Constraints (TOC) was never intended to be just for manufacturing, though because of his book "The Goal", it was characterized as manufacturing from the published birth of the material. In fact, he originally envisioned it to apply to anything that requires delivery flow. Business, software, hardware and manufacturing are only conversation points. They are all the same in terms of:
- they are intended to deliver something according to specification;
- delivering according to specification then allegedly elucidates planned revenue; and
- delivering with managed flow decreases waste thereby increasing profitability.
We can thank Henry Ford for his ground-breaking work in linear assembly line construction and flow. We can further thank Taiichi Ohno for taking the Henry Ford assembly line model and evolving it into a non-linear pull-by system now known as Kanban. And Eli Goldratt then took both Henry Ford and Taiichi Ohno's materials and evolved them yet further in terms of how to increase system-level flow by eliminating both system and component-level waste. Managing flow looks something like this:
THEN planned revenue;
ELSE revenue loss through operational waste.
I discussed this in another blog post titled, Managing Flow and later in a book titled Fundamentals of Software Company Operations in more detail. Some manufacturing theory can and does apply to software. However, it isn't understood well enough to do it correctly or successfully as it forces manufacturers to adapt to a new form of systems thinking.
Assembly line companies like Ford and Toyota have excellent histories of hard-product assembly line evolution. Entire enterprise cultures and academic bodies of knowledge have borne up around their successes. Now these companies, including others like Caterpillar, Vermeer, John Deere and more, have a new challenge. Higher and higher percentages of these historically big iron and aluminum (aluminium for some of my non-American English speaking friends) assembly line companies are now composed of software. Much of it embedded for fixed sensors. However, more and more of it represents a very-large ubiquitous software ecosystem. The internet and everything that goes along with it.
At some point very near today, the cost of building, delivering and supporting software will represent more of the delivery and operational cost of a car, truck, tractor, grader or directional drill than the hardware and hardware assembly line combined. And software moves at a far quicker change velocity than anything the big iron hardware world has ever had to solve. However, because of the historical success of the manufacturing industry such as at Ford and Toyota, leadership in these companies will believe they are giants. And software to them will (does) look no more complicated than another physical feature they can simply design in CAD, manufacture to specification and deliver without environmental variability.
These companies, who have typically and historically led and evolved the manufacturing world with total-earth domination, will fail because they choose to short-sightedly treat software as a factory behaviour.
Q: How do you take the success of assembly line production and translate it into software production?
In the follow-on post, we'll explore the idea of why decoupling software evolutionary behaviors from historical hard-line assembly line behaviours is necessary and what steps are necessary to get there.