Ask an agile practitioner what they know about quality, and it's quite likely you'll be told it's "invariant." This is received wisdom, a lesson hammered into skulls using an iron triangle. At the three corners of that triangle are the time, cost, and scope of a project. If one of those variables changes, then at least one of the others must, as well. Reduce the funds in the pot, for example, and you can no longer expect the same amount of work to be done within the same timeframe. The key characteristic is that quality should always remain constant. Quality bolts the center of the triangle to the production floor while the variables around it flex. That's where the iron is: right there in the underpinning of quality and professional standards. It ought to be the one thing that remains consistent in the face of change.
To agile and lean practitioners, however, the assertion of quality is rather more nuanced. For one thing, it is subject to continuous improvement. The qualities of product and process are not invariant but are open for inspection and adaptation. Quality is a complex variable to be analyzed in a timely manner and then ratcheted up.
In Scrum, for example, the Definition of Done may be revised so that the qualities observed in future sprints are enhanced. Having said that, there is a sense in which quality can indeed be held to be invariant. During each Sprint, all work must be completed to the standard which will make the increment fit for release. There are no exceptions. There are no items of work which, once in progress, can circumvent that standard or be held to a lower tolerance. The Definition of Done must hold.
A Definition of Done can also be expected in a DevOps system, where it will assert release-level qualities with an equivalent degree of rigor. However, since a DevOps stream does not typically operate in terms of Sprints but rather in terms of a continuous flow of work into production, there is no Sprint increment to be compromised by varying the quality of work performed. Each item of work can be discretely releasable in its own right. This brings opportunities for varying the quality of service which is offered to consumers.
For example, a team may establish a Kanban system where work is subject to different standards of handling such as Gold, Silver, and Bronze. These standards may correspond to different service level agreements for work of different types or for consumers of different grades. The quality of work undertaken can be expected to vary accordingly. A certain quality of service could assert the tolerances of the finished product or perhaps the turnaround time of a work request once it is brought into progress.
Ironically, perhaps, Scrum Teams can also be familiar with the Quality of Service pattern once it is seen in this context. Many teams are expected to support a "fast track" service level for production defects or other significant incidents. These events will preempt any work that is currently in progress or which has been planned into the Sprint Backlog. In effect, the team is not focused on product development but also on maintenance activities of one sort or another. A "fast track" grade implies that a team is not following Scrum at all but a Scrum-Kanban hybrid. By varying the quality of service, they hope to support both project and business-as-usual modes of operation, although they can dedicate themselves to neither. Often resorted to as a cost-cutting measure to avoid the expense of funding separate teams, the arrangement means that the rules of the Scrum Framework are no longer strictly observed. The Sprint Goal is quite likely to become unachievable once fast-track work rolls in, and the commitments that a team is expected to make therefore ought to be revised accordingly.
Quality of Service
Intent: Vary the way backlog items are expedited and handled.
Proverbs: Some are more equal than others.
Also known as: Fast tracking (when used in a Scrum or Scrumban context).
Not all items on a backlog are necessarily subject to the same terms of service. Examples include enhancements and defect fixes, the impact or severity of which may vary. The quality of service provided to those backlog items must be allowed to vary as well. Note that this motivation typically applies to Business As Usual workstreams such as technical support. The quality of project work should be invariant.
A team selects which items from a backlog to action according to the prescribed Quality of Service and only then will the order of items be considered. The Work In Progress limit may be revised to support the terms of service of a selected item.
Quality of Service is applicable to situations where the handling of work varies by context. Examples include Service Level Agreements, where the demands of certain clients may be prioritized over others; variations in the skills or technologies required for the implementation of a backlog item; or the prioritization of emergency work over that which is in progress.
Quality is no longer invariant. The order of backlog items only partly indicates their relative priority since their Quality of Service is also considered.
Quality of Service is allowed to vary in most Lean-Kanban implementations. These teams provide Business as Usual work in a support context. This pattern is not found in DSDM, XP, or Scrum as these methods hold quality to be invariant. Hybrid Scrum-Kanban implementations that allow the Quality of Service to vary (for example by supporting a “fast track” or “expedite” class of service) are widespread.
How to Handle Defects in Agile Projects, by Eric Landes.
Kanban: What Are Classes of Service and Why You Should Care, by Dennis Stevens.