Built-in Quality

There's an old saying that goes something like, you can't inspect quality in a product, either has it or it doesn't. And so we refer to that as built in quality. It's important for teams to realize that quality comes from attention to good design, good technical practices and that that lives on the team. That it's the team's responsibility to build quality into their product. And look, it can be easy to sort of lose sight of this as you're sprinting along every two weeks trying to get that increment out the do. And so our teams, we need to keep an eye on that design, on that technical excellence. It reminds us of the Agile Manifesto principle. Continuous attention to technical excellence and good design enhances agility. Continuous attention to our design and our technical practices makes us go faster. It used to be that there was a quality assurance department that would kind of inspect and looked at your work and then kick it back to you to make improvements and to sort of change things. But remember our cross functional agile teams, we've brought that quality onto our team. I like to say it this way, quality is not a department, it's a discipline. So build that discipline on your teams and begin to understand the importance at the team level. So what happens if we ignore this? Well, it's quite likely that your product will begin to accumulate massive amounts of technical debt. Foreign. The technical debt metaphor was coined by Ward Cunningham to describe a number of different things, including the consequences of partial design stubbing out of solutions architecture or development within an existing code base that needs to be refactored. Heck, even in documents or PowerPoint decks you might have technical debt. The best description I've ever heard is this Technical debt is that pain you feel when you think about changing your product? I know I could change it, but, oh, I'm going to have to change four other things. Well, that's, that's technical debt. So one of the ways we can pay down technical debt in our products is by refactoring. We're going to change the underlying code or we're going to enhance the deployment practices, or we're going to enhance the process. We're going to eliminate waste and smooth out the flow without actually changing the functionality of the product. That's refactoring. So refactoring kind of becomes a way of life for us. On agile teams we want to relentlessly refactor rework, on the other hand is actually changing the functionality of the product. And that comes in when you don't pay attention to these details. You have products riddled with technical debt, you're going to end up with rework. We don't like rework. It's expensive. Nobody wants to do it, so avoid it. Build that quality into your product from the beginning. So quality, it's not a department, it's a discipline. And we're going to build quality into our products as we go.