The Two Faces of Quality

Do you remember your last visit to an amusement park? Did you try the funny-shaped mirrors, warped to distort images in such a way that even the most serious person cannot hold back a smile? In the end, it is nothing more than a question of perception—a distortion of reality for the visitor's amusement.

Sometimes I see this same lack of alignment between reality and the perceived image in my corporate environment. Sharing some of my experiences working in the quality function of a software development department may be the best way to illustrate what I'm talking about.

The company is highly reputable and long established in the communications business—and its business volume puts it at the forefront of its market segment. When I joined the company, I was trusted with the mandate of implementing a quality program for the software development group. The opportunity offered unlimited possibilities of improvement, and had an enormous potential for quick returns on the investment. There was a clear wish to improve the quality processes at the base, and top management seemed supportive. All systems go...right?

Journal entry: Equipped with lots of enthusiasm, some apprehension about my ability to produce quick results, and the confidence spouting from past experiences, I start my first week.

My small QA team welcomes me as new member, looking forward to my contributions—but other staff seem uneasy with my new role in software quality. In order to understand the development activities and interfaces with other groups, we start exchanging information, and the questions multiply.

Very quickly the double-reality mirror image begins to appear.

It seems that people here see the quality assurance function as a tool to shape the clients' perception , not as a way to improve the quality in the product lines. The company is very receptive to customers' requests and suggestions. No effort is spared to answer customers’ complaints and correct problems. At the drop of a hat, the company sends development experts to the clients' sites to troubleshoot and solve major "quality" issues. The product development effort to continuously deliver new functionality puts us ahead of many of our competitors.

However, it seems that very little effort is made to prevent the problems at the source, during the initial phases of the development process.

Our initial approach of finding processes and project documentation is not a success. The more questions we ask, the fuzzier the picture gets. The software development teams are not following their procedures consistently. Most processes are not formally documented and approved. Many developers are not even aware that they exist. When we discuss development models, this lack of alignment becomes quite flagrant. Some are convinced they follow an incremental approach, when in fact they are using a waterfall model—except that they skip phases.

Some projects have very high-level requirements, while others have none. To save time and avoid delays in coding, it is an acceptable practice here to verbally pass the customers' requirements to the developers. Few projects have system specifications, architecture designs, or design specifications So how then do we capture assumptions and changes in the original documents? The answer is, "We don't." The development group doesn't see a need to go to this level of detail. They use the time it would take to do these updates to continue developing the product. The common answer is: "We can always look at the code if we need to find the details of what was done."

Some product teams are struggling hard to follow a less “flexible” development process. But their efforts to conform to the development processes by producing the