Wenn man Menschen, die in der Qualitätssicherung (QA) im Bereich Life-Sciences arbeiten, fragt, ob Agile und Compliance miteinander vereinbar sind, erhält man meist dieselbe Antwort: wahrscheinlich nicht. Die Argumentation ist bekannt: Agile lebt von Geschwindigkeit, Iteration und Flexibilität. Compliance hingegen fordert Kontrolle, Dokumentation und Stabilität. Das eine bewegt sich schnell, das andere mit Bedacht. Wenn man beides gleichzeitig angeht, fühlt es sich an, als würde man keines von beidem wirklich gut machen.
Nach Jahren der Arbeit an der Schnittstelle dieser beiden Welten ist jedoch klar: Die Spannung ist real, aber sie betrifft die Umsetzung und nicht das Prinzip. Das eigentliche Problem ist nicht die Regulierung. Es ist die manuelle, sequenzielle und veraltete Art und Weise, wie viele Organisationen versuchen, sie zu erfüllen. Wer Compliance von Grund auf neu denkt, sie in den Entwicklungsworkflow einbettet, anstatt sie obendrauf zu schichten, erlebt eine grundlegende Verschiebung. Agilität und Compliance konkurrieren nicht mehr miteinander, sondern beginnen, sich gegenseitig zu stärken.
Dieser Beitrag zeigt, wie diese Verschiebung in der Praxis gelingt. Er erläutert, was sie für QA-Fachleute bedeutet, wie sich Entwicklungsteams anpassen können und warum es eine wertvolle Investition ist, die Life-Sciences-Organisationen tätigen sollten.
In der klassischen Softwareentwicklung wird Qualitätssicherung häufig auf eine einzige Aufgabe reduziert: Fehler finden, bevor es der Kunde tut. Die Entwickler liefern Code, die Qualitätssicherung stellt sicher, dass er funktioniert, und dieser Prozess wiederholt sich. In den Life Sciences ist dieses Bild jedoch gefährlich unvollständig.
Software in diesem Sektor ist direkt in patientenkritische Prozesse eingebettet – von elektronischen klinischen Studiendatenbanken und Laborinformationssystemen bis hin zur Steuerungssoftware in Medizinprodukten. Ein Versagen ist hier nicht nur ein Problem der User Experience. Es stellt auch ein Risiko für die Datenintegrität dar, es gibt regulatorische Haftungsfragen und in einigen Fällen ist es eine direkte Bedrohung für die Patientensicherheit.
Genau deshalb stellen Standards wie FDA 21 CFR Part 11, EU GMP Annex 11 und ISO 13485 Anforderungen, die weit über funktionale Korrektheit hinausgehen. Sie verlangen systematische, dokumentierte Nachweise, dass ein System seinen beabsichtigten Zweck zuverlässig erfüllt – nicht nur zum Zeitpunkt der Freigabe, sondern über den gesamten Validierungs-Lebenszyklus hinweg. In diesem Umfeld ist QA die Brücke zwischen einem technischen Ergebnis und einem regulatorischen Nachweis. Dies ist eine grundlegend andere Rolle, die einen grundlegend anderen Ansatz erfordert.
Eine wirkungsvolle strukturelle Veränderung, die ein agiles Life-Sciences-Team vornehmen kann, ist es, Compliance nicht länger als etwas zu behandeln, das nach der Entwicklung stattfindet, sondern als etwas, das während der Entwicklung geschieht. Das bedeutet, Compliance zu einem zentralen Bestandteil der Definition of Done zu machen – kein Nachgedanke, kein Gate am Ende eines Release-Zyklus.
Forschungsergebnisse von DORA (DevOps Research and Assessment) zeigen konsistent, dass Hochleistungsteams, d.h. jene, die häufig deployen und sich schnell von Problemen erholen, nicht weniger konsequent sind. Sie sind lediglich disziplinierter darin, wann und wie Qualitätsarbeit stattfindet. Im Kontext der regulierten Softwareentwicklung sieht diese Disziplin konkret aus. Eine User Story ist nicht „Done”, weil der Code funktioniert und die Tests bestehen. Sie ist Done, wenn:
Frameworks wie GAMP 5 bieten die Struktur, um dies in der Praxis umzusetzen. Indem Risikobewertung, Anforderungsmanagement, Testdurchführung und Dokumentation in einem kohärenten Ansatz verknüpft werden, ermöglicht GAMP 5 Teams, regulatorische Disziplin Sprint für Sprint anzuwenden, anstatt versuchen zu müssen, einen gesamten Compliance-Rückstand vor einer Release-Deadline abzuarbeiten.
Eines der wirkungsvollsten, aber am wenigsten genutzten Instrumente für QA-Teams im Life-Sciences-Bereich ist das risikobasierte Testen und die Priorisierung. Regulatorische Standards verlangen keine gleiche Prüftiefe für alle Systemfunktionen. Sie verlangen eine proportionale Prüfung: Die Ressourcen sollten dort konzentriert werden, wo Ausfälle den größten Einfluss auf die Patientensicherheit, die Datenintegrität oder die regulatorische Compliance hätten. Ansätze mit weniger Prüftiefe sollten dort angewendet werden, wo das Risiko geringer ist.
Formale Risikoanalyse-Tools wie FMEA (Failure Mode and Effects Analysis) bieten eine strukturierte Grundlage für diese Entscheidungen. Sie stellen sicher, dass die Prüftiefe und die Dokumentationsstrenge bewusst und auf Basis von Nachweisen und nicht von Intuition zugewiesen werden. Dies ist kein Kompromiss zwischen Geschwindigkeit und Qualität. Es ist ein methodisch fundierter Ansatz, den Regulierungsbehörden selbst durch Frameworks wie GAMP 5 unterstützen.
Für agile Teams bedeutet das, dass nicht jedes Backlog-Element das gleiche Compliance-Gewicht trägt. Ein Sprint kann bei risikoarmen Funktionen schnell vorankommen und sich bei risikoreichen Änderungen angemessen verlangsamen, ohne dass jede Codezeile als gleich kritisch behandelt wird. Das Ergebnis ist ein Team, das gleichzeitig agil und konform ist.
Risikobasiertes Denken verändert auch die Reaktion von Teams, wenn das Unerwartete passiert – einschließlich eines unangekündigten Audits mitten im Projekt. Eine der häufigsten Bedenken in regulierten agilen Umgebungen ist genau dieses Szenario: Ein externer Prüfer trifft ein, während das Team noch aktiv entwickelt. In Organisationen, die noch manuelle Compliance-Prozesse betreiben, löst dies ein vertrautes Muster aus: ein Sprint-Freeze, wochenlange rückwirkende Dokumentation und das unangenehme Gefühl, dass Nachweise zusammengestellt statt präsentiert werden.
Es gibt jedoch einen besseren Weg. Regulatorische Anforderungen, Audit-Befunde und Inspektionsbeobachtungen können wie jedes andere Arbeitselement behandelt werden: Sie können verfeinert, geschätzt, priorisiert und über das Backlog eingeplant werden. Automatisierte Traceability-Tools, etwa Jira-basierte Validierungs-Frameworks, ermöglichen es, die Auswirkungen einer neuen Anforderung auf die bestehende Testlandschaft nahezu sofort zu bewerten und genau zu identifizieren, welche Testfälle aktualisiert und welche Dokumente überarbeitet werden müssen.
Ein konkretes Beispiel veranschaulicht dies besonders gut. In einem Projekt, das mit erheblichem Tempo voranschritt, wurde ein externes Audit angekündigt, während das Team noch mitten im Sprint war. Die Beteiligten waren nervös. Sie gingen davon aus, dass wochenlange Vorbereitung nötig sein würde: Ordner, Freigaben, späte Nächte. Doch das Team hatte kontinuierlich Rückverfolgbarkeit aufgebaut: Jede Anforderung war mit ihrem Code-Commit verknüpft und jeder Code-Commit mit seinem validierten Testergebnis. All dies war in Jira nachverfolgbar und durchsuchbar.
Als der Prüfer nach Nachweisen fragte, war die Antwort ein einziger Link. Der Prüfer prüfte die Traceability-Kette, fand nichts zu beanstanden und ging kommentarlos weiter.
In der regulierten Softwareentwicklung gibt es ein Prinzip, das jeder schnell lernt: Nicht dokumentierte Qualität existiert formal nicht. Ein funktionaler Fehler kostet Zeit und Geld bei der Behebung. Systemische Schwachstellen wie inkonsistente Studiendaten, unvollständige Audit-Trails oder Lücken in der Rückverfolgbarkeit können jedoch zu regulatorischen Befunden, abgelehnten klinischen Einreichungen oder Konsequenzen führen, die weit über das Softwareteam hinausreichen.
Agilität bedeutet nicht weniger Dokumentation. Es bedeutet lediglich, dass keine verschwenderische, redundante oder veraltete Dokumentation erstellt wird. Das Ziel ist nicht das Volumen, sondern Genauigkeit, Vollständigkeit und Rückverfolgbarkeit. Eine Dokumentation, die als natürliches Ergebnis des Entwicklungs- und Testprozesses entsteht, unterscheidet sich grundlegend von einer Dokumentation, die im Nachhinein zusammengestellt wird, um eine Inspektion zu bestehen. Erstere schafft Vertrauen, Letztere schafft Risiken.
Tools wie automatisierte Traceability-Matrizen, CI/CD-Pipelines mit integrierter Testbeweissicherung und Jira-basierte Validierungs-Workflows ermöglichen es, die richtige Dokumentation zum richtigen Zeitpunkt zu erstellen – sozusagen als Nebenprodukt der Arbeit selbst und nicht als separate, parallele Last.
QA-Experten, die diesen Unterschied verinnerlichen, hören auf, als Torwächter am Ende einer Entwicklungspipeline zu fungieren. So wird der QA-Experte zum Quality-Architekten, d. h. zu jemandem, der die Leitplanken entwirft, die es Teams ermöglichen, mit voller Geschwindigkeit zu innovieren, während sichergestellt wird, dass sich regulatorisches Risiko nie unbemerkt anhäuft.
Der wahrgenommene Konflikt zwischen agiler Qualitätssicherung (QA) und Life-Sciences-Compliance ist real, aber er betrifft die Umsetzung und nicht das Prinzip. Agile Werte wie funktionsfähige Software, kontinuierliche Verbesserung und Reaktionsfähigkeit auf Veränderungen sind mit einem regulierten Umfeld vollständig kompatibel. Inkompatibel ist jedoch die Paarung iterativer Entwicklung mit sequenziellen, manuellen Compliance-Prozessen, die für Wasserfall-Projekte und eine andere Ära konzipiert wurden.
Organisationen, die diese Spannung auflösen, indem sie agile Compliance in ihre Definition of Done einbetten, risikobasierte Priorisierung durch GAMP 5 und FMEA anwenden und Traceability durch Tools wie Jira automatisieren, übertreffen konsistent jene, die Compliance als separaten Workstream behandeln. Sie releasen schneller, bestehen Audits reibungsloser und tragen weniger regulatorisches Risiko. Noch wichtiger ist, dass sie aufhören, Compliance als etwas zu erleben, das ihnen passiert, und beginnen, es als etwas zu erleben, das sie kontrollieren.
Für QA-Fachleute in den Life Sciences ist das die Richtung der Entwicklung. Die Frage war nie, ob Agile und Compliance koexistieren können. Die Frage ist, ob Ihre Organisation bereit ist, die Arbeit zu leisten, um sie bewusst zusammenzubringen – Sprint für Sprint, Story für Story.
Sind Sie bereit für den nächsten Schritt?
Möchten Sie agile Compliance in Ihrer Life-Sciences-QA-Umgebung einführen oder optimieren? Dann sprechen Sie uns an. Wir begleiten Sie von der Strategie bis zur Umsetzung.