Wie gehen Verträge mit Scrum?

Drei grundsätzliche und unabhängige Entscheidungen

Bei der Gestaltung von Verträgen für die Herstellung von Produkten mit Hilfe von Scrum gibt es drei grundsätzlich voneinander unabhängige Entscheidungen zu fällen:

1. Wird die Arbeit des Product Owner vollständig vom Auftraggeber übernommen oder wird ein wesentlicher Teil der Arbeit des Produkt Owners und damit der Festlegung der Produktmerkmale vom Auftragnehmer durchgeführt?
2. Wird ein Festpreis vereinbart oder erfolgt eine Abrechnung nach Aufwand?
3. Wird ein Werkvertrag oder ein Dienstvertrag geschlossen?

1) Wer ist Product Owner?

Im Sinne der Scrum-Werte (enge Zusammenarbeit) ist die Idealform, dass der Auftraggeber die Rolle des Product Owners einnimmt; dies korrespondiert auch mit seiner Rolle als Zahlender. In diesem Fall formuliert und detailliert er die Anforderungen an das zu erstellende Werk selbst und passt die Anforderungen entsprechend der Scrum-Regeln an. Hierdurch erhält der Auftraggeber eine große Flexibilität. Er gewinnt während der Erstellung des Produktes durch die Inkremente und Sprint Reviews eine immer präzisere Vorstellung vom Produkt und kann die Anforderungen anpassen. 

Im Durchschnitt aller Projekte werden ca. 50% der Anforderungen eines Produktes während der Herstellung angepasst. Scrum bietet dem Auftraggeber ein pragmatisches Vorgehen für solche Änderungen. Als Alternative kann auch der Auftragnehmer die Anforderungen anstelle des Auftraggebers formulieren bzw. detaillieren und ihm somit die Arbeit erleichtern und teilweise abnehmen. In diesem Fall übernimmt der Auftragnehmer einen wesentlichen Teil der Arbeit des Product Owners. Dies hat allerdings den Nachteil, dass der Kunde deutlich weniger in die konkrete Ausgestaltung des Produktes einbezogen wird, hierauf auch deutlich weniger Einfluss hat, und die Gefahr besteht, dass das Produkt nicht die Erwartungen des Auftraggebers erfüllt. 

Erfahrungen zeigen, dass sich viele Auftraggeber anfänglich mit einer engen Einbindung in das Projekt als Product Owner schwer tun, aber nach wenigen Sprints die Rolle ausfüllen und Scrum als ein sehr gutes Vorgehen ansehen. Als Vorteile benennen die Auftraggeber unter anderem: die kontinuierliche Erstellung der Anforderungen statt eines großen Aufwands vorab, die Schärfungsmöglichkeit der Anforderungen und den regelmäßigen sichtbaren Fortschritt, der Vertrauen gibt und motiviert. 

2) Festpreis oder Abrechnung nach Aufwand?

Bei einem Festpreis (auch Pauschalpreis genannt) wird ein fester Preis für eine Leistung vereinbart und berechnet, unabhängig vom tatsächlich angefallenen (Zeit-)Aufwand. Bei einer Abrechnung nach Aufwand wird die tatsächlich benötigte Zeit für eine Leistung in Rechnung gestellt. 

Durch die Nutzung von Zeitfenstern (Timeboxen) arbeitet ein Scrum-Projekt natürlicherweise mit festen Aufwänden und festen Teams. Dies gilt sowohl für einen Sprint als auch für ein Release. Anforderungen und Ergebnisse werden an die Timeboxen angepasst. Für ein Scrum-Projekt ist daher der Festpreis die „natürliche“ Form der Abrechnung.

3) Werk- oder Dienstvertrag?

Bei einem Werkvertrag wird mit dem Auftragnehmer ein Vertrag über die Lieferung eines vorab definierten Werks geschlossen. Der Werkvertrag zielt auf ein bei Beauftragung schon festgelegtes Ergebnis. Der Auftragnehmer verpflichtet sich, dieses Werk gegen eine Vergütung (Festpreis oder Abrechnung nach Aufwand) herzustellen. Während beim Dienstvertrag nur die Erbringung einer durchschnittlich guten Leistung als solcher ohne Gewähr für das erhoffte oder beabsichtigte Ergebnis geschuldet wird, wird beim Werkvertrag der Erfolg in Form der Ablieferung des vereinbarten Werkes geschuldet. Bei dem Werkvertrag erhält der Auftragnehmer sein Geld dementsprechend erst, wenn er das Werk abgeliefert und der Kunde es für gut befunden hat (Abnahme). Bei einem Werkvertrag ist daher eine klare Vereinbarung nachvollziehbarer und eindeutig prüfbarer Abnahmekriterien notwendig. Auf das gelieferte Werk hat der Auftraggeber eine Gewährleistung von zwei Jahren, wenn es Mängel hat, d.h. nicht die vereinbarten Anforderungen erfüllt.

Im Gegensatz dazu wird bei dem Dienstvertrag die Bezahlung mit Erbringung der Leistungen geschuldet, unabhängig davon, ob die Leistung irgendein Resultat erbracht hat, insbesondere ein Resultat, dass der Auftraggeber nutzen kann. Dementsprechend gibt es folgerichtig auch keine Gewährleistung für Fehler des Ergebnisses, da bereits kein Ergebnis geschuldet wird. Eine sog. Schlechtleistung, d.h. ein Leistung unter Durchschnitt, kann aber Schadensersatzansprüche auf Seiten des Auftraggebers zur Folge haben.

Bei der Wahl des Vertragstyps und bei dessen Ausgestaltung ergeben sich eine Reihe von Möglichkeiten. Diese sind von der Flexibilität geprägt, die der Auftraggeber hat bzw. benötigt, um den Nutzen des Produkts während der Entwicklung zu schärfen und zu verbessern. Bei der Vertragsgestaltung stellt sich daher die Frage, wie Flexibilität und Verbesserung des Produkts gegen die Sicherheit abgewogen werden, die fest definierte Anforderungen mit sich bringen. Im ersten Fall besteht das Risiko, dass der Auftragnehmer auf Grund geringer Fähigkeiten nicht die gewünschten Ergebnisse liefert und trotzdem dafür bezahlt werden muss. Im zweiten Fall besteht das Risiko, dass der Auftraggeber ein Werk erhält, dass zwar die Anforderungen erfüllt, aber dennoch nicht optimal ist, da die Möglichkeiten zu Verbesserungen „unterwegs“ abgewürgt werden und dass Produkt dann entweder trotz Einhaltung der ursprünglichen Vorgaben nicht das erfüllt, was sich der Auftraggeber eigentlich vorgestellt hat oder aber jedenfalls nicht den optimalen, eigentlich möglichen Stand erreicht.

Drei Lösungsansätze für agile Verträge

Möglichkeit 1: Der Auftraggeber formuliert einen Werkvertrag mit Hilfe eines Pflichtenhefts, das das zu erstellende Gewerk definiert.

Der Auftragnehmer nutzt Scrum, um das fest definierte Gewerk herzustellen und übernimmt die Rolle des Product Owners. Diese Vertragsform ist dann sinnvoll, wenn der Auftraggeber sich sicher ist, dass es bei den Anforderungen keine Änderungen geben wird und dass das Gewerk den Nutzen bringen wird, wenn es genau so wie spezifiziert hergestellt wird. Statistiken zeigen, dass diese Situation nur sehr selten und nur in sehr kleinen Projekten gegeben ist. Eine solche Vertragsgestaltung ist daher nur in wenigen Fällen (wirtschaftlich) sinnvoll. Im Prinzip ist bei dieser Vertragsgestaltung Scrum für den Auftraggeber nicht sichtbar. Der Nutzen von Scrum beschränkt sich im Wesentlichen auf den Auftragnehmer. Er stellt mit Scrum sicher, dass das vorab definierte Gewerk effektiv und effizient hergestellt wird. Auf den Nutzen von Scrum für den Auftraggeber, das Produkt und seinen Nutzen während der Herstellung schärfen zu können, wird bei dieser Vertragsform verzichtet.

Möglichkeit 2: Es wird ein Werkvertrag vereinbart, der das Gewerk und seine Eigenschaften nur ganz grob definiert. 

Zugleich vereinbaren die Vertragspartner, dass die Einzelheiten erst im Laufe der Entwicklung im Rahmen der Sprints gemeinsam ausgeformt werden. In diesem Fall spezifizieren das Produkt-Ziel und die Release-Ziele (ggf. mit entsprechenden Akzeptanzkriterien) das Gewerk – die detaillierten Anforderungen an das Produkt sind hingegen nicht Bestandteil der an das Gewerk zu machenden Vorgaben. 

Das Risiko für den Auftraggeber ist in diesem Fall, dass der Auftragnehmer nicht die erwartete Leistung bringt und am Ende nicht das gewünschte Gewerk mit dem vertraglich vereinbarten Nutzen liefert. Der Auftraggeber muss dann zwar u. U. nicht zahlen, hat aber viel Zeit (und evtl. auch Geld) verloren. Insgesamt bietet diese Vertragsform viel Platz für Unklarheiten und Missverständnisse und somit auch für nachträglichen Streit. Auch dürfte es nur wenige Auftragnehmer geben, die bereit sind, die Ablieferung eines Endwerkes zuzusichern, wenn sie nicht bestimmen bzw. vorhersehen können, wie sie das Ziel erreichen können/müssen. 

Diese Risiken lassen sich eingrenzen:

• Nutzung der Sprint Reviews & Refinements:
  Eine Lösung ist in Scrum eingebaut: Sprint Reviews und Product Backlog Refinements mit dem Auftraggeber. Anhand von verwenbaren Inkrementen sieht der Auftraggeber, dass – und wie – es vorwärts geht. In den Product Backlog Refinements ist er eng eingebunden in die Detaillierung der Ziele aus dem Werkvertrag. Wenn dem Auftraggeber das Recht eingeräumt wird, nach einem Sprint Review zu kündigen und nur die Arbeitszeit bis zu diesem Zeitpunkt zu bezahlen, dann gibt es auch eine „Reißleine“. Erfahrungsgemäß ist es sehr unwahrscheinlich, dass ein Team, das in jedem Sprint verlässlich Inkremente liefert, plötzlich scheitert.

• Teilprodukte als Gewerk:
  Statt das gesamte Gewerk zu vereinbaren bezieht sich der Vertrag nur auf ein Release oder einen Sprint (z. B. Vereinbarung des Sprint Goals als Erfolg). Es können zunächst auch Verträge über Sprints geschlossen werden, bis der Auftraggeber ein ausreichendes Vertrauen hat, größere Gewerke (Release, Gesamtergebnis) zu bestellen.

• Scrum-Artefakte mit als Gewerk:
  Die Scrum Artefakte werden als Liefergegenstände in den Vertrag aufgenommen. Dies stellt sicher, dass Scrum ordentlich durchgeführt wird. Da die ordentliche Durchführung von Scrum der wesentliche Erfolgsfaktor ist, wird durch die Vereinbarung der Scrum Artefakte der Erfolg des Projekts abgesichert.

Während der Herstellung des Gewerks arbeitet der Auftraggeber als Product Owner und spezifiziert bzw. detailliert kontinuierlich die Anforderungen an das Produkt, prüft die Inkremente und schärft mit den Erkenntnissen aus den Sprint Reviews die Anforderungen und das Produkt. 

Gegebenenfalls hat der Auftraggeber zu Beginn eines Scrum-Projekts nicht die Fähigkeiten als Product Owner zu arbeiten. In diesem Fall kann er durch den Auftragnehmer bei der Definition der Anforderungen unterstützt werden. Der Auftraggeber bleibt aber bei dieser Vertragsgestaltung für die detaillierten Anforderungen verantwortlich.

Möglichkeit 3: Der Auftraggeber vereinbart einen Dienstvertrag mit Festpreis.

Typischerweise geschieht dies für einen Sprint. Auch hier arbeitet der Auftraggeber als Product Owner. Diese Vertragsform reduziert den Vertragsaufwand.

Vor- und Nachteile der Lösungsansätze:

Die einfachste Vertragsmöglichkeit ist der Dienstvertrag mit Festpreis (Lösungsansatz 3). Er ist dann sinnvoll, wenn zwischen Auftraggeber und Auftragnehmer ein gutes Vertrauen besteht. Im Prinzip ist dies die „natürlichste“ Vertragsgestaltung, die auch den Scrum-Prinzipien (Zusammenarbeit vor Vertragsverhandlung) am meisten entspricht. Ein solcher Vertrag hat für den Auftraggeber ein begrenztes Risiko (maximal ein Sprint) und ist einfach umzusetzen. Der Auftragnehmer hat den Vorteil, sein Geld auch zu erhalten, wenn die Erwartungen des Auftraggebers aufgrund der zunächst nur vagen Spezifizierung nicht erfüllt werden.

Ein Werkvertrag über den Nutzen eines Sprints, eines Releases oder des Gesamtprodukts, die dem Auftraggeber die Steuerungsmöglichkeiten als Product Owner lässt, ist eine alternative Vertragsform (Lösungsansatz 2). Diese Form setzt ebenfalls die Scrum Prinzipien um und hebt den Nutzen von Scrum (pünktliche Lieferung, größtmöglicher Return On Investment des Produkts).

Ein klassischer Werkvertrag mit den detaillierten Anforderungen in einem Pflichtenheft (Möglichkeit 1) beraubt den Auftraggeber faktisch des Nutzens, die das Scrum-Framework bietet. Die Nutzung von Scrum in diesem Vertragskontext hilft vorrangig dem Auftragnehmer-Team, nicht dem Auftraggeber.