Even the person who coined "lean manufacturing" says, "Don't try to bring lean manufacturing upstream to product development. The application of Lean in product development and manufacturing are different. Some aspects may look similar, but they are not! Be weary of an expert with experience in lean manufacturing that claims to know product development."[1]
There are a couple of books that have tried to capture the design process from Toyota. [1] is the Wikipedia page for [2]. [3] is an alternative take. Unfortunately I haven't read these books, so can't provide anything beyond the table of contents.
[1] https://en.wikipedia.org/wiki/Lean_product_development
[2] the table of contents needs to be downloaded from https://www.lean.org/store/book/lean-product-and-process-dev...
[2] https://www.routledge.com/The-Toyota-Product-Development-Sys...
The compromise is to tidy the workplace as well as possible, call it "5S", fill the dumpster with stuff that's really junk, and let each engineer stash their Undecidable Things under their desk.
As for software, maybe the best thing is to just not let hardware concepts such as "designing" and "manufacturing" creep in. Especially when those things imply a social hierarchy.
This is the even more crucial difference and the reason for all the time estimation arguments.
If a manager can’t estimate a car production run schedule they’re a bad manager.
No manager can schedule — to the day — when fusion powered cars will be ready for shipping.
Yet, this is expected from people trying something entirely new in software.
“Integrate these two things that no human has put together before. Now that you’ve heard this single sentence, tell me: will it be ready Tuesday or Wednesday… a year from now?”
Imagine if compiling/deploying involved teams on the daily hand writing assembly/machine code from code base?