eine Betrachtung von Realoptionsansatz in Kombination mit agiler Softwareentwicklung …
Angesichts der stark zunehmenden Bedeutung von agilen Vorgehensmodellen in Projekten – vor allem in der IT – ist es interessant zu hinterfragen, wie sich der Realoptionsansatz mit der Agilität verträgt bzw. welche Wechselwirkungen sich hier ergeben. Hierfür wird Scrum als Paradigma herangezogen.
Als Ausgangsbasis wird ein realistischer Business Case für ein IT-Projekt vorausgesetzt!
Im Wasserfallmodell ergab sich bei erfolgreichen Projekten der meiste Aufwand für Planung und Analyse. In Scrum geht man davon aus, dass ein gewisses Budget vorhanden ist, das mittels Abarbeitung von sogenannten User Stories verbraucht wird. Für ein erfolgreiches Projekt sind daher erforderlich:
- Budget
- User Stories im Zustand „Definition of Ready“
- Priorisierung der User Stories nach der Value Proposition jeder einzelnen User Story
Aber was bedeutet das im Kontext von Scrum? Wenn man das Setting Realoption vs Scrum User Story strikt durchzieht, würden sich daraus folgende Konsequenzen ergeben:
- für jede einzelne Story müßte man den Expanded NPV (=Expanded Net Present Value) errechnen
- der Entscheidungsbaum würde groß und unübersichtlich werden
Um das Problem zu umgehen sind mehrere Ansätze möglich. Zwei davon seien exemplarisch hervorgehoben:
- Bewertung des Gesamtbudget und dem zu erwartenden Funktionsumfang und den sich daraus ergebenden Handlungsspielräumen. Das würde aber erfordern, dass man schon im Vorfeld weiß, welche Funktionen am Ende des Budgets vorhanden sein werden. Das widerspricht allerdings der Scrum-Methodik.
- Gruppierung der User Stories nach bestimmten Kriterien – hier bietet sich der Wert einer User Story für das Unternehmen an. Dieser Ansatz bedingt zumindest eine NPV-Abschätzung der einzelnen Stories, um eine entsprechende Gruppierung zu ermöglichen.
Die Mathematik dahinter ließe sich recht einfach automatisieren, wäre aber schon alleine bei kleineren Projekten mit einigen wenigen Monaten Laufzeit aufgrund der Anzahl der User Stories ziemlich schnell unübersichtlich. Der Aufwand dafür wäre durchaus erheblich. Gleiches gilt für den daraus resultierenden Entscheidungsbaum.
Aufbauend auf Scrum wäre aber noch eine weitere Möglichkeit denkbar.
Jede User Story wird mittels Story Points geschätzt, was einen ungefähren Richtwert für den Aufwand ergibt. Aufgrund der Priorisierung der User Stories kann man eine grobe Gruppeneinteilung vornehmen. Aus dieser Gruppierung, den Story Points und der Velocity des/der Scrum-Team(s) läßt sich dann einerseits eine zeitliche Planung sowie auch eine Realoptionsbewertung ableiten. Teilt man die User Stories vorab noch in Themenbereiche innerhalb des Projekts ein, kann man dann zB in einem Softwareentwicklungsprojekt recht schnell feststellen, welches funktionale Paket welchen Expanded NPV hat.
Folge daraus wäre ein wesentlich überschaubareres Konstrukt aus Expanded NPVs und ein Entscheidungsbaum, der überschaubar und auch beherrschbar bleibt.
Links