The quality practices assessment model (QPAM) explores quality aspects that help teams to deliver in an agile way. The model covers both social and technical aspects of quality; it is used to assess the quality of the team’s processes and also touches on product quality. With an assessment, teams can look at where their practices lie within the quality aspects and decide on what they want to improve.
Janet Gregory spoke about assessing quality using this model at Agile Testing Days 2022.
The quality practices assessment model has ten quality aspects. Each quality aspect has several practices to be considered, although Gregory mentioned they are not specific agile practices.
The quality aspects are:
- Feedback loops
- Culture
- Learning and improvement
- Development approach
- Quality and test ownership
- Testing breadth
- Code quality and technical debt
- Test automation and tools
- Deployment pipeline
- Defect management
The first three are social aspects, how people work within the quality system, Gregory explained. The following two are a combination of social and technical, and the last five are purely technical aspects of the system.
Gregory mentioned that the behaviour exhibited by teams for each quality aspect, falls into one of four dimensions: Beginning, Unifying, Practicing and Innovating. This does not mean that every quality aspect for a team falls into the same dimension, she said.
Exploring the first quality aspect of feedback loops, the practices looked at are communication and feedback cycles within the delivery team, between the customers, stakeholders, and the delivery team, and also between leadership and the delivery team.
Gregory explained the role that feedback loops can play in quality:
We list feedback as the most important quality aspect, which can take many forms. Teams use feedback to determine whether they are on the correct path to create a valuable solution for both customers and the business. Communication among team members is also a form of feedback to understand their current state and how to achieve their goals together.
The faster the feedback loop, the easier it is to make adjustments as needed, Gregory concluded.
The quality practices assessment model is described in the book Assessing Agile Quality Practices with QPAM which Gregory co-authored with Selena Delesie and is listed on Gregory’s publications page.
InfoQ interviewed Janet Gregory about the quality practices assessment model.
InfoQ: Looking at the 7th quality aspect, what can teams do to increase code quality and reduce technical debt?
Janet Gregory: Technical debt is anything that needs fixing, improvement, restructuring, maintenance, or even further testing later. It exists because the team took a shortcut to deliver the software "today". Unfortunately, some shortcuts never get addressed.
Addressing technical debt is first about recognizing it exists, then planning how to address that hidden backlog. Outstanding defects are a good indication that technical debt exists.
Start by creating simple coding standards that all programmers can live with and hold peer reviews on any new or changed code going forward. This helps eliminate "new" technical debt.
Create an impediment backlog listing the areas that have been compromised, including areas with large concentration of defects. Plan to tackle one of those areas regularly - perhaps one every iteration. With every new story, look at the code and incorporate the standards as needed, building in testability and adding appropriate automation for fast feedback.
Teams who prioritize continuously addressing technical debt can safely modify existing code, create new features, and reliably deliver high quality and high value to their customers.
InfoQ: How can teams use the model to improve their quality practices?
Gregory: Once an assessment has been completed, teams can look at where their practices lie within the quality aspects. Once a team knows where they are, and reflects on what they want to improve, they can look at the rest of the model to see what might be possible. Teams may decide that their level of a practice/aspect is where they want to be, and that is ok.
The model is meant for teams to dig deep and reflect on the quality of their products and the quality of their agile practices. It may extend to multiple teams to reflect on the entire organization.