«    »

Who is Responsible for Quality?

I had a manager a short while ago ask me who was responsible for quality within their organization, within the context of software development projects. Without having to think about it, I knew the answer. It was intuitively obvious, but it was an intuition fueled by reading hundreds if not thousands of pages about lean thinking and quality. So I knew my answer was correct without knowing why it was correct. A difficult position to be in when trying to intelligently justify my response.

So what logical argument can be made to determine who is responsible for quality? I will start with an obvious possible answer: the quality assurance department. Perhaps they are responsible for quality because that is what their name means: they assure the organization that good quality work is being done. Oh wait, can they always do that? What if the work being done is poor quality? Can the QA department prevent or fix that? The answer is no. So the best QA can do in such cases is assure the organization that the quality is bad. Well, if QA cannot assure good quality, perhaps we can still hold them responsible for the bad quality work. And maybe QA would be responsible, to a limited degree, if their approach to assessing quality or their policies contributed to the bad quality work not being prevented or not detected sooner. But shouldn't the responsibility lie with those doing the actual work?

So it must be the developers who are primarily responsible for quality. They write the code, so they are responsible if it has defects. This sounds correct at first glance, but to be sure I will examine some different categories of defects. Logic errors - yup, developers are responsible. Misunderstood requirements - again let's make the developers responsible - they should have asked for clarification. Ambiguous requirements - this starts getting into a gray area - perhaps the business analysts drafting the requirements could have been clearer. Contradictory requirements - the developers are off the hook for this one - the business analysts have to take responsibility here. So for most aspects of quality the developers are responsible, and for other aspects it is the business analysts. I know - let's just make the development team as a whole responsible for quality. Great, case closed!

Wait, what's that? You are saying that I missed a category of defects - the category of missing requirements? Well, that might be due to poor analysis on the part of the business analysts, but ultimate responsibility falls on the source of the requirements - the product owner / business team. They're not usually considered direct members of the development team, though, so making the development team solely responsible for quality no longer seems like the right answer. And what about those in management responsible for setting organizational constraints on the development team - constraints like schedule, budget, or resources? If these constraints are too severe they are guaranteed to lead to quality problems, either in the form of defects due to sacrificing quality, or in the form of insufficient functionality due to sacrificing scope. So shouldn't these managers also be held responsible, to some degree, for quality?

Everywhere I look, at every unit within the enterprise associated with software development, each has a role to play in contributing to the success of a software development effort. In other words, each is providing a service. Imagine, if you would, one of these units with absolutely no responsibility for providing good quality. This irresponsible unit can provide the worst quality service, and the other units would just have to deal with it, either by completely avoiding the irresponsible unit's service, or by accepting responsibility for addressing the bad quality aspects to bring it up to the required level of quality. In either case, the other units are essentially doing the job of this irresponsible unit, which means it no longer has a rational reason for existence within the organization, and can be eliminated. Thus, in a proof by contradiction, I have demonstrated that a unit without any responsibility for quality should not exist within a rational organization. (I am well aware that most enterprises are only rational in theory, not in practice, and such irresponsible organizational units can exist in reality, but I believe my basic logical reasoning is not tarnished by this.)

This then leads back to my original question. Who is responsible for quality? The answer is everyone.

If you find this article helpful, please make a donation.

9 Comments on “Who is Responsible for Quality?”

  1. Tom Walton says:

    “Who is responsible for quality? The answer is everyone.”

    That is very simplistic and not very helpful. Suppose that there is a defined process in an organization for developing software but it isn’t very good. Everyone in the organization can do their very best work and the software can still be crappy. So who is responsible in that case? Suppose that there is a defined process but management doesn’t insist that it be the norm and people organize their own activities according to what they believe is best. That can lead to chaos. Who is responsible? Suppose there is a defined process that is the best in the whole world. But the people who develop the software are not trained to use it. Who is responsible? If there are poor or no tools available, who is responsible? The answer is the organizational element with its fingers on the purse strings bears the responsibility for quality. That is senior management.

    In most organizations there are a few people that are not really trying but the vast majority of people working in software are highly intelligent and highly motivated. Yet we still produce really crappy products. Each of us doing our best is not enough. And the only part of the organization with the wherewithall to make a difference is management. If there is someone in the organization that is not senior management that is making changes that are improving quality then they are doing senior management’s job.

    And you have a theory about that.

  2. Tom, thanks for your response. I’m sorry to hear you didn’t find my answer helpful. I agree it might seem simplistic (I view it as common sense). You raise some good points about the important role that senior management plays in ensuring good quality, but I don’t feel that invalidates my answer. My definition of “everyone” includes senior management :) While senior management can have a disproportionately major influence on quality, I have seen the reverse situation where despite the management’s efforts to emphasize quality and set appropriate processes in place, a developer ignored all guidelines and training and wrote a poorly tested, unstructured pile of code. I must be quick to point out that this was the exception – the majority of people are trying to do their best, as you point out. But I must disagree with your statements that only management can make a difference or improve quality. To me, this is abdicating your individual power / responsibility into management’s hands. From my perspective, there are many improvements in quality that lie outside the control of management, in developers’ hands. Should I use test-driven development to write this next class, or take a few extra minutes to ensure I understand all the boundary cases in this set of requirements? Maybe I should spend a few minutes thinking about why testers keep triggering null pointer exceptions in my code and make some changes to how I code. One reason I find the answer “everyone” to the question of “who is responsible for quality?” personally inspiring is because it does affirm the personal power and corresponding responsibility that each person has concerning software quality. To be a professional software developer requires, I believe, acceptance of this personal responsibility for quality.

  3. I would like to throw in another point here. A couple of times you guys said something along the line of “the process not being followed”. This touches upon a very important topic: Process vs. tooling.

    In my view we should rather look at it from the point of view “how well does the tooling support/implement the process?”. A process that is not enforced, has very little value in reality. And this enforcement has to be done by tools because otherwise it will not happen.

    Also, I think this is one critical aspect why agile methodologies work well: There is proper tooling available. I will soon post something on that topic on my blog. And perhaps a discussion here, can add further valuable input. It’s an important thing we are talking about here.

    Best regards,
    Christoph

  4. @Christoph, good point on tools being really helpful at verifying that processes are followed. I don’t consider tools mandatory – there are ways to monitor adherence to process without tools, but there’s definitely a danger of the imposition of extra overhead (usually in the form of extra forms / documentation to manually create evidence that the process was followed).

    Perhaps more important than ensuring the process is followed is ensuring the process is effective. And this is something that typically requires some sort of metrics or measurement, which tooling can best provide automatically rather than impose manual overhead to collect.

  5. And the monitoring/reporting on rules being followed, is something that really appeals to management. In terms of internal marketing/selling this is usually the road to go when you need money or approval for setting up something proper.

  6. 100% agree with this post Basil. Quality is definitely a team responsibility (ludicrous to think it can be delegated to one group of individuals).

    I wrote something similar (yet different):

    http://rasmusson.wordpress.com/2008/06/10/quality-has-nothing-to-do-with-testing/

    Cheers

    (PS I think I went to school with you at UofA – I was an EE).

  7. @Jonathan, thanks for the comment. I read your article and fully agree as well.

  8. Dorota Smoli?ska-Bartosz says:

    I love this article. Topic is hard and article easy to read. Great combination. But :)

    In my opinion when everyone is responsible – none really is. The good answer in my opinion is process. People wrote in comments that the process is not followed.

    Well that might be really something good: If some steps in the process were skip, and the project is a successful one – maybe you can simplify the process – it is good. Or if you contact with the client, not in the phase when process defines and this results in additional information- good. Or if you do the tests otherwise but as result
    hard to find bugs where detected. Process is a living being. It can change.

    In my opinion the process is responsible for Quality. Process has one owner, but for keeping process alive we are all responsible. The whole team should learn from mistakes, and changing process as a result. RCA is a great tool to do that.

    Regards,
    Dorota

  9. @Dorota, thanks for the thoughtful comment. I agree that process has a role to play, but I have a hard time with saying that an inanimate construct (the process) is responsible for quality. I’d rather say that the process owner is responsible for the quality of the process.

    Since you’re not the first to say that if everyone is responsible no-one is, let me offer a clarification / refinement. Lets say in a team of ten people, one is doing poor quality work. Who is responsible for dealing with this situation? In self-organizing / managing teams, the rest of the team should take responsibility, but ultimately the manager for this team is ultimately responsible for the team’s performance, including the quality of the work being done. This may be a subtle distinction: each person is responsible for doing quality work – and part of the work that a manger does is to handle performance problems within their team.

«    »