Improvement Kata: Making Better a Habit

Making improvement a practice

A retrospective can leave us with useful observations and good intentions. The harder part is what happens afterwards: someone needs to try a change, notice what it does, and bring that learning back. That gap is what interests me about Improvement Kata.

A kata is a pattern you practice until it becomes familiar. Mike Rother drew on his research into Toyota's management practices to describe a pattern of scientific thinking, then developed starter routines to help people learn it. These routines are a way to build the habit of testing assumptions; they aren't a script Toyota used everywhere or something you must follow unchanged forever. ¹

I've written about . Here I want to make the practice concrete: what would you actually do differently tomorrow?

The four steps

1. Understand the direction. What larger challenge makes this work worth improving? It might be helping customers receive small changes more predictably. The direction helps you choose which problems deserve attention.
2. Grasp the current condition. Observe how the work happens now. Separate measurements from assumptions, and agree where the process starts and ends. “Reviews are slow” is a concern; knowing where requests wait gives you something to investigate.
3. Describe the next target condition. Set a date and describe how you want the process to operate by then, with relevant measures. “Install a review bot” names a solution. “Routine requests receive a first review within one working day” describes a condition you could reach in several ways.
4. Experiment toward it. Choose an obstacle, write what you expect a small test to show, run it, and compare the observation with the prediction. Use what you learn to choose the next step. ²³

The distinction in step three matters. A target condition gives the work a direction without pretending we already know the intervention that will get us there. It describes both the operation we want and evidence that would tell us we're approaching it.

Follow one problem through the loop

Imagine a team whose routine pull requests spend too long waiting for review. In this fictional example, only four of the last ten received a first review within one working day. The team wants small changes to reach users predictably while keeping its existing review checks.

Its next target condition is: by the end of the fortnight, at least eight of ten routine requests receive a first review within one working day in each of two consecutive working weeks. Here, “routine” means a small, non-emergency change requiring one reviewer. Time starts when it is marked ready for review; a working day is eight working hours, and “first review” means substantive feedback. The automated checks and review checklist still apply before merge.

The team chooses one experiment: protect a daily review window for the next five routine requests. That window is an intervention to test. It is not the target condition. The sample is deliberately small enough to inspect closely.

Try it below: record a prediction, reveal the observations, and choose the next experiment. Notice whether the evidence answers the question you started with or exposes a different obstacle.

Three of the five requests receive substantive first feedback within one working day. An incident repeatedly pulls the reviewer away. That gives the team a more specific problem to address: coverage during interruptions. A backup reviewer is one possible next test. More reminders might help someone who forgot, but they don't necessarily help someone who is already occupied.

Even a better second result would leave work to do. Five requests are not two consecutive weeks of evidence, and a faster first response doesn't prove that the whole delivery process improved. I would also look at review quality, rework, and whether the queue simply moved to testing or release.

The coach's part

The Coaching Kata helps the learner examine their thinking. Its starter questions ask about the target condition, the actual condition, the obstacle being addressed, the next step and its expected result, and when the coach and learner can inspect what happened. ³

There is a crucial pause after establishing the actual condition: what did we predict last time, what happened, and what did we learn? Without that reflection, it is easy to turn the conversation into another update about activity.

I like the constraint this puts on me as a manager. I need to understand the learner's reasoning before jumping in with a solution. It also changes what counts as progress. Discovering that an assumption was wrong can be useful, provided we can explain what the observation changes about our next step.

A question card doesn't make someone a coach. The coach needs practice with improvement work too: enough to notice an untested assumption, a vague prediction, or a leap from one result to a confident explanation. Short, frequent conversations help keep that reasoning close to the work. ⁴

Where it fits with Scrum and Kanban

A retrospective can help identify an improvement challenge, but we don't have to wait for the next retrospective to learn. A sprint can contain several small experiments. A Kanban team can run the same loop as useful observations arrive. The experiment's cadence should follow the question and the available feedback. ⁴

The can help establish the current condition. They also need interpretation. A cycle-time chart shows what happened to completed work; it doesn't, by itself, tell us why reviews waited or what remains stuck. Talking to the people doing the work belongs alongside the chart.

I would keep an experiment record simple: the obstacle, the next step, the prediction, the observation, and what to try next. It should be easy to return to a week later and see why a decision was made.

Small experiments, whole-system consequences

Moving quickly means making the test smaller. Try the change on a limited set of work, keep the necessary checks, and inspect the result soon. Skipping those checks can make the result look encouraging while hiding the cost elsewhere.

Lean already includes people development and learning through experimentation. Kata is one way to practice that thinking. Treating Lean as process optimization and Kata as the people side misses how closely they belong together. ⁵¹

The same applies to improvement across a system. Faster coding can make an overloaded review queue worse. Faster review can expose a release bottleneck. We need to judge local changes against the flow of value through the whole process, rather than assume that better-looking pieces add up to a better system. ⁶

That is the habit I want to keep: make the intention clear, put an assumption where it can be tested, and let the observation influence what happens next. The routine is useful when it helps us learn, including when the result is inconvenient.

If you want to try it

• provides practice material and a place to start with the learner–coach conversation.
• goes deeper into the routines and the distinction between a target and a target condition.
• helps connect a local improvement to the wider flow of work.

This closes the Classical Agile series: introduces the frameworks, and explores the evidence. considers the related challenge of helping people develop while still making judgments about their work.