I confess that the title of this talk has me instinctively saying, "This is a sarcastic title, right?" Granted, Lean and SAFe have the idea of "Built-in Quality" as one of their main principles but again, I have been trained and conditioned to be skeptical of such a thing. Still, let's give Derk-Jan de Grood the benefit of the doubt ;). What does Built-In Quality mean and what could it look like?
In a variety of larger projects, especially in the physical sphere, a lack of quality isn't just inconvenient. It could literally be a matter of life and death. Thus, sure, we want to look at the abilities we can leverage to increase quality. Still, is this a matter of semantics? Can you actually build quality in? Of course, the answer is yes, you can take care while the product is being built to help ensure that the quality of a product is as high as it can be. Again, though, what does Built-IN Quality actually mean, and what does it actually look like?
Ultimately, in my worldview, Quality has to be present from the very beginning. Let's consider something I'm somewhat familiar with in regards to building a guitar. The first and foremost area to consider is the wood that makes up the body and the neck of the guitar. If there are hidden cracks inside of the wood, it doesn't really matter if the rest of the guitar is top notch. An uncovered but spreading crack in the interior of the wood would counteract any and all quality I might put into the frets, tuner, bridge, pickups, etc. In this example, if I were to scan the wood to look for cracks or imperfections within the wood, eliminating board stock that would not allow me to cut a solid piece without structural cracks, that will "build in" some quality in that instrument.
Likewise, we need to be able to look at our applications the same way. To build in quality means we as an organization need to be willing to go into our processes and practices with as much attention as my hypothetical luthier and them scanning the wood to look for potential defects before they make cut #1.
Ii a software example, we of course can and should apply similar ideas. If we have processes that address quality from the very beginning of the software development cycle, we can likewise create processes and practices that will allow us to test effectively from the earliest point of effort.
No comments:
Post a Comment