201731.01.

Beitragsreihe: Verträge für agile Softwareprojekte – Unsere Empfehlung: Agile “Time and Materials”-Projekte

Vertragliche Regelungen bei agilen Time and Material Projekten

Teil IV – Unsere Empfehlung: Agile “Time and Material”-Projekte


Die Beitragsreihe “Verträge für agile Softwareprojekte” setzt sich mit den schuld- und urheberrechtlichen Aspekten der agilen Softwareentwicklung auseinander. Unter der Prämisse, dass agile Verträge als Lösungsansatz auch für deutsche Unternehmen zunehmend Relevanz erlangen, diese Thematik bisher jedoch nur rudimentär aufgearbeitet wurde, wird anhand von Rechtsprechung und Literatur die gegenwärtige Rechtslage veranschaulicht. Schlussendlich werden Empfehlungen zu vertraglichen Regelungen ausgesprochen, die sich mit Blick auf die Vielzahl von Problemen und Risiken ergeben, die bei agilen Softwareentwicklungsprojekten zu erwarten sind.

Zurück zu Teil III: Konventionelle Vertragsmodelle

Agile Time and Materials-Projekte

Unsere Empfehlung für agile Projekte ist der Dienstvertrag mit definierten Prozessen und Sollbruchstellen. Die Risikoverschiebung des konventionellen Dienstvertrags zu Lasten des Auftraggebers wird durch dieses Konzept mit entsprechenden vertraglichen Regelungen aufgefangen. Diese Regelungen bieten bessere Kontroll- und Steuerungsmöglichkeiten, ermöglichen die frühzeitige Erkennung und effektive Lösung von Problemen, versprechen die vollständige Ausnutzung von Verbesserungs- und Einsparpotentialen und halten im Zweifel Sicherheitsmaßnahmen bereit, um durch Sollbruchstellen und ein geordnetes Exit Management eine einvernehmliche Trennung in beiderseitigem Interesse zu ermöglichen.

Die vertraglichen Regelungen sollten zuvorderst der klaren Definition der Arbeitsprozesse gelten. Die agile Softwareentwicklung am Beispiel des Scrum hat in der Praxis Arbeitsschritte entwickelt, die sich als produktiv erwiesen haben.[1] So empfiehlt es sich, Sprint Planning, Daily Scrum, Sprint Review, Sprint-Retrospective und Backlog Planning & Refinement als fortlaufendende Prozesse, bei denen sich Product Owner und Dienstleister oder das Entwicklerteam untereinander über die konkrete Gestaltung des Produkts austauschen und eine Bewertung der eigenen Leistungen und des derzeitigen Standes des Produkts vornehmen, als vertragliche Verpflichtung vorzusehen.

Scrum Prozesse

Scrum Prozesse


Im Vertrag sollte auch die Rolle des Product Owners als Vertreter des Auftraggebers geregelt werden.[2] Dem Product Owner sollten im Vertrag Entscheidungsbefugnisse übertragen werden, aus der sich seine Verantwortung für das Projekt ableiten lässt. Seine Verfügbarkeit sollte ebenso vertraglichen Regelungen unterliegen wie der Einsatz eines Proxy Product Owners[3] und Rechtsfolgen von Verzögerungen auf Seiten des Product Owners.

Die Rolle des Product Owners

Die Rolle des Product Owners


Die personelle Konsistenz des Entwicklerteams ist ein weiteres wichtiges Anliegen. Jegliche persönliche Änderung geht mit einem Verlust von spezifischem Wissen oder der notwendigen Einarbeitung eines neuen Mitglieds einher. Da sich dies stets negativ auf die Projektkosten und -dauer auswirkt, sollte ein definierter Anteil des Teams gleich bleiben müssen. Gleichwohl sollte ein Verfahren vorgesehen werden, um besonders wichtige Teammitglieder bei ihrem Ausscheiden aus dem Team mit vergleichbar qualifizierten Mitarbeitern zu ersetzen. Dies erlaubt es dem Auftraggeber, trotz der Beauftragung eines externen Dienstleisters, weitgehend die Kontrolle über die Zusammensetzung des Entwicklerteams zu behalten und die Erfolgswahrscheinlichkeit des Projekts zu erhöhen.

Exit Management

Durch ein Exit Management im Vertrag soll der Auftraggeber in die Lage versetzt werden, bei vorzeitigem Abbruch des Projekts mit dem bisherigen Dienstleister, also im worst case scenario, ohne Übergabe-Problematik möglichst nahtlos einen neuen Dienstleister beauftragen zu können. Dies erfordert Sollbruchstellen im Projekt, die bei übermäßiger Belastung der Geschäftsbeziehung oder einem sich abzeichnenden Misserfolg ein einvernehmliches Loslösen vom Vertrag erlauben. In diesem Zusammenhang sollten auch die Kündigungsfristen so bestimmt werden, dass beide Parteien genug Zeit für Abschlussvorbereitungen erhalten, um beispielsweise die Dokumentation vervollständigt übergeben zu können. Besonders bei Festpreismodellen ist eine Übergaberegelung hinsichtlich der bereits geleisteten Arbeitsleistung vorzusehen. So kann sich die zu leistende Zahlung anteilsmäßig auf den Prozentsatz der vervollständigten Arbeit oder auf die anteilige Auftragsdauer beziehen.

Sollbruchstellen & Exit Management

Sollbruchstellen & Exit Management


Abschließend sollte im Vertrag zu Art und Umfang der Dokumentation ausgeführt werden, welche Projektarchitektur vorgesehen ist, ob die Dokumentation im Code vorhanden sein soll oder Clean Code mit eigenem Handbuch bevorzugt wird. Die „Definition of Done“ als Kriterienkatalog[4], um ein Feature als fertig implementiert erachten zu dürfen, sollte ebenso nicht dem beliebigen Empfinden der Vertragsparteien unterliegen, sondern möglichst eindeutig im Vertrag zu finden sein.

Dokumentation

Dokumentation


Weiter zu Teil V: Die Rechtsprechung

[i] Schwaber/ Sutherland, The Scrum Guide, S. 9 ff.
[ii] Schwaber / Sutherland, The Scrum Guide, S. 5.
[iii] s. hierzu: Pichler, Agile Product Management with Scrum, S. 41.
[iv] ScrumAlliance, Scrum, S. 9.

RA Bilal Abedin
Wiss. Mit. Burak Zurel

201730.01.

Ab dem 01.02.2017: Neue Informationspflichten nach dem Verbraucherstreitbeilegungsgesetz

Zur Umsetzung der Richtlinie 2013/11/EU über die alternative Beilegung verbraucherrechtlicher Streitigkeiten hat die Bundesregierung am 19. Februar 2016 das Verbraucherstreitbeilegungsgesetz („VSBG“) verabschiedet, das teilweise schon zum 1. April 2016 in Kraft getreten ist.

Zum 1. Februar 2017 treten nun weitere wichtige Informationspflichten, insbesondere § 36 VSBG, in Kraft.

Neue Informationspflichten auf der Webseite und in AGB

Nach der neuen gesetzlichen Regelung muss ein Unternehmer, der am oder nach dem 31. Dezember 2016 mehr als 10 Personen beschäftigt, eine Webseite unterhält oder Allgemeine Geschäftsbedingungen verwendet, Verbraucher

  • davon in Kenntnis zu setzen, ob das Unternehmen bereit oder gesetzlich verpflichtet ist, an einem Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen, und
  • falls ein Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle von dem Unternehmen vorgesehen ist, unter welcher Anschrift und unter welcher Webseite die Verbraucherschlichtungsstelle erreicht werden kann.

Die Verpflichtung an einer Verbraucherschlichtung teilzunehmen kann

  • auf einer gesetzlichen Verpflichtung beruhen (z.B. im Bereich Energiewirtschaft, Finanzdienstleistungen, Telekommunikation oder Luftverkehr) oder
  • vereinbart werden, z.B. durch eine Selbstverpflichtung.

Sofern keine gesetzliche Verpflichtung vorliegt, steht es also im freien Ermessen des Unternehmens, ob es die Teilnahme an solchen Verbraucherschlichtungen zulässt oder nicht. Wichtig zu beachten ist, dass auch die Nichtteilnahme an solchen Verbraucherschlichtungen auf der Webseite und in den Allgemeinen Geschäftsbedingungen angegeben werden muss.

Handlungsempfehlung

Das Gesetz schreibt vor, dass die Informationen über die Teil- oder Nichtteilnahme an einer Verbrauchschlichtung für den Verbraucher leicht zugänglich, klar und verständlich dargestellt werden. Für das Merkmal der „leichten Zugänglichkeit“ dürfte die Einbindung eines entsprechenden Hinweises im Impressum der Webseite ausreichen. Zudem ist darauf zu achten, dass der Hinweis klar und verständlich formuliert wird.

Formulierungsvorschlag für Nichtteilnahme (sofern keine gesetzliche Verpflichtung zur Teilnahme besteht):

Die A GmbH ist nicht bereit und verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen.

 Formulierungsvorschlag für Teilnahme (freiwillige Selbstverpflichtung):

Die A GmbH ist verpflichtet, an Streitbeilegungsverfahren vor der folgenden Verbraucherschlichtungsstelle teilzunehmen:

 [Schlichtungsstelle, Anschrift, Webseite ].

Liste von Verbraucherschlichtungsstelle

Das Bundesministerium der Justiz stellt unter der folgenden URL eine Liste von Verbraucherschlichtungsstellen zur Verfügung:

https://www.bundesjustizamt.de/DE/SharedDocs/Publikationen/Verbraucherschutz/Liste_Verbraucherschlichtungsstellen.html?nn=7709020

Rechtsfolgen bei Nichtbeachtung:

Für den Fall, dass die Pflichtinformationen nach dem VSBG nicht beachtet werden, drohen Bußgelder der Aufsichtsbehörden bis zu einer Höhe von 50.000,00 EUR sowie wettbewerbsrechtliche Abmahnungen durch Wettbewerber, da das Fehlen der Angaben ein Wettbewerbsverstoß nach § 3, 3a UWG darstellt.


201710.01.

Beitragsreihe: Verträge für agile Softwareprojekte – Konventionelle Vertragsmodelle

Agile Softwareentwicklung - Konventionelle Vertragsmodelle

Agile Softwareentwicklung – Teil III


Die Beitragsreihe “Verträge für agile Softwareprojekte” setzt sich mit den schuld- und urheberrechtlichen Aspekten der agilen Softwareentwicklung auseinander. Unter der Prämisse, dass agile Verträge als Lösungsansatz auch für deutsche Unternehmen zunehmend Relevanz erlangen, diese Thematik bisher jedoch nur rudimentär aufgearbeitet wurde, wird anhand von Rechtsprechung und Literatur die gegenwärtige Rechtslage veranschaulicht. Schlussendlich werden Empfehlungen zu vertraglichen Regelungen ausgesprochen, die sich mit Blick auf die Vielzahl von Problemen und Risiken ergeben, die bei agilen Softwareentwicklungsprojekten zu erwarten sind.

Zurück zu Teil II: Risiken konventioneller Verträge

Konventionelle Vertragsmodelle

Die Vertragsgestaltung ermöglicht es, den vorher genannten Gefahren entgegenzutreten und die Verantwortlichkeit durch eine einvernehmliche Verlagerung in beiderseitigem Interesse gleichmäßig zu verteilen. Das passende Vertragsmodell hängt hierbei von den individuellen Anforderungen und Bedürfnissen der Parteien ab, es gibt also keine universelle Lösung für alle Sachverhalte der agilen Softwareentwicklung. In Betracht kommen zunächst die konventionellen Vertragsmodelle, also der Werkvertrag, der Dienstvertrag, aber auch kombinierte Verträge mit dienst- und werkvertraglichen Elementen.

Der klassische Werkvertrag bildet hierbei das Ausgangsmodell. Beim Werkvertrag schuldet der Dienstleister die Erstellung eines mangelfreien Werks, gemessen auf Grundlage einer konkreten Spezifikation, die vor Arbeitsbeginn einmalig vereinbart wurde. Die Vergütung erfolgt über einen Festpreis und Änderungen an oder der Austausch von Features erfolgt im Rahmen von Change-Requests mit Preissteigerungen auf der Basis von Time and Materials. Der klassische Werkvertrag sieht somit eine Kostensicherheit bei gleichbleibender Spezifikation, die Verantwortung des Auftragnehmers bei Mängeln und dadurch eine Vorhersehbarkeit für Auftraggeber und Auftragnehmer vor. Dies bedeutet zugleich, dass Änderungen stets Nachverhandlungen erfordern, mit nicht-einkalkulierten Kosten verbunden sind und es bedingt Anreize für den Arbeitnehmer gibt, über Verbesserungen im Sinne des Arbeitgebers nachzudenken. Der klassische Werkvertrag ist in der Gesamtbetrachtung für einfache Projekte in unveränderlichen Umgebungen geeignet.


Der Dienstvertrag scheint demgegenüber eher auf die Bedürfnisse der agilen Projektleitung zugeschnitten zu sein. Beim Dienstvertrag schuldet der Dienstleister kein definiertes Ergebnis (Werk) sondern lediglich seine Arbeitsleistung in Form der Tätigkeit. Dadurch verschiebt sich das Erfolgsrisiko zu Lasten des Auftraggebers. Innerhalb des Projekts würde die Software in sogenannten Sprints entwickelt, bei denen jeweils einzelne User-Stories entwickelt und implementiert werden. Ein Sprint ist ein abgeschlossener Zeitrahmen innerhalb dessen vorher bestimmte Entwicklungsziele verwirklicht werden und auf den sofort der nächste Sprint folgt.[1] Die Vergütung erfolgt nach Aufwand, also Time and Materials. Dadurch bietet der Dienstvertrag eine völlige Flexibilität im Hinblick auf den Vertragsgegenstand und eine wirtschaftliche Sicherheit für den Auftragnehmer. Die Projektkosten können für den Auftraggeber jedoch nicht abschließend bestimmt werden, und so bleiben Zeit und Kosten unvorhersehbar. Die Mängelbeseitigung durch den Auftragnehmer führt unweigerlich zu Zusatzkosten für den Auftraggeber. Im Ergebnis ist der Dienstvertrag eher für kleinere Projekte für die Entwicklung von Einzelkomponenten geeignet, die im Rahmen einer bereits eingespielten Zusammenarbeit verwirklicht werden soll.


Einen Kompromiss versucht der Rahmenvertrag mit einzelnen, untergeordneten Werkverträgen darzustellen. Der Rahmenvertrag regelt hierbei die Beziehung von Auftragnehmer und Auftraggeber und fasst einen Großteil des Verhandlungsumfangs einmalig ab. Für jeden Sprint vereinbaren die Parteien sodann einen präzisen Scope mit umzusetzenden User-Stories zu einem festen Preis nach werkvertraglichem Charakter. Die Mängelbeseitigung erfolgt nach jeder Teilabnahme im Rahmen der gesetzlichen Gewährleistung. Dieses Modell erreicht eine hohe Flexibilität, ohne Kostensicherheit bei gleichbleibender Spezifikation zu gefährden und bietet durch die Teilabnahmen und die gesetzliche Gewährleistung einen hervorragenden Ausgleich in der Qualitätssicherung. Jedoch ist jeder Sprint mit einem Verhandlungsaufwand verbunden und die beabsichtigte Agilität, also Änderungen im Scope, führen zu Kostenunsicherheiten. Der Rahmenvertrag mit einzelnen Werkverträgen ist demnach besonders gut für komplizierte Projekte geeignet, an denen ohne Zeitdruck gearbeitet werden kann.


Das Vertragsmodell des agilen Festpreises ist die Fortentwicklung und Anpassung des Werkvertrages mit Werkzeugen, die durch die agile Arbeitsweise selbst bereitgestellt werden. Hierbei werden im Rahmen einer Testphase Referenz-Userstories festgelegt, anhand derer dann allen User-Stories Storypoints zugewiesen werden. Die Parteien vereinbaren einen Festpreis für eine bestimmte Anzahl von Storypoints, die in den jeweiligen Sprints vom Auftraggeber genutzt flexibel genutzt werden können. Die Haftung des Auftragnehmers für Mängel ergibt sich aus den werkvertraglichen Regelungen. Durch dieses Modell wird eine hohe Flexibilität in der Ausgestaltung der Arbeitsleistung vorgesehen, ohne die Haftung des Auftragnehmers für die eigene Arbeitsleistung zu berühren. Change-Requests und Änderungen des Scope unterliegen klaren Prozessen, die im Vertrag beschrieben sind. Die Erforderlichkeit der Testphase und die Möglichkeit, Zeit und Kosten erst nach der Durchführung dieser Testphase bestimmen zu können, verursachen bei den Beteiligten dahingegen einen unproduktiven, möglicherweise sogar vergeblichen Aufwand. Das agile Festpreismodell ist für eingespielte Teams aus Auftragnehmern und Auftraggebern geeignet, insbesondere bei hausinterner Softwareentwicklung.

Weiter zu unserer Empfehlung Teil IV: Agile “Time and Materials”-Projekte

[1] Schwaber/ Sutherland, The Scrum Guide, S. 7.

RA Bilal Abedin
Wiss. Mit. Burak Zurel