Collective Quality Ownership

Elisabeth Hendrickson pointed out to me that she recently renamed her seventh practice of Agile testing to Collective Test Ownership. The name is the compartment of the XP practice Collective Code Ownership. Behind it is the value that everyone should be able to change everything if there is a claim to do so. There shall be no human singletons, which are the keepers of the holy grail of your product. This holds for the code that will be compiled and shipped as well as for the tests for that code. If a user story affects existing tests, the tests should be able to change – probably after discussing it with the product owner or using The Power of Three to decide about a failing acceptance-test.

However, I see another collective thing that Agile adresses very well: Collective Quality Ownership. What’s that? Collective Quality Ownership means that everyone has the responsibility to hold the line at the occurrence of a quality problem. Everybode on the team has the right and the responsibility to get to that problem, fix it, and get back to speed. XP practices like Continuous Integration and Collective Code Ownership are just some examples of it. In a waterfall environment where everyone is playing hot potatoe you will realize that there is a lack of Collective Quality thinking. If there is a problem, then someone to blame for this is identified and the hot potatoe is handed over to the next. In the end after months of passing the potatoe around, the problem is still there, and a lot of time has been wasted to pass the problem around, but not to address and fix it right here, right now.

Why do I think that this is important? Collective Quality Ownership is part of several parts in our development live. Each time a bug gets filed, ask yourself how much does this new bug contribute to fixing the problem? When testers hide in their cubicles, getting code thrown over the silo wall, throwing bugs back, then the problems are not addressed. Such a system is not optimized for fixing the problems, for solving the problems, but for identifying problems and for throwing them around. Time is spent in information hiding, time is spent for passing the next potatoe getting passed to own-self and too few time is actually spent at solving problems.

On the other hand Collective Quality Ownership calls out that everyone is responsible for delivering quality to their customer. What is quality? The famous quote from Jerry Weinberg here is

Quality means value to some person.

Quality may mean value to your customer, quality may mean value to your stakeholders within your company. If you see a problem that their very quality perception of the product may disturb, you have the right and the responsibility to fix it. Now, do it. Don’t pass the potatoe. It’s your responsibility. Don’t be blocked by the problem, don’t play the victim role here. If it’s an area which you’re not familiar with, you can always find someone to pair with you on it who is capable of it. In the end you may find out that you learned something and then be able to fix the problem yourself the next time. But you have to address the problem. Now. So, do it!

Agile Testing Days Berlin II – Monday evening dinner conversations

Agile Testing Days Website
On Monday evening of the Agile Testing Days all speakers were invited to go to lunch from the organizators. I had the dear honor to sit next to Tom Gilb with Mary & Tom Poppendieck directly facing. Though I was not able to follow the complete conversation in-depth, I was able to get most of their points. Unfortunately I didn’t take notes on everything discussed there, but I denoted two things on the next day from that conversation.

Continue reading Agile Testing Days Berlin II – Monday evening dinner conversations