Chapter 10. Process improvement

This chapter covers

• Continuous improvement—the real purpose of kanban
• Respect for people—putting people first
• Retrospectives, root-cause analysis, and Kanban Kata

Since it is people who manufacture things, manufacturing is impossible unless people are developed.

Display at Toyota Technology Museum in Nagoya

“Developing people first” is a core principle in Toyota’s philosophy, and its two parts, “respect for people” and “continuous improvement” (or kaizen), are often referred to as the two pillars of The Toyota Way management system.

This philosophy of improvement is a mindset that can be found throughout Lean organizations like Toyota, from the CEO and overarching strategies to the janitorial staff and how people place their tools on the workbench in order to be more effective. There’s a deeply rooted aspiration to do better, to improve, and to be more effective in the heart and soul of a working Lean organization. It’s the respect for people—respecting, developing, and encouraging everyone in the organization—that makes this possible.

With its roots in Lean thinking, kanban is all about continuous improvement and respect for people. Visualizing the work is an easy but effective way of enabling self-organized improvement work. Limiting WIP and helping work to flow make bottlenecks and improvement opportunities visible to the team, allowing team members to come up with ways to improve.

Unfortunately, kanban doesn’t solve the problems for you, and it doesn’t automatically improve things. Kanban exposes improvement opportunities, but it’s up to you to find out how to improve. In this chapter, we’ll look at a few different practices that will help you with that. There’s no better way to start this chapter, and get your attention, than to paraphrase the demanding dance coach Lydia Grant from Fame:

You’ve got big dreams. You want to improve. Well, improvement costs. And right here is where you start paying: in sweat.^[1]

¹ See www.imdb.com/title/tt0576603/quotes for the original quote.

Lydia Grant, Fame

10.1. Retrospectives

The retrospective is an important practice in most agile methodologies. In fact, one of the agile principles^[2] states, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” In the retrospective meeting, you analyze your process and progress during the last period and try to find areas in which you can improve.

² Check out the principles at http://agilemanifesto.org/principles.html.

Agile retrospectives are a big area, and several books have already been written on the topic. This section is by no means an attempt to provide complete coverage of the topic; rather, it’ll show you how the practice of retrospectives can be put into action in a kanban setting. If you want more information about a lot of different ways of running retrospectives and the thinking behind them, we recommend Agile Retrospectives by Esther Derby and Diana Larsen (Pragmatic Bookshelf, 2006, http://pragprog.com/book/dlret/agile-retrospectives) and The Retrospective Handbook by Patrick Kua (CreateSpace Independent Publishing Platform, 2013, https://leanpub.com/the-retrospective-handbook). Both of these are great and have a nice practical and pragmatic touch to them.

10.1.1. What is a retrospective?

A team retrospective is run at regular intervals, with a preference of doing them more often rather than seldom. Typically, teams set aside a few hours every one to four weeks for retrospectives. This can be seen as the team investing time in improving how they work together.

The aim of the retrospective is to come up with a few improvement actions (preferably no more than three) that can be changed before the next retrospective. This ensures that you, as a team, take on only as much improvement work as you can handle. You’re doing small improvements often. (“Limit your WIP,” remember?)

A retrospective usually consists of five distinct parts:^[3]

³ From the excellent book, Agile Retrospectives (http://pragprog.com/book/dlret/agile-retrospectives).

1. Set the stage. This first step is when you kick off the retrospective and set the mood for the meeting. A great way to do that can be to inform everyone about the retrospective prime directive (see the following box) or use some sort of icebreaker exercise (see the next Word from the Coach).

   

   A Word from the Coach

   

   A great trick is to use some sort of exercise that ensures that everyone says something, if only a single word such as “yes” or “no.” For example, go around the room and ask, “Do you agree with the retrospective prime directive?” Research has shown that if someone says something in the beginning of a meeting, there’s a much higher probability that they will speak again later in the meeting.

2. Gather data. At this stage, the team looks back (hence retrospective) at the past period and gathers data about what happened. Different retrospective exercises focus on different events, on different moods, or on the progress of the team, but the main idea is the same: gather data for analysis.
3. Generate insights. Here you analyze the data you gathered to learn what conclusions you can draw from it. Why did these events go down the way they did? There are a lot of different ways to do this: for example, root-cause analysis.
4. Decide what to do. The main effort next is to find a suitable set of actions that you know you can complete during the period up to the next retrospective, which often is a nice timebox for improvements. Typically it’s better to choose fewer actions than more; more actions stand the risk of ending up not being done. Sometimes you might not have actions come out of the retrospective. Maybe the team solved the problems during the retrospective, or maybe they had to sit down and talk for a while. This is OK, too.
5. Close the retrospective. A good practice at this point is to do a mini-retrospective of the retrospective.^[4] It can be as simple as asking people what they thought about the form of the retrospective and how it can be improved.

   ⁴ But don’t do a retrospective of the mini-retrospective on the retrospective, because then you might be drawn into a recursive loop of retrospectives ending in the inception of the universe.

In order to stay focused, we suggest that you timebox the meeting to, for example, an hour and that you also timebox the different parts of the retrospective.

10.1.2. How does it work?

The outline we just described is pretty generic and doesn’t tell you much about what to do during a retrospective. There are a lot of different ways to do this, and we often mix different approaches to keep the team alert and keep the retrospectives from becoming boring. A good tip is to invite someone from another team to facilitate the retrospective for you; that gives you fresh ways of running retrospectives, and someone who isn’t involved with the team can be neutral, focusing on the facilitation of the retrospective without feeling a need to participate.

You can find a lot of good exercises and complete plans for retrospectives online. Here are two sites that we’ve found useful:

• Agile Retrospective Resource Wiki, http://retrospectivewiki.org
• Gamestorming, www.gogamestorm.com

In the following sections you’ll find a basic retrospective that we think is a good representation of how a retrospective can be run.

Set the stage

1. Start by showing or reading the retrospective prime directive, and ask the people attending the retrospective if they can adhere to this for this retrospective. If not everyone agrees, you should underline that the goal of the retrospective is to find improvements, not to end up in a blame game.
2. Gather data. Ask the team to write down all the great things that have happened during the period since the last retrospective:
   • Instruct them to write each thing on a separate sticky.
   • Allow three to four minutes (use a timer) to brainstorm ideas. When the team is done, have them post the items on part of a whiteboard in any order they want.
3. Do the same thing again, but this time, write down things that you want to improve. Remind the team of your focus: you don’t want to find bad people, but rather improvement opportunities that you haven’t yet realized. Follow the same instructions as before.
4. There will often be a lot of similar ideas; ask the team to group them to identify common themes. If you want to, you can have them do this in silence.^[5] That brings out a different kind of dynamic in the group and is often quite quick. This should be done in a few minutes.

   ⁵ Of course you can talk if you can’t read the stickies. The silence part makes everyone equal in that anyone can move a sticky without being interrupted. Watch carefully for stickies that move back and forth a lot, because those are things that people don’t agree on how to group. Those might be interesting to discuss separately or maybe to split into two stickies.

5. Do the exercise one more time, but this time focus on an ideal future. You could say. “If you had a magical wand and could do anything—what would your situation look like at the next retrospective?” Use the same patterns as for the good and bad items.

Generate insights

1. You should now have a lot of ideas of good things that have happened and some areas that the team can do better in or would like to experiment with to improve. This is usually a good basis for a discussion.
2. Ask the team to vote for the one or two (maybe even three) things that they would like to change during the next period.
3. Decide what to do. During the discussion, help the team to focus on things that stand a chance of being implemented during the next period and that have a concrete outcome. You could, for example, ask them, “How do you know when that’s done?” Using SMART goals^[6] for your improvement actions is another good practice.

   ⁶ SMART is an acronym that stands for Specific, Measurable, Attainable, Relevant, and Time-bound goals. This makes sure you end up with a very clearly expressed goal, and in the discussions you’ll also clear out misunderstandings and misinterpretations of the goal.

   Make sure to set aside a good portion of the retrospective timebox for this, because this is usually an important (and hopefully fruitful) discussion. Allow at least 15 minutes, if you’re running a one-hour timebox (25% of your time, in other words).
4. Close the retrospective. Ask the team to vote with a “fist of five” on what they thought about the retrospective. On the count of three, each person raises the number of fingers corresponding to their rating of the retrospective: one is worst, five is best.
5. Ask them to write down one thing that can be improved before the next retrospective and post that sticky on the door on their way out.
6. Thank them for their participation.

These instructions should be viewed as a starting point. You can elaborate on this by using other forms of retrospectives as you see the need: for example, to address a specific area or to mix it up a little.

When should you run retrospectives?

For methods that are iteration focused (Scrum, for example), the retrospective comes naturally at the end of the sprint or iteration. Many teams that are using kanban use a flow-based approach, and there’s no “end of iteration” in your process. Our suggestion is that you decide on a suitable cadence (see chapter 9) for your team. A suggestion could be to have retrospectives every other week and keep them timeboxed to one hour. As you start to get more used to doing retrospectives, you could experiment with what a suitable cadence for your team would be.

A retrospective can help you come up with a couple of improvement points that you want to implement. To understand why this is important or where the root of the problem lies, you can do a root-cause analysis, the topic of the next section.

10.2. Root-cause analysis

Imagine that you’re working on a team and that lately a lot of bugs have appeared. You have metrics in place and see that the trends are clear: the number of defects has gone up, and the total lead time has increased quite a lot. The team has decided to do something about this trend. They want to have fewer defects and shorter lead times.

What do you do? Where should you start? What is the problem at hand? Should you tell the developers that they should get their act together? Has the quality of the specifications degenerated? Are the testers not on their toes? Do you need more testers, to keep quality under control? Everyone is doing the best they can, right?

Root-cause analysis is a structured approach to reason around a problem so that you get to the bottom of the issue: the real, underlying reason that the problem occurs. The idea is that there’s no use in fixing the symptoms without also looking for the root cause, because that will only make the same, or similar, symptoms resurface somewhere else later. You want to fix the real problem,^[7] to make sure it doesn’t happen again and that all the problems that follow go away.

⁷ “The problem, the real problem, and nothing but the problem, so help me God,” if you want.

You might also have heard about the five whys. Root-cause analysis is based on the same thinking. You keep asking “Why?” until you hit the root cause of the problem. Strangely enough, teams often hit the real problem after five “Why?” questions and answers; hence the five in the five whys. Let’s see that in action.

10.2.1. How it works

Root-cause analysis can be used to solve problems on all levels, both big and small. You could ask questions to find the root cause (the five whys) or, if it’s a more complicated problem, run a workshop. If you run a workshop, we suggest that you have all the people in the room who you think might help you find the root cause. Keep the workshop timeboxed to focus on the important questions and discussions, and don’t wander off topic. Decide on a start and end time for the workshop, and tell everyone attending that the goal of the workshop is to find the root cause of the problem at hand.

Why do we need to fix this?

Start by writing down the problem you’re discussing on a sticky note, and post it in the middle of a whiteboard. The first part of root-cause analysis is finding the consequences of not fixing this problem. This is done to gain a deeper understanding of why it’s important to fix the issue:

1. Starting from the “problem sticky,” ask “So what?” to generate ideas.
2. Post each new idea on the board, and continue upward until the “So what?” questions don’t make sense anymore.
3. You’ll probably generate several different paths or branches of ideas. Follow each branch, and keep asking “So what?” to follow the reasoning in each branch.
4. Indicate how the stickies relate to each other by drawing lines and arrows between them.

   

Here’s one example of a dialogue:

Marcus: We have a lot of bugs; so what?

Daphne: Well, that takes time away from developing new features.

Beth: Yes, and it will also make our product look bad.

Marcus: Ok, our product looks bad; who cares?

Beth: Are you crazy? We may lose users.

Adam: And the net promoter score, NPS, goes down.

Marcus: What about the NPS, why is that bad?

Beth: Well, that’s what our investors are looking at. In fact, they care about the number of users as well.

Marcus: Why is upsetting the investors bad?”

Beth: They may cut back investments—ultimately stopping the product development. That’s why.

Marcus: So what? Who cares about ...

Daphne: Marcus, come on ... I think we’ve reached the end of the road for this one. It’s bad. We end up unemployed, alright?

Marcus: You’re right. Let’s go back to the fact that bugs take away time from developing new features. Why is that so bad, then?

Daphne: It means we can’t build new features. There’s no new stuff added to our product.

Marcus: So what?

Daphne: Well, that would also make us lose users.

Beth: But that also means there’s an opportunity for our competition to catch up.

As you can see, the team quickly came up with reasons why this issue is important to look at and learned a lot about the problem in the process. Using the approach described here, they’ve now reached one or more top nodes of the tree. They now know the impact of not doing anything about this problem. Let’s now work our way down to the root of the evil to find out what the real reason behind the problem is.

Finding the root cause OF the problem

The second part is digging downward into the root cause by asking “Why?” questions. Just like with the “So what?” questions, you start from the problem statement and create stickies for each answer to the “Why?” questions.

You’ll end up with a lot of branches here too, but keep digging deep. Remember to draw arrows and lines that show how the stickies relate to each other.

You may find that you create a circle of references, so that a loop is created. These are special places that need your attention: they’re called self-enforcing loops. These are things that pose the risk of creating a vicious circle of things that keep feeding each other.^[8] Make a circle around those loops or make them stand out somehow, so that you remember to do something about those problems.

⁸ For example, we’re stressed, so we take shortcuts and hence start to cut back on quality, which makes us more stressed, forcing us to take more shortcuts, cutting back on quality. That in turn makes us stressed and forces us to ... What? Ah—you got it. OK. I’ll stop now. It’s a circle—it’s hard to know if you’re there yet.

Here’s an example of the team going for the root cause:

Joakim: We have many bugs; why?

Adam: We’ve been under a lot of time pressure. It’s deliver, deliver, deliver.

Daphne: We don’t do any technical work items anymore.

Eric: We have stopped pair programming.

Joakim: Ok, why don’t we do any technical work items?

Adam: Because of the time pressure.

Eric: And the same goes for the pair programming. People think that it takes longer.

Joakim: That’s what we call a self-enforcing loop. Let’s indicate those with red arrows.

Joakim: So why has the time pressure been on?

Adam: Well, it’s the May release coming up ...

Joakim: Why do we have a time pressure to deliver that?

Adam: We didn’t get to decide what went into the May-release backlog. That created a much bigger backlog than we could handle.

Joakim: Why didn’t we have any say on that, then?”

Eric: Because Sales didn’t care to ask us?

Daphne: Nope, that’s not true. They asked us, but we weren’t allowed to take time out of development on the February release, remember ...

Joakim: OK, so that’s another way that the pressure on delivering is hindering us. Another self-enforcing loop.

As you probably see from that dialogue, root-cause analysis is a razor-sharp tool that quickly cuts to the root of the problem and the business impact. This might raise some big questions, so make sure you have an atmosphere of problem solving rather than blaming in the room. Reminding people about the goal of the workshop before you start and that you want to find “unrealized improvement opportunities” in your process and not people who have failed could be one way.

10.3. Kanban Kata

Retrospectives are great because they allow time out of your normal flow to improve your process. In your normal work, you can also work on improvements, such as small things that you can fix right away (fixing that step in the build process that often fails) or steps toward a bigger goal (lowering the average lead time of your work items).

Kanban Kata is another way to implement process improvements. Kanban Kata is a series of questions and forms that help you to improve in small steps, in a continuous flow, so that improvement work and ordinary work are intermingled. It’s a great way to get a process around the continuous improvements in your team, pioneered by our good friend Håkan Forss.^[9] We like Kanban Kata because it’s along the lines of continuous improvement, inspired by the way Toyota does it—making process improvements an integral part of normal work. It also complements normal retrospectives in a nice way for kanban teams.

⁹ Visit him at @hakanforss on Twitter and at http://hakanforss.wordpress.com.

A kata—a number of precise questions that you follow to a point—might feel contrived at first, but remember that a kata is a series of predefined steps that you follow in order for them to become muscle memory. A kata is written a certain way so that ultimately it trains you to do the right thing without thinking. In this case, the kata trains you in process improvement.

10.3.1. What is Kanban Kata?

The easiest way to introduce Kanban Kata, now that you know the origin of it, is through an example. In this section, we’ll introduce the three katas, or improvement dialogues, that make up Kanban Kata:

• Daily Kata— A way to start including improvement work in your daily meetings
• Improvement Kata— A formalized way to improve your process
• Coaching Kata— Focuses on improving the learners (the people in the team): a coaching technique

In the imaginary world where the Kanbaneros reside, we’ve sent Håkan to the team for a couple of days, and you’ll see how their way of tackling improvements and daily work has changed. Håkan has introduced the whole team to Kanban Kata and given Frank (the team lead) some extra hours of introduction.

Daily Kata

You join the team and Håkan^[10] around the board for a morning meeting that Frank has started:

¹⁰ We use a LEGO^® avatar to represent Håkan. This feels very appropriate to us because Håkan not only is a big LEGO^® fan but also has used LEGO^® elements in his presentations in a very effective and entertaining way. And we can disassemble him if he starts to complain about how we describe Kanban Kata.

“Alright guys, what are we trying to achieve?” Frank asked, facing the team.

“We’re aiming to have code ready for release every Wednesday; that’s tomorrow,” Daphne said.

Frank looked down at a little card he held in his hand. He looked up again and continued: “Where are we now?”

“There is a risk that we won’t be able to release tomorrow,” Adam said, a bit disappointed.

“What obstacles are in our way now?” Frank asked.

“We have work items 22 and 33 checked in with no problems,” Eric said.

“There are a couple of problems jeopardizing the release,” Adam stated.

“What are they?” Frank asked.

“Right now we can’t build the master branch. There are some nasty merge problems that need resolving,” Daphne said, clinching her fist in an I-will-wring-that-problem’s-neck-in-a-second movement.

“What’s our next step, and what do we expect?” Frank continued.

“I’m looking into the build errors for the master branch right now,” Daphne said. “With the help of Eric, we expect to find the problem soon.”

“When can we see what we’ve learned from taking that step?” Frank asked.

“We’ll probably find a solution in an hour or two.” Daphne looked at Eric, who nodded his agreement.

“Alright, let’s meet back here before lunch.” Frank checked his watch. He continued: “Anything preventing flow right now?”

“Yeah,” Adam started, as he pointed to the red sticky for story 46, “we have some questions regarding the business rules. They block us from finishing up the specifications and test specs, and development will be waiting too.”

“Alright, what’s our next step, and what do we expect?” Frank asked.

“We have a meeting booked with Cesar and Beth for 2:00 PM today. We expect that meeting will clear it up,” Adam said.

“When can we see what we’ve learned from taking that step?” Frank asked again.

“We can share what we learned at tomorrow’s morning meeting,” Adam answered.

“Great. Be sure to add the resolved date to the blocking sticky when it’s resolved.”

“Anything else preventing the flow right now?” Frank urged them on.

There was some murmuring in the group, but no one had anything else stopping them. Frank closed the meeting with a perky, “Alright people—stop starting, and start finishing.” They all looked at Joakim, who stood in the back, and then burst out laughing at Frank using that statement in such a cheerful manner.

Improvement and coaching kata

When the group dissolved, Frank went up to Håkan and asked, “Did I do alright?”

“Yeah, that was great. What was the biggest difference from your normal standups?” Håkan asked.

“Well, probably the focus on learning and that I underlined taking small steps. Also I think the ‘what do you expect’ part made us think about what we did before we started, in a good way,” Frank said.

“Yes, that was what I heard too. Great work!” Håkan said. “Should we move on to the next kata, then?”

“By all means, sensei,” Frank said and winked. They went back to the board, and Håkan started by asking, “What is the target condition?”

“We’re still working with our long-term goal of reducing lead times for all our work items, as we decided a month back. Our hypothesis is that it can be achieved with the same number of people that we have today on the team.” Frank continued, “We are reducing the lead time on the board to five days, for items classified as medium.”

“What is the condition now?” Håkan asked.

“We’re getting there; at least, it feels a lot closer now,” Frank said.

“What do you base that on? Can you show me some data?” Håkan asked.

“Sure thing, here’s our work-item run chart for the lead times.” Frank pointed to a chart next to the board.

“Can you explain to me what you see?” Håkan asked.

“Yes: in this diagram we have tracked the lead times for medium-sized work items. We can see that for the last items we’re close to five days, our target condition,” Frank said.

“What was your last step?” Håkan asked, after turning over the five coaching questions card (shown later in this section).

Frank grabbed a Plan-Do-Check-Act (PDCA) cycles record form^[11] and pointed to the row from the last coaching session.^[12]

¹¹ A PDCA cycles record form can be used to track your decisions and progress through the improvement work.

¹² The forms and cards in this section are taken from The Improvement Kata Handbook, Copyright © 2013 by Mike Rother, all rights reserved. Issued under the Creative Commons license. You can download yours here: http://mng.bz/Kweb.

“To document the test setup process.”

“What happened?” Håkan prompted.

“Well ... we went through a normal test setup and documented everything we did,” Frank said, a bit unsure.

Håkan nodded acknowledgment before asking, “What did you learn?”

“It was quite easy to see a number of steps in the test setup process that could be automated, if not all of them,” Frank said.

“What obstacles are now preventing you from reaching the target condition?” Håkan asked.

“There’s a number of issues, and right now ...” Frank said, and then listed the obstacles for Håkan.

“Which one are you addressing now?” Håkan asked.

“The test setup time,” Frank said.

“What is your next step?”

“We’re starting to automate the complete test setup today,” Frank said proudly.

“Do you expect to be done with that by the next time we meet?” Håkan asked sneakily.

Frank smiled as he remembered. “Smaller steps that we can finish in a short time are preferred ... right, sensei?”

“Yes.” Håkan smiled.

“Well, we could probably start automating the loading of the test data. That’s a pretty easy one.”

“Sounds reasonable. What do you expect, when taking that step?”

“Well, at least 80% of the time spent to set up the database should be cut,” Frank answered.

“And what would the time be?” Håkan asked.

Frank did some calculation in his head, and then said: “That would be about four to five minutes, at least.”

“Good. We want to be as precise as possible,” Håkan explained. “When we’re more precise, it’s clear whether we’ve reached the expected outcome or not. The important part isn’t reaching the expected outcome, but that we can learn by comparing the outcome to what we expected to achieve. The kata is all about learning so we can improve in small steps over and over again. Getting back to the kata,” Håkan said, “when can we go and see what we have learned from taking that step?”

“We expect to have it done at the end of the week.”

“Great. Let’s meet back here again on Friday at 10:00,” Håkan said, as they ended the coaching session.

Håkan and Frank headed for the coffee machine and kept talking about the test setup. The improvement work was on a roll, and it felt like they had good control over the process. That calls for coffee!

10.3.2. What happened

In this example, you saw three katas being used: the Daily Kata, the Improvement Kata, and the Coaching Kata. You could see the rather strict form in which both Frank (in the Daily Kata) and Håkan (in the Coaching Kata) used a set of predefined questions, known as the Five Questions.^[13]

¹³ Used under Creative Commons; see http://mng.bz/Kweb.

If you feel that the way these katas (questions and forms) are formulated doesn’t suit you and your team, then you could formulate your own. But the questions should then be followed to the letter, as you would have done with the ones suggested here. Repetition is the key to getting it perfect.

Repetition is the mother of all knowledge. Now do the assignment again.

Lennart Wistedt, Marcus’s fourth- to eighth-grade math teacher

Did you also notice the focus on learning and taking small steps? For every little step the team took, they first were asked for the expected outcome. Then they were asked what they learned from what happened. That’s the scientific method at play: developing a hypothesis, making a prediction of what will happen, performing an experiment, observing the data, and reflecting on the difference between the prediction and what happened.

10.3.3. Why does this work?

Kanban Kata puts a strong focus on learning in a structured manner. It consists of three katas, or routines, if you like, that build on the scientific method. The nice part about using the scientific method is that no result is bad; it’s only a result. You’ll use the outcome to learn and to improve your next hypothesis.

There is no such thing as a failed experiment, only experiments with unexpected outcomes.

R. Buckminster Fuller

The next secret to why Kanban Kata works is that it takes small steps. You’re trying to improve from your current condition toward an improved target condition. The road toward the target is unknown, and the best way to navigate it is in small steps. These steps are the experiments that you’re conducting based on your hypothesis.

That brings us back to the results of the experiments and the fact that they’re only that: results. Even making mistakes or taking wrong turns is OK, as long as you learn and improve from there. Getting from your current condition to the target you’ve set for yourself means going through unclear territory. You’re bound to take some wrong turns—but that’s OK, as long as they’re small steps and you can correct your bearing toward your challenge on the way to fulfill your vision.

In the Kanban Kata, you’re using routines (see the questions that Håkan was using earlier) that guide you through the different katas. They help you create new habits, a new mindset of continuous learning and improvement. That’s where the real gain is in using Kanban Kata: creating habits, a mindset, throughout the organization, of making small, small improvements, every day.

10.4. Summary

This chapter talked about process improvement and common improvement practices:

• Continuous improvement and respect for people are core to kanban.
• Kanban helps you discover improvement opportunities.

We then turned our attention to a couple of common practices for improvements:

• A retrospective is a way for a team to look back on their process and see how they can improve it.
• Root-cause analysis is a tool that helps you find the root problem so you don’t only fix the symptom.
• Root-cause analysis also guides you to see why the problem is worth solving.
• Kanban Kata is a continuous-improvement tool that is based on how Toyota makes improvements.
• There are three katas within Kanban Kata:
  • Daily Kata— Including improvement work in your daily work
  • Improvement Kata— A formalized way to improve your process
  • Coaching Kata— Improving the learners
• The “kata” in Kanban Kata indicates that you follow a set way of working toward a goal, until the routine becomes second nature and making improvements becomes the way that you normally work.

In the next chapter, we’ll take a look at how metrics can help you know whether or not you’re improving.