So gestalten Sie Verträge für agile Projekte

Agile Verträge und Preismodelle für die agile Softwareentwicklung

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.

Exkurs: Wasserfall vs. Agilität

Was unterscheidet Agilität vom klassischen Vorgehen?

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

Welche Vertragstypen existieren und welche eignen sich für Software-Projekte?

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: 

  • Kaufvertrag
    Beispiel: Kauf einer Standard-Software wie z. B. Microsoft Office
  • Mietvertrag
    Beispiel: Nutzung eines Cloud-Services
  • Dienstvertrag
    Beispiel: Pflegeverträge für Standard-Software mit limitierten Services
  • Werkvertrag
    Beispiel: Planung und Programmierung einer auf die spezifischen Bedürfnisse der Kund:innen zugeschnittenen Software
  • Schenkungsvertrag
    Beispiel: Nutzung einer Freeware-Tools

Den richtigen Vertragstyp wählen

Agiler Softwarevertrag: Dienstvertrag oder Werkvertrag?

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:

Dienstvertrag

Der/die Auftragnehmer:in stellt die Erbringung seiner/ihrer Dienste zur Verfügung.

D.h. man schuldet „nur“ das Bemühen um die Erstellung der Software = Programmieren.

Der/die Auftraggeber:in ist also sofort zur Zahlung verpflichtet.

Werkvertrag

Der/die Auftragnehmer:in übernimmt die Verantwortung für die erfolgreiche Erstellung seines/ihres Werkes.

D.h. man schuldet den Erfolg = funktionsfähige Software.

Der/die Auftraggeber:in ist nach Abnahme zur Zahlung verpflichtet.

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 der Entwicklung umfangreicher Individual-Software liegt in der Regel ein Werkvertrag vor“.

Die Begründung lautete:

„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?

Wie finde ich heraus, ob ein Dienst- oder Werkvertrag vorliegt?

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

 


x

Keine Mängelhaftung inkludiert


x

 

Erstellung nach „Gutdünken“


x

 

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 wichtigsten Inhalte für agile Verträge 

Die 6 wichtigsten Inhalte für die Vertragsgestaltung bei agilen Software-Projekten. Detaillierter Infos finden Sie im Buch „Agile Verträge“.

  1. Leistungsbeschreibung
  2. Beschreibung der agilen Methode (z. B. Scrum)
  3. Beschreibung der Rollen
  4. Vergütung (z. B. Festpreis, „Time & Material“ u. Ä.)
  5. Testverfahren nach Sprints bei Dienstverträgen bzw. Teil-/Gesamtabnahmen bei Werkverträgen
  6. Mängelhaftung, allgemeine Haftung

Fokus auf „Warum” oder „Wie”

Was ist der grundsätzliche Unterschied zwischen kosten- und nutzenorientierten Verträgen?

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?

Vergütung und Preismodelle für agile Verträge

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 

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.

  1. Für den ersten Sprint werden verschiedene Dienstleister:innen beauftragt.
  2. Danach werden Qualität der Ergebnisse und Zeitaufwand verglichen.
  3. Das beste Team erhält den Auftrag.
  4. Das Sprint-Planning orientiert sich am 1 Sprint.
  5. Was pro Sprint nicht geschafft wird, liefert das Entwickler:innen-Team kostenlos nach.

„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:

  1. Der/die Auftraggeber:in kauft 1 Entwickler:innen-Team für X Sprints
  2. Der 1. Sprint dient zur Orientierung bzgl. der Velocity/Schnelligkeit pro Sprint, auf die sich beide im Dialog einigen.
  3. Nach jedem Schritt wird die Velocity ausgewertet, ggf. angepasst und gemeinsam besprochen.
  4. Wenn am Projekt-Ende mehr Zeit aufgewendet wurde als erwartet, werden die Mehrkosten geteilt.

Nutzenorientierte Verträge

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: Pay per Use

Wie der Name schon sagt, wird bei Nutzung eine Zahlung fällig. Wie kann das aussehen?
 

Beispiel „Rechnungssoftware“:
Die Erstellung der Software ist kostenlos, der/die Auftraggeber:in bezahlt für jede mit der Software erstellte Rechnung.

Mischformen aus kosten- und nutzenorientierten Vertragsmodellen

Idee 1: Proviant und Prämie

Der/die Auftragnehmer:in erhält eine Erstattung seiner/ihrer Kosten zzgl. einer Prämie, wenn ein vorher definiertes Ziel erreicht wird.

Je weniger Aufwände er/sie hat, desto höher fällt im Vergleich der Gewinn aus. 

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 €.

Verschiedene Preismodelle für agile Software-Verträge in der Übersicht

Fazit: Wie setze ich den passenden vertraglichen Rahmen für agile Software-Projekte?

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.

Hier ist unser Kollege Stefan zu sehen.

Über den Autor

Stefan Roock

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.):

E-Mail:Twitter:LinkedIn:

Mehr von Stefan Roock

Sie wollen weiterlesen?

Das Buch zum Thema

„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.

Buch bei Amazon »

Unser it-agile Lagerraum

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

 

+ 49 40 4135 848-0    info@it-agile.de    Online Termin buchen

Agile Coaching von it-agile

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

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.

  • Wir integrieren Pragmatismus mit Idealismus
  • Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
  • Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
agile review Magazin

agile review

Unser Kundenmagazin 

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

  • Als Abo oder Einzelausgabe erhältlich
  • Digital oder Print
  • Einzelne Artikel sofort digital verfügbar

Wissens- und Lesenswertes

Das könnte Sie zu Agiler Arbeit auch interessieren

Die 5 Dysfunktionen eines Teams

Agile Teams

Die fünf Dysfunktionen sind in einer Pyramide angeordnet, um auszudrücken, dass eine Ebene der Pyramide die vorherige als Voraussetzung braucht.

Agile Teams

Ein Haufen abhängiger agiler Teams ergibt noch kein agiles Unternehmen. Die übergreifenden Themen führen zu extremen Overhead, schlechter Vorhersagbarkeit und langsamer Time-To-Market. Diese Probleme…

Agile Teams

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings. Was steckt dahinter?

it-agile Newsletter

Sichern Sie sich regelmäßige Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle und neue Termine für unsere Schulungen sowie vieles mehr.


* Benötigte Angaben