Development Method Successfully Combining Agility and Regulatory Security

Companies need to develop complex products faster and under increasing regulatory requirements. Agile models offer speed and flexibility, but are often in conflict with quality and compliance requirements. This article sheds light on how agility and regulatory security can be reconciled.

The increasing complexity of industrial product development is not an abstract phenomenon, but can be clearly identified. Mechanics, electronics and software are growing ever closer together, with the software component of many products continuously increasing. As a result, products are changing fundamentally: they are becoming more dynamic, updateable - and at the same time less deterministically plannable. Added to this are shorter innovation and market launch cycles, a growing number of variants and increasing regulatory density, for example due to requirements for functional safety, cybersecurity or industry-specific standards.

Why Purely Linear Development Approaches are not Enough

"The real challenge does not arise from individual factors, but from their interactions," emphasizes Dirk Meißner, Managing Partner of CO-Improve, a consulting boutique specializing in agile development of physical products and agile transformation in industrial companies. "Technical, organizational and regulatory complexity are intertwined - and this is precisely what makes traditional, purely linear development approaches increasingly inadequate."

Agility as the Answer—But Not Without Limits

Agile and hybrid development models are seen by many companies as the logical response to this mixed situation. They promise better manageability of complex problems and a reduction in time-to-market through short iterations, early feedback and early risk minimization. In practice, however, there are limits where agile methods are introduced in isolation at team level without considering the overall organization.
 

Agility initially addresses complexity at the level of individual teams. However, regulatory security, system responsibility and architectural decisions are at a different level. If there is no proper interlinking, teams may work in an agile manner - but they are increasingly decoupled from architecture, safety and compliance logic.

Christoph Seeberg-Elverfeldt, Senior Consultant at CO-Improve

Typical symptoms are unclear product and system responsibility as well as missing or downstream normative evidence. Although architecture decisions are often made in or close to the teams, they are not always explicitly embedded in an overarching system, safety and compliance logic. This can lead to either relevant requirements not being considered across the board, or the organization fearing this and reacting with increasing control. In both cases, the effectiveness of agile working methods suffers.

Avoid Conflicting Goals—Integrate Agility in a Targeted Manner

The impression is often created that agility is fundamentally at odds with normative requirements. In fact, the typical conflicts of objectives - for example between rapid iteration and formal approvals, team autonomy and clear decision-making powers or "working software" and standard-compliant documentation - do not arise from the method itself. "These conflicts are not methodological errors, but organizational design problems," says Meißner. "They arise where responsibility, decision-making rights and expectations are not clearly defined." The decisive factor is therefore not the question of "agile or not agile", but how agility is embedded in the organization.

Rethinking Governance

Governance plays a central role, especially in large, complex organizations. However, not in the sense of additional control bodies or extensive process specifications. "Agile organizations don't need less governance, but a different kind of governance," says Seeberg-Elverfeldt. "It's about orientation, clarity and reliability - not control." A clear separation between decisions at team level and those at organizational level is key. Governance creates the framework within which teams can work independently. The decisive factor is not so much the scope of the processes as a regulatory-compliant design of the product creation process - with clearly defined delivery results, handover points and quality criteria.

Risks of Late Integrated Compliance

The consequences are particularly clear where quality, safety and compliance requirements are only considered late or in isolation. The consequences range from increased reworking costs and delays shortly before market launch to declining product quality and limited auditability. "In such situations, compliance becomes an emergency mechanism," warns Seeberg-Elverfeldt. "Agility can help, especially if it is implemented in a disciplined manner and embedded in the system." 

Agile working methods involve clear routines, roles and commitment - provided they are not misunderstood as arbitrariness: Teams are free in terms of how they achieve their agreed sprint goals - but not in terms of what they have bindingly agreed to.

Systems Engineering as a Unifying Regulatory Framework

Systems engineering is a frequently used approach to support traceability in complex systems. This is less a rigid standard than a way of thinking and working that takes the entire system life cycle into account. Systems engineering supports end-to-end traceability from requirements to implementation. Used correctly, it promotes a common language between the disciplines and favors early risk and safety assessment.

Clearly defining product responsibility 
Another key factor is the clear definition of product responsibility: who decides what, under what conditions and with what quality and safety criteria? "Speed does not come from a lack of responsibility," emphasizes Meißner, "but from clarity about who decides under what conditions." Roles for product, system, safety and quality that are integrated at an early stage take the pressure off teams and reduce implicit risks.

Establishing Compliance as an Enabler

In many organizations, governance and compliance are perceived as a brake. This will change if they are integrated at an early stage, designed in a decision-oriented manner and firmly embedded in routines, reviews and artifacts. "Compliance is not a documentation problem, but a design problem," says Seeberg-Elverfeldt. Security is created through conscious, early decisions - not through downstream approvals.

Using Governance as a Structuring Regulatory Framework

In practice, the combination of agility and regulatory security often fails due to an unclear architecture of responsibility and decision-making rights. Agile methods are introduced while governance and system responsibility remain unchanged. CO-Improve offers approaches to design governance as a structuring framework that sets clear expectations and allows teams to work independently. Binding results and integrated quality aspects are crucial. ALM, PLM and requirements management systems are central if they are embedded in a consistent governance model. In this way, regulatory security becomes part of robust product development.

Agile product development in highly complex, regulated industrial environments is not a contradiction, but a conscious design task. Clear governance structures, clearly defined product responsibility, early integrated compliance and a systemic regulatory framework such as systems engineering are crucial.