Using Kata to help teams deliver value faster

8 min readFeb 24, 2018

Kaizen, Kanban, Kaikaku. We can’t get enough of these Japanese words in agile! Here’s a lesser known one: Kata. Kata is a term used by Mike Rother to describe a set of routines that Toyota use to ingrain a culture of continuous improvement in their organisation. Each routine is practiced and repeated so that it becomes second nature.

During his time with Toyota he identified two Katas:

The improvement Kata is a four- step pattern which enables teams to pursue challenging goals with autonomy
The coaching Kata is a method of training people in how to use the improvement kata.

Together they were designed to make Toyota’s teams better at working independently to solve complex problems.

In this blog post, I explore how digital teams can take inspiration from Kata to deliver value to users more quickly.

Improvement Kata

Step 1 of 4 — Understand the Challenge

Step 1 of the Improvement Kata is to understand the challenge. The challenge for each team is decided by leadership. It describes the problem(s) the team should focus on solving or the goal they should be aiming for, and gives them a shared purpose. It is a new condition several months in the future that will take the organisation closer to achieving the vision.

Before starting work, teams should collectively review their challenge and clarify any ambiguities. If necessary they should challenge the challenge — leaders should be open to discussing changes in strategic direction where the team can demonstrate there are clear benefits in doing so. There must be a shared understanding between leadership and the team regarding how success will be measured and what the definition of done is.

Step 2 of 4 — Grasp the current condition

Before teams can start figuring out how to progress, they need to figure out where they are now — their current condition. This is something that should be done in a short kick-off stage.

Do it as a team. This first couple of days give everyone the context they need to make a positive contribution.

Team charter. As well as understanding the problem area, teams also need to understand each other. Who are they? What are their capabilities? How do they like to work? A team charter session is a great way to start answering these questions.

Look sideways (and backwards). Most organisations I’ve worked in already know a lot about their users and have ton of historical research. When designing or redesigning services from scratch, the UK Government Service Standard mandates a 4–8 week discovery stage. A long discovery stage often isn’t necessary for improvements to existing products. Instead, a much shorter period of discovering (or grasping the current condition) usually suffices. Teams should:

Research historical work done by others
Use organisation and industry communication channels to identify others who might have knowledge to share (or be working on a similar problem)
Research what has been done in other industries

Mapping. Usually it helps to visualise the status quo so everyone can see how things currently work. Processes, systems and user journeys are all good examples of things a team might want to map.

Research questions sessions are a great way to build a shared understanding about what you know and don’t know about the challenge. This involves identifying what you don’t know, don’t need to know, think you know and know. This part makes the next stage easy — usually some of the first target conditions in a project will be to address some of the uncertainties identified here.

Step 3 of 4 — Establish the next target condition

A key feature of the challenge is that it is only achievable with multiple increments or target conditions. A target condition is an interim goal on the way to the challenge. Unlike the challenge it is set by the team, and describes a future set of circumstances that lie beyond their current knowledge threshold.

Each target condition should take a few weeks or more to be achieved. There should be more than one target condition on the road to completing any challenge. The only target condition a team needs is the next one. It’s not necessary to have a three-month plan at the end of week one. Instead, teams should focus on minimising their work in progress and focusing on the problem at hand. One step at a time.

Most teams work in iterations or sprints, so the target condition is often the goal for the iteration.

Some example target conditions for a product improvement might include:

Know who your users are, their needs and how well they’re currently being met
Identify a prototype solution that you are confident best solves the problem
Develop an A/B test on the live product to validate the solution with quantitative data from a subset of users
Develop the solution into scalable production ready code

Target conditions can also be outcome focused. For example, increasing daily active users by 10%.

Steps 1 to 3 should be finished within week one

By the end of week one, teams should have understood the challenge, grasped the current condition and established their first target condition. From week two onwards they should start iterating towards their first target condition. The sooner they start validating their learning, the better.

Step 4 of 4 — Iterate towards the target condition

How does a team get from where they are now to achieving a target condition? They science the shit out of it.

Scientific method involves three steps:

1. Make a hypothesis. This should be the team’s best guess at what change they believe is most likely to allow them to achieve the target condition.

2. Devise a test to rapidly disprove the hypothesis and make a prediction about the result.

3. Run the test and analyse the result.

If the Result ≠ Prediction then revise the hypothesis or make new one
If the Result = Prediction then make additional predictions and test them until you are confident enough in the validity of your hypothesis to proceed to the next obstacle

Repeat this cycle as many times as you need to until the target condition is met. Fail fast and use scientific method to learn from your mistakes, and you will improve more rapidly. In the words of Ed Catmull at Pixar, “People need to be wrong as fast as they can”.

Some tips on how to do this well:

Don’t take too long to make a hypothesis. Just pick your best guess and get on and do the test already. If you can’t decide, take a vote on it.

Always make a prediction. Without a prediction, you risk succumbing to confirmation bias — the human tendency to find the answer we’re looking for regardless of what the data says.

Incorrect predictions can be a good thing. An incorrect prediction means you have learnt something from the experiment. If more than 50% of your hypothesis are correct then you’re probably wasting time testing things you already know the answer to.

Try to disprove your hypothesis. If you set out to disprove your hypothesis then they will fail faster. If they don’t fail, you can have greater confidence in their accuracy. Test the highest-priority and riskiest obstacles first.

Run tests quickly and cheaply. When you are first starting out with a hypothesis, run tests quickly and cheaply. Before designing a high-fidelity prototype and paying for time in a user research lab, do some low-fi sketches and gorilla test it with colleagues or family. Before building production-ready code, hard code an A/B test to experiment with a subset of users. Gradually invest more time in experiments as you become more confident in your hypothesis.

Confidence over certainty. The only things that are certain in life are death and taxes. Hypotheses are never proven true — they are just not proven wrong yet. We may observe 100 white swans in a row and conclude that all swans are white, and then a black swan would come along. Pareto efficiency applies to hypothesis validation — 20% of effort will yield 80% of the value. Don’t wait until you think you are certain an improvement will be a success before deploying it to real users. Instead, once you’ve put in that optimum 20% of effort to have 80% confidence that your hypothesis is correct, validate it with an A/B test on a subset of real users. Too often, product teams aim for certainty. It is rarely worth the cost. Get better at taking calculated risks

Test one hypothesis at a time. If you change lots of variables at once and then performance plummets, you won’t know which was the cause..

Keep a log of the tests you’ve run and the results. These are useful to refer back to later, and to use a basis for conversations with leadership.

What to do when you meet the target condition

Retrospect. This is a great opportunity for the team to reflect on how they have been working. Lessons should be learned, used to improve the team’s future performance and shared with others, solving similar problems in the future.

Revisit the challenge. Ensure there is a shared understanding of what the purpose of the team is. Ensure the next target condition aligns to it. Don’t get lost in a sea of unrelated improvements.

Set the next target condition. The next step toward achieving the challenge.

Coaching Kata

At Toyota, managers at all levels in the organisation coach individuals and teams to follow the Improvement Kata. They coach their reports by regularly asking five simple questions:

What is the target condition?
What is the actual condition now?*
What obstacles do you think are preventing you from reaching the target condition, and which one are you addressing now?
What is your next experiment? What result do you expect?
When can we go and see what we have learned from that experiment?

After each experiment, there’s another four questions to ask:

What was your Last Step?
What did you Expect?
What Actually Happened?
What did you Learn?

Through regularly asking these questions of teams and of each other, the improvement kata has become second habit to Toyota teams. Coaches also help the team to understand the challenge/current condition, set good target conditions and develop and test hypothesis quickly and cheaply.

I’ve found that using these questions in 1-to-1s and planning sessions is an excellent way to focus conversation on the obstacles the team needs to overcome in order to improve.

Some tips on how to coach teams to achieve a culture of self improvement:

Get good at asking questions. Don’t tell the team what to do. Ask open and challenging questions which encourage the team to think and help them to figure out the answer for themselves.

Don’t be afraid to ask a stupid question. If something doesn’t make sense to you but everyone else seems to be going along with it, put your hand up and ask. Be the one to ask the stupid question. And encourage others to do the same.

Be wrong as fast as you can. So you can learn quicker.

Encourage the team to take calculated risks. We will never progress if we don’t take risks. Encourage the team to test out risky ideas by setting up experiments to minimise the cost of failure.

Stop doing things that aren’t adding value. If you think the team is doing something that is wasting time or energy, ask them why they’re doing it. If they don’t have a good reason, ask them why they haven’t stopped doing it yet. Nothing is off limits, and feel free to be agile with agile — I’ve been on teams before where we’ve stopped doing regular standups.

Create a sense of urgency. Focus the team on meeting the next target condition and create a sense of urgency around it. If the iteration is two weeks long but you meet the target after a few days, call a new planning meeting and agree a new target condition.