Quality is an accumulation of subsequent right decisions.
This chain of events leads to a great product. If one part is broken, a feature might only work part of the time. Or a software is slow. Or data is processed wrong.
Overall quality depends on the quality of the parts.
Good project teams set a quality standard and adhere to it. This is where our “Definition of done” comes in. Done is when it works. After it is tested. After internal quality was checked.
I wasted quite a bit of time attending meetings to “Determine the DOD”.
Quality is something that cannot be the average of a group. People have different standards of what they accept as the bare minimum. If you ever ate in a cheap fast food shack, you know what I mean.
What does this mean for software teams?
Setting a high quality bar should be the responsibility of the tech lead. Other team members can suggest “upping” the quality. But they can never dial the quality down.
This is not a democratic meeting where everyone adds their thoughts. Not something where we pick cards and then find a conclusion in a team. Apart from coming to a mediocre solution, it wastes everyone’s time.
A DOD meeting is a teaching session.
Let’s say we start a new project. The most senior person sets the quality standard. Then adhere’s themselves to it and produces examples that can be copied. A meeting can then be held to teach new members what quality is.
A DOD is a good checklist. Every code review involves this checklist. When the PM or the QA person tests a feature, they can cross-check if everything is done accordingly.
Usually this includes:
- Was it programmed?
- Does the code stick to our linting standards and is it readable?
- Were all documented business requirements observed (test cases observed)?
- Were all other guidelines observed?
“Qualtity is non-negotiable” is bullshit. People (or AIs) writing this have never faced reality. It is always negotiable. It’s just important to know when it’s compromised, and how.
Best intentions can change if
- The investor demo needs to be done to ensure funding
- A feature needs to get out to meet compliance
- Hotfix was demanded by management
I asked my product owner friend Lasse about this:
We are building an MVP and speed > quality. Now having to rigorously involve the DoD every time is a luxury we don’t have :D
Speed is more important than quality especially when a feature is built that nobody uses.
Like everything in life, it is. That’s why the most senior person should define it. If we compromise quality to increase speed: this should be done consciously.
That’s why we need a good checklist. If we say we don’t check one item: then we at least know.
Being conscious about quality also means to sometimes only sacrifice it consciously.