Who’s In Charge of Quality?

Who's in Charge of Quality?

At the Agile 2010 conference a couple of weeks ago, I heard many people say, “When QA gets the software, …” In an agile project, that makes no sense to me, unless the team has not developed its own definition of done.

In more traditional projects, the people in the testing group, whatever that group is called, often make the decision about whether or not to release the software. With these statements and decision-making power, you might think that the testers are in charge of quality.

They are not.

The testers do not decide how the developers develop. The testers do not decide how many projects the project team works on. The testers do not decide how to organize the physical environment so the project can run smoothly. The testers do not decide who works on the project.

So, could it be the developers who are in charge of quality? After all, they make the decisions about what goes in the code and how the code looks. The developers have a small piece of the quality decisions. And, if you ask developers, they don't normally think they are in charge of quality.

Is it the project managers? They try to make decisions about the iron triangle (which is really a six-sided pyramid), but they don't fix the cost, scope, date, people, or environment, never mind the defects. When I work with project managers, they tell me they feel as if they have little or no control of quality.

The people who are in charge of quality are the managers. They decide who is assigned to the project, they decide how to organize the physical environment, they decide about the project scope and projected release date, and they definitely decide how much to invest in a given project. They even decide if people are going to multi-task, which makes everything take longer, cost more, and influences the number of defects the developers create.

Many managers do not realize they have this power. The decisions managers make have more effect on quality than any other decision anyone else makes for a given project.

That means that project managers, developers, and testers have obligations to managers, to help them make quality decisions and decisions about quality:

  1. Project managers need to ask what success looks like for this project. And, based on what success looks like, the project manager can facilitate the development of release criteria for this project.
  2. Developers need to explain that when they estimate a duration for a feature or other work, that they are planning for no defects. So, if a manager requests they finish that work faster, the developers can decrease the time and that decreased time will have the effect of increasing the number of defects.
  3. Testers need to explain that their job is to explain what they know about the product. If they have not tested anything yet, they don't know anything.

One more thing: Nobody, aside from managers, should be approving products for release. If the product meets the release criteria, then the project team can say, “This product meets the release criteria.”

Releasing a product is a business decision. Managers need to make that decision. Project managers, developers, testers, whomever is on the project team can help prepare for and facilitate that decision. But managers are in charge of quality, and therefore, in charge of release decisions.

Managers: Yes, this is a difficult job, and that's why the buck stops with you.

New to the Pragmatic Manager?

If you're a new subscriber, you may not have read all the back issues. Start here.

I keep my blogs current with my writings:

Managing Product Development
Hiring Technical People

Johanna
© 2010 Johanna Rothman

Leave a Reply

Scroll to Top