Ein wesentlicher Vorteil von Scrum ist Transparenz. Ein hohes Maß an Transparenz gibt auch einen besseren Überblick über die Risiken. Neben der Transparenz sind auch die klar verteilte Verantwortung, hohe Flexibilität, kurze Iterationen und ein hohes Maß an kontinuierlicher Abstimmung Maßnahmen oder Methoden, um auch schnell und gut mit Risiken umgehen zu können. Scrum ist dabei aber keine Projektmanagement-Methode, sondern beschreibt ein Vorgehen für (vor allem) komplexe Softwareentwicklung. Die Annahme, man könne bei einem Vorgehen nach Scrum trotz oder wegen der beschriebenen Vorteile auf explizites Risikomanagement verzichten, halte ich für gefährlich.
Wer hat die Erfahrung noch nicht gemacht, dass leicht zu sehende große Risiken nicht eintreten, dafür aber die kleinen, nicht beachteten, große negative Folgen hatten? In eher klassisch nach Wasserfall organisierten Projekten ist in der Regel der Projektleiter für das Managen der Risiken verantwortlich. In Scrum verteilt sich die Verantwortung abhängig von der Art des Risikos. Aber auch bei einem Vorgehen nach Scrum sollte es ein dediziertes Risiko-Management geben, um auch die kleinen Risiken nicht aus dem Auge zu verlieren. Wie kann man da vorgehen?
Umgang mit Risiken:
Auch in Scrum ist ein strukturierter und geplanter Umgang mit Risiken hilfreich:
- Als erstes sollte man Risiken identifizieren und dokumentieren.
- Abschließend muss man die Risiken qualifizieren und quantifizieren.
- Dann bietet sich an einen Risiko-Indikatoren zu ermitteln.
- Auf der Basis kann man planen, wie man mit dem Eintreten von einzelnen Risiken umgehen will.
- Natürlich muss man die Risiken kontinuierlich beobachten.
Schon zu Beginn eines Projekts empfiehlt es sich, eine Liste der möglichen Risiken zu führen, die sich im Laufe des Projekts verändern kann. Die erste Version einer solchen Liste kann gut in einem „Risiko-Workshop“ mit repräsentativen Mitgliedern verschiedener Gruppen (Entwickler, Stakeholder, Lieferanten) erstellt werden.
Anschließend sollten die Risiken qualifiziert und quantifiziert werden. Dabei müssen alle Risiken berücksichtigt werden. Bei der Qualifizierung von Risiken muss die Relevanz für das Projekt eingeschätzt werden. Es wird immer Risiken geben, deren Eintrittswahrscheinlichkeit so niedrig ist, dass eine weitere Betrachtung im Projektkontext nicht notwendig ist.
Die durch die Qualifizierung gefilterten, für das Projekt relevanten Risiken müssen quantifiziert werden. Das mögliche Ausmaß des Schadens (beispielsweise verlorene Zeit, geringere Produktivität, nicht Erreichen von Anforderungen) bei Eintreten muss eingeschätzt werden. Diese Informationen sind bei weiteren Planungen der Umsetzung hilfreich.
Jedes Risiko hat Auslöser und es ist hilfreich, diese Auslöser zu kennen. Zusätzlich ist es gut zu wissen, welche Umstände dazu führen, dass das Eintreten eines Risikos wahrscheinlicher oder unwahrscheinlicher wird.
Die Frage, wie man mit den jeweiligen Risiken umgehen will, sollte außerdem geklärt sein und jedes Risiko wird hier eigene Antworten erfordern. Üblicherweise gibt es vier grundsätzliche Strategien, Risiken zu reduzieren:
- Risiko-Ursache beseitigen
- Risiko eingehen
- Risiko reduzieren
- Das Risiko verschieben
Während der Entwicklungszeit müssen die Risiken kontinuierlich überwacht werden. Dabei kann man immer wieder neu bewerten, ob die getroffenen Einschätzungen noch gelten, neue Risiken hinzugekommen oder bestehende vernachlässigbar sind.
Verantwortlichkeit
Die Verantwortlichkeiten des Projektleiters teilen sich in Scrum auf die verschiedenen Rollen Product Owner, Team und Scrum Master auf. Der Scrum Master kümmert sich darum, dass das Team möglichst gut arbeiten kann. Das Eintreten von Risiken würde die Arbeit des Entwicklungsteam und damit die Ergebnisse für den Product Owner gefährden. Die Rolle des Scrum Masters bietet sich an, um die Risiken im Blick zu behalten, auch wenn er nicht immer die Aufgaben für die Vermeidung oder Reduktion von Risiken übernehmen können wird.
Welche Risiken gibt es?
Auf externe Risiken hat das Projektteam nur eingeschränkt Einfluss. Dazu gehören zum Beispiel übergeordnete strategische Entscheidungen, finanzielle Veränderungen, manche operative Themen außerhalb des Umsetzungsteams und ähnliches. Diese Risiken sind Projektverantwortlichen in der Regel bewusst, meistens gibt es hier keinen konkreten Management-Plan.
Projektrisiken betreffen das Projekt und die Umsetzung selbst. Darunter fallen Risiken wie zum Beispiel der Umfang, die Betriebsumgebung, Methoden und Werkzeuge, Organisation und Management, Anforderungen, Hardware, Software und andere, vielleicht einzigartige das Projekt betreffende Themen. Normalerweise sind diese Themen den jeweils Verantwortlichen bewusst und ihre Größe ist bewertet.
Anwendungsrisiken betreffen den Umsetzungsprozess, die Mitarbeiter, die Technologie oder die Umgebung. Diese Risiken treten meistens in der Umgebung auf, während ein Projekt von den Anforderungen in die Umsetzungsphase gehen. In einem nach Scrum entwickelten Projekt können diese Risiken also kontinuierlich auftreten. Die Risiken werden häufig erst während der Umsetzung erkannt und bewertet.
Risiken entstehen ganz unabhängig von der Methode, mit oder nach der man komplexe Software entwickelt und lassen sich nicht vollständig vermeiden. Ein gutes Risiko-Management hilft aber dabei, schneller richtige Entscheidungen zu treffen.
Anstoß und Grundlage für diesen Artikel war ein Blog-Beitrag von Richard Payne.