Who Owns Quality in Agile?
Extrinsic quality is the most important measure of quality. Scrum teams need to balance long-term performance and stability with short-term goals for delivery and value.
Join the DZone community and get the full member experience.
Join For FreeIn Scrum, the expectation is that the entire Scrum Team owns quality, but what does that really mean? Isn’t the Product Owner only worried about value? Doesn’t the team own all the testing? Don’t they really own quality? Like many other concepts in Agile, the answer to who owns quality is subtler than that, and as my first Agile mentor liked to say, “It depends.”
Before we define ownership, let’s define what we mean by quality in Agile. In terms of Agile software development, Jim Highsmith in Agile Project Management: Creating Innovative Products identifies quality as two points of the Agile Triangle: Intrinsic quality and Extrinsic quality.
This suggests that the definition of quality comes from two different sources, externally from the customer and internally from the development teams.
Defining Quality
Joseph Kelada, author of Integrating Reengineering with Total Quality defines these two aspects of quality:
Intrinsic Quality is all of the qualities that are built intothe product: suitability, durability, reliability, uniformity, and maintainability. This type of quality can be measured quantitatively, such as test coverage, bugs per line of code, escaped defects, cohesion, etc.
Extrinsic Quality is the buyer’s perception of quality and thevalue to the customer. This is a more qualitative measurementbased upon sales, usage, and customer feedback.
When most people think of quality, they think of intrinsic quality, which is why we have team members who are Quality Assurance specialists. They aren’t evaluating the customer’s perception of the product, they are performing verification and validation (V&V): Are we building the system right? Are we building the right system? The goal of V&V is to test the product against the writtenbusiness and technical requirements.
On Agile projects, we build products with the premise that every requirement ties back to a customer-facing vision and value proposition. If a requirement doesn’t align with that vision, then it doesn’t matter how reliable it is, for it is of no value. With each iteration and release, the goal is to provide the highest value features balanced against the cost to develop those features. This is the goal of each Sprint in Scrum.
Given this, I would suggest that Jim Highsmith’s Agile triangle is visually inaccurate. It gives equal weight to intrinsic andextrinsic quality. The reality is that in order for organizations to compete, extrinsic quality, in most cases, is more important. Remember, the first principle in the Agile Manifesto is, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
The Role of Product Owner in Quality
I recently encountered a simple example of how a Product Owner addressed intrinsic versus extrinsic quality while facilitating aSprint planning meeting. A developer submitted a backlog item to refactor some previously written code that was causing a large increase in storage each time a report was run. This was an unexpected outcome of a customer-facing requirement. The assumption from a technical perspective was that the storage issue was egregious and the impact was large, but the effort to refactor the code was large as well. In a traditional software development environment, it would be assumed that a defect like this would automatically be addressed in the next release. On this high-performing Scrum Team, the Product Owner questioned the value of addressing the defect in this release.
This involved an in-depth discussion of the issue and the options, and ultimately it came down to a quantifiable measurement. The technical debt of that storage issue could be measured in dollars and could easily be compared against the business value of other requirements. Once the issue was quantified, the Product Owner removed the requirement as a candidate for this release. The Product Owner had more “valuable” items slated for this release. Not all issues of extrinsic quality versus intrinsic quality can be that easily quantified, but in mature Agile teams, the correct dialogue will occur and the decision that is most often made will balance the short-term customer facing goals with the long-term viability of the product.
Quality Ownership
So, back to the original question, who owns quality? When speaking of Agile roles, it is easiest to use the Scrum roles. In the most recent annual VersionOne Agile survey, 75% of companies practicing Agile are using Scrum or at least the Scrum terminology. The roles of Product Owner, Scrum Master, and Development Team have become ubiquitous terms in our industry.
In the Scrum Guide, it states, “As Scrum Teams mature, it isexpected that their definitions of ‘Done’ will expand to includemore stringent criteria for higher quality.” “Scrum Teams” includes all three Scrum roles. So this would presume that the entire Scrum Team owns the intrinsic quality. However, the Guide also states that the Product Owner is responsible for “Optimizing the value of the work the Development Team performs.” So, ultimately, the Product Owner owns extrinsic quality, and as we just discussed, this may supersede intrinsic quality.
The Reality
Though organizations understand this theoretically, this is seldom put fully into practice. For the Product Owner to truly own quality, the following best practices would need to be in place:
Quality Assurance specialists would functionally report to the business.
The Product Owner would sign off on design documents.
Performance and non-functional requirements would be approved by the Product Owner.
All defects would be approved by the Product Owner before being added to the backlog.
The scope of pre-production testing and readiness would be approved by the Product Owner.
Those changes and many more would need to occur, both culturally and organizationally, for an organization to truly align quality ownership with the Product Owner role.
At minimum, in order for the Product Owner to truly own value and quality, the Development Team needs to educate the Product Owner on the cost and effort of addressing intrinsic quality issues. The Product Owner needs to understand that well-written code costs less to support and maintain. Technical debt eventually needs to be paid back and only an educated Product Owner can make the best decision as to when. This often creates conflicts within newly emerging Agile teams. In my experience, especially with large traditional organizations, this can shift the ownership of building the product away from the IT department and more to the business. This is intentional in Agile so that we ensure that delivering value to the customer is a primary goal.
Personally, I have seen too many well-built, highly reliable, stable products sit on a shelf because ultimately they missed customer’s expectations or were too late to market. Often a product that was not built half as well can dominate market share. There are exceptions to this of course, but for those companies at the forefront of their industries, they are adopting a Lean and Agile approach to software development that frontend-loads value. They then add stability and reliability once the product achieves traction and validates the ROI for both the initial investment and continuing investment.
It is a team effort to understand how each requirement, whether technical or functional, will drive value to the customer. This type of understanding requires close collaboration between the Product Owner and the development team. It means truly embracing the “one team” concept and allowing full transparency into the decisions about which requirements make it into each release. Ultimately, it will be the Product Owner’s decision, but this can only occur in an environment that has truly embraced what it means to be Agile.
References
Joseph Kelada, Integrating Reengineering With Total Quality
Jim Highsmith, Agile Project Management: Creating Innovative Products
10th Annual VersionOne Survey
Jeff Sutherland, Ken Schwaber, 2016 Scrum Guide
More Agile Goodness
If you'd like to see other articles in the guide, be sure to check out:
Published at DZone with permission of Dan Tousignant. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments