Agile Quality Patterns is a collection about how to infuse quality assurance activities and roles, as well as system quality-related activities into software development projects. For a short description of each pattern, see Agile Quality Pattern Gists. Lengthier pattern descriptions can be found in individual papers in the collection.

The patterns—written during a span of three years (2014-2016)—were gleaned from a variety of sources. These patterns were originally written and workshopped at various patterns conferences. Up to now they have had limited visibility.

Some of these patterns came directly from experiences working with clients, adapting system quality-related activities to fit into a more incremental software development approach. Some are based on material drawn from training courses I developed and taught. I also had many interactions with authors of Agile Experience Reports who shared their stories of finding effective ways to be the “quality advocate” on their team and introducing others to quality-related activities. And I had many discussions with my colleagues and pattern co-authors (a special nod to Joe Yoder).

At the time we wrote these patterns, the world of agile software development was quite different. Organizations were running big experiments on how to become agile. Traditional software roles were being questioned. What value did they really bring to product development?

Some organizations, in streamlining their product development efforts, “blew up” testing departments and laid off quality assurance (QA) personnel. Other organizations embedded testers in development teams. System architects were shifted into product owner roles. Architects who still had the title of software or system architect, struggled with how to engage with development teams. How could they follow through to ensure system quality requirements were understood and given enough ongoing attention?

I suspect that those organizations hoped that by following agile development practices and delivering software incrementally, that, well, software quality would take care of itself.

Integrating the concerns of testers, quality assurance folks, system analysts, technical specialists, and system architects and their concerns into an agile development and delivery pipeline, can be a challenge. It takes ongoing effort, experimentation, and “tweaking” of processes. Quality assurance activities need “tuning” to fit into incremental delivery cycles. And creating teams comprised of individuals with diverse interests, skills, and backgrounds involves more than simply shoving people together. These patterns can be of use to those who want to pay more attention to software quality.