3 ms·

Do you recommended any resources about this? I'd like to try to bring this over to my org.

akeck 10y ago
Hmmm... There are many facets, but they roughly come down to a bottom up organizational culture of using the scientific method for everything. Every assumption in developing a process, code, or product should be rapidly validated with quick prototypes and other experiments. When determining the cause of issues, target process and design flaws with formal root cause analysis tools, rather than targeting people. Everyone does this everyday with all that they do, although large-scale improvements sometimes work better in organized events with all the stakeholders ("Kaizen Events"). My favorite book for getting started is "The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition" by Steven Spear. Then read skill-specific books like, "Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System", by Sobek II and Smalley, "Root Cause Analysis: Simplified Tools and Techniques, Second Edition" by Fagerhaug and Anderson, and the classic, "Toyota Production System: Beyond Large-Scale Production" by Ohno and Bodek, which goes into the particular systems Toyota uses. Many people simply apply Toyota's car-factory-specific tools from Ohno's book in all sorts of situations, but LEAN/TPS is about developing tools and approaches on the fly, based on the scientific method and actual data from rapid experiments. Maybe that rapid experimentation shows that the car factory tools will work, maybe you end up with entirely new tools, specific to your particular situation. The "classic" tools in Ohno's book are specific, rapid-prototyped responses to particular issues faced by Toyota and their suppliers. Applying the LEAN/TPS philosophy to your company's specific coding and design practices may result in entirely new tools and techniques. The "classic" tools have become popular for re-use because the classes problems they solve appear in many other industries and situations. LEAN/TPS says that one would use the classic tools, if your own rapid experimentation showed that they will address the process and design defects you are encountering. That is, don't do kan-ban just for the sake of doing kan-ban; base your improvement decisions only on actual data from experiments.

akeck 10y ago

Hmmm... There are many facets, but they roughly come down to a bottom up organizational culture of using the scientific method for everything. Every assumption in developing a process, code, or product should be rapidly validated with quick prototypes and other experiments. When determining the cause of issues, target process and design flaws with formal root cause analysis tools, rather than targeting people. Everyone does this everyday with all that they do, although large-scale improvements sometimes work better in organized events with all the stakeholders ("Kaizen Events"). My favorite book for getting started is "The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition" by Steven Spear. Then read skill-specific books like, "Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System", by Sobek II and Smalley, "Root Cause Analysis: Simplified Tools and Techniques, Second Edition" by Fagerhaug and Anderson, and the classic, "Toyota Production System: Beyond Large-Scale Production" by Ohno and Bodek, which goes into the particular systems Toyota uses. Many people simply apply Toyota's car-factory-specific tools from Ohno's book in all sorts of situations, but LEAN/TPS is about developing tools and approaches on the fly, based on the scientific method and actual data from rapid experiments. Maybe that rapid experimentation shows that the car factory tools will work, maybe you end up with entirely new tools, specific to your particular situation. The "classic" tools in Ohno's book are specific, rapid-prototyped responses to particular issues faced by Toyota and their suppliers. Applying the LEAN/TPS philosophy to your company's specific coding and design practices may result in entirely new tools and techniques. The "classic" tools have become popular for re-use because the classes problems they solve appear in many other industries and situations. LEAN/TPS says that one would use the classic tools, if your own rapid experimentation showed that they will address the process and design defects you are encountering. That is, don't do kan-ban just for the sake of doing kan-ban; base your improvement decisions only on actual data from experiments.