III Die Praxis.
Funktioniert nicht: Anhäufung von Stories
1.) In der Praxis habe ich Verträge gesehen, die diesem Schema auch entsprechen. Sie agieren eigentlich nach dem Schema, das für Change Request- Verfahren Anwendung findet. Häufig findet man Verträge, nach deren Inhalt der Unternehmer kostenlos Anforderungen des Kunden zur Realisierung eines Changes durchführen soll und der Aufwand durch die Marge kompensiert werden soll, die aus der Realisierung des Changes resultiert. So soll der Auftragnehmer dazu verpflichtet werden, im Rahmen eines Festpreises eine Reihe von „Stories“/ Epics etc. zur prüfen und mit Preisen zu versehen und der Auftraggeber soll sich dann aussuchen können, welche der Epics tatsächlich in Sprints realisiert werden. Das Problem dieses Vertragstyps besteht darin, dass unklar ist, ob sich alle dann schließlich beauftragten Stories dann auch im Rahmen der Konsolidierungsphase systemisch miteinander vertragen. Die Planungsphase würde – insbesondere dann, wenn die Abnahme nicht nur auf dem Test- sondern auf dem Produktivsystem stattfinden soll, bedeuten, dass der Auftragnehmer ein erhebliches Risiko für die Phasen übernimmt, die sich erstens daraus ergeben, dass die jeweiligen Stories tatsächlich so genau formuliert sind, dass der Auftraggeber mit diesen arbeiten kann und zweitens aus den Unsicherheiten, die mit den nachfolgenden Phasen einhergehen – Systemintegration und Abnahme auf dem Produktivsystem. Wenn der Auftragnehmer einigermaßen besonnen ist, wird er dieses Risiko vernünftig einpreisen.
Am wichtigsten aber: Dieser Vertragstyp beseitigt überhaupt nicht die Schwachstellen, die die klassischen Projektmethodiken aufweisen. Ich habe hier immer wieder darauf hingewiesen, dass die agilen Vertragsmethodiken deshalb beliebt sind und immer beliebter werden, weil sie auf einer methodischen Basis zwei Probleme angehen: Erstens geben die agilen Modelle ein Verfahren vor, wie in einem reiterativen Zyklus beide Vertragsparteien ein immer besseres Verständnis über die fachlichen Anforderungen gewinnen können. Je häufiger Menschen miteinander über den fachlichen Soll-Zustand sprechen und desto häufiger sie über dieses Verständnis kommunizieren, desto besser werden am Ende die Ergebnisse sein. Der zweite Punkt betrifft die Dokumentationen, die einfach viel zu häufig zu lückenhaft oder vage sind und die allzu häufig schnell veralten. Die agilen Verfahren arbeiten mehr auf der Basis tatsächlich erlebbarer Prototypen, die häufig gegen UATs (User acceptance Tests) getestet werden können. Solche Verfahren sind geeignet, das Projektergebnis zu verbessern. Aber sie beinhalten immer eine „Agilität“ (in Wirklichkeit die Gefahr der Veränderung der fachlichen Anforderungen) was dann auch entweder eine Erhöhung des Preises nach sich ziehen sollte oder aber die Aussage des Auftraggebers, auf die Realisierung von bestimmten Funktionen verzichten zu wollen, damit das Projektbudget nicht überschritten wird.
Funktioniert: Rapid Prototyping
2.) Der zweite Vertragstyp, der tatsächlich funktioniert ist ein „rapid prototyping“, wobei aber die Anzahl der reiterativen Zyklen von vorne herein begrenzt wird. Hier findet eine Wiederholung des V- Models statt. Der Auftraggeber nimmt in Kauf, dass es nach Abschluss des letzten Punktes noch immer „offene Flanken“ hinsichtlich der fachlichen Anforderungen gibt. Das Model ist tatsächlich fair, weil dessen Ansatz ist, mit dem Ergebnis einer bestimmten Planungsphase zufrieden zu sein. Es setzt aber auf der Seite des Auftraggebers voraus, dass man auf Dinge verzichtet, die man vorher noch nicht kennt. Auch hier sei wieder an das „Modell des schwarzen Schwanes“ erinnert. Es ist besser, das vorhandene Budget dafür zu verwenden, dass bestimmte Module und Funktionalitäten wirklich funktionieren, als zu erwarten, dass „alles“, wie erhofft, umgesetzt wird. Auch im Verzicht kann eine Stärke liegen.
IV Fazit:
Einen „agilen Festpreis“ auf der Basis des Werkvertragsrechts sollte es nicht geben. Er führt nicht dazu, dass man die Vorteile der agilen Projektmethodiken für das Projekt fruchtbar machen kann. Dem Auftraggeber sei an diese Stelle geraten, eine Planungsphase auf der Basis des Dienstvertrags zu vollziehen, damit die erste Planungsphase begonnen werden kann. Erfahrungsgemäß wird der Auftragnehmer bestimmte fachliche Anforderungen ohne Schwierigkeiten verstehen und realisieren können, ohne dass man die agile Methodiken heranziehen muss. Daneben könnten jedoch bestimmte Anforderungen vielleicht noch nicht gut verstanden werden und können dann mittels einer agilen Methodik realisiert werden. Auf der Basis dieses Verständnisses kann der Auftragnehmer dann ein Angebot für einen Fixpreis für die fachlichen Anforderungen abgeben, die mittels klassischer Methodiken realisierbar sind und einen variablen Preis für die Punkte, die man mittels agiler Methodiken realisieren lassen will.
Der Gedanke aber, man könne die Risiken, die sich aus der eigenen Unkenntnis fachlicher Anforderungen ergeben mittels eines Festpreises auf den Auftragnehmer abwälzen, ist trügerisch.
