Dantotsu Radical Software Quality Improvement
summary
Claims that Toyota’s dantotsu method cuts defects by another ~90% and is transferable to software. Teams standardize “defect = unexpected user behavior,” build a visual defect tracker, adopt an A‑D outflow classification, require tech‑lead daily bug analyses, and use linters, added tests, targeted rewrites, and a Notion template plus a Slack bot for a right-first-time gamified metric (one refresh). A small project (5–8k LOC, 118 engineer days) records two production defects — about 0.3 defects/KLOC — one to two orders of magnitude better than industry averages.
AI-written summary · about
chapters (10)
- 0:00Intro
- 0:33Topic
- 1:08Quality at Scale Dilemma
- 6:44Dantotsu Approach
- 11:07Dantotsu Key Points
- 18:45Defect Classification
- 24:21What are defects
- 24:51One refresh only
- 26:09Learnings
- 29:53Questions
related talks
01h 21mTradeoffs in the Software Workflow
01h 04mDevOps Kaizen: Empowering Teams to find and fix their own Problems
01h 19mPNSQC 2013 - Capers Jones
27mTrue North and Technical Debt
58mDeveloper Joy – How great teams get s%*t done
43mDeliver Fast with Confidence
19mAccelerating Code Quality with DORA Metrics
39mDev Team Metrics that Matter