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.
