Leistung und Gegenleistung (die sogenannten "essentialia negotii") stellen den Mindestinhalt eines Vertrages dar, der nur zustande kommt, wenn übereinstimmende Willenserklärungen hierzu vorliegen.

Dieses allgemeingültige Konzept stößt bei bestimmten IT-Verträgen allerdings an seine Grenzen. Die vermeintlich einfachen Fragen des Juristen – "Was wird hergestellt?", "Was bekommen wir?" – können zum Zeitpunkt des Vertragsabschlusses schlichtweg nicht beantwortet werden, wenn IT-Projekte agil durchgeführt werden.

Die Leitsätze und Grundprinzipien der agilen Softwareentwicklung wurden erstmals 2001 im "Manifest für Agile Softwareentwicklung" formuliert. Eine agile Vorgehensweise bietet sowohl für die Softwareentwickler als auch für den Auftraggeber zahlreiche Vorteile.

So ermöglicht diese Art der Abwicklung von IT-Projekten die Reaktion auf Veränderungen während des laufenden Projekts. Würde man sehr komplexe Projekte nach dem klassischen Wasserfallvorgehen abwickeln, bei dem zunächst abschließend alle Anforderungen an eine Software in einem Pflichtenheft definiert und diese dann umgesetzt werden, riskiert man, vom Leben überholt zu werden.

Zum Zeitpunkt der Fertigstellung der Software sind die zu Beginn des aufwendigen und in der Umsetzung langwierigen Projekts definierten Anforderungen oft nicht mehr aktuell.

Die agile Abwicklung von IT-Projekten ermöglicht demgegenüber die schrittweise Annäherung an komplexe Projekte. Entscheidungen können von den Beteiligten am konkreten Anwendungsfall getroffen werden.

Der Auftraggeber hat das zu schaffende Werk stets vor Augen und sieht, wie es sich entwickelt. In der Praxis werden komplexe IT-Projekte daher beinahe ausschließlich agil abgewickelt.

Verzicht auf Pflichtenheft

Dabei beschreiben Fachexperten und Entwickler zunächst gemeinsam eine "Produktvision". Hierbei handelt es sich jedoch nur um eine grobe Richtungsvorgabe, die während des Projekts konkretisiert wird. Die Produktvision kann während des laufenden Projekts ohne weiteres geändert werden. Auf die Herstellung eines Pflichtenheftes, das die genauen Anforderungen an das Endprodukt definiert, wird bewusst verzichtet.

Das Projekt wird vielmehr in kurze Etappen (Iterationen oder "Sprints") unterteilt. Am Anfang einer Iteration werden die Anforderungen für ein Teilprodukt ("Produktinkrement") festgelegt. Das Produktinkrement wird sogleich hergestellt, ohne dass zuvor weitere, aufbauende Teilprodukte definiert werden.

Tests, Feedback und Weiterentwicklung

Die Entwicklung der Software beginnt daher, ohne dass zuvor alle Anforderungen an das Endprodukt in einem Pflichtenheft definiert wurden. Das voll funktionsfähige Teilprodukt wird dem Auftraggeber vorgelegt. Der Auftraggeber kann es testen und Feedback geben. Anschließend wird unter Berücksichtigung des Feedbacks in der nächsten Iteration ein weiteres Teilprodukt definiert und hergestellt.

Dies wird wiederholt, bis das gesamte Produkt fertig ist – oder das Budget aufgebraucht ist. Fachexperten und Entwickler arbeiten laufend eng zusammen und stehen in engem persönlichem Kontakt.

Rechtliche Herausforderungen

Häufig werden bei agilen Projekten Juristen vor allem zu Projektbeginn nicht gerne beigezogen, da die Projektverantwortlichen befürchten, die Juristen könnten die Erstellung eines abschließenden Pflichtenhefts zu Beginn des Projekts verlangen und somit die agile Vorgehens weise untergraben. Diese Sorge ist nicht unbegründet.

Der Obersten Gerichtshof stuft Verträge über Individualsoftware-Entwicklungen regelmäßig als Werkvertrag ein, bei dem das herzustellende Werk im Pflichtenheft möglichst genau beschrieben werden muss. Möchte der Softwareentwickler agil arbeiten, hat er dieses Vorhaben nach der Rechtsprechung des OGH vor Vertragsabschluss offenzulegen; die Mitarbeit des Auftraggebers an der Programmerstellung ist vertraglich zu vereinbaren. Unterbleibt dies und ist der Auftraggeber mit dem Endprodukt nicht zufrieden, kann der Softwareentwickler unter Umständen seinen Entgeltanspruch verlieren.

Für Vertragsjuristen bringt dies große Herausforderungen. Einerseits müssen Verträge so gestaltet werden, dass sie dem agilen Vorgehen entsprechen, das klar auf partnerschaftliche Lösungen am konkreten Anwendungsfall setzt. Andererseits sollen die Verträge der OGH-Judikatur genügen und als Regelwerk für weniger harmonische Tage klare Bestimmungen und Verantwortlichkeiten vorsehen.

Vertragliche Abbildung

Die Erfüllung aller Anforderungen an den Vertrag sicherzustellen ist nicht leicht, aber keinesfalls unmöglich. Die Vertragsparteien müssen das komplexe agile Vorgehen abstrakt vertraglich abbilden. Besondere Bedeutung kommt dabei dem jeweiligen Produktinkrement zu. Bei Vertragsabschluss können der Leistungsgegenstand und der Preis noch nicht benannt werden.

Im Projekt in Bezug auf ein konkretes Produktinkrement ist dies jedoch möglich. Die Schätzung der Kosten sowie die Festlegung des Leistungsgegenstands erfolgen laufend, und zwar durch die konkrete Beschreibung des jeweiligen Produktinkrements (User Story). Der Vertrag kann daher nur abstrakt die vereinbarte Vorgehensweise (z. B. Scrum) und Verantwortlichkeiten regeln und auf die Konkretisierungen im Projekt verweisen.

Wann ist das Projekt gescheitert?

Bei dieser Vorgehensweise ist es essenziell, den Projektmitarbeitern die rechtliche Bedeutung der konkreten Beschreibung des jeweiligen Produktinkrements zu vermitteln. Darüber hinaus ist im Vertrag zu definieren, wann ein Projekt als gescheitert angesehen wird und wie in einem solchen Fall vorzugehen ist.

Schließlich sind die Faktoren für ein erfolgreiches agiles IT-Projekt vertraglich abzusichern. Hierzu gehört die Sicherstellung der Kontinuität des Projektteams. Ein Austausch von Teammitgliedern sollte tunlichst vermieden werden.

Enge Zusammenarbeit

Die vertragliche Abbildung des agilen Vorgehens erfordert ein gewisses Grundverständnis des agilen Projektmanagements und des Arbeitsalltages des Projektteams. Entwickler, Fachexperten und Juristen müssen eng zusammenarbeiten, um auf das Know-how aller Beteiligten zugreifen zu können.

Manche Themen sind schrittweise – vielleicht auch in mehreren Iterationen – zu erarbeiten. Im Ergebnis kann aber auch komplexen und agil durchgeführten Softwareentwicklungsprojekten ein angemessener Vertragsrahmen gegeben werden, wenn die Juristen sich auf die Herausforderungen dieser Vorgangsweise einlassen. (Franziska Paefgen, Boris Treml, Wirtschaft & Recht Journal, 17.10.2019)