richrtesting

Recently the phrase ‘building quality in‘ has become something of a mantra for lean and agile development. It is sometimes offered as an alternative to ‘testing quality in’ (which is something I never really understood). I believe the point is to emphasize that we should consider quality whilst building our products, and not as an afterthought in a wasteful testing and fixing ‘phase’.

This might seem sensible; after all there is a broad acceptance that quality should be everybody’s responsibility and that this is a good thing.

The problem is that it implies that quality is a kind of static, tangible element of a product, an ingredient like yeast or salt which can be added to the mix. It is as if we can make our customers happy by stirring just the right amount of quality into our product when the time is right.

The word ‘build’ places the burden of responsibility with those who write code. It implies that we can pick up our burden of quality and shift left. Again, some might see this as a good thing, given the popularity of that term.

But responsibility for quality doesn’t solely lie with those who write code. The perceived value of a product, and the experience of using that product is the result of any decision or action taken from the earliest stages of an idea, through the design and build, the testing, the monitoring, feedback analysis and subsequent improvements.

If responsibility for quality lies with everybody who works within our teams then we need to think quality in. We need to consider the people who will use our products, the potential value to them of what we are doing, and the experience for them. Only by keeping quality front of mind at every turn can we truly make it a shared responsibility.

This bite size blog was inspired by a tweet from Colin Cherry. Colin himself has written on the subject of ‘Building quality in’ here