People in software development often say that quality is not negotiable. But this is not true.
Not negotiating is not discussing quality and you need to discuss the level of quality that is needed and how to achieve this level every day. If you do not discuss quality everybody does have its own perspective on it. The discussion needs to happen on all levels of a company. Take the sales department. Their job is to sell features, not quality. Look at customer support. They want less features to support, but more quality, as poor quality makes their live a mess. Developer themselves want quality for each new feature but face the problem to also need to provide quality for some old legacy features they do not own. This shows that company departments might have different requirements on quality. Hence quality is not only negotiable. You have to discuss and negotiate it every day.
Negotiate on company level
To have a common understanding of the level of quality you want to achieve, this quality topic needs to be addressed on a company level. The requirements to quality and the cost it has need to be transparent in every department. Sure, sales want to sell features. But if these features do not work properly, they will not sell a second feature to the same customer. The customer support wants to have features to work properly only, but no new features will make them lose work. Quality does have a cost and return of investment. This and the different needs of everybody should be communicated well to let management decide the proper company needs of quality assurance.
The testing pyramid often has its base at unit test level. But to work properly it needs support by a clear and well communicated quality requirement.
Negotiate on software developer team level
Developers need to know what they should deliver. If they are told “quality is not negotiable” developers need to do what ever it takes to prevent any bug. It might include refactoring old the old legacy code. This means that any new features might take an eternity to develop. If developer know what is expected, they can negotiate on how to achieve the expected level of quality within the team
In any software development team, the first step of negotiation should be the definition of done (DOD). The DOD defines what it needs for a feature to be finished. Which tasks should the team perform, and what checks need to be done. If this is not negotiated and therefore not known to anybody, the team will not be able to deliver a sustainable level of quality and each feature implemented might contain an expectation gap. A team DOD might contain something like the following:
- all acceptance criteria are met.
- new code is secured by an automatic test (unit test, integration test, UI test).
- four-eye principle: Code has been reviewed and understood by at least one other developer (Code review or pair programming).
- Code guidelines for the components (server, client, mobile…) are met.
- No new linting or compiler warnings exist (depends on component type).
This example is part of the DOD of one of my teams and it shows the result of an intensive discussion between all members of the development team (product owner, software developer, quality experts). Having a DOD written down is needed, but the negotiation does not stop here. For each new feature product owner, software developer and quality experts need to discuss the quality or testing strategy. Which kind of automatic tested is needed? Which edge cases need to be tested? The discussion about the testing strategy does not only impact the proper quality of the product but also the speed of development for this and upcoming features. Additionally, the four eyes principle stated in the example DOD is nothing else than a negotiation about quality. At least two developers discuss for each feature if the unit tests are suitable, the coding guidelines are kept and if the overall code quality has been increased (boy-scout-rule). They might even discuss to remove an automatic test if it does not suite any meaningful test case but increase the effort of maintenance and the performance of the overall test run.
To achieve the right balance between working software and pace of development the whole company needs to be involved in the negotiation of quality. Quality is not an act. It’s a habit of negotiation.