Agile Compliance

Bild: Wikimedia Commons / Creig Pat - CC BY-SA 4.0

Wenn die Vorteile von agilen Vorgehensweisen genannt werden liegt in der überwiegenden Mehrzahl der Fälle der Schwerpunkt auf der IT, die so zu bedarfsgerechteren Produkten und schnelleren Releases kommt. Auch Betrieb (Stichwort DevOps) und andere Organisationseinheiten entdecken diese Welt mittlerweile für sich und sehen in Agilität ein anzustrebendes Zielbild. Es gibt aber auch einen weiteren Berech in dem dieser Ansatz Sinn macht, selbst wenn man ihn dort zunächst nicht vermuten würde - Compliance.

Zum besseren Verständnis muss man sich vor Augen halten was dieser Begriff bedeutet. Compliance ist in der Theorie eine Umschreibung für die Einhaltung von Gesetzen und Richtlinien während der Berufsausübung. In der Realität haben sich Compliance-Tätigkeiten allerdings in Teilen von dieser Bedeutung gelöst und auf die damit verbundene Bürokratie ausgedehnt - in fast allen auch nur halbwegs grossen Organisationen bedeutet Compliance heute, dass die eigene Arbeit möglichst lückenlos dokumentiert wird, um bei Bedarf nachzuweisen zu können, dass man sich wirklich an alle Vorschriften gehalten hat¹.

Im klassischen wasserfall-artigen Vorgehen führt das am Ende eines Geschäftsjahres oder einer Projektphase zu hektischen Aktivitäten. Nicht nur muss rückwirkend dokumentiert werden, gegebenenfalls muss zuerst durch Reverse Engineering ermittelt werden was überhaupt der zu dokumentierende aktuelle Stand ist. Und im schlimmsten Fall weicht der Ist-Stand so stark von den Vorschriften ab, dass er überarbeitet werden muss. So kann klassische Compliance dazu beitragen, dass sich "fast fertige" Projekte noch erstaunlich lange ziehen.

Ein agiler Ansatz würde dieses Risiko minimieren indem die notwendigen Dokumentationen parallel zur Produktentwicklung fertiggestellt werden, idealerweise im Team selbst, möglicherweise aber auch durch unterstützende Spezialistenteams. Das bedeutet zwar, dass Juristen, Datenschutz-Beauftragte, Penetrationstester und Security-Spezialisten durchgehend verfügbar sein müssen, im Gegenzug ist der Zustand des "potentially shippable" damit durchgehend gewährleistet und nicht nur punktuell. Und die Nacharbeits-Aufwände am Ende fallen weg.

Ein in diesem Kontext sinnvolles Vorgehen wäre übrigens ein Aufbrechen von Wissensmonopolen, z.B. durch den Transfer von Security- oder Datenschutz-Know-How in die Umsetzungsteams. Auch das trägt bei zu schneller Reaktionszeit, da nicht mehr auf den Experten gewartet werden muss.


¹Das einfach wegzulassen ist zwar naheliegend, wegen der Überprüfung durch Regulierungs- und Aufsichtsbehörden aber oft nicht machbar.