Agile in Theory, Waterfall in Practice: Why Regulated Teams Struggle to Ship Fast

Most regulated teams want to be as agile as unregulated teams. 

They run sprints in Jira, with their work broken down into stories. They track bugs in GitHub and run automated tests in Xray. But when it’s time to release, these quick-iteration practices grind to a halt. 

We call the gap between code freeze and release “release readiness time." In unregulated environments, teams can just deploy their code. But in regulated environments, this period of time—which can range from a few days to multiple months—is dedicated almost exclusively to documentation. 

Teams spend this time manually assembling documents, re-checking traceability, assessing risks, and sometimes making changes—changes which then trigger a cascading effort to update artifacts across tools and formats.

This is where agile dies. 

Agile Development vs. Regulatory Expectations

Medical software teams want to move fast, but the 1990s tools and compliance processes used in regulated environments are built around a waterfall approach.

Meanwhile, tools like Jira, Git, and CI/CD pipelines were built for agility, but not for compliance with standards like IEC 62304. They lack built-in Part 11 approvals and traceability checks. 

“Jira can’t track the changes in a granular enough way for FDA compliance. How do we track changes in our everyday work in a way that’s compliant?” - founder & engineering lead, oral radiology company

This creates a dangerous disconnect. Teams are working in agile systems, but evidence of compliance lives elsewhere—in spreadsheets, Word documents, PDF exports, and eQMS systems. 

Why Documentation Should Follow the Work

The core challenge of regulated software development is managing change.

Software updates frequently—sometimes daily. But documentation processes haven’t kept up. The same level of regulatory scrutiny that applied to once-yearly hardware updates in the 1990s is still applied to frequent AI-based software changes today. This is a heavy burden. 

And yet, most teams are still generating documentation manually. 

“When a change occurs, we don’t know all of the impacted areas because there are so many things interconnected.” - R&D lead, top 10 pharmaceutical company

The burden of documenting frequent changes to regulated software makes true agility feel impossible. 

The Heavy Cost of Siloed Tools

Because development tools aren’t integrated with compliance requirements outlined in your QMS, teams get stuck managing the gaps manually. 

• Engineers do the work in Jira
• Test results get exported from Xray
• Release notes are copy-pasted into Confluence
• Quality/Regulatory makes sure all this work is documented 
• Documents get stored in an EDMS

Teams face similar challenges when documenting automated tests. For example, Beacon Biosignals told us that they wanted to use as many automated tests as possible to speed up their development process while maintaining a high standard of quality. But these automated tests live in testing tools, in their CI/CD pipeline, or directly in the code. Capturing the results of those test executions (whether they passed or failed) in a compliant way is difficult and time-consuming to do manually. 

This fragmented approach introduces delays and errors, undermining the benefits of an agile approach. Even if your sprint is two weeks, your release takes months. 

Agile for Regulated Teams 

The problem isn’t with agile. It’s with implementing agile in a document-centric world.

“The process is backward. Right now, we start with documents and try to fit our work into them. But what we need is documentation that gets generated from the work.” - R&D lead, top 10 pharma company

True agility in regulated development requires: 

• Automated traceability 
• Automated documentation
• Deep integrations with developer tooling
• Audit-ready artifacts 

When documentation follows the work, not the other way around, agile becomes achievable for regulated teams. 

Beacon Biosignals leverages Ketryx's integration with GitHub Actions to automate test execution logging, streamlining the development process. Beacon was able to stay agile by integrating automated testing into the developer workflow, making it easy to document the results of comprehensive testing for every release.

The End of Waterfall? 

Agile teams can’t thrive in a waterfall documentation system.

To meet both regulatory expectations and product development goals, documentation must be a byproduct of compliant work—not a separate, manual effort layered on top. 

To reduce release readiness time, agile teams should implement a self-documenting approach, so that the documentation happens as they are working in systems like Jira and GitHub. When release readiness time is a day instead of a week, a month, or many months, vital updates get to patients faster, and teams can focus on mitigating risk rather than re-checking documents. 

In our next post in this series, we’ll dive deeper on how to stop managing documents and start managing the work itself in a way that results in rigorous documentation.