Agile vs Waterfall for Medical Device Software: IEC 62304 Audit Evidence

The One Question Every MedTech Software Team Asks

Can we use Agile to develop medical device software and still pass an FDA inspection or EU MDR audit? The short answer is yes — and AAMI TIR45:2023, now an FDA-recognized consensus standard (FR Recognition Number 13-143, added May 26, 2025), proves it.

The longer answer is that IEC 62304 does not mandate any specific development methodology. Waterfall, Agile, and hybrid approaches are all acceptable, provided that required lifecycle activities are performed, outputs are documented and traceable, and risk controls are implemented and verified. What regulators care about is evidence, not process rigidity.

This guide compares Agile and Waterfall for medical device software, maps each methodology to IEC 62304 and FDA design controls, explains AAMI TIR45 in practical terms, and shows you what auditors actually examine during inspections.

IEC 62304: What It Actually Requires (and What It Does Not)

The Standard Does Not Prescribe a Process Model

IEC 62304:2006+A1:2015 (and the upcoming Edition 2, in ballot as of 2026) defines what outputs must exist, not how you produce them. Clause 5.1.1 requires a software development plan that defines lifecycle activities, roles, interfaces with risk management, and configuration control. But the standard never says "use waterfall" or "use Scrum."

Annex B of IEC 62304 explicitly states that plans may be iterative and processes may recur as development progresses — a clear acknowledgment that iterative methods are compatible.

Three Key Requirements Any Methodology Must Satisfy

Regardless of whether you use Agile, Waterfall, or a hybrid, IEC 62304 requires:

1. Documented lifecycle activities — planning, requirements analysis, architectural design, implementation, verification, integration testing, system testing, and release

2. Traceability — every software requirement traced to system requirements, risk controls, and verification evidence

3. Risk management integration — ISO 14971 risk analysis feeding into software requirements, with risk controls verified through testing

Software safety classification (Class A, B, or C in the current edition; moving to two levels in Edition 2) determines the depth of documentation required, not the methodology itself.

Waterfall for Medical Device Software

How It Works

Waterfall follows a linear, sequential path: requirements → design → implementation → verification → validation → release. Each phase must be completed before the next begins. This is the classic "V-model" described in IEC 62304 Figure C.2.

Advantages for Regulated Development

• Straightforward audit trail: Each phase produces a distinct set of deliverables with clear entry and exit criteria

• Natural alignment with design control gates: Waterfall phases map one-to-one to FDA 21 CFR 820.30 and ISO 13485 Clause 7.3 design control stages

• Predictable documentation: Regulators and auditors are familiar with waterfall deliverables — software development plan, requirements specification, design description, verification protocols and reports

• Clear baseline management: Requirements are baselined early, and change control is explicit

Limitations

• Rigidity to change: If new FDA guidance, updated risk information, or evolving user needs emerge mid-project, accommodating changes requires formal change control that can delay timelines significantly

• Late defect discovery: Verification and validation occur after full implementation, meaning design defects are found late — when they are most expensive to fix

• Delayed feedback: Users and clinicians do not see working software until late in the cycle

• Documentation weight: For Class B and C software, waterfall can produce thousands of pages of documentation, much of it redundant with the actual development record

Agile for Medical Device Software

How It Works

Agile breaks development into short iterations (sprints), typically 1–4 weeks, each producing a potentially shippable increment of functionality. Requirements evolve through user stories, and teams adapt based on continuous feedback.

AAMI TIR45:2023 — The Bridge Between Agile and IEC 62304

AAMI TIR45 ("Guidance on the use of AGILE practices in the development of medical device software") is the authoritative guide on reconciling Agile with regulatory requirements. First published in 2012 and updated in 2023, it was added to FDA's Recognized Consensus Standards list in May 2025.

Key principles from TIR45:

1. Agile and regulatory rigor are not mutually exclusive — Agile's focus on small, verified increments can improve safety by surfacing defects earlier than waterfall

2. Documentation is a per-sprint deliverable, not a post-project activity — every sprint must produce verification artifacts

3. Design inputs and outputs are generated in pairs — user stories serve as the framework for input/output pairs, continuously generated rather than front-loaded

4. Definition of Done includes regulatory requirements — traceability, risk file updates, and verification evidence are part of the DoD for every sprint

TIR45 Iteration Layers

TIR45 distinguishes four iteration layers, each producing different outputs:

For each layer, TIR45 maps activities to IEC 62304 clause numbers, ensuring that every required lifecycle process is addressed at the appropriate level of granularity.

Agile Ceremony → Design Control Mapping

Agile ceremonies produce the same evidence that waterfall phases produce, organized differently:

Advantages for Regulated Development

• Early defect detection: Each sprint includes testing, catching issues when they are cheapest to fix

• Adaptability: New regulatory guidance (such as FDA's 2025 AI/ML PCCP guidance), updated risk information, or changing user needs can be incorporated into the next sprint

• Continuous traceability: Requirements, tests, and risk controls are linked incrementally rather than retroactively

• Faster time-to-market for SaMD: Class B SaMD development typically takes 10–14 months with Agile versus 18–24 months with pure Waterfall

Limitations

• Requires discipline: "Pure Scrum by the book" does not work for medical device software. Teams must embed regulatory requirements into the Definition of Done, sprint planning, and retrospectives

• Audit complexity: Auditors may be less familiar with Agile artifacts (Jira boards, Confluence pages) than with traditional documentation. Teams must ensure Agile tools are configured to capture the right evidence

• Documentation overhead per sprint: Each sprint must produce verification artifacts, risk file updates, and traceability evidence — this is non-negotiable regardless of methodology

• Change control discipline: Even in Agile, software changes require formal impact analysis and risk assessment per IEC 62304 Clause 7 (maintenance)

The Hybrid Model: What Most Mature Teams Actually Use

In practice, most experienced medical device software teams run a hybrid model — Agile sprints inside Waterfall milestone gates. This approach combines the flexibility of iterative development with the regulatory predictability of phase-gate reviews.

How It Works

1. Phase 0 — Planning (Waterfall gate): Define the software development plan, risk management plan, and overall architecture. Establish the product backlog from user needs and preliminary hazard analysis.

2. Phase 1 — Iterative development (Agile sprints): Execute 2–4 week sprints, each producing verified, traceable increments. Each sprint includes:

   • Sprint planning with risk file review

   • Development and unit testing

   • Integration testing and sprint review (informal design review)

   • Sprint retrospective feeding the CAPA system

   • Updated traceability matrix

3. Phase 2 — System-level verification and validation (Waterfall gate): Formal design verification and validation against the complete set of requirements. This is a defined milestone, not an incremental activity.

4. Phase 3 — Release and transfer (Waterfall gate): Formal design review, design transfer to manufacturing, and release. All Agile artifacts are compiled into the Device History Record (DHR) and Design History File (DHF).

Why Auditors Accept This

The hybrid model works because it satisfies both IEC 62304 and FDA design controls:

• FDA Design Control Guidance (1997) explicitly states that design controls are iterative — the Agency has never mandated a waterfall-only approach

• ISO 13485 Clause 7.3 requires documented design inputs, outputs, reviews, verification, and validation — not a specific sequence

• IEC 62304 Edition 2 (draft) further reduces process rigidity by simplifying software classes and removing redundant QMS requirements

What Auditors Actually Look For

Whether you use Agile, Waterfall, or hybrid, auditors examine the same evidence:

1. Software Development Plan (SDP)

The SDP must define lifecycle activities, roles, deliverables, and the development model used. If Agile is selected, the SDP should describe how sprints are structured, what constitutes a design review, and how traceability is maintained.

2. Traceability Matrix

This is the single most audited artifact. Every software requirement must link to:

• System requirements or user needs

• Risk controls (ISO 14971)

• Design outputs (code, configuration files)

• Verification tests (unit, integration, system)

In Agile, this is maintained incrementally per sprint. In Waterfall, it is built progressively through phases.

3. Risk Management Integration

Auditors check that risk analysis feeds into software requirements and that risk controls are verified. Common findings include:

• Risk management disconnected from development (the risk file is a separate exercise no one updates)

• Software requirements with no traceability to risk controls

• Verification tests that do not cover risk control measures

4. Design Review Evidence

Design reviews must be documented with agenda, attendees, decisions, and action items. In Agile:

• Sprint reviews can serve as informal design reviews

• Formal design reviews should occur at defined milestones (e.g., before system V&V, before release)

• TIR45 recommends using the software development plan to define which sprint-level reviews are formal design reviews

5. Verification and Validation Evidence

Auditors expect to see:

• Test protocols with pass/fail criteria

• Test reports with actual results

• Evidence that verification covers all requirements (traceability)

• Validation evidence showing the software meets user needs and intended use

In Agile, this evidence is generated per sprint and compiled at release.

6. Configuration Management and Change Control

Every software change must be tracked. Auditors look for:

• Version control of source code, documents, and test assets

• Change requests with impact analysis

• Re-verification evidence for changes

• Evidence that changes were reviewed and approved

Comparison: Agile vs Waterfall vs Hybrid

When to Choose Each Approach

Choose Waterfall When

• Developing safety-critical embedded software (Class C) with well-understood, stable requirements

• The device has a long regulatory history and requirements are unlikely to change

• Your team and QMS are optimized for traditional phased development

• The notified body or auditor has explicitly requested waterfall-style deliverables

Choose Agile When

• Developing SaMD, digital health products, or mobile medical apps

• Requirements are evolving, user needs are being discovered through prototyping, or market feedback must be incorporated

• Your team has strong Agile discipline and can embed regulatory requirements into sprint workflows

• Time-to-market is a critical competitive factor

Choose Hybrid When

• Your project includes both embedded firmware (stable, safety-critical) and a connected app or cloud component (rapidly evolving)

• You want the flexibility of Agile but need the regulatory predictability of formal phase gates

• Your team is transitioning from Waterfall to Agile and needs a gradual adoption path

• Most real-world medical device software projects fall into this category

IEC 62304 Edition 2: What Changes for Development Methodology

Edition 2 of IEC 62304, currently in ballot as of 2026, includes several changes relevant to methodology choice:

• Software classes reduced from three (A/B/C) to two levels, simplifying the documentation burden for medium-complexity software

• Scope expanded to all healthcare software, not just software in medical devices — covering clinical decision support, health apps, and AI/ML components

• Explicit acknowledgment of modern development practices — the draft references CI/CD pipelines, automated testing, and DevOps workflows as acceptable evidence generation mechanisms

• Greater alignment with ISO 14971:2019 — the broader definition of "harm" (including property and environmental damage) must be reflected in risk analysis regardless of methodology

These changes reinforce that methodology choice is a business and engineering decision, not a regulatory mandate. What matters is the quality and completeness of evidence.

Practical Implementation Checklist

For Teams Adopting Agile Under IEC 62304

• Update your Software Development Plan to describe the Agile methodology, sprint structure, and how design controls are satisfied per sprint

• Configure your Agile tooling (Jira, Azure DevOps, or equivalent) to capture: user stories linked to requirements, test cases linked to stories, risk control traceability, and sprint review records

• Define your Definition of Done to include: code review, unit test pass, traceability update, risk file update, and documentation update

• Establish formal design review milestones (not every sprint review is a formal design review — use the SDP to define which ones are)

• Implement automated traceability between requirements, code, tests, and risk controls

• Train the team on AAMI TIR45 principles — not just Agile practices but regulatory alignment

• Schedule retrospectives that feed findings into the CAPA system

• Plan for configuration management of all artifacts — code, documents, test protocols, risk files

For Teams Using Hybrid

• Define clear phase gates where formal design reviews, verification, and validation occur

• Ensure each sprint produces audit-ready evidence, not just working code

• Maintain a living traceability matrix that grows with each sprint

• Document the criteria for transitioning between phases (e.g., from development to system V&V)

• Plan the compilation of sprint artifacts into the DHF at release

Key Takeaways

1. IEC 62304 does not mandate Waterfall. The standard requires documented lifecycle activities and traceable evidence — not a specific development methodology.

2. AAMI TIR45:2023 is now FDA-recognized (since May 2025), providing authoritative guidance on using Agile for medical device software that regulators accept.

3. Most mature teams use a hybrid model — Agile sprints inside Waterfall phase gates — combining flexibility with regulatory predictability.

4. Auditors examine evidence, not methodology. Whether you produce a test report at the end of a 6-month phase or at the end of a 2-week sprint, the evidence must show that requirements were verified and risk controls were effective.

5. The hybrid model maps naturally to design controls. Sprint reviews produce incremental design review evidence; phase gates satisfy formal design review requirements; system V&V occurs at defined milestones.

6. IEC 62304 Edition 2 (in ballot 2026) reinforces modern practices — reducing software classes to two levels and explicitly acknowledging CI/CD, automated testing, and iterative development.