Das Thema
Egal ob Scrum, Kanban oder Crystal – kaum noch eine Software wird heutzutage klassisch entlang der Wasserfall-Methodik entwickelt. Vielmehr entwickeln Auftraggeber und IT-Dienstleister iterativ die Software nach den Bedürfnissen der Stakeholder. Diese Art der Zusammenarbeit – basierend auf dem „Manifesto for Agile Software Development“ – hat die Softwareentwicklung grundlegend geprägt.
Allerdings birgt diese Art der Zusammenarbeit aus (arbeits-)rechtlicher Sicht einige Risiken. Spätestens mit der Änderung des Arbeitnehmerüberlassungsgesetzes (AÜG) im April 2017 wurden die Sanktionen für den Fall einer falschen rechtlichen Einordnung (Stichwort „Scheinselbständigkeit“ oder „Scheindienst-/Scheinwerkvertrag“) erheblich verschärft. So drohen dem Auftraggeber bei Nichteinhaltung der „Spielregeln“, dass Arbeitsverhältnisse mit den Mitarbeitern des IT-Dienstleisters oder Freelancern fingiert werden, die Nachzahlung von Sozialversicherungsbeiträgen sowie Bußgelder und (bei Vorsatz) sogar strafrechtliche Konsequenzen.
Die Leistung ist das „A und O“
In der Praxis finden sich statt einer konkreten Leistungsbeschreibung häufig nur allgemeine Klauseln, wonach der Auftragnehmer „bei der Softwareentwicklung unterstützt“. Dabei kommt der Leistungsbeschreibung erhebliche Bedeutung zu:
- Zum einen für die Frage, ob es sich um einen Dienst- oder Werkvertrag handelt und zur Bestimmung des Haftungsrisikos für die Parteien, so auch der Bundesgerichtshof (VII ZR 203/17).
- Zum anderen dient die Leistungsbeschreibung als Abgrenzungskriterium zur (verdeckten) Arbeitnehmerüberlassung. Letzteres ist durch die reine Personalgestellung gekennzeichnet, während Basis eines Dienst- oder Werkvertrages die Vereinbarung einer konkret zu erbringenden Leistung ist.
Die Konkretisierung der Leistung bereitet bei der agilen Softwareentwicklung jedoch große Schwierigkeiten, da die zu entwickelnden Funktionalitäten der Software zum Zeitpunkt des Vertragsschlusses noch nicht bekannt sind.
Rahmenvertrag und Einzelvertrag als Ausweg?
Ein Ausweg aus diesem „Dilemma“ kann sein, in einem Rahmenvertrag die Leistung zunächst generisch zu beschreiben. Was für eine Software soll entwickelt werden und wer definiert/setzt die zu entwickelnden Softwarefunktionaltäten um? Hierbei sind nicht nur die einzelnen Phasen der Softwareentwicklung (z.B. Ramp-up, Initalphase, Iterationsplanung, Refinement) zu beschreiben, sondern auch die Rollen der einzelnen Beteiligten („Was ist die Aufgabe des Agile Master?“; „Gibt es einen Site Reliability Engineer?“).
Sodann ist im Wege von Einzelverträgen die Leistung zu präzisieren. Zum Beispiel ist ein Set an User Stories festzulegen, das vom Software Engineer zu entwickeln ist. Hierbei ist darauf zu achten, das Set nicht zu kleinteilig und ein abgrenzbares Arbeitspaket bildet, da dies andererseits ein Indiz für eine verdeckte Arbeitnehmerüberlassung (oder Scheinselbständigkeit) sein kann.
Diese arbeitsrechtlich notwendige Vorgehensweise führt in der Praxis zu erheblichem Unverständnis und wird als extreme Beschränkung der Agilität empfunden. Diese Kritik ist nicht von der Hand zu weisen. Der Gesetzgeber benachteiligt die deutsche IT-Branche hierdurch erheblich. Appelle, die IT-Branche vom Anwendungsbereich des AÜG auszunehmen, blieben bislang ohne Erfolg. Im Gegenteil, die Behörden prüfen aktuell verstärkt die IT-Branche.
Keine Eingliederung in die Arbeitsorganisation
Während der Vertragsdurchführung ist darauf zu achten, dass es nicht zu einer Eingliederung der Mitarbeiter des IT-Dienstleisters oder der Freelancer in die Arbeitsorganisation des Auftraggebers kommt. Schwierigkeiten bereiten hierbei vor allem die Konstellationen, in denen der Auftraggeber – oft zum Zwecke des Know-How-Transfers – gemischte Teams bilden möchte. Dies birgt das erhebliche Risiko einer „Hand-in-Hand“-Zusammenarbeit und damit einer Eingliederung in die Arbeitsorganisation des Auftraggebers.
Wichtig ist, dass auch in der Rückschau der Leistungsbeitrag des seitens des IT-Dienstleisters eingesetzten Entwicklungsteams eigenständig erbracht und abgrenzbar von den Leistungen der Auftraggeber-Mitarbeiter ist.
Keine Weisungsbefugnis
Der Auftraggeber darf gegenüber den Mitarbeitern des IT-Dienstleisters keine arbeitsrechtlichen Weisungen (bezüglich Arbeitsort, Arbeitszeit und Art und Weise der Tätigkeit) erteilen.
Projektbezogene Weisungen, die sich etwa auf bestimmte Qualitätsanforderungen oder andere mit der Erfüllung der Leistung in Zusammenhang stehende Aspekte beziehen, sind hingegen möglich.
Exkurs: Nutzungsrechte
Neben der Haftung und der arbeitsrechtlichen Compliance stellt sich häufig noch die Frage, in welchem Umfang Nutzungsrechte dem Auftraggeber eingeräumt werden können. Hier ist zu differenzieren:
Soweit der IT-Dienstleister Teile der Software individuell für den Auftraggeber erstellt, können die Nutzungsrechte dem Auftraggeber nicht nur zeitlich, räumlich und inhaltlich unbeschränkt, sondern auch ausschließlich eingeräumt werden. Fügt der IT-Dienstleister auch Standardkomponenten ein, z.B. Standardbibliotheken oder Tools, muss er darauf achten, dass er dem Auftraggeber nur „nicht ausschließliche“ Nutzungsrechte überträgt. Des Weiteren werden regelmäßig auch Open Source Komponenten verwendet. Hier ist mit dem Auftraggeber abzustimmen, welche Open Source Komponenten im Hinblick auf die spätere Nutzung verwendet werden dürfen.
Vor allem ist aber darauf zu achten, dass keine Open Source Komponenten genutzt werden, welche dazu führen, dass die gesamte Software als Open Source angeboten oder der Source Code offengelegt werden muss (sog. „Copy Left-“ oder „viraler Effekt“).
Es bleibt dabei: Die Vertragswirklichkeit zählt
Bei der agilen Softwareentwicklung ist auf eine klare Aufgabenabgrenzung und strikte Einhaltung der „Spielregeln“ zu achten. Wenn dies der Fall ist, kann ein agiles Projekt rechtskonform umgesetzt werden.
Wichtig ist jedoch, dass nicht nur der Vertrag „schön“ geschrieben ist, sondern auch in der Vertragswirklichkeit gelebt wird.
