Auch wenn das berühmte Agile Manifest bereits 2001 das Licht der Welt erblickt hat: Agilität ist nach wie vor DAS Top-Thema im Projektmanagement. Alles ist ja nun so einfach. Vor allem: Agiles Projektmanagement reduziert die Risiken nicht nur, sondern besser noch: Es gibt gar keine Risiken mehr!
Risiken im agilen Umfeld – das UTM-Backlog
SCRUM ist zwar nur ein agiler Ansatz unter vielen, mutierte inzwischen aber zu einer Art Marktführer.
Es fällt auf, dass neben allen Backlogs, User Stories und Velocity scheinbar kein Platz mehr für Risiken ist. Ein Risk Backlog ist unbekannt. Vielleicht ist Risk Backlog aber einfach auch zu old fashioned? Wie wär’s stattdessen mit einem „Uncertainty-That-Matters Backlog (UTM-Backlog – ganz der Tradition verpflichtet, für alles neue Namen zu finden)? Aber auch das sucht man vergebens. Also, wo sind all die Risiken geblieben? Einfach verschwunden?
These 1:
Der agile Ansatz per se reduziert massiv die Risiken. Richtig. Und falsch. Richtig ist, dass die Unsicherheit, ein Produkt zu entwickeln, das der Markt nicht braucht und das viel Geld kostet, bevor es der erste Kunde sieht (und dann nicht will), massiv reduziert wird. Durch richtig durchgeführte sowie permanente Kommunikation und Iteration ist es fast unmöglich, am Markt vorbei zu entwickeln. Aber die Unsicherheit, ein falsches Produkt zu entwickeln, ist ja nur ein Aspekt. Risiken sind Unsicherheiten auf Ziele. In einem agilen Projekt, Release und/oder Sprint gibt es Ziele, also muss es dort auch Risiken geben.
These 2:
Das Impediment Backlog ist praktiziertes Risikomanagement. Falsch. Das Impediment Backlog ist dafür da, dem Team den Rücken frei zu halten und Hindernisse aus dem Weg zu räumen. Impediments sind eher Issues, Themen, Dinge, die es zu klären und zu beseitigen gilt. Es gibt mit Sicherheit Impediment Backlogs, in denen sich auch echte Risiken finden. Dann liegt das aber nicht an der Methode, sondern an der Kompetenz des Prozessbegleiters. Wir kämpfen im klassischen Projektumfeld seit Jahren dafür, das Risikoregister ausschließlich für Risiken zu verwenden und dort keine Probleme zu verwalten. So gesehen ist der Impediment Backlog-Ansatz also wieder ein Schritt zurück.
These 3:
Die enge Zusammenarbeit in einem funktionierenden Team vermeidet Risiken. Falsch. Zunächst Klarstellung: Eine gute Zusammenarbeit im Team an einem Ort und ohne dauernde Störungen ist extrem förderlich für die Projektarbeit – ohne Frage. Aber Risikomanagement ist das nicht.
Ein Gedankenspiel: Wenn Risikomanagement etwas damit zu tun hat, z.B. im Falle von Bedrohungen künftigen Problemen präventiv den Wind aus den Segeln zu nehmen und andererseits im agilen Projektumfeld anscheinend kein aktives Risikomanagement stattfindet, dann müssten agile Projekte ja mit einer ganzen Reihe von Probleme zu kämpfen haben. Das wäre der logische Schluss. Ist das so?
Allgemeine Wahrnehmung:
In der allgemeinen Wahrnehmung überstrahlt die oben genannte These 1 die komplette Diskussion, dass die Risiken einer Produkteinführung am Markt vorbei tatsächlich massiv minimiert werden.
Denn es gibt viele agile Ruinen und Misserfolge. Scheinagilität und doppelte Arbeit. Never ending stories, weil der Product Owner seinen Pflichten nicht nachkommt. Investitionsruinen vor dem Hintergrund der neu angeschafften Kanbantafel. Missinterpretation der gesamten Methode. Falsches Leistungsverständnis im Management. Glaube an Wunder und nicht zuletzt der unausrottbare Blödsinn, dass in agilen Projekten nicht dokumentiert werden muss.
Probleme lösen:
Es ist absolut nicht so, dass durch Agilität das Ende aller Projektprobleme dämmert. Agil ist en vogue und wer im agilen Umfeld scheitert, sucht vielleicht den Fehler zuerst bei sich – es scheint ja bei so vielen so gut zu klappen.
In der Tat würde uns ein UTM-Backlog helfen, die Macht des Risikomanagements zu entfalten und an vielen Baustellen Linderung zu spenden. Im Sprint bräuchte der SCRUM-Master nicht viel, um auch die segensreiche Wirkung von Risikomanagement zu erfahren. Der Product Owner sollte nicht nur sein Backlog im Auge behalten, sondern auch die Bedrohungen und Chancen dieser Zielebene. Und dem Management muss klar sein, dass es die Organisation in ein Kulturchaos stürzt, wenn eine stark hierarchische Struktur plötzlich ganz anders arbeiten soll.
Fazit:
Nennen Sie es, wie Sie wollen. Gerne auch UTM-Backlog. Messen Sie die Auswirkung problemlos in risk points. Spielen Sie mit dem Team lustiges risk poker, um Eintrittswahrscheinlichkeiten zu bestimmen. Betrachten Sie bewundernd Ihre risk exposure im risk burndown. Wunderbar. Und letztlich völlig egal, wie Sie das Kind nennen: Aber lassen Sie unbedingt auch im agilen Projekt die segensreiche Entfaltung von Risikomanagement auf Ihre Ziele zu. Im Guten wie im Schlechten.
Letzte Aktualisierung: 11. Februar 2022 / Copyright Gita GmbH / PMI, PMP und PMI-ACP sind eingetragene Warenzeichen des Project Management Institute, PMI (www.pmi.org) / WTIN: M1029
Wir verwenden Cookies, um unsere Website und unseren Service zu optimieren.
Funktional
Immer aktiv
Der Zugriff oder die technische Speicherung ist unbedingt für den rechtmäßigen Zweck erforderlich, um die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Abonnenten oder Nutzer ausdrücklich angefordert wurde, oder für den alleinigen Zweck der Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Voreinstellungen erforderlich, die nicht vom Abonnenten oder Nutzer beantragt wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Aufforderung, die freiwillige Zustimmung Ihres Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht zu Ihrer Identifizierung verwendet werden.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.