Die Agile-Methodik hat sich aus guten Gründen zur dominierenden Herangehensweise in der kommerziellen Softwareentwicklung entwickelt: Sie reduziert das Lieferrisiko durch häufige Integration, deckt Missverständnisse früh durch Demos funktionierender Software auf und ermöglicht die Anpassung des Umfangs, wenn sich das Verständnis der Anforderungen weiterentwickelt. Diese Vorteile sind real und auf Verteidigungsprogramme anwendbar. Die Herausforderung besteht darin, dass Verteidigungsprogramme Constraints einführen, für die Standard-Agile-Praktiken nicht ausgelegt sind — und das Ignorieren dieser Constraints lässt sie nicht verschwinden.

Dieser Artikel untersucht, wo Agile in seiner üblichen Form mit Verteidigungsanforderungen kollidiert, welche Anpassungen sich als effektiv erwiesen haben, und wo die konventionelle Weisheit über Agile in der Verteidigung aktualisiert werden muss.

Wo Agile mit Verteidigungsanforderungen kollidiert

Sicherheitsklassifizierung und Zugangskontrolle. Standard-Agile setzt voraus, dass alle Teammitglieder an allen Teilen der Codebasis arbeiten und alle Zeremonien besuchen können. Verteidigungsprogramme mit klassifizierten Komponenten können einschränken, wer an welchen Subsystemen arbeiten kann, basierend auf dem Sicherheitsfreigabeniveau. Dies schafft Teamstrukturen, die das funktionsübergreifende Teammodell von Agile nicht vorsieht.

ITAR und Exportkontrollbeschränkungen. Für Programme mit US-amerikanischer Technologie, die den International Traffic in Arms Regulations (ITAR) unterliegt, ist die Teamzusammensetzung durch Staatsangehörigkeitsanforderungen eingeschränkt. Standard-Agile-Einstellungspraktiken können mit ITAR-Anforderungen kollidieren, die Ausländern den Zugang zu bestimmten technischen Daten einschränken.

Formale Akkreditierung und Authority to Operate (ATO). Verteidigungssoftwaresysteme benötigen typischerweise eine Sicherheitsakkreditierung, bevor sie in operativen Umgebungen eingesetzt werden. Akkreditierungsprozesse sind nicht Sprint-freundlich: Sie umfassen umfangreiche Dokumentation, Beweissammlung, Drittanbieter-Bewertung und formale Entscheidungsfindung. Dies schafft eine strukturelle Fehlanpassung: Agile produziert kontinuierlich funktionierende Software, aber der Einsatz ist durch Akkreditierungszeitpläne begrenzt, die der Entwicklung um Monate hinterherhinken können.

Air-gapped Entwicklungsumgebungen. Verteidigungsprogramme, die klassifizierte Daten verarbeiten, erfordern oft die Entwicklung in air-gapped Umgebungen — physisch vom öffentlichen Netz getrennten Systemen. Standard-CI/CD-Pipelines sind auf internetaccessible Paket-Repositories und Cloud-basierte Build-Infrastruktur angewiesen, die in air-gapped Umgebungen intern repliziert werden müssen.

Anpassungen: Sprint-gesteuerte Sicherheitsreviews und akkreditierungsbewusstes CI/CD

Sprint-gesteuerte Sicherheitsreviews integrieren Sicherheitsbewertungsaktivitäten in den Sprint-Zyklus, anstatt sie als einmaliges Gate zu behandeln. Jeder Sprint umfasst Sicherheitsreview-Aktivitäten proportional zu den sicherheitsrelevanten Änderungen. Dies verteilt die Sicherheitsreview-Last über das gesamte Programm und verhindert die Anhäufung von Sicherheitsschuld.

Akkreditierungsbewusstes CI/CD adressiert die Air-gap- und Akkreditierungszeitplan-Herausforderungen. Die Pipeline ist mit der endgültigen Akkreditierungsumgebung im Blick konzipiert: Sie verwendet nur Komponenten, die in der air-gapped Umgebung gespiegelt werden können; sie generiert die Artefakttypen, die Akkreditierer benötigen werden (SBOMs, Schwachstellen-Scan-Berichte, statische Analyseergebnisse).

Beobachtetes Muster: Programme, die die Akkreditierung als separaten Workstream parallel zur Agile-Entwicklung behandeln, schneiden konsistent besser ab als Programme, die versuchen, Akkreditierungsaktivitäten auf das Ende zu verschieben. Der Aufwand für die Aufrechterhaltung des Akkreditierungsbewusstseins während des gesamten Programms ist geringer als der Aufwand für den Versuch, Nachweise zu rekonstruieren und Befunde zu beheben, nachdem die Entwicklung nominell abgeschlossen ist.

Dokumentationsanforderungen vs. das Agile Manifest

Das Agile-Manifest erklärt eine Präferenz für „funktionierende Software über umfassende Dokumentation". In Verteidigungsprogrammen erfüllt Dokumentation Funktionen, die über die Erfassung des Software-Verhaltens hinausgehen: Sie ist der rechtliche Nachweis über Vertragsinhalt, Lieferumfang und Verifikation; sie ist die Beweisgrundlage für Regulierungskonformität; und sie ist das Artefakt, das langlebigen Verteidigungssystemen ermöglicht, von zukünftigen Teams gewartet und modernisiert zu werden. Die praktische Lösung besteht nicht darin, zwischen funktionierender Software und Dokumentation zu wählen, sondern explizit zu definieren, welche Dokumentationsartefakte erforderlich sind, wann sie erstellt werden müssen und welches Detailniveau notwendig ist.

Was in der Praxis tatsächlich funktioniert

Verteidigungsprogramme, die Agile-Prinzipien erfolgreich anwenden ohne die Compliance zu gefährden, teilen mehrere Charakteristika: Sie verwenden ein skaliertes Framework (SAFe oder eine programmspezifische Anpassung); sie investieren in eine sichere, konforme Entwicklungsinfrastruktur vor Programmbeginn; sie unterscheiden zwischen Compliance-Aktivitäten, die agil sein können, und solchen, die es nicht können; und sie schulen das gesamte Team — nicht nur Prozesseigentümer — in verteidigungsspezifischen Anforderungen, die die tägliche Arbeit betreffen. Compliance-Fehler in Defence-Agile-Programmen entstehen am häufigsten dadurch, dass Teammitglieder kommerzielle Agile-Instinkte in Kontexten anwenden, wo diese Instinkte falsch sind.