FEATURE – TPS points us to what needs improving — customer value, quality, flow, people, stability — and kaizen supplies the how, through learning-by-doing. Together, they create adaptiveness, says the author, as he describes Lean as a learning system.

Words: Michael Ballé

What do I mean when I say Lean is a learning system? What is learning, in fact?

To understand learning, we need to look into why learn, what to learn and how to learn. To a certain extent, all living creatures have an innate drive to learn: they try to adapt in order to avoid what they don't like (bad conditions) and move towards what they like (good conditions), and learning is figure out how to do so. For us, learning is generally about what we want to change and figuring out how to do so. But sometimes, it's just for the hell of it as well: the drive to learn, and the pleasure to learn.

Learning, however, soon becomes hard. A new thing has the wow factor, and, if we have picked it up, it is usually because it appears to have a high promise and a few early steps. I found out that purchasing a guitar (cool) is much easier than learning to play it (I gave up). Learning means sticking it out through the period of frustration until you get proficient enough to have something to show for it and then sticking it out for the even longer period of persistence to develop true expertise as a subject. Why to learn is feeling that you want to change something, and feeling moved, motivated, driven by this change enough to figure out how to do so, then learning through repeated deliberate practice, and using the lessons to achieve what you wanted, and sometimes going further. To learn, you have to learn how to learn, what to learn and remember why you wanted to learn in the first place.

Say you run a small team of software maintenance engineers that supports the business intelligence software of a large company. Every day has its usual deluge of new requests, updated requests, snide comments from your colleagues, and long working hours fixing things yourself that your team should be able to handle. Griping week about week after week, you conclude that one of the issues is members of your team never keep you abreast of changes in their schedules, and although they deliver stuff, it is never what you thought they would, or that you promised your internal customer. As a result, you put in the long hours working on delivery yourself.

You get in gear, demand updates that are ignored, start asking around and discover the problem is… you. Your distracted and abrupt communication style discourages the members of your team from giving you any bad news. Of course, you’re distracted and abrupt: you’re a software engineer, not a people pleaser. And you’re drowning in urgent work that is always late. Still, as you think it through logically, you realize that you can’t escape GIGO - garbage in, garbage out. If you don’t get information early on who’s going to deliver what and what has changed, you don’t have the information to change anything in the current process.

So, you decide to improve your communication style. This is the first step. You commit to learning and you know you need it. Most people never make that step.

You read a book about it. You try a few techniques. No one seems to notice and nothing changes. You go to a course about non-violent communication, and it’s high-level stuff, so you don’t know what to make of it. Still, you come out of all this certain you need to have more structured conversations about scheduling with each member of your team. Now you hold a concrete end of the stick.

Here is something you can kaizen: you can get better at scheduling talks. Obviously, the first few discussions go terribly awry: your team doesn’t want to talk to you, so they see this as one more heavy-handed way of controlling them. Slowly, you learn: make it short, narrowly focused on one schedule change, and most of all, listen to what the team member is hinting at. You learn to have a to-do list of issues that you need to follow through and discuss next week with the person, to prove you listened. You learn to let the conversation drift around the topics once you’ve identified one issue, because they’re saying other stuff that you don’t know how to hear. Cycle after cycle, you get better at listening and progressively discover just how much you never listened before: their kids have names, their spouses have jobs, they worry about rumors in the company, and they hate the bad rep their department gets.

In Lean, kaizen teaches you how to learn. Kaizen is the essence of learning-by-doing. Pick anything you do, then decide to kaizen it. Deciding to learn is the first step of how to learn. Without this commitment, nothing will happen. Then study what you do and isolate something wasteful, either in the result of your activity, or the activity itself. Scratch yourself to figure out a strategy to reduce this waste. Once you have an idea, then work out how to execute it a few times so that you can tell whether it's working or not.

Reality will probably fight back and frustrate your efforts. You're likely to bump into your own habits, someone else who doesn't want to play ball, or simply not knowing how to do this and that. This is learning. Such learning expands the field of your original enquiry because now you have to better understand the politics of the problem, the technical issues you hadn't thought of beforehand, and your own flagging motivation. You have to deepen your own thinking in all these directions, which is where a-ha moments spring from. Practicing kaizen gets you to deepen your thinking. Now, learning-by-doing brings you to clarify your own theories and understanding about what is going on and to broaden your horizons about how, what and why. Kaizen teaches you about the wider process.

Kaizen on narrow scheduling conversations has opened a whole new world of knowing how to handle a conversation in general - an eye opener if there ever was one. Now you know where the schedule changes are likely to come from and what to prepare for, if you want to take on some of the slack. To some extent, you’ve learned to redirect and prioritize work better in the team, so you don’t have to do it all and, surprisingly, the mood improves. But where do you go from there? You can see that this communication thing is a domain in and of itself, something you can study forever, and that’s quite exciting. But communication alone won’t solve your delivery problems.

This is when you turn to TPS. Three things you can see immediately: workload per person varies drastically from week to week, depending on how specialties have been set up (load leveling); each person will procrastinate on specific activities they don’t feel comfortable with and push them down the schedule (standardized work); and the team has no mechanism to learn together how to deal with both these issues and their combination (kaizen).

Now that you have a better relationship with each team member, you can address, as tactfully as possible, the issue of work they’re not comfortable with. In your study of communication, you’ve learned of motivational interviewing, so you broach the issue of a development plan per person. They make their plan; you support it with resources: it’s a good deal. It helps you learn to better negotiate with HR for training resources. Ultimately, you find out that outside trainers are rare, but that each team member has something to teach if you build and maintain the right conversational environment. The kaizen workshop work wonders in getting them to face together their workload issue, and they set up a meeting you’re not part of at the end of the week to try and smooth workload amongst them. All this time you continue to learn and try new things in conversational competence, because none of these discussions are easy and you realize just how much you didn’t know before and the damage you did to relationships around you – at work, but at home as well. You learn that to be listened to first you have to listen.

On the other hand, anything could be a topic for kaizen, but most kaizen won't deliver much overall progress - they're not supposed to. So, what should we kaizen first? What gets priority? This is where Lean, as in the Toyota Production System applied out of Toyota, comes into play. It tells you what to kaizen:

• What can you improve to satisfy your customers better (what is the current mistake you could fix if you could change a customer facing practice)?
• Where can you spot quality issues closer to where they're made so defects get corrected sooner? How do we recognize a mistake as it's being made? Who needs to talk to whom? Who needs whose opinion?
• Can you reduce overall lead-time in what you're doing? What are the inflexible points that create this lead-time? Where do you hold backlogs or inventories? Before or after hand-offs? Can something be done about this by pulling work rather than pushing it?
• How can you involve coworkers better with the job? Is load/capacity under control or do they go through peaks and troughs of activity? Do they understand all aspects of the job, or should we train more on some specifics? Are they themselves involved in kaizen?
• Is it possible to build a more stable foundation? Are teams autonomous in keeping their area organized (do they know 5S)? How proficient are they at solving their own local problems? And is equipment shipshape and reliable?

This menu offers endless opportunities for kaizen. Look at any work through this prism and something will jump out at you. And as you kaizen this aspect, you'll learn more about the topic, and how these topics are related between them, what makes it a system. And this never changes. No matter what the business or its present situation, the TPS is always there, and it is always the same.

You follow up with the team about their scheduling meeting and they shrug shoulders, mumble “All right,” and at some point, you realize they’re no longer doing it. It solved what it could, it didn’t solve it all, and their work is better balanced anyhow… so, who needs one more meeting? You get the team together and ask them to explain, and they go on about what they did. But, surer of yourself now, you ask them about what the meeting didn’t solve: you’re looking for the kaizen topic. Incoming tickets come irregularly and in batches, the team finally says. “Nothing we can do about that!” You think back to the TPS and wonder whether this is a just-in-time issue. You ask them to keep the slot of the scheduling meeting, but now you’re going to join to investigate with them why demand is so variable. After a few of these sessions, it dawns on you the team receives from the ticketing system both “repair” and “upgrade” requests, which triggers batches of work, which then blend and create a more or less permanent backlog. This is something the team can handle: you ask them to separate the “fix” versus “upgrade” requests and whom the demand comes from. As you investigate it, the team realizes there are several horizons (by when the job needs to get done) and politics (who asks for it, or in the name of whom it’s been asked) involved. You wonder what pull and push might mean in your context.

TPS topics are a great frame because they relate directly to improving performance. Any value proposition is about (what we offer) x (what probability of getting it good, full-on time) / (lead-time to get it) x (overall cost or effort to get it). Experience has shown us for sure that following these principles will increase your performance and following them means... kaizen.

Kaizen teaches you how to learn: you pick something you do, identify waste or a problem, try to improve it, encounter difficulties, adjust your thinking, and learn through repeated practice. TPS, on the other hand, helps you decide what to learn about and improve by directing attention to customer satisfaction, quality at the source, shorter lead-times, better involvement of people, and more stable processes. Without TPS, kaizen can improve almost anything but may not lead to meaningful overall progress; without kaizen, TPS remains a set of principles without the learning needed to put them into practice. TPS gives direction to kaizen, while kaizen turns TPS principles into learn-by-doing concrete situations.

In our case, learning better conversation skills was a threshold moment. Not only did it get you to solve the immediate issue of better communicating with the team, but it also taught you how to handle the learning curve: the long frustration of repeating an exercise and never getting it quite right. By taking on one topic, you can ask yourself the two core questions of learning:

• What is progress?
• What mistake do I keep repeating?

With something like conversational skills, there is no point where you can say to yourself: “I’ve got it, I can stop studying now!” The moment you lose your tempo, old habits die hard and will return as zombie behaviors. Nonetheless, no matter how good you become at conversation, at some stage this won’t help you solve the other issues in the process. This is where looking at it using the compass of TPS is so powerful. Just thinking about it, problems of workloads balance, standardized work and kaizen jumped at you, and you knew attacking those would bring benefits and reveal further, deeper issues. You are learning more deeply about your domain, while learning to better work with others.

How is any of this making us more adaptive? The trick is that by practicing kaizen/TPS back and forth, we learn to learn, and we increase our situational awareness of what's going on. When business conditions change, we're more ready than most: we see it coming and we know how to go about it. It won't guarantee success, but it's better than getting caught with your pants down. The evolutive structure of kaizen/TPS is the engine of adaptiveness that makes Lean so valuable if you seek long-term success.

Learning-by-doing through repeated kaizen makes you more proficient at an activity, but it also makes you understand the why and why not of what you do better and think more deeply about causes and conditions, which leads to seeing sea changes as they occur. TPS acts as a compass to keep you working on the right subjects, on these typical problems that will always be there with any business, and on looking for countermeasures rather than hail-Mary solutions. Bit by bit.

One of the core things I learned from my father was helicopter thinking, which he learned from his sensei as “see with your feet, think with your hands.” Learning can only happen in the detail, in the hands-on practice, deliberately, cycle after cycle. However, it also requires that you lift your head and explore the landscape to see how the land lays, who calls the shots, and what challenges you should respond to in order to adapt and thrive. This core skill of looking for specific answers, then asking large questions and back and forth, from the specific to the general, from the local to the global, from the here-and-now to the intemporal is precisely what deepens your thinking as well as sharpens your focus and your commitment to making things better.

In the end, Lean as a learning system comes down to three simple questions: what, why, and how. TPS helps us figure out what to work on, the recurring problems of customer value, quality, flow, people, and stability. The why is performance and adaptiveness: getting better at what matters today while becoming better prepared for whatever tomorrow throws at us. And kaizen gives us the how: try something, see what happens, scratch our heads, learn, adjust, and try again. TPS without kaizen risks becoming a bunch of principles on a poster; kaizen without TPS risks making us wonderfully good at improving things that don’t matter very much. Put the two together and you get something much more interesting: a way of learning what matters by doing it, bit by bit, every day. The fun of Lean is in that you never quite arrive, but you do get better at figuring out where to go next.

_THE AUTHOR