Agiles Risikomanagement – braucht man das?

Bei der Arbeit mit agilen Projektteams fällt auf, dass es bei diesen heute im Wesentlichen zwei Ansätze rund um “Risikomanagement” zu geben scheint:

• Ein Teil der Wirtschaft hat offenbar mit dem Wechsel auf agile Vorgehensweisen die systematische Betrachtung von Risiken einfach fallengelassen, was für manche gut funktioniert, sicher aber auch oft für das „kopflose agile Chaos“ verantwortlich ist, was Vertreter der alten Arbeitsweise nicht immer zu Unrecht kritisieren.
• Der Rest scheint zu versuchen, ihren agilen Vorgehensweisen einfach ein klassisches Risikomanagement überzustülpen. Leider ist vieles, was in agilen Projekten zum Alltag gehört, nach klassischer Denke als Risiko zu bewerten – etwa laufende Änderungen des Scopes. Dieser Widerspruch wird nun entweder aufgelöst, indem das Projekt klassisch mit Iterationen durchgeführt und damit der Vorteil agiler Methoden verschenkt wird, oder man lässt die unterschiedlichen Teile der Projektorganisation im offenen Konflikt zueinander stehen und schlägt sich mit den resultierenden Problemen herum.

Meine Meinung ist, dass das besser gehen muss. Den neuen Ansatz können wir “agiles Risikomanagement” nennen, ich bin mit diesem Begriff allerdings nicht glücklich – zum einen wollen wir uns vom eng gefassten Konzept des “Risikos” lösen, zum anderen wollen Risiken nicht “gemanagt” werden, sondern adressiert. Ich will hier einen Ansatz beschreiben, der beides tut, im Wissen, dass wir über kurz oder lang eine etwas weniger irreführende Bezeichnung dafür suchen sollten.

Was ist Risiko?

In Anlehnung an Gerhard Wohland will ich hier zwischen Gefahr und Risiko unterscheiden. Gefahren sind Umweltereignisse, die negative Auswirkungen auf uns haben können. Ein schnell fahrendes Auto stellt also eine Gefahr dar. Ein Risiko dagegen hat mit eigenem Handeln zu tun – wenn ich eine Straße überquere, gehe ich ein Risiko ein. Steinschlag im Gebirge ist eine objektive Gefahr – im Gebirge wandern zu gehen ist eine risikobehaftete Tätigkeit.

Wohland schreibt dazu: “Da auch Nichtentscheiden Risiko beinhaltet, kann Risiko nicht vermieden werden”.¹ Er führt weiter aus, dass sich bei steigender Komplexität immer weniger Negativereignisse eindeutig auf externe Umwelteinflüsse zurückführen lassen. Unser Handeln hat Auswirkungen auf unser Umfeld, und je größer die Komplexität der Situation, desto größer auch die Wahrscheinlichkeit, dass wir selbst unerwünschte Ereignisse auslösen, die wir im Vorfeld nicht absehen können. Höhere Komplexität bedeutet also Zunahme des Risikos, selbst wenn die objektiven Gefahren die gleichen bleiben.

Wie überall sonst, sind auch hier im Vergleich zu den bekannten Risiken die “unknown unknowns” das größere Problem – böse Überraschungen, die wir erleben werden, von denen wir nicht wissen, dass wir sie nicht wissen. Wie viele Risikomanagement-Reports werden Ende 2019 wohl die Möglichkeit einer globalen Viruspandemie als Gefahr für die Organisation aufgelistet haben?

Probleme mit Risikomanagement

In klassischen Vorhaben wird Risikomanagement oft als eine separate Aufgabe in der funktionalen Teilung gesehen – entweder als Teil des Projektmanagements, oder, bei größeren Vorhaben, als separate Funktion, die dem eigentlichen Projektmanagement oder dem “Steuerungs”-Gremium zuarbeitet.

Allein schon diese strukturelle Entscheidung führt zu einer Reihe von Problemen. Offensichtlich lässt sich in einem hochspezialisierten Arbeitsumfeld weder das Erkennen, noch das Untersuchen, noch das Adressieren eines Risikos von der eigentlichen fachlichen Arbeit trennen. Niemand außer den Spezialisten ist in der Lage, die Risiken ihrer Arbeit anzugehen – oft nicht einmal, diese überhaupt zu verstehen.

Versucht wird es trotzdem, was in der Praxis dazu führt, dass Risikomanagement schnell auf allen Seiten unbeliebt ist:

• bei den Fachexperten, weil das Diskutieren der Risiken mit Fachfremden viel Zeit und Nerven kostet,
• beim Entscheiderkreis, weil diese natürlich spüren dass das Verständnis der Risiken in der Risikobetrachtung bestenfalls oberflächlich ist,
• weiterhin, weil dann schwierige Entscheidungen mit mangelhaftem Informationsstand getroffen werden müssen,
• schließlich wieder bei den Fachexperten, die am Ende die resultierenden Maßnahmen umzusetzen haben und genau wissen, dass diese in der Regel mit ausbaufähiger Sachkenntnis beschlossen worden sind.

Dass diese Vorgehensweise an und für sich schon risikobehaftet ist, haben wir etwa beim Bau des Flughafens BER eindrucksvoll miterleben dürfen.

Ein weiterer, ungünstiger Nebeneffekt der funktionalen Trennung ist Overengineering. Da sich das Adressieren der Risiken nicht im Rahmen der Rolle allein bewerkstelligen lässt, wird verfügbare Zeit stattdessen für den Ausbau des “Management”-Aspekts genutzt. Hier lässt sich eine Vielzahl von budgetfüllenden Aktivitäten entwickeln, vom Berechnen von Eintrittswahrscheinlichkeiten über das Ermitteln akzeptabler Risikoobergrenzen, Entwicklung, Erhebung und Kontrolle von Kennzahlen, Reporting an Dritte, bis hin zur rekursiven Anwendung auf sich selbst, zum Beispiel indem Risikomanagement-Standards entwickelt werden, um das Risiko unprofessionellen Risikomanagements zu managen. Wie viel hiervon tatsächlich einem Kunden nutzt, darüber kann man streiten.

Am Ende scheint oft ein Zustand zu stehen, in dem das Projektmanagement irgendwo eine Liste von möglichen Problemen in Form einer langen Excel-Tabelle mit rot-gelb-grüner Farbcodierung herumliegen hat, und in dem das tatsächliche Adressieren von Risiken gegenüber ihrer bürokratischen Verwaltung den Kürzeren zieht. Das ist intransparent und wenig effektiv, und es wird auch nicht wesentlich besser dadurch, dass man neuerdings die Cloud-Variante der bevorzugten Tabellenkalkulation dafür zweckentfremden kann.

Für stark standardisierbare und routinehafte Abläufe wie Serienfertigung oder Bauwesen mag klassisches Risikomanagement trotzdem ein gangbares und vielleicht sogar sinnvolles Vorgehen sein, darüber mag ich mir kein Urteil anmaßen. Spätestens in agilen, interdisziplinären Teams kommt diese Prozedur an ihre Grenzen, was wie erwähnt in meiner Erfahrung dazu führt, dass viele agile Teams überhaupt keine bewusste Risikobetrachtung mehr machen. Auch wenn das gerade für den Kunden oft mit viel Unsicherheit und unschönen Überraschungen verbunden ist, scheint es zumindest so leidlich zu funktionieren, dass viele Unternehmen weiterhin willens sind, ihre klassischen durch agile Vorgehensmodelle abzulösen.

Implizites Risikomanagement in agilen Vorgehensweisen

“Risiko ist das Wasser, in dem agile Fische schwimmen.” (Ron Jeffries²)

Nach wie vor begegnet mir regelmäßig der Reflex in Organisationen, auf steigende Ungewissheit und zunehmendes Risiko mit mehr Planung, mehr zentraler Steuerung, mehr Kontrolle zu reagieren. Das Ergebnis sind ineffiziente, aufgeblähte, selbstreferenzielle Strukturen, deren Nutzen nur schwer ihren enormen Ressourcenverbrauch rechtfertigen kann. Die Wahrnehmung scheint zu sein, dass man sich agile Ansätze vor allem in kleinen, überschaubaren Vorhaben leisten könne, nicht aber in größeren oder risikobehafteten, auch wenn Werkzeuge wie etwa das Cynefin-Modell³ oder die Blau-Rot-Unterscheidung⁴ genau das Gegenteil nahelegen.

Tatsächlich ist in agilen Ansätzen ein gewisses Risikomanagement schon auf der Strukturebene implizit mit eingebaut, und zwar bewusst, nicht etwa aus Versehen. Im Scrum Guide fällt beispielsweise schon in der Einleitung die Aussage “Scrum employs an iterative, incremental approach to optimize predictability and to control risk”.⁵ Risiken beherrschbar zu machen, ist also ein Kernmerkmal agiler Methoden, und je risikoreicher ein Vorhaben ist, desto wichtiger wird das Anwenden agiler Prinzipien in seiner Durchführung!

Ein produktives Team, welches kontinuierlich die Anforderungen mit dem höchsten Wert in ein nutzbares, hochwertiges Produkt überführt, wird im Rahmen jedes beliebigen Zeitraums das Maximum dessen herausholen, was möglich gewesen ist. Kleiner kann man ein Lieferrisiko nach meinem Verständnis nicht machen. Man kann es allerdings größer machen – durch willkürlich gesetzte Deadlines, durch lange Planungsphasen ohne konkret nutzbare Ergebnisse, durch eine schlechte Priorisierung der Aufgaben, die eben nicht zu jedem Zeitpunkt in einem maximal wertvollen, konkret nutzbaren Zwischenergebnis resultiert. Und natürlich hat man die Möglichkeit, mittels unrealistischer Erwartungen über den Lieferumfang das Enttäuschungspotenzial beliebig weit zu steigern.

Diese Liste lässt sich nun fortsetzen. Was Scrum für das Lieferrisiko ist, sind Ansätze wie XP für technische Risiken. Kommunikationsrollen zweiter Ordnung, wie z.B. die des Scrum Masters, haben die Aufgabe, Risiken der Kommunikation und der Zusammenarbeit zu finden und zu adressieren. Flowbasierte Techniken wie Kanban haben das Ziel, Ineffizienzen, Lastspitzen und andere Formen der Verschwendung zu vermeiden, was ebenfalls als eine Form des Risikomanagements gesehen werden muss. Und so weiter, und so fort.

In Summe heißt das für mich: ein gut laufendes, kompetentes Team, welches sein Produkt nutzergetrieben Ende-zu-Ende entwickelt, sollte für Risikomanagement, wie wir es von früher kennen, wenig Bedarf haben.

Aber natürlich: wir wollen auch in die Zukunft schauen. Und die Organisationsrealität ist meist nicht so rosarot wie eben skizziert. Eventuell gibt es Abhängigkeiten. Eventuell gibt es Deadlines, an die Erwartungen geknüpft sind. Unter Umständen steigt der Nutzen des Produkts nicht linear mit seinem Funktionsumfang, sondern es muss eine gewisse Mindestfunktionalität erreicht werden, damit es wirklich als lieferbar bezeichnet werden kann. Und natürlich gibt es auch für Teams in optimalen Umfeldern eine Vielzahl möglicher sozialer, rechtlicher und organisatorischer Ereignisse, die sich auf den Erfolg des Vorhabens auswirken können.

Ein neues “Risikomanagement” für agile Teams

Wenn wir die Schwächen klassischer Risikomanagementansätze vermeiden und möglichst die Stärken agiler Methoden nutzen wollen, sollte unser Vorgehen zum Adressieren von Risiken einige neue Eigenschaften aufweisen.

Um Verschwendung und Missverständnisse zu vermeiden, möchten wir, dass das Erkennen, Verstehen und Adressieren von möglichen Überraschungen durch die Fachexperten selbst erfolgt. Um Risiken in der Softwareentwicklung abzufangen, braucht es Softwareentwickler. Für das Einschätzen finanzieller Risiken braucht es jemanden, der sich mit den Finanzen des Vorhabens auskennt.

Eine dedizierte Rolle “Risikomanager” erhöht das Risiko, anstatt es zu senken, weil durch die zusätzliche fachfremde Person Wege länger und Missverständnisse wahrscheinlicher werden. Wir wollen also einen Prozess mit Handoffs und Zuständigkeiten durch direkte, kollaborative Zusammenarbeit im Team ersetzen. Damit wandert auch die Verantwortung für Risikomanagement in das Team selbst.

Viele Risiken lassen sich nur durch den Abgleich verschiedener Perspektiven erkennen. Wenn es z.B. bei einer zentralen Anforderung ein Missverständnis gegeben hat, werden das weder Kunde noch Teammitglied für sich allein erkennen können, weil beide von falschen Annahmen ausgehen. Erst im Dialog können diese Themen ans Licht kommen. Ein Risikomanagement, welches diesen Namen verdient, sollte also das Stattfinden dieser Dialoge bewusst fördern und den Abgleich von Annahmen und Blickwinkeln herausfordern.

In klassisch geplanten Vorhaben ist meist das Erreichen des ursprünglich geplanten Ziels das beste mögliche Ergebnis. Der mögliche Nutzen ist also durch den Wissensstand limitiert, der zu Anfang des Vorhabens verfügbar gewesen ist, und sinkt in dem Maß, wie sich das Umfeld und die Erwartungen während der Umsetzung verändern. Alles, was an neuen Erkenntnissen während des Vorhabens entsteht, ist in dieser Vorgehensweise nicht vorgesehen und daher meist unerwünscht, auch wenn es das Ergebnis noch deutlich verbessern könnte. Wir verschenken hier offensichtlich Potenzial.

Wenn wir uns von diesem Ansatz lösen, stellen wir fest: Risiken sind nur eine Hälfte der möglichen Ereignisse, auf die man reagieren können möchte. Chancen für eine spontane Verbesserung der Ergebnisse werden in unserem oft sicherheitsfixierten Arbeitsumfeld meist gar nicht erst wahrgenommen, geschweige denn genutzt. Wir wollen also weg vom Begriff des Risikos, hin zu einem Überbegriff für mögliche, für das Vorhaben relevante Ereignisse in der Zukunft. Für den treffenden englischen Begriff “Contingency” gibt es auf Deutsch leider nur das etwas steife “Kontingenz“ oder „Eventualität“ – oder man nennt Kontingenzen einfach “Chancen und Risiken”. In jedem Fall sollten wir mögliche Ereignisse sowohl mit positiven als auch negativen Auswirkungen in unsere Vorausschau mit aufnehmen.

Schließlich wird aus einer solchen gemeinsamen Betrachtung nur dann ein “agiles Risikomanagement”, wenn dieser Prozess interdisziplinär, iterativ und inkrementell stattfindet und die identifizierten Maßnahmen den üblichen Weg durch den Arbeitsprozess nehmen, wie alle anderen Aufgaben auch.

Ein Methodenvorschlag

Mit den erwähnten Überlegungen im Kopf wäre hier eine Skizze von mir, wie man es machen kann – natürlich nicht muss. In regelmäßigen Abständen betrachtet das Team in einem kollaborativen Arbeitstermin mögliche Ereignisse in der Zukunft, die sich auf das Team und sein Vorhaben auswirken könnten. Für eine möglichst vollständige Betrachtung würde ich zu diesem Event mindestens Product Owner und Scrum Master (falls vorhanden), Kunden und/oder Projektsponsoren und natürlich das Entwicklungsteam einladen. Diversität der Blickwinkel ist immer eine gute Idee, bei der Betrachtung möglicher Risiken ist sie aber unerlässlich.

Für den Aufbau des Termins können wir eine Visualisierungsmethode nutzen, die ich mal “Eventualitäten-Analyse”⁶ nennen würde:

In einer eher offen gestalteten Arbeitsphase wird ein Diagramm wie das folgende von den Anwesenden befüllt. Dazu werden mögliche Ereignisse in der Zukunft gesammelt, nach ihrer Auswirkung positiv-negativ und ihrer groben Eintrittswahrscheinlichkeit sortiert. Wir können uns das Diagramm als erweiterte Risikomatrix denken, die um einen Bereich positiver Auswirkungen erweitert wurde, und die ohne eine künstliche Abgrenzung in “Stufen” auskommt.

Für die Maßnahmenfindung will man sich anschließend auf drei Bereiche konzentrieren, nämlich auf Chancen mittlerer Wahrscheinlichkeit (wie können wir sie wahrscheinlicher machen?) und auf Risiken hoher bis mittlerer Wahrscheinlichkeit (wie können wir sie unwahrscheinlicher machen oder sie durch Vorbereitung abfedern?).

Wenig Handlungsbedarf sehe ich bei Ereignissen, die sich kaum positiv oder negativ auswirken; unwahrscheinlichen Ereignissen, und sicher zu erwartenden, positiven Ereignissen (ein Grund zur Freude, aber kein Handlungsbedarf). Diese kann man natürlich ebenfalls auf Maßnahmen abklopfen, hierauf würde ich aber keinen besonderen Fokus legen.

Maßnahmen können dann grob in eine von zwei Strategien fallen, analog zu den Achsen im Diagramm: entweder die Auswirkung des Ereignisses durch Vorbereitung zum Positiven zu verändern, oder die Eintrittswahrscheinlichkeit zu beeinflussen, das heißt Risiken unwahrscheinlicher und Chancen wahrscheinlicher zu machen. Identifizierte Maßnahmen werden entweder sofort umgesetzt (z.B. Anpassen der Arbeitsmethodik) oder in das Backlog des Teams aufgenommen und wie normale Aufgaben priorisiert und bearbeitet. Die Umsetzung der längerfristigen Maßnahmen kann dann im Alltag mit Ideen wie beispielsweise der Stop Work Authority-Karte⁷ kombiniert werden, um auch kurzfristige Risiken zu erkennen und zu besprechen.

Wann und wie oft dieser Austausch nützlich ist, ist sicher kontextabhängig. Eine Durchführung ein paar Mal im Jahr erscheint mir sinnvoll, bzw. zeitnah nach dem Start eines Projekts, oder auch immer dann, wenn sich die Rahmenbedingungen wesentlich geändert haben (z.B. eine neue Deadline, die zu halten ist). Wer dafür kein zusätzliches Meeting ansetzen möchte, kann diesen Termin auch anstelle einer der regulären Retrospektiven einplanen. Den Auftrag, die „eigene Arbeitsweise zu reflektieren und gegebenenfalls anzupassen“, erfüllt dieses Format mit Sicherheit, und es lockert die oft ermüdende Reihe von „was lief gut, was lief schlecht, was sollten wir anders machen“-Standardretrospektiven auf.

Natürlich will auch der Nutzen dieser Termine regelmäßig inspiziert und das Format bei Bedarf angepasst werden. Es wird auch weiterhin vorkommen, dass manche Ereignisse das Team unvorbereitet erwischen können – da wird es sich ebenfalls lohnen zu besprechen, wie man derartige Überraschungen in Zukunft früher erkennen könnte.

Ein Wort der Warnung: Termine wie diese haben ein gewisses Konfliktpotenzial – etwa, wenn direkt nach Projektstart sich Kunde und Entwicklungsteam plötzlich darüber unterhalten, wie realistisch der neue, vorgezogene Liefertermin noch ist. Ich bin überzeugt, dass es sinnvoll ist, diese Unterhaltungen früh, ehrlich und gemeinsam zu führen, aber es lohnt sich, vorbereitet zu sein und Erfahrung in Moderation und Gesprächsführung mitzubringen.

Fazit

Im Großen und Ganzen scheinen viele agile Vorhaben ohne jegliches explizite Risikomanagement auszukommen. Ich begrüße das überall dort, wo es nicht notwendig ist, und erinnere gerne an das zehnte agile Prinzip, im Sinne der Einfachheit die Menge nicht zu erledigender Arbeit zu maximieren. Ich mache aber ebenfalls die Erfahrung, dass es reichlich Situationen gibt, in denen ein Mindestmaß an vorausschauendem Handeln wichtig gewesen wäre. Hier setzen sich agile Teams unnötigerweise dem Vorwurf unprofessionellen, chaotischen Handelns aus und beschädigen eben die Vertrauensbeziehungen, auf die agile Ansätze zum Erfolg angewiesen sind.

Die Lösung kann nun nicht sein, einem agilen Team einfach eine klassische Projektorganisation mitsamt Risikomanagementstruktur aufzukleben. Derartige “Hybridansätze” zeigen seit nunmehr zwei Jahrzehnten, dass sie zuverlässig mehr Probleme schaffen als sie lösen – kaum verwunderlich, schließlich werden hier immer wieder Methoden miteinander kombiniert, die für unterschiedliche Problemklassen entwickelt wurden⁸ und deren Grundannahmen nicht miteinander kompatibel sind.

Von einem professionell handelnden Team kann man in meinen Augen erwarten, dass es nicht nur die Vergangenheit betrachten und daraus Erkenntnisse für die Gegenwart ableiten kann; sondern auch, dass es seine Fachkompetenzen einsetzt, um zukünftige Ereignisse frühzeitig zu erkennen, zu beobachten und, wenn nötig, vorbereitende Maßnahmen zu ergreifen. In welcher Form das getan wird, steht dem Team natürlich offen. Es bietet sich aber an, dafür allgemein akzeptierte Ideen und Hilfsmittel aus agilen Kontexten zu nutzen – Retrospektiven, interdisziplinäre Workshopsettings, kollaborative Visualisierungsmethoden und existierende Prozesse zum Sammeln, Priorisieren und Erledigen von Aufgaben. Die Rolle “Risikomanager” hat in einem solchen Umfeld sicher nur noch selten eine Berechtigung, stattdessen wird Risikomanagement, wie viele funktional geschnittene Spezialistenrollen von früher, einfach eine alltägliche Aufgabe des Teams, das für die Entwicklung des Produkts oder Services verantwortlich ist.

 

Hinweise:

Interessieren Sie sich für weitere Erfahrungen aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Weitere Artikel von Kai-Marian Pukall sind u .a. bei Inspect&Adapt und auf LinkedIn zu finden.

[1] Wohland u. Wiemeyer: „Denkwerkzeuge der Höchstleister“, S. 168
[2] https://ronjeffries.com/xprog/blog/risk-is-the-water-in-which-the-agile-fish-swims/
[3] Cynefin-Framework
[4] Blau-Rot-Unterscheidung
[5] Scrum Guide
[6] angelehnt an eine Methode aus „Liftoff“ von Diana Larsen und Ainsley Nies
[7] Stop-Work-Authority-Karte
[8] siehe ebenfalls die Blau-Rot-Unterscheidung, z.B. in „Denkwerkzeuge der Höchstleister“ oder „Komplexithoden“ von Niels Pfläging und Silke Herrmann.

Dies ist ein Best of Blog 2021 Beitrag. Hier können Sie sich die besten Beiträge aus 2021 herunterladen.

Kai-Marian Pukall hat weitere Beiträge im t2informatik Blog veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.