I have heard a lot of people talking about the execution of tasks related to quality and many absolute rules on the subject.
I always hear about the subject on rigid terms and I don’t think people really ponder the variables related to the subject.
First, a brief introduction on the polemic subject:
A team wants to do a task that is related to the quality of the code, let’s say, improve the unit test coverage. On one side, people say this is part of doing the tasks, and are not open to discussion. The team should just goes ahead and do it. On the complete opposite side, there is a pressure from the customer to have the product ready within a certain time-frame and he does not care about quality.
Similar discussions are something that can be seen on a day-to-day basis in most projects, and in my view, putting it simply like I did above is very one-dimensional and limiting.
From the little I learned from manufacturing industry, for every material, there are different quality standards demanded by the factories from their vendors. There is a definition on what is the quality standard prior to production, and depending on the usage of the material, the standards are different.
Suppose you are buying steel to build a popular vehicle, your iron needs to be assessed under a series of tests so you can be ensured that the car will be safe to the general population. If the iron is to be used in a formula 1, the requirements and the quality level must be much more demanding.
The formula 1 will be running above 300Km/h under extreme g forces, and the popular car will not. It does not make sense to use the same quality on both cases.
I once visited a rice farm in the state of Mato Grosso do Sul, here in Brasil. The rice farmed there goes into different rice brands in the supermarket, and those different brands sell with different prices and quality standards. The top brand comes from that farm, and also some not so good brands. And when you look at the rice, it came from the same farm, but they do not have the same quality.
One of the brands go through extra processing, leaving only top quality grain in the shipping. The other does not, and is of course cheaper.
With this, my point is that quality is not an absolute concept. Quality must be adequate to the purpose it serves!
The company producing software must determine standards for quality that the team must maintain rationally. The team must have the freedom to maintain the agreed level of quality, but not above that. If the PO pressures you to go below the “minimum” level of quality, the ScrumMaster must defend the team so they can do their job and the technological deficit is held bellow a certain level.
If the team wants to do a task that goes above the required level of quality, that decision IS up to the PO. It does not matter if the Team is capable of delivering NASA quality when you need to do a short lived system for a small marketing campaign.
It is important to be mindful, there is a minimum, and everyone must try to understand what that minimum is. Lots of times, this minimum comes in the discussion of the Definition of Done, and sometimes on non-funcional requirements on the ProductBacklog.
On the first example I gave, the team improving unit tests, if the agreed coverage is 80%, and the team has 80% but wants to spend a week getting it to 95%, it must have the involvement of the PO.
If the level was 75%, below what was agreed upon as the minimum level of quality, then there is no discussion, it must be done or else the task itself is not Done.
This minimum does depend on the project, and going above it, if it is not effort free, must have the agreement of the client. That’s how I see it.