Verträge zu Scrum & Co: Vertragsgestaltung bei agilen Programmiermethoden – Teil 1

Einleitung

Agile Programmiermethoden haben klassische Modelle wie das Wasserfallmodell oder das V-Modell weitgehend verdrängt. In einem dynamischen, auf ständige Innovation ausgerichteten Wirtschaftssystem rücken rasche Entwicklungen und schnelle Ergebnisse in den Vordergrund und bestimmen Arbeitsleben und Produktionsschritte. Gerade im Bereich der Informationstechnologie, die besonders schnellen Entwicklungen und Änderungen unterliegt, wünschen viele Unternehmen die möglichst rasche Lieferung einsatzfähiger Produkte; vorhandene Schwächen und Mängel sollen den Einsatz nicht verzögern, sondern ggf. später beseitigt werden, was nicht als störend empfunden, sondern bei der ohnehin notwendigen ständigen Anpassung an die sich ändernde IT-Landschaft mit erledigt wird.

Spielverderber und Bremsen sind – wie so häufig – die Juristen. Denn aus juristischer Sicht bergen unvollendete Planungen und Abweichungen von bekannten Rechtsformen und Schemata Risiken. Risiken, die im Bereich der Softwareentwicklung durchaus sechs- oder siebenstellige Summen kosten können. Beauftragen Unternehmen – Nachfrager oder Entwickler – Rechtsanwälte mit der Erstellung von Verträgen zur Softwareprogrammierung, prallen daher regelmäßig Welten aufeinander: Der Unternehmer ist fassungslos ob der zögerlichen Haltung des Rechtsanwalts und dessen mangelnden Verständnisses für rasche Aktionen, während der Rechtsanwalt die Bereitschaft des Unternehmens, die Rechtssicherheit einem frühen Produktionsstart unterzuordnen, kaum nachvollziehen kann.

Dieser Beitrag soll daher keine Entscheidungshilfe bieten, ob im Einzelfall herkömmliche oder agile Methoden zu wählen sind. Er unterstellt vielmehr, dass bereits die unternehmerische Entscheidung zur agilen Softwareentwicklung getroffen wurde, nicht zuletzt, weil viele Softwarehäuser die Programmierung nach anderen Methoden überhaupt nicht mehr anbieten!

Dieser Beitrag besteht aus zwei Teilen. In diesem ersten Teil geht es um die Darstellung der Grundlagen der agilen Softwareerstellung und um das Spannungsfeld zwischen agilen Eigenheiten und der gesetzlichen Vertragstypen. Der zweite Teil widmet sich der Vergütung und der Projektkommunikation.

Agiles Programmieren: Was ist das überhaupt?

Klassischen Programmiermethoden wie dem Wasserfall-Modell oder dem V-Modell liegt das Prinzip der strikten Trennung der einzelnen Phasen bei der Softwareentstehung zugrunde, neben weiteren Phasen insbesondere der Planungsphase, der Programmierphase und der Testphase. Sie beruhen auf der Vorstellung, dass das bestellende Unternehmen bereits konkrete Vorstellungen von dem zu entwickelnden Produkt hat, diese zum Abschluss der Planungsphase verbindlich festgeschrieben wird, und das Ergebnis der Planung verbindliches Kriterium für die Ordnungsgemäßheit der Programmierergebnisse ist.

Aus juristischer Sicht haben diese Entwicklungsmethoden den Vorteil, dass die Verträge problemlos den klassischen Vertragstypen des BGB, namentlich Werkvertrag und Dienstvertrag, zugeordnet werden, und bei auftretenden Problemen die Verantwortlichkeiten schnell geklärt werden können. Flexibilität bieten derartige Methoden aber wenig: Ändern sich die Wünsche oder Anforderungen des Bestellers, muss zunächst in eine neue Planungsphase eingetreten werden, die nach Beginn der Programmierarbeiten auch den aktuellen Entwicklungsstand des Produkts berücksichtigen muss.

Bei agilen Programmiermethoden sieht dies anders aus. Gut darzustellen ist dies anhand der Methode „Scrum“. Bei dieser Methode entwickelt das Programmierteam in kurzen Produktionszyklen, sog. Sprints, Programmbestandteile, die dem Besteller in regelmäßigen Meetings, sog. Reviews vorgestellt und übergeben werden. Dieser kann dann beurteilen, ob die Entwicklung seinen Vorstellungen entspricht, was die zügige Umsetzung von Änderungswünschen ermöglicht. Ist der Besteller zufrieden, wird das Ziel des nächsten Sprints festgelegt, und die Programmierarbeiten können fortgesetzt werden. Es entsteht nach und nach ein Produkt, mit dem sich der Besteller schrittweise vertraut machen, und dessen fertiggestellte Teile er in der Praxis verwenden kann.

So groß der praktische Nutzen dieser Methode ist, so schwierig ist deren juristische Handhabung. Dies beginnt bereits damit, dass agiles Programmieren keiner starren Schematik folgt, sondern eine Vielzahl von praktischen Gestaltungsmöglichkeiten besteht. Denn weder agiles Programmieren an sich noch die Unterkategorien wie Scrum, Kanban usw. sind geschützte Begriffe oder gar technischen Normen unterworfen. Die Einzelheiten sind im folgenden Abschnitt dargestellt.

Teamplay: Aufteilung nach Kompetenzen statt formalen Kriterien

Alle agilen Programmiermethoden zeichnen sich durch die enge Zusammenarbeit zwischen Besteller und Entwickler aus. Fehlt diese, ist ein Projekt zum Scheitern verurteilt. Wie und an welchen Stellen der Besteller an der Entwicklung teilnimmt, ist allerdings von Projekt zu Projekt verschieden, ebenso die Art und Zahl der am Entstehungsprozess beteiligten Personen. Letzteres sind regelmäßig das Entwickler-Team, der Product-Owner und die Stakeholder, welche die Software nutzen oder bezahlen sollen, und im Einzelfall konträre Interessen haben können (z. B. Management, Nutzer, Betriebsrat). Häufig wird das Entwicklerteam zudem von einem Scrum Master beratend unterstützt. In fachlicher Hinsicht sind an agilen Softwareprojekten regelmäßig Softwareprogrammierer und Datenbankentwickler beteiligt, darüber hinaus häufig Web-Entwickler, Grafikdesigner, Analytiker und Tester.

Die Auswahl der Beteiligten erfolgt in erster Linie nach Fachwissen, nicht nach Unternehmenszugehörigkeit, je nach dem, über wie viel technisches und fachliches Know-how die beteiligten Unternehmen verfügen. Häufig führt dies dazu, dass auf Bestellerseite nur die Stakeholder agieren, und sämtliche anderen Positionen von Mitarbeitern des Entwicklers besetzt sind. Das andere Extrem ist die Übernahme fast aller Aufgaben durch den Besteller, der lediglich einige externe Programmierer in sein Team zu dessen Vervollständigung holt. Dazwischen sind alle möglichen Fallgestaltungen denkbar, etwa die Bereitstellung des Entwicklerteams durch den Entwickler, während der Product-Owner dem Unternehmen des Bestellers angehört.

Welche Funktionen die einzelnen Beteiligten haben, soll an dieser Stelle nicht näher behandelt werden. Begriffe wie „Product-Owner“ finden sich zwar mit ähnlicher Rollengestaltung in jedem agilen Softwareprojekt. Die genaue Stellung der Beteiligten und deren Aufgaben unterliegen jedoch keiner allgemeingültigen Definition, sondern bedürfen der einvernehmlichen Festlegung durch die Vertragsparteien. Denn es ist diese genaue Ausgestaltung, die letztendlich für die rechtliche Einordnung der Vertragsbestandteile verantwortlich ist.

So wird ein Vertrag, der die maßgeblichen Planungs- und Ausführungsleistungen dem Entwickler überlässt und für den Besteller nur Mitwirkungsleistungen vorsieht, regelmäßig als Werkvertrag einzustufen sein, mit allen damit verbundenen Folgen für Produktverantwortung und Gewährleistung. Je mehr Positionen allerdings mit Mitarbeitern des Bestellers besetzt sind, desto mehr verschwimmen die Verantwortlichkeiten für das Produkt, während dienstvertragliche Elemente an Gewicht gewinnen. Je mehr die Mitarbeiter des Entwicklers hierdurch den Weisungen des Bestellers unterworfen und in dessen Betriebsabläufe eingebunden werden, desto mehr nähert sich der Vertrag einem Arbeitnehmerüberlassungsvertrag an, der dann aber wieder den strengen Maßgaben des AÜG genügen muss; andernfalls drohen empfindliche Sanktionen für Besteller und Entwickler.

Die unklare Typisierung derartiger Verträge bietet darüber hinaus im Rahmen der Vertragsstörungsregelungen Risiken für beide Parteien. Ist der Vertrag im Einzelfall als Dienstvertrag zu bewerten, mangelt es an spezifischem Mängelgewährleistungsrecht, die gesetzlich vorgesehenen Schadensersatz- und insbesondere Rücktrittsrechte sind selten sachgerecht. Ebenso wenig passen die werkvertraglichen Abnahme- und Kündigungsregeln zum agilen Projekt. Kommt es zu Störungen, ist im Einzelfall sehr schwer zu ermitteln, welcher Partei welche Pflichten obliegen, ob sie gegen diese verstoßen hat, und welche Rechtsfolge daraus herzuleiten ist. Bei schlecht geplanten oder durchgeführten agilen Projekten bietet sich hier ein enormes Streitpotential.

In Teil 2 folgen

• Vergütung: Die Quadratur des Kreises
• Der häufigste Knackpunkt: Die Kommunikation bei der Durchführung
• Zusammenfassung

Das Team von MWW Rechtsanwälte berät Sie zu allen IT-rechtlichen, arbeitsrechtlichen und datenschutzrechtlichen Anliegen, setzen Sie sich gerne mit uns in Verbindung (Ansprechpartner: RA Johannes Zimmermann)!