Agile Softwareprojekte werden am besten nach Aufwand abgerechnet. Das ist eine Binsenweisheit. Aber warum ist das eigentlich so? Und: gibt es so etwas wie den agilen Festpreis? Und was bedeutet das für das Projekt?
Was ist eigentlich so schlimm an Festpreisen? Schließlich bieten sie Planungssicherheit für beide Seiten, oder etwa nicht?
Ein Festpreis basiert auf der Annahme, dass eine ordentliche Planung alle Unwägbarkeiten berücksichtigen kann. Dies ist in folgenden Aspekten problematisch:
1. Umfang: Weil der Auftraggeber weiß, dass fachliche Nachforderungen schwierig werden, wird alles ins Pflichtenheft geschrieben, was evtl. Relevanz bekommen könnte. Dies ist oft mehr, als in einem ersten Wurf sinnvoll wäre, schließlich lehrt uns der Standard Chaos Report, dass bis zu zwei Drittel aller Features in einem Softwareprodukt wenig oder nie benutzt werden.
2. Aufwand: Auch der Auftragnehmer weiß natürlich, dass er nur einen Wurf für die Aufwandsschätzung hat. Von daher werden Puffer mit einkalkuliert, die in aller Regel auch aufgebraucht werden, da Entwickler nie eher fertig werden als ursprünglich kalkuliert.
3. Kosten: Spätestens der Projektverantwortliche wird am Ende einen Risikoaufschlag auf den Festpreis addieren, 20%-25% sind hier ein üblicher Wert.
Letztendlich folgt daraus, dass Festpreisprojekte größer und teurer werden, als es eigentlich sein müsste. Das Schlimmste ist allerdings, dass Fronten zwischen Auftraggeber und Auftragnehmer aufgebaut werden und Gelerntes so gut wie nie in das Projekt einfließen wird, da der Umfang ja feststeht. Ein monströses Change Management ist dann oft die Folge, das gute und sinnvolle Verbesserungen aber eher verhindert als fördert.
Aufwandsprojekte ticken anders. Hier gibt es keine Risikoaufschläge und keine Aufwandspuffer. Und wenn die Anforderungsanalyse und Projektsteuerung auch noch agil verläuft, gibt es auch keine Probleme mit dem Umfang, da das Wichtigste immer zuerst umgesetzt wird und vor jedem Sprint die Entscheidung getroffen werden kann und muss, ob der Geschäftswert, der im kommenden Sprint erwirtschaftet wird, die Kosten wirklich rechtfertigt, denn sonst sollte man das Projekt beenden.
Klingt toll, oder? Aber warum sträuben sich dann so viele Kunden, nach Aufwand abzurechnen? Die Zauberworte heißen Vertrauen und Verantwortung. Zum einen glaubt der Auftraggeber oftmals, dass sich der Dienstleister dauerhaft einrichtet und die Kosten ins Unermessliche steigen, da der Kunde technisch nicht beurteilen kann, ob der Entwickler mit Volldampf am Problem arbeitet. Zum anderen habe ich schon viele Auftraggeber erlebt, die das Projekt einfach nur abgeben, ohne sich wirklich darum kümmern zu wollen. Das Risiko des Projekterfolgs wird vollends auf den Dienstleister abgeschoben. Was natürlich überhaupt nicht dazu passt, dass man eigentlich kein Vertrauen zu ihm hat. Wie soll das gehen?
Dabei ist es so einfach: Agiles Projektmanagement minimiert das Risiko so weit, dass der Auftraggeber es gern selbst tragen kann.
Ein guter Product Owner hat die komplette fachliche Steuerung des Projekts allein in seiner Hand. Und selbst der Aufwand kann kontrolliert werden. Die Schätzungen basieren auf Komplexität und nicht auf Zeit und da kann der Product Owner sehr wohl mitreden. Und weil der PO einen guten Teil seiner Zeit mit dem Team verbringen sollte, bekommt er recht schnell ein gutes Gefühl dafür, ob das Team ordentlich „performed“ oder nicht.
Brauchen wir also überhaupt so was wie agile Festpreise? Und was ist das überhaupt?
Ein agiler Festpreis ist eindeutig eine Krücke. Es ist der Versuch, einem Kunden, der eigentlich Aufträge nur nach Festpreis vergibt, das agile Vorgehen doch schmackhaft zu machen. Es gibt verschiedenste Varianten von agilen Festpreisen, einige sind bei Alistair Cockburn nachzuschlagen. Eine Variante, die wir kürzlich gewählt haben, ist ein Aufwandsprojekt, dem eine klassische Schätzung vorausging und für das deshalb ein mutmaßlicher Endwert verkündet wurde. Mit einer Nebenklausel, dass der Auftraggeber nach jedem Sprint über das weitere Vorgehen entscheiden kann.
Rechtlich alles sauber, aber in der konkreten Durchführung dann doch schwierig. Natürlich wurde intern ein Budget eingestellt und natürlich war der Scrum-Ansatz so erfolgreich, dass viele tolle Ideen in den Sprint-Reviews entwickelt wurden, die das Projekt viel besser machen würden. Nur eben leider auch teurer. Und hier haben wir den Salat. Der agile Festpreis ist ein Deckel auf einem vor Ideen überkochenden Topf. Und das kann problematisch werden, wenn man hier nicht sehr genau steuert. Letztendlich behindert es also ein richtig agiles Vorgehen. Und diese Frage muss sich der Kunde dann gefallen lassen: Willst du ein Projekt, bei dem du die vollständige Kontrolle über Inhalt und Fortschritt hast, aber Gefahr läufst, dass es möglicherweise teurer wird als geplant (wenn auch besser)? Oder willst du ein Projekt, das sicher in den Budgetgrenzen bleibt, bei dem aber alle tollen Ideen, die unterwegs geboren werden, auf der Strecke bleiben?
So gesehen ist ein agiler Festpreis vielleicht doch nicht so attraktiv, wie er auf den ersten Blick erscheint.
