Suche
Suche Menü

Agile Softwareentwicklung: Vertragsgestaltung und Praxistipps

Agile Softwareentwicklung und Recht

Agile Softwareentwicklung (z.B. nach Scrum oder Kanban) hat das statische Wasserfallmodell vielerorts abgelöst. Die Flexibilität agiler Projekte erfordert jedoch einen belastbaren vertraglichen Rahmen. Sonst sind rechtliche Konflikte zwischen Entwickler und Auftraggeber vorprogrammiert.

Klassische Programmierung nach dem Wasserfallmodell

Bei den klassischen Programmiermethoden zur Entwicklung einer Softwarelösung nach dem Wasserfallmodell ist das Projekt in aufeinanderfolgende Phasen organisiert.

Die Ergebnisse der einzelnen Phasen gehen – wie bei einem Wasserfall – immer als Vorgaben in die nächstfolgende Phase ein. Jede Aktivität muss vollständig durchgeführt werden, bevor die nächste beginnen darf. Rückschritte kann es nur zur unmittelbar vorangegangenen Phase geben.

Wasserfallmodell

Maciej Jaros (commons: Nux, wiki-pl: Nux), Wasserfallmodell, CC BY-SA 3.0

Charakteristisch für Programmierung nach dem Wasserfallmodell ist, dass die Beteiligung der Anwender nur in der Anforderungsanalysephase vorgesehen ist. Die Anforderungen an das Produkt werden schon vor Beginn der Entwicklung durch den Auftraggeber in einem sog. Lastenheft festgelegt. Im Lastenheft werden alle Anforderungen des Auftraggebers an die Lieferungen und Leistungen des Auftragnehmers festgehalten.

Nach oben

Agile Softwareentwicklung

Ändern sich die Anforderungen an das Softwareprojekt, können klassische Modelle meist nur träge reagieren. Rücksprünge und das erneute Durchlaufen von Projektphasen kosten Zeit und Geld. Gerade bei Neuentwicklungen sind unklare oder sich häufig ändernde Anforderungen aber eher die Regel als die Ausnahme.

Bei komplexen Entwicklungen geht man daher dazu über, die vorgeschaltete Planungsphase deutlich zu reduzieren und die Ziele erst im laufenden Prozess festzulegen. Die bekannteste dieser agilen Methoden heißt Scrum. Der Begriff Scrum ist angelehnt an das vom Schiedsrichter angeordnete Gedränge beim Rugby.

Die Entwicklungsarbeit beim Vorgehen nach Scrum erfolgt innerhalb sogenannter Sprints. Ein Sprint ist ein definierter Zeitraum, häufig z.B. zwei bis drei Wochen. In dieser Zeit erarbeitet das Team ein Produkt oder eine Teillösung. Die Aufgaben für einen Sprint stehen im sogenannten Sprint Backlog. Innerhalb eines Sprints können die Anforderungen nicht geändert werden. Das Sprint Backlog bildet zugleich die Grundlage für das tägliche Scrum Meeting. In diesem auch Daily Scrum genannten Meeting wird beschlossen, welche Sprint – Backlog Tasks als nächstes bearbeitet werden. Nach jedem Sprint werden dem Auftraggeber die Teilergebnisse als sog. Sprint Review präsentiert. Erkennt der Auftraggeber bei einem solchen Sprint Review, dass weitere Funktionen sein Projekt sinnvoll ergänzen würden, wird dieser neue Input in das Product Backlog aufgenommen. Im nächsten Sprint wird die Software dann um die neuen Anforderungen erweitert bzw. verändert.

Nach der Grundidee von Scrum sind drei verschiedene „Rollen“ auszufüllen:

  • Der Scrum Master übernimmt vor allem Koordinationsaufgaben. Er sorgt dafür, dass der Scrum Prozess eingehalten wird, löst Konflikte und moderiert die Scrum Meetings. Der Scrum Master hat in der Regel keine Weisungsbefugnis gegenüber den Teammitgliedern. Seine Rolle besteht vorwiegend darin, für optimale Arbeitsbedingungen und Abläufe im Scrum Team zu sorgen.
  • Der Product Owner ist der Produktverantwortliche. Er pflegt das Product Backlog, eine Liste, in der die Anforderungen an ein Produkt priorisiert dokumentiert werden. Darüber hinaus besetzt er die wichtigen Schnittstellen zu Stakeholdern und Management. Typischerweise gehört der Product Owner zum Lager der Auftragnehmerseite. Dies ist allerdings nicht zwingend. Es kann auch vereinbart werden, dass ein Mitarbeiter des Auftraggebers die Position des Product Owners ausfüllt.
  • Das Scrum Team sorgt dafür, dass die im Product Backlog niedergelegten Anforderungen erfüllt werden. Das Team organisiert sich selbst. Das heißt, es entscheidet selbstständig darüber, wie es die Anforderungen aus dem Backlog umsetzt.

Nach oben

Wann ist agiles Vorgehen (nach Scrum) sinnvoll?

Ein agiles Vorgehen ist kein Garant für eine erfolgreiche Zusammenarbeit zwischen Kunde und Programmierer. Vielmehr sollte von Projekt zu Projekt die Frage gestellt werden, welche Methode jeweils geeignet ist.

Ein agiles Vorgehen empfiehlt sich

  • wenn der Auftraggeber zunächst nur eine grobe Idee hat, die er schnell umsetzen möchte,
  • wenn der Auftraggeber bereit ist, das Projekt aktiv mitzugestalten,
  • wenn es sich um ein Projekt handelt, das in einem sich schnell wandelnden Umfeld eingesetzt werden soll,
  • wenn die technischen Kenntnisse des Auftraggebers eher gering sind und er bereits zur Definition der Anforderungen Hilfe bedarf.

Demgegenüber ist ein agiles Vorgehen weniger geeignet

  • bei Projekten, die eine hohe Planungssicherheit erfordern,
  • wenn der Auftraggeber technisch versiert ist und aufgrunddessen genaue Vorgaben machen kann, was das Endprodukt leisten soll,
  • bei einer nur unwahrscheinlichen Änderung der Umgebungsvariablen,
  • bei standardisierter Software.

Nicht übersehen werden darf, dass Scrum letztlich auch eine Philosophie ist, auf die man sich einlassen muss.

Nach oben

Vertragstyp: Werkvertrag, Dienstvertrag oder etwas anderes?

Gerade bei agilen Projekten, die sich durch Flexibilität in der Vorgehensweise auszeichnen, kann es zu Missverständnissen über die Rechte und Pflichten der Parteien kommen. Diesem Risiko sollte durch eine klare Vertragsgrundlage entgegengewirkt werden.

Es gibt keinen Vertragstyp, der pauschal auf alle Arten von agilen Projekten passt. In Betracht kommt sowohl Werkvertragsrecht, bei dem ein konkreter Erfolg geschuldet ist (= lauffähige Software), als auch Dienstvertragsrecht, bei dem die geschuldete Leistung in der Erbringung von Diensten liegt, ohne dass ein konkreter Erfolg geschuldet wird (= Programmieren).

Merke: Für die Abgrenzung von Dienst- und Werkvertrag ist der im Vertrag zum Ausdruck kommende Wille der Parteien maßgebend. Es kommt darauf an, ob auf dieser Grundlage eine Dienstleistung als solche oder als Arbeitsergebnis deren Erfolg geschuldet wird. Fehlt eine ausdrückliche Regelung, muss anhand der Umstände des Einzelfalls ermittelt werden, was Vertragsgegenstand ist; die vertragliche Beschreibung eines Ziels ist allein kein ausreichendes Indiz für die Annahme eines Werkvertrags (vgl. BGH, Urteil vom 16.07.2002, Az. X ZR 27/01).

Indizien pro Dienstvertrag

  • starke Einbindung des Auftraggebers im gesamten Prozess
  • keine klaren Vorgaben über die fertige Software
  • Weisungen durch den Auftraggeber im Verlauf der Entwicklung
  • Vertragsgegenstand (und damit Auslöser der Vergütungspflicht) ist die Programmierleistung, nicht die fertige Software

Indizien pro Werkvertrag

  • Einbindung des Auftraggebers hauptsächlich vor Start der Programmierarbeiten
  • Klare Darlegung des Vertragsgegenstandes, etwa in Lasten- bzw. Pflichtenheften
  • Vertragsgegenstand (und damit Auslöser der Vergütungspflicht) ist die Programmierleistung, nicht die fertige Software
  • Keine Weisungsbefugnis des Auftraggebers während des laufenden Projekts

Rechtsprechung zur Einordnung des Vertragstyps bei agilen Projekten ist bislang noch dünn gesät.

Eine Klage vor dem Landgericht Wiesbaden auf „Bezahlung“ eines Softwareprojekts (150.000 Euro) wurde abgewiesen, weil das Gericht den Scrum Vertrag als Werkvertrag einstufte. Da die bisher geleistete Arbeit für den Auftraggeber unbrauchbar war, schuldete er aus Sicht des Gerichts keinen Werklohn (LG Wiesbaden, Urteil vom 30.11.2016, Az. 11 O 10/15).

Das OLG Frankfurt hob die Entscheidung in der Berufungsinstanz auf und sprach die Vergütung zu (OLG Frankfurt, Urteil vom 17.08.2017, Az. 5 U 152/16). Ob Werk- oder Dienstvertragsrecht anzuwenden sei, ließ das Gericht offen. Die Vergütung sei in jedem Fall geschuldet gewesen, weil die Parteien im Laufe des Projekts einen Ratenzahlungsvertrag geschlossen hatten. Daraus folgerte das Oberlandesgericht, dass sich die Parteien zumindest zu diesem Zeitpunkt einig waren, dass die bis dahin erbrachten Programmierleistungen vom Auftraggeber als grundsätzlich vertragsgemäß und der Zahlungsanspruch als fällig anerkannt worden waren.

Obwohl das Oberlandesgericht in seinem Urteil ausführlich zur Anwendung von Werkvertragsrecht bei Scrum Stellung nimmt, lassen sich aus der Entscheidung nur bedingt allgemeine Rückschlüsse ableiten. Hiervor warnt auch Rechtsanwalt Christian Welkenbach in CR 2017, 639 ff. „Scrum auf dem Prüfstand der Rechtsprechung – Lehren für die Vertragsgestaltung“.

Das Gericht lässt nämlich offen, ob Werk- oder Dienstvertragsrecht anzuwenden ist. Vielmehr stellt es fest, dass im verhandelten Fall sowohl die Anwendung von Dienst- als auch die Anwendung von Werkvertragsrecht zu einer Vergütungspflicht führt. Zweitens gab es im Prozess die Besonderheit einer Ratenzahlungsvereinbarung im Verlauf der Zusammenarbeit, auf die das Gericht ebenfalls wesentliche Teile seines Ergebnisses stützt. Drittens war das Projekt noch nicht abgeschlossen, so dass sich das Gericht nur dazu äußerte, was im Zeitpunkt des Projektabbruchs geschuldet war, nicht aber, wie die am Ende vertragsgemäße Leistung ausgesehen hätte.

Festgehalten werden kann aber, dass das Gericht in dem Umstand, dass bei Scrum noch nicht von vornherein feststeht, wie das das Endprodukt auszusehen hat, kein Hindernis für die Annahme von Werkvertragsrecht sieht. Insoweit komme es auch in Betracht (deutlicher wird das Gericht leider nicht), in der jeweiligen Fortführung des Projekts nach den sprint reviews und den damit einhergehenden Zahlungen eine Abnahme des bisher Geleisteten – und nicht lediglich eine Abschlagszahlung – zu sehen.

Zweitens berücksichtigte das Gericht die agile Methodik auch bei der Frage der geschuldeten Dokumentationspflichten: Hinsichtlich der Systemarchitektur und ihrer Komponenten sah das Gericht eine Dokumentation, deren Brauchbarkeit von der Beratung des früheren Entwicklerteams abhängt, als hinreichend an. Begründet wurde dies damit, dass das Projekt zum Zeitpunkt des Abbruchs auf weitere Kooperation, insbesondere weitere Beratung durch den Auftragnehmer ausgelegt war. Entsprechend habe die zu diesem Zeitpunkt geleistete Dokumentation der Systemarchitektur und der Komponenten dem vertraglich Geschuldeten entsprochen.

Hinsichtlich des Quellcodes sah das Gericht in dem Umstand, dass dieser zwar „durchweg […] wenn auch […] nur sehr rudimentär […] und fachlich nicht überall als ausreichend zum Verständnis“ kommentiert war, keinen erheblichen Mangel.

Diese beiden Punkte zeigen, dass den Parteien bei der Ausgestaltung und praktischen Umsetzung des Softwareprojekts viele Freiheiten bleiben. Die Kehrseite dieser Freiheiten liegt darin, dass vertraglich fixiert werden muss, wie das Softwareprojekt gelebt werden soll. Andernfalls besteht die Gefahr, dass ein Gericht die Lücken füllt und es dabei zu Überraschungen kommt.

Nach oben

Tipps zur Vertragsgestaltung

Die folgenden Tipps und Formulierungsvorschläge erheben keinen Anspruch auf Vollständigkeit. Die Vertragsgestaltung bedarf stets einer auf den Einzelfall und die Bedürfnisse der Parteien angepassten Lösung.

Bei Beginn eines agilen Projekts ist der Leistungsgegenstand nicht konkret festgelegt. Zu diesem Zeitpunkt existiert meist nur eine Vision, die noch nicht die gesamten Anforderungen des Produkts umfasst. Eine Festlegung von bestimmten Meilensteinen, Teilergebnissen oder sogar der Software im Ganzen wäre mit den Grundsätzen agiler Entwicklung demnach nicht vereinbar. Allerdings können gewisse Punkte vorab in einem Rahmenvertrag festgelegt werden.

Oft wird dazu geraten, im ersten Schritt einen Rahmenvertrag abzuschließen, der die dienstvertraglichen Elemente der Zusammenarbeit umfasst. Daneben sollen die einzelnen Sprints als Teilprojektverträge den werkvertraglichen Teil erfassen. Das ist ein guter Ansatz, aber keine Garantie dafür, dass Unklarheiten ausgeschlossen sind: Im oben geschilderten Fall vor dem OLG Frankfurt (der vollständige Vertragstext konnte den Urteilen nicht entnommen werden) war eine zweigliedrige Vertragskonstellation aus Letter of Intent und Projektentwicklungsvertrag zumindest beabsichtigt. Angesichts dessen ist es – trotz der Scrum-üblichen Verschlankung der Planungsphase – unumgänglich, die vertraglichen Verhältnisse im Vorfeld zu klären.

Diese Notwendigkeit wird noch deutlicher, wenn man sich vor Augen führt, dass die BGB-Regelungen im B2B-Bereich größtenteils nicht zwingend sind. Die Parteien können den Leistungsgegenstand und die Folgen von Leistungsstörungen auch abweichend von den Vorgaben des BGB regeln. Das insoweit wohl bekannteste Beispiel ist die Möglichkeit zum Ausschluss von Gewährleistungsrechten: Im Streitfall wendet ein Gericht die gesetzlich vorgesehenen Normen nicht an, weil es die Parteien so vereinbart haben. Genauso können sich die Parteien auch im Rahmen eines Softwareprojektvertrags auf etwas einigen, das nicht den im BGB vorgesehenen Vertragstypen entspricht. Anders ausgedrückt: Das Gericht stellt sich nur dann die Frage, ob es Dienst- oder Werkvertragsrecht anwenden soll, wenn der Vertrag zu einem bestimmten Punkt keine ausdrückliche Regelung enthält. Dabei ist selbstverständlich zu beachten, dass kaum jede Eventualität berücksichtigt werden kann. Man kann Unsicherheiten regelmäßig nur minimieren, aber nicht ausschließen.

Nach oben

Nachfolgend finden Sie eine Reihe von Tipps zur Vertragsgestaltung:

1. Vertragsgegenstand und Vorgehensmodell

Da verschiedene agile Vorgehensweisen existieren und die Parteien möglicherweise unterschiedliche begriffliche Vorstellungen haben, sollte das geplante Vorgehen zunächst so konkret wie möglich beschrieben werden.

Beschreiben Sie in einer Präambel neben der zur Anwendung kommenden agilen Methode (z.B. Scrum oder Kanban) auch die im Vertrag verwendeten Fachbegriffe und definieren Sie die Rollen.

Wie bereits erwähnt sind die Anforderungen an die zu schaffende Software bei Vertragsschluss typischerweise noch nicht konkret festgelegt. Meist besteht nur eine Vision, die dann gleichzeitig die einzige Beschreibung des Leistungsgegenstandes darstellt. Aus der Vision lassen sich wiederum Rückschlüsse ziehen, welche Ziele die Parteien mit dem Vertrag verfolgen.

Halten Sie die Vision so konkret wie möglich im Vertrag fest. Falls bereits zu Beginn des Projekts klar ist, dass die spätere Software bestimmte Anforderungen unbedingt einhalten muss (bspw. Daten- oder Jugendschutz), sollte dies ebenfalls festgehalten werden.

Zur grundsätzlichen Einordnung des Vertrages ist es hilfreich, das grundsätzlich gewählte Risikomodell (Werkvertrag/Dienstvertrag) festzuhalten. Dabei ist jedoch nicht zu unterschätzen, dass die Mitwirkung des Auftraggebers auch immer zu mehr eigener Verantwortung für den Erfolg des Projekts führt (s. auch Conrad/Schneider, in: Auer-Reinsdorff/Conrad, Handbuch IT- und Datenschutzrecht, § 11 Rn. 4). Je weiter sich der Vertrag vom klassischen Modell entfernt (= Planung durch den Auftraggeber, Durchführung durch den Auftragnehmer), desto unsicherer wird die Prognose, wie Vertragsverletzungen im Streitfall von einem Gericht beurteilt werden.

Beschreiben Sie, ob der Auftragnehmer den Entwicklungsprozess in eigener Verantwortung organisiert oder ob der Auftraggeber in der Hauptverantwortung ist.

Halten Sie im Vertrag fest, welche Anforderungen an die Parteien in welcher Phase zu stellen sind. Dabei sollte die Dauer der jeweiligen Sprints sowie der Turnus der Meetings festgehalten werden.

Definieren Sie im Vertrag die Dauer der Sprints und die angestrebten Termine bzw. den Turnus der sprint planning meetings und sprint reviews.

Nach oben

2. Mitwirkungspflichten des Auftraggebers

Die vertraglich festgehaltene Einbindung des Auftraggebers in den Entwicklungsprozess kann für beide Seiten Vorteile bringen: Durch die Teilnahme an den sprint reviews sind alle Beteiligten über die Vorstellungen und Wünsche des Auftraggebers im Bilde. So können Missverständnisse – und damit unnötige Arbeit – vermieden werden. Es muss aber auch geklärt werden, was passiert, wenn es nicht mehr „rund“ läuft.

Einigen Sie über die Rolle des Auftraggebers, insbesondere darüber, ob er den Product Owner stellt oder der Auftragnehmer. Weiter muss Klarheit bestehen, an welchen Meetings der Auftraggeber teilzunehmen hat und worin seine Mitwirkungspflichten bestehen. Formulieren Sie auch die Folgen der Verletzung von Mitwirkungspflichten.

Nach oben

3. Dokumentationspflichten

In den oben vorgestellten Urteilen spielte auch die Dokumentation eine wesentliche Rolle. Diese kann bei werkvertraglicher Einordnung des Projekts darüber entscheiden, ob die gelieferte Software dem Geschuldeten entspricht.

Einigen Sie sich, in welcher Form eine Dokumentation erfolgen soll und halten Sie dies auch im Einzelnen im Vertrag fest.

Nach oben

4. Vergütung / Preise

Besonders relevant und streitträchtig sind die Vergütungsregelungen. Für den Auftragnehmer ist es von Vorteil, eine Vergütung nach Aufwand und Zeit zu vereinbaren (z.B. einen Einheitspreis pro Person/Tag). Damit kann er sicherstellen, dass er nicht unbezahlt arbeitet. Demgegenüber hat der Auftraggebers ein Interesse daran, die Kosten überschaubar, wenigstens aber planbar zu halten. Zwischen diesen beiden Polen liegt der objektiv faire Preis. Diesen wird man in den seltensten Fällen genau treffen. Auch lässt sich kaum pauschal zu einem Modell raten. Eine langfristig gute – und nicht nur einmalige – Zusammenarbeit wird jedoch wahrscheinlicher, je näher man sich einem fairen Preis nähert. Sinnvoll kann es deshalb sein, ein Vorgehen zu wählen, bei dem nach der Erbringung einer brauchbaren Teilleistung jeweils ein Teilbetrag gezahlt wird.

Halten Sie fest, inwieweit sich das Projekt sinnvoll aufteilen lässt und schätzen Sie gemeinsam ab, wie die Vergütung der jeweiligen Teile aussehen soll. Dabei können auch verschiedene Modelle nebeneinander zum Einsatz kommen.

Falls Sie Scrum dahingehend anwenden, dass Sie einen agilen Festpreis vereinbaren, halten Sie auch insoweit die Modalitäten fest.

Nach oben

4. Kündigungsmöglichkeiten

Das Scrum Modell erfordert großes gegenseitiges Vertrauen, das in der Anfangsphase vor allem vom Auftraggeber und später eher vom Auftragnehmer aufzubringen ist. Daher sollten Möglichkeiten zur Loslösung vom Projekt in den Vertrag integriert werden.

Beispielsweise könnte ein Kündigungsrecht zum Ende jedes Sprints vereinbart werden. Das empfiehlt sich besonders, wenn die einzelnen Sprints gesondert vergütet werden und für jeden Sprint eine fest umrissene, eigenständig brauchbare Leistung vereinbart wird. Dies ermöglicht eine gewisse Kostenkontrolle. Gleichzeitig kann im Falle einer unergiebigen Zusammenarbeit das „Schrecken ohne Ende“ vermieden werden, dem sich möglicherweise noch ein Rechtsstreit anschließen würde.

Ein Kündigungsrecht wird angesichts der anfänglichen Ungewissheiten unumgänglich sein. Dabei muss insbesondere geklärt werden, inwieweit das bisher Geleistete auch geeignet sein muss, von anderen Auftragnehmern weiter bearbeitet zu werden. Das Kündigungsrecht sollte daher – auch wenn dies bei Scrum unüblich ist – mit Dokumentationspflichten einhergehen.

Praxistipp: Vor allem bei größeren Projekten (ab einem Vertragswert von 50.000 Euro) sollte eine sog. Escrow Klausel in den Rahmenvertrag aufgenommen werden, die die Hinterlegung des Quellcodes bei einem Escrow – Agenten vorsieht. In Ausnahmefällen wie z.B. der Insolvenz des Auftragnehmers lässt sich so sicherstellen, dass die Weiterentwicklung bzw. Fertigstellung des Projekts durch einen anderen Auftragnehmer erfolgen kann.

Nach oben

5. Abnahme und Gewährleistung

Soweit Sie den Vertrag so ausgestalten, dass die einzelnen Sprints Werkvertragsrecht unterliegen, ist festzuhalten, an welchen Punkten (Teil-)Abnahmen erfolgen sollen. Es ist naheliegend (aber nicht zwingend), dass diese in den sprint reviews erfolgen.

Halten Sie im Vertrag fest, in welcher Form die Absprachen der sprint planning meetings und sprint reviews protokolliert werden. Definieren Sie, welche Wirkungen die Protokolle und Änderungen des product backlog haben. Insbesondere sollte geregelt werden, ob darin die Genehmigung des bisher geleisteten bzw. ein Vorbehalt der Abnahme zu sehen ist und wie die Endabnahme erfolgt. Regeln Sie auch, ob in dem Beginn der Nutzung (von Teilen) der Software eine Abnahme liegt.

Nach oben

6. Nutzungsrechte

Uneinigkeiten ergeben sich häufig auch bei der Frage der Nutzungsrechte: Während der Auftragnehmer oft davon ausgeht, dass er stets nur einfache Nutzungsrechte überträgt, da er das Programm geschrieben hat, ist der Auftraggeber der Auffassung, ausschließliche Nutzungsrechte erworben zu haben, da es sich um eine von ihm bezahlte Auftragsarbeit handelt. Problematisch wird dies spätestens dann, wenn der Auftraggeber Unterlizenzen erteilen oder der Auftragnehmer das Programm anderweitig vermarkten möchte.

Fehlt es an einer Absprache, richtet sich die Rechteeinräumung nach § 31 Abs. 5 UrhG (sog. Zweckübertragungslehre). Danach werden Nutzungsrechte nur insoweit eingeräumt, als es zur Erfüllung des Vertrages erforderlich ist. Praktisch wird der Streit damit jedoch nicht gelöst, sondern auf die Frage verlagert, welche Rechteübertragung zur Erfüllung des Vertrages erforderlich ist. Dabei ist zwar regelmäßig davon auszugehen, dass bei vereinbarter individueller Nutzung einfache, bei vereinbarter Weitervermarktung ausschließliche Rechte eingeräumt werden; im Einzelfall haben Gerichte aber auch schon hiervor abweichende Entscheidungen getroffen (Grützmacher, in: Wandte/Bullinger, PK-UrhR, § 69a UrhG, Rn. 64).

Vereinbaren Sie detailliert, zu welchem Zweck die Software erworben wird und welche Nutzungs- und Verwertungsrechte dem Auftraggeber an der Software und ggf. sonstigen Leistungen zu welchem Zeitpunkt übertragen werden.

Nach oben

7. Vertragsgestaltung bei anderen agilen Methoden

Neben Scrum existieren noch weitere agile Entwicklungsmethoden wie Kanban, Crystal, XP oder RAD, deren Ansätze sich teilweise ähneln. Bei diesen Methoden ist es ebenfalls kaum möglich, pauschale Vorlagen zu entwickeln. Die obigen Punkte sollten dabei aber ebenfalls berücksichtigt werden. Auch wenn sich agile Methoden gerade dadurch auszeichnen, sich auf das Wesentliche, die Softwareentwicklung zu konzentrieren und möglichst unbürokratisch zu sein: Sobald im Streitfalle Juristen mit der Sache befasst sind, werden sie versuchen, das was sie vor sich haben, in ein ihnen bekanntes Schema einzuordnen, was für beide Seiten das Potenzial unangenehmer Überraschungen birgt. Das einzige Gegenmittel sind möglichst klare Absprachen zu allen wesentlichen Punkten.

Benötigen Sie rechtliche Unterstützung bei der Begleitung eines agilen Softwareprojekts? Nutzen Sie unsere kostenlose und unverbindliche Ersteinschätzung.

Nach oben

An diesem Beitrag hat unsere wissenschaftliche Hilfskraft Frau Lisa Marie Uhe mitgewirkt.

Autor:

Oliver Wolf, LL.M. ist angestellter Rechtsanwalt der Kanzlei Plutte.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.


Kostenlose Ersteinschätzung