Der richtige Umgang mit Risiken bei Scrum

Bei klassischen Projektumsetzungen beispielsweise mittels Wasserfallmodell gibt es einen Projektleiter. Dieser hat unter anderem die Aufgabe, Ressourcen zu planen und Risiken zu mangen. Welche Risiken in welcher Form und mit welcher Priorität behandelt werden, entscheidet beim Wasserfallmodell klassischerweise der Projektleiter. Ein System, welches fehleranfällig und sehr stark von einer Person abhängig ist – dem Projektleiter. Das bringt Vor- und Nachteile.

Vorteile hierbei sind:

  • Es gibt ein dezidiertes Risikomanagement
  • Es gibt klare Verantwortungsbereiche

Nachteile sind:

  • Das Risikomanagement ist vom Projektleiter abhängig
  • Die Art des Risikomanagements schwankt stark zwischen verschiedenen Projekten
  • Der Aufwand der im Risikomanagement betrieben wird, hängt stark vom Projekt, vom Projektleiter, und von der Projektphase ab.

Bei Scrum wird das Thema Risiko anders angegangen. Es gibt keine dezidierte Rolle die bei Scrum für Risikomanagement verantwortlich ist. Das liegt daran, dass bei Scrum die drei Rollen, drei verschiedene Kompetenzbereiche haben, es aber keine eigene Rolle gibt die das Thema Risikomanagement inne hat.

Scrum - Rollen Zusammenspiel der Rollen beim Optimierungsproblem, Scrum Master, Team und Product-Owner kümmern sich um ihre Hauptaufgaben. Das richtige Produkt, richtig und schnell zu bauen. Ein Optimierungsproblem.

Der Product-Owner konzentriert sich auf den Kompetenzbereich

  • das Richtige bauen.

Das Team konzentriert sich auf den Kompetenzbereich

  • es richtig zu bauen

Der Scrum Master konzentriert sich darauf

  • das Team zu unterstützen es schnell(er) zu bauen (bzw. die Abläufe zu verbessern, Hindernisse zu beseitigen und schneller und effizienter zu werden)

Generell gibt es in Softwareprojekten folgende Risiken

In Software-Projekten gibt es verschiedene Risikobereiche bzw. Klassen oder Arten von Risiken. Es gibt:

  1. Produktrisiken – Geschäft und Markt
  2. soziale Risiken
  3. technische Risiken
  4. das Risiko Kosten- oder Zeitpläne nicht zu erreichen.

1. Produktrisiken – Geschäft und Markt

  • „Bauen ich das Richtige Produkt?“
  • „Werden die Features die wir Planen wirklich vom Markt und unseren Usern gewünscht?“
  • „Ist die Software, die wir bauen Legal?“

Solche Fragen fallen alle in die Kategorie Produktrisiken. Es ist wichtig sich frühzeitig mit diesen Fragen zu beschäftigen und das Richtige Produkt zu bauen. Eine Aufgabe die bei Scrum vor allem der Product-Owner hat.

2. Soziale Risiken

Als Soziale Risiken definieren wir soziale, personenbezogene Abhängigkeiten im Team, die einen erheblichen negativen Einfluss auf das Projekt haben können.

Die Frage lautet:

  • „Können diese Teammitglieder das bauen?“

So ist es beispielsweise ein hohes Risiko, wenn die Kernteile einer Software von nur einem Software-Entwickler implementiert werden. Im Falle eines Ausfalls, eines Krankenstandes, oder eines Abgangs des Entwicklers geht somit viel Knowhow verloren und es kann ein Schaden entstehen. Auch der Tunnelblick von einzelnen Mitarbeitern kann ein Risiko darstellen. Software-Entwicklung ist ein sehr breites Thema. Das benötigte Wissen ist so breit, dass kein einzelnes Teammitglied alleine alle Themen abdecken kann. Setzt das Team aufgrund des vorhandenen Knowhows auf eine bestimmte Architektur, vernachlässigt wichtige Tätigkeiten in der Qualitätssicherung oder andere Tätigkeiten so kann dies ein erhebliches Risiko für ein Projekt darstellen.

3. Technische Risiken

Technische Risiken sind vor allem bei Softwareentwicklungsprojekte die Regel, die nicht rein in die standardmäßige Datenverarbeitung eingeordnet werden können. Die Fragen die wir uns hier stellen sind:

  • „Wird die Software auf der geforderten Plattform laufen?“
  • „Wird die Software skalieren?“
  • „Wird die Software in 20 Jahren weiterhin wartbar sein?“

Bei Projekten die mit Cutting-Edge-Technologien einsetzen und in neue Bereiche vorstoßen, gibt es besonders viele technische Risiken. So kann es beispielsweise eine technische Herausforderung sein, bei IoT-Devices eine Konnektivität und eine gewisse Reaktionszeit zu gewährleisten. Vor 10 Jahren wäre eine flächendeckende Abdeckung mit High-Speed Internet nicht denkbar gewesen. Die technischen Hürden waren diesbezüglich sehr hoch. Heute ist der 3G Ausbau sehr weit fortgeschritten und 5G steht in den Startlöchern. Infrastruktur und Cutting-Edge IoT-Technologie wie beispielsweise Microsoft Azure-IoT-Hub machen eine technische Umsetzung leichter.

4. Wirtschaftliche Risiken in Kosten- und Zeitpläne

  • „Können wir das Produkt mit geringen Kosten bauen um es nachher gut verkaufen zu können?“
  • „können wir das Produkt rechtzeitig auf den Markt bringen?“

Selbst wenn ein Produkt perfekt die Wünsche seiner User erfüllt, kann ein Projekt dennoch scheitern, wenn das Produkt zu spät am Markt ist und die Konkurrenz schneller war, oder in der Entwicklung so viele Kosten entstanden sind, dass es keiner für einen wirtschaftlich sinnvollen Preis verkaufen kann oder kaufen möchte. Einen Zeit- und Kostenplan einzuhalten ist entscheiden für den Projekterfolg. Ein nichteinhalten ein Risiko.

Risikomanagement in Scrum

Scrum sieht für das Thema Risikomanagement vor, dass risikoreiche Aufgaben/Features möglichst früh im Backlog angelegt werden und abgearbeitet werden. Es werden beispielsweise Spikes angelegt, sobald technische Herausforderungen, Risiken und Unsicherheiten identifiziert wurden. Diese Spikes werden dann vom Team möglichst zeitnahe bei einen der nächsten Sprints umgesetzt. Die Idee hierbei ist, alle technischen Unsicherheiten gleich zu Beginn zu eliminieren. Dadurch steigt bei zukünftigen Aufgaben die Schätzungsgenauigkeit, weil ja die schwierigsten Aufgaben bereits erledigt wurden und Unsicherheiten aus den Weg geräumt wurden. Alle nachfolgenden Aufgaben sind dementsprechend leichter und besser zu schätzen.

Der Product-Owner priorisiert im Idealfall die Product-Backlog-Items (=PBIs) mit dem höchsten Wert für die Benutzer zuerst. Das senkt das Risiko, das falsche Produkt zu implementieren oder für den User wertlose Features zu realisieren und somit das Produktrisiko. Durch die iterativ-inkrementelle Vorgehensmethode die Scrum aufweist, werden bereits sehr früh Produktinkremente hergestellt, welche den Usern und Stakeholdern wie bspw. dem Legal-Department vorgestellt werden können. Dadurch kann frühzeitig Feedback eingeholt werden und welches wieder in das Produkt einfließen kann.

Soziale Risiken werden bei Scrum durch Retrospektiven Meetings und Standups adressiert. Hier kann jedes Teammitglied Probleme und Verbesserungspotentiale aufzeigen. Bei Standups kann außerdem ein Austausch entstehen. Wenn einzelne Teammitglieder sehen, dass andere Teammitglieder eine Aufgabe angehen, können sie kooperieren und eingreifen. Da das ganze Team für die Umsetzung verantwortlich ist, wird die Bildung von Spezialisierungen und Expertenwissen eher verhindert. Es gibt aber laut Scrum-Theorie keine Pflicht und keine Arena für detaillierten Wissensaustausch. In der Praxis werden (Code-)Reviews eingesetzt um Wissen zu streuen und Qualität zu sichern.

Kosten- und Zeitpläne zu erreichen ist ein komplexes Thema, was man grob als eine der Hauptaufgaben des Projektmanagements zusammenfassen kann. Daher ist das Risiko diese Pläne nicht zu erreichen natürlich dementsprechend schwierig zu adressieren. Scrum bietet keine komplexen Kosten und Zeitpläne wie es das klassische Projektmanagement mit Netzplänen und Gant-Diagrammen anbietet und verwendet. Scrum hat die Strategie kritische Aufgaben möglichst bald umzusetzen, ein Product-Backlog aufzubauen und Sprints zu planen. Durch Burn-Up Charts und Velocity-Messungen können vorhersagen getroffen werden und Zeitpläne entwickelt kontrolliert und gesteuert werden. Durch Retrospektiven wird der Prozess regelmäßig reflektiert und optimiert, was wiederum Kostenrisiken minimiert.

Was bietet Scrum nicht im Risikomanagement

Scrum macht sich als Framework keine konkreten Gedanken über Risikomanagement. Es gibt keine eigene Arena die sich dem Thema Risikomanagement annimmt kein regelmäßiges Meeting und keine definierten Artefakte. Risiken werden zwar auf unterschiedlichen Teilbereichen adressiert, aber nicht explizit gemanaged. Es reicht nicht, sich darauf zu verlassen, dass jeder Projektbeteiligte in seiner Rolle auch die vorhandenen Risiken beleuchtet und sich um das Risikomanagement annimmt. Vielmehr muss der Scrum-Prozess um eine eigene Arena für Risikomanagement erweitert werden.

Wie kann der Scrum-Prozess um Risikomanagement erweitert werden?

Es muss ein gezieltes explizites Risikomanagement in Scrum-Projekten durchgeführt werden. Der Product-Owner hat in seiner Rolle den größten Einfluss auf das Risikomanagement. Es ist daher ratsam das Risikomanagement bei ihm anzusiedeln. Er kann selbstorganisiert Product Backlog Items (PBIs) zum Risikomanagement anlegen und regelmäßig, beispielsweise jeden zweiten Sprint im Sprint-Planning und während des Sprints, Platz für das Risikomanagement schaffen. Als Resultat und Arbeitsergebnis dieser PBIs kann eine Risikoliste geführt und gewartet werden, die die größten Risiken listet. Danach kann das Product-Backlog um risikominimierende Aufgaben erweitert und PBIs besser priorisiert werden. Es können regelmäßig Risikomanagement-Meetings abgehalten werden die als zusätzliches Meeting Einzug in den Sprintablauf nehmen. Dieses Risikomanagement ergänzt das bereits vorhandene implizite Risikomanagement und macht es sichtbar. So kann jedes Scrum-Mitglied die Risikomanagementaufgaben in seinem Kompetenzbereich besser wahrnehmen.

Dieser Artikel gehört zur Artikelreihe Tipps für Product-Owner

Tipps für Product-Owner

 

Buchempfehlungen:

 

Mehr zum Thema Digitalisierung

https://www.facebook.com/Digitalisierung Täglich zwischen 20 und 100 Beiträge aus über 200 verschiedenen Fachquellen

https://www.facebook.com/DerDigitalisierungsCoach/ Der DigitalisierungsCoach auf Facebook, Infos, Termine und mehr.

Zum Autor:

David Theil aus Linz Oberösterreich ist Digitalisierungs-Coach, Software-Entwickler und als Head of Software-Development für über 30 Softwareentwickler verantwortlich. Beruflich beschäftigt er sich bereits jahrelang mit der Digitalisierung und hat bereits bei vielen Digitalisierungs-Projekten in der Wirtschaft federführend mitgewirkt. Er bewegt sich in Themen wie Digitalisierung, IoT, oder Industrie 4.0 sowohl beratend als auch praktisch mit echten Lösungen.

https://medium.com/@david.theil

https://www.xing.com/profile/David_Theil

https://www.linkedin.com/in/david-theil-1a4190148/

https://www.linkedin.com/groups/8678887

https://twitter.com/DavidTheil

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: