UTM-Backlog oder was?

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?

 

 

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.

 

 

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.

 

 

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?

 

 

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.

 

 

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.

 

 

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.

 

__________________________________________________________________________________