We experience that teams and organizations have become blind in recognizing potential for improvement. And when improvement needs are there, they have no clue where to begin improving.
In this blog Bert Linker and Jan Sleutjes shed a light on the model that he uses to help teams and organizations with Improving Quality.

Improving your Quality Engineering

Quality engineering should be the subject of continuous improvement. In our book “Quality for DevOps teams” (section Quality Measures) it is emphasized that Quality Engineering (QE) consists of multiple quality measures that can be grouped into three core elements: Build Quality in, Provide Information about Quality and Improve Quality. As per definition QE is a joint responsibility of team members and their stakeholders.

But does everyone involved actually feel responsible and how does that show? And how good is the team in building in quality? Does the team provide sufficient information about quality? And how is the quality perceived by the stakeholders and business people?

If these questions emerge, they should be addressed during the retrospective as part of continuous improvement. From our experience it is the challenge that many teams and organizations face that they may have become blind to recognize potential for improvement or they have no idea where to begin improving. Maybe even the problem stretches beyond the sphere of influence of the team or even the department. In all cases, that is where an expert view helps. It often takes a fresh pair of eyes to put things into proper perspective, while being unbiased and often not being regarded as a threat.

You need an approach and a model

Improvement should lead to increased business value. “Value” is not always ‘a team thing’. A team operates within an organization where business drivers and IT goals are the basics to work towards. So improvement is only relevant when it contributes to these basics. Our model starts here.

To cope with these challenges, we have, over the last years, developed our model, which is used in a ‘Quality Improvement Scan’, with a few additional starting points in mind:

The model is primarily intended as an improvement tool rather than as a measuring tool.
- Since there is not just one right way of working, we use questions that give insight into the why and how: it’s up to the expert who performs the scan to determine if the implementation is the most adequate in that situation.
- It is possible to score and compare teams, but only as a means, never as a goal itself. Quality is not a game where you can accrue points.
Teams are self-managing but operate in the service of the organization and are therefore bound by its “rules of the road.” Furthermore, their improvement also depends on collaboration between teams and the way they are facilitated by the organization. Therefore, we look not only at teams but also explicitly at their surroundings. Therefore, the Quality Improvement Scan’ includes questions at both the team and organizational levels.
The model takes different aspects of quality engineering into account, which we call key areas. They are a manageable and informative group, with sub areas.

QA & Testing having the tools and knowledge within the teams for effective Quality Engineering
Automation enabling cross-functional behavior and fast feedback
Infrastructure needs to fit the demands and requirements of both team and organization
Quality as Culture have specific focus on increasing Quality awareness and everyone understanding their part in delivering quality products
Governance clear processes, guidelines and responsibilities increase transparency and sharing information within the organization
Transparency have insight in progress, quality and costs at all time both at team level as well as at organization level.

We have applied this model successfully for several years now in various Scans! Also what we have learned is that to use the model to its best it is key to scope your group, like: How many teams?; including system/support teams?; including the responsibility of the stakeholders/organization?; what subject to focus on?; how to gather the information?; etc

Your take away

As a result, the scan provides insight into where teams and the organization can improve within the key areas and where to start. It also provides insight into the interrelationships between teams and the organization. This indicates the extent to which the teams’ autonomy aligns with the level of support provided by the organization.

At its simplest, the objective is to ensure your quality engineering is (continuously) improved:

Insights into good practices at the performing and organizing levels, and how other teams in the organization might benefit from those good practices.
A holistic overview of improvement areas within both the performing and organizing levels.
Improvement suggestions, also possible to align them in a roadmap, that contribute to the identified business and IT goals, with a brief business case.

Post blog note:

The Quality Improvement Scan is part of the Agile Quality Improvement framework and you can learn more about it in the training course “TMAP Organizing built-in quality at scale”.

Published: 7 October 2025
Authors: Bert Linker, Jan Sleutjes