Agile Quality Management Model

Every project is different in many regards and the quality management aspect is not an exception. Most of the time the project would have some type of restrictions and a set of priorities you would need to work on. Different project needs could be illustrated with the following examples:
 

• You’re a project manager and you want to know the maturity level of the team when it comes to practices that drive quality.
• You’re a test manager on a delivery oriented project and want to figure out the ways to improve the existing quality processes.
• You’re a technical lead on a newly launched project with no dedicated QA role in the team and wondering how to choose and adopt the test practices.

How do you handle the above needs? 

Is your strategy based on intuition, your own experience, or existing widely known methodologies? You probably answer: “it depends” and would be most probably right.

In reality, one’s gut feeling might be wrong and the existing methodologies, as well as the experience of the individual, might not fit well as per the needs of specific projects.

Let me introduce the ‘agile quality management model’ to you which could help to handle above needs. It evaluates adoption for different quality practices against the following dimensions:

• Quality Built-in Concept
• Fast Delivery
• Shift-left Test
• Shift-right Test
• Test Strategy Collection
• Test Method Collection

Some of these may look familiar to you as Quality Built-In and Fast Delivery are both concepts from SAFe (Scaled Agile Framework). However, we can extend these dimensions with learnings from lean agile thinking and popular practices in the field of quality analysis. Four new dimensions become apparent: Test Strategy Collection, Test Method Collection, Shift-left Test and Shift-right Test. For each dimension there is a set of evaluation rules to assess the maturity in terms of practices adopted. Overall, it contains 42 evaluation rules.

There are two different modes you can choose from: easy and complex.
For the easy mode the range is:
- N/A (not applicable), 

- 0 - there’s no adoption, 

- 1 - there’s an adoption.

The complex mode allows more granularity with regards to the level of adoption (goes from N/A up to 3), where 1-3 would indicate a different level of practice adoption.
Below is an example using the easy mode on a project #1.





The assessment results can be visualized in two ways - the radar chart and scale chart, which features a single project over a period of time AND can also be a comparison between different projects.




For the ease of utilizing the model, find this google sheet template. It describes the evaluation rules in detail and helps with auto-calculations and chart generation. Here is a demo of how this google sheet tool can be used.

If you’re  wondering how having a chart with numbers would help you on the project, let’s focus on the three needs we posted previously.
 

• You’re a project manager and you want to know the maturity level of the team when it comes to practices that drive quality.
  To benefit from the model, the first priority would be to make sure the team has a firm understanding of the concepts and the evaluation rules. A scheduled set of interviews with all relevant stakeholders/teams is highly suggested to assess the familiarity of the team with the terms, concepts and clarify any questions that might arise. Then the team members need to apply the evaluation rules to evaluate their project. Once this is done, the project manager can clearly see where the gaps are to feed this into the planning of the project, be it  the skills we need to look out for or weighing the possible risks vs the cost of effort to improve on some area in terms of quality.
   
• You’re a test manager on a delivery oriented project and want to figure out the ways to improve the existing quality processes.
  Once the project is evaluated according to the model and quality management maturity results are generated, a Growth/Share (Boston) matrix can be used to further prioritize the areas to work on and create actionable plans for specific issues. This brings the team closer to the desired state.
   
• ​You’re a technical lead on a newly launched project with no dedicated QA role in the team and wondering how to choose and adopt the test practices.
  Prior to applying the model to the project, it’s suggested to first get the detailed trade-off chart in terms of different aspects including, but not limited to, product quality, user experience, technical debt, etc. from stakeholders. The next step would be to pick a set of practices from evaluation rules to fit the tradeoffs.

Before the end, I want to give thanks to Kateryna Nemesh’s contribution and the reviewer, Santosh Joshi, and Kelvin Nicholson for his great support.