Is quality just a belief? While this notion has merit, I think it can easily lead us down the wrong path. In the article Quality Needs Data Not Beliefs I highlighted an example of a quality assurance (QA) organization that had difficult detecting quality in a project that eventually was recognized for achieving new levels of quality.
In this case one QA “belief” was that defects were being overlooked and mis-prioritized. As it turned out, the belief was unsupported by any hard evidence (or root cause analysis) and so not surprisingly the QA remedies did nothing but increase the number of meetings and additionally generated tension between QA and product management.
This project, which took a data driven approach to planning, ended up exceeding most of our quality criteria and was lauded by one of our biggest customers for its quality. It also spawned a whole product line noted for its on time delivery and quality.
What was most telling was that while this break-through project was ongoing, QA could not detect that quality was improving (or was even different from previous projects). In my observation (I managed this project) this was due in large part to QA being based more on a “collection of beliefs” about quality than it was on hard data driven indicators.
Both product/project management and QA were not functioning well in this organization. So it was not too much of a surprise that when one part of the organization improved itself, it uncovered problems in other parts of the organization.
We often apply QA as the change agent to improve our organization. What is sobering about this is that QA is probably just as hard to do well as is the activity that QA is supporting. So if we can’t manage the primary development activity well enough to produce quality, it is unlikely that we’ll be able to mange QA so well as to in-turn produce quality in the development organization.