QA, Quality & SPeed

Intermediate

difficulty

Stage 3

Agile IQ® Level

Quality

Practices

Scrum

Framework

Introduction

As early as the 1950s, Deming argued that downstream gates for assessing quality don’t build-in quality. They only identify what re-work is needed.

Rework Slows Delivery

QA’s need for teams to attend to the errors they find force people into rework-mode.

Team members spend time fixing errors.
Focus is taken away from delivery.
Delivery slows.

In this model, no time is spent on learning why the errors occur in the first place and what actions are needed to ensure the errors don’t happen again. This is why Deming argued that quality should, instead, be “built-in” at every step.

Define Quality

Scrum teams define quality in their Definition of Done. This list outlines all of the activities, standards and contraints that downstream QA teams would investigate and asks the team to:

Plan how they will deliver work accoring to the Definition of Done.
Release work when it meets the Definition of Done.
Elicit feedback from work by demonstrating it meets the Definition of Done to stakeholders.
Take feedback from errors and lapses in quality, including from its use, and ascertain how to improve the Defintion of Done in a Retrospective potentially in each and every Sprint (not at the end of the project).

What should be in your Definition of Done?

A team’s Definition of Done should be taken from its organisations rules, policies and processes, including:

Auditing requirements.
Security standards.
Compliance standards.
Industry standards.
Customer expectations of quality.
Coding and testing standards, if it’s a software team.

Some examples include:

Team	Quality Activity Examples
Software	Code review (don't make your own homework). Code check-in and merged with the main branch. No severity level 1-2 defects. Testing complete: Unit tests, functional test, smoke tests, integration tests, regression tests. Design "as-built" documentation updated.
Marketing & Comms	Copy is in plain-English. Minimal use of jargon. Metadata and tags used from common library. Assessed for alignment with SEO strategy. Work is spell and grammar checked (US-English). Copy is peer reviewed. Publishing automation setup. Comms calendar updated. Copy stored and version controlled in the document management system.
Data Science	Content in English (US). Peer reviewed. Macro library updated. WDB file created and stored. Sent for approval to the customer.
HR	Peer reviewed. Copy in plain-English (Australian). Alignment to HR policies confirmed. Stored in the document management system. Templates updated. Sent for approval.

Embed QA talent in the team

Agile teams are cross-functional, designed to operate as a single delivery unit. Where they rely on external teams, such as a specialist QA team, these handovers create delays in the delivery of value.

When designing teams, consider the skills needed to create quality and whether putting people with QA skills into the team is an important step to removing handovers and improving quality.

Expect time savings

Building-in quality takes time. After a few months, expect the following impacts:

Less time spent fixing errors from QA.
Quality should improve within a few months.
Time to deliver the same work should now be quicker.
Less time to deliver the same work means reduced operational costs.
Time savings mean the team can deliver more work.
Productivity should increase within a few months.

All fields are required.