Agiles Projektmanagement in regulierten Branchen.
Wie sich Scrum und pragmatische Governance vereinen lassen – ohne Prozessbürokratie, aber mit dem nötigen Risikoblick.
„Agil geht bei uns nicht, wir sind reguliert.“ Diesen Satz höre ich in Banken, Versicherungen, im Gesundheitswesen und in der öffentlichen Verwaltung regelmäßig. Meine Erfahrung ist eine andere: Regulierung verbietet keine Agilität – sie verlangt Nachvollziehbarkeit. Und die lässt sich hervorragend in einen agilen Rhythmus einbauen, wenn man sie von Anfang an mitdenkt statt hinterher aufzusatteln.
Regulierung ist eine Anforderung, kein Vorgehensmodell
Der häufigste Denkfehler: Weil ein Audit Dokumentation verlangt, wird gleich das komplette Wasserfallmodell eingeführt. Dabei fordert kaum eine Regulierung ein bestimmtes Vorgehensmodell. Gefordert werden Belege – wer hat was wann entschieden, freigegeben, getestet und produktiv gesetzt.
Sobald man Compliance als Anforderung behandelt, wird sie greifbar: Sie landet im Backlog, bekommt Akzeptanzkriterien und wird pro Increment erfüllt statt in einer Phase am Ende.
Governance in den Rhythmus einbauen
Statt separater Gremienlandschaft nutze ich die vorhandenen agilen Formate und erweitere sie punktuell:
- Definition of Done um Compliance-Kriterien ergänzen (Freigabe, Testnachweis, Dokumentation).
- Review als offizielle fachliche Abnahme protokollieren – ein Ticketkommentar reicht oft als Nachweis.
- Risiken im Refinement bewerten, nicht in einem separaten Risikoworkshop pro Quartal.
- Automatisierte Traceability: Commit → Ticket → Release-Notes, statt manueller Nachweislisten.
Dokumentation, die niemand nachträglich schreiben muss
Nachträgliche Dokumentation ist teuer, ungenau und demotivierend. Deutlich besser funktioniert Dokumentation als Nebenprodukt der Arbeit: Entscheidungen werden dort festgehalten, wo sie fallen – im Ticket, im Architecture Decision Record, in der Release-Note.
Ein Confluence-Template mit fünf Pflichtfeldern schlägt jedes 40-seitige Dokument, das nach dem Go-live niemand mehr öffnet.
Was in der Praxis den Unterschied macht
- Früh mit Compliance, Datenschutz und Revision sprechen – nicht erst vor dem Go-live.
- Ein gemeinsames Verständnis davon herstellen, welcher Nachweis tatsächlich verlangt wird.
- Nachweise automatisieren, wo es geht; standardisieren, wo Automatisierung nicht möglich ist.
- Regelmäßig aufräumen: jede Regel, die keinen Nachweis erzeugt, gehört auf den Prüfstand.
