The Toyota Kata - Book Review and Thoughts

If you haven’t heard of the Toyota Kata book, you can head over to Mike Rother’s Toyota Kata Homepage where you can find good presentations about the key topics as well as a good synopsis of the book, which I won’t repeat here. At a very very high level this book is about the Toyota approach to management - which is to have a focused approach to improvement (The Improvement Kata) and a focused approach to teaching people how to focus on improvement (The Coaching Kata).

As a practitioner of Agile and Kanban in software/product development environments, I love this focus on what REALLY makes Toyota tick. There’s certainly a lot of bad mouthing of Lean and Toyota’s approach to production out there, calling it tool-focused and mechanistic/unfocused. The Kata is book is very aligned with our view of Lean as Kanban practitioners - the key being the thinking about improvement rather than the actual tools.

Let me try to review it by trying to apply it to the context of a Kanban team.

[caption id="" align=“alignright” width=“400”] The Improvement Kata[/caption]

The Kata starts with understanding the direction. Let’s say we bought the Kanban / Lean Startup cool-aid and are aiming at the direction of faster end to end feedback and effectiveness through having dramatically shorter Cycle Times.

Then we grasp the current condition. This is similar to the “Visualize the work” step in Kanban.

Establish the Next Target Condition can mean - ok now that we understand our mean cycle time is 8 weeks and it is unstable - ranging 4-12 weeks and the direction is towards a stable cycle time of days not weeks, lets aim at stable 8 weeks meaning to reduce the variability from 4 weeks in each direction to 1 week in each direction. Sounds like a reasonable next target condition to me.

Now we try to make that happen and encounter obstacles. We would need to overcome them.

The Improvement Kata talks about a daily cycle of looking at the current actual condition, in light of the current target condition, understanding the obstacles explaining the gaps between the actual and the target, and urging us to choose one of the obstacles and work to address it in small experimentation steps using the PDCA cycle (Plan Do Check Act). On top of this approach sits the Coaching Kata with Five Questions that are aimed at coaching people on using the Improvement Kata. The aim is for managers to coach their people in their improvement work.

[caption id="" align=“alignright” width=“255”] The Five Toyota Kata Questions - Mike Rother[/caption]

This is great stuff. Really great. The key point here is the focus on the job of people to always improve in a focused way, and the job of management to work on improvement themselves but also work to improve the improvement capabilities of their people. Use this as a repeating building block, tie it to the value system and objectives of people throughout the organization and you stand a real chance for improvement work to become part of your DNA.

I’m just not clear on how to implement this in Product Development/Knowledge Work. Our processing cycles are orders of magnitude slower than in production. Which means we either do coaching/improvement cycles without the ability to see samples of finished work - which invalidates the scientific nature of the experimentation cycles, or we have to suffice with much slower improvement cycles, which makes improvement part of the outer-loop cadence (e.g. retrospectives, operation reviews) rather than the inner-loop cadence (e.g. Daily Syncs). Which is a real shame because it seems Mike associates a lot of the power of the Kata with the fact it is done very often.

At the moment I’m planning to use the Improvement Kata / Coaching Kata for outer-loop cadence, but am still trying to find a way to run it for the inner-loop. If you have some idea or experience with this, help me out…

A possible direction is to do the improvement/coaching kata for local internal processes e.g. Dev/Test in the inner-loop. If a developer is using TDD then we can apply the Kata for his TDD cycles. For a tester we can do it for his exploratory testing sessions or for his test cases.

Having a reason to avoid relaxing processes

Toyota plant manager would likely say something like this to the assembly manager: “You are correct that the extra paperwork and first-piece inspection requirements are obstacles to achieving a smaller lot size. Thank you for pointing that out. However, the fact that we want to reduce lot sizes is not optional nor open for discussion, because it moves us closer to our vision of a one-by-one flow. Rather than losing time discussing whether or not we should reduce the lot size, please turn your attention to those two obstacles standing in the way of our progress. Please go observe the current paperwork and inspection processes and report back what you learn. After that I will ask you to make a proposal for how we can move to a one day lot size without increasing our cost.”

Think about the scrum team talking about the overhead of weekly sprints and asking to use longer 2-week or 3-week sprints. Or the kanban team complaining about low WIP limits. Or testers complaining about the overhead of Small Batches. I love this quote highlighting the use of a vision to act as a decision filter for such policy discussions. We are using 1-week sprints because it is bringing us closer to cycle times measured in days. We are using low WIP / small batches thru testing for the same reason. Now instead of trying to revert to longer sprints/higher WIP/larger batches, let’s observe what are the overheads that make sprints/WIP/small batches painful and let’s see a proposal for how we can be more effective using them. I actually started to use this approach in the last couple of months. An exercise I frequently run in management workshops is trying to think what would enforcing a WIP limit entail for an organization. What would be the obstacles. It helps with change management to have a chance to vent some obstacles and understand how other companies deal with them and how this group can deal with them, even without starting to actually enforce a WIP limit.

The important point is that without the overarching direction / north star, it is hard to remember the rationale for many of the lean/agile practices/tools. If we don’t remember we believe shorter cycles lead to faster feedback leading to higher efficiency, it is easy to fall into the trap of regression to easier more comfortable ways of the past.

Ability to work according to Sequence is an indication of maturity

Sequence attainment is a tighter process metric, which means if the assembly process has to deviate from the intended leveling sequence, then even if shipments are still made on time, you do not have sequence attainment for that day

In product development this is similar to pulling cards out of order from your input queue / Product Backlog. Skipping cards in the backlog is a good indication of a capability problem. A target condition can be “we always pull from the top of our input queue/backlog so that we achieve alignment with the value priorities of the business”. A typical obstacle for this target condition is a sparse skills/talent matrix. And a next step can be knowledge transfer or training.

The difference between a Target Condition and a Target

The Improvement Kata talks about setting Target Conditions, which are Process Conditions, which in turn enable reaching a Target Bottom Line result. It says that having outcome targets is important, but the means for getting to those outcomes should be the real focus of management work. This is quite different from how many managers see the world, especially in the era of Management By Objectives. We have a lot of work to do to teach managers to think about managing by Means in order to reach Outcomes.

For example Sprint Velocity is important, but more important is managing the means towards improving the velocity. So discuss the target condition you need in order to have a high velocity and manage the obstacles towards that. It can be “READY” policies, smaller stories, healthy Continuous Integration system, TDD or whatever you feel enables a higher velocity.

Vague Target Conditions

It is important to understand that specifying a target condition doesn’t mean we define the solution up front. We define the required condition up front, and let the solution emerge through experimentation cycles. We do have a desired behavior of the process we are improving at the black box level and we tweak the process towards the required behavior through probe-sense-respond cycles as defined in Cynefin for example. Bottom line in my understanding the Toyota Improvement Kata is compatible with Complexity Thinking.

Be hard on the Process - Be soft on the operators

What a great quote to start a retrospective with… It means that if there are problems most chances are they are process related. The process needs to help people succeed. (individual and interactions over processes and tools?) It is similar to deming saying 95% of what affects performance is the system. Rest 5% is people. Or five whys striving to policy/system impediments/obstacles underlying people errors. My view is that the role of people is to adapt the system/process so they affect more than 5% at the end of the day. That is the importance of the improvement kata and continuous improvement in general

There are currently no autonomous, self-directed teams at Toyota

Actually, Toyota even considers expecting people to autonomously own improvements “Disrespectful of People”. While operators and teams do participate in voluntary improvement activities, improvement is part of the job function of team leaders, supervisors/managers and engineers.

Applied to our typical agile team, what this would mean is that the main ownership for improvement lies in the hands of leaders/managers rather than the teams/engineers. Certainly interesting thinking. I do agree that managers/leaders need to lead the improvement efforts. I do think that using fair process and involving team members makes more sense in knowledge work environments such as product development.

Mike does talk about operators participating in improvement work - but mainly as improving their understanding of Kaizen and to help understand whether they are candidates for promotion.

A good take away is to let someone tackle a tough process/obstacle to consider whether they are ready for promotion. Maybe a better alternative than let them own a certain delivery objective?

To develop your own capability, the effort will have to be internally led, from the top. If the top does not change behavior and lead, then the organization will not change either

Managers should lead the improvement effort. Loud and clear… This actually means running improvement kata at a process and coaching their people in their improvement katas. Not a trivial request from managers. Think about the VP R&D overseeing the improvement kata at a testing process or coaching his Director of QA in his improvement kata for an automation challenge. Part of this problem is a Catch-22. In order for the organization to know how to do this they need to try it hands on. In order to have internal leadership managers need to try it first.

Part of the approach Mike suggests is having an Advance Team experimenting with the improvement kata hands on, before rolling it out throughout the organization. I actually like the implications, at least in theory. As a Kanban example, have senior leadership involved in using Kanban to improve a process, so they are proficient enough in the improvement process and its effects when Kanban becomes an improvement approach used more and more within the organization. How can we ask them to coach their people otherwise… This certainly helps with stickiness of the change/improvement effort, although it might slow it down or even block it from taking off in the first place in places which are not ready for it (That is a “Fail Fast” scenario which is probably preferable. We’ve all seen the stalled change initiative - it’s not a pretty picture, not for the organization and neither for the consultants)

coach only one target condition at a time, which generally means one mentee at a time

We typically use forums to coach people towards improvement. Mike’s recommendation to coach one on one is an interesting and challenging one. Need to think about it some more.

(1) a restatement of the overall theme (for example, “To develop improvement kata behavior in the organization”), and (2) a reiteration of “why we experiment,”

Another great quote to start a retrospective with… the current focus of improvement and the reason for experimentation, to facilitate open healthy focused retrospection.

I hope I sparked your interest in this great book. There is still lots of work to be done mapping the Improvement/Coaching Katas to Knowledge Work, but even at raw unmapped form there are great insights in this book. Highly Recommended.

One last note - if you are interested in this topic, you will probably find Henrik Kniberg’s Tokyo Scrum Gathering Keynote about Change interesting as well…