10 Kaizen: Continuous improvement

The chapter presents Kaizen as a disciplined practice of continuous, incremental improvement focused on the system around the code, not just the code itself. It contrasts teams that merely tolerate friction with teams that steadily reduce it by observing work where it happens, measuring the problem, making a small change, and checking the result. The key idea is that improvement must be structured and repeated; when it is treated as a habit rather than a one-off cleanup, small gains begin to compound into major changes in flow, quality, and speed.

It also distinguishes Kaizen from refactoring and from ordinary retrospective talk. Refactoring improves the internal structure of software, while Kaizen improves the workflow, tooling, standards, and handoffs that determine how value moves through the organization. The chapter argues that many retrospectives fail because they focus on ceremonies and feelings instead of the value stream, produce too many vague action items, and rarely measure outcomes. A better approach is to use a single Kaizen card per sprint, tie it to a clear baseline, implement it during normal work, and record the result in a log so that improvements become visible, accountable, and reusable.

Finally, the chapter emphasizes that Kaizen can be practiced by individuals as well as teams. Developers are encouraged to notice recurring friction, automate repetitive tasks, improve personal workflows, and share the results so others can benefit. Simple habits such as keeping a friction log, setting aside a small recurring improvement block, and anchoring Kaizen to existing routines make the practice sustainable. The overall message is that continuous improvement is not a slogan or a personality trait; it is a repeatable method that, when applied consistently, reduces waste, builds momentum, and helps teams deliver value faster and with less frustration.

The compounding value of sprint-on-sprint kaizen improvements.

Cadence versus the good intentions approach to Kaizen.

Improvement trajectory with and without a kaizen cadence.

Retrospective-driven kaizen flow, one friction point per sprint, measured and resolved.

An A3 improvement proposal to capture the justification for pursuing an action. It fits on a single page, readable in <2 minutes with full context.

The improvement permission spectrum, showing that most Kaizen doesn't need anyone's approval.

• Kaizen involves small, continuous, and measured process improvements implemented by the people who perform the actual work.
• The Kaizen cycle consists of observing the process, measuring the performance, implementing a change, measuring again, and deciding whether to standardize the result or revert the change.
• Refactoring focuses on improving code structure, while Kaizen aims to improve the system that produces the code.
• Sprint retrospectives should include one Kaizen card per sprint, detailing the baseline, the proposed change, the owner, and the target outcome.
• A3 reports serve as structured proposals that effectively replace meetings by documenting the full case for an improvement.
• Most high-impact improvements do not require formal approval; they only need clear communication with the team.
• Friction logs are used to record daily stalls, allow for a weekly review of these issues, and enable teams to fix the top-priority friction point.

FAQ