How to speak Improvement Kata

We have been practicing the Improvement Kata for quite some time now, but we still struggle with the meaning of the different terms, and how to apply them. After reading this article you should have a clear view of the parts of the Improvement Kata, what they mean, and how to apply them. 

Let’s get started!

Process vs. Result

Before we can dive into the details of the Improvement Kata language we should start by making a distinction between the process and the result. This is maybe the hardest part of the Improvement Kata. We’re used to thinking about goals and results and what we want to accomplish. We want to get to our production numbers. We’re focused on the result. With the Improvement Kata we focus on the process that leads to a result. We should put the process in the spotlight, and the result is the outcome of the process. I always try to explain it in this way:

• You can’t carry out a goal or a result.
• But you can carry out a process.

Why is this difficult?

This mindset shift is the most difficult part of the Improvement Kata. We have been taught from early on to think about outcomes and results. We have to set bold goals and reach for the stars. It’s not ingrained in our culture to think about the process. So we have to make this mindset shift to learn to make this distinction, and focus on the process.

Improvement of daily work is more important than daily work. But it doesn’t come instead of daily work.

Before we start, an overview

This is a schematic overview of the Improvement Kata process. I will discuss the different parts in this article, you can use this image as a reference.

The true north - our vision for the company

We want to be a calm company. And we believe that striving for these four things in our processes will achieve that:

• Single item flow, in sequence, and on-demand.
• Zero defects.
• 100% value-added.
• Security for people.

Let’s examine them further.

Single item flow, in sequence, and on-demand

This is one of the overarching principles of the Improvement Kata. Before we do anything else, we should move a process, any process, closer to being a single item flow, in sequence, and on-demand. But why?

We want a stable and predictable process. We want to have a scalable process, and a process without a lot of waste. To get there we need to see the bottlenecks in that process. Moving to a single item flow shows those bottlenecks as soon as possible. And more clearly. You have to solve them, or else nothing can flow through the process.

If we have a single item flow process, in sequence, we can’t cut corners and expedite things to get things done. We have to remove a bottleneck in the process before we can move on. As long as we’re not there we can cheat. If you can clearly see the bottleneck in a process, you can start solving it and improve the process which leads to better results.

Zero defects

Every time a process doesn't work as defined, we have a defect. So, a defect is focused on the process, not on the result. Every defect should be investigated to learn from it.

Lots of problems equals a happy boss.

100% value-added

Everything we do in a process should add value to the end result of the process. If we do things in our process that don't add value, we shouldn’t do it. This is also referred to as removing waste from a process.

A lot of ‘lean’ discussions focus on getting rid of waste. The assumption being that getting rid of waste is a goal of being lean, while getting rid of waste is actually a result of the Improvement Kata. It’s not a goal on its own.

Security for people

All the things we do must adhere to this principle. When we set a challenge, target condition, or process description, we always have to check if it is within this limit.

People make mistakes. The systems we have in place should help prevent that, or if they happen should reduce the fallout a mistake has. It should be safe to make mistakes. They shouldn’t result in any catastrophic events. And if a catastrophic event or less catastrophic event happens, we have to improve the systems.

Security for people also means that everybody can be themselves on the job. We should be able to speak out, give feedback, and share knowledge. That’s how we learn as people, and as an organization.

Current condition

If we talk about the current condition we talk about the process we want to improve. In a perfect world, this process should have a clear description. This description should tell you how we would like the process to work. The description should contain:

• All steps of the process.
• The time each step can take.
• How many people work on a step.
• Any quality metrics of this step.
• How much inventory is allowed per step.
• The total cycle time of the process.

It can also contain a description of the characteristics of this process. Any concerns regarding the safety for people should be mentioned, and last but not least, it should include an outcome metric.

For a new process, this description can be made along the way. While we work at improving the process we discover how the process should work. This can and should be written down so it can be used as documentation on the process. And, while we’re changing and improving the process this documentation should be updated. You will see that the longer you work on a process the more refined the process gets.

Why is this difficult?

To be able to move to single item flow and not end up with local optimizations we have to strive for one process. Look out for describing a process as a stand-alone process, which is actually part of a larger process, and thus is a subprocess on its own.

When we started out applying the Improvement Kata we had a develop process, a test process and a documentation, translations and communication process. I had a hard time convincing development that we had to include the test process as part of the total development pipeline. Because in improving the development cycle, but not being able to test and deploy stories, we had created waste.

We have to optimize the whole.

Example

Let’s use an example to illustrate this. Our process to deliver value to clients is made up of the following subprocesses to get a feature online:

• Decide what to build - 3 weeks
  • Gather information on feature requests (on demand).
  • Rank feature requests to get a priority (in sequence).
  • Describe this feature and plan it for development.
• Develop a story - 3 days
  • Discuss with the product owner.
  • Define acceptance criteria.
  • Design, build, code review.
  • Refactor the code.
  • Test with the team.
• Test and deploy a story - 3 hours
  • Build the story to staging.
  • Run acceptance tests.
  • Test a story.
  • Merge story.
  • Deploy to production.
• Translate - 1 day
  • Create single item package for this story for translators.
  • Send the package to the translators.
  • Translators translate the labels for this story.
• Document and communicate - 3 days
  • Write release notes.
  • Write, update, and publish help articles.
  • Communicate with relevant clients.

We have a lot of documentation for each step describing what quality to adhere to, how many stories can be in any given step, how many iterations are allowed, and how many defects are allowed in a story. That would be an article on its own.

The important takeaway from this is that to optimize the whole you have to have all the steps in one process and measure them. If you don’t do it like this an optimization in one step will bring waste in another step.

Outcome metric

The outcome metric describes what a process produces. This is the result of the process. We measure the outcome metric once in a while to check if the process is still on track to deliver the desired result to the company. This is what other companies use as goals or targets.

Why is this difficult?

What we find difficult is making a clear distinction between results (outcome metric) and process. And once you have defined an outcome metric, it all of a sudden seems to be a goal. Which we have to make, and are disappointed at not meeting. The sole purpose of the outcome metric is to be able to measure if you get closer to where you want to be.

Example

The outcome metric from our development process is that we want to release a $100 feature every three months per team. We think that bringing such a feature that delivers value to our clients every month will provide us with the growth the company needs to be a calm company.

Challenge

The challenge describes the future state of your process that you want to reach. The hard part about this is to keep in mind that we’re talking about the process, not the result. You should describe how you would like the process to work, and not a goal or result. A challenge can be set far away with a long timeline, anywhere between six weeks and a year. If you already know how to get there, it’s too close. The challenge gives direction, and will be broken down to smaller target conditions.

The best place to start defining the challenge is getting to single item flow. Then you should strive for in sequence and the last part should be about demand. Getting to the single item flow and in sequence took us two years.

Why is this difficult?

Once again this boils down to thinking in processes and not results. For a lot of people it’s difficult to cope with the uncertainty that you don’t know how to get there.

Examples

When we started with the Improvement Kata we had the challenge to move to single item flow for releasing a story. So, when a story was ready it should get online.

Another example is for the subprocess for the translations. We defined the challenge like this:
Within three months get to single item flow for translations, with a cycle time of one day, without spending any time answering questions.

Target condition

A target condition is the first step that brings you closer to your challenge and that’s attainable within three to six weeks. This is the future state of the process that we’re aiming for. The target condition will give us a sense of direction for our improvements. How? We measure our work process while we work. Every time we have a deviation from the process as described in the target condition, we have to look into that. We call that a 'root cause analysis' (RCA for short). Doing the RCAs will provide us with information about our bottleneck.

Example

For the challenge about the translations we defined this first target condition:
Define and measure the time it takes to translate a single item to all languages. We want to measure per language.

Bottleneck

Sometimes we have referred to this as an obstacle. But the word bottleneck is much better suited to describe what it is. A process can only have one bottleneck (but many obstacles). The bottleneck is what prevents us from getting to our target condition.

If you look at an hourglass, the part that’s the smallest is the bottleneck. Increasing the size of the hourglass before or after the bottleneck doesn’t increase flow. Improving anything other than the bottleneck is waste. The bottleneck prevents the item from flowing through the process uninterrupted, or is that part of the process with the lowest throughput.

Only improving the bottleneck will bring you closer to your target condition. We solve the bottleneck by doing a PDCA cycle (more on that later).

Why is this difficult?

The hardest part is defining the bottleneck. When you start improving and get the hang of it you see a lot of things that can be improved but are not the bottleneck. The urge to solve those things is hard to resist, especially when they are small things you can do. Sticking to solving the bottleneck is difficult and takes some discipline. On the other hand, while the theory says there is only one bottleneck, solving something is always better than searching for the bottleneck and solving nothing. Making an improvement gets you to practice the RCA and PDCA cycles.

Improve what must be improved not what can be improved.

Example

For our translation example we defined the first bottleneck as follows:
Not knowing what an item consists of. We haven’t defined an item, and we don’t know which labels and pages that need translating are part of that item.

RCA

As I explained, RCA is shorthand for ‘root cause analysis’. Every time we have a deviation from our target condition we do an RCA to find the root cause. Finding the root cause will show you the bottleneck.

Why is this difficult?

A deviation from the target condition never happens at a convenient time, most of the time you have to disturb people to get together to do the RCA. We like to do the RCA as close as possible to when the deviation is happening so the trail of information doesn't get cold. So, doing the RCA is a trade-off between not working in flow and improving daily.

I had a discussion the other day with Maarten, Front-End Developer & UX Designer, about a feature that took a long time to get online. It unfolded like this:

Maarten: We finally have the story that automatically generates the images for the documentation online. It took us two RCAs and a lot of work to get it done.
Me: Don’t worry that it took longer than planned, because we learned a lot in the process.
Maarten: Yes, the RCAs we did shifted my mindset from ‘this process is unstable’ to ‘why is this process so unstable?’.

With this mindset shift you can start looking at the root cause and think of solutions. With the former mindset you only get annoyed and frustrated and it won’t improve anything.

We have to slow down to go faster.

PDCA

PDCA is shorthand for ‘Plan, Do, Check, Act’. The process to improve a bottleneck in small steps. The challenge here is to come up with a small step to improve the process. Something you can do today. For some things, we obviously need more time. For example, if we need to develop or automate something. But, we should always try to make things smaller. Can we first do an improvement by hand so we can see if it brings us closer to the target condition? When that’s the case, can we automate? A small improvement will shift our field of vision and will increase our knowledge threshold. After the improvement we see and know more.

Too big of an improvement can lead to waste because it doesn’t bring us closer to the challenge. That’s why we have to keep improvements small. We can only do one improvement per process per day. Else we don’t know if the improvement actually improved something.

Why is this difficult?

Most of the time we see a lot of things that can be improved. And we want to get those out of the way, thinking that will solve all problems, so we can carry on with our work. But we don’t know if all those problems still exist when we do some small improvements.

Another difficult thing is to not think too far ahead and see all the obstacles on the road. You don’t know if those obstacles will actually materialize when we’re there. And, if that obstacle is actually the bottleneck. So, we don’t know until we get there.

Taking small steps is to maximize the work not done. We get there when we get there.

Field of vision or knowledge threshold

The field of vision or knowledge threshold is what we currently know and what we can see. In this field of vision are a lot of possible improvements. The challenge will give us a direction for our improvements. If we make a small improvement we will shift our field of vision (blue line) and increase our knowledge threshold in the direction of the challenge. After this shift, we know more and can see other improvements and steps we can take to reach our challenge.

Why is this difficult?

We blame ourselves for not seeing improvements earlier. You can catch somebody saying “why didn’t we do this last year?”.

I have to quote the famous Dutch football player, Cruijff, here:

Je gaat het pas zien als je het doorhebt.

Translated roughly to English:

You’ll only see it when you understand it.