Rechtliche Fragestellungen bei Scrum

Wie so oft im Bereich des IT-Rechts kann dieGesetzgebung und Rechtsprechung nicht mit den sich rasch änderndenAnforderungen der Praxis mithalten.  Diesgilt auch für Fragestellungen im Bereich der agilen Softwarenentwicklung. Invielerlei Hinsicht von hoher Relevanz ist zunächst die vertragstypologischeEinordnung von Scrum-Projektverträgen. Rechtlich ist fast alles offen; schon die Einordnung als Dienstvertragoder Werkvertrag ist nicht eindeutig. Die Frage nach dem Vertragstyp istzentral, aber ungelöst. Herrschende Meinung dürfte sein, den Vertrag insgesamtals Dienstvertrag einzuordnen, die einzelnen Sprints aber am Werkvertragsrechtzu messen.

Je innovativer, flexibler und stärker vom Kundengesteuert die Projektmethodik ist, umso weniger passt jedoch dasWerkvertragsrecht. Jedenfalls aus Sicht des Auftragnehmers wird sich dasDienstvertragsrecht deutlich besser als Vertragsgrundlage eignen als dasWerkvertragsrecht. Agiles Programmieren dem Dienstvertragsrecht unterzuordnenkann aus rechtlicher Sicht naheliegend sein, wenn die vorliegendeRisikoverteilung aus auf Seiten des Auftraggebers liegenden Gründen deutlich zuLasten des Auftragnehmers geht.  Jeweniger zu Beginn des Projekts feststeht, was eigentlich genau geschuldet ist,umso stärkere Zweifel ergeben sich daran, ob es sich um eine genügendeErfolgsorientierung handelt, um den Vertrag noch als Werkvertrag zuqualifizieren.

Unabhängig von der konkreten typologischen Einordnungmuss den Parteien bewusst sein, dass ein erfolgsversprechender Verlauf desProjekts nur dann gewährleistet sein kann, wenn konkrete prozedurale Regelungengetroffen werden. Es bleibt dann zwar noch immer offen, „was“ letztendlich dasErgebnis der Arbeit werden wird, „wie“ das Projekt durchgeführt werden soll,ist jedoch von Anfang an eindeutig festgelegt.

Neben Aspekten der Datensicherheit und von Privacy byDesign ergeben sich bei Scrum auch datenschutzrechtliche Fragestellungen.Hier insbesondere, ob die Zusammenarbeit zwischen den Vertragsparteien einJoint-Controllership-Verhältnis (im Sinne des Art 26 DSGVO) oderAuftragsverarbeiter-Verhältnis (im Sinne des Art 28 DSGVO) begründet.  Diese Frage stellt sich freilich nur dann,wenn personenbezogene Daten im Sinne des Art 4 Z 1 DSGVO verarbeitet werden unddamit der Anwendungsbereich der DSGVO eröffnet ist. Unter Umständen erfolgendatenschutzrechtlich problematische Tests im Echt-/Produktivbetrieb, also mitEchtdaten.  Regelmäßig wird es spätestensim Rahmen der Testphase mitunter vorkommen, dass personenbezogene Mitarbeiter-oder Kundendaten eingesetzt werden. Je intensiver der Kooperationsgrad, destoweniger wird sich vermeiden lassen, dass personenbezogene Daten ausgetauschtwerden.

Die entscheidende Determinante hinsichtlich derBeurteilung, ob ein Auftragsverarbeiter- oder Joint-Controllership-Verhältnisvorliegt, dürfte auch bei Scrum in der Ausgestaltung des Weisungsrechtesgelegen sein. Nachdem der Auftraggeber der Initiator des jeweiligen Projektesist und Daten daher „in seinem Auftrag“ verarbeitet werden, sprechen diebesseren Argumente dafür, in diesen Konstellationen einAuftragsverarbeiter-Verhältnis anzunehmen. Schließlich hat es der Auftraggeberals Business Owner in der Hand, das Projekt zu initiieren, zu ändern oderabzubrechen. Wenn jedoch der Auftragnehmer auch über das konkrete Projekthinaus an der erstellten Software, etwa im Wege einer Standardsoftware,wirtschaftlich partizipieren soll, spricht dies eher für einJoint-Controllership-Verhältnis. In diesen Fällen wird nämlich ein gemeinsamerZweck verfolgt. Schließlich ist auch denkbar, dass sowohl einAuftragsverarbeiter- als auch Joint-Controllership-Verhältnis vorliegt.

Die enge Kooperation zwischen den Vertragsparteienbedingt schließlich die „Gefahr“, bewusst oder unbewusst ein Verhältnis derScheinselbstständigkeit oder aber Arbeitskräfteüberlassung zu begründen. Jeintensiver die Zusammenarbeit der Teams beider Vertragspartner erfolgt, destogrößer werden die arbeitsrechtlichen Probleme.  

Weiters ist zu beachten, dass im Falle einergemeinschaftlichen, unternehmerischen Zweckverfolgung die Möglichkeit besteht,eine Gesellschaft bürgerlichen Rechtes im Sinne des §§ 1175 ff ABGB zubegründen. Um keine diesbezüglichen ungewollten Rechtsfolgen auszulösen,empfiehlt es sich vertraglich, vor allem aber operativ,  entsprechende Vorkehrungen zu treffen.

Abschließend ist festzuhalten, dass die Gestaltungeines agilen Projektvertrages eine hohe Komplexität aufweist. Einerseitskonterkariert ein zu detailliertes Vertragswerk einen flexiblen und agilenEntwicklungsprozess. Andererseits sind Unklarheiten in Bezug auf dieAnsprechpersonen, Kompetenzen, Verwertungsrechte, Abläufe im Projektmanagement,Mitwirkungspflichten und die finanzielle Abgeltung in Kombination mit einemhohen Erfolgsdruck der Stoff, aus dem (Gerichts-)Streitigkeiten gemacht sind.Gefragt ist daher ein – auf den konkreten Sachverhalt angepasstes – Vertragswerk,das den Entwicklungsprozess wie Leitplanken lenkt und im Rahmen hält. Dabeimuss der Jurist darauf achten, dass er das Projekt nicht „übersteuert“.  Mindestens genauso wichtig ist dieAntizipation möglicher Konfliktpunkte und deren anschließende offeneAussprache, dies ganz im Sinne der Grundprinzipien von Scrum: Mut, Respekt,Commitment, Offenheit und Fokus.

Zum Autor:

Dr. Tobias Tretzmüller, LLM, B.A. ist Rechtsanwalt mitFokus auf den Bereich des Softwarerechts. Er ist auf IT-Vertragsgestaltung,IT-Streitigkeiten, E-Commerce, Markenrecht, neue Technologien (Blockchain, KI)sowie Datenschutzrecht spezialisiert. Umfassende Lehr- und Vortragstätigkeitensowie Publikationen in einschlägigen Medien.

‍