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:
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.
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.