Comment by bit1 | Hacker News Reader

Comment by bit1 | Hacker News Reader

Definitely "The Machine That Changed the World" by Womack, Jones, and Roos [0]. This is "the first book to reveal Toyota's lean production system." Before reading it, I had never imagined just-in-time production or value chain mapping, or vehicle assembly lines that can profitably produce quantity one of a product before being reconfigured to produce a different model (SMED: single minute exchange of die).

Now I see muda everywhere and cringe when I overhear people talking about applying kaizen and how they think they're practicing "continuous improvement" while repeating the same rote, industrial, mindless processes that they have been for the last 40 years. We can do so much better. Toyota tried very hard to teach GM how at their NUMMI[1] plant, but it wasn't the right location relative to their suppliers for JIT to fully work and "It is difficult to get a man to understand something, when his salary depends on his not understanding it." -Upton Sinclair

[0] https://www.lean.org/Bookstore/ProductDetails.cfm?SelectedPr... [1] https://en.wikipedia.org/wiki/NUMMI

In software people use agile as an excuse to not think through the core architecture.

I believe agile was invented to incrementally improve an already well thought production process. Once the assembly line was setup, agile was used to eliminate the unproductive activities. I am not sure agile will be helpful to build the assembly line itself?

In most scenarios that's what people try to do with agile.

You're describing Lean. Similar and related, but not the same.

I don't think that is a good comparison.

Setting up a mechanical assembly line is very different from setting up a software pipeline, although, as you can tell already, they use some of the same words and metaphors.

It isn't possible to build a mechanical factory in weeks with readily available tools [0]. We just don't have that kind of concentration of knowledge, we don't have the skills, the know-how etc. to accomplish that. Whereas with software: you have OSS, you have the Cloud, and all kinds of numerous tooling that helps you get started immediately, and iterate on that until you get to the final product. That kind of iteration, debugging etc. is just not possible with manufacturing. Which is why in manufacturing you need great designs and processes: bad decisions are very costly. They are costly in software too, but... your MVP will still churn out value, even if its not efficient. Once you prove that your product satisfies a need, you then make it better, you make it more efficient, scale it out, yadda yadda. But getting started is absurdly easy. And thats why lean works.

The designers of lean realized that all that worry about scaling, about automation, planning, QA... while its important, it doesn't provide the most value for everyone. For a smaller company, its more important to get out a product that solves a problem even if its janky. Once you prove its usefulness, you attract more money, more people etc.

So lean solves two problems: * gets you started quickly and fails bad ideas fast * lets you justify bad design if it provides more value

One could argue that the technical debt built up by this kind of process has to be paid down someday. If your product survives for long enough, you will have enough resources to do that. And then you have a core product that brings in revenue, and you repeat the same lean method for other products. Rinse and repeat, ad infinitum.

[0]: where this assumption fails, you see a lot more manufacturing. e.g. in China, the fruits of this kind of aggregation in manufacturing skill is visible, and that's why Chinese manufacturers are so adept at responding to changing market conditions.

I agree with your points above.Having said that knowledge and experience is a critical factor and I am fine with using agile for MVPs and startup scenarios.

My issue is with the way agile is evangelized and implemented in the Enterprise. These Enterprise people simply rationalize that if Toyota can do it then why we can't without realizing where it fit and where it does not.

Personally I think it does not fit with the culture of thousand approvals and beating the dead horse i.e. endlessly cross examining any design or implementation failures.

This happens because Enterprise people love the buzzwords. Agile and cloud are the latest buzz in Enterprise so they watch a ppt or two somewhere starts pushing agile into a culture where it does not fit at all. This results in sufferings and frustration.

This American Life did a fantastic episode[1] on the NUMMI plant, highly recommend it.

[1] https://www.thisamericanlife.org/403/nummi

Added to my queue, thanks!

Kaizen seems to be manufacturing's equivalent of agile. Everyone says they do it, but almost no one actually does it because that would mean totally re-configuring their business.

A good approach to this is to start small. Apply kaizen on small things, get the "kaizen culture" ingrained in your team/company culture, and slowly move on to bigger things.

Not gonna lie, it's very hard

I hadn't recognized the equivalency of [lean] and agile before. That's interesting and helps give me a better appreciation for why we only end up paying lip service to the idea. Thanks for the thought.

For me it was a sequence of books that did it. The Phoenix Project first, then David Anderson's Kanban book. Some tine after that was The Goal and Deming's Out Of The Crisis, and a book of Taichi Ohno musings.

You're right, what has been seen cannot be unseen.

I just finished The Toyota Way and am getting started on The Goal. I'm very curious about the Taichi Ohno book. Do you have a link or a title?

Taiichi Ohnos Workplace Management https://www.amazon.co.uk/dp/0071808019/ref=cm_sw_r_cp_apa_i_...

It's interesting for a number of reasons, not least because it explains that a lot of the ideas driving how Toyota worked post-war came from the fact that they knew they wouldn't be able to let people go in an economic downturn.

Why did GM's people's salaries depend on not understanding NUMMI/TPS? I would have thought it would have been clear to them they either adapt or die, and thus their salary depended on understanding it.

Simply accepting you're in the wrong location means moving, and you can't move a factory and all it's workers cheaply. Similarly, no one wants to automate their own job away, as that would result in them not having a job.

Granted, long-term that thinking kills companies, but short term it keeps the bills paid, the kids fed, and the beer cold.

From what I was able to gather it was less about being in the wrong location and that the internal politics of GM set NUMMI up for failure.

America was able to be a powerhouse of manufacturing during WW2, I remember reading that a lot of the DNA for JIT/Kaizen/Lean came from the Marshall Plan[1].

[1] https://en.wikipedia.org/wiki/Kaizen#History

The Chicken Tax. Because of it, US auto manufactures promoted and sold the one market segment where they had 0 to no competition. Even today, the big American automakers suck balls at making Sedans and focus exclusively on Trucks and SUVs.

I had a similar experience with The Toyota Way, which was also about Toyota's manufacturing process.

Toyota Way is a great book.

The tools don't really mean anything, it's mostly adopting the principles enforced. And everyone has to adopt it for it to work. The ones that do it best, have a strong company culture. You define the why before the how and what.

Reply on news.ycombinator.com