GA 084 | Practical Problem Solving: Part Five with Jon Miller

You're listening to episode 84 with John Miller. Welcome to the Gemba Academy Podcast, the show that's focused on helping individuals and companies achieve breakthrough results using the same continuous improvement principles leveraged by companies such as Toyota Del Monte and the U.S. department of Defense. And now, here's your host, Ron Perera.

Hey there.

This is Ron Pereira with Gemba Academy, and I'd like to welcome you to another edition of the Gemba Academy Podcast. As always, thank you. Thank you so much for taking time out of your day and your week to listen to the show and for watching our Lean In Six Sigma training videos over@gembacademy.com now a quick update on Gemba Academy. As we've mentioned in the last podcast, we are doing our free DVDs promotion again this November. So anybody that buys an online subscription to either the School of Lean or School of Six Sigma or our combo will receive those same training videos on DVDs free of charge. And if DVDs aren't your thing, we're also offering this month for the first time, four Lean Enterprise Institute workbooks, which are, as I've mentioned in the promo video and previous podcasts, four of the most useful Lean workbooks that I've ever used, namely, learning to see, Creating Continuous flow, Creating level pool, Making Materials flow. So if you're interested in that, go ahead over to gembaacademy.com and you can learn all about that promotion. Now then, today I'm excited to bring John Miller back to the show to continue our Practical Problem Solving series of podcasts. Now, we've done this over. This is actually, I believe, episode four or no, sorry.

5.

This is the fifth series, our fifth episode. In this series, in episode one or part one, which was episode 60, we covered the first three PPS steps. Then in the episode 63, we talked about step four, which is all about root cause analysis. In episode 66, we talked about step five, and then in episode 72, we talked about step six. And now here in episode 84, we're going to talk about step seven of the PPS series. And don't worry, you're not going to have to remember all that. We're going to have everything linked up in the show notes. So if you haven't listened to the first episodes in this series, I would really encourage you to go back and start with episode 60. So to get into any of this, go to GembaPodcast.com and then you can just look for episode 84. This will be the most recent one. And you'll find the links to all the previous episodes on those show notes pages there. So, anyhow, during this episode, John and I really get into, I would say, what are the steps that most people kind of gloss over? All the excitement of planning and doing, you know, that's the fun part of pdca. But this checking part, for some reason, it's. I don't know, people will kind of see did it work or not. But that's basically it. But as John goes into, there's much more to the step than simply seeing whether or not our countermeasure was successful. John gets into some things, double loop learning, he talks about, and he really ties in some really fun analogies of, like, an American football team and a coach and how he might go about evaluating the results of a game or a play. So I think there's some really interesting parallels there. So show notes for this episode, which again will include links to all of the other PPS episodes, can be found over@gembapodcast.com and just look for episode 84, and that'll bring you. Give you all the links to all the other episodes in this series. Okay, enough for me. Let's get to the show. All right, John, well, welcome back to the show. How you been?

Been good. How are you?

I'm doing well, thank you. Thank you. We was telling you that we were at the Lean Management summit. Oh, gosh, I guess it's been maybe about a month ago, I don't know, two, three weeks ago. And our friend Olga, who's, I'm sure listening, was peppering us with pressure to finish this series. She was really liking it. So this one's for you, Olga. Right. I guess.

Hello, Olga. Thanks for the message.

Yeah, right.

We meant to get this one out a bit earlier, but we had some schedule conflicts, slipping a little bit. No worries.

No worries. All right, well, John, let's just jump right in. So just to catch everybody up in the intro, I kind of told everybody where we've been and. And pointed people to the show notes where they can catch up on the previous episode. So that's probably the first bit of advice, if you have. If you're just jumping into this series now, probably a good idea to kind of go back to the. To the start and kind of, I don't know, start from step one, clarifying the problem. But if you've been with us, let's just kind of jump into step seven here, John. And we've been starting everything with a quote. So do you have one for this.

Step Yeah, I do, actually. And now that it's American football season and the Seahawks are kind of four and four, they're not doing so great. I listened to their coach, Pete Carroll, talk about what they're going to do every week, and every time at the end of the game on the interview, he doesn't say, well, here's what we did wrong or anything. He says, I don't know. I don't know. We'll have to look at the tape. We'll have to look at the tape. And he's very consistent about that. And so it's not a quote. That's a small quote from Pete Carroll, but there's a better quote that kind of captures this whole idea. It's from the basketball coach for UCLA, John Wooden, who was legendary. He won 88 consecutive games and has 11 national titles. So he's acknowledged as a great coach. And the quote from him is that, I did everything I could to make sure that all of our players gave everything they had to give, both in practice and in games. The score will take care of itself when you take care of the effort that precedes the score. So if you do everything right up front, the game should be. The result should be good, right? Good process, good result. Well, so, you know, you train the people, you get them, you coach them properly from the sidelines. That's what he says in the quote. But what I. What I like about, you know, 2015 and video everywhere and the fact that we can film everything and review it, and Pete Carroll's quote is, you know, I don't know until I watch the tape, I've got to watch the tape. So the check process in the PDC cycle to me is like watching the tape because you've got. You've done all the preparation. If you followed the steps of practical problem solving to this point, you know, you've gotten the right kind of mindset into the people. So the training, the skill set to do root cause analysis, fishbone diagrams, go see all that stuff. You've got a lean coach or some sort of a facilitator on the sidelines, not giving the answers, but guiding the team and asking the right kind of questions. And that should give you good countermeasures and good results, right? That's the assumption. But here's what we have to check the assumption. We have to watch the tape, play it back, and say, okay, we won the game, we lost the game. Countermeasures did work or didn't work. What happened? What do we have to do? So I'd like to bring those two coaches ideas together and sort of say that's, that's a good way to think about step 7 of the check cycle, the check step of the PDCA cycle. So we've got, you know, we have only one step for one whole quarter of the PDCA cycle. So it's kind of misleading. It looks like, well, you know, we, we do plan that takes about what five steps do. That's one step. And then check is just a small part of it. But no, check is a huge part of it. It's a huge part of it. And this, this is often, often neglected. But yeah, watch the tape. See what you did, learn from it.

So I guess the most common description of step seven is to evaluate process and results. So I guess let's just start there. What's it all about really at a high level.

Yeah, so check process and results or evaluate process and results is what we, what we call it. And then actually it works at several different levels. And sometimes people don't take it, let's say to enough high enough levels or enough levels, enough dimensions, if you will. So most common thing is people just check the results. Results are good, they're happy, they move on to the next, next problem or the next and try the next countermeasure to get even more results. That's sort of Level, Level 0 or Level 1, the most basic level, and it's not, not adequate. Then checking the process on the results. So you check the results, make sure they're good or not, and then check the processes that got you there. Did we follow our plan? What did we learn? Were there any unintended consequences? That's good as well. But that's still very much focused on the problem solving itself. The problem itself, you can say, how did we do with regards to this specific problem? So at a higher level, kind of at a, I guess organizational learning level, there's sort of learning how did you do? Or checking how did you do in a broader sense in problem solving. So not strictly speaking, how did our six steps prior to this go, but everything around it and how our organization set the team up, how we defined the problem to begin with, why this even became a problem solving activity, all of that sort of your assumptions around the problem, problem statements and so forth, things that are sort of deeper in your mind or in the organizational culture than you can always, than you can sometimes gain just by looking at the problem. So there's an interesting, I guess an idea phrase called double loop learning. Double loop learning. And this is created by a professor and consultant named Chris R. Girus. And basically it says that sometimes the way a problem is defined, depending on the kind of assumptions you have, it can complicate the problem or make it difficult to solve the problem. So it really is quite applicable to step seven. I think he arrived at this independently, but he's talking about the check cycle of pdca. But if you think about the check cycle of PDCA and the PDCA loop, that's one loop, right? It's one. Many times people draw the PDCA cycle as just a circle and there's arrows going around and around and that's okay. But that you're still containing your thinking within the problem itself, that you're trying to solve. The double loop idea places the emphasis on at the check cycle you have another loop like a, like a balloon popping out of it. To look at a bigger picture of the wider context of how you, why you selected this problem, who is on the team, what resources did you give the team? You can get to that if you do it really well. If you make it very, let's say natural, you can get to all those questions within the normal, let's say PDCA check questioning. But by calling it double loop, by thinking, by doing the problem solving part of it and doing another level of it, it actually allows you to ask questions that might seem out of scope, but what the key point is that the leadership really needs to step in because the problem solving team may not be able to ask some of those double loop questions.

Always give an example, John, because I'm not sure I'm even like 100% following. I want to make sure that, that I really get it. Give me, give me an example.

Let me think of an example. So a common one that I've seen is people have a problem solving team is given a specific problem, customer's not happy about outages in let's say some software solution or IT service that they're gaining, that they're receiving. So they have to go and solve this problem and they may Google see, they do a root cause analysis, they break down the problem, they find out which regions, which specific services and for what kind of situations they're having the major outages and which customers or which internal customers are most unhappy. They put some countermeasures in place and then at the check process, did that work? Did that not work? What could we do better next time to, let's say reduce similar outages or just catch them earlier or what standards can we put in place for these Specific suppliers so that we're not losing service on whatever it is, cloud computing and so forth. But what's not asked at that point sometimes is why this problem? How do we get to this? How do we get to scoping and solving this problem? Is there an issue with how we're doing outsourcing of these kinds of services? Is there an issue with how we're selecting our vendors? Is there an issue of how these kinds of solutions get, let's say, driven down from the IT organization into the business organization that actually uses them? How good is that communication? So it's looking. What that leads you to is asking bigger systemic questions. I see about how do we get to that problem? How do we get to these issues? What assumptions are we making? We're assuming that this is the right problem. They're assuming that the root cause lies within the performance of this specific vendor, on this specific technology, versus at a deeper level. And sometimes the root cause analysis will get you there if you ask enough whys. But this is also a tricky part where if you ask enough whys, you always get to, well, you know, it's a leadership issue or it's a management decision that got us here somewhere deep down the chain. And you can't. But that's not an actionable root cause. We talked in step four about actionable root causes. The point of root cause analysis is not to find necessarily the true root cause, but the actionable root cause for countermeasure selection purposes. Because the true root cause may be out of your scope, something you can't really do anything about. So this double loop learning part of it helps you uncover assumptions you have about your thinking. So how you're choosing, how you're, how you're assigning responsibility, how you're accepting problems. It's not just, that's just one example. It can do a lot of different things. And I think the important point really is just to think of it, to think outside of the PDCA loop.

Yeah, well, I like the analogy of an external bubble popping off to the side. I think that's helpful.

Yeah, I think that's the best way to think of this. The key, I think is again, checking your assumptions, your biases, your cognitive biases, your prejudices, your thinking. What you may not necessarily do, if all you're checking is how did we do on this specific problem? Did we. And you could find those kinds of biases in terms of, well, we made an assumption here on this root cause or on this countermeasure that this would work. But that doesn't tell you necessarily something larger about how the organization thinks or makes decisions. It could, but it doesn't necessarily. It could be too focused on a specific problem to teach you more than more about behaviors and things. It might just teach you about specific, let's say, knowledge issues you had on a technical aspect. So, yeah, that's pretty interesting, I think.

Okay, so, all right, so that's kind of what, what it is and what this step's all about. But I mean, why is it so important to check? I mean, because it's easy to. Well, I'd say it's, it's fun, right, to do. Right. Not even so fun to plan. But once you've done done something and you feel exhilarated, you know, checking it is not sexy.

Right.

It's not always.

Yeah, yeah. Problem solving is done when you've gone through steps one through six, you've put countermeasures through and you're having a celebration. So now you have to bring the team back together or you've got to bring the stakeholders together and sort of drag them through the mud of what did you do right and wrong. And it's probably been a tiring, tense process all along. So why, you know, why wash? Why bring all this dirty laundry up again? Right? Why, why go through all these issues again? Yeah, that's a, that's a good question. I think partly it's that, that the value of double loop learning is organizational learning and getting better at problem solving. If you want, if you want to do problem solving well, you have to get better at it because you're not going to be ever good enough to solve future challenges and you want people to learn about it and identify your blind spot. So I think that's from a larger perspective, but even from, even from a problem focused point of view, specific to. Why would that benefit? If you say, yeah, I get that, John, we have to be better as an organization, but my scope isn't organizational learning. That's not what I'm tasked to do. I'm tasked to go lead teams, solve problems, repeat. So don't force me into trying to change the whole organization, boil the ocean. So that from that point of view, why do this? Well, I think the key thing is that good process, good results mantra that we have and these sometimes gets forgotten. If we have good results, we figure that it's a good people who are watching you, the leaders, the sponsors are going to say, great job, good work, let's have more of that. And they may not ask deep questions or Challenging questions about the process. They're happy with the results. But what can happen is that it could be improvement that comes from chance, comes from regression to the mean. It could be that some other countermeasures that were in progress already before the problem solving have finally kicked in. It could be Hawthorne effect, where now people are actually paying attention to it. So small, minuscule, hardly detectable losses are being caught because people are just sharper, paying more attention. There's a momentary bump in performance. All these kind of things can lead you to thinking that you had a good, you made a good effort at it. And this is where I can test your Latin. I know Latin is spoken in your home a little bit. At least it was a few years ago when I visited home.

Oh gosh, I gotta get my kids on here. If you want to ask a Latin question.

Not me. Yeah. So there's something called the post hoc fallacy. Post hoc is from a phrase, post hoc ergo propter. So can you tell me what that means? Post hoc ergo propter?

No, I could Google.

Means after this, therefore, because of this Latino is much more concise. But what that means is you're essentially incorrectly jumping to a conclusion and saying that because this, because of this, therefore, that you're making a false cause and cause and effect connection. And what's an example of that would be, you know, you went to the witch doctor, the witch doctor shook a rattle, blew some smoke at you and you got better. So that's. There's no, let's say, scientifically verifiable evidence that says cause and effect. But after the, after you went to the witch doctor, you got better. Therefore it was because of the witch doctor. Yeah, right. And it could just be that colds get better. You know, it could just be a number of things. It could have been psycho, psychosomatic. It could have been.

Or you walked outside and got vitamin D and you know.

Yeah, yeah, yeah. So it's really this post hoc fallacy that a lot of organizations, a lot of problem solving teams can be at risk of committing that the result was good. Therefore our problem solving efforts must have been good. Where a lot of problem solving problems, let's say problem solving documents, A3 documents will have a well fleshed out background section, current condition, maybe a mediocre problem statement, and then a very poor root cause analysis and then a really robust set of countermeasures. And then they go do and they get some results, but they're not sustainable. And what happens is people sort of skim through or Skip through the root cause analysis part because in their mind they already have a pretty good idea of what they're going to do anyway.

Yeah.

And they're putting it in an A3 because it's a lean thing to do.

Yeah.

You know, that happens a lot, I see that a lot. And what you end up with is the post hoc fallacy, which is, ah, these things we did, they worked. Therefore we must have addressed the causes. Now they might, they're not even thinking that way, but they're, they're satisfied with it. Yeah. Where if you really drilled into the root causes, spent more time there. So you shouldn't have to. This, this shouldn't happen. This issue shouldn't happen if you're doing steps one through four, five, six properly. But the check here is to make sure that in your haste and enthusiasm to get the problem solved, you didn't trick yourself into sort of drawing a fishbone, putting things in that cause and effect diagram, putting things in a, in a selection matrix and saying, yeah, I think we got it. I think we've managed to justify our pre existing countermeasures or the things that we know we're doing. You know, we're putting a line in place, we know we're doing that. So which counter, which root causes will we be addressing by doing that? You know, you see that sort of backwards process as well, which sometimes you have to do. Sometimes it's a proposal, it's a business proposal. We're going to start up this new product, we need a new line. We think it's going to address these root causes. But if you don't check it, if you don't go back and say, how did, what were our assumptions, how did we actually address those, those underlying causes? And you end up with this, this Latin phrase that I'm so fond of.

Well, what like. So let me just ask a kind of a contrarian question. What if witch doctoring was real and it worked and we went to the witch doctor and they blew smoke at us and we got better because witch doctoring really was the truth. It's real. I mean, I don't believe it is. But I'm just saying, hypothetically, how does that work into the. I mean, how do you know? Like, I got better, right? I got better. So how do I know it was not witch doctoring? How do you prove that it wasn't witch doctoring that made me better?

Well, I think it's, that's where science comes in that, that I think there are aspects of witch doctoring that that work? Yeah.

And I don't, I don't want to get into witch doctor.

It's just an example which doctoring is basically in folk medicine, which doctoring, all these things are basically things that are, are pre scientific remedies. Right. And some of them, some of these remedies that we laugh at, whether it's Chinese medicine or Amazonian ceremonies with vines that make you hallucinate and then work out all your problems and somehow rearrange your brain chemistry, science will find that a chunk of these are real, but a chunk of them aren't real. And laying on hands does seem to have curative effects to some people, but we haven't scientifically shown double blind tests and null hypothesis and all that. That hasn't happened in a way that the scientific community can replicate in a medical controlled environment. Right?

Yes.

So that's the problem is if you say, well, it's good enough for me, my faith is strong, I put it in God's hands, then you're leaving a lot up to you might call it chance, you might call it faith, but what you're not doing is resting it on evidence. And in business, when we're talking about people's livelihoods and real consequential matters, paycheck next month, return to shareholders, you can't afford to do that for very long. So you have to look for evidence and say, okay, this worked. We're not quite sure why it worked. So you have to set up an experiment then and say, let's look at the null hypothesis and try to disprove the opposite. So I think you can't dismiss out of hand something that seems to work that you don't understand. And you also can't accept something on blind faith that seems to work without and remain and remain honest as a science or member of modern society. I think that's the key, is that there's both of those things we have to even lean. You have to go in there with a certain amount of faith that I don't have scientific evidence that this works. I have a lot of anecdotal evidence that it does work. Some people tell me only 10% of lean implementations succeed. I haven't seen the data. I've never seen evidence of that. It's always on some survey that was done by somebody some years ago. I've seen lots of failures and lots of successes. So we're still really in a witch doctor phase of in many ways where we know some things. You know, the smoke that they're blowing at you that Contains some good chemicals. And that rattle, they're rattling at you, distracts you from your own whatever. And then they give you some crushed up herb that contains some antibiotics. But the rest of it is like, well, why do we need to, why do we need to get dipped in mud and dance in a circle for three days? Well, we don't understand that part yet.

Just go do 5s and it'll be okay.

Right, Exactly. Map all your value streams and everything's good.

Make value flow. Right. Not making fun of our own product here. No. So I guess the next question I have is, you know, we've recently gone through some practical problem solving here at Gambit Academy, trying to solve some internal challenges that we have. And we're kind of at the phase now where we are really evaluating process and results. And it's, it's one of those sayings of how long do you evaluate? Right. Like that's, that's kind of where we're at right now is you make some, you make some changes to the process, you think you really uncover some potential root causes and we try to counter them. But now it's almost a wait and see, isn't it? When you do some operational changes, you won't know right away if it's, especially if it's more of a lagging type indicator that you might be attempting to improve.

Right, right, that's a good point. So I think anytime you make a change or make an improvement, you want to update the standard. And that standard can be, you know, a standard method, it can be standard specs, it can be a process. So once you've got a new process saying, before we did it this way, now we're doing it that way, you document it. And then ideally you would have ways of checking both process and results. And the closest you can do to that on an operational day to day basis is having a combination of KPIs key performance indicators. So leading and lagging process results, those kinds of things. Right. So leading indicators are showing you how your process is performing. Lagging indicators are results because they come later, they lag. And by the time you get the results, you can't do much about it because the process is the process that you followed a month ago. So whether it's sales or product development.

Or marketing or on time delivery, anything.

Like that, any of those things. It's how is the process functioning today? Visibly on the shop floor or in the office? What can you measure in a snapshot? Now that will give you an indication that if we continue in this way the result is going to be good or bad. So I think that's the key thing is to set good because most organizations have really fairly good results metrics. You know, sales, how many inquiries you get from your marketing efforts, what kind of levels of skills and skill development you have with your people or number of people you manage to hire and train versus your target. But the processes to get there are what people tend to, organizations tend to kind of gloss over or not put as much effort into. So I think any improvement has to result in a standard. And that standard should, you know, if you want to manage it and we should want to manage it. If you want to manage performance, it should have a combination of leading and lagging indicators. And that's also where your step seven check comes in. Because you can go back to that and say we wanted to see how the result of the problem solving would affect the problem. Did we solve the problem by how much did we reduce the on time delivery problem and did we follow the process, the process indicators or the leading indicators are, did we stay on track with our project plan? Did we get the number of inputs and feedback comments from shop floor people, from management, from engineers that we hope to get? Did we get customer feedback during the process? Whatever you decide should be the in process indicators of success for the project. Right. Because people know when a, when a problem solving activity is going well or isn't going well. People are not showing up to the meetings, meetings are going late, action items aren't getting done. These are all indicators of something's not going to work, something's not right. It's a process metric. And so even if the countermeasures are good, you may not be implementing them on time or sufficiently.

Yeah.

To, or you know, the root causes may shift by the time you get those put in place. So these are the kinds of things you can set up and say, did we follow a good process to get there? If you didn't do all that, if it was a horrible process and somehow the problem went away, you might say, oh, that was rough, but we got it done well, maybe it was just reversion to the mean, it was rough, you didn't quite get it done on time, you did all your actions, it didn't really matter and now it's going to come back and bite you for a different reason later on because you really haven't got to the root of it. So I think that's the key, is to have those two kinds of KPIs and keep an eye on them.

Got it, Got it. All right, so the next kind of series of questions I have for you, it's kind of two part is, we've talked about what it is, why it's important. Now I'm curious if you can maybe offer some practical tips for how to go about this step. And then the second part to that is, what can go wrong?

Okay. How to go about it? Well, I think human beings have to get together in a sort of a safe, open environment, discuss the history, the facts. You know, what did we do? How did we do it? You know, write that down, reflect on it. I think that's the raw mechanics of it. It's kind of a mini HANSEI session, if you will, a reflection session. Specific things to look for. And you want to look for success factors. What did we do that seemed to help us get the results we wanted? Again, it's looking for the cause and effect and seeing if you understand how you got the results. Can you make that? Can you do the therefore test backwards? Again, from. Yeah, from. Here's the result. The result was good. It was good because therefore. And back to your root cause. Does it link logically through your countermeasure activities, Any adjustments that you made during the process? What did you do to get failing efforts back on track? That's always good to look at. So look for any wins, any successes. I think that's for some organizations, starting with the positives or staying focused on the positives and then looking for the contrary is also useful, not just to look at what didn't go right. So I think that's one of the key parts of it. A metaphor that I, like, I use a lot in a lot of different ways in terms of organizational change. And lean is just think of it as a plant that's growing. You know, what's the soil that helped the seed grow? Did you have enough rain? Did you have enough water? How fertile was the soil, and did you take care of it? Or is it a weed that just grew up because it will grow up anywhere? Or is it something specifically that you planted that grew up in the way that you hoped it would? So can you make that kind of connection? I think that's. That's one thing looking for unintended consequences, that's another thing that's a very useful activity. Did you have any bad effects downstream or unintended effects that you had to catch up and recover, either in terms of safety issues, that if you didn't create it, you might have exposed it or made it more visible, more evident, something that you have to, you see that a lot when you rearrange a production area and you think it's going to be more productive than suddenly something that wasn't an issue becomes an issue where there is a danger or there's a lifting hazard or somebody that's been sitting for eight hours a day now has to stand and walk. And if they're overweight or if they're not, if the equipment isn't, let's say the workstations aren't designed for good posture, then that in days or weeks can lead to injury. Those kind of unintended things, you have to look for those during the check process. And assuming that the problem solving took place over a period of days and weeks, this will have happened. If it was a quick resolution and these things are yet to be seen, then it has to be kind of in the follow up and monitoring. But the same thing for quality and productivity and cost, you know, making sure that those things met your targets. And if not, was it poor assumptions or was it poor execution? You know, those kind of questions need to happen. And yeah, if the results weren't good, so those are looking at the good things and unintended consequences from the good things and then looking at results that were poor, didn't meet the target. You just have to track back from step six back to step one, just sort of ask the questions. Did we have good sets of countermeasures? Did we execute them all?

Did we break the problem down properly?

Did we break the problem down? How do we come up with countermeasures? Did we break the problem down? Did we do good root cause analysis? Did we have a target that was correct, that was factual and specific? Was the problem, initial problem statement focused on the right area? Was it too vague? Was it too broad? Was it in the wrong area? Things like that?

Yeah. I do think you mentioned set a target. I mean, I do think that there's an obvious strong correlation or maybe not correlation, but interaction, if you will, between step three and step seven. Right. Set a target and evaluate the process and results. If you, you know, if you didn't do a good job setting a realistic target, then you may feel as if you failed in step seven when in fact, you know, maybe, maybe you just, you got it wrong at step three.

Yeah, yeah. So I think that's the, that's the key point is that the practical problem solving is not so much about. Well, it's, it's maybe half about getting the problem solved and half about getting better at.

Yeah.

Problem solving because if you want to just get the problem solved, you can. If you provided you have resources, you can throw money at it and resources at it and have the illusion of solving a problem more quickly. What happens, unfortunately, is you have a period of time and a leadership change, and then some financial person says, well, we don't need that in place anymore. That seems like an excess. I don't know why we have that check there or that person there or that additional process. You take it away and then you expose the root cause again because you never really. It's like reducing buffer inventory. Our counter manager is we'll put some buffer inventory there and then we'll have on time. Well, some other consultant comes along and says, you don't need that inventory. Well, if there's not a good A3 document showing why that was there and what it's covering up, then suddenly you've got delivery problems again or quality problems again, or you uncover root causes. So it's the practical problem solving aspect. Half of it's got to be learning about your organization, learning about getting better at problem solving, and then in small increments, solving the problem. So that's what the failure you could say of problem solving is, not doing step seven. Anything you learn in step seven is, is good, right? Because it's, it's all about learning. Is if you learn that you are totally screwed up, that's good news because now at least you learn that. Might have known that before, but at least you've exposed that in a. Yeah, you've exposed that in a positive structured PDCA environment versus just everybody having to deal with it and live with it. So I think that you can really never fail at step seven if you, if you do it and if you uncover or something.

I keep, I keep thinking about your analogy earlier when you're talking about Pete Carroll. And so I'm imagining a football team, you know, watching tape of a, Of a play, right? In the play, let's say was the target was to gain 7 yards, right? That was the, that. That's really the. What they thought could happen if they executed it properly and the play actually lost him three yards. And so I imagine them sitting back and saying, okay, here's exactly the schematics of how the play was, was supposed to be run. They can watch it back and forth, rewind, go forward and so forth. And so they're watching every, every single move. But what happens if maybe everybody did exactly what they thought, right, should have been done, but it still didn't work because the defense countered it somehow that they didn't anticipate. So I, that that's to me the beauty in the, I don't know the depth, if you will of problem solving is even when you do exactly the right things per your plan, it still may not work because you didn't understand your opponent entropy or whatever it might be. Right.

No plan survives beyond contact with the enemy. So you can't go in with a perfect plan. You've got to go in with a working hypothesis and saying when we encounter a situation that requires us to adapt, the quarterback or whoever on the line needs to. The good quarterbacks will read and make adjustments on the spot saying okay, you guys go this way and go that way, you know, because I see they're coming, they're going to blitz us and we won't have the time we thought we will to. Yeah, to make the hole in the line or whatever. It's going to change this up a little bit. The really good teams are able to do that and the ones that don't think and don't do a quick on the spot check and adjust in those 10, 20 seconds when they have on the field before they start to play, they're the ones that get creamed. So I think that's, that's part of that. Must be part of that watching the tape to say, okay, next time you see that, what will you do differently? Yeah, or a quarterback or center or you know, whoever is calling the plays on either side. When we see that shape, when we see that formation, when we see that guy doing this, we know a trick plays coming or we know they're going to run up the middle. So I think that type of.

Or even if they, even if they break it for, you know, lynch runs for 70 yards for a touchdown, they may say, you know what, we got extremely lucky and here's why. You know that knucklehead middle linebacker totally blew it. You know, if they would have just done their job, they would have gotten us for a three yard. So that's another one where don't celebrate that success without truly understanding that you are lucky. And that's why.

Yeah, I think good coaches really look at calls that went their way, didn't go their way or things that the other team did to screw up that helped us, helped us help the team win. You know, you take advantage of the opponent's mistake and there's a little bit less of that in problem solving because you're not. There's no active opponent in many cases, unless you're talking about Sort of a business business, let's say competition, going after the competitors market, that kind of a thing. But if you're talking about a non human, non intelligent process that you're trying to understand and fix and so forth.

So John, what do you think Pete Carroll and his coaching staff, how did they do step seven at the end of last year's Super Bowl?

Yeah, well, don't get me started because I think I have my personal theory on why they're struggling this year and I think it's related to that last play of the game. But yeah, I think we're going to lose the people that are not, not football fans.

I think there's a lot, I mean there's a lot of foot. We mean Mark Graben actually talked about it on a previous, previous episode, but that was a perfect example. It's just so if people who are listening don't know about American football. It was a Super bowl and Seattle was about to score to win the game, right? They would have won and they have the best running back in the National Football League. This big huge man who could basically bust through a brick wall and they didn't give him the ball. Instead they threw a pass and it was intercepted and the other team won the game. And so everybody was upset, right, with, with Seattle or not everybody, but a lot of people thought they should.

People were sad. It was a sad month of February here in Seattle for a lot of people. But, but I speculate as to why they didn't give it to lynch to run. But when I, when I saw that they had made a trade of their center, Max Unger and the first round draft pick for Jimmy Graham, who is a huge 6 foot 7, 250 pound tight end, you know, from, from the New Orleans Saints, I thought well why are they doing that? Why? They're not a passing team. And I thought well this must be. They looked at that tape and it haunted them and they said if we'd only had a 6 foot 7 guy who could walk in, turn around, stand up, reach up, nobody can grab the ball, we would have won that. That's kind of what I think because he doesn't really fit into their playing style. And also, and it's. This again is sort of a post hoc fallacy because their offensive line has been terr for the first five or six games. Quarterback's been sacked 30 odd times because they've had new people, they lost their center and it's just, it's just been a disaster. And why did they lose and why did they have a weaker offensive line? Well, one thing is they, they couldn't, they couldn't keep their center who was All Pro, and then they had, I think they lost somebody else. But, you know, that's, that's all sort of post hoc. We can't say for sure because there's a number of other things that it could have gone in either direction in any of those games. They were very close games. But if you, if you look at the performance of the team, what's killed them a lot of ways is that offensive line hasn't been able to, to give Russell Wilson enough time, the quarterback to throw it or the running back to, to actually make it through the line. So, yeah, that could have been, that could have been the reaction of some people saying, gee, if we only had a big, tall guy to catch a ball, you know, we wouldn't have, we wouldn't have lost the super bowl and we'll be in the same position next year. Yeah, that's that thought. They crossed my mind, but I don't, I don't linger on it. I mean, I, I wish them well in all their decisions. I just hope they have a good, good process to get to them.

Ah, you've been to two Super Bowls the last few years. Give them, Give me a break. You could be a Cowboys fan or something like that.

Yeah, I like the sport. It's a brutal sport, but it's also very beautiful in some ways.

Yeah, yeah, yeah. All right. Well, John, let's give a sneak peek to, to the last part of this PPS series. We're going to talk about step eight, which is standardizing success. So give us a sneak peek of what we're going to be talking about in that episode.

Yeah. So last step really is a number of different things. It's the act or adjust step on the PDCA cycle. And a couple of the key actions are making sure that you've captured the learnings from step seven, and you're going to take those and build them back into your organization's strengths. So whatever your playbook is, whatever your, your base of wisdom and knowledge is, however you capture and manage knowledge, you want to, ideally in some documented format, but how you do problem solving, how you select problems, how you make, make decisions around which way, where you're going to invest in future, future improvements and so forth in your organization, what, whatever you can learn from the, the problem solving process, you want to put that in place. The Yoko 10 process, the horizontal deployment process. That's a key aspect where you take successes and rapidly try to share them with other parts of the organization who can hopefully copy paste them to a close degree or if not say how would I do something similar in my organization? So sort of getting a knock on effect that way by allowing other parts of the organization to learn and capture similar learnings.

So a question that I'm going to ask you in that episode, and I really do want to hear your thoughts on it, is and I don't want you to, don't blurt anything out right now, you'll spoil it. But I want to talk about the difference between ACT and adjust. If there is a difference and that terminology, pdca, the A, sometimes it's act, sometimes it's adjust. I want to explore is there a difference? If so, what is it?

Okay, sure. Let's discuss.

All right, well, any final words of wisdom as it relates to Step seven, John?

Well, they're not my words, but there's another quote that I think is appropriate. I think this is from the, I think it's from the Toyota Way book, but it's by Bruce Brownlee who was general manager at the Toyota Technical Center. And the quote that I have is it is really being honest about your own weaknesses. If you're talking about only your strengths, you're bragging. If you're recognizing your weaknesses with sincerity, it's a high level of strength, but it doesn't end there. How do you change to overcome those weaknesses? That is at the root of Kaizen, continuous improvement. If you do not understand Hansei, then Kaizen is just continuous improvement. Hansei is the incubator for change, that whole process. So I thought that was pretty, pretty useful. And it kind of goes back to the beginning idea. It's not how you make adjustments to get the results during the game, but it's how you make adjustments to overall, how your, how you're managing the team, how you're managing the whole season, how you're managing the whole franchise. Go back to the sports analogy and that requires strength and being able to look at your weaknesses and humility. Right? Yeah. And the owners and coaches that are not humble are the ones that continue to make ego driven decisions and struggle. So unless they get lucky.

Yeah. All right, well, fantastic, John. It's awesome. Thanks again, Olga. Hopefully that was good. Worth the work.

Wait, hopefully it's good. Yeah.

All right, well, I look forward to talking with you about Step eight. I guess we'll try to record that here in the next few weeks and maybe we'll get that out in early December or something. Like that.

Sounds good.

All right, John, take care.

Talk to you soon.

Ron, thanks for listening to the Gemba Academy podcast. Now it's time to take a free, no strings attached, fully functional test drive of Gemba Academy's School of Lean and Six Sigma. Over at Gembaacademy.com gain immediate access to more than 500 Lean and Six Sigma training videos free of charge@gembaacademy.com.