How teams fail to provide adequate quality

I've seen many teams waste their time and budget applying quality attributes they are not obligated to follow.

The second thing is that having a quality attribute like Availability doesn't mean we have to be as close to 100% as possible. Maybe 96% is good enough?

Maybe the ability of the system to Recover a state and data after a failure doesn't have to be closed in seconds. Maybe 5 minutes is good enough?

Some system properties can be easily defined as numbers in a service-level agreement document. But not all can be measured so effortlessly to say it is good enough.

Why am I talking about quality attributes and wasting teams’ resources?

I observe that different departments within teams, such as UX, QA, devs, team leaders, and regulatory, strive to do the best of their work.

➡️ UX applies the best of Accessibility, Clarity, UI aesthetics, and Appearance properties.

➡️ Devs… well, devs do like overengineering. They want the best of Consistency, Portability, Performance, Elasticity, etc…

➡️ QA applies the best Precision and Appearance properties. They want the UI to be pixel-perfect.

➡️ Team leaders want to have everything in the formal process. Every small change, like a typo, entails a task renewal, a new commit, a new pull request, waiting for approval, and another testing.

➡️ Regulatory wants the highest quality in Standards Compliance.

However, the quality attributes should be required by customers. Also, having a quality attribute on the list doesn't mean it must be implemented 100%.

Teams must know what “good enough” means for them.

Applying “100% protocol” destroys pragmatism, increases frustration, and drains budgets.

That's why teams should have pragmatic leaders who can stand up in defence of the real goals. Because the highest quality is not itself a goal.

👉 Sometimes, good enough is the highest quality.

💡You can find the complete list of all humanity's known non-functional requirements here.