Can Quality be an adjustable constraint of an agile process?

Question

When defining the constraints of a project, the classical Iron Triangle defines three concurrent constraints: Resources, Scope and Time. Some more complex models (see the Project Constraint Model) add Quality to the above list.

I understand that view in a classical waterfall view, where quality is a separate process. It makes perfect sense at some level when QA team is some independent entity. The QA team spend time to test product, count defects or missing features and ask for product changes to development team.

But I wonder if it is meaningful to see Quality as an adjustment variable inside an Agile team. As I understand it, Quality should be on par with Velocity. Some structural property of a team that you can measure and try to improve but never really control.

In the past I've seen managers trying to use it as a lever and that lead to unpredictable results. In some cases trying to lower Quality lead to higher Costs, Resources and Development times (defects were caught later in the process, and that has a well known cost). I've also seen exactly the opposite: well meaning teams trying to get higher Quality which translated to heavier processes (more code reviews for instance, or more tests written), and more complex definitions of done... but without any observable positive relationship with customer value reached in the end.

In the end I believe Quality is not a true adjustment variable of Agile process inside of a team, as you can neither control it nor measure it, but merely something like Velocity that can be used for it's predictive power (how many bugs will there be in the final product?) but not really use as an adjustment variable.

Is Quality a legitimate constraint in Agile teams? How should it be measured? Can it be used as an adjustment variable and how?

Answer 1

TL;DR

Quality is a widely-recognized project management constraint. To the extent that one can modify the quality controls applied to a project, one can impact the quality of the deliverables. In addition, by adjusting quality, one can impact other constraints that affect (or are affected by) the quality control process such as schedule or budget.

Agile processes should have explicitly defined quality controls. A well-defined control is measurable, even if the measurement is simply pass/fail, so agile frameworks certainly support the ability to measure "quality" as defined within the project.

Quality Defined by "Definition of Done"

By definition, "quality" is a qualitative assessment. From a purely pragmatic point of view, it means that quality controls are what you should measure against.

Within an agile framework like Scrum, quality should be defined by the Definition of Done. The organization or the team generally defines "quality" in terms of fitness for purpose, and the Definition of Done should therefore describe the steps necessary to certify a potentially-shippable increment as fit for that purpose.

Constraints and Sliders

Within project management, constraints and sliders are generally used to focus a project and to define the trade-offs inherent in a system. The Iron Triangle is an example of such a constrained system, and the paradigm posits that the third side of such a triangle is determined by the other two sides. If your sides are Scope, Schedule, and Cost, then:

• You can control Cost by modifying Schedule and Scope.
• You can affect Schedule by modifying Scope and Cost.
• You can impact Scope by modifying Schedule and Cost.

While a useful concept, the theory of constraints doesn't limit you to exactly three sides, nor does the paradigm insist that the constraints be the same across all projects. In fact, the Project Management Book of Knowledge currently advocates a model with six constraints:

• Scope
• Quality
• Schedule
• Budget
• Resources
• Risk

Perhaps a more agile alternative is Mike Cohn's Project Success Sliders, which provides a less-geometrical way to visualize the trade-offs inherent in the theory of constraints. Among other reasons, I personally recommend this approach over the more traditional triple-constraint precisely because it sidesteps definitional arguments about the commonly-accepted constraints.

Measuring Quality

Quality within an agile process is both measurable and adjustable, and fitness for purpose is tightly bound up with a project's scope. One measures quality against the Definition of Done, and by the metrics associated with any process controls created to meet that definition. For example, a partial Definition of Done for a software project may state that:

• Unit tests shall provide at least 60% code coverage.
• Each feature shall be accompanied by measurable acceptance tests.
• All integration and acceptance tests shall be 100% green at the end of each iteration.
• A build must run without error on a continuous integration server before being added to the iteration's release.

Each of these quality controls can be measured and adjusted to suit the needs of the project. For example:

• Code coverage requirements could be increased to improve long-term maintainability at the expense of higher labor or infrastructure costs.
• The requirement for continuous integration could be sacrificed for speed or budget reasons.

By modifying the quality controls within the process, one can therefore impact other constraints. In addition, by feeding the results of the quality controls into the inspect-and-adapt cycle, the organization gains the ability to gauge the quality of the product and the sustainability of the project itself.

Answer 2

Quality has to be a constraint, whether or not it is measurable by itself or is so intrinsic to scope is another question.

I disagree with your assertion that you can't control quality and that it cannot be measured. The key is that you have to define what you mean by "quality" up front, in other words how well does a piece of functionality have to work in order to be acceptable to the client. That will not only inform your assignment of story points to a deliverable, but will also give you some level of predictability in terms of effects if taking shortcuts.

The challenge is to get the client to define quality objectively. The easy ones are quality measures like "No more than X defects reported in Y transactions during UAT" or "Processing time of less than Z seconds", these can be measured and can give you the opportunity to use them as adjustment variables. But you will also need to consider inherently more subjective metrics like how intuitive the UI is or how pretty the formatting of output is, though if you can turn them into a yes/no type metric you could possibly use those as adjustment variables.