Agile Produktentwicklung und Festpreise – das geht

Kunden planen Budgets, Kunden haben Budgets und wünschen sich einen Festpreis. Auf die agile Entwicklung von Produkten muss deshalb niemand verzichten. Wie geht das zusammen oder geht das überhaupt zusammen? Wir haben fünf Punkte identifiziert, auf die es ankommt.

Jeder, der länger im Geschäft ist, kommt an diesen unerfreulichen Punkt in einem Projekt. Das Budget ist weg, das Produkt nicht fertig. Wenn es gut läuft, findet sich ein Topf, der die Lücke zur Fertigstellung stopft und das Produkt erblickt das Licht der Welt. Wenn es weniger gut läuft, dann wartet das Projektteam auf das nächste Jahr, das nächste Budget und nimmt die Arbeit wieder auf. Es kommt aber auch vor, dass es nicht weiter geht. Bis wieder Budget da ist, ist die Produktidee veraltet oder zumindest so weit weg von den aktuellen Bedürfnissen, dass es einen Neustart gibt.

Zu Zeiten von Wasserfallmethoden war das fast normal. Es lag in der Regel nicht am Budget, das war ja ordentlich geplant worden. Doch da die User zwischenzeitlich nichts zu sehen bekamen, war die (negative) Überraschung oft so groß, dass das Produkt nicht mehr zu retten war.
Deshalb wurden die agilen Methoden erfunden. Die Produktentwicklung sollte näher an die User rücken, die schwarzen Löcher, in denen die Budgets verschwinden, sollten kleiner werden. Doch wie geht das?

Wir haben aus unseren Erfahrungen fünf Punkte extrahiert, die uns dabei helfen, dass unsere Produkte das Licht der Welt tatsächlich erblicken:

• 50%-Regel: Wir verplanen initial nur 50% des Budgets, der Rest ist Puffer. Wie hoch der Prozentsatz sein muss, hängt vom Kunden, von den Stakeholdern und von der Produktidee ab. Er kann auch näher am tatsächlichen Budget liegen. Aber nicht bei einem ersten Projekt mit einem neuen Kunden.
• MVP ernst gemeint: Wir definieren gemeinsam mit dem Kunden, was ein MVP ist. Das klingt trivial, denn eigentlich gibt es dafür ja Definitionen, die leicht zu finden sind. Was wir damit meinen: Wir beantworten gemeinsam mit dem Kunden die Frage, welche kunden- und marktspezifischen Kriterien es gibt, die den MVP definieren.
• Konzeptionskreislauf durchbrechen: Wir starten früh mit der Entwicklung. Selbst wenn noch viele konzeptionelle Fragen offen sind und der Kunde sie mit Leidenschaft mit uns diskutiert. Selbst wenn wir wissen, dass wir etwas wegwerfen müssen, fangen wir an zu entwickeln. Denn es ist besser ein Stück Frontend nochmals zu schreiben, als dass das Produkt nicht live geht. Dahinter steckt eine ganz wesentliche Erkenntnis der agilen Entwicklung. Es geht nicht darum, dass sich mehr aus einem Budget rausholen lässt, wenn wir agil arbeiten. Es geht darum, dass die User das Produkt sehen und testen können, dass sie ihr Feedback geben können, was gut ist und wo Verbesserungspotenzial besteht.
• Engagement von Anfang an: Das ist aus unserer Sicht der schwierigste Punkt. Am Anfang klingen Ideen verheißungsvoll, es wird nicht so genau geguckt, wie sie sinnvoll umgesetzt werden können. Wenn es dann auf einen (imaginären) Release-Termin zugeht, kommt mehr Ernsthaftigkeit in die Betrachtung. Diesen Zeitpunkt der Ernsthaftigkeit ziehen wir vor. Wir geben deshalb dem Feedback von Anfang an viel Raum, fordern bewusst auch Kritik ein. So sind wir sicher, dass wir nicht in der Wasserfall-Falle landen („das habe ich mir eigentlich ganz anders vorgestellt“), sondern das Produkt von Anfang an genau und kritisch betrachtet wird.
• Erwartungsmanagement: Wir versprechen keinen Porsche, wenn das Budget für einen Golf ausgelegt ist, aber wir reden auch nicht mehr vom Porsche, wenn umrissen ist, was mit dem Budget möglich ist. Das heißt, wir sprechen nicht darüber, was nicht geht, sondern fokussieren auf das, was machbar ist.

Agil heißt weder chaotisch noch bedeutet es, dass es keine Planungssicherheit gibt. Vielmehr nimmt die Sicherheit in Projekten zu, in time, in scope und in budget zu bleiben.