Risikomanagement in Scrum Projekten

Risikomanagement ist sowohl im klassischen Projektmanagement wie auch in agilen Vorgehensweisen unverzichtbar. Hierdurch wird ein frühes Eingreifen bei Abweichungen ermöglicht und Fehlentwicklungen vermieden. Der Scrum Guide macht nur allgemeine Aussagen zu Risiken in Teilbereichen wie z.B. Länge der Sprints und Transparenz der Artefakte ([Teil-]-Arbeitsergebnisse). Konkrete Hinweise zum Risikomanagement fehlen im Scrum Guide. Wie oft in solchen Situationen bilden sich dann in der Scrum Community aus der Praxis entwickelte Vorgehensweisen heraus, die dann allgemein zur Anwendung kommen.

Risikomanagement in agilen Projekten

Risikomanagement befasst sich mit dem Umgang mit Risiken und den Maßnahmen zur Erkennung, Analyse, Bewertung, Behandlung, Überwachung und Kontrolle von Risiken.

Risiken sind dabei, die sich aus der Unvorhersehbarkeit der Zukunft ergebenden und durch teils zufällige Einflüsse verursachten Störungen, die zu Abweichungen von erwarteten Zielwerten führen. Dabei können diese Abweichungen sowohl negativer Natur („Gefahren/Wagnisse“) als auch positiver Natur sein („Chancen“). Risiken sind mit Unsicherheiten verknüpft. Je mehr Unsicherheiten, desto riskanter wird das Projekt.

In Abgrenzung zu Risiken die möglicherweise in der Zukunft eintreten können sind Impediments (Hindernisse), Probleme  bzw. Störungen aller Art, die während der Arbeit auftreten und einzelne Team-Mitglieder (oder auch das gesamte Team) an der effektiven Erledigung ihrer Aufgaben hindern,                  bereits eingetreten und müssen beseitigt werden.

Scrum bietet bereits aufgrund seiner Methodik bereits implizit bestimmte Mechanismen, die Risiken in der Entwicklung von Produkten, Dienstleistungen und Prozessen reduzieren können, unter anderem:

So steht z.B. nach jedem Sprint im Sprint-Review das Produkt-Inkrement auf dem Prüfstand.

Über die Länge der einzelnen Sprints wird das Risiko auf eine Sprintlänge eingegrenzt.

Die gezielt genutzte Strategie „fail fast (rasches Scheitern)“, ist ein gezieltes Vorgehen bei dem mit der Arbeit an einem Task oder Produktentwicklung begonnen wird, rasch Feedback eingeholt wird und abhängig davon entschieden wird, ob man weiter daran arbeitet oder ein anderer Ansatz ausprobiert wird – Inspect & adapt. Läuft eine Produktentwicklung nicht gut, dann sollte das so früh wie möglich offenbar werden, um nicht Zeit und Finanzmittel zu verschwenden.

Im Product Backlog sollten daher die Einträge unter anderem auch nach der Risikohöhe priorisiert werden, um solche Einträge möglichst frühzeitig abzuarbeiten und so das Risiko zu mindern.

Ein ganz wichtiger Aspekt zur Risikokontrolle in Scrum ist die Schaffung von Transparenz. Scrum basiert auf einer umfassenden Transparenz der Artefakte (Arbeitsergebnisse, u.a.  Produktinkrement). „…Entscheidungen zur Wertoptimierung und Risikokontrolle werden auf der Basis des festgestellten Zustands der Artefakte vorgenommen…“ (siehe Scrum Guide 2017). Ob die Transparenz wirklich umfassend ist, kann durch Erkennung von Mustern, intensives Zuhören und die Erkennung von Abweichungen zwischen den erwarteten und den tatsächlichen Resultaten festgestellt werden.

Aufgaben, Rollen, Verantwortlichkeiten im Risikomanagement agiler Projekte

Risikomanagement wird vom gesamten Scrum Team bestehend aus dem Product Owner, dem Scrum Master und den Entwickler betrieben. Es ergeben sich jedoch aus den Rollenbeschreibungen und deren jeweiligen Aufgabenspektrum unterschiedliche Schwerpunkte für das Risikomanagement.

So ist der Product Owner für den wirtschaftlichen Erfolg des Produkts verantwortlich und er muss dabei den Wert des Produkts maximieren, das aus der Arbeit des Entwicklungsteams entsteht. Er organisiert, verwaltet und priorisiert den Backlog mit all seinen Anforderungen und hat damit großen Einfluss auf das Risikomanagement. Er steht mit vielen Stakeholdern in ständigem Kontakt und erschließt sich dadurch viele Quellen für die Identifikation von Risiken.

Der Scrum Master sichert die Einhaltung der Scrum-Spielregeln, hilft der Organisation Scrum zu verstehen und zu leben, wählt geeignete Praktiken aus um maximale Transparenz der Artefakte zu schaffen und hilft so die Risiken zu mindern. Darüber muss der Impediments beseitigen bevor diese zum Risiko werden.

Das Entwicklerteam als selbstverwaltendes, selbstorganisierendes Team ist für die technische Umsetzung der Anforderungen in das Produktinkrement verantwortlich. Alle daraus resultierende Risiken sind von diesem Team klären.

Grundsätzliche Vorgehensweisen beim Risikomanagement

Ein systematisches Risikomanagement umfasst die folgenden Schritte:

Abbildung: Vorgehensweise beim Risikomanagement

Erstellen Sie ein Risikoregister und pflegen Sie es regelmäßig über das initiale und laufende Risikomanagement im Scrum Life Cycle hinweg.

Abbildung Beispiel für ein Risikoregister

Strategien der Risikobehandlung

Für das Management bzw. die Behandlung von Risiken gibt es die nachfolgenden grundsätzlichen Strategien:

Abbildung Strategien der Risikobehandlung

Risikomanagement in Scrum beginnt bereits mit der Initiierung des Vorhabens

Risikomanagement kann unterteilt werden in ein initiales Risikomanagement und ein laufendes Risikomanagement.

 

Abbildung Agiler Life Cycle einer Scrum Produktentwicklung

Initiales Risikomanagement

Jedes Projekt/Produktentwicklung über Scrum entspringt einer Idee, einem erkannten oder vermuteten Bedarf/Anforderung von Kunden oder Anwendern oder hat einen gesetzlichen Hintergrund. Schon in der Initiierungsphase sollte unbedingt eine initiale Risikobetrachtung durchgeführt werden.

Das kann z.B. in einem Risiken-/Umfeldanalyse-Workshop mit den relevanten Stakeholdern durchgeführt werden.

Unter anderem gelten dabei folgende Risikoquellen zu beachten: 

Überzogenes Analysieren führen zu späten Time-to-Market – Exzessive Befassung mit Marktforschung, Marktanteile, Absatzzahlen, Gewinnprognosen etc. statt Entwicklung eines minimal viable products  und Einholung von frühem Kunden-/Anwenderfeedback. Risiken und Unsicherheiten gehören zu jeder Produktinnovation.

Kunden nicht einbeziehen, vermeintlich genau wissen was der Kunde will. Zeit und Geld werden investiert für Produkte die keiner will. Siehe hierzu auch unseren Blogbeitrag https://www.gotscharek-company.com/blog/wie-sie-produkte-und-dienstleistungen-entwickeln-und-projektergebnisse-generieren,-die-ihr-kunde-wirklich-will

Over-Engineering – Zu Beginn viel Funktionalität und perfekte Lösung entwickeln statt mit einem minimal viable product (einfacher Prototyp) zu starten das wachsen kann

Mögliche Betrachtungs-/Suchfelder für potenzielle interne und externe Risiken/Einflussfaktoren können dabei z.B. sein:

Abbildung Mögliche Betrachtungs-/Suchfelder für potenzielle Risiken

Im Rahmen der Initiierung des Scrum Entwicklungsvorhabens und des initialen Risikomanagements entsteht ein initialer Product Backlog. Der Product Backlog ist eine dynamisch sich laufend anpassende geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt.

Der Product Backlog enthält als Attribute eine Beschreibung die Reihenfolge (Priorität), die Schätzung und den Wert (Geschäftswert). In der Praxis hat sich herausbildet auch das Risiko mit einzubeziehen. Features mit hohem Wert und hohem Risiko werden zuerst entwickelt! Hier kommt die gezielte Strategie „fail fast“ zum Tragen.

In Workshops mit den relevanten Stakeholdern lässt sich mit einem qualitativen Ansatz eine solche Abschätzung relativ einfach treffen:

Abbildung Qualitative Einschätzung von Risiken

Im Rahmen eines paarweisen Vergleichs werden dann die Features jeweils hinsichtlich Wert und Risiko paarweise miteinander verglichen und können so in die Quadranten eingeordnet werden.

Neben anderen zu identifizierenden Risiken gilt es auch eine weitere Risikoquelle, nämlich das mit den richtigen Skills und Verfügbarkeit ausgestattete, cross-funktional besetzte und sich selbst organisierende Entwicklerteam zu beachten.

Laufendes Risikomanagement – Ansatzpunkte für Risikomanagement

Häufig liegt in der Praxis der Fokus des Scrum Teams im Sprint auf der Umsetzung sodass ein systematisches Risikomanagement oftmals gar nicht oder nur unzureichend durchgeführt wird.

Abbildung Ansatzpunkte für Risikomanagement in Scrum Projekten

Ansatzpunkt 1 – Sprint Planning

Die Sprintlänge legt das Scrum Team je nach Produkt individuell fest. Sie kann zwischen 2 und 4 Wochen betragen und sollte, einmal festgelegt, nicht mehr im weiteren Verlauf verändert werden. Zu groß gewählte Sprintlängen können zu einem Anstieg der Komplexität führen und damit das Risiko erhöhen. Ein gemeinsam im Scrum Team vereinbartes Sprint Ziel nach SMART Grundsätzen (Specific, Measurable, Achievable, Reasonable, Time Bound) macht klare Vorgaben wie das Produktinkrement auszusehen hat. In den Sprint Backlog gelangen nur Anforderungen aus dem Product Backlog die den Status „Ready“, zuvor als Definition of Ready - DoR vereinbart, entsprechen. Über das herunterbrechen der Anforderungen in einzelne Tasks entstehen auch weitere Quellen für die Identifikation potenzieller Risiken. Der Sprint-Umsetzungsplan regelt wie das Product Increment im Sprint entsteht. Diese Schaffung von hoher Transparenz mindert das Risikopotenzial für die Produktentstehung.

Ansatzpunkt 2 – Sprint

Im Sprint können soziale Risiken entstehen, die aus der Selbstorganisation sowie aus der zwischenmenschlichen Zusammenarbeit resultieren, die in jedem Team immanent sind.

Während des Sprints tauchen oftmals Impediments (Hindernisse) auf, die das Team bei der Erreichung des Sprint Ziels behindern. Offensichtlich werden diese in den daily scrums. Rasche Beseitigung durch den Scrum Master ist hier wichtig, damit Impediments nicht selber zur Risikoquelle werden. Auch die tägliche Pflege des Task Boards im daily scrum erzeugt maximale Transparenz über den aktuellen Fortschritt und lässt Fehlentwicklungen in Bezug auf den Fortschritt relativ rasch erkennen.

Über die Definition-of-Done – DoR, welche eindeutige Vorgaben macht wann eine User story wirklich fertig ist, werden Risiken die aus potenziellen Qualitätsmängeln resultieren könnten eingegrenzt.

Ansatzpunkt 3 – Sprint Review

Im Sprint Review steht das Product Increment auf dem Prüfstand. Dabei werden durch die Stakeholder (Kunde, Anwender, Scrum Team, Marketing, Vertrieb, etc) die technischen/fachlichen Funktionalitäten überprüft sowie die wirtschaftlichen und Umfeldbedingungen für das Produkt beurteilt. Der Inspect und Adapt Ansatz von Scrum ermöglicht hier rasche Anpassungen, was die Risiken für den Erfolg des Produkts mindert. Das wirtschaftliche Risiko ist beispielsweise auf eine Sprintlänge begrenzt, sollte von den Stakeholdern z.B. aufgrund geänderter Umfeldbedingungen eingeschätzt werden, dass die Produktentwicklung nicht weiter fortgeführt werden soll.

Ansatzpunkt 4 – Sprint Retrospektive

In der Sprint Retrospektive werden die Abläufe, Werkzeugeinsatz, Zusammenarbeit im Team etc kritisch hinterfragt und es werden Optimierungen gesucht, die schon im nächsten Sprint umgesetzt werden können. Auch dieser Schritt hilft mögliche Risiken kontinuierlich zu mindern, da nach jedem Sprint eine Sprint Retrospektive durchgeführt wird.

Literaturhinweise und interessante Links

Minimal viable Product

https://www.computerwoche.de/a/5-fragen-zum-mvp,3544544?tap=cb69aaacbde6b55b1fa6c9603a975639&utm_source=Nachrichten%20mittags&utm_medium=email&utm_campaign=newsletter&r=469616510941145&lid=965095&pm_ln=32

Paarweiser Vergleich

Projektmagazin: https://www.projektmagazin.de/methoden/paarweiser-vergleich

SMART Ziele definieren

https://de.wikipedia.org/wiki/SMART_(Projektmanagement)

Der Scrum Guide

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf

Fazit

Auch wenn Scrum schon implizit Mechanismen zur Risikoreduktion mitbringt, ist ein systematisches Risikomanagement unbedingt zu empfehlen. Insbesondere in der Initiierungsphase kann Risikomanagement dazu beitragen, die richtigen Entscheidungen zu treffen und die richtigen Weichen zu stellen.