Agil – aber richtig: Wahl des passenden Vertragstyps

Agile Methoden sind bei der Lösung von komplexen Fragestellungen erheblich im Vorteil und mittlerweile State of the Art bei vielen IT-Projekten. Doch es ist nicht ganz trivial, die „agilen Besonderheiten“ bei der Vertragsgestaltung mit dem Kunden zu berücksichtigen. Werkvertrag? Dienstvertrag? Irgendetwas dazwischen? Ohne das korrekte Rahmenwerk fallen im Fall der Fälle die praktische Umsetzung im Projekt und die vertragliche Regelung auseinander – spätestens vor Gericht sind dann sicher geglaubte Ansprüche nicht mehr durchsetzbar.

Vertragsgestaltung von IT-Projekten: immer individuell

Jedes Projekt ist einzigartig. Daher gibt es nicht den richtigen Vertrag für alle agilen Projekte. Der Vertragstyp ist vielmehr abhängig von den Zielen der Vertragspartner, der Situation und der gewünschten Risikoverteilung.

Sofern der Auftraggeber eher ein Produkt, z.B. eine Mobile App oder einen smarten Koffer als Projektziel hat und er daher die Projektziele auf der Ebene von Ergebnistypen z. B. in einem Pflichtenheft festlegen kann, er Umsetzungsrisiken nicht selbst tragen möchte, Fixtermine für ihn ein kritischer Erfolgsfaktor sind, er über kein eigenes Know-how verfügt und auch keinen Projektleiter stellen kann, spricht viel dafür, das Projekt als Werkvertrag zu vereinbaren und umzusetzen. Der Auftragnehmer – also der Freelancer – verantwortet dann den Projekterfolg. In den meisten Fällen sind einige Punkte jedoch nicht klar. Dann müssen die Vertragspartner den Vertragsgegenstand genauer untersuchen.

Dabei gilt grundsätzlich: Wer die ordnungsgemäße Durchführung eines Auftrages schuldet, ist für das Projektmanagement und die Steuerung, d.h. für den ordnungsgemäßen Ablauf des Projektes verantwortlich. Wer das Projekt steuert, nimmt in der Regel auch die unternehmerische Verantwortung für den Erfolg wahr.

Vertragstypen für Software-Entwicklungsprojekte im Überblick

Eine der umstrittensten Fragen der letzten Jahre im IT-Recht ist die Frage nach dem Rechtscharakter von Verträgen über IT-Projekte zur Softwareentwicklung. Softwareentwicklungsprojekte werden dabei vertragstypologisch als Dienstvertrag nach § 611 ff. BGB, als Gesellschaftsvertrag nach § 705 ff. BGB, als Lizenzvertrag, als Werkvertrag nach § 631 ff. BGB und als Kaufvertrag gem. §§ 433, 651 BGB eingeordnet.

In der vertraglichen Praxis sind hiervon jedoch zumeist nur der dienstvertragliche oder der werkvertragliche Typus relevant. Denn in den allermeisten Fällen entsprechen nur Werk‑ oder Dienstverträge der gewollten Risikoverteilung und damit dem Willen der Parteien. Dies gilt unabhängig von der gewählten Projektmanagementmethode, beispielsweise Wasserfall oder agil.

Den richtigen Vertrag für agile Projekte finden

Agile Methoden wie Scrum basieren auf der intensiven Zusammenarbeit aller Beteiligten. Denn erst im Laufe des Projektes werden die Anforderungen parallel zum Entwicklungsfortschritt konkretisiert. Änderungen und das Entstehen von neuen Anforderungen sind keine außergewöhnlichen Ereignisse wie bei den klassischen Projektmethoden. Sie sind ein natürlicher Teil des Projektfortschrittes und werden dementsprechend prozessual von der Methode unterstützt. Das begünstigt den erfolgreichen Einsatz von agilen Methoden gerade in einem komplexen Umfeld.

Bislang gibt es keine höchstrichterliche Rechtsprechung zur Einordnung von Verträgen über Scrum-Projekte. Dennoch können wertvolle Rückschlüsse für agile Projekte aus der Rechtsprechung in relevanten, ähnlichen Fällen gezogen werden.

In seiner Siloanlagen-Entscheidung macht der Bundesgerichtshof (BGH) elementare Ausführungen zu Werkverträgen, die auch für Scrum-Projekte relevant sind. Der BGH entschied in seinem Urteil unter anderem, dass die vorherige Instanz das Vertragsverhältnis fälschlicherweise als Werkvertrag angesehen habe.

Richtigerweise lag ein Werklieferungsvertrag nach § 615 BGB vor, der nach kaufrechtlichen Regeln zu beurteilen sein. Denn Vertragsgegenstand war die Lieferung herzustellender oder zu erzeugender beweglicher Sachen. Weiter führt der BGH in der Begründung aus (Siehe BGH, Urteil vom 23.7.2009 - VII ZR 151/08, MMR 2010, 23 mit Anmerkungen RiOLG Dr. Helmut Hoffmann):

„Eine Ausnahme [zur Anwendung von § 651 BGB] kann deshalb allenfalls dann gelten, wenn die Planungsleistung so dominiert, dass sie den Schwerpunkt des Vertrages bildet und deshalb die Anwendung des Werkvertragsrechts erfordert. Das kann z. B. dann der Fall sein, wenn es bei der Beauftragung im Wesentlichen um die allgemein planerische Lösung eines konstruktiven Problems geht.“

Als Rückschluss aus dem Urteil lässt sich für Scrum-Projektverträge gut vertreten, dass ein Werkvertrag vorliegt. Denn die Planung ist bei Scrum in die Entwicklung integriert. Beide sind in den Sprints untrennbar verbunden. Die Planungsleistung ist bei Scrum ein zentraler Entwicklungsbestandteil und daher Kern des Vertrages.

Dagegen könnte sprechen, dass es bei Scrum kein Lasten- und kein Pflichtenheft und damit keine Leistungsbeschreibung gibt. Aber dies steht einem Werkvertrag grundsätzlich nicht entgegen. Bei Projektbeginn stehen die Grundvorstellungen zu der bezweckten Anwendung und den Zielen des Projekts sowie Konkretisierungen durch Use-Cases und das Product-Backlog fest. Das ist in der Regel weit mehr, als bei der Reparatur eines Autos feststeht, welches ein Schulbuchbeispiel für einen Werkvertrag ist. Für ein Scrum-Projekt als Werkvertrag spricht weiter, dass ein potentiell auslieferungsfähiges Produkt/Inkrement das wesentliche Ziel des Scrum-Prozesses ist. Das heißt, mit jedem Sprint entsteht ein implementiertes, getestetes und dokumentiertes Stückchen Software als Erfolg. Damit sind Scrum-Projekte im Regelfall Werkverträge.

Ein Scrum-Projekt könnte jedoch auch als Dienstvertrag durchgeführt werden, wenn die Vertragsparteien eben keinen Werkvertrag wünschen. Gegebenenfalls ist auch die Besetzung der Scrum-Rollen in der Art, dass es dem Auftragnehmer nicht möglich ist, die unternehmerische Verantwortung für den Erfolg des Projektes zu übernehmen. Dann wird von einem Dienstvertrag auszugehen sein. Denn es darf vernünftigerweise nicht davon ausgegangen werden, dass der Auftraggeber für den erfolgreichen Projektabschluss einstehen möchte, wenn er das Projekt nicht steuern kann.

Die Rollenverteilung ist entscheidend

Ob ein Scrum-Projekt als Werk- oder Dienstvertrag durchgeführt werden kann, hängt maßgeblich von der Besetzung der Rollen ab. Das Scrum Team besteht aus drei zentralen Rollen: Scrum-Master, Product Owner und Entwicklungsteam (Development Team).

In der Praxis kommt häufig der Product Owner vom Auftraggeber. Denn schließlich weiß der Auftraggeber am besten, wie sein Produkt aussehen soll. Bei sorgfältiger Gestaltung des Vertrages ist dabei die Abwicklung des Projektes als Werkvertrag vertretbar. Denn der Product Owner ist lediglich der Anwalt des Produktes. Seine Entscheidungen betreffen nur das Produkt und sind rein fachlicher Art.

Nicht ganz so gebräuchlich ist die Konstellation, dass das Scrum-Team komplett vom Auftragnehmer z.B. als Arbeitsgemeinschaft (ARGE) von externen Experten gestellt wird. Rechtlich unproblematisch liegt dann ein Werkvertrag vor. Viele Agilisten finden diese Konstellation jedoch befremdlich, da die Produktvision etc. natürlicherweise auf Auftraggeber-Seite gesehen wird.

Jedoch arbeitet der – in diesem Fall externe – Product Owner regelmäßig nicht auf der „grünen Wiese“. Er stimmt seine Produktvision mit dem Management, den Nutzern und den Kunden ab. Sofern die Projektpartner vertrauensvoll zusammenarbeiten, kann die Rolle des Product Owners als Anwalt des Produktes auch extern vom Auftragnehmer besetzt werden.

Selbstverständlich sollte der Product Owner in diesem Fall noch klarer mit dem äußeren Kreis beim Auftraggeber seine Produktvision abstimmen und diese dokumentieren, um bei einer formellen Abnahme durch den Auftraggeber keine Überraschungen zu erleben.

Sofern der Hüter der Methode, der Scrum-Master, auf der Auftraggeber-Seite steht, kann der Auftragnehmer den Erfolg des Projektes kaum mehr verantworten. Daher ist das Projekt dienstvertraglich auszugestalten. Gleiches gilt daher grundsätzlich auch für das Entwicklerteam. Denn es organisiert sich selbst und ist dafür verantwortlich, die Inkremente zu liefern. Sofern Mitarbeiter des Auftraggebers in dem Entwicklerteam verantwortlich mitarbeiten, ist daher ausgeschlossen, dass der Auftragnehmer für den Erfolg des Projektes einsteht. Anders kann es sich darstellen, sofern die Verantwortung für das Inkrement beim Auftragnehmer verbleibt und der Auftraggeber z. B. Mitarbeiter lediglich beratend oder zum Know-how-Transfer als Mitwirkung entsprechend beistellt. In diesem Fall müssen die Risikosphären sehr sorgfältig auseinanderdividiert und gelebt werden, aber eine werkvertragliche Gestaltung wäre möglich.

Diese ersten Überlegungen zeigen, dass sich agile Methoden durchaus in werk- oder dienstvertragliche Formen gießen lassen. In Teil 2 der Serie geben wir weitere Impulse, wie das Vertragswerk konkret ausgestaltet werden kann. Außerdem zeigen wir, was in der Praxis in Sachen Scheinselbstständigkeit beziehungsweise verdeckte Arbeitnehmerüberlassung beachtet werden muss.