So machen Sie Risikomanagement bei agilen Projekten

Nach meiner Meinung ist Risikomanagement bei agilen Projekten eines der am meisten vernachlässigten Themen. Oft wird gemeint, dass Risikomanagement bei agilen Projekten nicht notwendig ist, weil das agile Vorgehen die Risiken eliminiert. Das ist jedoch etwas kurzsichtig. In einem früheren Artikel habe ich Ihnen gezeigt warum “Risikomanagement auch bei agilen Projekten notwendig ist.  In diesem Artikel erfahren Sie, wie Sie Risikomanagement bei agilen Projekten umsetzen und auf was Sie dabei achten müssen. Jeder Scrum Master, Product Owner oder Developer kann hier sicher noch ein paar hilfreiche Tipps hinzulernen. Sicher!

Bei Projekten geht immer etwas schief – auch bei agilen

Risikomanagement ist auch bei agilen Projekten ein Thema – aber oft ein vernachlässigtes! Auch Jeff Sutherland (ein Mitgründer von Scrum) hat seine Erfahrungen mit Risiken gemacht und diese an ein Zitat von General Carl von Clausewitz (Buch: Vom Kriege) angelehnt:

As soon as you try to execute anything, even a software project, bad things happen!

Er bemerkte dazu: “Sie kennen sicher auch solche Momente: Es gibt eine Menge Lärm und Verwirrung, manchmal gibt es Rauch und Feuer und die Kommunikation bricht zusammen und alles verschwört sich, nur um Sie davon abzuhalten Dinge zu erledigen”.

In seinem Buch “Scrum: The Art of Doing Twice the Work in Half the Time“, beschreibt Jeff Sutherland, dass in Scrum-Projekten normalerweise drei Arten von Risiken vorherrschen:

• Finanzielles Risiko – können wir dafür bezahlen?
• Business-Risiko – wird es genutzt? Lässt sich damit das Problem lösen?
• Technisches Risiko – kann es hergestellt oder gebaut werden? (oft im Zusammenhang mit der Finanzierung, wenn ein Produkt gebaut werden kann, aber zu teuer ist).

Und er fasst zusammen: Der beste Weg, Risiken generell zu reduzieren, ist: “Erstellen Sie potenziell releasebare Inkremente für die Benutzer”. Genügt das wirklich?

Haben Sie nach dem Risikomanagement auch schon im aktuelle Scrum Guide Ausschau gehalten?

Risikomanagement im Scrum Guide

Im Scrum Guide wird das Risikomanagement nicht explizit angesprochen, außer mit diesen knappen Hinweisen:

• dass das inkrementelle Vorgehen mit Sprints Risiken reduziert
• dass Sprints die Vorhersehbarkeit erhöhen und das Kostenrisiko auf maximal einen Monat beschränken
• dass die ständige “Artifact Transparency” dazu beiträgt den (Business) Value zu optimieren und Risiken reduziert

Ist Jeff Sutherland tatsächlich der Meinung, dass einzig durch das agile Projektvorgehen Risiken bestmöglich reduziert werden? Einen Teil der Risiken reduziert man damit bestimmt, wie Sie in meinem letzten Beitrag  “Ist Risikomanagement bei agilen Projekten notwendig?” gelesen haben, aber ein großer Teil der Risiken lauert irgendwo, um Sie irgendwann unverhofft zu überrumpeln.

Risiken identifizieren auf zwei Ebenen und an verschiedenen Zeitpunkten

Risiken sollten Sie bei agilen Projekten auf zwei Ebenen bestimmen:

• Auf  Projektebene: Was für Risiken bedrohen das Gesamtprojekt oder Epics (grosse User Stories) des Projektes?
• Auf Anforderungsebene (User Story): Was hat jede Anforderung für ein Risiko beim Umsetzen oder wenn diese im Betrieb ist? Dazu gehören z.B. Risiken bezüglich: Machbarkeit, Akzeptanz, Time-to-Market, Kosten, Personen- und Datensicherheit.

Schon bevor man ein Projekt startet sollte man dessen Risiken grob bewerten – und wenn diese zu hoch sind, das Projekt abbrechen bzw. überdenken.  Ein weiterer wichtiger Zeitpunkt ist der Anforderungsworkshop, der eine detailliertere Risikobetrachtung für das weitere Vorgehen liefert.

Risiken bestimmen beim Projektstart, Projekt-Kick-off oder Anforderungsworkshop

Beim Projektstart, Projekt-Kick-off oder Anforderungsworkshop sollte der Product Owner mit den Teilnehmern des Workshops auch die Risiken betrachten.  Die Teilnehmer sollten Risiken für das Gesamtprojekt, aber auch für die bereits bekannten Anforderungen identifizieren.  Dann sollte der Product Owner mit den Teilnehmern die Risiken bewerten und Maßnahmen definieren. Dauer ca. 30 Minuten bis 1 Stunde.

Risiken bestimmen bei der Releaseplanung

Bei jeder Releaseplanung (Mittelfristplanung) sollte der Product Owner mit dem Developement-Team und evtl. anderen Stakeholdern die bereits erfassten Risiken überprüfen und, wenn notwendig, neu bewerten. Falls die Release nur einen oder zwei Sprints umfassen, sollten diese Risikoreviews, abhängig von der Projektdauer, mindestens alle 2-3 Monate wiederholt werden. Dauer ca. 30 Minuten.

Der Product Owner benötigt den Risikowert einer Anforderung, denn der Risikowert ist – neben dem Business Value – ein wichtiges Kriterium, wenn er die umzusetzenden Anforderungen priorisiert. Anforderungen mit dem höchsten Risiko werden oft als erstes realisiert, nach dem Motto:

Fail early, fail fast, fail cheap

Risiken beim Sprint Planning identifizieren/überprüfen

Im Estimation Meeting, aber spätestens bei jedem Sprint Planning sollte das Scrum-Team die Risiken jeder einzelnen Anforderung nochmals kurz besprechen/überprüfen, evtl. neue Risiken identifizieren und bewerten und Maßnahmen definieren. Damit ist sich das Development-Team bei der Umsetzung der User Stories den Risiken bewusst und kann geplante Maßnahmen umsetzen. Aufwand 15-30 Minuten.

Die folgende Abbildung zeigt an welchen Zeitpunkten Risikomanagement-Aktivitäten bei einem Scrum-Projekt sinnvoll sind:

• Vor dem eigentlichen Projektstart (im Anforderungsworkshop oder umfassenden Kick-off Meeting)
• Bei jeder Releaseplanung (vor jedem neuen Release)
• Bei jedem Sprint Planning (beim Start jedes Sprints)

Den Risikowert bestimmen

Hier erhalten Sie eine ganz kurze Zusammenfassung wie Sie Risiken beschreiben und den Risikowert bestimmen.

Für jede Anforderung bestimmen Sie das Risiko und den Risikowert folgendermaßen:

• Beschreiben Sie die Unsicherheit (was könnte passieren)
• Bestimmen Sie die Auswirkung A (1=gering, 5=hoch)
• Bestimmen Sie die Eintrittswahrscheinlichkeit E (1=gering, 5=hoch)
• Multiplizieren Sie die Auswirkung (A) mit der Eintritts­wahr­schein­lichkeit (E) und Sie erhalten den Risikowert R=AxE
• Bestimmen Sie wenn möglich Maßnahmen, um das Risiko zu vermindern oder es zu eliminieren.

Sie bestimmen die Auswirkung und Ein­tritts­wahr­schein­lichkeit der Risiken effizient und ohne lange Diskussionen, wenn jedes Team­mitglied spontan seine Bewertung mit Aufhalten einer Karte von 1 bis 5 abgibt (wie Punktrichter beim Eiskunstlauf). Danach ermitteln Sie den ungefähren Mittelwert. Wenn eine Anforderung kein Risiko hat, dann hat es den Risikowert „0“.

Wenn Sie ein Risiko identifiziert haben, dann beschreiben Sie dieses ganz kurz auf der Rückseite der Karte, auf der die User Story geschrieben ist. Alle Risikodaten erfassen Sie dann aber am Besten in einem separaten Risk-Log. Dies kann eine einfache Datentabelle in Excel oder in einer anderen Software sein.

Wie bereits gesagt, das war nur eine sehr kurze Einführung. Investieren Sie doch den Betrag eines guten Starbucks-Kaffees und bestellen Sie diese gute Einführung das Projekt-Risikomanagement: Risikomanagement für Projekte – 30 Minuten Kompaktwissen.

Kürzere Sprints reduzieren Risiken

Je mehr Risiken Ihr Projekt hat, desto kürzer sollten Ihre Sprints sein. Sprints in Scrum haben eine maximale Dauer von 4 Wochen. Bei kürzeren Sprints kann der Product Owner häufiger den Projektfortschritt bestimmen und bei Abweichungen vom Plan schneller Maßnahmen einleiten. Kürzere Sprints von 1 oder 2 Wochen Dauer haben auch den Vorteil, dass sie mehr Druck generieren und damit den Fokus des Teams auf die Arbeit erhöhen.

Wenn Sie kürzere Sprints verwenden, dann sollten die Anforderungen, die in die Sprintplanung eingebracht werden, kleiner und detaillierter sein. Dies gibt natürlich mehr Vorbereitungsarbeit für den Product Owner.

Generell bedeuten kürzere Sprints, dass aus Anforderungen schneller ein auslieferbares Product Increment entsteht. Das heißt auch, es werden häufiger Retrospektiven durchgeführt, was sich positiv auf die Zusammenarbeit, die Prozesse und die Produktivität auswirkt und somit auch Projektrisiken reduziert.

„Je mehr Risiken Ihr Projekt hat, desto kürzer sollten die Sprints sein.“

Das Risikomanagement effizient und erfolgreich durchführen

Wie viel Zeit für das Risikomanagement aufwenden?

Ich habe in den oberen Abschnitten die ungefähre Zeitdauer angegeben für das Risikomanagement in den verschiedenen Abschnitten eines Scrum-Projektes. Die Dauer ist absichtlich knapp gehalten. Je grösser und komplexer Ihr Projekt ist, desto mehr Aufwand sollten Sie für das Risikomanagement einsetzen. Risikomanagement kann effizient und gleichzeitig erfolgreich durchgeführt werden. Dazu braucht es jedoch etwas Übung, bzw. Erfahrung. Tipps dazu finden Sie in meinen Risikomanagement-Büchern.

Wer ist verantwortlich für das Risikomanagement?

Verantwortlich für das Risikomanagement in einem Scrum-Projekt ist nach meiner Ansicht der Product Owner. Der Scrum Master ist dagegen die geeignete Person das Risikomanagement im Scrum-Team zu etablieren . Er sollte das Scrum-Team so weit bringen, dass es mit der Zeit dieses selbst erfolgreich durchführen kann.

Risikomanagement effizient durchführen braucht Wissen und Erfahrung

Risikomanagement in Projekten einsetzen braucht ein gutes Wissen über das Risikomanagement selbst (Prozess, Methoden), aber auch Übung, bzw. Erfahrung.
Nur ein Scrum Master, der hinter dem Risikomanagement steht und darin einen Wert sieht, kann das Scrum-Team vom Nutzen des Risikomanagements überzeugen. Der Scrum Master kann dem ganzen Scrum-Team als Coach und Mentor einen großen Nutzen bereiten und es vom Risikomanagement überzeugen und den Prozess zu Beginn schulen und führen. So werden auch agile Projekte noch erfolgreicher.

Mein Top-Tipp zum Schluss: Fangen Sie mit dem Risikomanagement an! Seien Sie vom Nutzen überzeugt. Nur schon über Risiken im Projekt sprechen reduziert deren Eintrittswahrscheinlichkeit! Ich wünsche Ihnen viel Erfolg.

Dies war jetzt nur eine sehr kurze Beschreibung zum Risikomanagement bei agilen Projekten. Ich habe zum Beispiel die Chancen weggelassen oder wie Sie Risiken richtig beschreiben und gute Maßnahmen definieren.

Hier gibt es noch mehr Wissen