Über die letzten Jahre hinweg haben wir die Methodik in unseren Projekten “agilisiert”. Wir führen mittlerweile kein neues Projekt mehr durch, ohne uns in irgendeiner Art agiler Methoden zu bedienen. Dies wird dadurch gestützt, dass uns das agile Wertesystem in der gesamten Organisation wichtig ist und wir dieses leben. Das heißt nicht, dass jedes Projekt in Scrum in Reinform durchgeführt wird, jedoch streben wir in diese Richtung. Genau dabei hat sich der bewusste Umgang mit Risiken als wichtiger Aspekt herausgestellt.
Doch warum ist das so? Je weniger man versucht einen längeren Zeitraum detailliert vorauszuplanen, desto wichtiger ist es, sich mit Risiken auseinanderzusetzen, die das jeweilige Projekt negativ beeinträchtigen oder sogar scheitern lassen können. Da wir in unseren Projekten konsequent Azure DevOps als ganzheitliche Entwicklungsplattform und somit auch für das agile Projektmanagement einsetzen, bietet es sich an, auch die Risiken darüber zu verwalten und nachzuverfolgen. Unseren aktuellen Ansatz dazu möchten wir mit diesem Blogpost teilen.
Dem ganzen Thema liegen folgende Annahmen bzw. Randbedingungen zu Grunde:
- Ein einzelnes Risiko lässt sich benennen, beschreiben und klassifizieren.
- Es gibt Risiken, zu deren Vermeidung oder zumindest Abschwächung Maßnahmen ergriffen werden und andere, die akzeptiert werden.
- Die Risiken sind offen für das gesamte Projektteam sichtbar und nachverfolgbar.
In den meisten unserer Projekte setzen wir in Azure DevOps das Scrum-Template als Prozessbasis ein. Dieses wird nun durch einen weiteren Work Item Type “Risk” angereichert (siehe Abbildung 1). Im CMMI-Process von Azure DevOps ist ebenfalls ein Risk Work Item Type vorhanden. Der hier beschriebene Work Item Type ist in manchen Punkten an diesen angelehnt, im Detail dann jedoch auch abweichend. Der von uns verwendete Risk Work Item Type ist maßgeblich durch folgende Attribute gekennzeichnet:
- Beschreibung
- Description: HTML
- Mitigation Plan: HTML
- Justification: HTML
- Klassifizierung
- Probability: Int (0-100)
- Severity: Auswahl zwischen “1 – Critical”, “2 – High”, “3 – Medium” und “4 – Low”
- Type: Auswahl zwischen “External”, “Organizational”, “Project Management” und “Technical”
- Risk State: Auswahl zwischen “Mitigation defined” und “Risk accepted”
Bei dem Attribut “Type” arbeiten wir mit der oben aufgeführten einfachen Auswahl aus vier Werten, da wir eine leichtgewichtige Lösung wollen. In den Lehrbüchern zu Risikomanagement findet man hier sehr detaillierte Klassifizierungen für Risiken. Je nach Bedarf, kann diese Liste natürlich angepasst werden.
Dieser neue Work Item Type ist in keiner der Backlog-Ansichten zu sehen, da es sich nicht originär um ein Backlog Item handelt, welches eine gewisse Zielstellung beschreiben würde. Vielmehr handelt es sich um eine weitere Art an Informationen, die im Projektkontext verwaltet wird und die wiederum Einfluss auf die eigentlich Backlog Items nehmen kann. So ist es nicht selten, dass durch die Überlegungen bzgl. Risiken neue Backlog Items entstehen.
Um die Maßnahmen zu dokumentieren, die von einem Risiko ausgehen, steht in unserem Ansatz das Freitextfeld “Mitigation Plan” zur Verfügung. Dort kann man optional den Ansatz zum Umgang mit einem bestimmten Risiko beschreiben. Darüber hinaus sollen Backlog Items, die aus dem Risiko heraus entstanden sind oder zumindest mit dem Risiko in Verbindung stehen, auch mit dem Risiko verknüpft werden (siehe Abbildung 2).
Das Risk Work Item selbst kennt drei Zustände:
- New: Das Risiko wurde identifiziert und in die Liste der bekannten Risiken aufgenommen
- Committed: Das Risiko wird analysiert und ggf. werden Gegenmaßnahmen eingeleitet.
- Done: Die Risikoanalyse ist abgeschlossen.
Der Zustand Done bedeutet demnach nicht, dass das Risiko beseitigt wurde. Jedoch wurden die Maßnahmen definiert und ggf. Backlog Items dafür erstellt. Deren Abarbeitung wird dann separat über deren Status verfolgt. Im Zustand Done gibt es jedoch noch din weiteres Datum, welches von Bedeutung ist, nämlich “Risk State”. Spätestens im Zustand “Done” des Risk Work Items muss man festlegen, ob zu dem Risiko Gegenmaßnahmen definiert wurden oder aber das Risiko ohne Maßnahme akzeptiert wird. Dies legt man durch einen der beiden möglichen Werte “Mitigation defined” oder “Risk accepted” fest (siehe Abbildung 4).
Um einen schnellen Blick auf die Risiken im Projekt zu ermöglichen, visualisieren wir diese auf verschiedene Arten auf dem Dashboard in Azure DevOps. Nachfolgend ein paar Beispiele.
Die Matrixdarstellung bietet eine gute Übersicht mit Priorisierung aus Severity und Probability. Links unten sind die Risiken mit der höchsten Eintrittswahrscheinlichkeit und den schwerwiegendsten Auswirkungen. Dies nimmt nach rechts oben ab.
Dieser Ansatz kann als Anregung dienen, die Risiken mit vollkommener Transparenz in Azure DevOps zu verwalten und dabei von allen Vorteilen integrierter Daten zu profitieren. Gerne kann der Ansatz dabei beliebig nach den eigenen Bedürfnissen angepasst werden. Wir freuen uns auch über jede Rückmeldung, wie Sie mit dem Thema Risikomanagement in Ihren Projekten umgehen.