The desire for agile companies, agility and agile work is ubiquitous, but we all know it’s mostly just talk. However, this worn-out motto is also an expression of the legitimate wish for better and more effective processes in the most various areas of business and projects. What does “agile” really mean and, more importantly, what does it mean in the context of companies and failure mode and effects analysis (FMEA)? Is “agile” in this context just a misused buzzword?
Definition agility & FMEA
In relation to FMEA, agility means delivering as early as possible in the production process useful, high-quality results. This is in keeping with the Rule of Ten which states that the costs of undetected errors increase by a factor of ten from stage to stage in the value creation chain. The continual improvement process (CIP) – a basic principle of quality management and an essential part of ISO 90001 – also requires this.
What distinguishes an agile company?
“… the ability of a company’s information function to make provisions for meeting changing production demands and modified functional requirements very quickly, as close to real-time as possible, as well as being able to use the advantages of information technology in such a way that the technical scope of the company can be expanded or even re-defined.” 
Why work agilely with FMEA?
There is general agreement that agility creates transparency. When creating high-level basic and family FMEA’s this can be achieved above all through division of tasks and effective FMEA sprints (in preparation for an FMEA). This creates a noticeably lighter workload for everyone. Individual stress levels are lowered, an organization’s decision making ability is streamlined, employee motivation is increased through shared responsibility, and finally customer satisfaction is achieved faster and with better results from FMEA.
For FMEA as a whole, however, a hybrid approach is the best. That means a combination of agile and classic approaches. For preparation, agility has true benefits, but for moderation I recommend a classic process.
Agile + Classic = Hybrid
Agile FMEA (FMEA sprints) + Classic FMEA moderation = Hybrid FMEA
Distinguishing factors in preparing and conducting an agile FMEA
- achieving goals
Problem: There are actually still companies who attempt to document FMEA without using any noteworthy aids, usually with the resolution: “We’ll think about using software in the future.”
Goal: In almost every other area we consider how to optimize and accelerate procedures, yet in an area that ties up employees considerably, we’re still trying to earn a smiley face by laboriously copying back and forth between Excel spreadsheets. And we’re doing this despite the fact that there are many more or less practical software solutions on the market that can create enormous time saving for users. FMEA Sprints can be used for FMEA preparation and they are the means of choice.
Problem: FMEA moderations are painstakingly prepared, taking a lot of time. Even the best plan seldom makes it through the first glances of an FMEA moderation. Reason: Circumstances have changed, participants and knowledge carriers have cancelled last minute, and so on.
Goal: Through extended responsibility and modifying task and roll divisions, groups can organize themselves more flexibly. This is usually faster and more effective. The issue of flexibility has already been adequately addressed and also finds justification in FMEA.
Problem: In general, FMEA moderations run according to the same fixed pattern. The FMEA moderator questions each team member and processes the input with a standardized data sheet. If you have six developers, each employee gets very little time to make a contribution; the moderator can’t do justice to each individual.
Goal: A dynamic or agile FMEA can be worked on in parallel on several levels and everyone can add their own approved contributions. The moderator continues to be available as a specialist in the method and for deeper causal research, but not as a lecturer for the FMEA team.
Problem: Companies still think and act in projects and budgets. This often leads to redundancies, also with regard to responsibilities. In most companies, however, products and processes are constantly evolving. And yet the project-driven way of working often leads to the reinvention of the wheel.
Goal: The consistent implementation of agility means striving for networked cooperation and avoiding overlaps and redundancies (e.g. through basic and variant FMEA).
Problem: Often the FMEA moderator is the only one who has detailed FMEA knowledge and can operate FMEA software. Consequently, only the FMEA moderator can and is allowed to add content to the FMEA.
Goal: The trust and ability to extend the FMEA with elements and sound knowledge should be granted to all employees and project groups. If the employees are not qualified for the FMEA, training can be provided. If they do not have sufficient knowledge, they shouldn’t be on the FMEA team…
Problem: Even long-term practitioners and FMEA team members often come unprepared to FMEA meetings, expecting that it will be first be explained in the meeting which documentation, specifications, data, etc. are important for the “new” FMEA.
Goal: Lacking documentation is nerve-wracking and time-consuming. It should be made available before the next meeting. Basic knowledge and data should always be present in order to avoid waiting times and to optimize everyone’s ability to contribute.
Problem: It’s as if FMEA teams were part of an unpopular secret club that takes place in isolated meeting rooms, led by their moderator and master. And if we’re honest, we think that’s fine but just hope not to be confronted with the FMEA and dragged into the circle…
Goal: The current status of the FMEA should be transparently available for live viewing at all times. The progress of the FMEA is then immediate available and comprehensible for everyone, and contributions from individuals can be added at any time. The prerequisite for this is methodological competence in FMEA provided to everyone through general training.
Problem: Without an adequate concept and sound structures, the FMEA is subject to repeated fluctuations. Phases of low interest and phases of increased interest alternate. The latter especially when an audit is imminent or an important customer asks for inspection.
Goal: The consistent implementation of agility in most cases also means a change in the corporate culture. One must want to improve continuously and iteratively. The FMEA must therefore be understood as a method that accompanies development and not merely as a method for diligently filling out forms.
Problem: Sometimes it seems like the FMEA moderator alone feels completely responsible for the FMEA results. In addition, the project manager needs an FMEA solely for the customer and auditor. Even after many tough FMEA meetings / FMEA moderations, many employees do not know the true value and the true results of an FMEA.
Goal: The company knowledge built up with the help of FMEA and the competitive advantage gained from agile product and process development are intangible assets. Both contribute significantly to achieving FMEA and business objectives.
Classic FMEA moderation
An agile FMEA that has been created through many smaller FMEA sprints needs to be perfected through FMEA moderation. It should now be easy to check results with the FMEA moderation and team and to extend and improve step by step through a guided moderation. When the causes are found, enough time should be taken for considering appropriate measures. An agile approach can lead to errors here, because things can be incorrectly assessed or too quickly considered unimportant. For that reason, I recommend proceeding classically through the moderation phase.
Read more about André Kapust’s FMEA. On his website you can learn more about trainings and seminars for this and other topics: https://www.quality.de/
In addition, you can find many more articles on quality management at his Wiki: https://www.qm.wiki/
 https://agile-unternehmen.de/was-ist-agil-definition/ (in German only)