This is the second in a five-part series on how agile methods, applied with hardware-ready tactics, deliver better outcomes for medical device companies. Executives face three consistent pressures: get products to market faster, remain fully compliant, and improve ROI. Traditional waterfall development slows innovation and increases risk; pure software agile doesn’t fit the regulated realities of devices.

The Modified Agile for Hardware Development (MAHD) Framework resolves this tension. By leveraging iterative learning cycles, cross-disciplinary alignment, and living traceability, MAHD helps organizations reduce risk, accelerate innovation, and remain audit-ready for compliance.

In this second article, we focus on how agile principles can help companies effectively manage the common challenge of developing, updating, and maintaining Design History Files (DHF).

The Traditional Design History Files

For many medical device organizations, the DHF is intended to be a clear, orderly record of how a product moved from concept to commercialization. Yet in practice, it often becomes a scramble to assemble missing evidence, a reconstruction of past decisions, or a parallel activity disconnected from real engineering work. Technical leaders know the consequences all too well. A weak DHF process can lead to audit findings, incomplete verification, gaps in traceability, CAPAs triggered by documentation errors, and delays in submissions. All of these place financial, scheduling, and compliance pressure on the organization.

The issue is rarely that teams do not understand design controls. Rather, it is that most development processes were not built to produce a living DHF as engineering actually unfolds. Waterfall and stage-gate systems tend to push real learning later in the cycle, leaving documentation to play catch-up. Meanwhile, traditional software agile is fine for rapid iteration, but does not inherently align with FDA expectations or ISO 13485 documentation structure. Caught between these models, medical device teams often struggle to balance adaptability with rigor.

A more thoughtful approach begins by recognizing that a strong DHF is not created by working harder on documentation. It is created by running development in a way that naturally synchronizes decisions, rationale, evolving risk files, and traceability as the product evolves. When documentation emerges from the work itself, the DHF no longer feels like an administrative burden, but becomes a reflection of well-structured engineering.

Where DHFs Break Down—and Why It Matters

Medical device development is inherently iterative, even when traditional processes try to force it into linear steps. Requirements evolve as clinicians provide feedback. Product attributes shift and get solidified as engineering learns more about interfaces, design elements, or constraints. Risk and control measures also change as prototypes expose real-world behavior. Yet many processes still expect design inputs/outputs, risk documentation, and verification plans to be locked in early and revisited only at set checkpoints.

This disconnect causes three predictable failure modes:

• Design Inputs become outdated or incomplete because early assumptions and preliminary designs change, but documentation does not.
• Traceability collapses late in the project, requiring painful reconstruction just as teams prepare for verification or submission.
• Risk management files diverge from reality, making ISO 14971 compliance more difficult and creating exposure during audits or unannounced inspections.

These gaps have direct operational consequences. Verification teams may discover that test protocols do not align with updated specifications. Manufacturing may uncover missing design transfer elements. Regulatory teams may have to delay a submission to fill documentation gaps. And quality may open corrective and preventive actions (CAPAs) because DHF elements do not accurately match the design that was actually developed.

For technical leaders, the result is clear: poor DHF integration is not just a paperwork problem but a product development problem that shows up in schedule, cost, and compliance.

A More Effective Model: Let Documentation Emerge from Engineering

A more modern, healthier approach is to integrate DHF creation directly into how teams plan, collaborate, and make decisions. Instead of treating documentation as a separate stream, engineering and design control activities move together. This avoids the common issue where the DHF reflects what “should have happened” rather than what did happen.

The process starts with clearer early alignment. With an agile approach, an essential foundation is a concise articulation of the product’s purpose, intended use, clinical need, constraints, and expected outcomes. This not only provides a strong foundation and direction without the traditional locked-in “requirements,” but it also forms the early spine of design inputs and enables system and risk discussions to happen earlier and more coherently. Technical leaders see immediate value when early architectural, safety, and feasibility decisions are grounded in shared understanding.

As work progresses, engineering iterations, such as the MAHD Framework’s IPAC Iterations (Figure 1), become the engine for both learning and documentation. Each cycle—whether focused on integration, prototyping, architectural refinement, or early customer feedback—produces tangible outputs that can immediately feed the DHF. When teams routinely capture decisions, rationale, updated risks, and evidence during these cycles, traceability and documentation naturally stay current.

Risk management becomes more transparent as well. Instead of risk files lagging weeks or months behind engineering changes, all of the hazard analyses, risk controls, and residual risk evaluations evolve incrementally. This tightens alignment with ISO 14971 expectations and helps ensure verification plans reflect the actual intended controls and satisfy increasingly skeptical auditors.

This synchronous approach also strengthens design reviews. Instead of theatrical events where teams rebuild slides or create documentation expressly for the review, the reviews draw on real artifacts actively used by engineering. Verification plans, interface definitions, early test results, architectural updates, and risk files are already in motion. Leaders get a more accurate view of product maturity, and teams experience fewer disruptions.

Using Digital Tools with Purpose

Digital platforms support modern medical device development, but no single system can meet every need. Execution tools like Jira and Planner are excellent for coordinating work, while purpose-built solutions such as Jama, Helix ALM, Greenlight Guru, and Ketryx manage requirements, traceability, and DHF structure. The real impact comes from using these tools in a consistent rhythm that keeps documentation synchronized with engineering decisions. When updated incrementally, they strengthen design control practices instead of adding administrative overhead.

What Improves for Technical Leaders

When documentation becomes a natural part of how engineering works, leaders see several consistent benefits:

• Better visibility into risks and architectural issues earlier, before they compromise verification or design transfer.
• More predictable readiness for design reviews and submission milestones, since documentation matches engineering reality. 
• Reduced time spent reconstructing decisions, improving both compliance and engineering efficiency.
• Fewer last-minute crises, because traceability, risk, and design outputs have been evolving continuously. 

Most importantly, teams reclaim time and energy that would otherwise be spent fixing documentation gaps. This enables them to focus on building safer, more effective devices.

A DHF that Builds Itself

When development practices support continuous clarity, cross-functional collaboration, and incremental documentation, the DHF becomes something far closer to what regulators expect it to be: an authentic, contemporaneous record of how the device was designed.

The result is not simply a better DHF. It is a better device, built through a process that naturally strengthens engineering discipline, reduces uncertainty, and produces compliant, audit-ready evidence with far less overhead.

MORE FROM THIS AUTHOR: Guiding QMSR Alignment with Agile Methods

Dorian Simpson is an innovation, product management, and agile consultant, trainer, and speaker. He is the author of The Savvy Corporate Innovator and co-founder of the Modified Agile for Hardware Development (MAHD) Framework. He helps startups to Fortune 500 technology leaders build skills to improve their ability to identify, evaluate, plan, and develop innovative products. The MAHD Framework is a purpose-built agile approach for physical product innovation. MAHD combines agile principles with hardware-ready methods: On-Ramps to set strategic intent, IPAC Iterations to integrate and learn quickly, Aligned Backlogs to connect work across disciplines, and hardware-aligned roles that empower technical leaders. Organizations adopting MAHD report faster time-to-market, improved compliance confidence, and higher ROI—without sacrificing safety or quality. Learn more at www.MAHDFramework.com.