Risiken in agilen Projekten

Kürzlich haben wir über einen Blogpost diskutiert, in dem der Autor behauptet, man solle lieber auf klassisches Projektmanagement setzen wenn man nicht das Risiko agiler Methoden eingehen möchte. Hierzu ein paar Gedanken und Erfahrungen aus unserer täglichen Projektarbeit.


Timing & Budget

Diese zwei Risiken sind die vermeintlich “einfachsten”, denn sie können als schwarz/weiß verstanden werden. D.h. Entweder das Projekt kostet mehr oder dauer länger als geplant oder – was seltener der Fall ist – das Projekt ist kostengünstiger und/oder schneller. Weniger kann im klassischen Budgeting Prozess natürlich auch ein Problem sein, lässt sich aber noch am einfachsten lösen.

Neben Zeit und Geld gibt es noch einen weiteren, ganz entscheidenden Parameter bei IT-Projekten – den sog. Scope. Darunter versteht man den Umfang des Projektes bzw. das, was am Ende des Tages an Funktionalität abgeliefert wird. Timing und Budget einzuhalten ist eine Sache – ihre Beurteilung ist nur relativ einfach, deshalb wird es gerne als Maßstab herangezogen. Was aber, wenn Time und Budget stimmen, ich als Auftraggeber aber nicht das “richtige” bekomme?


Scope

Ob das, was umgesetzt wurde, das Richtige ist, in der richtigen Qualität und Menge, ist deutlich schwieriger zu beurteilen, enthält zugleich aber auch das höchste Risiko.

Woran mache ich das fest? Hier liegt auch wohl der größte Unterschied zwischen klassisch und agil. Wasserfall bedeutet, das Geplante umzusetzen. Es zieht nicht in Betracht, dass das Geplante falsch sein könnte. Agil ist deshalb so stark, weil die Grundannahme vernünftiger ist: Man geht davon aus, dass sich vieles ändern wird. Also plant man auf Sicht.

Als „Änderung“ wird immer unsere schnelllebige Welt und insbesondere die IT angeführt – dabei ist das bei weitem nicht der größte Faktor.

Viel wichtiger ist: Was ändert sich, wenn ich die Software zum ersten Mal sehe und bediene? Was sagt die Zielgruppe? Ist danach noch alles so wie ursprünglich gedacht? Fallen mir dann neue, wichtigere Sachen ein? Und haben sich meine Annahmen bewahrheitet?

Je früher ich diese Fragen beantworte, umso besser für das Ergebnis. Umso mehr ändert sich aber am ursprünglichen Plan.

 

 

Scope lässt sich erst abschließend beurteilen, wenn man die Zielgruppe auf die Software loslässt. Es gibt praktisch keinen anderen Weg. Je früher man dies tut, umso mehr lässt sich das Risiko eingrenzen. Wird das Projekt erst „komplett fertig gestellt“ (was auch immer das Wort fertig bedeutet), hat man jede Chance vertan, auf Fehlentwicklungen zu reagieren.

Die Zielgruppe ist leider oft der Vorgesetzte. Man hat etwas vereinbart und wird daran gemessen, ob das geliefert wird. Unsere Empfehlung: Beziehen Sie insbesondere auch Vorgesetzte möglichst früh mit ein, das mindert das Risiko.

Scope lässt sich nicht einfach beurteilen – das größte Risiko besteht wohl darin, das falsche zu entwickeln; etwas, das die Zielgruppe nicht verwendet. Scope entscheidet aber letztlich über Time und Budget – und von beidem will man so wenig wie möglich verwenden bzw. eine möglichst effiziente Abwicklung.

Doch selbst, wenn man die vermeintlich optimalste Software der Welt entwickelt, trägt man Risiken mit sich herum:


Technik

Die Frage, ob die Technik hinter dem System Risiken birgt, zeigt sich leider oft erst sehr spät. Sicherheitslücken werden oft nicht einmal erkannt, wenn sie schon genutzt worden sind. Die zugrunde liegenden “Basis-Software” sollte erweiterbar, skalierbar und wartbar sein, auch die Hardware spielt eine wichtige Rolle. Die Qualität der Entwicklungsarbeit d.h. das Customizing an die jeweiligen, individuellen Bedürfnisse ist dabei ein entscheidendes Kriterium.

Aber selbst wenn die Technik in Ordnung ist, bleibt ein Restrisiko:


Operations

Der langfristige Betrieb der Software kann zu kostspielig sein. Kleine Änderungen können zu viel Geld kosten. Für alles muss der Dienstleister herangezogen werden. Und das mittlerweile gewachsene System ist im Worst-Case kaum mehr administrierbar.

Im Fall einer Website oder E-Commerce Anwendung muss man das System aus vielerlei Aspekten betrachten: Technik, Marketing, Suchmaschinen, Content, Daten, Drittsysteme usw. Hier bleibt die Frage, ob man diesen Bestandteilen sinnvoll nachkommen kann. Daran bemisst sich das Risiko, ob sich das Projekt langfristig sinnvoll betreiben lässt.


Risikobewertung

Sowohl klassisches Projektvorgehen z.B. nach dem Wasserfallmodell als auch agiles Projektmanagement haben ihre Daseinsberechtigung. Eine solide und exakte Upfront-Projektplanung ist dann sinnvoll, wenn Änderungen extrem teuer oder unwahrscheinlich sind; typischerweise in Produktionsumgebungen. Aber selbst hier könnte man mit agilen Methoden dagegen halten und wie folgt argumentieren: Wann sind Änderungen extrem teuer und v.a. warum? Gerade, wenn ein Fehlschlag extrem teuer ist, ist ein iteratives Entwickeln der Lösung mit vielfachen Realitäts-Feedbacks sinnvoll. So wurde ein Mondfahrzeug beispielsweise nicht rein auf dem Zeichenbrett entwickelt, es wird bzw. wurde in der Wüste von Nevada vorab getestet.

Sind Änderungen wahrscheinlich und zudem relativ “schmerzfrei” umsetzbar, ist das Risiko mit agilen Methoden in aller Regel deutlich geringer.

Voraussetzung für erfolgreiche, agile Projekte ist allerdings immer entsprechende Erfahrung beim Dienstleister. Ist dies nicht gegeben und wird agil lediglich als Buzzword im Marketing und/oder Vertrieb verwendet, ist das Risiko jedoch auch entsprechend hoch.

Nenne ich mein Projektmanagement „agil“, weil ich Sprints durchführe und Daily Standups abhalte? Setze ich ein Lastenheft „agil“ um, ohne es zu hinterfragen und die Ergebnisse zu bewerten? Anders ausgedrückt: Ist agil nur ein Mittel zum Zweck oder aus Überzeugung und Erfahrung der beste Weg?

Agil muss für uns folgendes bedeuten:

  • wirklich fertige Software am Ende jedes Sprints zu haben
  • diese so früh wie möglich realistisch einzusetzen (release often & early)
  • Daraufhin die Software und den Plan wenn nötig anzupassen
  • Reduktion aufs Wesentliche ohne zwingend erforderliches Chichi (Minimal Viable Product)

Dies können meist nur eingespielte und technisch versierte Teams leisten. Damit lässt sich dann allerdings auch Scope, Time und Budget kontrollieren und das Risiko minimieren. In der Konsequenz bedeutet dies, dass man hier auf den entsprechenden Dienstleister und seine Erfahrung und sein Know How angewiesen ist. Dabei ist es unerheblich, ob und wie Agilität kommuniziert wird. Entscheidend ist das, was am Ende geliefert wird!

Frühe und häufige Änderungen am Plan führen im Normalfall auch zu flexiblerer, technisch besserer Software. Fixe Pläne fordern weder Software noch die Entwickler, sie fördern monolithische komplexe Strukturen und sind daher aus unserer Sicht nicht mehr zeitgemäß!

Und wie finden Sie nun heraus, ob ihr Dienstleister der richtige ist? Ganz einfach! Machen Sie auch die Dienstleisterauswahl agil. Lassen Sie dazu 2-3 Dienstleister ein erstes Teilprojekt im Rahmen von 1-2 Sprints umsetzen. Das Ergebnis ist entweder „working software“ oder hohes Risiko. Das ist viel aussagekräftiger als Vertragsverhandlungen und Bauchgefühle. Wenn der Dienstleister dann auch noch versucht, Ihnen Features und Ideen mit guten Argumenten auszureden, dann hat er entsprechende Komplexitäten höchstwahrscheinlich im Griff; er versucht, aufs Wesentliche zu reduzieren um Time und Budget optimal zu nutzen ohne Kompromisse bei der Qualität eingehen zu müssen.


Fazit

Im Grunde ist das vielzitierte „Eiserne Dreieck“ eine schlechte Analogie. Letzten Endes geht es um Scope – Budget und Timeline sind dem untergeordnet.

Stellen wir uns eine Wippe vor. Links ist Scope (hier kann man Qualität, Effizienz und alle Aspekte aufnehmen – nicht nur die Menge) und rechts das Budget, welches meist fix ist.

Die meisten Projekte werden so aufgezogen, dass kein Gleichgewicht zwischen Scope und Budget vorhanden sein soll – fast immer gibt es mehr Scope als Budget.

 


Wasserfall-Methoden machen folgendes: Sie versuchen das Gelenk der Wippe zu fixieren, so dass sie sich nicht mehr bewegen kann, egal was ich rechts und links mache.

Merke: Agile Methoden versuchen, den Scope zu Gunsten des Budgets zu optimieren!

Gleichgewicht ist nur als Ergebnis erstrebenswert – und wir tun das, indem wir einem “Budget-Gewicht” entsprechendes “Scope-Gewicht” eines nach dem anderen auflegen, die großen und wichtigen zuerst – und wenn noch “Luft” ist, kann man noch mehr auflegen.

 

 

 

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.