Der Vertrag bei agilen IT-Projekten

Die agile Softwareentwicklung – und hier insbesondere das Vorgehensmodell des „Scrum“ – weicht komplett von der klassischen „Wasserfallmethodik“ ab. Während bei der Wasserfallmethode in „Milestones“ entwickelt wird, ist die entscheidende Vertragsgrundlage beim agilen IT-Projekt der „agile Projektplan“, der ständigen Anpassungen unterworfen ist.

In der Praxis hat sich oftmals gezeigt, dass insbesondere Großprojekte im Bereich der Softwareeinführung und Anpassung häufig zu komplex sind, um vorab vollständig durchgeplant werden zu können. Dadurch entstehen häufig Streitigkeiten, die schlimmstenfalls zu Projektabbrüchen führen und in langwierigen juristischen Auseinandersetzungen enden.

Die agile Softwareerstellung bietet gerade dann Vorteile, wenn der Auftraggeber bei Vertragsbeginn nur eine ungefähre Vorstellung vom Umfang der fertigen Software hat, die Programmierung jedoch zügig beginnen möchte

Für die agile Softwareerstellung ungeeignet sind Projekte, bei denen Aufwand, Budget und ein festes Zeitfenster vom Auftragnehmer vorgegeben sind.

Das Verfahren der agilen Softwareprogrammierung wird vornehmlich von folgenden Grundprinzipien getragen:

  • Transparenz: Der Projektfortschritt und seine Risiken und Hemmnisse werden in kurzen Zeitabständen für alle Beteiligten dokumentiert.
  • Überprüfung / Kontrolle: In ebenfalls kurzen, regelmäßigen Zeitabständen werden Funktionalitäten implementiert, getestet und beurteilt.
  • Anpassung: Die Anforderungskriterien sind nicht starr, sondern ständiger Neubewertung und Anpassung unterworfen.

Im Vordergrund steht die gesteigerte Zusammenarbeit der Parteien. Es wird versucht, nach einer sehr kurzen Planungsphase möglichst schnell zu einer ausführbaren Software zu gelangen. Dafür werden in einem ständigen Austausch der Parteien Leistungspakete definiert. Teilleistungen sind allenfalls nach Phasen (bspw. Erstellung eines Grundmoduls, weitere Funktionen, Tuning) denkbar, ohne dass eine echte Trennbarkeit und gesonderte Abnahmefähigkeit selbständiger Teile bestünde. Der Kunde erstellt immer wieder eine Prioritätenliste gewünschter Funktionen, die dann nach Vereinbarung mit dem Auftragnehmer eingearbeitet wird. Mängel und Themaverfehlungen sollen dadurch vermieden werden, dass die Parteien die Zwischenergebnisse in kurzen Abständen überprüfen.

Auch wenn sich agiles Programmieren in den vergangenen Jahren zunehmend als anerkannte Methode durchgesetzt hat, stellt sich für die Parteien häufig die Frage, wie ein solches Projekt sinnvoll in einem Vertrag abgebildet werden kann. Dies gilt umso mehr, wenn Vertragsverhandlungen von den Parteien als eher hinderlich für den Erfolg eines Projekts wahrgenommen werden.

Vor dem Hintergrund, dass der Auftraggeber in solchen Projekten in der Regel nur ein begrenztes Budget zur Verfügung hat, muss er  jedoch sicherstellen, am Ende ein bestimmtes Resultat zu erhalten. Auf ein prozessorientiertes Vertragswerk zur Umsetzung seiner Anforderungen sollte daher keinesfalls verzichtet werden.

Agiles Programmieren kann jedoch ohne gegenseitiges Vertrauen, Verständnis und Teamwork nicht funktionieren. Mangels abschließender Leistungsbeschreibung, und durch ein nach oben offenes Budget sowie einen ungewissen Zeitplan muss der Auftraggeber zwangsläufig ein Risiko eingehen. Dieses Risiko sollte jedoch durch einen geeigneten Projektvertrag soweit wie möglich reduziert werden.

Die Vertragsgestaltung bei einem agilen Projekt bietet jedoch auch einige juristische Herausforderungen:

1. Grundsätzliches

Grundsätzlich stellt sich für Parteien eines solchen Projekts die Frage, was ein Vertrag, bei dessen Abschluss hinsichtlich des Ergebnisses nur grobe Vorstellungen existieren, regeln soll.

Der klassische Softwareerstellungsvertrag wird in der Regel als Werkvertrag eingestuft. Bei einem klassischen Werkvertrag gemäß § 631 BGB muss der Besteller seine Anforderungen vorab so exakt wie möglich definieren. Dies geschieht in der Regel in Form eines ausführlichen Lastenhefts. Dieses setzt der Auftragnehmer vereinbarungsgemäß um. Das klassische IT-Projekt wird daher als Phasenmodell oder Wasserfallmodell beschrieben, weil es naturgemäß in eine Planungs- und sich zeitlich anschließende Umsetzungsphase unterteilt ist. Das Vertragsrisiko liegt in der Planungsphase hauptsächlich beim Besteller, in der Umsetzungsphase beim Auftragnehmer.

Im Gegensatz dazu verzichtet das agile Programmieren weitgehend auf die Planung als vorgeschaltete Phase mit Erstellung eines ausführlichen Lastenhefts oder nachfolgenden Pflichtenheftes. Der Planungsprozess begleitet den Entwicklungsprozess vielmehr parallel während der gesamten Zeit und soll so zu einer Softwareentwicklung mit geringem bürokratischem Aufwand und wenigen Regeln führen. Die Projektziele sind im Vorfeld somit nur grob definiert.

2. Einordung in die Vertragsarten

Das agile Programmieren könnte sowohl als Dienstvertrag als auch als Werkvertrag eingeordnet  werden.

Der reine Dienstvertrag wird zumeist dem Interesse des Auftraggebers nicht gerecht, da er am Ende des Projektes ein Ergebnis haben möchte, dass seinen inzwischen klaren Anforderungen entspricht und für dessen Fehlerfreiheit der Auftragnehmer auch einstehen soll.

Die Einordnung des Projekts als reiner Werkvertrag schafft ebenfalls Probleme: Bei Vertragsschluss stehen die Eigenschaften der zu erstellenden Software noch nicht hinreichend konkret fest. Es kann daher weder eine Beschaffenheitsvereinbarung noch eine Vergütungsvereinbarung getroffen werden.

Teilweise wird in der Literatur deshalb vorgeschlagen, einen Rahmenvertrag über die Grundlagen der Zusammenarbeit zu schließen. Dieser sieht dann sowohl dienstvertraglich ausgestaltete Reglungen über die Zusammenarbeit der Parteien vor als auch den gesonderten Abschluss von Teilprojektverträgen, die dann zur Realisierung einzelner Abschnitte als gesondertes Teilprojekt mit werkvertraglichen Elementen ausgestaltet sind. In den Bestimmungen über die Zusammenarbeit im Allgemeinen wird das von beiden Parteien gewünschte Vorgehensmodell so genau wie möglich vereinbart.

3. Mitwirkungspflichten des Auftraggebers

Auftraggeber sind sich häufig nicht darüber im Klaren, dass ihre Mitwirkungspflichten in agilen Entwicklungsprojekten im Vergleich zu den traditionellen Wasserfallprojekten deutlich stärker ausgeprägt sind. In einem Wasserfallprozess werden Entscheidungen typischerweise hierarchisch und sehr formalisiert getroffen. Dieses Prinzip ist bei agiler Programmierung stark aufgeweicht. Es ist daher notwendig, einen sinnvollen und effektiven Change- Management und Dispute-Management-Prozess zu finden und vertraglich festzulegen.

4. Projekt- und Prozessplanung

Eng mit der Steuerung der Prozesse verbunden ist auch die Projekt- und Prozessplanung. Diese spielt bei der agilen Softwareentwicklung eine besondere Rolle. Die Risiken sind aufgrund des unterschiedlichen Iterationsprozesses hier anders verortet als bei einem Wasserfallprojekt. Bei den herkömmlichen Projekten verstärken sich die Risiken zum Ende des Projektes hin, da dann die kritische Integrations- und Abnahmephase beginnt.

Der Vertrag im agilen Projekt sollte hingegen verstärkt Leitlinien für den Iterationsprozess vorgeben. Vertragliche Bestimmungen über die Zusammenarbeit und das Projektmanagement können zusätzlich die Entscheidungsfindung im Projekt fördern. Zudem sollten Eskalationsverfahren vorgesehen werden, um bei Meinungsverschiedenheiten schnell Lösungen zu finden.

5. Verzicht auf Pflichtenheft und Dokumentation

Der Aktivitäten- und Fristenplan tritt im Rahmen der Projektplanung an die Stelle des Pflichtenheftes, auf das im agilen Softwareprojekt grundsätzlich verzichtet wird. Die Bestimmung des Projektergebnisses und damit die Festlegung der geschuldeten Leistungen verlagern sich folglich in den Erstellungsprozess. Dokumentationen erfolgen typischerweise “inline” im Quellcode oder “online” als in der Anwendung oder vom Auftragnehmer zur Verfügung gestellter “Hilfe”. Hier gilt es aus Sicht des Auftraggebers, den Auftragnehmer nicht zu stark aus der Verantwortung zu entlassen, um für den Fall, dass das Projekt tatsächlich in Schieflage gerät, noch auf justiziable Leistungspflichten des Auftragnehmers zurückgreifen zu können. Art und Umfang der Dokumentation sollten daher vertraglich festgelegt werden.

6. Vergütungsregelungen

Von besonderer Bedeutung sind naturgemäß die Vergütungsregelungen Der Auftragnehmer wird dabei meist versuchen, nach Zeit und Aufwand abzurechnen und so die Risiken auf den Auftraggeber abzuwälzen. Da der Auftraggeber dem bei agilen Entwicklungsprozessen erhöhten Kostenrisiko begegnen muss, bietet es sich an, auf alternative Vergütungsmodelle zurückzugreifen, die das Risiko auf beide Parteien ausgewogen verteilen.

7. Nutzungsrechte

Der Frage der Einräumung von Nutzungsrechten wird häufig eine untergeordnete Bedeutung beigemessen, entsprechende Vertragsklauseln sind häufig zu ungenau gefasst. Bestimmungen zum Zeitpunkt der Rechtseinräumung fehlen meist ganz. Versäumnisse in der Vertragsgestaltung diesbezüglich gehen zu Lasten des Auftraggebers. Er trägt die Beweislast dafür, dass die von ihm behauptete Rechtseinräumung vom Vertrag gedeckt ist.

Die Besonderheit agiler Softwareprogrammierung liegt darin, dass es sich um eine individuelle Programmierung handelt und Nutzungsrechte bereits an Teilergebnissen entstehen können und ggf. bereits dann auf den Auftragnehmer übertragen werden sollen. Hier ist es wichtig, eine Abgrenzung vorzunehmen und den exakten Zeitpunkt der Rechtseinräumung festzulegen.

Da bei agilen Projektmethoden eine verstärkte Mitwirkungsleistung des Auftragnehmers vorliegt, kann diese Situation auch häufig zu einer Miturheberschaft führen.

Es empfiehlt sich daher dringend eine detaillierte Klausel über die Rechteverteilung in den Vertrag aufzunehmen.

8. Weitere Punkte für die Vertragsgestaltung

Soweit inhaltliche Anforderungen an das Projektergebnis zu Beginn der Zusammenarbeit grob vereinbart werden, sollte die Parteien zugleich eine Einigung darüber treffen, wie viele Entwicklungszyklen sie für die Umsetzung erwarten, wie viel Zeit hierfür voraussichtlich benötigt wird und welche Kosten hierfür geschätzt anfallen. Auch für jeden Entwicklungszyklus sollte vor dessen Beginn ein konkretes Arbeitsziel und der voraussichtliche Aufwand vereinbart werden.

Zu denken ist schließlich an die Vereinbarung geeigneter Testszenarien und deren Dokumentation. Anders als in vielen herkömmlichen Projekten wird man bei agiler Softwareerstellung auch während der Erstellungsphase sehr viel testen und mitunter auch Teilabnahmen vornehmen.

FAZIT :

Das agile Programmieren bietet insbesondere für den Auftraggeber zahlreiche Risiken, die es vertraglich einzugrenzen gilt. Die Praxis zeigt, dass häufig unausgewogene Verträge entstehen, wobei es häufig der Auftraggeber ist, der nicht angemessen abgesichert ist. Mit einem individuell auf das agile Projekt zugeschnittenen Vertrag können jedoch bereits im Vorfeld viele potentielle Konfliktpunkte entschärft werden.

 

Das könnte Sie ebenfalls interessieren:

App IT-RechtKostenloser Ratgeber

Das Anbieten von Apps für Smartphone und Tablet
Was Sie als App-Anbieter rechtlich beachten sollten

Februar 2016, Format 12 x 12 cm, 24 Seiten, pdf-Datei, 2,0 MB
Jetzt hier downloaden!

 

 

 

 

Merken

geschrieben von: Florian Decker

Florian Decker

Fragen zum Thema? Mailen Sie einfach an decker@res-media.net.

Florian Decker
Fachanwalt für Informationstechnologierecht (IT-Recht)

RESMEDIA Mainz – Anwälte für IT-IP-Medien
Am Winterhafen 78 | 55131 Mainz
Fon +49 6131 144 56 -0 | Fax +49 6131 144 56 – 20
E-Mail: decker@res-media.net
Internet: www.res-media.net

 

Related Posts

1 Comment

  1. Die Übersicht ist schon mal eine Hilfe bei Agilen Projekten, lediglich wird nicht auf das Vergütungsmodell eingegangen. Der Hinweis das man für beide Seiten eine Vereinbarung treffen muss ist nicht zielführend.
    Hier wäre es schön ein konkretes Beispiel zu nennen wie solch eine Vergütung aussehen könnte!

Leave a comment