10 Kaizen: Continuous improvement
This chapter covers
- Kaizen and refactoring differences
- Applying the measure-change-measure cycle
- Communicating improvements via A3 reports
- Practicing personal Kaizen and friction logs
Every developer carries a mental list of things that are broken: the slow build, fragile test, or deploy step that should have been automated two years ago. At most companies, that list only grows. Someone fixes an item occasionally, but two new ones appear. The list becomes background noise, something you complain about over coffee and live with. But at some teams, the list shrinks. Steadily, visibly, sprint over sprint. The difference is a single habit that one team adopted, and the other didn't: Kaizen. It was introduced alongside Gemba as the Lean practice of continuous, incremental improvement. Gemba is where you observe. Kaizen is what you do about it. But Kaizen is not a synonym for refactoring, and it is not a cleanup sprint scheduled once a quarter when the backlog is light. Kaizen improves the system that produces the code, workflows, feedback loops, standards, and tools, not just the code itself. A developer who fixes a flaky test is debugging. A developer who adds a CI rule preventing that class of flake from ever recurring is doing Kaizen. This distinction matters because most development teams already refactor. They clean up code, extract methods, and rename variables.