Auf der einen Seite die „Agilisten“, die nach den agilen Werten „Funktionierende Software vor ausufernder Dokumentation“ oder „Zusammenarbeit mit dem Kunden vor Vertragsverhandlung“ oder gar „Individuen und Interaktionen vor Prozesse und Werkzeuge“ handeln.
Auf der anderen Seite eine Revision, für die alles im Vorfeld dokumentiert und vereinbart werden muss, und deren Zweck es ist, gerade jede Individualität als mögliche Quelle von Fehlern auszuschließen. Eine Softwareentwicklung nach dem guten alten Wasserfallmodell ist eher nach dem Geschmack einer Revision.
Es gibt zwei Möglichkeiten beide Arbeitsweisen miteinander zu verbinden:
1) Die agile Projektarbeit wird organisatorisch gekapselt. Für die Revision sieht das Projekt aus, als ob es nach klassischen Methoden entwickelt wird: plan – build – test - run. Tatsächlich übernimmt die Übersetzungsleistung ein Mitarbeiter, der mit nichts anderem beschäftigt ist, als die in Stories formulierten Anforderungen in einem Fachkonzept zu sammeln, oder Testergebnisse aus einzelnen Sprints zu einem Abnahmedokument zusammenzuführen. Diese Methode ist natürlich sehr zeitaufwändig und bildet nur in gewisser Weise die von der Revision angeforderte Qualität einer Dokumentation ab.
2) Ein Revisionsteam wird in die agile Arbeit eingebunden und passt seine Richtlinien entsprechend den Projekten an. Das Ziel einer Revision ist nicht die Funktion einer Software zu beurteilen, sondern die Rahmenbedingungen zu überwachen. Dies kann durch die Einbettung in den agilen Prozess natürlich viel besser erfolgen. Das Entwicklungsteam hat die Anforderungen direkt im Blick. Eine Überprüfung der Methoden findet laufend statt und nicht nur einmal pro Quartal oder Halbjahr.
Fazit:
Die Einhaltung und Überwachung von Compliance Anforderungen sind gerade für Großkonzerne wichtig und richtig. Bei der stetigen Verbreitung von agilen Arbeitsmethoden - nicht nur in der IT - sollten Revisionsabteilungen viel enger in die Agile Entwicklungsarbeit eingebunden werden.
