Agile Quality Management – Is There Such a Thing?

by | 17.10.2022 | using objectiF RPM

Nowadays, there is a lot of talk about the need for companies to have business agility. This means the ability to move dynamically in a volatile, uncertain, complex and ambivalent (VUCA) business environment whilst pursuing the goal of remaining relevant.

Business agility has three dimensions: the Value Proposition that a business can offer, its Quality, and the Speed at which its value can be established. All three need to be optimized to their full potential. Failure to do this for even one dimension can create the following problems:

  • Customers won’t see value in a service or product, regardless of how innovative it is.
  • Without quick and dynamic development and marketing, a product or service will not be able to seize market opportunities and will be left behind by market competitors.
  • Even with value proposition and speed, customer interest will wane if the quality is lacking.

microTOOL Blog: Dimensions of business agility

Fig. 1: The three dimensions of business agility

Now we know what the possible problems these shortcomings can make, a few questions remain; what does the combination of innovative value proposition, quality and speed bring? What will it mean for quality management? Does quality management even have a place in a VUCA business environment? If yes, are there any changes that need to be made?

Pre-programmed Conflicts?

Quality management and agile management. Ostensibly, these two concepts are worlds apart.

Central to quality management is a quality manager. They are responsible for establishing an organization’s Continuous Improvement Process (CIP). This is done, primarily, by analysing existing work processes and outlining possible improvements (i.e. employing new methods and tools). They also need to ask the right questions; what needs to be documented? What should the contractual obligations between an organization and its customers and contractors look like? Additionally, a quality manager has to delineate regulations and implement them within an organization.

Meanwhile, the agile management approach, which has been formed over the last 20 years mainly by software developers, is best summed up in the agile manifesto [1]:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

These four guiding principles appear to be at odds with the strict regulations associated with quality management. However, it would be a mistake to think that these four principles dismiss the need for processes, tools, comprehensive documentation, negotiations, and good planning. This would be disastrous. Instead, the agile manifesto stresses that they are of secondary importance to the guiding principles of the agile approach.

So, how can these two seemingly incompatible approaches be combined?

Conventional quality management aims for long-term stability through establishing regulations and decision-making processes in an organization’s hierarchy. Its rigid nature makes it inadequate for dealing with the quickly-changing markets companies are faced with nowadays. Therefore, for companies depending on high business agility, their quality management must also be agile. This is a challenge; however, it is manageable because an agile approach doesn’t exclude clear rules or structured processes.

The Path to Agile Quality Management

A shared understanding and responsibility for quality can lead to a new form of quality management in agile organizations.

Crucial to agile working is being in close collaboration with customers. This involves establishing requirements, quickly delivering on them, and reviewing them in feedback sessions. This helps to avoid developing a product or service that doesn’t meet customer requirements. This approach also helps an organization better understand its customers’ wishes, unspoken expectations, functional requirements, and emotional needs. By gaining such an understanding, an organization is better prepared to deliver on those requirements, as well as develop innovative, unanticipated and exciting product or service characteristics. Therefore, quality from the perspective of an organization doesn’t just mean a seamlessly functioning product or service, nor the realization of quantifiable technical properties. It also means creating customer satisfaction.

With flat hierarchies and a reliance on self-organization within agile companies, a comprehensive re-think is needed when it comes to quality management. In a study by Benedikt Sommerhoff and Olaf Wolter on agile quality management, they formulated the following principles [2]:

Focus on customers and business over internal guidelines
Engagement and responsibility for quality over working through a checklist
Networked working over chaos
Test early and learn quickly over drawn-out product launches
Transparency with real-time data over detailed quality reports
Quality and competence during the building stage over training from quality experts
Lean management systems over comprehensive manuals

(See also a comparison of these core principles with the ISO 9001 in [3])

What do these principles entail for finding a path to agile quality management?

  • Continuous interaction between an organization and external and internal customers has to be ensured. This helps to gain direct feedback on requirements, solution concepts, planned use, prototypes etc. whenever it is needed.
  • Awareness among a self-organized team that they all bear a high degree of responsibility for the quality of their approach and the shared results.
  • With a self-organized team comes the need for an established network structure. This provides the necessary expert knowledge, especially in regard to product and process quality.
  • With a team taking on responsibility for the quality of a product or service, a shared-know has to be developed.
  • A central element of working agilely is testing. This needs to be done as soon as possible and, when available, in collaboration with potential users.
  • Working agilely also means being able to react quickly to change. A prerequisite for this is access to up-to-date information, which in turn helps in real-time analysis.
  • To avoid over-formalization and bureaucratization, keep structures, processes and regulations streamlined and documentation to a minimum. You should have the option of generating and automatically updating documents in real time.

Instruments for Agile Quality Management

To successfully navigate the path to agile quality management, processes and regulations need to be streamlined, simplified and- when possible- developed in an incremental and iterative manner. This includes introducing instruments for a new interactive form of cooperation.

Nowadays, there are numerous tried and tested methods and techniques for agile product development that can be utilized in quality management. Instances include design thinking on a large and small scale, working with personas in mind, refining requirements through user storyboards, early on-paper process testing, and lo-fi prototypes.

Enterprise software such as objectiF RPM can also help pave the way to agile test management. objectiF RPM offers the ability to:

  • Refine requirements and visualize their interrelationships.
  • Access user storyboards and Kanban boards.
  • Define personas.
  • Work collaboratively and interactively with experts.
  • Obtain data in real-time.
  • Generate and update documentation.
  • Keep a record of results.
  • Guarantee compliance with auditing.

What does all this look like in practice?

An Example of Agile Techniques in Quality Management: FMEA with Kanban and Real-Time Data

One method of preventative quality management is Failure Mode and Effects Analysis (FMEA). Originating in the automobile industry, FMEA is a systematic approach for identifying risks, avoiding potential product problems, focusing attention on production processes, and- consequentially- reducing error costs.

An FMEA is performed by an interdisciplinary team, who have the support and guidance of a moderator who is equipped with methodical know-how, social competence, and the ability to resolve conflicts. This lays the foundations for agile working.

With objectiF RPM, it’s possible to make an FMEA quicker, more interactive and more iterative through the use of Kanban boards. It looks something like this:

microTOOL Blog: Kanbanboard ifor failures n objectiF RPM for
Fig. 2: A Kanban board for failure analysis in an FMEA in objectiF RPM

microTOOL Blog: Kanbanboard in objectiF RPM shows progress of work
Fig. 3: Where do we stand with the planning and implementation of procedures for identifying and avoiding failures? This Kanban board offers a visual representation of the progress of work to an FMEA team.

To speed up this approach, data input can also occur in real-time. Here is an example:

microTOOL Blog: Identified errors with statuses of the FMEA in objectiF RPM
Fig. 4: What is the current status of the FMEA with regard to the potential errors identified so far and the planned measures? objectiF RPM provides the answer with current statuses in real-time.

How can agile approaches, such as FMEA, or quality management in general be introduced into an organization? A pre-requisite for a successful integration period is a willingness and ability to learn within the organization in question.

A Journey of Small Steps and Stumbling Blocks

No organization becomes agile overnight. The same is true for quality management. Achieving this requires organizational development. For this, there are also agile techniques, such as safe-to-fail experiments (see [4]).

For quality management, it works like this: treat every new agile technique and process as an experiment where it’s fine for it to fail. Each experiment should be on a small scale and manageable. By limiting the context surrounding an experiment, you also limit the potential fallout that could follow from failure. Make sure also not to perform too many experiments at the same time. When it comes to planning experiments, Kanban boards are a big help.

microTOOL Blog: Safe to fail board

Kanban boards should be a place of gathering for members of quality management teams during stand-up meetings, providing a point of reference when discussing the progress of an experiment. At the end of every experiment, there should be an assessment with a short retrospective that asks the following questions:

  • What did and didn’t work?
  • Did the parties concerned do what was expected of them? If not, why?
  • Can the technique/ process be integrated into the organization? Does something within the organization need to be changed before a new experiment begins? Or is it better to simply forget the experiment?

If an experiment turns out to be successful, it can be tried out in a more expansive context. This way, an organization makes tentative steps in the direction of becoming versed in agile practice.


Achieving business agility doesn’t happen at the snap of the fingers It requires a change in mindset, culture and role allocation within an organization. Alongside value proposition and speed, quality also determines the future viability of a company. This means that quality management also needs to contribute to the effort for greater business agility; for this to happen, quality management has to depart from its old and conventional form. However, a change in quality culture doesn’t happen overnight either. It requires someone with extensive experience with agile business methods and techniques, as well as tools from other corporate fields. Only then can the path to agile quality management be tread.

For more information about tool support, please see our whitepaper for Failure Mode and Effects Analysis with objectiF RPM.

Try objectiF RPM for free with our trial edition. Download it here.


[1] Manifesto for Agile Software Development:
[2] Sommerhoff, Benedikt; Wolter, Olaf: Agiles Qualitätsmanagement (Pocket Power), Carl Hanser Verlag München 2019
[3] Manifesto for Agile Quality Management:
[4] Dave Snowden: Safe-fail probes,