Abstract
No one wants to deliver a poor-quality product. But our projects often seem like a struggle between the Quality Assurance personnel and those who have other jobs. Do some people really not care about quality? If that is not the case, then why does it so often seem that way?
How can we get all of the players on our projects to work together? How can we change our mode of operation from that of warring factions into that of a partnership for success? The key is to be certain that we all understand the meaning of success. Only then will we be able to work together to achieve it.
The Conflict
My first experience with quality assurance (QA) was in my third year out of college, when I went to work for a large computer company. I chose the QA department because it afforded me the greatest opportunity to grow my career and learn. It would be decades before I would realize that most of that learning would be about how not to do things!
My boss, the QA manager (we'll call him Craig) was a quality warrior. Quality was his job, and he took that job very seriously. He was always trying to teach the rest of the organization about quality and help them to change their slovenly ways. Unfortunately, outside of his department, he seemed to be a voice crying in the wilderness.
Especially perplexing was the development manager, who we will call John. He seemed to take great pleasure in pushing out as much code as he possibly could, but without any consideration for the quality. How could he be so dull? Why couldn't he see that his poor quality would sink our product?
The battle was set. Craig versus John in bout after bout, as John push out bad code and Craig revealed it for what it was. It didn't take long for the rivalry to turn personal, with both of them fighting to win the VP's ear and get the other removed. In the decades following, I have seen similar fights in many organizations. Thankfully, most were not so rancorous, but tension and in-fighting existed, just the same. Is this just a part of the job? Is this conflict necessary to developing software?
Finding the Common Ground
Dr. W. Edwards Deming (the luminary of quality in the 20th century) made it clear that such conflict is not only unnecessary, it is also harmful. The first of his 14 points is constancy of purpose. He wrote, "Create constancy of purpose toward improvement of the product and service so as to become competitive, stay in business and provide jobs."
Dr. Deming’s statement about constancy of purpose primarily references quality. Indeed, what is quality other than the attributes of our product that will allow us to be competitive in the marketplace and assure the company's continued existence? How can anyone argue against the supreme importance of quality after reading what Deming wrote?
Yes, quality is supremely important; so important, that we must take the time to understand and define what it means for our product to be high-quality. It is in this task of defining quality that we will find the common ground between QA and the other players on our projects. We will establish the basis for not only a constancy of purpose, but also a partnership for success! Those of us in QA tend to think of quality in terms of defects. After all, a defect is where we focus our efforts: Our tests reveal them, reviews highlight them, systems track and manage them, and we argue about whether they really are defects (as opposed to features). We constantly negotiate about which defects will be fixed and which will not. If we have any spare time or energy, we may also look at some of the other dimensions of quality (like performance or usability).
The quality of a product goes far beyond that narrow focus, though. While it is true that a defective product isn't good for much, it does not follow that lack of defects results in a good product. Deming's constancy of purpose points us to being competitive in the marketplace. Indeed, we must always use that idea as our common ground.
What will it take to make our product competitive in the marketplace? The answer to that question will take us beyond defects and the other traditional dimensions of quality. The answer will include a mix of topics concerning product quality, timeliness of delivery, cost to produce, and functional capability of the product. The proper mix of these things is different for every different organization, and likely for each product we produce.
Agreement about what it means for us to be successful is the key to establishing common ground. That common ground will be the basis from which we can fight shoulder-to-shoulder instead of toe-to-toe! It will allow each of us to perform his or her duties in a way that coordinates with the work of our teammates so that we can be successful!
Working Together to be Successful
Establishing this common ground will not solve all of our problems. It will be our basis for working together, but each of us will still have a different job, different responsibilities, and a different focus. That is the nature of an organization. The work is too big for any one person to do, so it is divided into its component parts. These differences can still be the root of problems. As each of us strives to do the best possible job, there will be conflicts. Dr. Deming made another important observation that illuminates this problem. Although it is not one of his 14 Points, it is the key to our ability to achieve constancy of purpose. He observed that when each part of a system is optimized, the result is often that the system itself is sub-optimized. That is, when each group is working in a way that makes its particular job come out in the best possible way, the result can be that the sum total of all of the work is not what is best for the organization!
For this reason, he preached that we should not seek to optimize our own jobs. But rather, that we should do what is necessary in our own jobs to optimize the result for the entire company. And at times, that will mean sub-optimizing our own work. This is a hard prescription! It is telling us to look beyond our own responsibilities, and do what is best for the company at large.
In practical terms, that means that we who are responsible for assuring the quality of the product, must always keep in our minds the other contributors to project success (timeliness of delivery, cost to produce, and functional capability of the product). At the same time, developers, and others must also keep all of the contributors in focus, including quality. Then, we must work carefully together to balance all of those things to bring about success for the project and the company.
Sometimes quality must slip to meet dates, but at other times the date must slip for quality's sake. Sometimes, functionality will suffer to constrain costs, but at other times, cost must give way to capability. By keeping all of the contributors to success clearly in focus, we will be able to work together, shoulder-to-shoulder in a partnership for success.
