Who should be accountable for Quality?

According to you, which team should be accountable for the quality of a product? Development Team, Quality Assurance Team

PS: "Both" is not an option because Accountability can only be with one. :)

Sachin Shenoy had asked this interesting question on LinkedIn (here). There were many answers as comments to this post. Because of the commenting system's nature, most of the comments were cryptic or lacked context to understand the commenters' point of view. It was also hard to derive any actionable insights.

To arrive at an actionable answer, we have to understand and agree on some fundamental constructs. These constructs assume that the product referred in question is a software product.

What is Accountability? Is it different from responsibility?

In many contexts, we use Accountability and Responsibility as synonyms, but they have distinct meanings in the business world. 

There is a reason why the original question points out "Accountability can only be with one". I would extend the notion to assert - "Accountability can be only with only one person".

To understand this, let us look at the root of the word - Accountability. "Accountability" stems from late Latin accomptare (to account), a prefixed form of computare (to calculate), which in turn derived from putare (to reckon). The root indicates that Accountability is associated with counting and related to someone who can count and understand what is being counted.

For example, the CEO is accountable for the outcomes of a business. If the business if not performing, the board replaces the CEO. Accountable means you understand the counts (business metrics) have the power to change things when the counts are not acceptable, and if you fail to do so, you have failed in your Accountability. For example, if the CEO finds that the sales number are below expectations, she can change the sales head, change the product, change the market, change the strategy etc. To be accountable also means to be empowered to change.

On the other hand, responsibility means doing a thing in response to an ask, using your ability.  

"Responsibility" comes from an obsolete French word "responsible", itself coming from a Latin word "responsabilis", the past participle of "respondere", meaning "to respond".

For example, as a salesperson, you are responsible for achieving your sales quota that you agreed to at the beginning of the quarter. You have to achieve this using your ability to sell. If you cannot achieve the quota, you can either reduce the agreed quota in the next quarter by pointing out the product's lack of demand or start looking for another job. 

Accountability implies measuring the expected outcomes and the ability to course-correct if there are deviations. Responsibility implies execution to the expected outcomes using your ability.

PS: There are organizations with cultures that transcend this difference where people with responsibility can influence people with Accountability. For example, a sales team where the salespeople can understand, communicate the reasons for the product's lack of demand and effect a change.

What is quality in a software product?

From a business point of view, the Quality (good) of a software product can be defined as "The instances when the product functions the way the user expects it to function". When the product functions otherwise, we can say the product has quality issues.

This definition would confuse the different teams involved in software development because they do not perceive different definitions of quality they draw, based on the organization structure. 

Based on the team, one belongs to or the role one plays, one can define the quality as:

• The product functions according to the product manager's defined acceptance criteria or the test cases that we defined - QA Engineer. For example, when I enter an invalid id in the "to" field, the product shows an error listed in the test case.
• The product functioned as defined by the expected system design and defined use cases - Engineer. For example, the system stores the message as "sent" when the message gateway is available and sent.
• The product functioned as per my definition of my understanding of the user's expectation - Product Manager. For example, the system sent the message to the intended recipient by email when the user clicks on the "Send" button.

We can now see that the "issues' around quality can creep in multiple places - 

• The product manager's misinterpretation of the user expectations - User expected instant messaging, not email.
• The missed use case in the definition of the use cases - The messaging system can be down at a given moment, and hence the system cannot send the message.
• The user keeps clicking on send without entering an id.

The ability to understand the different issues requires different skill sets. We cannot expect one person to have all these skill sets. The entire team should be "Responsible for Quality" and treat quality as "What the user preceives?" irrespective of "What the organization structure is?".

To define who should be held accountable, we first have to understand the cost of fixing quality issues.

Where should we identify quality issues and why?

If your users perceive that your product has quality issues, it will affect business. So, in general, it is desirable to build a product that is perceived to be of high quality.

The cost of software changes increases, the closer it is to delivery. Hence fixing quality issues that require changes to the software are higher, the later they are identified. Paradoxically, we can identify some issues only after building the software for e.g. misunderstanding in the user expectations.

So building high-quality products, require faster feedback cycles to all the people in the development team. As we noted in the previous section, identifying different issues requires different skillsets. 

As a team tasked with the responsibility of ensuring the quality of the product, the team members should complement each other to provide insights as early as possible during the entire development process.

The following is one example where let us assume that the development team follows some variation of Agile scrum.

• Product team gets feedback from dev and QA engineers on the high-level feature/solution approach once they prioritize it in the backlog.
• Product team gets feedback from dev and QA engineers once UX is ready. 
• Product team shows the prototype/mock-up to the users to get feedback.
• Product team grooms the details in collaboration with dev and QA engineers. They talk about the tradeoffs involved in validating the solution vis-a-vis delivering a solution that handles all the use cases.
• QA is involved in the kick-off of the epic/story.
• Product & QA work with the development engineers to do informal testing as the development happens.

Who should be made accountable for "Quality"?

Let us establish the necessary skills, responsibilities and power of the person accountable for quality.

The accountable person should

• Have to maturity (proxied by experience) to understand the quality as perceived the user.
• Analyze the quality issues data, identify trends.
• Have communication skills to surface up the issues and help the teams identify the root cause.
• Have sufficient expertise to suggest remedies and tradeoffs.
• Have earned the teams' respect across the functional boundary, esp. engineering and QA - as they usually are in more numbers.
• Have good relationships across the functional teams to influence them without any reporting hierarchy.
• Be able to escalate or influence senior leadership if she is not able to effect change.
• Have time to participate in multiple meetings/rituals to ensure that the feedback cycles listed in the previous sections actually work.

In most of the teams I have worked with, the person who meets the above criteria is usually the one who is playing one of the following roles

• Tech lead
• QA lead
• Delivery/Program lead (Large organizations)
• Product Owner (on fewer occasions)

The actual person who becomes accountable would depend on your organization's specific structure and the abilities of the people who play these roles.

Should teams have a separate "Quality Assurance" team?

This question needs another long post. The TLDR; is below.

When you are writing software, you are in a creator mindset and trying to get something done. This creator role is what a development engineer plays. It would be best to have deep user empathy and a destroyer mindset (how can this fail) for testing quality. This proxy user role is what a QA engineer plays. 

Switching context between these two mindsets constantly challenges one person to understand tradeoffs profoundly, and it comes with experience. 

So unless you have long-living teams with experienced. development engineers, it is prudent to have QA engineers as well in the same team (not as a borrowed resource from a central team)

The joke that justifies the picture of the post

Development team marked the "bar module" as done. The QA team then Orders a beer, Orders 0 beers, Orders 999999999 beers, Orders 9.99 beers, Orders a lizard, Orders -1 beers, Orders a sfdeljknesv. They certify it for release. The first customer comes in and asks - "Where is the rest room?". In a flash, the bar module crashes.