Perspektivenwechsel

Der agile Festpreis

In Schulungen werde ich immer wieder gefragt, ob agile Softwareprojekte Verträge nach Aufwand verlangen, oder ob auch Festpreisverträge möglich sind. Stand der Kunst in der agilen Community ist, dass Festpreisprojekte durchaus agil durchgeführt werden können.

Bei Bernd Oestereich heißt das Verfahren „Agiler Festpreis“ [1]. Jeff Sutherland spricht in Anlehnung an einen alten Dire-Straits-Song von „Money for Nothing, Change for Free“ [2], und wir nennen es schlicht „Anforderungstausch“ siehe [3]. Wahrscheinlich gibt es noch unzählige weitere Namen dafür, und wahrscheinlich glaubt jeder, er habe sich das zuerst ausgedacht.

Im Grunde läuft es aber immer auf dasselbe hinaus: Der Anbieter weist in seinem Angebot je Anforderung einen Einzelpreis aus (in Euro, Dollar oder auch Story Points). Der Gesamtpreis ergibt sich dann aus der Summierung der Einzelpositionen. Der Auftraggeber priorisiert die Anforderungen und gibt dem Anbieter damit die Reihenfolge der Abarbeitung vor. Der Anbieter entwickelt entlang dieser Priorisierung und präsentiert den jeweiligen Systemstand regelmäßig im Iterationsreview. Möchte der Auftraggeber während des Projekts die Prioritäten der offenen Anforderungen ändern, kann er das. Fällt ihm eine neue Anforderung ein, kann er sie entwickeln lassen, wenn er auf eine gleich teure Anforderung verzichtet, die noch nicht implementiert ist („Change for Free“). Und stellt der Auftraggeber fest, dass er eine beauftragte, aber nicht realisierte Anforderung doch nicht benötigt, kann er sie gegen Stornogebühr ersatzlos streichen („Money for Nothing“). Mit diesem Modell kann man Iterationsplanung und Iterationsreview auch bei Festpreisprojekten einen Sinn geben, und der Auftraggeber wird deutlich flexibler. Das Modell folgt der vierten Wertaussage des agilen Manifests: „Responding to change over following a plan“ [4]. Wir können also Festpreisprojekte agil(er) durchführen.

Perspektivenwechsel

Aber sollten wir das auch tun? Auch mit dem beschriebenen Modell bleiben Festpreisprojekte strukturell problematisch: Es wird viel Zeit in die detaillierte Spezifikation der Anforderungen investiert. Je stärker vom Anforderungstausch während des Projekts Gebrauch gemacht wird, desto mehr dieser Spezifikationsaufwände waren schlichtweg für die Mülltonne.

Der Auftraggeber hat immer noch den Anreiz, in die vereinbarten Anforderungen möglichst viel hinein zu interpretieren – er bekommt dann einfach mehr für sein Geld. In diesem Sinne hat der Auftraggeber auch einen Anreiz, die Systemstruktur und damit die Wartbarkeit des Systems zu opfern, wenn er das System dadurch schneller und billiger fertigstellen kann.

Der Anbieter hat immer noch den Anreiz, die vereinbarten Anforderungen möglichst billig umzusetzen – er hat dann einen höheren Gewinn. Dies führt dazu, dass der Anbieter sich mit Verbesserungsvorschlägen während des Projekts zurückhält. Der Auftraggeber wird ohnehin versuchen, diese Verbesserungen umsonst zu bekommen („Wo ist denn da der Verbesserungsvorschlag? Das ist doch selbstverständlich, dass das Bestandteil des Lastenhefts ist!“) Stattdessen ist es leider gängige Praxis, nur genau die Anforderungen abzuarbeiten, die das Lastenheft vorgibt und dann hinterher darauf zu warten, dass die notwendigen Change Requests beauftragt (und zusätzlich bezahlt) werden.

So sieht die Praxis bei Festpreisen leider häufig aus: Nach dem "eigentlichen" Projekt warten teure Change Requests

Der Anforderungstausch klebt ein Pflaster auf den Ausschlag, den der Festpreisvertrag verursacht. Dadurch verschwindet das eigentliche Problem aber nicht. Es wird nur schlechter sichtbar, und dadurch verringert sich die Chance, dass es beseitigt wird. Manchmal muss man das Problem absichtlich schlimmer machen, um es genau erkennen und beseitigen zu können.

Sollten wir also in Festpreisverträgen auf das Pflaster „Anforderungstausch“ verzichten und uns vertragskonform verhalten? Dann bekäme der Kunde genau das, was er bestellt hat – egal, ob das für ihn Geschwäftswert generiert oder nicht. Und wenn dann der obligatorische Ärger kommt („Das System kann man ja gar nicht benutzen!“) bringen wir dem Kunden bei, dass es bessere Vertragsmodelle gibt. Wir geben ihm die Chance, zu lernen und sich zu verbessern. Wäre das nicht viel besser, als ihn in Watte zu packen und glauben zu machen, er hätte ein sinnvolles Vertragsmodell? Das ist aus ethischer Sicht alles vollkommen unkritisch, wenn wir dem Kunden neben dem Festpreisangebot die Realisierung nach Aufwand angeboten und vorher bereits darauf hingewiesen haben, dass dieses Vertragsmodell zu besseren Systemen führt.

Letztlich läuft es darauf hinaus, sich zwischen den Alternativen „Love it, change it, leave it“ zu entscheiden, die uns die Organisationspsychologie vorgibt: Wir können den Festpreis mit den oben beschriebenen Modellen „an-agilisieren“ und uns letztlich mit der Situation arrangieren. Dann dürfen wir uns aber auch nicht beschweren – „Love it“. Oder wir versuchen, etwas zu verändern – „Change It“. Und dann ist es möglicherweise schlauer, die Nachteile des Festpreises sehr sichtbar zu machen.

Und nicht zuletzt gibt es noch die Option „Leave it“. Wenn „Love it“ und „Change it“ keine gangbaren Varianten sind, besteht immer noch die Möglichkeit, sich nach anderen Kunden umzusehen, die alternativen Vertragsmodellen gegenüber aufgeschlossener sind. Wenn wir allerdings der Meinung sind, dass sich die Kunden ändern können, sollten wir sie dabei unterstützen („Change it“). Und dabei hilft es auf jeden Fall, wenn wir neben den klassischen Vertragsmodellen Festpreis und Aufwand noch weitere Vertragsmodelle kennen. Zuerst gibt es einige Mischmodelle zwischen Festpreis und Aufwand. Bei Proviant und Prämie zahlt der Auftraggeber beispielsweise einen gerade mal kostendeckenden Tagessatz nach Aufwand. Wenn ein vorher festgelegtes Ziel erreicht wird, erhält der Auftragnehmer eine Prämie, die dann letztlich seinen Gewinn definiert. Der Auftragnehmer hat ein Interesse daran, das Ziel schnell zu erreichen. Dann ist sein Gewinn am größten. Gleichzeitig ist sein Überleben gesichert, auch wenn das Ziel gar nicht oder sehr spät erreicht wird. Oder man geht noch einen Schritt weiter: Die bisher diskutierten Vertragsmodelle sind alle kostenorientiert. Der Auftragnehmer maximiert seinen Gewinn, indem er seine Entwicklungskosten minimiert. Wieviel Gewinne der Auftraggeber mit der Software macht, wirkt sich nicht auf die Finanzen des Auftragnehmers aus. Es gibt aber auch wertorientierte Vertragsformen. So könnte die Prämie im Proviant-und-Prämie-Modell ersetzt werden durch eine Gewinnbeteiligung. Dann hat der Auftragnehmer einen großen Anreiz, bei der Gewinnmaximierung des Auftraggebers mitzuwirken und sich z. B. aktiv in die Anforderungsdefinition einzubringen.

Ich will hier nicht über den Festpreis richten. Wenn das Modell für Auftraggeber und Auftragnehmer gut funktioniert, muss man daran nichts ändern. Wenn man aber mit dem Modell unzufrieden ist, sollte man nicht jammern, sondern etwas unternehmen.

 

Stefan Roock ist Senior IT-Berater bei der it-agile GmbH in Hamburg. Er verfügt über mehrjährige Erfahrung aus agilen Softwareprojekten (Scrum. eXtreme Programming, Feature-driven Development) als Coach, Trainer, Projektleiter und Entwickler. Darüber hinaus hat er zahlreiche Artikel und Tagungsbeiträge über agile Softwareentwicklung verfasst und ist Autor der Bücher „Software entwickeln mit eXtreme Programming“ und „Refactorings in großen Softwareprojekten“.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.