Wie gehen Verträge mit Scrum?

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?

Komponenten eines agilen Vertrags

1) Wer ist Product Owner?

Im Sinne der Scrum-Werte (enge Zusammenarbeit) ist die Idealform, dass der Auftraggeber die Rolle des Product Owner 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 Werks durch die Inkremente und Sprint Reviews eine immer präzisere Vorstellung vom Werk und kann die Anforderungen anpassen. Im Durchschnitt aller Projekte werden ca. 50% der Anforderungen eines Werks 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 bzw. teilweise abnehmen. In diesem Fall übernimmt der Auftraggeber einen wesentlichen Teil der Arbeit des Product Owners. Dies hat allerdings den Nachteil, dass der Kunde deutlich weniger in die konkrete Ausgestaltung des Werks einbezogen wird, hierauf auch deutlich weniger Einfluss hat, und die Gefahr besteht, dass das Werk 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.

feste-preise.510_de.jpg

Lösungsansätze:

Möglichkeit 1: Der Auftraggeber formuliert einen Werkvertrag mit Hilfe eines Pflichtenhefts, das das zu erstellende Werk definiert. Der Auftragnehmer nutzt Scrum, um das fest definierte Werk 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 Werk 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 Werk effektiv und effizient hergestellt wird. Auf den Nutzen von Scrum für den der 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 Werk 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 anfangs vorrangig die Produktvision und einige wenige prüfbare Nutzungskriterien das Werk – die detaillierten Anforderungen an das Produkt sind hingegen nicht Bestandteil der an das Werk zu machenden Vorgaben. Während der Herstellung des Werks 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. Das Risiko für den Auftraggeber ist in diesem Fall, dass der Auftragnehmer ggfls. nicht die erwartete Leistung bringt und am Ende der Entwicklung nicht das gewünschte Werk 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. Dieses Risiko lässt sich durch zwei Maßnahmen begrenzen:

  • Statt dass gesamte Werk zu vereinbaren bezieht sich der Vertrag nur auf ein Release oder einen Sprint (z.B. Vereinbarung des Sprint Goals als Erfolg). Ggf. können auch erst Verträge über Sprints geschlossen werden, bis der Auftraggeber ein ausreichendes Vertrauen hat, größere Werke (Release, Gesamtergebnis) zu bestellen.
  • 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.

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 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 (Möglichkeit 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 (Möglichkeit 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). Diese Vertragsform lebt nicht ganz den Geist des agilen Manifests (Zusammenarbeit vor Vertragsverhandlung), aber auf der anderen Seite kann die Verpflichtung auf den Nutzen und die Scrum-Artefakte das Team darin unterstützen, den Fokus auf eine disziplinierte Scrum-Umsetzung zu behalten.

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.

Icon Dieser Artikel als PDF (1,0 MB)
Haben Sie Fragen?
Portrait
Malte Foegen

Geschäftsführung


+49 6151 503349-0

[protected email]

[protected email]

Wir unterstützen Sie bei der Umsetzung von Scrum:

Haben Sie Fragen?
Portrait
Malte Foegen

Geschäftsführung


+49 6151 503349-0

[protected email]

[protected email]