Kaizen loops for software teams

Small improvements compound

Kaizen has been flattened by management literature into a slogan, which is a shame, because the underlying mechanism is one of the few process ideas I have seen work reliably in engineering teams. The mechanism is compounding: a one-percent improvement in how a team ships, made weekly and kept, outgrows any single heroic re-organization within a year.

The condition is that improvements stay concrete. Improve one review habit. Remove one recurring manual step. Clarify one ownership boundary. Abstract goals — "improve quality", "communicate better" — do not compound because they cannot be executed, verified, or kept.

Those numbers are deliberately austere. A team that changes five process things at once cannot attribute any effect to any change, which means it learns nothing — and learning, not the change itself, is the actual product of the loop.

Do not optimize noise

Improvement needs direction, and the direction comes from friction that repeats. A one-off annoyance is weather; recurring friction is climate. The common mistake is optimizing whatever irritated someone most recently — usually a loud one-off — while the quiet, structural drags on the team stay untouched for years.

Before changing anything, I ask the team to name the friction precisely and count its recurrence. "Reviews are slow" is noise. "PRs wait a median of two days for first review, and the wait doubled since the team split" is a target. If you cannot state the friction as something observable, you are not ready to improve it — you are ready to investigate it, which is a fine first loop on its own.

The loop itself

The loop I run with teams has four steps, and its power is in what it refuses to include:

1. Name the friction. One sentence, observable, with evidence of recurrence. Written where the team plans work — not in a separate improvement tracker that becomes a graveyard.
2. Choose one small change. Small means reversible within a day and requiring no permission from outside the team. If the change needs a committee, decompose it until it does not.
3. Run it for two iterations. One iteration measures novelty; two begin to measure the change. Resist evaluating early — most process changes feel worse before they feel better.
4. Keep or kill by the signal. The signal was chosen in step one, before anyone was invested. If it did not move, the change dies without debate, and that is a success of the loop, not a failure of the idea.

friction: hotfixes bypass review "temporarily", then cause repeat incidents
change:   hotfix template requires a linked follow-up ticket + 24h retro-review
signal:   count of hotfix-caused repeat incidents per month
verdict:  after 2 sprints — repeats dropped, keep; review load unchanged

Where friction hides

After enough of these loops across teams, the same hiding places show up again and again. When a team says everything is fine but delivery feels heavy, I look here first:

• Feedback latency. How long from pushing code to knowing it works — locally, in CI, in review, in staging. Every stage of waiting is a place where focus dies and context-switching begins.
• Environment fragility. The "works on my machine" tax: manual setup steps, drifting configs, the one person who knows how to fix the dev database.
• Flaky tests. Each flake teaches engineers to re-run instead of read, which quietly disables the entire safety system the tests were meant to be.
• Handoffs and permissions. Work that waits on another team, a ticket queue, or an approval — often invisible in metrics because nobody measures waiting, only doing.
• Hidden assumptions. Incidents whose post-mortems begin "we assumed…" are pointing at improvement targets with unusual precision.

Make change observable

A team should be able to tell whether a process change helped, and that requires choosing the signal before the change — afterwards, confirmation bias will happily find a metric that improved. The signals I reach for most often: lead time for changes, review cycle time, deployment frequency and confidence, escaped defects, and time to recover from incidents.

Two honesty rules make these signals trustworthy. First, measure medians and distributions, not averages — one stuck PR should not hide behind ten fast ones. Second, accept "no effect" as a real and reportable outcome. A team that only ever reports successful improvements is not improving; it is marketing.

A retrospective that produces changes

The retrospective is where most teams believe their kaizen happens, and where most of it actually dies. The standard failure: ninety minutes of honest discussion producing a list of action items that nobody looks at until the next retro produces the same list.

What I change about the format is small and structural. The retro's output is exactly one loop — one friction, one change, one signal — and it enters the next iteration's plan as a regular work item, prioritized against features. Improvements that live outside the planning system do not exist; putting them inside it is the whole trick. The previous loop's verdict opens the retro, which makes the practice self-demonstrating: the team watches its own changes get kept or killed by evidence.

When kaizen goes wrong

• Kaizen theater. Improvement boards, transformation workshops, and maturity assessments that consume the energy real loops would have used. If the artifact count grows faster than the change count, stop.
• Blame wearing process clothes. "Continuous improvement" aimed at individuals — review discipline for one person, estimation accuracy for another — is performance management in disguise and poisons the safety the loop needs. Kaizen targets the system, never the person.
• The big-bang exception. "This problem is too large for small changes" is occasionally true and usually an excuse. Most large problems decompose into loop-sized pieces; the refusal to decompose is often the actual problem.
• Improvement debt. A backlog of forty acknowledged frictions is not a plan; it is a mood. Keep the list short and current — three named frictions maximum — and let the rest go until a slot opens.

Summary

• Compounding requires concreteness: one change, reversible, inside the team's own authority.
• Target friction that repeats, stated as something observable — investigate first if you cannot.
• Run every change for two iterations; let a pre-chosen signal decide, not the advocate.
• Look for friction in feedback latency, environments, flaky tests, handoffs, and post-incident assumptions.
• Route improvements through the normal planning system, one per iteration, opened by the previous verdict.
• Watch for theater, disguised blame, and the big-bang excuse — they are how the loop quietly dies.