How to know something is done?
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.
The misconception of the DOD meeting
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.
What we actually need
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?
Quality vs time
“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.
So, it’s a tradeoff?
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.
