So machen Sie Risikomanagement bei agilen Projekten

Risikomanagement bei agilen ProjektenIm letzten Beitrag „Ist Risikomanagement bei agilen Projekten notwendig?“ habe ich Ihnen gezeigt, warum Risikomanagement auch bei agilen Projekten notwendig ist. In diesem Beitrag erfahren Sie, wie Sie das Risikomanagement bei agilen Projekten umsetzen und auf was Sie dabei achten müssen.

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“.

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 wie: Machbarkeit, Akzeptanz, Time-to-Market, Kosten Personensicherheit.

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 Releases 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 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 bei der 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)

Risikomanagement im Projektablauf bei agilen Projekten

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 aber dann am Besten in einem 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 die 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.“

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 Büchern.

Der Product Owner oder Scrum Master sollte gute Risikomanagement-Kenntnisse haben, damit das Risikomanagement wirkungsvoll, aber auch effizient durchgeführt wird. Aber nicht nur das, sie sollten auch vom Risikomanagement überzeugt sein.

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.

Was haben Sie für Erfahrungen mit dem Risikomanagement bei agilen Projekten gemacht? Stimmen Sie mit meinen Aussagen überein oder haben Sie eine andere Ansicht? Teilen Sie Ihre Erfahrung mit einem Kommentar den Lesern mit, damit wir alle eine weitere Sicht kennenlernen. Danke!

Wollen Sie mehr über das Risikomanagement bei Projekten oder Scrum erfahren? Meine Bücher über Projekt-Risikomanagement oder Scrum bringen Sie einen wichtigen Schritt weiter!Risikomanagement-Buch

Kennen Sie jemanden, den dieser Beitrag auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn. Danke!

HAT DIR DIESER ARTIKEL GEFALLEN?

Erhalte monatlich meine Blog-Updates und mein kostenloses eBook: Projektplanung

E-Mail Adressen werden vertraulich behandelt und nie weitergegeben

Posted in Agiles Projektmanagement, Risikomanagement.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.