Eight signs that your quality sucks

Sustainable high quality is essential for the success of your product. When I get hired as an Agile Coach, I often encounter that quality isn't at all where people think it is, and in this article, I'll expose some of the key clues that quality sucks and the product has a huge pile of technical debt attached.

To tell you how obvious problems can be, I will exclude the options of "looking at the product" and "looking at the code", because that would be too easy.

When I see these signs, I will immediately drill in and go for the root cause with just a handful of questions, because the symptoms are dead give-aways of poor quality.

If you see one of these symptoms, that might be coincidence. If you see two or more, there's something fishy. And if you see all of them and don't have quality issues, I would surely like to hear from you, because I'd really love to learn how that is possible.

So here's my list of hints that you need to work on your product quality:

Pseudo Done

When teams play ticket ping pong and spend large amounts of time "fixing" things after an allegedly "Done" feature goes into test (or: live) then I first ask about their Definition of Done. Usually, they either have none - or one they don't live by...

Sticking to Formalities

Sometimes, I see fake User Stories like, "As an API, I want to be informed about changes to the database so that I can process the new data." or lists of wishy-washy Acceptance Criteria like, "Buttons are implemented". When teams and/or organizations don't even understand the "Why" behind simple tools and practices, how can they understand what's value for the product?

Not Releasing

If you haven't released in months, you're stacking up assumptions until you get into dreamland. You assume that you understand what users want and users assume that everything is going to be great. The release will later bring you down to reality, often with sore disappointment, massive rework and a hard course correction.

Top-Down Process

When people who don't actually do the work define how, what or when work should be done, I don't need further evidence. I'll need just a handful of "Why" and "How" questions that will make it glaringly obvious to everyone that things haven't been thought through and the outcome isn't going to be what it was supposed to be.

Snooze Refinement

When the only persons talking during Refinement are the Product Owner and the Lead Developer while everyone else remains silent and near motionless or no user joins the show, it's very likely that developers don't really understand what's the best way to translate demand into reults, and the outcome will be accordingly.

Reviews

When your Reviews are a glamour show where only the sunny side of the product is presented, issues are masked or users don't get to actually touch the product until much later, you have no idea what quality level you're actually on. If you do indeed get feedback, but that has no effect on your backlog, you're closing your eyes to some very unpleasant facts.

Pointless Retrospectives

How can breakthrough improvement happen when by sticking to existing processes, tools and dogma? Many teams only do miniscule, cosmetic improvements without ever fundamentally questioning what they're doing or how they're doing it. If quality isn't increasing dramatically, it's declining in comparison to everything around - which, a few years down the line, will make a product obsolete.

Low Morale

Developers who do a great job and produce a great poduct tend to be proud of what they do. When most of what I hear boils down to complaints and frustration, I already know that the product sucks. Are developers forced to build the wrong thing, are they building it wrong, don't they understand what the right thing is? I don't know - but I know if they continue doing what they do, the product won't last long.

And then what?

What can you do if you observe any of these symptoms?
Ask yourself: "Why? Why do we have this situation, what causes it?"

The root cause isn't always the same, so a discovery journey is always in order - and then you get to decide what to do with the problem.