A minimalist framework to think about quality problems

Every quality problem is either a problem in the quality bar or a problem in enforcing the quality bar.

To consistently deliver quality work, we need a system that helps us achieve that. I want to share this simple framework for improving and sustaining quality that I learned while working at Aurea Software.

The diagram shows the flow of work. On the left side is a request to the team. On the right side is its output.

Three quality bars

The quality bars are the three gateways where work is accepted/rejected. We need to work them backward.

External quality bar

We can't fully define or know this quality bar upfront. We are going to learn it as we get feedback delivering work to customers. When the customers receive a product or service, they know if what they received has good quality or not.  

Example: Incidents and defects are a common way of getting feedback on quality.

Internal quality bar

As we learn the quality bar from our customers, we want to translate it into a checklist of things to check before delivering work to them. That checklist is the internal quality bar. It is there to avoid giving low-quality work.

Example: Automated tests, manual verification and code reviews are frequent activities on an internal quality bar checklist.

Input quality bar

The input quality bar is what our team needs to know to deliver good quality work. If the team does not get this information/inputs, it won't produce the work with the accepted quality.

Example: Getting a good list of requirements and acceptance criteria are usual quality bar items for feature work. Steps to reproduce are another example of quality bar items for defect work.

Who should do these checks?

In this model, the external quality bar is implicitly "checked" by your customers, while the internal and input quality bar are the ones in control for your team.

There are different alternatives for who verifies it in the team:

  • The person who is doing the work.
  • Another person in the team (peer review)
  • A specific role (i.e., QA)
  • Automated checks

These options optimize for different goals (autonomy, cross-training and specialization). For this model, all are valid options and it doesn't matter who does it.

Using the framework to frame quality problems

Every time your team faces a quality problem (external quality bar failure), you can frame it in the following ways:

  • we didn't check our internal quality bar before making the change, so we had a problem enforcing the quality bar.
  • we used our internal quality bar, but it was not good enough, so we need to improve it.

Based on the cause, you can focus either on enforcing the internal quality bar or improving your set of validations.

Follow me on Twitter for more articles on leading software engineering teams. I publish twice a week.

Matias Lespiau

Matias Lespiau

Madrid, Spain