Most teams building Software as a Medical Device (SaMD), digital therapeutics, or device-connected software run sprints. Most of them are also making one of three mistakes that break their IEC 62304 compliance — and they don't usually find out until submission prep. Check out our whitepaper to learn more.
If you're building software that falls under FDA oversight, whether it's a Software as a Medical Device (SaMD) product, a digital therapeutic, software that supports a physical device, or embedded software inside one, you've probably already committed to working in some form of agile. Most teams have. The days of choosing between agile and waterfall for medical device software are mostly behind us.
The real question is no longer whether to use agile for FDA-regulated software. It's how. How do you run sprints and still produce the documentation IEC 62304 expects? How do you keep velocity without sacrificing the rigor that regulators (and patient safety) demand? How do you satisfy design controls under 21 CFR 820.30, risk management aligned with ISO 14971, and the lifecycle processes of IEC 62304, all inside a methodology that was originally built for everything but regulated industries?
That question is where things usually break down. After years of building FDA-regulated medical device software across many projects, we keep seeing the same three failure patterns. None of them happen because the team is bad. They happen because nobody told them what regulated agile actually looks like in practice.
A timely note: IEC 62304 Edition 2 and Annex F
It's worth flagging up front that the standards landscape has just shifted. IEC 62304 Edition 2 (2026) introduced Annex F, the first formal mapping inside the standard of how agile practices reconcile with the lifecycle processes it requires. Annex F is based on AAMI TIR45:2023, which has been the practical reference for agile in medical device software for over a decade.
What Annex F gives you is the regulatory legitimacy: agile is no longer something you have to argue for in your software development plan. What it doesn't give you, and isn't trying to, is the operational playbook. Knowing the mapping is allowed is not the same as knowing how to run a sprint when your Definition of Done has to satisfy IEC 62304, ISO 14971, and ISO 13485 at the same time. That's where the three failure patterns below tend to bite.
Pattern 1: The "Move Fast" team
This is the team that's great at building software. Developers ship features quickly, the backlog moves, and the product evolves. From the outside, everything looks healthy — velocity is high, demos go well, the team is shipping.
Then it's time to prepare for an FDA submission, or even an internal audit, and the documentation simply doesn't exist.
There is no Software Requirements Specification because nobody wrote formal requirements. The design descriptions live in developers' heads or scattered across Jira tickets and Slack threads. Testing happened, but there's no traceable test protocol linked to specific requirements. Risk assessments were discussed in meetings but never formally documented. The hazard analysis exists as a half-finished spreadsheet from six months ago that nobody can quite remember how to update.
These teams aren't careless. They're operating the way most software teams operate outside regulated industries, and they're often very good at it. The problem is that FDA expectations don't bend to accommodate the way most software gets built. The agency expects design controls under 21 CFR 820.30, traceability between requirements and test results, documented risk management aligned with ISO 14971, and a Design History File that demonstrates how the software came to be the way it is. None of that gets built retroactively without significant pain.
When the documentation gap becomes visible, the team faces a painful choice. Go back and reconstruct everything, which is both slow and often inaccurate, since nobody can quite remember why a particular technical decision was made in sprint 8. Or accept significant delays to the submission timeline while a small team works backwards through months of completed work, trying to write requirements for code that already exists.
The pattern: strong agile development practices, absent regulatory documentation. The fix isn't to slow the team down. It's to make documentation a natural byproduct of development, produced as the work happens rather than reconstructed afterward.
Pattern 2: Waterfall with sprints
This is the most common pattern we encounter in FDA-regulated software development, and the most insidious because it looks like the team is doing the right thing.
The team runs sprints. They have standups, sprint planning, retrospectives. There's a product owner, a Definition of Done, story points, velocity tracking. On the surface, it looks like agile.
But underneath, the work follows a fundamentally sequential logic. First the team gathers all the requirements. Then they design everything. Then they build. Then they test. Then they write the documentation.
What these teams have done is break a waterfall process into time-boxed chunks. The requirements phase takes four sprints. The design phase takes three sprints. Testing comes at the end. Documentation is a final sprint — or sometimes three — before submission.
The result is the worst of both methodologies. The team loses the feedback loops that make agile valuable for medical device software, because they're not validating working software incrementally — they're validating intermediate artifacts. And they lose waterfall's predictability, because the sprint structure creates an illusion of progress that masks the fact that integration and testing haven't happened yet. Cycle three sprints of "design" and you have a thick stack of design documents and zero running code. Cycle three sprints of "testing" and you discover, very late, that the design didn't survive contact with reality.
The pattern: agile ceremonies without agile engineering practices. The activities that should happen concurrently within each sprint are spread across the timeline sequentially. The fix isn't more ceremonies. It's restructuring what happens inside each sprint so that requirements, design, implementation, testing, and risk assessment all advance together at the story level — which is exactly what IEC 62304 Annex F now formally allows, and what AAMI TIR45 has described for years.
Pattern 3: The Late Compliance team
This is a subtler version of the first pattern, and it often hides inside organizations that genuinely believe they're doing things well.
The team might actually be doing decent agile development. Stories are well-formed, code quality is good, the product works. But the quality and regulatory roles show up too late. Maybe QA gets involved when the sprint is "done" and it's time to review. Maybe the regulatory affairs specialist joins three months before submission to start assembling the technical file. Maybe the cybersecurity person consults at architectural milestones but isn't in the day-to-day work.
The problem here is timing. In regulated agile, the RA/QA perspective needs to be embedded from the beginning, shaping how stories are written, ensuring risk assessments happen alongside development, reviewing deliverables as they're produced. When these roles operate downstream instead of alongside, three things go wrong. Rework increases, because issues that could have been caught at story level get caught at submission prep level instead. The risk analysis develops gaps, because nobody is identifying new hazards as features are being built. And documentation drifts from reality, because the people writing it weren't in the room when the decisions were made.
This pattern often stems from organizational structure more than intent. Companies organize their quality and regulatory teams separately from development. The teams might be in different time zones, different reporting lines, sometimes different vendors. The collaboration model hasn't adapted to an agile workflow because the org chart hasn't either.
The pattern: regulatory involvement happens after the fact rather than in parallel. The fix requires both process changes and organizational alignment, and the process changes alone usually aren't enough.
What all three failure patterns have in common
It's easy to read these as three separate problems. They share a common root.
In all three patterns, regulatory activities are being deferred. In the Move Fast team, they're deferred to a future "documentation sprint" that turns into six months of reconstruction. In Waterfall with Sprints, they're deferred to dedicated phases that arrive too late to inform development. In Late Compliance, they're deferred organizationally, handled by someone who shows up after the decisions have already been made.
The opposite of all three patterns is the same thing: regulatory activities happen at the story level, inside every sprint, as part of how the work gets done. Not as a parallel track. Not as a gate at the end. Not as a phase. As an integrated part of building each piece of software.
That sounds simple in a sentence. In practice it requires rethinking the Definition of Done, restructuring how the team works together, and changing what each role does inside a sprint. It is not a tool change or a ceremony change. It is a methodology, and it's the methodology AAMI TIR45 (and now IEC 62304 Annex F) describes at a conceptual level but doesn't, and isn't trying to, give you as an operational playbook.
We've spent some time working that methodology out across many FDA-regulated projects. We wrote it down.
Get the full regulated agile playbook
Our whitepaper, Regulated Agile for FDA Software: A Practical Guide from Years in the Trenches, is the operational playbook for running agile development on FDA-regulated medical device software. It covers the layered model that makes the methodology work, how documentation can build itself as a byproduct of development, how to handle design controls and risk management iteratively, and how to integrate cybersecurity without slowing down.
It's the practical layer on top of AAMI TIR45:2023 and IEC 62304 Annex F — twenty pages of how we actually run regulated agile on SaMD and medical device software, not how it's supposed to work in theory.
Download the Regulated Agile whitepaper →
Hattrick IT is a software development company specializing in regulated agile for medical devices, digital health, and digital therapeutics. We've been building digital products since 2014. If you're working on something in this space, we'd be glad to talk: [email protected].