Agile Verträge – Spielregeln für die Entwicklung mit Scrum
Agil bedeutet, schnell und flexibel auf Veränderungen reagieren zu können. In der Entwicklung von Software erfüllt die herkömmliche Wasserfallmethode nicht die Anforderungen an den Entwicklungsprozess. Agile Projekte sind komplett anders aufgebaut. Unterteilt in kurze, mehrwöchige Sprints, an deren Ende ein wiederkehrender Feedback-Prozess (Review) steht. Durch diesen Rahmen können Ziele auf dem Weg geändert und angepasst werden. Während sich die agile Entwicklung immer mehr etabliert, besteht die Schwierigkeit oft noch im Aufsetzen agiler Verträge. Doch was ist die Schwierigkeit, welche Formen agiler Verträge gibt es und wie kann in der Praxis damit umgegangen werden?
Was ist eigentlich das Ziel eines agilen Vertrags?
Im Grunde werden im Vertrag die Spielregeln für die Zusammenarbeit festgelegt. Im Zweifel kann man sich dann auf die festgelegten Regeln berufen. Im besten Fall bedeutet ein Vertrag, für beide Seiten gute Konditionen festzulegen, um ein Projekt zügig und erfolgreich umzusetzen. Im agilen Manifest ist folgender Grundsatz festgehalten: Die Zusammenarbeit mit den Kunden geht über Vertragsverhandlungen. In der Praxis bedeutet der Vertrag meistens eine Konkurrenzsituation, in der jeder versucht, im Zweifel Vorteile zu haben und den Schwarzen Peter der anderen Partei zuschieben zu können. Teil der agilen Philosophie ist aber eine partnerschaftliche Zusammenarbeit. Ein agiler Vertrag bedeutet also im besten Fall, dass der Kunde die Kontrolle über jeden Sprint hat und bei Problemen einvernehmliche Lösungen gefunden werden.
Flexibilität für mehr Qualität
In Wasserfallprojekten, wie man sie aus dem Agenturbetrieb kennt, liegt vor Beginn des Projektes die fachliche Spezifikation als Lastenheft vor. Die Rechnung wird nach erbrachter Leistung oder zu festgelegten Zeitpunkten beglichen. Ändert sich etwas im Projektverlauf, muss im Zweifel das Budget nachverhandelt werden. Jeder Projektmanager weiß, was für eine zähe Aufgabe das ist. Da man in der Softwareentwicklung schon lange weiß, dass diese festen Budgets und festgelegten Milestones dem Produkt nicht gerecht werden, entwickelt man agil. Man definiert eine bestimmte Anzahl an Sprints. Damit wird ermöglicht, zu einem frühen Zeitpunkt funktionierende Software auszuliefern und diese dann immer weiterzuentwickeln. Kunde und Entwickler geben sich in regelmäßigen Abständen, nämlich zum Sprintende, Feedback. Dieses fließt in den nächsten Sprint ein und zahlt damit auf die Gesamtqualität des Projekts mit ein.
Agile Projekte budgetieren
Die Herausforderung beim agilen Arbeiten ist nach wie vor die Verständigung auf eine einheitliche Vorstellung, was agiles Arbeiten bedeutet. Nach dem Motto Freiheiten und Pflichten ist es extrem wichtig, sich auf gemeinsame Grundlagen zu verständigen. Das beginnt bei den agilen Verträgen. Da hier immer noch die Best Practice fehlt, lief es in den letzten Jahren häufig so, dass man sich über den agilen Projektverlauf geeinigt hat, dann aber aus Gründen der Sicherheit, Bequemlichkeit und mangels Expertise das Ganze in herkömmliche Verträge gepresst hat. Obwohl man in Sprints plant, wird das Ganze in Tagessätze heruntergerechnet. Dieser Zustand führt natürlich zu Missverständnissen, die dann wieder aus der Welt geschafft werden müssen.
Mut beim Aufsetzen agiler Verträge – Wir brauchen mehr Best Practice
Allem voran: Wer agil entwickelt, muss die entsprechenden Vertragsformen einfordern. Vor allem, weil große Konzerne oft mit Standardverträgen arbeiten, an denen nur schwer zu rütteln ist. Der Kunde ist meist sehr aufgeschlossen gegenüber agilen Projekten oder lässt sich leicht davon überzeugen. Die Argumente sprechen da natürlich für sich. Bei den Verträgen allerdings drängen alle auf die klassische Form. Das hat viele Gründe. Hauptsächlich natürlich, dass die Unternehmen und ihre Rechtsabteilungen keinerlei Erfahrung mit agilen Verträgen haben. Um Fehler zu vermeiden, halten alle an vertrauten Vertragsformen fest. Als Agentur hat man im Prinzip das gleiche Problem und gibt deshalb meist viel zu schnell klein bei, anstatt den agilen Vertrag selbstbewusst durchzusetzen.
Um etwas Licht ins Dunkel zu bringen, stellen wir exemplarisch verschiedene Formen agiler Verträge vor. Ausgehend von bewährten Vertragsformen werden zusätzliche Klauseln eingearbeitet, die den flexiblen, partnerschaftlichen Entwicklungsprozess ermöglichen. Zeitmanagement und Budgetierung unterscheiden sich hier. Das Ganze ist ohne Gewähr auf Vollständigkeit, sondern bietet eine erste Grundlage. Denn zunächst geht es darum, viel Erfahrung und Best Practice im Umgang mit agilen Verträgen zu bekommen.
Ansätze agiler Verträge
1. Festpreisverträge – Money for nothing, changes for free
Bei Festpreisverträgen definiert der Kunde den Lieferumfang und der Anbieter bietet die Entwicklung zu einem definierten Preis an. Häufig hört man in diesem Zusammenhang von der „Money for nothing, changes for free”-Klausel. Diese ermöglicht es, das Projekt, im Sinne von Scrum, schon früher mit einem fertigen Produkt zu beenden. „Changes for free” bedeutet, alles, was noch nicht im Sprint geplant ist, kann noch geändert werden. Ändern sich die Anforderungen, kann ohne Mehraufwände reagiert werden. Dafür werden entsprechende Funktionalitäten mit geringer Priorität entfernt. Gesamtpreis und Fertigstellungstermin bleiben erhalten. „Money for nothing”, beschreibt den Umstand, dass sich im Falle einer vorzeitigen Fertigstellung der Projektpreis verringert.
Die Vertragsform verwandelt die Vorteile von Scrum und agiler Entwicklungsprozesse in einen Wettbewerbsvorteil. Allerdings ist in einer aktuellen Publikation zu lesen: „Von der ‚Money for nothing‘-Klausel hat übrigens keiner unserer Kunden jemals Gebrauch gemacht. Wir erklären uns das mit den Budgetierungsverfahren in großen Unternehmen. Wenn eine Fachabteilung ein Budget für die Entwicklung eines neuen Systems bekommt, ist es für die Fachabteilung eine schlechte Idee, das Geld nicht zu verbrauchen. Sie muss nicht nur das nicht verbrauchte Geld zurückgeben. Sie läuft zusätzliche Gefahr, nächstes Jahr weniger Budget zu erhalten (weil ja offensichtlich gar nicht so viel Budget notwendig ist). Die Fachabteilungen haben also keinen Anreiz, die ‚Money for Nothing‘-Klausel zu verwenden."*
2. Time and Material – Bezahlung nach Aufwand
Die Bezahlung nach Aufwand bietet mehr Flexibilität. Abgerechnet wird nach geleisteten Stunden. Der Anbieter rechnet laufend (meist monatlich) die erbrachten Aufwände zu einem vereinbarten Tagessatz ab. Damit legt der Vertrag nicht die zu entwickelnde Funktionalität fest. Der Auftraggeber kann während des Projektverlaufs lernen, welche Funktionalität er wirklich braucht und die Entwicklung entsprechend beeinflussen, was der Idee von Scrum entgegenkommt.
3. Bezahlung pro Sprint
Neben Time & Material vs. Festpreis gibt es noch eine weitere Ebene, in die Verträge unterteilt werden können. Es wird juristisch unterschieden, ob man ein Werk erstellt oder eine Dienstleistung erbringt. Beim Erstellen eines Werkes ist der Anbieter insbesondere gewährleistungspflichtig – er muss also Mängel (Bugs) auf seine Kosten beheben. Häufig wird Werk mit Festpreis und Dienstleistung mit Time & Material gleichgesetzt, was aber wenig sinnvoll ist.
Geht man von dieser Unterteilung aus, kann für jeden Sprint ein eigener Dienstvertrag mit Festpreis geschlossen werden. Ein solcher Vertrag reduziert den Vertragsaufwand. Allerdings setzt diese Form Vertrauens zwischen Auftraggeber und Auftragnehmer voraus. Diese Form des Vertrags entspricht den Prinzipien von Scrum (Zusammenarbeit vor Vertragsverhandlung). Für den Auftraggeber ist das Risiko begrenzt (maximal ein Sprint) und ist einfach umzusetzen. Der Auftragnehmer hat den Vorteil, sein Geld auch zu erhalten, wenn die Erwartungen des Auftraggebers zunächst nur teilweise erfüllt werden.
Die drei Beispiele zeigen, dass es keinen perfekten agilen Vertrag gibt, sondern auch hier der Einzelfall entscheidet. Agile und Scrum erfordern eine enge Zusammenarbeit von beiden Seiten sowie entgegengebrachtes Vertrauen. Das muss sich im Vertrag widerspiegeln, denn nur so kommen die Vorteile und die Flexibilität von Scrum zum Tragen.
*Rock, Stefan; Pieper. Fritz-Ulli (2017): Agile Verträge – Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche. dpunkt Verlag, Heidelberg.