Quality is an effort across the whole value creation chain

Quality should be everybody’s concern. Ideally there is no need for quality assurance people, for testers or similar roles. Instead a whole team comprised of professionals ensures a quality product is made.

Over the years I’ve seen two basic models for testing. Larger companies typically have a dedicated testing department or a dedicated tester role while smaller companies just have programmers. Larger companies usually employ a structured approach for software development and are heavy on process while the smaller companies “just work” on their product.

When it comes to offering help to all of them one tries to bring specialists together at the larger companies and at the smaller companies one tries to introduce testing as an important methodical activity that people frequently seem to neglect.

Bringing specialists together at the larger companies frequently involves putting down department silos. A testing or QA department with incentives, KPIs and other control mechanism that is deliberately set up against other departments, usually dubbed “development XYZ”, is typically seen by agilists as a bad thing. It is difficult to have people on a team verifying their team mate’s work and expect to have everybody to have a trustful relationship. When monetary incentives are added that will turn into a competitive situation and likely lead to a global minimum. In such a situation there is no team either - it is probably best to call it a workgroup instead - because people are not trying to help each other. They are trying to help their tribal members and not those who belong to the other tribe.

The existance of a testing or QA department is probably related to the fact that traditional management is mostly concerned with efficiency and sharing a resource that is only used at the end of a process for a given length of time is more cost efficient than making similar resources available within each group. In a structured, linear development process testing happens typically at the end and so the testing resource is of limited use.

When quality is everybody’s concern then we cannot have a quality specialist on a team. We can have quality specialists as a consulting function - some sort of a guide - and that function can be provided by its own department. These people provide help, training, education on the subject of quality.

The market defines quality

In software development we are making a product that is one of a kind. That means we can not really compare things of the same kind and define quality as how much they are identical to each other. In the case of a one of a kind product quality can be described as the degree of excellence the product is perceived as having or how fit it is for a given purpose. Further, what the product can do it should perform without crashing or delivering false results.

The only way to ensure that a product has a high degree of fitness for a given purpose is to work closely with those who will use it or with good representatives for them. That is where the value creation chain for the product starts. Then the value creation chain continues with those actually making the product followed by those who probably will deliver or deploy it, if that is needed, and the value creation chain ends with the customers who will use it.

What we have is a circle. When we call our customers the market we get our definition of acceptable or desired quality from the market and then deliver value, in the form of the product, back to the market. We are going to be paid money for the product based on the degree of excellence as perceived by our customers.

Making quality a whole team effort

Commonly talk about quality and quality improvements happens in development teams or managers ask leaders of development teams to improve the quality of their deliverables. Sometimes testers try to introduce efforts to improve quality as well.

None of that is really helpful. It is a good start but unless the effort is being done across the whole value creation chain, it stays a local optimization and may also lead to harm for the product and the organization making it or depending on it.

A more effective and more sustainable approach is to figure out how the value creation chain for a product looks like and who are the participants. Then we should try to optimize it for effectivess and not for efficiency.

Usually an improvement of effectivess happens when communication is improved. Why separate marketing people from the developers? Isn’t it that the marketing people know the market, the customers, best? They know what degree of excellence is required to be successful. Instead of marketing it can also be the product management function where the knowledge about the required degree of excellence can be found. If you are working on a inhouse product in a large enterprise, the actual users are best suited to explain what they think makes your product fit for purpose.

Models, processes or tools like Acceptance Test-Driven Development or Specification by Example can be helpful to capture and convey what product behavior is expected and stimulate conversations across the value creation chain. That way the contextual information people at the start of the value creation chain possess, let’s call that the market context, can be conveyed to purely technical people like programmers. Now we have a conversation between the requesting party of a feature and the makers and likely will develop shared understanding.

This article has been posted to social media sites. There might be comments. Just follow the links: