It's worth keeping in mind that lean manufacturing and all the interesting things that Toyota did that get written up are about building cars. In software the equivalent process is compiling and deploying code. Writing software is equivalent to designing, prototyping and testing a car. So while there are many interesting lessons to learn they are about the deployment and running of code, not about writing it. In the mass manufactured automobile industry you spend more time and effort building the product than designing it. In software you spend much more time designing (specs, coding, testing, all that stuff) the product than deploying it. The lessons of lean manufacturing may not apply to design.
Lean manufacturing and the Toyota Production System are absolutely about manufacturing. It's rooted in industrial engineering and operations research. It is about addressing root causes and truly solving issues. What we see in the lean books is a bunch of solutions to problems Toyota was facing at the time and how they solved them.
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.
In my experience, whenever a site installs lean processes, somebody gets the bright idea that if it works in manufacturing, then surely it can work in R&D. Every senior (hardware) engineer has a story of this happening at a past workplace.
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.
Yes! I still meet too many people who think what we are manufacturing software, while what we are doing is designing it. The manufacturing, that is, the building and deployment is already highly automated and very cheap.
A significant percentage of the time you’re researching software — determining if something is even possible.
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?”
This is why Agile/Standups make people go crazy! The daily standup makes sense when all the topics discussed will close out within hours, blockers sometimes stand literally upstream on the assembly line, and no one can really talk to each other outside of the standup because they’re too busy running manufacturing work centers that need 100% of their constant attention.
Imagine if compiling/deploying involved teams on the daily hand writing assembly/machine code from code base?
The lessons of lean manufacturing may not apply to design processes themselves, but a lean transformation in manufacturing often relies a lot on certain design choices (poka-yoke in assembling, standardization to cut setup times, etc). Design is often one of the most important factors in successful lean companies. I totally get the point, though.
