Scrum und Festpreisverträge

Wie von Alexander Maisch schon im Artikel über den Nokiatest erwähnt gibt es bei InterFace in loser Regelmäßigkeit alle 2 Wochen ein Treffen aller am Thema Scrum interessierten Kollegen: Die Scrum-Sprechstunde.

Eines der Themen, welches in letzter Zeit hier immer wieder mal Gegenstand der Diskussion war, ist das Thema Scrum und Festpreisverträge.

Bevor wir hier jedoch eine konkrete Empfehlung abgeben, wie man diese zwei scheinbaren Gegensätze zusammenbringen kann, möchten wir jedoch die Gelegenheit nutzen, etwas zu Festpreisverträgen an sich zu schreiben.

Festpreisverträge sind etwas, was in den letzten Jahren immer mehr üblich wurde, und in manchen Bereichen mittlerweile eher die Regel als die Ausnahme sind. Doch warum ist das so?

Unserer Ansicht nach liegt der Grund hier vor allem im Wunsch des Auftraggebers, das mit dem Projekt verbundene Risiko vermeintlich auf den Auftragnehmer zu übertragen.

Die Nachfrage nach einem Festpreisprojekt ist daher auch immer ein Stück weit mit der unterschwelligen Aussage verbunden „eigentlich denken wir, das Projekt scheitert eh, deswegen sichern wir uns lieber schon mal dagegen ab“. Ein ideales Softwareprojekt sollte daher immer mit einem auf Stundensätzen basierenden Vertrag abgewickelt werden, da das bereits im Vorfeld ein größeres Vertrauen an den Auftragnehmer signalisiert und so eine gemeinsame Vertrauensbasis für eine erfolgreiche Projektabwicklung geschaffen wird.

Ein solches Idealbild existiert in der Realität jedoch leider nicht immer. Früher oder später wird wohl jede Organisation, egal ob sie nun mit Scrum arbeitet oder nicht, mit Festpreisprojekten konfrontiert werden. Es existieren jedoch verschiedene Möglichkeiten, mit dieser Situation umzugehen. Wir haben eine Reihe dieser Möglichkeiten an dieser Stelle mal zusammengefasst:

Bei Festpreisprojekten wird vom Kunden üblicherweise ja ein „Über-den-Zaun“-Vorgehen erwartet (d.h., man wirft eine Spezifikation über den bildlichen Zaun und hofft, dass das erwartete Produkt zurückgeworfen wird).

Bei agilen Methoden ist das jedoch ein wenig anders: Hier wird auf die konstante Mitarbeit des Kunden während des gesamten Projektverlaufs gesetzt. Um hierfür einen Anreiz zu schaffen könnte man einen Festpreisvertrag mit ein paar zusätzlichen Modifikationen jedoch mit etwas mehr Agilität versehen (siehe auch das Scrum-FAQ von Ken Schwaber:

• Jede Anforderung, die noch nicht bearbeitet wurde, darf vom Auftraggeber jederzeit durch eine andere Anforderung von gleichem Wert ersetzt werden (auch eine Neue!).
• Alle Anforderungen, die noch nicht bearbeitet wurden, dürfen vom Auftraggeber jederzeit umpriorisiert werden.
• Der Kunde kann die vorzeitige Auslieferung eines geplanten Software-Inkrements verlangen. Sollten hierbei jedoch zusätzliche Kosten anfallen, so werden diese gesondert in Rechnung gestellt.
• Sollte der Kunde mit dem Produkt bereits zufrieden sein, bevor alle Anforderungen abgearbeitet wurden, so wird ihm die Möglichkeit eingeräumt, das Projekt schon zu einem früheren Zeitpunkt zu beenden. Es wird dann zwar eine (vorher vereinbarte) Konventionalstrafe fällig, diese fällt jedoch nicht allzu hoch aus.

Diese (auf den ersten Blick unscheinbaren) Änderungen verbessern die Situation des Kunden in einigen Punkten wesentlich.

Schon die erste Änderung bringt einen riesen Vorteil: Da es hier erlaubt ist, bisherige Anforderungen auch durch komplett Neue zu ersetzen eliminiert man auch die bisherige Praxis mit nachträglichen Change Requests (denn gerade damit können Auftragnehmer bisher gutes Geld verdienen). Übrigens leistet man so auch einen wertvollen Beitrag gegen die heutzutage immer mehr grassierende „Featuritis“: Da bei traditionellen Festpreisverträgen nachträgliche Änderungen immer zusätzliches Geld kosten, werden zu Beginn oft alle Eventualitäten, und seien sie auch noch so unwahrscheinlich, mit Anforderungen abgedeckt. Das Resultat ist dann oftmals ein Produkt mit überbordender, aber selten gebrauchter oder zum Zeitpunkt der Fertigstellung sogar schon überholter Funktionalität.

Trägt man jedoch, wie hier, dem Umstand Rechnung, dass Anforderungen zu Beginn oft noch unklar sind, und sich im Laufe der Zeit zudem noch öfters mal ändern können, so ist die Wahrscheinlichkeit, ein zielgerichtet auf die Kundenwünsche entwickeltes Produkt zu erhalten wesentlich höher, auch wenn am Ende etwas ganz anderes herauskommt, als am Anfang gedacht war.

Dies wird noch weiter unterstützt durch die Möglichkeit, ein Projekt vorzeitig abzubrechen. Wenn dem Auftraggeber der erreichte Stand gut genug ist (bzw. das Budget plötzlich gekürzt wird) kann man das Projekt stoppen und trotzdem eine brauchbare Software-Lösung bekommen – und das ohne alle ursprünglich gedachten Features implementiert haben zu müssen.

Die dritte Klausel ermöglicht das schrittweise Ausrollen eines IT-Systems (also kein „Big-Bang“), was die Risiken des Projekts erheblich reduziert (wenn man die Anzahl an gescheiterten IT-Projekten bedenkt) und interessante Perspektiven eröffnet: Wenn das neue System schrittweise jeden Monat eingeführt wird, muss man nicht alle Mitarbeiter in teure Schulungen schicken: Sie können sich schrittweise mit dem neuen System vertraut machen.

Soweit die graue Theorie. Doch wie sieht es in der Praxis aus? Schlecht! Warum dies?

Mehr dazu im nächsten Artikel…

BFI