If you ask most people working in life sciences quality assurance (QA) whether Agile and compliance can coexist, you will probably hear the same answer: 'Probably not.' The reasoning behind this is familiar: Agile thrives on speed, iteration and flexibility. Compliance, on the other hand, demands control, documentation and stability. One moves fast; the other moves carefully. Attempting to achieve both simultaneously can seem like a recipe for achieving neither effectively.
After years of working at the intersection of these two worlds, the tension is real — but it is a tension of implementation, not of principle. The actual problem is not the regulation. It is the manual, sequential, and outdated way that many organisations still try to satisfy it. When you rethink compliance from the ground up — embedding it into your development workflow rather than layering it on top — the dynamic shifts fundamentally. Agility and compliance stop competing and start reinforcing each other.
This article explores how that shift happens in practice: what it means for QA professionals, how development teams can adapt. It also explains why getting this right is one of the most valuable things a life sciences organisation can do.
In conventional software development, quality assurance is often reduced to one job: find what is broken before the customer does. Developers ship code, QA makes sure it works, and the cycle repeats. In Life Sciences, this picture is dangerously incomplete.
Software in this sector is embedded directly into critical patient processes, ranging from electronic clinical trial databases and laboratory information systems to embedded control software in medical devices. A failure here is not just a problem with the user experience. It poses a risk to data integrity, creates regulatory liabilities and, in some cases, poses a direct threat to patient safety.
This is why standards like FDA 21 CFR Part 11, EU GMP Annex 11, and ISO 13485 impose requirements that go far beyond functional correctness. They demand systematic, documented evidence that a system reliably does what it is supposed to do — not just at the point of release, but across its entire validation lifecycle. QA in this environment is the bridge between a technical deliverable and a regulatory proof. That is a fundamentally different role — and it requires a fundamentally different approach.
The most impactful structural change an Agile Life Sciences team can make is to stop treating compliance as something that happens after development and start treating it as something that happens during development. This means making it a core part of the Definition of Done — not an afterthought, not a gate at the end of a release cycle.
Research from DORA (DevOps Research and Assessment) consistently shows that high-performing teams — those that deploy frequently and recover quickly from issues — are no less rigorous. They are simply more disciplined about when and how quality work happens. In a regulated software development context, this discipline takes a specific form. A story is not considered 'Done' simply because the code works and the tests pass. It is done when:
Frameworks such as GAMP 5 provide the structure to facilitate this in practice. By linking risk assessment, requirements management, test execution and documentation into one coherent approach, GAMP 5 enables teams to apply regulatory discipline on a sprint-by-sprint basis, rather than attempting to address an entire compliance backlog before a release deadline.
Risk-based testing and prioritisation is one of the most powerful — and most underused — tools available to Life Sciences QA teams. Regulatory standards do not require equal scrutiny of all system functions. Instead, they require proportionate scrutiny: resources should be concentrated where failures would have the greatest impact on patient safety, data integrity or regulatory compliance, while lighter-weight approaches can be applied where the risk is lower.
Formal risk analysis tools, such as FMEA (Failure Mode and Effects Analysis), provide a structured basis for these decisions. They ensure that test depth and documentation rigour are allocated deliberately, based on evidence rather than intuition. This is not a trade-off between speed and quality. It is a methodologically sound approach endorsed by regulators themselves through frameworks such as GAMP 5.
For Agile teams, this means that not every backlog item carries the same compliance weight. A sprint can quickly move through low-risk functionality and appropriately slow down for high-risk changes — without treating every line of code as equally critical. The result is a team that is both genuinely agile and genuinely compliant.
Risk-based thinking changes the way teams respond to the unexpected — including a mid-project audit. One of the most common fears in regulated Agile environments is precisely this scenario: an external inspector arriving while the team is still actively developing. In organisations that are still running manual compliance processes, this triggers a familiar pattern: a sprint freeze, weeks of retrospective documentation and an uncomfortable sense that evidence is being assembled rather than presented.
There is a better way. Regulatory requirements, audit findings, and inspection observations can all be handled like any other work item: refined, estimated, prioritised, and scheduled through the backlog. Automated traceability tools — such as Jira-based validation frameworks — make it possible to assess the impact of a new requirement across the existing test landscape almost immediately, identifying exactly which test cases need updating and which documents need revision.
One experience illustrates this well. On a project moving at significant pace, an external audit was announced while the team was still mid-sprint. Stakeholders were nervous. The assumption was that weeks of preparation would be needed — binders, sign-offs, late nights. But the team had been building traceability continuously throughout the project: every requirement linked to its code commit, every code commit linked to its validated test result, all of it tracked and searchable in Jira.
When the auditor asked for evidence, the answer was a single link. The auditor reviewed the traceability chain, found nothing to question, and moved on without comment. In Life Sciences QA, a bored auditor is the clearest possible sign that your quality system is actually working.
There is a principle that anyone working in regulated software development learns quickly: undocumented quality is formally non-existent. A functional bug costs time and money to fix. However, systemic weaknesses, such as inconsistent study data, incomplete audit trails and gaps in traceability, can result in regulatory findings, rejected clinical submissions or consequences that affect more than just the software team.
Agility does not mean less documentation. It means eliminating wasteful, redundant or outdated documentation. The goal is not volume, but accuracy, completeness and traceability. Documentation that is created as a natural by-product of the development and testing process differs fundamentally from documentation that is assembled afterwards to satisfy an inspection. The former builds confidence. The latter creates risk.
Tools like automated Traceability Matrices, CI/CD pipelines with built-in test evidence capture, and Jira-based validation workflows make it possible to produce the right documentation at the right time — as a by-product of the work itself, not as a separate and parallel burden.
The QA professional who internalises this distinction stops functioning as a gatekeeper at the end of a development pipeline. They become a Quality Architect — someone who designs the guardrails that allow teams to innovate at full speed, while ensuring regulatory risk never quietly accumulates in the Background.
While the conflict between Agile QA and life sciences compliance is real, it is a conflict of implementation, not principle. The values of Agile, such as producing working software, continuous improvement and responsiveness to change, are entirely compatible with a regulated environment. What is incompatible, however, is pairing iterative development with sequential, manual compliance processes designed for waterfall projects and a different era.
Organisations that resolve this tension — by embedding agile compliance into their Definition of Done, applying risk-based prioritisation through GAMP 5 and FMEA, and automating traceability through tools like Jira — consistently outperform those that treat compliance as a separate workstream. They release faster, audit more cleanly, and carry less regulatory risk. More importantly, they stop experiencing compliance as something that happens to them and start experiencing it as something they control.
For QA professionals in life sciences, this is the direction of travel. The question has never really been whether Agile and compliance can coexist. The question is whether your organisation is willing to deliberately bring them together, sprint by sprint and story by story.
Ready for the next step?
Would you like to implement or improve agile compliance in your life sciences QA environment? Get in touch with us and we will support you throughout the process, from strategy to implementation.