Vertragsgestaltung in Scrum Projekten – Wann, welche Vertragsform wählen?

Um eines vorweg zu nehmen. Dieser Artikel stellt keine Rechtsberatung über Verträge zur agilen Produktentwicklung dar. Vielmehr sollen einige Hintergründe, Möglichkeiten und Ideen der Vertragsgestaltung im agilen Umfeld, insbesondere bei Produktentwicklungen mit Scrum,  beleuchtet werden, die beide Vertragsparteien zufriedenstellen können. Für die jeweilige konkrete Ausgestaltung der Verträge sollten Sie einen Juristen hinzuziehen.

Im Rahmen der klassischen Projektabwicklung kommen häufig Werkverträge zum Einsatz. Basis sind dabei Lastenhefte oder sonstige Anforderungsspezifikationen, die den Leistungsumfang umfänglich schon zu Beginn festlegen. Genau dies ist aber bei Scrum mit seinen inkrementellen, iterativen und adaptiven Vorgehen aus guten Gründen nicht gewollt.

Bei Scrum werden Kunden und Anwender intensiv in die Entwicklung mit einbezogen und arbeiten gemeinsam an der erfolgreichen Produktentwicklung. Dadurch wird es schwieriger die Vertragsbeziehungen und Leistungsverpflichtungen zwischen Auftraggeber und Auftragnehmer abzugrenzen und den richtigen Vertragstyp oder Kombinationen davon zu wählen.

Grundsätzliches zu den Vertragstypen für Projekte

Neben dem Vertragstyp Kaufvertrag (hier ist der Werkliefervertrag mit eingeschlossen), der hier nicht im Fokus steht, gibt es im Wesentlichen zwei Vertragstypen, die Anwendung finden.

Der Dienstvertrag §611 ff. BGB

Bei einem Dienstvertrag verpflichtet sich ein Auftragnehmer eine bestimmte Dienstleistung zu erbringen und der Auftraggeber verpflichtet sich dafür eine Vergütung zu bezahlen. Ungeachtet möglicher Regelungen, die individuell vereinbart werden können, erfolgt die Vergütung erst nach Erbringung der Dienstleistung.

Der Dienstvertag kennt keine besonderen Vorschriften hinsichtlich der Mängelhaftung, wie bei Kauf- oder Werkverträgen. Nachbesserungen oder Minderung der Vergütung kann nicht verlangt werden. Vereinbarte Vergütungen sind selbst dann zu zahlen, wenn die Leistung erbracht aber nicht angenommen wurde. Es ist kein konkreter Erfolg geschuldet. Der Dienstleister ist nur zum Tätigwerden verpflichtet.

Auftragnehmer haben besonderes Interesse an dieser Vertragsform, da kein Mängelhaftungsrecht (Sachmängelhaftung) greift.

Das hauptsächliche Risiko liegt hier beim Auftraggeber.

Der Werkvertrag §631 ff. BGB

In Abgrenzung zum Dienstvertrag verpflichtet sich der Auftragnehmer ein Werk herzustellen. Der Auftraggeber verpflichtet sich dafür einen Werklohn zu bezahlen, der nach Abnahme fällig wird.

Das Werk steht im Vordergrund des Werkvertrags. Der Auftragnehmer schuldet also einen tatsächlichen Erfolg. Im Gegensatz zum Werkvertrag schuldet der Auftragnehmer bei einem Dienstvertrag nur die Tätigkeit.

Der Auftragnehmer schuldet also ein der Leistungsbeschreibung (z.B. Lastenheft) entsprechendes Ergebnis. Abweichungen davon muss der Auftragnehmer im Rahmen der Sachmängelhaftung beseitigen.

Das hauptsächliche Risiko liegt hier beim Auftragnehmer.

Auftraggeber haben besonderes Interesse an dieser Vertragsform, da das Mängelhaftungsrecht (Sachmängelhaftung) greift und Nachbesserungen bei Abweichungen gefordert werden können. Darüber hinaus sind häufig Festpreise und Vertragsstrafen bei Nichteinhaltung von Lieferterminen vereinbart, die dem Auftraggeber eine gewisse Planungssicherheit geben.

Vertragsproblematiken

Schlagworte und Beschreibungen der Vertragsinhalte sind nicht immer relevant. Entscheidend sind allein die tatsächlich vereinbarten Vertragspflichten, insbesondere diejenigen des Auftragnehmers (Leistungspflichten). Es kommt in der Praxis eben auch auf die tatsächliche Aus-/Durchführung des Vertrags an.

Bei Werkverträgen kalkuliert der Auftragnehmer häufig Risikozuschläge in seinen Angebotspreis ein, die das „Werk“ verteuern. Läuft alles glatt, streicht der Auftragnehmer die Risikoprämie als zusätzlichen Gewinn ein.

Die Erfahrung zeigt, dass zu Beginn eines Projekts i.d.R. nicht immer alle Leistungsmerkmale des „Werks“ bekannt sind. Im Verlaufe des Projekts, je mehr Erkenntnisse man erlangt, kommen häufig erforderliche oder auch weniger erforderliche Zusatz- oder Änderungswünsche auf. Dann kommen sogenannte Change Requests, d.h. Änderungsanforderungen zum Tragen. Diese sind naturgemäß nicht Bestandteil der ursprünglich kalkulierten und vereinbarten Leistungsbeschreibung und deshalb auch vom Auftraggeber zusätzlich zu beauftragen und zu bezahlen. Das kann das Projekt erheblich verteuern und verzögern.

Problematiken bei Verträgen zur agilen Produktentwicklung mit Scrum

Scrum kennt kein Lasten- oder Pflichtenheft, nur einen Product Backlog. Die Anforderungen im Backlog sind zu Beginn unscharf und auch veränderbar. Das ist so von Scrum auch beabsichtigt, da sich Scrum auf eine iterative, inkrementelle und adaptive Vorgehensweise stützt, die auf eine Wertmaximierung des Produkts abzielt.

Damit ist zu Beginn der Vertragslegung kein umfänglich bekannter Leistungsumfang und damit auch kein garantierter Leistungsumfang möglich. Lediglich ein initialer Product Backlog, der sich ggf. noch stark verändern kann, ist denkbar. Durch die iterative, inkrementelle und adaptive Vorgehensweise entstehen die Anforderungen und deren Prioritäten sowie Detaillierungsgrade dynamisch und fortlaufend im Product Backlog. Änderungen von Sprint zu Sprint sind möglich und gewollt, um den größtmöglichen Wert des Produkts für den Auftraggeber zu sichern.

Ein Fertigstellungstermin für einen definierten Leistungsumfang kann bei Scrum nicht präzise und verbindlich festgelegt werden. Aber selbst in klassischen Projektvorgehensmodellen ist der Endtermin oftmals nur ein theoretischer Wert, der häufig nicht eingehalten wird. Dazu gibt es unzählige Beispiele, viele sind auch aus den Medien bekannt.

In Scrum müssen Auftragnehmer und Auftraggeber gemeinsam auf den Projekterfolg hinarbeiten. Die einfache Abgrenzung ich der Auftraggeber der den Auftrag vergibt und sich dann nicht weiter kümmern muss und du Lieferant der zum vereinbarten Zeitpunkt spezifikationsgemäß liefern muss, funktioniert in Scrum nicht mehr.

Der Anspruch des Auftraggebers lautet oftmals: Wir wollen jetzt agil arbeiten. Gleichzeitig möchte er aber die aus der klassischen Projektabwicklungswelt bekannten Vertragstypen beibehalten. Häufig akzeptiert der Auftraggeber daher keine einseitige Risikoverlagerung auf sich und strebt daher einen Werkvertrag an. Der Auftraggeber möchte Planungssicherheit, gerade auch in Bezug auf das Budget. Hinzu kommt, dass der Einkauf häufig auf einen Werkvertrag drängt.

Langwierige Vertragsverhandlungen gefährden die Geschäftsziele für agil zu entwickelnde Produkte.

Nicht immer hat der Product Owner Macht genug, um seinen Einfluss auf Budgets und Vertragsgestaltung geltend machen zu können, obwohl er in Scrum für den wirtschaftlichen Erfolg des Produkts vollumfänglich verantwortlich ist.

Möglichkeiten einer beiderseitig fairen Vertragsgestaltung

In Scrum gibt es Bereiche, die gegebenenfalls als Dienstvertrag und Bereiche die gegebenenfalls auf Basis eines Werkvertrags geregelt werden könnten. Hier können Rahmenverträge für Dienst- und Werkvertrags-Abrufe den administrativen Aufwand vermindern.

So können beispielsweise die Planungsaktivitäten, Meetings und Reviews in Scrum auf Basis eines Dienstvertrags geregelt werden. Die Inkremente/Ausliefergegenstände als Ergebnis eines Sprints könnten auf Basis eines Werkvertrags ausgestaltet werden. Basis sind hier die Inhalte des Sprint-Backlogs/-Ziels, das als Werk geschuldet und abgenommen wird.

Problematisch an dieser Vorgehensweise ist jedoch, dass es z.B. bei Scrum innerhalb eines Sprints dazu kommen kann, dass das Entwicklerteam auf nicht erwartbare Probleme oder neue Erkenntnisse stößt, die Änderungen am Sprint-Ziel/-planung sinnvoll und zielgerecht mit Blick auf die Wertmaximierung des Produkts machen. Dann wird laut Scrum-Methodik  mit dem Product Owner der Scope des Sprints neu verhandelt.

Vertrauen erwächst aus der intensiven Zusammenarbeit von Auftraggeber und Auftragnehmer, die bei Scrum ausdrücklich vorgesehen ist. Daher sind kleine Schritte zum Vertrauensaufbau wichtig.

Dazu kann die Erteilung kleinerer Aufträge nach Aufwand (z.B. Dienstvertrag, ggf. mit Obergrenze, kostengedeckelt) genutzt werden.

Eine weitere Möglichkeit bieten Incentive-Verträge, bei denen das finanzielle Risiko auf beide Seiten nach einem vereinbarten Schlüssel verteilt wird und Anreize bieten effizient und effektiv zu arbeiten.

Risikominimierung, auch für das Budget

Aufgrund der kurzen Sprintzyklen von max. 4 Wochen und der direkten Überprüfung des entwickelten Inkrements/Ausliefergegenstands durch den Auftraggeber wird das Risiko minimiert hohe Kosten und Investitionen zu verursachen, die nicht zielführend sind. Die Produktentwicklung kann frühzeitig abgebrochen oder adaptiv und iterativ an neue Anforderungen angepasst werden. Darüber hinaus ist der Auftraggeber bei Scrum intensiv in den Sprint/Produktentwicklung mit einbezogen und kennt so die aktuelle Situation sehr genau. Maximal ein Monat an Zeit und Budget kann so im „worst case“ auf dem Spiel stehen.

Fazit

Einen allgemeingültigen Weg in der Vertragsgestaltung für Scrum-Produktentwicklungen gibt es nicht.

Gegenseitiges Vertrauen erwächst aus der intensiven Zusammenarbeit, die bei Scrum sehr bedeutend und ausdrücklich vorgesehen ist.

Eine bedarfsgerechte Gestaltung der Vertragsbeziehungen zwischen Auftraggeber und Auftragnehmer vor dem Hintergrund der Besonderheiten einer agilen Vorgehensweise ist geboten. Sonst können die unbestreitbaren Vorteile der agilen Vorgehensweise nicht erschlossen werden.

Literaturhinweise und nützliche Links

IT-Vertragsrecht – Uni Münster Vorlesungsskriptum Stand April 2017

http://www.uni-muenster.de/Jura.itm/hoeren/itm/wp-content/uploads/Skript_IT_Stand_April-2017.pdf

Bürgerliches Gesetzbuch

• 611 ff. Dienstvertrag https://www.gesetze-im-internet.de/bgb/__611.html
• 631 ff. Werkvertrag https://www.gesetze-im-internet.de/bgb/__631.html