[dnos]

I worked at a software company that went through a "lean transformation" where management effectively idolized Toyota's production philosophy and wanted it used in each and every department.

While it helped our customer service department quite a bit as-is. The Toyota Way is definitely not something you can directly copy/paste and use in software development. Building a Camry 5000 times is not the same as shipping 5000 different software projects, so a lot of the analogies and examples you find in text don't always apply. I always found it amusing that you never see or hear examples used from the R&D and engineering of the actual automobiles -- just once all that hard stuff has been figured out and the manufacturing starts, all the principles are magically, easily applied.

To be honest, a lot of it is just "common sense" or things that just naturally transpire if you have a good team (especially if Agile dev and ideas like continuous delivery are used anyway.)

With the negatives aside, the problem-solving culture part of it is something that can really change things for the better and is worth researching. If nothing else, I found just being able to have a framework for solving problems as they come up is huge -- surely regardless of what a company does. For instance, integrating a standard to collectively write out the "Five Why's" and clearly define the problem statement when a team is gathered to discuss solutions to a problem can save so much time. How many times have you been dragged into a meeting, go through a huge discussion, design a solution, only to realize later that it wasn't really solving what needed to be solved?

Outside the culture aspects, it mostly just felt forced, frustrating devs, and really made things feel almost like a cargo cult waiting for the goodies to drop from the sky.