
Agiler Festpreis Eine Alternative zu Stundensatz und Pauschale
Wann welches Abrechnungsmodell Sinn macht und warum wir für bestimmte Projekte den Agilen Festpreis nutzen
Die üblichen Modelle und ihre Trade-offs
Bei Black Bridge arbeiten wir je nach Projekt mit unterschiedlichen Modellen. Jedes hat seinen Platz. Aber für eine bestimmte Art von Projekten haben wir einen dritten Weg gefunden, der oft besser funktioniert.
Stundensatz: Flexibel, aber mit Risiko beim Auftraggeber
Beim Stundensatz-Modell bezahlt der Kunde unsere Zeit. Das funktioniert gut für:
- Laufende Betreuung: Wenn der Umfang schwer planbar ist
- Beratung und Reviews: Ad-hoc-Support, Architektur-Sparring
- Kleine Anpassungen: Wenn ein festes Paket Overhead wäre
Der Trade-off ist klar: Der Auftraggeber trägt das Budgetrisiko. Wenn etwas länger dauert als gedacht, zahlt er mehr. Das ist fair, solange beide Seiten das verstehen—und solange wir transparent kommunizieren, wenn sich Aufwände ändern.
Wir bieten Stundensatz-Projekte an und werden das auch weiterhin tun. Es ist das richtige Modell für bestimmte Situationen.
Klassischer Festpreis: Planbar, aber starr
Am anderen Ende steht der klassische Festpreis. Ein Projekt, ein Preis, fertig.
Das Problem: Damit das funktioniert, müssen Anforderungen glasklar sein. In der Realität—besonders bei Cloud- und Infrastruktur-Projekten—weiß man am Anfang selten alles. Man entdeckt Dinge während der Umsetzung. Prioritäten verschieben sich. Der Markt ändert sich.
Bei einem klassischen Festpreis führt das zu Konflikten. Jede Änderung wird zur Verhandlung. “Das war nicht im Scope.” Der Fokus verschiebt sich von der besten Lösung zur Vertragsauslegung.
Deshalb machen wir selten klassische Festpreise für größere Projekte. Nicht weil das Modell schlecht ist—sondern weil es für die Art von Projekten, die wir machen, oft nicht passt.
Der Agile Festpreis: Ein dritter Weg
Für Projekte, die zu groß für reinen Stundensatz sind, aber zu dynamisch für einen klassischen Festpreis, nutzen wir den Agilen Festpreis. Das Konzept stammt aus dem gleichnamigen Buch von Boris Gloger und André Häusling, und wir haben es für unsere Arbeit adaptiert.
Die Kernidee: Budget fix, Scope flexibel. Risiko geteilt.
Statt ein Gesamtprojekt pauschal zu bepreisen, arbeiten wir in Paketen. Jedes Paket hat einen festen Preis. Was in diesem Paket umgesetzt wird, entscheiden wir gemeinsam—basierend auf dem aktuellen Stand, nicht auf Annahmen von vor drei Monaten.
Wie der Preis entsteht
Im Kern bepreisen wir Komplexität, nicht Zeit. Wir arbeiten mit Story Points—eine Einheit, die den Aufwand und die Komplexität einer Aufgabe beschreibt. Zu Beginn einigen wir uns auf einen Preis pro Story Point.
Daraus ergibt sich der Rest: Budget geteilt durch Story-Point-Preis ergibt die Menge an Komplexität, die wir liefern. Das Backlog wird geschätzt, priorisiert, und beide Seiten wissen, was für das Budget realistisch ist.
Der entscheidende Unterschied: Der Kunde zahlt für gelöste Probleme, nicht für geleisteten Aufwand. Ob wir für eine Aufgabe zwei Stunden oder zwei Tage brauchen, ändert nichts am Preis—und damit auch nichts an der Motivation, effizient zu arbeiten.
Wie wir priorisieren
Value first. Was bringt dem Business den größten Impact? Das kommt zuerst.
Am Ende jeder Iteration schauen wir gemeinsam: Was hat sich verändert? Welche Prioritäten haben sich verschoben? Das Backlog wird neu sortiert—immer nach dem Prinzip, dass das Wichtigste als nächstes kommt.
Wie wir das umsetzen
Discovery-Phase (Festpreis)
Wir starten mit einer klaren Analyse. AWS-Account-Review, Architektur-Assessment, Kostenstruktur. Am Ende steht ein priorisiertes Backlog: Was sind die wichtigsten Themen? Was bringt den größten Hebel? Und eine erste Schätzung in Story Points, damit klar ist, was im Budget realistisch ist.
Iterative Pakete (Festpreis pro Paket)
Dann arbeiten wir in Iterationen. Typischerweise zwei bis vier Wochen pro Paket. Jedes Paket hat ein klares Ziel:
- AWS Security Audit und Quick Wins
- Infrastructure-as-Code Setup mit Terraform oder CDK
- Cost Optimization: Reserved Instances, Spot-Strategien, Right-Sizing
- Migration: Von Heroku zu AWS, von VMs zu Containern
Am Ende jedes Pakets: Ein Review. Was haben wir erreicht? Was haben wir gelernt? Und vor allem: Was ist jetzt am wichtigsten für das nächste Paket?
Die Flexibilität
Hier liegt der Unterschied zum klassischen Festpreis. Nach jedem Paket können Prioritäten angepasst werden. Neue Erkenntnisse aus dem Betrieb? Eine verschobene Deadline? Ein Feature, das sich als unwichtiger herausstellt? Das Backlog wird neu sortiert, und wir machen im nächsten Paket das, was jetzt den größten Wert bringt.
Und weil jede Iteration ein lauffähiges Ergebnis liefert, bleibt der Kunde frei: pausieren, aufhören, oder sogar den Dienstleister wechseln. Kein halbfertiger Zustand, keine Abhängigkeit. Das Projekt ist nach jeder Iteration in einem nutzbaren Stand.
Warum das für beide Seiten funktioniert
Für unsere Kunden:
- Klare Kosten pro Paket, keine Überraschungen
- Nach jedem Paket etwas Nutzbares, nicht “80% fertig”
- Freiheit, Prioritäten anzupassen ohne Vertragskämpfe
- Risiko verteilt auf kleine Einheiten statt auf ein Mammutprojekt
Für uns bei Black Bridge:
- Wir können uns auf gute Arbeit konzentrieren, nicht auf Scope-Diskussionen
- Effizienz wird belohnt—wenn wir schneller sind, starten wir früher ins nächste Paket
- Die Zusammenarbeit basiert auf Vertrauen und regelmäßigem Alignment
- Wir lernen den Kontext des Kunden wirklich kennen
Wann welches Modell
Bei Black Bridge entscheiden wir gemeinsam mit dem Kunden, welches Modell passt.
Stundensatz wählen wir für:
- Laufende Betreuung und Support
- Beratung, Reviews, Architektur-Sparring
- Projekte mit sehr variablem oder unklarem Umfang
- Situationen, in denen maximale Flexibilität wichtig ist
Agiler Festpreis wählen wir für:
- Klar abgrenzbare Projekte mit mehreren Phasen
- Situationen, in denen Budgetsicherheit wichtig ist
- Teams, die aktiv mitarbeiten und priorisieren wollen
- Projekte, bei denen wir erwarten, dass sich Anforderungen entwickeln
Klassischer Festpreis kommt in Frage für:
- Kleine, klar definierte Einzelleistungen
- Situationen mit sehr stabilen, dokumentierten Anforderungen
Wann es nicht funktioniert
Der Agile Festpreis ist kein Allheilmittel. Er scheitert, wenn die Grundvoraussetzungen nicht stimmen.
Fehlende Mitwirkung: Das Modell lebt davon, dass der Kunde Tickets definiert, an Schätzungen teilnimmt, Prioritäten setzt. Wenn diese Beteiligung ausbleibt—weil keine Zeit, kein Interesse, oder “macht ihr mal”—funktioniert es nicht.
Politik bei der Schätzung: Story Points funktionieren nur, wenn beide Seiten ehrlich schätzen. Wenn Tickets absichtlich klein geredet werden, um mehr ins Budget zu quetschen, oder absichtlich aufgeblasen werden, um Puffer zu schaffen, bricht das Vertrauen zusammen. Und damit das ganze Modell.
Unklare Anforderungen ohne Bereitschaft zur Klärung: Komplexität lässt sich nur schätzen, wenn klar ist, was gebaut werden soll. Wenn Tickets vage bleiben und niemand sie schärfen will, wird jede Schätzung zum Ratespiel.
In diesen Fällen ist ein Stundensatz-Modell oft ehrlicher—weil es die Unsicherheit dort lässt, wo sie hingehört.
Worauf es wirklich ankommt
Das Abrechnungsmodell ist am Ende ein Werkzeug. Was zählt, ist die Zusammenarbeit.
Der Agile Festpreis funktioniert, weil er Struktur für Vertrauen schafft. Kleine Pakete bedeuten regelmäßige Checkpoints. Regelmäßige Checkpoints bedeuten, dass Probleme früh sichtbar werden. Und klare Ergebnisse nach jedem Paket bedeuten, dass niemand im Dunkeln tappt.
Das erfordert aber auch etwas vom Kunden: Beteiligung. Priorisierung. Entscheidungen. Der Agile Festpreis ist kein “Projekt über den Zaun werfen”-Modell. Er funktioniert, wenn beide Seiten investieren.