Partnership For Success


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

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.