About

Why Deming Driven Testing

I came across the term Deming Driven Testing from Mike Harris which I like very much because it describes the approach I took accurately.

So why Deming and not Lean?

As I was searching for information on how to transform QA teams in 2018, a new buzzword emerged; Shift Left. I researched where that term came from and came across Dr Deming’s work and the quote on scraping toast. I also learnt about his 14 points and the need to cease dependency on inspection and the System of Profound knowledge. The latter included the psychology of change which I found was essential in trying to solve what are socio-technical problems. I like to take a first principles approach and so I concluded that what Dr Deming described made for a good foundation.

Additionally as it is with other concepts, there seems to be multiple definitions on what it is. I was concerned that if people on my team went Googling what Lean is, they’d get information that would discourage them from trying it out. Some folks think Lean six-sigma is the same as Lean which is the same as TPS. I admit that I think the latter two are the same and know nothing about the six-sigma one (I’ve so far found no use for it). From the podcasts I listen to I hear consultants say similar things; folks think it doesn’t apply because they don’t make anything (my QA team didn’t make software), or they don’t make cars or they don’t make the same thing over and over again. My response is that lean is about the process. Even if you don’t make cars, the same car or make anything at all, your process is not changing everytime you do the job. And so this aligns nicely with Statistical Process Control and the emphasis on process quality and inspecting products to find defects in the process rather than inspecting the product to ensure quality.

I should note that when it came to how to apply anything to do with psychology I had no idea of what to do at the time and found very little help from the software development world. For that I relied on Start with Why by Simon Sinek.

Personal Transformation Journey

The transformation wasn’t just about changing processes - it was about fundamentally shifting how I understood quality and leadership. When I moved from systems architecture to QA leadership in 2018, I realized that traditional inspection-based approaches were creating more problems than they solved.

The real breakthrough came when I started seeing the QA team not as quality gatekeepers, but as partners helping developers build quality in from the start. This required me to learn entirely new skills - not just technical ones, but psychological and cultural ones.

Working with four different QA teams over four years taught me that each transformation is unique. What worked for one team didn’t automatically work for another. The human element - understanding team dynamics, individual motivations, and organizational culture - proved to be just as important as the technical methodology.

The most challenging part was helping traditional QA professionals see themselves as problem-solvers and improvement partners rather than defect finders. This required patience, continuous coaching, and a willingness to fail fast and learn together.