„Agilität in Regulatorikprojekten – Widerspruch oder Chance?“
Anzahl und Komplexität von Regulatorikprojekten in Banken steigen ständig. Immer mehr Ressourcen, personell und finanziell, werden mit der Sicherstellung einer regulatorikkonformen Governance gebunden. Leider ist der Beitrag zur unternehmerischen Wertschöpfung von Regulatorikprojekten nahezu „Null“. Aus diesem Grund kommt der effektiven Bearbeitung regulatorischer Anforderungen sowie dem effizienten Management von Regulatorikprojekten eine hohe Bedeutung zu. Können hier agile Methoden oder gar Scrum helfen?
Zur Klärung einer Eignung von Scrum für die Durchführung regulatorischer Projekte in Banken empfiehlt sich ein Blick auf die Charakteristika von Projekten, bei denen Scrum idealtypisch eingesetzt wird.
Aufgrund der gesetzlichen oder aufsichtsrechtlichen Vorgaben, an denen Regulatorikprojekte ausgerichtet sind, wird auf den ersten Blick deutlich, dass diese Art von Projekten nicht die Kennzeichen aufweisen, die ein Projekt charakterisieren, das sich gut für die Anwendung von Scrum eignet. Selbstverständlich lässt sich einwenden, dass Methodiken immer auch eine individuelle Interpretation oder Ausprägung aufweisen. Scrum lebt aber gerade von der Einhaltung des Methodenkanons, um seine Wirkung entfalten zu können. Methodische „Eingriffe“ stellen hier den Erfolg eines Scrum-Projektes schnell in Frage – die Anwendung von Scrum wird mit diesen Eingriffen abgebrochen.
Lösen wir uns vor diesem Hintergrund einmal von dem Begriff Scrum und rücken stattdessen Agilität in den Mittelpunkt der Betrachtung. Unter der Fragestellung, ob und wenn ja welche agilen Methoden für Regulatorikprojekte geeignet sind, ist eine Entkopplung von der Strenge der durch Scrum determinierten Vorgaben möglich.
Welche agilen Methoden gibt es, die in Scrum genutzt werden, und gibt es darüber hinaus geeignete Ergänzungen dieses agilen Toolsets – diese Frage soll im Folgenden betrachtet werden, um danach die Eignung für einen Einsatz in Regulatorikprojekten zu bewerten.
Die aus Scrum bekannten agilen Methoden lassen sich aus meiner Erfahrung grob in drei Schwerpunkte aufteilen. Sie unterstützen eine inhaltliche Strukturierung, eine zeitliche Strukturierung oder stellen die Interaktion der Beteiligten in den Mittelpunkt. Nachstehende Übersicht ordnet die in Scrum genutzten Methodenbausteine diesen drei Schwerpunkten zu.
Zu 1 – Inhaltliche Strukturierung
- Mittels eines Backlogs können Anforderungen in unterschiedlicher Ausprägung und Dokumentationsform verwaltet werden
- Neben der Beschreibung erfolgt für die Inhalte eines Backlogs eine Darstellung von Aufwand und Nutzen sowie eine Priorisierung
- Entsprechend der Priorisierung wird die Beschreibung detaillierter spezifiziert
- Das Kanban-Board visualisiert Arbeitsfortschritte
- Aufgaben durchlaufen nach Arbeitsfortschritt gegliederte Rubriken, die je nach Einsatzzweck unterschiedlich gegliedert werden, z. B.:
- Zu tun | In Arbeit | Erledigt
- Backlog | Konzeption | Umsetzung | Test | Freigabe | Erledigt
Eignung für Regulatorikprojekte:
Eine strukturierte Sammlung von Anforderungen ist Inhalt jedes Projektes und damit auch für Regulatorikprojekte essenziell. User Stories werden sicherlich nicht die dominierende Bedeutung in der Zusammensetzung des Backlogs haben. Ebenso wenig wird die Summe der Anforderungen mittels eines Fachkonzepts und eines DV-Konzepts beschrieben, um dann mit dem Label Backlog versehen zu werden.
Unter Berücksichtigung eines modularen Aufbaus der Grundgesamtheit von Anforderungen in Regulatorikprojekten ist ein Backlog gut geeignet, um diese als Summe zu verwalten. Aus ihm lassen sich dann zusammenhängende Einzelanforderungen herausziehen und in einen Sprint-Backlog zusammenfassen. Denkbar sind hier beispielsweise Use-Cases zur Anbindung von Anwendungssystemen oder Infrastrukturkomponenten an ein SIEM (Security Incident and Event Management).
Zu 2 – Zeitliche Strukturierung
Sich für einen kurzen Arbeitszeitraum definierte Arbeitsinhalte vorzunehmen, die aus der Grundgesamtheit aller Anforderungen ausgewählt werden, ist unabhängig von Scrum ein sinnvolles Vorgehen zur Handhabung eines komplexen Anforderungsuniversums. Voraussetzung ist jedoch, dass die Inhalte eines Sprints keine zu feste Kopplung zu anderen Anforderungen außerhalb des Sprits aufweisen und damit eine unabhängige Bearbeitung ermöglichen.
Eignung für Regulatorikprojekte:
Folgende Beispiele aus Regulatorikprojekten seien zur Verdeutlichung genannt:
- Anbindung von Anwendungen an ein PAM-Tool (privileged access management) zum Handling privilegierter Berechtigungen
- Durchführung einer Business-Impact-Analyse für einen Kernprozess
- Umsetzung gemeinsamer Schwachstellenscans mit einem IT-Provider
Gemeinsames Charakteristikum obiger Tätigkeiten ist, dass sie nicht durch eine Person allein durchgeführt werden, sondern nur personen‑, abteilungs‑, bereichs- oder firmenübergreifend bewältigt werden können. Mit ihrer losen Kopplung zu anderen Themen sind sie jedoch gut für eine Bearbeitung in Form eines Sprints geeignet.
Deutlich wird anhand dieser Aufgaben jedoch die Notwendigkeit zur Interaktion in der Bearbeitung. Und genau hier liegt der dritte Schwerpunkt agiler Methodiken.
Zu 3 – Interaktion
„Miteinander reden“ hießen nicht nur die vier Standardwerke von Friedemann Schulz von Thun zur Kommunikationspsychologie, sondern auch in Projekten gilt dieser Leitsatz. Aus diesem Grund wurden in der Scrum-Methodik Vorgaben zum strukturierten Austausch umgesetzt, sei es der tägliche Standup oder Sprint-Review und Sprint-Retrospektive. Strukturelle und zeitliche Vorgaben stellen die Effizienz und Effektivität dieser Termine sicher.
Eignung für Regulatorikprojekte:
Die Eignung eines täglichen Standup für Regulatorikprojekte steht außer Zweifel, hat sich doch dieses kurze Meeting inzwischen weit über Scrum hinaus in den beruflichen Alltag ausgebreitet. Wichtig im Kontext von Regulatorikprojekten ist hier jedoch die Einhaltung der strukturellen und zeitlichen Vorgaben aus Scrum, um einen diffusen Informationsaustausch zu vermeiden. Das Ergebnis eines Sprints im Review zu betrachten und Verbesserungen daraus abzuleiten (Retrospektive), ist grundsätzlich auch außerhalb von Scrum wichtig. Die eng gefassten methodischen Vorgaben verlieren jedoch ein Stück weit an Bedeutung, wenn in Regulatorikprojekten nicht wie bei Scrum das Ergebnis eines Sprints produktiv gesetzt wird.
Zusammenfassung:
Zusammenfassend lässt sich sagen, dass Scrum als geschlossene Methodik sicherlich nicht geeignet ist für die Durchführung von Regulatorikprojekten. Aber eine Vielzahl von Elementen aus dem agilen Methodenbaukasten, den Scrum nutzt, lassen sich übertragen. Sie zahlen ein auf die schnelle Erzeugung verwertbarer Ergebnisse im Projekt, die Sicherstellung der Kommunikation sowie die Umsetzung der ganzheitlichen Zielsetzung des Projektes.
Hier haben Erfahrungen gezeigt, dass sich einzelne Elemente auch sehr gut miteinander kombinieren lassen. Explizit sei hier auf die Methodik des Scrumban hingewiesen, in der die Visualisierung mittels Kanban-Board um prozessuale Elemente erweitert wird. So informiert es über die Anzahl der Objekte, an denen das Team gerade arbeitet, sowie die Anzahl an Aufgaben, welche schon abgeschossen sind. Ziel ist hier die Stärkung von Verantwortungsbewusstsein und Kommunikation sowie die Visualisierung der bereits erzielten Leistungsergebnisse.
In einer fortgeschrittenen Ausbaustufe kann ein solches Scrumban-Board durch die inkrementelle Arbeitsplanung Sprints obsolet machen. Jedoch hat sich im praktischen Einsatz die Kombination von Sprints und Scrumban-Boards bewährt. Das Prinzipbild eines Scrumban-Boards zeigt nachstehende Abbildung.
Expertise bankon Management Consulting
Die Expertise der bankon-Berater aus mehr als fünfzehn Jahren Erfahrung mit Projekten im Kontext IT-Regulatorik sichert praxiserprobtes Wissen. Umfangreiche Kenntnis von Organisationsstrukturen, Prozessen und IT-Systemen deutscher Banken und Sparkassen gewährleisten den erforderlichen fachlichen und technischen Hintergrund.
Auf dieser Grundlage sowie mittels unseres langjährigen Erfahrungsschatzes in der erfolgreichen Anwendung traditioneller und agiler Methoden im Projekt wählen wir gemeinsam mit Ihnen den für Ihr Institut geeigneten Methodenmix aus.
