Agile Compliance (II)

Seit kurzem kann ich einen weiteren Punkt in meiner grossen, ständig nachwachsenden To Do-Liste abhaken: ich habe einen Beitrag in einem juristischen Fachbuch veröffentlicht, und zwar in Product Compliance, Herausgegeben von Chibanguza und Steege im Nomos Verlag. Damit habe ich jetzt einen zweiten Grund um mich Autor zu nennen, aber auch darüber hinaus ist das Thema eines, das für mich schon seit längerer Zeit wichtig ist.

Wie ich schon einmal geschrieben habe, wird in einem agilen Vorgehen Compliance sichergestellt, indem die notwendigen Dokumentationen parallel zur Produktentwicklung fertiggestellt werden. Das bedeutet zwar, dass mehr (und unterschiedlichere) Arbeit parallel stattfinden muss, im Gegenzug ist der Zustand des "potentially shippable" damit durchgehend gewährleistet und nicht nur punktuell (denn: ohne Compliance keine Auslieferung). Und die Nachdokumentations-Aufwände am Ende fallen weg.

Um sicherzustellen, dass es so kommt, kann mit zweien der klassischsten unter den agilen Praktiken gearbeitet werden: der Definition of Ready (DoR) und der Definition of Done (DoD) bezw. mit ähnlich funktionierenden aber abweichend benannten Policies, Quality Gates oder vergleichbaren Ansätzen. Unanhängig vom Namen ist dabei wichtig, dass im Voraus klar ist, wie mit Compliance-Themen umgegangen wird, und dass bei jeder einzelnen Auslieferung eine Konformität gegeben ist.

Zunächst zur im Voraus nötigen Klarheit. Die bedeutet nicht, dass schon vor Beginn der Arbeit feststehen muss, welche Normen erfüllt werden müssen. Bei einem Vorgehensmodell, das die Art der Umsetzung möglichst lange offen lässt wäre das auch schwierig. Es kann aber in der DoR im Voraus festgelegt werden, welche Vorgaben zu prüfen oder welche Experten zu konsultieren sind, um das aktuelle Increment für compliant erklären zu können (zum Increment gleich mehr).

Die Art auf die das geschieht, kann dann Teil der DoD sein. Je nach Kontext kann die Ausgestaltung unterschiedlich sein, mögliche Varianten sind aber wie oben gesagt der Abgleich mit bestehenden Regeln und Gesetzen, die Freigabe durch einen Juristen, Datenschützer, o.Ä. und wenn erforderlich die Erstellung der dazugehörigen Dokumentation. Das kann natürlich bedeuten, dass z.B. ein Jurist Teil eines Softwareentwicklungsteams werden muss - aber das ist eben Crossfunktionalität.

Um sich dabei nicht zu verzetteln ist es schliesslich wichtig, sich darüber im Klaren zu sein, welcher Arbeits- oder Funktionsumfang denn jeweils Compliance-konform sein muss. Es ist das Increment, ein Begriff mit sehr spezifischem Inhalt: zu ihm gehört nicht nur der Umfang des letzten Sprints oder Arbeitspakets, sondern ausserdem die Summe aller bereits vorher erstellten Arbeitsergebnisse. Nur als Ganzes kann ein Increment compliant sein, und nicht lediglich in Teilen.