3 ms·

One of the things I wonder, as we stare at pulling a release at my work, is can elements of the Toyota Way be brought over to software? We practice SCRUM, whic

One of the things I wonder, as we stare at pulling a release at my work, is can elements of the Toyota Way be brought over to software? We practice SCRUM, which supposedly learned from the Toyota Product System, but our quality assurance has a long way to go.

akeck 10y ago
Yes! We use Toyota/LEAN tools constantly to improve our code (and everything else).
- pwthornton 10y ago
  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

Yes! We use Toyota/LEAN tools constantly to improve our code (and everything else).

pwthornton 10y ago
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.