Quality advocacy

A few months ago, ThoughtWorks colleague Alister Scott coined the role “quality advocate.” I’m totally sold on it and have been talking it up wherever I go. Alister defined the role in a very practical way:

They work closely with other team members to build quality in, whether that be though clear, consistent acceptance criteria, ensuring adequate automated test coverage at the unit/integration level, asking for dev box walkthrough, or encouraging collaboration/discussion about doing better testing within the team.

Another ThoughtWorker, Sam Newman, described the erstwhile agile QA (assurance/analyst) role, but I think that his definition also gets at the heart of  the role of quality advocate:

They are responsible for understanding the current level of quality, and working with the wider team to implement/change processes to ensure that quality is of a sufficient level. They should know when to test, and when not to test. When to automate, and when not to automate. They should carry out root cause analysis of defects when the occur, in order to understand if the processes need to change. They should partner with everyone from the BA to operations to help ensure that everyone is working towards the goal of delivering a quality working product into production. The typical QA on a team should have a more holistic understanding of the system than the average developer – they need a wide view of the system and the processes being used to create it. Oh, and as the kicker, if they want to write automated tests, then they need to write code as good as the developers.

Now that we have a working definition of the role, I’d like to try the easier task of defining the practice:

Quality Advocacy is a software-delivery practice of guiding the whole team to build the right product and to build the product right by fostering a mindset of continuous process improvement, taking a holistic view of the product and communicating constant awareness of the product’s quality.

To expand on a few of those points:

  • Whole team: The entire delivery team shares this practice, though one or more people on the team lead or principally guide, since most other roles on the team are more focused on certain aspects.
  • Build the right product and to build the product right: This speaks to both internal and external quality, but also to an ability to work up- and downstream with various business and operations stakeholders.
  • Fostering a mindset of continuous process improvement: This is much art as science, and the practice involves helping people share this mindset. Sam mentions the power of root-cause analysis, and Alister talks about “encouraging collaboration/discussion about doing better testing within the team.”
  • Taking a holistic view of the product: Alister mentions practices like “clear, consistent acceptance criteria, ensuring adequate automated test coverage at the unit/integration level,” both massively helpful. A holistic view extends beyond the core agile team to understand the business value of the product and the “last mile” of delivery, as Sam infers by “the goal of delivering a quality working product into production.”
  • Communicating constant awareness of the product’s quality: Feedback from a properly aligned (aka pyramid-shaped) test suite, status of the team’s delivery pipeline and quality metrics (including team-level measures like lead/cycle time) are all part of this.
Advertisements


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s