Validation and

Agile Methods

The regulations governing medical devices and pharmaceutical products apply regardless of the software development life cycle.

Agile methods are iterative, meaning they involve successive development cycles. Each iteration is based on key elements such as user requirements and acceptance criteria, which serve as the foundation for starting the development cycle. At the end of each iteration, a version—or increment in Agile terminology—is produced and should be usable by end users. The principle is to deliver reliable versions of the system even if not all features are finalized.

Unlike the V-cycle model, Agile allows development to begin without drafting detailed functional specifications upfront, as users and Quality Assurance are involved from the start and continuously validate the functional response.

The Agile approach is well suited when system requirements cannot all be defined precisely at the start of the project. Historically, web projects were among the first to adopt it—for example, adding a GxP chatbot. The key idea is that users can access new functionalities as updates are released to production and can modify requirements throughout the system’s lifecycle.

The term Agile methods covers multiple frameworks aligned with the 2001 Agile Manifesto, such as Scrum, eXtreme Programming (XP), Feature Driven Development (FDD), Rapid Application Development (RAD), and Behavior Driven Development (BDD).

Agile development originally applied mainly to software development phases. Depending on the method, some start at the pre-project and feasibility phases, while others focus more on project execution. The latter are mainly used in regulated environments (e.g. Scrum).

The V-cycle model is a variant of the Waterfall software development model. It follows a sequential process in which each step must be completed before the next can begin. The descending branch represents design phases, while the ascending branch represents testing. Each design phase corresponds to a verification phase.

This method requires a precise definition of requirements from the beginning. It is best suited to systems with limited changes during development. The initial schedule and functional scope are not expected to evolve. The traceability between requirements and tests ensures documented quality control at each stage.

In the pharmaceutical sector, there is no incompatibility between validation principles and the Agile approach. The 2022 second edition of the GAMP® 5 Guide supports this view, setting out key requirements without prescribing a specific development model. It describes five phases: planning, specification, configuration (or coding), verification, and reporting.

Risk management must be integrated throughout all stages, requiring dynamic risk assessment. Similarly, regulations on medical devices (Regulations (EU) 2017/745 and (EU) 2017/746) do not impose any particular software design or development sequence.

Note that the chosen development method has no impact on the content of the required documented evidence, which must comply with standard expectations.

The Agile approach can therefore be implemented within a GxP environment as long as it integrates regulatory requirements related to software documentation and the quality management system. In particular, maintaining control of requirement traceability throughout development is essential.

Agility is not, as is sometimes claimed, a method without structure or change control—it can be effectively applied in regulated environments.

A key success factor is the early involvement of Quality Assurance, beginning with the user requirements definition.

At the heart of Agile lies an autonomous, multidisciplinary, and stable team—meaning the same group follows the project from start to finish. Team members should be trained not only in Agile methodology but also in its terminology and collaborative, flexible mindset.

For effective validation, Agile-specific tools are indispensable. They ensure continuous tracking of requirements and risks throughout development.

Implementing Agile often requires organizational transformation. A hybrid mode can serve as a transitional step before adopting full Agile.

Positive outcomes include systems that meet user expectations thanks to the flexibility of the approach. Gradual adoption by key users fosters engagement and system acceptance.

A key caution: Agile does not necessarily save time. The time distribution is different. Each iteration involves documentation updates, risk reassessments, and repeated testing. When these updates are neglected, compliance issues arise.

Another caution: test quality. Tests are often linear, verifying only system functionality without proper linkage to identified risks. Boundary and failure tests are insufficiently included.

Finally, Agile has its limits. Flexibility and adaptability must not result in a system that deviates too far from the initial requirements—for reasons of cost, resourcing, schedule, and quality feasibility.