Managers Make the Real Product Quality Decisions

In a conversation about product quality, the product owner said, “If the testers found the problems faster, we would be done faster.”

The tester said, “If the developers didn't put so many problems in, we'd be done by now.”

The developer said, “If you didn't pressure me so much, I could have done a better job.”

They're all right.

That's because product development is a system of work. If you pressure one piece of the system and don't accommodate that pressure elsewhere, you create bad products.

Let's start with what testers do.

What Do Testers Do?

Years ago, I wrote The Influential Test Manager. In that article, I said, the test manager's (and the test team's) mission is:

To assess the state of the product under development at any time and report on that state.

That's not “assurance.” It's also not quality engineering. The testers cannot assure product quality—they can report on the state of the product. The testers also cannot engineer product quality.

Only the developers can engineer quality into the product. And, if they feel pressure, what's the first thing they stop? Any technical excellence, which is how you engineer quality into a product.

Both the developers' engineering and the testers' assessments require time.

This is why stopping testing doesn't stop the occurrence of problems. Stopping testing hides problems. The problems are still there. We don't know about them.

When managers decide to scrimp on test time and test resources such as computers or lab equipment, the managers decide about product quality. They take the pyramid and turn it lopsided.

When managers focus on dates and features, they ignore the effect on defects and the actual cost to release. (The initial cost to release might be low. The ongoing costs are significant. Hmm, I might need to write a post about supposedly agile teams and their costs to fix defects.)

Management decisions affect how we talk about problems and where people spend time. Let's start with the words we use.

Management Decisions About Words

I hate the word bug applied to software. See the Wikipedia article about the origins of Software Bug. Notice that the origin is bugaboo or bugbear, referring to monsters.

Bugs fly in from the outside.

Most monsters are fantastical creatures.

Neither of those accurately describes software problems.

I have spent (more than?) my fair share of time fixing problems in code, test, writing, you name it. And, each of these problems shared these characteristics:

1. Either my teammates or I created the problem.
2. We didn't check or test the code or tests enough (and now in my writing) before we tried or released the product.

We created defects, problems, errors, faults. We didn't create bugs. And, we didn't check our work for technical excellence in advance.

I urge you to reconsider how you talk about problems. When I use words such as defect, problem, fault, or issue, we often change our discussions about where to allocate time for the work.

Manage Decisions About Time

I included the project pyramid at the top of this post. (That link goes to the project boundaries series of posts.)

Not every project needs to optimize for low defects. Sometimes, we need to optimize for just-good-enough product to the customers so we can learn.

And, if you pressure developers, you might not get good enough product for anything. If you pressure testers, you might not know about the product.

Pressure doesn't make people work faster.

This is why I say that managers are in charge of quality. Developers and testers do their best work inside the system. And, if managers make unwise decisions, the product quality will suffer.

Great Management Decisions That Help Product Quality

So, what kinds of management decisions will help product quality?

1. Decide the kind of outcomes you want to see. This is part of the strategic work when managers choose this project for the project portfolio. You might need specific product outcomes or learnings. And, decide the boundaries for drivers, constraints, and floats.
2. Instead of pressuring a team, ask them, “What else do you need to perform your best work as fast as possible?”
3. If you started a project late, reduce the scope and release smaller increments of value more often. Don't try to cram everything into one big release. (Use recursion on this idea, from every week to every month to every quarter to every year.)

Managers create and refine the system in which people work. If you encourage technical excellence, you will get it, in both development and testing. You'll probably get the product earlier, too. And, the ongoing costs of managing the assets (the products) will be lower.

The team at the start of this post was under pressure. I've never seen external pressure work to create better products. Create a system where people can be proud of their work. They will deliver their best work. All because managers made quality decisions.