Autor
Stefan Roock
- Twitter:@StefanRoock
- LinkedIn:stefanroock
So gestalten Sie Verträge für agile Projekte
Bei agilen IT-Softwareprojekten stellen sich besondere Herausforderungen bezüglich der Vertragsgestaltung. Denn ohne klassisches Lastenheft mit vorab definierten Spezifikationen können die Aufwände nur schwer vorhergesagt und somit beziffert werden. Stefan Roock von it-agile hat sich zusammen mit dem IT-Rechtler Fritz-Ulli Pieper diesem Thema gewidmet. Herausgekommen ist ein umfassendes Buch über Vertragsgestaltung bei agilen Softwareprojekten.
Wir geben Ihnen hier einen Überblick über die juristischen Grundlagen und Lösungen für Ihre agile Software-Vertragsgestaltung.
Der schnelle Überblick
Die Gestaltung von Verträgen für agile Softwareentwicklungsprojekte stellt besondere Herausforderungen dar, da traditionelle Lastenhefte mit detaillierten Spezifikationen oft fehlen und Aufwände schwer vorherzusagen sind. Dieser Artikel bietet umfassende Informationen zu juristischen Grundlagen und Lösungen für agile Vertragsgestaltungen.
Die Wahl des passenden vertraglichen Rahmens für agile Softwareprojekte erfordert ein tiefes Verständnis sowohl der agilen Methoden als auch der juristischen Grundlagen. Eine enge Zusammenarbeit zwischen allen Beteiligten ist essenziell, um flexible und dennoch rechtlich abgesicherte Vereinbarungen zu treffen.
Für eine vertiefte Auseinandersetzung mit diesem Thema empfiehlt sich das Buch „Agile Verträge“ von Fritz-Ulli Pieper und Stefan Roock, das die vertragsrechtlichen Grundlagen bei agiler Entwicklung sowie verschiedene Vertragsgestaltungsvarianten detailliert beschreibt.
Wasserfall-Methode: Beim klassischen Projektmanagement erfolgt die Software-Entwicklung in Phasen, die ineinander übergehen. Man spricht von der Wasserfall-Methode, da der Output aus der vorherigen Phase in die nächste einfließt:
Nach der Analyse werden die Anforderungen in ein Lastenheft aufgenommen, das die Entwickler:innen in einer vorgegebenen Zeit abarbeiten. Sobald die Software programmiert ist, wird sie getestet, nötige Korrekturen vorgenommen und fertig ist das Projekt. (vgl. Grafik)
Dieses Vorgehen ist ungeeignet für komplexe Projekte wie die meisten Software-Entwicklungsprojekte, da die wirklich benötigten Software-Funktionen erst im Verlauf der Entwicklung deutlich werden. Es führt oft zu Konflikten bei der Zahlung oder zum totalen Projektstopp, da man sich nicht einigen kann, was Nachbesserung und was neue Beauftragung ist, wenn weitere oder andere Funktionen am Projektende gewünscht sind.
Agiles Vorgehen: In der agilen Entwicklung von Software oder anderen komplexen Produkten wird möglichst frühzeitig eine erste funktionsfähige (aber wahrscheinlich noch nicht perfekte) Version erstellt, die getestet und Kund:innen vorgelegt werden kann. Aus dem direkten Feedback und den Test-Ergebnissen werden Schlüsse für Verbesserungen gezogen. Dieses Vorgehen wird mehrmals wiederholt, bis die bestmögliche Version entsteht.
Das ist das Prinzip von „Inspect & Adapt“ (in Deutsch etwa: „inspizieren und anpassen“).
Die einzelnen Phasen aus Analyse, Design, Entwicklung und Test erfolgen überlappend und nicht nacheinander wie bei der Wasserfall-Methode. Im Laufe der Entwicklung kristallisiert sich schrittweise die beste Lösung. Überlappende Phasen sind hier die Antwort, um mit der Unklarheit besser umgehen zu können.
Agilität hat sich in der IT-Branche, aber nicht nur dort, durchgesetzt, weil es Kunden:innnen und Entwickler:innen mehr Flexibilität schafft und so den Weg frei macht, für bessere und innovativere Produkte.
Was die Jurist:innen über agile Verträge sagen
Die im Bürgerlichen Gesetzbuch (BGB) vorgesehenen Vertragstypen sind an sich auch für Software-Produkte und -Projekte geeignet, auch wenn die IT-Branche im Vergleich zum BGB sehr jung ist. Beispiele, wie Software-Produkte und -Services den Vertragstypen im BGB zuzuordnen sind:
Den richtigen Vertragstyp wählen
Verträge sind übereinstimmende Willenserklärungen (Angebot und Annahme) von 2 oder mehreren Personen, die eine bestimmte Rechtsfolge herbeiführen wollen. Kurz gesagt: Verträge regeln die Leistungen und Ansprüche von Auftragnehmer:in und Auftraggeber:in bei einem Projekt.
Je nach Vertragstyp unterscheiden sich beispielsweise die Fälligkeit der Vergütung, die Verpflichtung zur Mängelbeseitigung usw. Im Konfliktfall ist es also von besonderer Bedeutung, welcher Vertragstyp vorliegt.
Nach den oben aufgezeigten Vertragstypen lassen sich agile Software-Projekte am ehesten dem Dienst- oder Werkvertrag zuordnen. So unterscheiden sich die Vertragstypen und die Rechtsfolgen bzgl. der Zahlungsfälligkeit:
Der Bundesgerichtshof hat in Bezug auf die Einordnung von Software-Entwicklungsverträge eine Entscheidung getroffen, die sich auch auf agile Software-Verträge übertragen lässt:
„Bei Software-Entwicklungen ist eine erhebliche Planung nötig. Deshalb handelt es sich oft um einen Werkvertrag.“
Das ist jedoch keine Vorgabe für die Vertragsgestaltung von agilen Projekten. Denn es gilt grundsätzlich die Vertragsfreiheit.
Wann gilt was?
Es gibt eine Reihe an Indizien für Dienst- bzw. Werkvertrag, die wir hier exemplarisch aufführen. Wichtig ist dabei, dass es unerheblich ist, welche Überschrift man dem Vertrag gibt. Anders gesagt: Wenn „Dienstvertrag“ draufsteht, muss noch lange kein Dienstvertrag drinstecken.
Dienstvertrag | Werkvertrag | |
Es ist eine Abnahme für die fertige Software vorgesehen |
| |
Keine Mängelhaftung inkludiert |
| |
Erstellung nach „Gutdünken“ |
| |
Klare Vorgaben für die Software, z. B. in Form eines Lastenheftes |
x | |
Nennenswerte planerische oder gestalterische Leistung beim Auftragnehmer |
x | |
Starke Einbindung des/der Auftraggebers:in in den gesamten Prozess |
x |
Das sollte drinstehen:
Die 6 wichtigsten Inhalte für die Vertragsgestaltung bei agilen Software-Projekten. Detaillierter Infos finden Sie im Buch „Agile Verträge“.
Fokus auf „Warum” oder „Wie”
Kostenorientierte Verträge thematisieren die Kosten der Entwicklung. Nutzenorientierte Verträge benennen den Nutzen für den Anbieter und machen die Bezahlung von diesem Nutzen abhängig.
Obwohl sich nutzenorientierte Verträge von ihrer Grundidee deutlich von kostenorientierten Verträgen unterscheiden, sind die rechtlichen Unterschiede weniger deutlich. Nutzenorientierte Verträge fokussieren auf „warum” etwas programmiert wird, weniger „wie”.
Was geht außer Festpreis und „Time & Material“ noch?
Die Praxis zeigt, dass auch bei agilen Projekten nach den klassischen Abrechnungsmethoden abgerechnet wird. Das sind der Festpreis und „Time & Material“.
Beide bremsen Agilität jedoch ab einem gewissen Punkt aus. Wir geben Ihnen hier einen Überblick über mögliche Alternativen und Lösungen, die wir umfassend in unserem Buch erklären.
Kostenorientierte Verträge regeln die Vergütung gemäß der tatsächlich entstandenen Kosten; also: nach Materialverbrauch, Personaleinsatz, Zeitaufwand usw.
Festpreis
Beim Festpreis definiert man vorab einen pauschalen Betrag, der unabhängig vom letztendlichen Aufwand fällig wird.
Deshalb ist dieses Preismodell ungeeignet für die agile Software-Entwicklung, da der Funktionsumfang und damit die Ressourcen und der Zeitaufwand ja eben nicht klar sind von Anfang an. Das Festpreis-Modell bringt dem/der IT-Dienstleister:in mehr Risiken als dem/der Auftraggeber:in.
Lösungsansatz 1: Agiler Festpreis
Mit dem „agile Festpreis“ wandelt man den Klassiker gemäß der agilen Vorgehensweise ein wenig ab.
Es wird eine erste Testphase durchgeführt, aus der Kosten und Termin für die agile Entwicklung abgeleitet werden. Der Umfang wird so zu Beginn zwar schon vollständig erfasst, jedoch nicht im Detail beschrieben. Diese Variante stellt aus agiler Sicht auf jeden Fall einen Fortschritt gegenüber dem klassischen Festpreis da. Allerdings engt sie agiles Vorgehen immer noch relativ stark ein.
Lösungsansatz 2: „Money for nothing, change for free” von Jeff Sutherland
Bei diesem Preismodell werden 2 Klauseln integriert, die mehr Flexibilität im Vergleich zum Festpreis schaffen:
Die Klausel „Change for free“ ermöglicht dem/der Auftraggeber:in in einem vorher vereinbarten Funktionsumfang Features kostenlos auszutauschen. Das gibt den Entwickler:innen Raum, Optimierungen vorzuschlagen und diese umzusetzen, ohne gleich die Preisfrage neu zu eröffnen.
Die Klausel „Money for nothing“ setzt beim vereinbarten Festpreis an. Der/die Auftraggeber:in priorisiert zu Beginn einzelne Features nach dem Geschäftsnutzen. Je weiter man im Entwicklungsprozess ist, desto geringer wird der Nutzen der noch fehlenden Features.
Wenn der Punkt erreicht ist, dass eine Weiterarbeit einen nur geringen Mehrwert bringt, kann das Projekt beendet werden. Das nicht aufgebrauchte Geld wird 50:50 zwischen den beiden Parteien aufgeteilt.
Hier gilt das Motto: „Lieber für nichts (weniger) bezahlen, als für Unnötiges irgendwas zu bezahlen.“
Lösungsansatz 3: Festpreis pro Sprint
Eine andere Möglichkeit, den unflexiblen Festpreis an die agile Software-Entwicklung anzupassen, ist es, pro Sprint – und nicht pro Projekt – einen Festpreis festzulegen.
„Time & Material“
Bei diesem Preismodell ändert sich die Vergütung in Abhängigkeit von den Aufwänden.
Die Problematik aus unserer Erfahrung ist, dass Auftraggeber:innen dem/der Auftragnehmer:in mangelnde Motivation unterstellen oder zumindest befürchten, dass es dazu kommt.
Schließlich bringen mehr Aufwände, mehr Geld. Das bedeutet, dass der/die Auftraggeber:in bei „Time & Material“ das größere Risiko trägt im Vergleich zum Festpreis-Verfahren.
Lösungsansatz 1: Risk Share
Wie schafft man es, beiden Parteien gerecht zu werden? Indem die Risiken gemeinsam getragen werden. Das ist die Idee von „Risk Share“. Und so funktioniert sie:
Bei Agilität steht der Nutzen für die End:kundinnen im Vordergrund, nicht das Abarbeiten von Lastenheften. Daher lag die Idee nah, Preismodelle zu entwickeln, die diesem Kerngedanken von Agilität Rechnung tragen. Nicht der Aufwand, die Ressourcen und der Umfang definieren den Preis, sondern der Nutzen. Zwei Modelle werden im Folgenden beschrieben:
Idee 1: Profit Sharing
Der/die Auftragnehmer erhält die Vergütung nicht fürs Programmieren oder das Erstellen der fertigen Software, sondern beteiligt sich am Gewinn, der dem/der Auftraggeber:in durch die Software entsteht. Das garantiert eine Höchstleistung durch die Auftragnehmer:innen. Denn je besser das Ergebnis, desto eher bzw. höher die Gewinnbeteiligung.
Beispiel „Webshop“:
Die Erstellung des Webshops ist kostenlos, aber von jedem getätigten Kauf über den Webshop erhält der/die IT-Dienstleister:in einen Prozentsatz.
Idee 2: Bezahlung nach Produktivität
Der/die IT-Dienstleister:in verspricht, eine bestimmte Menge an Features für eine bestimmte Menge an Geld zu liefern.
Als Messwert werden Function Points (= Einheit der Bewertung des fachlich-funktionalen Umfangs eines informationstechnischen Systems) herangezogen. 1 Function Point hat beispielsweise den Preis von 1.000 €.
Die im BGB definierten Vertragstypen „Dienstvertrag“ und „Werkvertrag“ passen am besten zu Software-Entwicklungsprojekten, auch zu agilen. Diese Unterscheidung ist wichtig, da sich daraus die Rechte und Pflichten beider Parteien ergeben.
Die Vergütungsmodelle wie Festpreis oder „Time & Material“ sind dabei nicht entscheidend, sondern u.a. die Leistungsdefinition. Insofern liegt bei Festpreis nicht automatisch ein Werkvertrag und bei „Time & Material“ ein Dienstvertrag vor.
Agile Verträge definieren die Art der Zusammenarbeit und weniger das Ergebnis. Bei den Preismodellen gibt es verschiedene Ansätze, die dem agilen Vorgehen zuspielen. Nutzenorientierte Vertragstypen und das Teilen von Risiken passen am besten zu agilen Denk- und Handelsweisen.
Interesse geweckt?
Unsere Schulungen unterstützen die Fort- und Weiterbildung der Mitarbeiter:innen Ihres Unternehmen mit dem Umgang extremer Unsicherheit und Komplexität. Ihr Unternehmen und Ihre Mitarbeiter:innen werden dadurch handlungsfähig.
Weiterhin:
Über den Autor
Stefan Roock hilft Unternehmen, Führungskräften und Teams dabei, ihre Potenziale zu entfalten - hin zu erfolgreichen Unternehmen, die ihre Kunden und Mitarbeiter begeistern. Er ist davon überzeugt, dass dazu strukturelle, personelle und interpersonelle Themen im Zusammenspiel adressiert werden müssen.
Veröffentlichungen (u. a.):
Sie wollen weiterlesen?
„Agile Verträge Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche“ von Fritz-Ulli Pier und Stefan Roock
Das Buch beschreibt die vertragsrechtlichen Grundlagen bei agiler Entwicklung, die verschiedenen Varianten der Vertragsgestaltung sowie die einzelnen Vertragsformen mit ihren Eigenschaften, Funktionsweisen, Vorteilen und Risiken.
Kennen Sie eigentlich schon it-agile?
Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.