The agile manifesto

One of the highest priorities in quality management is to understand customer requirements and to implement them in a compliant manner. The normative as well as product-specific conformity that the customer requires will become significantly less complex as a result of digitalization. Whereas today it is necessary to have legal lists that prove knowledge of the requirements for a product or service or their consistent fulfillment within the company, in the future this will probably be completely digitalized and automated. Product or regulatory managers employed for this task are likely to give way to these data-driven automatisms - at least with regard to this task.

The distinction between requirements and needs
The challenge will be to react quickly to individual customer requirements - in real time if necessary. A common tool for deriving customer requirements for products and services is Quality Function Deployment (QFD). If it was derived step by step which product feature, which function or which service feature must be configured, changed or improved in which way in order to fulfill the customer requirement, these step-by-step procedures will be too time-consuming for real-time requirements in the future. An alternative from the agile world is the Scrum framework from the toolbox of software developers. In the meantime, Scrum has also established itself from a strict software development method into project procedures. Customers also have to adapt and actively participate throughout the entire project (co-creation) as well as provide a dedicated contact person. The advantage is that they benefit from having direct influence on the course of the project, the implementation of their needs and being informed about the status of the work at all times. This approach could hardly be better in terms of the requirement to understand the customer's expectations.

An important aspect of this is the strict demarcation between the two definitions of customer needs and requirements described below. The Scrum method develops the solution regardless of the supposed requirements of the customer and focuses on the overriding question, the benefit, the purpose, which triggered the customer need in the first place, and strives to find the solution based on this. In this process, customer requirements are considered as the initial hypothesis. Within the iterative development process, a solution is developed based on the customer requirements. The implementation, the result, is conducted as an experiment to validate the purpose, the customer's motivation, the benefit. New findings flow into the next iteration (see graphic).

One task of quality management is to ensure that requirements are met. The term requirements is interpreted or understood differently depending on the context: as customer needs or as specifications for a product. In between lies solution finding, which converts the customer's problems or needs into possible solutions. The requirements for the product, the specifications, are derived from the developed solution.

Screws: meet the specifications or the purpose?
Example: At a manufacturer of screws, a quality manager typically ensures that the screws to be produced meet the specification. The requirements of the customers are screws according to specification. Quality management therefore ensures that the screws meet these requirements and thus promises to satisfy the customer. So far, so good.

"With agile methods, customer needs are much more broadly defined in development projects."

With agile methods, customer needs are defined much more broadly in development projects. The question is not just whether screws meet specifications, i.e. are created correctly. The question is: do the screws fulfill their purpose? Only when the screws are used do they fulfill the original need. If the screw serves to hang up pictures, the screw fulfils its purpose with the picture hung up. With the understanding of the need for a picture on the wall, the development of a product range can be continued and lead to specific picture fastening systems or even services instead of just screws. Depending on the need for innovation, the development can be extended to other needs: Decorating rooms, displaying diplomas and awards, showing idols, holding on to memories. A product or service offering could accordingly go beyond picture fixing and take on room decoration or other topics.

Consequences for quality management
Digitalization leads to more automation, standardization and cost pressure. Differentiation through additional value creation is a possible, proven strategy to escape this pressure. More value creation means developing products and services for higher-level customer needs (in the example: "showcasing successes achieved" instead of hanging up fasteners or screws and diplomas and awards).

Identifying overriding needs and developing products and services to meet them is a complex process and is therefore ideally approached empirically. As already stated, quality in empirical processes cannot be ensured by monitoring the process steps alone. This can mean that the requirements for the solution as well as the corresponding testing and quality assurance procedures are developed together with the solution. In the future, this means that quality management must be able to reliably ensure this. The A/B testing of the Internet giants can be taken as an example of an integral procedure. With A/B testing, different variants of a web application are delivered to different users. By measuring user behavior, the web application is continuously refined and improved. Decisions about the best solution variant are replaced by testable hypotheses. Ensuring that customer needs are met is an integral part of the solution, including the necessary processes for evaluating the data, gaining insights, and controlling further development in a targeted manner. A sound quality management for empirical processes must therefore be an integral part of the process itself.

Changed understanding of leadership/value orientation
With the last revision, ISO 9001 has placed management at the centre of all actions. At the same time, new demands are made on the awareness of the employees about the management system or the already existing requirements such as the inclusion of the employees, culture, etc. Agility gives this partially failed attempt a completely new dynamic. Agility gives this partially failed attempt a completely new dynamic. While it was previously a soft topic, it is now a prerequisite for future value creation activities and is thus indispensable.

"Moving away from decision maker to team coach."

If a company decides to adopt an agile approach to change, this not only affects the overarching strategy development process. The most challenging part may be the cultural change and the related readiness for a new and more consistent leadership role. Because with the intention of becoming an agile company, the company must also have a uniform understanding of how it wants to deal with change in the future and what measures are required for a systematic approach at all levels.

It requires the willingness of everyone involved to get involved and take responsibility, to have trust in employees/colleagues, to live a solution-focused error culture, and last but not least, it requires leaders who measure themselves and others more in terms of fulfilled performance and quality expectations than in terms of influence and status.

Co-creation was mentioned as a possible example in the previous chapter. For successful co-creation, for example, the constructive handling of criticism is just as important as openness to good solutions that exist outside the company and have proven themselves.

All decisions regarding culture should also be anchored or expanded in the strategic foundations of an organisation. Often, impulses for the adaptation of action-guiding principles in the organization are triggered by quality management. Examples can be the organizational structure defined in the vi sion, an agile corporate culture documented in the mission statement or an agile management understanding in the principles. In terms of culture, software development is guided by the Manifesto for Agile Software Development (see "Agile Manifesto"). Compared to the vision or mission statement, this refers to an operational level. However, it is equally understood as the cornerstone of every action in a project.

It can be deduced from the manifesto below that the agile values are strongly aimed at the human image. It is assumed that people are intrinsically motivated and that the driver of their motivation to act is not dependent on incentive systems and requirements. Rather, it depends on facts such as having meaning and purpose for a challenging goal and/or being able to provide knowledge for improvement and added value in a self-organized manner. It goes without saying that management must redefine its previous understanding of its role - away from being a decision maker and towards becoming a team coach.

Agile Manifesto
Translated into German, the Agile Manifesto enshrines the following.

We open up better ways of developing software by making it do yourself and others help with that. Through this activity we have learned to appreciate these values:
- Individuals and interactions stand above processes and tools.
- Functioning software stands above comprehensive documentation.
- Collaboration with the customer takes precedence over contract negotiation.
- Responding to change is above following a plan.
That is, although we think the values on the right are important,
we estimate the values on the left side to be higher.

If one compares the contents of the manifesto and the approaches that were described in the introduction to the AGIL model, it can be seen that the cultural aspect of "creating and securing cohesion" and "maintaining basic structures and values" (AGIL) are the most important.IL) was often not cultivated consistently enough. Too much attention has been paid to the need for action "adapting to change" and "defining and pursuing goals" (AGIL). The reason for this imbalance is in almost all cases when there are bottlenecks in terms of resources (time and money).

Another opposite application of the above principles occurs in projects. If the organization determines the need for action through a potential for improvement or a deviation from the target, an optimization project with responsible persons as well as the project objective is decided. This decision is usually made by the line managers, whereby the subject matter experts are entrusted as a project team to develop their professional knowledge for the specific solution of this goal.

At first glance, this sounds quite reasonable. However, it contradicts the mechanisms of the agile manifesto. This is because the determination of the project goal already lays the foundation for a direction and the project team is hardly given the chance to strive for even more suitable alternative solutions that not only fulfill customer requirements, but also create additional benefits.

Part 3 will follow in the next issue. Part 1 appeared in issue 6-2018. We are looking for interested parties for a needs analysis on the topic of agile and quality management. Are you interested? Get in touch with us
on.