Defects & Overprocessing | Flow vs Friction Ch. 1

Speaker A: Welcome to leanverse, where Lean thinking meets modern life. I'm, um, your host, Bernadette Hill, and

Speaker B: I'm joined by my co host, Tatiana Sell.

Speaker A: We're two lean Six Sigma black belts who spent our careers helping people and organizations simplify, improve and thrive.

Speaker B: Our goal at leanverse is to ignite

Speaker A: the desire for transformation and provide the tools to turn intention into action. Hi, welcome to leanverse, the new podcast where we explore Lean thinking in modern life.

Speaker B: My name is Bernadette Hill and I'm

Speaker A: a Lean Six Sigma black belt and a continuous improvement professional.

Speaker C: Hi everyone. I'm Tatiana Sau, co host of the leanverse with Bernadette Hill. I'm a business operations and continuous improvement

Speaker B: leader and together we geek out about all things Lean.

Speaker C: Geek out on Lean Six Sigma methodology.

Speaker A: I am joined by my co host, Tatiana Sell.

Speaker C: Let's dig in

Speaker A: for our new leanverse series. Tatiana and I are exploring a simple but powerful theme. Flow versus friction. We all get the same 24 hours in a day. We can't manufacture more time, but we can reduce the friction inside the systems that shape how that time gets used. Over the next four episodes, we'll walk through the eight wastes of Lean, not as definitions to memorize, but as patterns to notice. Because friction rarely shows up alone, one form of waste almost always creates the conditions for another. And today we're starting with two wastes that quietly reinforce each other in almost every defects and over processing. All right.

Speaker B: Hi, Tatiana.

Speaker C: Uh, hey, Bernadette. How you doing? Good.

Speaker B: How was your run this morning?

Speaker C: It was awesome. Thanks for asking.

Speaker B: You're welcome. I know. We'll talk a little bit about that later. Before we get into today's episode, I just wanted to set the framework around our February series. It's about flow and friction. And in Lean, one of the most useful ways to understand flow and friction is really around the concept of waste. Not the waste that you take out in your bin once a week and put on the curve. But, uh, this idea of waste came from Toyota back in the 1950s, um, when leaders were closely observing how work actually got done, uh, at the Gemba, or the place where work happens. And what the leaders noticed was that, um, there were recurring patterns where lots of effort was consumed but no value was created at all from the perspective of the customer. And from those observations came this idea of the original seven wastes. There are defects. Overproduction, waiting, transportation, inventory motion, and over processing, sometimes called extra processing. And later, practitioners added an eighth waste, non utilized talent to reflect how often people's skills and ideas are underutilized.

Speaker A: Mhm.

Speaker C: Well, memorizing the list is really not the point here. What matters is the idea that waste is friction and friction is low. The flow of value through a process. Waste never shows up alone. This is another thing to note. One type of waste ended up kind of creating the condition for others. That's why friction and waste compound.

Speaker B: That's exactly right. Um, this is also why waste matters so much across industries. Uh, research consistently shows that only a small portion of work, often around 5%, actually adds customer value. And the rest of the is friction. When organizations improve flow, the impact is measurable. Teams see double digit reduction in delays, rework and wasted effort. Not because people are working harder, but because the system stops getting in the way.

Speaker C: There you go Bernard. That's why in this series we are pairing the ways together. So we have four episodes and we'll pair two of them in each episode. We want to see really the cause and effect relationship of um, two ways together. Because remember that we mentioned that they kind of connect to each other, they compound. So that's the idea. Right. So we can see how they play out in the real world.

Speaker B: Exactly. Today we're starting out with defects and over processing because those two wastes like to hang out together and cause a lot of trouble. When did these two wastes show, uh, up in your life?

Speaker C: Okay, so let me start with the true story. I hope you like it. So I joined this uh, software development company. I was responsible for managing this multimillion dollar budget. Pretty much the development cost was the second largest expense that we had. What I noticed was at first that the engineering team was outsourced offshore, um, basically in two countries, nine hours apart. Huge difference of time zones. We had a front end and the back end team. They were doing kind of a sequential work. Right. One team would finish one thing, then the other team would, would start the other. The classical upstream, downstream type of flow. But they were almost kind of a never overlapping in time because of the challenges with the time zone. Another thing that I noticed right when I joined is that the sprint velocity was kind of low. Uh, we work was pretty much constant. And the hours from this development team, because they were offshore, they were contractors and they were just burning super fast. So you know, hours equals to cash, which is a financial impact in the budget.

Speaker B: Well, so at that point were you thinking it was a skill problem or a process problem?

Speaker C: That's a good point. Initially I really had no idea. So to learn I ended up investing some type time in virtual Gamble walks, right? Just observing the teams, the process, what was going on in current state. The first thing that I noticed to your point is that there was not really skill or capability issue that was clear to me. However, I noticed one thing that I touched a little bit when I was giving the introduction. Features were not delivered right at first time. A lot of the rework that was defect for sure. The fascinating thing that I noticed during the gamma walks was this. The frontline teams, they were building based on one interpretation, the back end teams based on another interpretation. When the pieces of ah, features, the software, the work were coming together, the assumptions clashed, right? That's the reason why we were having so much rework. The root cause, guess what, Ambiguity, the tickets in that case we call stories in software development, they were really not clear on the problem statement, success criteria, the scope or even definition of done. So the requirements that we were seeing in those tickets, the stories, they were vary a lot in quality and detail to cope with that problem. Over processing, right? Took over the product team, the qa, the engineering, what they did, they start to do more reviews, more communications, a lot of handoffs. The goal was initially to prevent the defects, all the rework. But instead the process became heavier, slower, more expensive. Defects were still surfacing and the ambiguity never solved.

Speaker B: Oh yeah, I found this pops up all the time when clarity is missing. Defects show up, um, because people don't know that they're making mistakes, right? And instead of fixing that clarity or that root cause, um, organizations often respond by adding extra stuff steps. And that's how over processing sneaks in and elongates the process, right? Uh, not because anybody asked for it, but because, because something earlier was unclear. We see this in higher education all the time. Uh, there are extra, uh, when mistakes happen, we have extra reviews, extra approvals. And that again, elongates the process just like your story. So how are you dealing with these wastes, Tatiana?

Speaker C: Yeah, so the first thing that I did was, uh, hey, I need to work with the product team, right? We standardize the ticket structure. As I mentioned before, it had that variance on how the requirements was, you know, they were um, given to the development team. The very first thing was, hey, we really needed to have a very clear definition of problem. The success criteria, the definition of done. We were very intentional as well about surfacing the blockers during the standups that we had with the teams. And especially when we had this overlapping of hours between them. We were being like, hey, we need to protect this so they can solve any questions or doubts that they have real time. That reduced a lot of waiting, which was good, um, because the assumptions were clarified earlier and also actually reduced a lot of, you know, inventories of, um, story. Because a lot of the unfinished work, unfinished code was not piling up between the teams anymore. The good thing is that within the first month since we implemented this new standardized way of working with the tickets, the defects that were especially the one driven by the lack of clarity, dropped by 38%.

Speaker B: 38% in just the first month. Wow. Clarity makes a difference, doesn't it?

Speaker C: Yeah, it does.

Speaker B: So just in that story you touched on, you know, multiple ways. You know, I heard defects over processing, weighting and inventory. And that alone tells you something about how important and how much waste compounds. I often say waste begets waste. Right. But for this episode, we're just really focused on those two that we talked about.

Speaker C: Okay.

Speaker B: So a defect is anything that does not meet the customer requirements, including any deviations from agreed upon standards. It's when the output is not what the customer expected. So think about it like running your dishwasher. Um, if you run a cycle in your dishwasher and the dishes come out dirty, the effort happened, but the outcome did not meet the expectation. You still have dirty dishes.

Speaker C: I do love this example. Thank you for bringing it. But now linking to our story. Imagine that the product team was really the customer. In this case, the engineer was the one delivering the work. And guess what? It was deviating from the expectations from the product team. The code that they were delivering technically worked, but that was delivered with defect because was not following the, um, expectations. People didn't fail. It was just the way that things were organized that made them not be according to the spec. Hence we got the defects.

Speaker B: Yeah, well, nobody wants to do extra work. Nobody wants to do rework after they've already done it, you know, tried to do it the first time. And over processing really is doing more work, more steps or being more precise than the customer actually required. So if we go back to that dishwasher example, right. If we are pre washing dishes or having to rewash dishes because we don't trust that the dishwasher is going to wash the dishes to our standard, right. Um, then the extra effort really isn't about value to us. That's not, that's not bringing me any value. It's just compensating for the dirty dishes.

Speaker C: There you go, there you go. Well, linking again back to the story. In that case, the unclear requirement created the uncertainty. And to compensate to your point, teams added more Reviews, more handoffs, and, um, more communication. The customer didn't ask for all of that formal process, but those extra steps existed to manage the uncertainty that was created earlier. And again, classical way to describe over processing, right?

Speaker B: And then again, it matters because once we, uh, create the defect, it doesn't just mean something went wrong. Defects lead to rework and that leads to delays. And that often will lead to a loss of trust from the customer side to, you know, the business side. Um, it also, over processing also increases costs. Anytime we have to do it again, it's going to cost twice as much. It consumes effort, it consumes resources. And the customer never asked for that, any of that. Right? So together, both defects and over processing, these wastes reinforce each other. Defects create the uncertainty, and then over processing is the reaction to that uncertainty. And the heavier this process becomes, the harder it is to maintain flow. The whole reason we started talking about that, this at the beginning, right?

Speaker C: Exactly. What started as a clarity issue becomes a cost issue, a split speed issue, and a press issue. This is not really about working hard or adding controls. It's about removing the conditions that cause defects in the first place. So over processing never becomes necessary.

Speaker B: Not all the time. A lean tool is necessary as well. There are lots of lean tools, lots of different lean tools that can help. But the tools themselves are not the point. The most powerful thing anybody can really do is observe the process. Just like you were talking about at the beginning of your story, right? You went out there, you just wanted to see what's going on, um, ask questions to understand, you know, we're not judging the process, we're not judging the people. We're just finding out where the waste is. Right? We're just discovering where, uh, that is. So for defects, we're going to focus on the prevention side. We're not, we're going to try to prevent the defects so we don't have to do the rework that the over processing causes. So if we're again going back to that dishwasher example, if we know, um, the right stacking pattern for our dishes, what is the right detergent to use? How much should we use? Maybe we can reduce the impact of dirty dishes or reduce the, uh, possibility of the dirty dishes coming out of a clean dish cycle. If we understand how to eliminate the defects in the first place.

Speaker C: There you go. If I would. Everything that you just said, right? It's all about expectations. So when expectations, they are explicitly right. We know how to load the dishwasher and the ambiguity is reduced. Guess What? The errors become less likely to happen. So simple mistake proving and targeted training at the points where the defects actually occur are far more effective than just spreading crazy controls everywhere for over processing. Right. But let's start by understanding what the customer truly needs. That's where everything starts. And no more than that. That's a good way to start, uh, reducing the over processing extra steps that exist only to catch errors that are created early. Just. They should be questioned. Honestly, redesign the process so those errors are less likely to happen first place. Right? It's not that we need more qa. We just need to make sure that errors are not happening, period. The goal is not perfection. Again, we talk about this all the time. The goal, to the point of the whole series is smoother flow with less compensation and less rework.

Speaker B: Exactly. And that's exactly what you found with your software development story that first month of just, you know, understanding where the friction was coming from, that waste was coming from. You were able to, you know, your team, the team was able to drop those defects 38% just from understanding that piece. Right. So let's kind of. Let's recap. That's very powerful. Defects are failures to meet customer expectations, even when you're the customer. Over processing is the extra work we add. When those defects keep showing up, we're rewashing and pre washing our dishes before they go in the dishwasher. Right.

Speaker A: Yeah.

Speaker C: So thank you for the recap. And now the reflection, uh, to sit with everyone that it's listening. Where have you added extra steps to manage uncertainty because something wasn't clear?

Speaker B: Join us next time in the February Flow and Friction series when we talk about overproduction and inventory. Two wastes that love to hang out together and cause even more trouble.

Speaker C: See you next time on Ling Verse. See ya.

Speaker A: As we close out today's episode, here's the pattern to remember. When clarity is missing, defects appear. When defects appear, we often respond by adding process. And that's how over processing becomes normal.

Speaker B: If you're seeing extra steps in your

Speaker A: work right now, pause and ask, is this process creating value or compensating for something that was never made clear? In the next episode of the Flow and Friction series, we'll look at overproduction and inventory. Two wastes that create friction long before we feel it. And if this way of thinking resonates with you, the Lean Mastery makerspace is now live inside the Savage Simplicity ecosystem. It's a free space designed for people who want to practice lean thinking beyond the tools as a way to see systems clearly reduce fruit friction intentionally and improve without adding noise. You can explore it at savage simplicity ecosystem on circle. So no pressure, just an invitation to think differently. Because life is hard. Why not make it simpler? Leanverse is hosted by Bernadette Hill and Tatiana Sell. This episode was programmed and written by Tatiana Sell Produced and edited by Bernadette Hill.

Speaker C: I was blamed for results.

Speaker B: Today we're starting out with defects and over processing. Uh, it's with. Sorry. So, uh, a defect is anything that does not meet the customer requirements, including deviations from agreed upon. I'm going to pause here.