Quality Quote

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely May Be Agile with your hosts Peter Maddison and Dave Sharrock.

How are you today, Dave? I'm doing very well. I've been on the road finally after many, many months or a couple of years actually of not really being on the road. So exciting week for me.

That's uh that's excellent. It's nice to get out of the house, get go places, see new sites or old sites.

What's interesting is all the things that you'd forgotten, the good things and the bad things of being on the road. But anyway, that's not necessarily a topic for today. What do we want to talk about today?

Well, I came across a quote, and it's an old quote, um, but I thought it was something worth exploring because of the of the language and the way that it's stated. And it's by a gentleman called Tom DiMarco, who was a uh software engineer, who's I mean, he's still around and uh but in the like 70s and 80s. Uh and the quote goes like this. So I'll just be out quality takes time and reduces quantity. So it makes you, in a sense, less efficient. The efficiency optimized organization recognizes quality as its enemy. That's why many corporate quality programs are really quality reduction programs in disguise. And I kind of felt this was an interesting way of explaining a concept. And I thought it might be something that was worthwhile for you and I to kind of batter around, deconstruct, and talk about this in both today's context and uh and uh what we see in as the underlying reasons behind some of this.

I uh I was uh when you shared this quote with me earlier on, I'm sitting here thinking this is just one of those really interesting quotes in the sense that it's so easy to look at this and say, see, this is why we need to do X, Y, and Z, when actually there's a lot of depth in this quote that we really need to sit and understand. And too many times we we're looking for simple solutions to complex problems when actually complex problems often require complicated, complex solutions. Um, so if we just take that first sentence, quality takes time and reduces quantity, so obviously it's less efficient. What do you think to that?

It's it's true in uh in a sense, right? I mean, I mean I I agree. It's that uh if you're if you're gonna focus on quality, you're gonna go slower, you're not gonna be able to produce as much. So in the in a sense, you're less efficient at that point, right?

You're yeah, uh but at the same time. I was gonna say I can't agree to that. I think that's a very simple interpretation. Exactly, exactly. And and yeah.

So it it's it's gonna depend a lot on how you're measuring your efficiency, like what you consider efficiency to be, like how you um and uh what what is quality in the sense of um how and because it's such a loaded word in of itself. I mean, there's lots of ways we can interpret it. If we um something that may be of high quality to one person might be of low quality to someone else, if we're looking at uh the this in an overall sense, then there could be lots of different ways we can deconstruct even just this first sentence.

Yes, and and I think uh I mean, here's the the when I look at this, this isn't a it it isn't really describing efficiency, it's describing a simple interpretation of efficiency, which is time to market. The time it takes you to respond to my request is how efficient you are, which is not really true. There's a lot of different things that go into that. If the first time, I mean, we've all worked with um, say, help desks or customer service agents where you get an answer really quickly. Great, so they're efficient. But if that answer doesn't solve your problem, then it's not really efficient because either I have to go back or the problem doesn't get solved and I have to live with it, or there's something else happening. So efficiency has a lot in it. Uh, and it's not simply how quickly can I respond or how quickly can I get a change to market, it's whether or not that change is fit for purpose. And, you know, do I have to revisit and continually modify my requests until it actually serves the purpose I was looking for, or does it immediately solve my problem and I can move on and forget about it?

And this is why we look at uh mean time response in comparison with mean time to repair, so we can understand like how long it's actually taking us to to fix things and and improve.

And uh just in the same same way, that's efficient as the last word in that sentence. Quality is the first one and it's exactly the same. If you're building an aircraft, quality means completely different thing to if I'm building an app for sharing music, for example. So it it's there there's a whole gradation, so there's a there's lots of different inter sort of levels uh that we have to look at. Um, and I think the when I look at this sentence, I think the thing that in a sense bugs me the most is I can immediately imagine organizations where that focus on efficiency is all about my my service level agreement or my my organizational objective is to do X more quickly, more efficiently. And the consequences or the fitness of that solution is ignored in the continuous attempt to just drive down an efficiency measure, whatever that efficiency measure might be.

So as we let's go and look at the the second sentence here. So because I because I this is the one I think I I that really caught my eye in here, because um I just thought the the use of language was kind of interesting. Uh the efficiency optimized organization recognizes quality as its enemy. Enemy. That's just such a great way of describing it, right?

Yeah, it's it's interesting because it's it is um it feels wrong, and yet I think your experience and mine is probably similar here, where we go, yeah, I can begin seeing that. It's really like if it's an enemy, we don't like talking about it. It's something that we want to squash and get out of the way as quickly as possible, and it's a barrier to us achieving the good works that we are trying to achieve. And so yeah, I think it definitely comes across in that way in certain mindsets and certain organizations.

Yeah, and I I I think especially when it's the time to market of a new feature and the it's being driven that we we have to get this out the door, it has to go out by this date, and that very often what happens as a consequence is that the the quality goes down because it becomes the enemy. It's uh we we we don't validate it well enough, we don't give ourselves time to or break it down enough so we can bake it in. We don't we don't have um we would we constrain ourselves by optimizing for efficiency, and so we don't necessarily um build enough uh time in to be able to properly uh ensure that quality has been uh built in.

It's it's interesting because I'm I'm listening to your description there and I'm just thinking it it's the compromises that get made. Are it it's it's almost like you want the balance there. We need the balance between being efficient and having sufficient quality. And if the balance of power leans towards efficiency, the compromises we make undermine the quality of the product, the service that we're delivering. So we need balance there rather than one or the other. Obviously, if if quality is the be-all and end all, you don't have efficiency. We're always, you know, perfect is the enemy of good, right? But on the other side, if efficiency is the beast that we are following and chasing, then quality is what gets sacrificed. So there needs to be balance there, and that balance has to be an even conversation. And I think it's interesting, there are too many organizations, or certainly in the past I've worked in organizations where the quality QA or the testing component of any any sort of uh delivery piece is somehow not at the table, at the same table as the drivers for efficiency, whoever they may be, whatever that is. There's some sort of you know a hierarchy, and the QA is the last stop on the station towards getting something out of the door, and it's not necessarily given enough um authority influence. I don't know what it would be.

Well, I mean, and from the DevOps perspective, I mean, this is why. I mean, QA and doing all of your QA at the end and waiting for that, and that's how that gets constrained is exactly the problem.

Yeah, it's it it's it's actually a a symptom of the whole thing. Is if you're doing things sequentially, you're squeezing all of the testing into the end. By definition, you're you're demoting that particular role in the conversation about getting product to the market.

Yeah, which is why, in order to help create that balance, we need to move to a more quality engineering mindset and move quality further into the pipeline. All the wonderful things we can talk about in that space.

But uh, should we So I was gonna say, yeah, sorry to interrupt, but I just wanted to say maybe um how would you spin this quote around to have a takeaway that is puts a smile on people's face when they're producing a product and they can actually balance efficiency with quality. What are you looking for there?

Uh so uh for I mean from my perspective, and of course I'm I'm coming at uh this, there's a couple of key parts here. One is uh I think some of the things we've we've mentioned, like uh focus on uh on your mean time to repair, understand what uh what it means to be able to um bring things back online so you're understanding what the impact quality is of the changes that you're making and continually improving and learning from that. So that's building the the learning in from the the production side. The and then from uh ensuring the product has quality in, building quality engineering in earlier in the process, ensuring that they're at the table to help define um what quality will look like for the product as we move forward and as you're defining what it is that you're doing up front versus waiting till the end and then uh hoping that that uh that uh there's a QA mythical QA department that's somehow going to take what's thrown over the wall and capture that and somehow test it, and then you'll be and remembering that oh, I'm gonna now feed that back, and I need to have further cycles of back and forth to get to the point that I now have quality. If we're if you're operating still in that kind of development QA and operations type model, and you haven't started to break down those silos, then uh you have a lot of problems that uh you can start to undo.

Yeah, as uh as as I I was just thinking about this one. This is this is where what I was looking at there or thinking about is um if if we shortcut efficiency, for example, by exactly what um Tom Tomako is talking about, if effectively quality is bad, and therefore we're going to sort of demote it in the conversation, that efficiency gain is short, and it might get you to meet your target for a quarter or for a couple of quarters, but eventually that's going to come back and and and it's going to hurt. Efficiency taking it over the long run, you build quality in, you gain the efficiency, and that efficiency that you gain is a permanent or at least a much more sustainable gain in efficiency that gives you the opportunity to dominate a market. And again, the classic story here is Toyota in the auto industry, um, which over time overtook all of the dominant players in that auto industry because they got quality sorted out, amongst many other things. But that focus in relentless focus on quality allowed them to become relentlessly efficient as well.

I I think a classic uh example of this is the uh, and I heard this I think from one of my meetups, is this idea that um Mercedes are known for being very, very quiet cars. And to be quiet cars, they um they pack tons of insulation in so you couldn't hear the engine. The Toyota, on the other hand, uh decided, well, insulation's expensive and it'll make the car really heavy, so instead we'll work out what's causing the noise and we'll remove it. And this is an example of this. Uh understand what the underlying causes are, start to eliminate those in your system so that you are actually delivering the higher quality product, and that in turn will help with the efficiency versus um solely focusing on efficiency, at which point uh quality will start to reduce.

And uh the the book that sort of put all of that on the map for me is The Machine That Changed the World. It's it's a really fascinating read about just exactly how Toyota um made lean product management, the whole concept of sort of building quality in into the core of their company and and their philosophy and therefore how they were able to dominate the auto industry through the 80s and the 90s in particular.

Well, rapidly quick takeaways. Well, we've got one sentence left. Do you want to cover the last sentence? Yes, really quickly. Really quickly. The uh that's that's why many corporate quality programs are really quality reduction programs in disguise. What do you think on this?

I'm waiting for you. What are you gonna say to that one?

So, yes, uh it it could be.

I think that's a uh um very possibly true.

Yes. Uh um I I I I would be one of the I've seen this even in actually some very, very modern um sort of growth startup organizations where they've they've been rapidly accelerating, they've multiplied the number of teams collaborating, and they've realized quality is going down through whatever metric they're recognizing, and their solution is to put a Q8 apart. And I immediately start looking at well, is that actually gonna solve your problem, or is that actually gonna probably end up just is either not gonna help, or you're just gonna end up over time reducing your quality because you're not gonna be able to release as quickly, and you're gonna you're gonna have lots of problems. This is not a good solution to the problem you're looking to solve from the place you're coming from. We we've learned more, and I I think this leads us into some of the things we were thinking of in terms of a wrap-up to this as well.

Well, I mean, with that that final sentence there, what it's really says to me is you know, many corporate quality programs are really quality reduction programs. Well, as soon as I'm testing for quality, instead of building quality in, then when I'm testing for quality, if I reduce the time, the investment that we make in testing for quality, in a sense, we become more efficient, of course, because I spend less time in that testing for quality phase. But by spending less time, it does not mean the quality goes up. It just means that we're missing more and more and more. So I think DeMarco's absolutely right. Um, if I have that mindset, that short-term view of efficiency, by definition, we're going to be missing things and we're going to create a situation where the quality is going to degrade over time, of course.

I I think uh I think that's a good way of saying it. I think between us, we kind of generally agree. It's just that without unpacking this statement, it's a little hard to see it an initial read-through. Because I know when I read this out to you initially, your initial reaction was kind of whoa, that doesn't seem like that. Exactly.

And and I still I find it it's it's that one where you look at that and you go, I don't know if I'm offended by that or or not offended by it. And I think it's a great comment. I think as you unpack it, you begin to realize, yeah, there's of course a grain of truth. And part of it is that simplicity is looking at complex problems and saying efficiency is a single measure, or quality itself is a single measure. It's just the number of defects that escape, or efficiency is how long it takes you to get to market. Well, of course, it isn't, there's a lot more to that. But what's interesting as you get to the end of that quote is the impact of this simplicity, the interpretation, an overly simple interpretation can be felt in organizations. You can definitely see it. Organizations that the test at the end have a uh test for quality, have that um a reinforcing loop. I think of it, a downward spiral of quality, just because the the reinforcements are going in the wrong direction. Agreed.

So as we as we look to wrap up this conversation today, um I there was there was one piece that I thought was that we took away from this too, is that the the context is, I mean, this I think this quote is reasonably old compared to the world we live in today, and there were some differences in the world he's looking at. It's interesting though that I see some similar behaviors, and I can definitely take a view of this where I could uh apply it to what I see happening in organizations uh that I work with today who are sort of trying to solve some of these problems. Um but there is there is a big difference to the technology world uh that was there, to the technology world that we're operating in today. Um we have um far more ability, much more ability to integrate between systems now. There's uh there's more standards, as we have a better understanding of how to do that. A lot of those problems have been uh if not necessarily solved. We still learn into lots of integration problems, but there's there's patterns and there's there's models for doing this. Um and uh technology was also much more expensive there, whereas now I you can you can if you want to experiment or learn or try something, you can much more easily get access to a service that will allow you to do that. So I think that's definitely something.

And the consequences of that. What's the consequence like technology commoditized in many ways? Forming, like it's not commoditized if technology people are some of the most expensive people on the planet, but it's much more ubiquitous. We can go and make changes and we can do a lot more with technology than we could many years ago. So the consequence of that to this quote, what does it what do you pick up?

So so there's this piece that uh it it especially as we look at a a distributed space, it's like where we've gone into a space where, hey, if I if I want to see what's gonna work and I want to be able to test what quality will mean for me, uh I can now run multiple experiments very much more easily. I can try different things, whereas previously I was constrained by the the technology platforms and the space I was in. Now now I have the ability to um operate in a very, very different manner. And I can start to uh build I can solve a lot of these problems much more easily because some of these problems have already been solved for me, and I can take advantage of those solutions and build them into how I'm looking to solve it and build on top of the people who've come before, whereas if I had to previously everything would be very much more constrained by um what I had available to me from technology um for a print perspective. And we build technology in a very different way today. So is that quote relevant today? I think that uh it's I think it's a useful lens on organize for organizations as they try to adopt as an example I gave previously. We we have this this natural tendency still to fall into some of the same patterns that uh we see uh again, even though we have this these capabilities, we still end up doing things which we instinctively think is the right thing to do. Um like putting QA in as a group. Oh, okay, so we're our quality's dropping, so our solution is we're gonna have some groups who kind of stand there and have a checklist and validate that everything's okay before we let it go through, rather than thinking about, well, what actually is quality for our product and how do we build that into uh the release of the product as we move forward and start to understand how do we engineer quality into the system and understand what those different connotations of that are. Uh, you and we can we could spend an entire episode just talking about some of the underlying pieces and ways in which you need to go about that because it's uh it is a complex space in of itself.

So, in closing, let me just uh I think my my sort of my sort of 10-word sentence to bring this to to a close from my side would be um quality, focusing on quality, building quality in if we want to use the the lean terminology there, will give you the efficiency. I think that's one of the key things. And I think it's more relevant today because technology is ubiquitous, because everything that we do impacts many, many different services that we either provide information to, data to, whatever it might be, or we use. So that is more relevant today than it's ever been. I think building quality and builds your efficiency over time, long-term sustainable efficiency.

Yeah, because because your customers, if they don't see that quality, it's much, much easier now because of that ubiquitousness to go somewhere else. So that to uninstall your app and go to a different app and then and so on and so forth. It's much easier for them to change if uh than it was before too. So that's the impact. Well, thank you very much, Dave. It's a fun conversation as always. Uh we'll wrap this up now. If you want to send us any feedback, you can at uh feedback at definitymabyagile.com. And a pleasure as always. Always good. Thanks again, Peter. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps scale.