Iterative development can help a medical-device team expose technical and user risk earlier, but “agile” is not permission to defer safety, documentation or system thinking. The useful approach combines short learning cycles with controlled requirements, risk management, architecture, verification and change.
That distinction matters because a medical device is more than a software backlog. Hardware lead times, clinical use, manufacturing processes, human factors, cybersecurity and regulatory evidence create dependencies that a sprint cadence alone cannot manage.
Agile changes the learning cadence
An iterative team divides work into increments that answer specific questions or deliver testable behavior. It reviews the evidence, updates priorities and plans the next increment. This can reduce the time between an assumption and the observation that proves it wrong.
The method works best when each increment has a technical purpose. “Complete the user interface” is broad. “Demonstrate the alarm-priority interaction with representative users and trace the resulting changes to risk controls” gives the team a decision and evidence target.
Design controls still apply
Under the U.S. Quality Management System Regulation, effective February 2, 2026, applicable device design and development activities remain controlled within a quality system incorporating ISO 13485:2016 by reference. Iteration does not remove the need for approved inputs, outputs, reviews, verification, validation, transfer and change control.
The backlog can help manage work, but it should not become the only product record. User needs, system requirements, risk controls, interface definitions, verification results and configuration history need durable, reviewed relationships.
Use a layered planning model
One practical structure separates planning into three levels:
- Product and evidence plan: intended use, regulatory path, major risks, architecture, clinical or usability evidence, transfer and submission milestones.
- Increment plan: the user, technical or manufacturing uncertainty that the next increment will close.
- Daily execution: design, implementation, review and test tasks needed to produce the increment.
This lets teams adapt detailed work without losing the product-level dependencies that determine safety and submission readiness.
Define “done” as evidence
A feature is not complete because code was merged or a prototype worked once. The definition of done should reflect the maturity of the work. During exploration, it may require a documented result, configuration, open risks and next decision. For a controlled design output, it may also require review, traceability, tests and updated risk records.
| Increment type | Useful completion evidence |
|---|---|
| Feasibility experiment | Question, configuration, method, result, uncertainty and decision |
| Software behavior | Reviewed implementation, unit tests, interfaces, hazards and traceability |
| User-interface concept | Representative tasks, formative findings, use-related risk updates and design decision |
| Hardware revision | Released files, build record, bring-up evidence, known deviations and affected requirements |
| Verification item | Approved method, acceptance criteria, test configuration, result and disposition |
Keep architecture ahead of local optimization
Teams can move quickly within the wrong architecture. Establish system boundaries, safety functions, data ownership, timing constraints, cybersecurity assumptions and hardware interfaces before independent workstreams diverge.
The architecture can evolve, but changes should be explicit. A software workaround may increase processor load, change alarm timing or hide a sensor limitation. A mechanical change may affect calibration, optical alignment or electromagnetic performance. Regular cross-disciplinary reviews catch these effects before they become local “done” items.
Integrate risk work into the backlog
Risk management should shape priorities. Hazards, hazardous situations, risk controls and verification activities can generate backlog work, while completed increments can reveal new hazards or change risk estimates.
Do not reduce risk management to a final document update. When a control depends on software, labeling, mechanical guarding, alarm behavior or a manufacturing inspection, the corresponding work and evidence should remain visible through implementation and test.
Use continuous integration with controlled baselines
Automated builds, static analysis, unit tests, interface tests and hardware-in-the-loop tests can improve feedback. They are most useful when results identify the source revision, build environment, test configuration and acceptance criteria.
Frequent integration does not require releasing every build as a controlled product version. Teams can distinguish exploratory builds, engineering baselines, verification configurations and production releases. The distinction prevents informal prototypes from being mistaken for verified product.
Plan hardware and manufacturing around longer loops
Printed circuit boards, molded parts, machined components and supplier changes do not follow the same cadence as application software. Use staged prototypes and interface simulators so learning can continue while hardware is in fabrication.
Bring manufacturing engineering into early increments. Assembly sequence, test access, calibration, inspection and supplier capability may force product changes. Waiting until “design transfer” turns those discoveries into expensive rework.
Use reviews as decision points
A design review should evaluate whether the evidence supports the next decision, not celebrate activity completed during the sprint. Define the question, entry criteria, reviewers, open risks and required dispositions. Preserve the record at the level appropriate to the product and quality system.
Short technical reviews can occur frequently. Formal reviews can align with major baselines or regulated milestones. Both benefit from current, traceable information.
Where agile medical-device development fails
- The team treats changing requirements as a reason to avoid approved baselines.
- Software increments advance without stable hardware or system interfaces.
- Documentation is postponed until people no longer remember why decisions were made.
- Testing emphasizes the normal path while fault, recovery and misuse scenarios remain late.
- User feedback comes from internal stakeholders instead of representative users and environments.
- Velocity becomes the goal even when the critical uncertainty is not being reduced.
Apply agile practices proportionately
FDA’s recognition database lists AAMI TIR45:2023, guidance on using agile practices in medical-device software development. IEC 62304:2006, confirmed current in 2023, defines a framework for medical-device software life-cycle processes. These resources reinforce that iterative practices can operate within a disciplined lifecycle.
The right implementation depends on device risk, software safety classification, architecture, organization and evidence needs. A small internal tool and a distributed connected therapy system should not use identical controls.
Build around learning and traceability
Agile practices are useful when they shorten the path from a risky assumption to credible evidence. They become dangerous when speed hides unresolved interfaces or undocumented decisions. The development system needs both adaptation and control.
Outer Reef’s medical-device software, program management and product development work connect iterative execution with system architecture, risk and verification.
