Vertragsgestaltung im Kontext agiler Arbeitsmethoden: Scrum und Co.

Agiles Arbeiten und seine Bedeutung

Agile Arbeitsmethoden wie Scrum, Kanban oder Extreme Programming sind längst etablierte Vorgehensweisen in der Softwareentwicklung und darüber hinaus. Unternehmen greifen zunehmend auf iterative Prozesse und flexible Planungen zurück, um schnellere Ergebnisse zu erzielen und besser auf neue Anforderungen reagieren zu können. Als Rechtsanwalt mit Schwerpunkt auf IT-Verträgen sehe ich oft, dass diese Agilität in Vertragswerken nicht ausreichend berücksichtigt wird und dadurch Unsicherheiten entstehen. Dabei ist die grundlegende Idee agiler Methoden rechtlich durchaus erfassbar, sofern der Vertrag die iterative Vorgehensweise und die laufende Einbindung des Auftraggebers klar abbildet. Ein wichtiger Punkt ist, die richtige Balance zwischen Flexibilität und Rechtssicherheit zu finden, damit beide Parteien auf Änderungen reagieren können, ohne endlosen Nachverhandlungen ausgesetzt zu sein.

Agiles Arbeiten setzt auf kurze Entwicklungszyklen (Sprints), in denen kleine, gut umsetzbare Schritte definiert werden. Diese Vorgehensweise ermöglicht es, regelmäßig Feedback einzuholen und Anpassungswünsche sofort zu berücksichtigen. In der Praxis führt dies häufig zu einer höheren Qualität des Endprodukts, weil Fehler schneller erkannt und korrigiert werden können. Andererseits erfordert es eine intensive Kommunikation und klare Prozesse, damit sich iterative Änderungen und vertragliche Pflichten nicht widersprechen. Insbesondere die Frage, wie der Leistungsumfang definiert und abgenommen wird, ist ein wesentlicher Faktor, um Streit über den Endzustand der Software zu vermeiden.

Gerade für Auftraggeber bietet Agilität den Vorteil, Kosten und Funktionen laufend kontrollieren zu können. Es entsteht kein starrer Projektplan, der erst am Schluss überprüft wird – stattdessen gibt es kontinuierliche Zwischenergebnisse. Allerdings müssen Unternehmen bereit sein, aktiv mitzuwirken und dem Entwicklerteam fortwährend Feedback zu liefern. Fehlt diese Bereitschaft, verpufft der große Vorteil der hohen Flexibilität und schnelle Iterationen können ins Leere laufen. Als Anwalt betone ich daher die Notwendigkeit einer klaren Festlegung der Rollen und Verantwortlichkeiten im Vertrag, damit niemand im Ernstfall behauptet, seine Mitwirkung sei nicht eingefordert oder nicht vertraglich geregelt gewesen.

Wer Agilität rechtskonform in ein Projekt integrieren will, sollte in der Vertragsphase regeln, wie mit sprintbezogenen Abnahmen, veränderten Funktionswünschen und einer dynamischen Priorisierung von Anforderungen umgegangen wird. Damit lässt sich der Prozess strukturieren, ohne das iterative Grundprinzip zu ersticken. Letztlich schafft eine solche vertragliche Einbindung auch Vertrauen beim Auftraggeber, der sicher sein kann, dass trotz Flexibilität ein verbindlicher Rahmen existiert.

Bedeutung agiler Methoden im Projektumfeld

Agiles Arbeiten zeichnet sich durch häufige Feedback-Schleifen, zeitlich kurz getaktete Iterationen (Sprints) und eine stete Anpassung des Product-Backlogs an aktuelle Anforderungen aus. Der klassische Festpreisvertrag, wie er oft im Wasserfall-Modell zum Einsatz kommt, wirkt auf den ersten Blick schwer vereinbar mit einer Vorgehensweise, die sich dauernd weiterentwickelt. Dennoch zeigt meine Erfahrung als Rechtsanwalt, dass agile Projekte häufig sehr erfolgreich sind, wenn beide Seiten ihre Rolle im Prozess verstehen und vertraglich absichern. Die iterative Arbeitsweise sorgt nicht nur für schnellere Teilresultate, sondern fördert auch eine enge Kommunikation zwischen Entwicklerteam und Auftraggeber.

Eine große Stärke agiler Methoden liegt in der inkrementellen Entwicklung. Kleine Arbeitspakete werden in Sprintzyklen, die meist zwei bis vier Wochen dauern, abgearbeitet und unmittelbar mit dem Auftraggeber (Product Owner) abgestimmt. Dabei ändern sich Anforderungen nicht nur, sie werden verfeinert oder neu priorisiert, was in starren Festpreisverträgen schwer abzubilden ist. Genau hier setzt jedoch der vertragliche Knackpunkt an: Wenn Anpassungen jederzeit möglich sein sollen, muss geregelt sein, ob und wann dadurch zusätzliche Kosten oder Zeitaufwände entstehen.

Praktisch wirkt sich Agilität zum Beispiel so aus, dass ein Feature, das zunächst als nebensächlich galt, sich plötzlich als zentral herausstellt, sodass andere Aufgaben verschoben werden müssen. In einem rein wasserfallorientierten Projekt wäre das eine klassische „Änderung“, die einen aufwändigen Nachtrag bräuchte. In einem agilen Projekt wird dieser Wechsel im Backlog vermerkt, neu priorisiert und im nächsten Sprint berücksichtigt. Damit einher geht allerdings die Frage, wie Vergütung und Haftung geregelt werden, wenn das Gesamtprojekt Zielkataloge hat, die sich fortwährend ändern.

Die dynamische Natur agiler Projekte darf also nicht zur Folge haben, dass dem Auftraggeber jede Kostenkontrolle entgleitet. Vielmehr können regelmäßige Sprint-Reviews in den Vertrag aufgenommen werden, bei denen einerseits die Ergebnisse präsentiert und andererseits Budget oder Funktionen gemeinsam evaluiert werden. So lassen sich Konflikte minimieren und transparente Entscheidungen treffen, ohne dass agiles Vorgehen in langwierigen Formalitäten erstickt.

Frage der Vertragsart: Dienst- oder Werkvertrag?

Im deutschen Recht wird oft entschieden, ob ein IT-Projekt als Dienstvertrag (§§ 611 ff. BGB) oder als Werkvertrag (§§ 631 ff. BGB) zu qualifizieren ist. Beim Dienstvertrag ist eine sorgfältige Tätigkeit geschuldet, während beim Werkvertrag ein konkretes Ergebnis (Werk) abzuliefern ist. In klassischen Entwicklungsprojekten dominieren meist Werkverträge, weil ein fertiges Softwareprodukt erwartet wird. In agilen Szenarien wirkt ein reiner Werkvertrag jedoch manchmal zu rigide, da der Umfang sich laufend ändert. Trotzdem kann man agile Elemente in einem Werkvertrag verankern, indem etwa der zu erstellende Kernumfang definiert wird, während zusätzliche Features als optionale Pakete gelten.

Viele Mandanten, die ich berate, sind überrascht, dass eine Kombination beider Vertragsarten durchaus sinnvoll sein kann. So kann beispielsweise ein Mindestprodukt (MVP) als werkvertraglicher Teil festgesetzt werden, für den der Auftragnehmer ein konkretes Ergebnis schuldet. Darüber hinausgehende Anpassungen oder neue Anforderungen könnten dann nach Dienstvertragslogik (Time & Material) abgerechnet werden. Auf diese Weise erhält der Auftraggeber ein Mindestmaß an Planungssicherheit, während der Entwickler die nötige Flexibilität behält, um rasch zu reagieren.

Ein gängiges Missverständnis entsteht, wenn der Auftraggeber glaubt, die fortlaufende agile Arbeit führe automatisch zu einem reinen Dienstvertrag und er verliere seinen Anspruch auf ein betriebsbereites Produkt. Tatsächlich lassen sich aber sehr wohl werkvertragliche Elemente im Sprints-Modell abbilden: Jede Iteration liefert ein „Inkrement“, das abgenommen werden kann, wodurch ein Teil des geschuldeten Werkes quasi sukzessive entsteht. So wird eine Stück-für-Stück-Fertigstellung ermöglicht, ohne dass man auf Agilität verzichten muss.

Die Kunst besteht darin, vertraglich festzulegen, welche Sprints oder Features die Werkkomponenten ausmachen und wie einzelne Abnahmen aussehen. Gerade wenn ein Projekt erhebliche Summen umfasst, ist es für beide Seiten vorteilhaft, die Rechtsfolgen klar zu benennen. Hierzu gehört etwa die Frage, was passiert, wenn eine Teilleistung mangelhaft ist oder ein Sprint nicht wie geplant fertig wird. Durch eine klare Regelung bleiben die Vorteile agiler Methoden bestehen, während die rechtliche Sicherheit gewahrt wird.

Leistungsumfang und Scope-Definition

Eine knifflige Frage ist die Beschreibung des Leistungsumfangs in einem agilen Projekt. Ein rein agiler Ansatz sieht vor, Anforderungen – das Product Backlog – dynamisch zu priorisieren und fortlaufend zu verändern. Häufig existiert kein umfassendes Pflichtenheft, weil dieses schon nach wenigen Sprints überholt sein könnte. Dennoch ist es in der Vertragsgestaltung wichtig, wenigstens einen groben „Scope“ festzulegen, damit beide Seiten wissen, welche Ziele angestrebt werden und wo die Grenzen liegen. Solch ein „Scope“ kann beispielsweise in Form von Epics oder Hauptfunktionen formuliert werden, die in jedem Fall zu liefern sind.

Im Streitfall hilft ein definierter Rahmen, klarzumachen, was eigentlich Teil des vereinbarten Projekts war und was als Neuerung gilt. Wer diesen Schritt auslässt, riskiert, dass sich am Ende Unstimmigkeiten darüber ergeben, ob bestimmte Features geschuldet sind oder nicht. Dabei muss keineswegs jede Kleinigkeit festgeschrieben werden; gerade meine Mandanten im Tech-Bereich bevorzugen es, flexibel auf Kundenwünsche zu reagieren. Trotzdem sollte man mindestens definieren, welche Kernanforderungen zwingend in einem MVP enthalten sein müssen.

Sobald Zwischenergebnisse existieren, können diese vertraglich als Teilabnahmen („Abnahmen von Sprint-Increments“) geregelt werden. Dabei erhält jede erfolgreich abgeschlossene Iteration den Charakter einer werkvertraglichen Teilleistung, die gesondert geprüft wird. Dieses Vorgehen beugt Unklarheiten vor, weil in jedem Sprint-Review transparent wird, welche Anforderungen umgesetzt wurden und welche Mängel möglicherweise noch bestehen. Darüber hinaus schafft es eine Dokumentationsbasis, die später als Beweis für die erbrachten Leistungen dient.

Als Rechtsanwalt empfehle ich, die Dokumentation der Sprints auch zur Fortschrittskontrolle zu nutzen. Damit lassen sich Änderungen im Backlog lückenlos nachvollziehen. Gelingt das, so werden nachträgliche Vorwürfe, ein Feature sei „vergessen“ worden, deutlich unwahrscheinlicher. Stattdessen wird von Anfang an klar, dass Änderungen immer Teil eines geregelten Abstimmungsprozesses sind, den beide Parteien aktiv mitgestalten.

Vergütung in agilen Projekten

Eine wichtige Frage betrifft die Vergütungsstruktur, denn der klassische Festpreisvertrag steht oft dem agilen Gedanken diametral entgegen. In vielen agilen Projekten wird „Time & Material“ (nach Aufwand) abgerechnet, weil man so Änderungen und neue Ideen sofort integrieren kann, ohne zu jedem Feature eine Nachtragsverhandlung führen zu müssen. Dieses Modell kann allerdings die Budgetsicherheit des Auftraggebers beeinträchtigen. Umgekehrt wünschen sich manche Mandanten einen Festpreis, um finanziell nicht ins Ungewisse zu geraten.

Eine gängige Lösung besteht in der Kombination: Ein Grundbudget, das auch einen Risikopuffer enthält, soll die wesentlichen Anforderungen abdecken, während zusätzliche Wünsche oder starke Veränderungen nach Time & Material abgerechnet werden. So bleibt das Projekt beweglich, ohne dass der Auftraggeber fürchten muss, sämtliche Änderungen führen zu unkontrollierten Mehrkosten. Teilweise wird auch für einen definierten Teilbereich, etwa das MVP, ein Festpreis vereinbart, während Erweiterungen agil weiterentwickelt werden.

Ein weiterer Ansatz ist das Cap-Preis-Modell, wo die Abrechnung zwar nach Aufwand erfolgt, aber ein Oberlimit (Cap) gesetzt wird, das nicht überschritten werden darf. Damit bewahrt man einen größtmöglichen Spielraum in der Entwicklung, hält aber dennoch die Kosten kalkulierbar. Aus anwaltlicher Sicht rate ich dazu, schon im Vertrag zu regeln, wie genau die Arbeitszeiten dokumentiert und übermittelt werden, damit keine Diskussionen über abrechnungsfähige Tätigkeiten entstehen.

Gerade im agilen Umfeld ist es zudem hilfreich, wenn man in regelmäßigen Abständen, beispielsweise bei jedem Sprint, prüft, ob der aufgelaufene Aufwand noch innerhalb des geplanten Budgets liegt. So wird das Thema Geld nicht erst am Ende zum Knackpunkt, sondern fließt kontinuierlich in die Projektsteuerung ein. Für beide Seiten ist das ein großer Vorteil, weil es böse Überraschungen verhindert und zu einer realistischen Erwartungssteuerung beiträgt.

Mögliche Haftungsfragen

Haftungsrisiken ergeben sich im agilen Kontext vor allem dann, wenn eine Partei annimmt, dass zu einem bestimmten Zeitpunkt ein konkretes Resultat ohne weitere Absprachen fix geschuldet sei, während die andere Partei die fortlaufende Erbringung von Entwicklungsleistungen als ausreichend erachtet. Als Anwalt sehe ich oft Konflikte, bei denen der Auftraggeber ein fertiges Produkt einklagt, obwohl die Spezifikationen sich im Laufe der Sprints mehrmals verändert haben. Um das zu vermeiden, sollte ein Vertrag klare Regelungen zur Abnahme und Mängelrüge enthalten.

Wer ein agiles Projekt in Sprints aufteilt, kann für jedes Inkrement eine Teilabnahme vorsehen, nach deren Ablauf ein Sprint-Ergebnis offiziell abgenommen oder gerügt wird. Auf diese Weise fällt eine mangelhafte Leistung schnell auf und kann im folgenden Sprint behoben werden. Dieses Vorgehen reduziert die Gefahr, dass am Projektende eine unübersichtliche Liste an Fehlern oder offenen Anforderungen auftaucht. Eine mögliche Fiktion der Abnahme nach einer bestimmten Prüffrist ist außerdem sinnvoll, damit kein Sprint-Output endlos in der Schwebe bleibt.

Eine weitere Frage sind unvorhersehbare Schwierigkeiten, wie Ausfälle bei Drittanbietern oder unklare Abhängigkeiten von externen Bibliotheken. Um späteren Streit zu vermeiden, sollte geregelt sein, dass der Entwickler für solche Fälle nur beschränkt haftet, sofern er die Störung nicht zu verantworten hat. Zudem lohnt es sich, eine Mängelklassifizierung (kritisch, wichtig, geringfügig) zu definieren, damit sofort erkennbar ist, wie schnell Probleme behoben werden müssen.

Gerade im agilen Umfeld ist schnelles Feedback entscheidend. Wer z. B. Fehler monatelang nicht meldet und erst am Schluss reklamiert, erschwert die Mängelbeseitigung und erhöht das Streitpotenzial. Daher empfehle ich, eine regelmäßige Dokumentation und Kommunikation festzuschreiben, um haftungsrelevante Punkte früh und unmissverständlich anzusprechen.

Service-Level-Agreements und Laufzeit

Ein großer Streitpunkt entsteht häufig nach Abschluss des Kernprojekts, wenn Wartungsaufgaben oder fortlaufender Support anfallen. Im agilen Ansatz geht man davon aus, dass Software dauernd fortentwickelt und angepasst wird. Fehlt aber im Hauptvertrag eine klare Regelung zur Weiterbetreuung, kann es sein, dass der Auftraggeber erwartet, auch nach Fertigstellung kontinuierliche Updates oder Bugfixes zu erhalten, während der Entwickler dafür ein neues Honorar wünscht. Dieses Dilemma lässt sich durch ein separates Service-Level-Agreement (SLA) lösen.

SLAs können definieren, innerhalb welcher Zeiträume auf Störungen verschiedener Kategorien reagiert wird und wie hoch die Vergütung für derartige Leistungen ist. Das sorgt für Transparenz und verhindert, dass unklare Erwartungen nach Projektabschluss zu Streit führen. Beispielsweise kann man für kritische Fehler eine Reaktionszeit von wenigen Stunden festlegen, während geringfügige Fehler in einem zyklischen Update abgearbeitet werden. Dabei sollte man auch regeln, ob Patches und Releases im Sinne eines Wartungsvertrags enthalten sind oder ob jeder zusätzliche Feature-Wunsch als neuer Auftrag behandelt wird.

In meiner Praxis empfehle ich Auftraggebern und Entwicklern gleichermaßen, SLA-Regeln früh anzusprechen, weil gerade im agilen Kontext das Projektende nicht immer eindeutig definiert ist. Wenn eine Software stetig weiter ausgebaut wird, kann das Kernprojekt gefühlt „nie“ abgeschlossen sein. Klare SLAs lösen diese Unklarheit, indem sie den Zustand beschreiben, ab dem der Entwicklungsvertrag als erfüllt gilt und die fortlaufende Pflege beginnt. Das sorgt nicht nur für bessere Planbarkeit, sondern stärkt auch das Vertrauensverhältnis, weil jeder weiß, welche Leistungen nach dem eigentlichen Projekt geliefert werden.

Ohne eine solche separate Regelung kann die Erwartung entstehen, dass Entwickler und Auftraggeber in einer dauerhaften Revisionsschleife verharren. Das ist weder effizient noch rechtssicher. Durch ein separates SLA lässt sich hingegen das beste aus dem agilen Grundgedanken nutzen, während die Wartung als eigenständige Leistung zu fairen Bedingungen vereinbart wird.

Verträge zwischen Auftraggeber und Softwareentwicklungshaus: Problematik von Milestones und Festpreisen

In meiner Beratungspraxis begegne ich regelmäßig Projekten, in denen das Softwareentwicklungshaus konsequent agil arbeiten will und daher am liebsten keine konkreten Milestones oder Festpreise zusagt. Für viele Auftraggeber ist das jedoch schwer akzeptabel, da sie mindestens den Umfang und die Kosten eines Kernpakets überschauen möchten. Genau hier entsteht oft eine Pattsituation, bei der der Entwickler Flexibilität fordert, während der Kunde Kalkulationssicherheit wünscht. Meist ist es hochproblematisch, völlig auf Meilensteine zu verzichten, weil dies zu einer planlosen Abrechnung führt und der Auftraggeber befürchtet, irgendwann ein Vielfaches des ursprünglichen Budgets zahlen zu müssen.

Allerdings muss dieses Spannungsfeld nicht unauflösbar bleiben. Als Rechtsanwalt begleite ich gerade einen Fall, bei dem wir eine Mischkalkulation anstreben: Ein definierter Mindestfunktionsumfang wird als Werkvertrag zu einem Festpreis geregelt, sodass der Auftraggeber eine klare Basis hat. Gleichzeitig wird vereinbart, dass alle zusätzlich gewünschten Features oder signifikanten Änderungen am Funktionsumfang iterativ und gegen Time & Material abgerechnet werden. Diese Lösung ermöglicht einerseits das agile Vorgehen und sorgt andererseits dafür, dass der Kunde nicht von unvorhersehbaren Kosten überrascht wird.

In diesem konkreten Projekt haben wir zudem Meilensteine eingeführt, die dem agilen Gedanken entgegenkommen, indem sie auf Sprints oder vergleichbaren Iterationen basieren. Jeder Milestone steht für ein definiertes Teilziel, welches einsetzbare Software beinhaltet. So kann der Auftraggeber kontrollieren, wie viel tatsächlich entstanden ist, und gegebenenfalls Anpassungen noch vornehmen, ohne das gesamte Projekt neu verhandeln zu müssen. Diese Herangehensweise entlastet das Entwicklungshaus, weil es nicht zu jedem kleinen Change eine neue Kalkulation erstellen muss, solange die Grundfunktionen im vorgegebenen Rahmen bleiben.

Gerade in komplexen Projekten ist Transparenz der Schlüssel zum Erfolg. Im erwähnten Fall haben wir eine fortlaufende Budgetübersicht integriert, sodass alle Beteiligten immer sehen, wie weit das Projekt ist und wie viel Budget noch verfügbar ist. Damit verliert niemand den Überblick, und es entsteht ein Klima des Vertrauens. Dabei hilft es ungemein, dass das Entwicklungshaus seine agilen Prozesse offenlegt und erklärt, wie Sprints geplant werden, wie das Backlog organisiert ist und in welchem Rhythmus Reviews stattfinden.

Die meisten Auftraggeber begrüßen diesen Ansatz, weil sie damit sowohl ein Mindestmaß an Sicherheit als auch die Vorteile der agilen Weiterentwicklung erhalten. Als Anwalt ist es mir wichtig, sicherzustellen, dass sowohl die vertraglichen Ziele des Werkcharakters (gewisse fertige Kernelemente) als auch die Agilität (laufende Anpassung, Time & Material bei Erweiterungen) rechtsverbindlich geregelt sind. Auf diese Weise wird Agilität nicht zu einem unkalkulierbaren Risiko, sondern zu einem methodischen Vorteil, der sich in der Vertragsgestaltung widerspiegelt und für beide Seiten ein Win-Win darstellt.

Fazit und Handlungsempfehlungen

Die Integration agiler Methoden wie Scrum in Verträge ist keineswegs ein Widerspruch, erfordert aber sorgfältige Absprachen. Eine präzise Festlegung der vertraglichen Parameter – vom groben Scope über iterative Teilabnahmen bis hin zu Change-Request-Verfahren und SLAs – verhindert Missverständnisse und schafft Rechtssicherheit. Dabei sollte man Dienst- und Werkvertragselemente so kombinieren, dass sowohl die flexible Vorgehensweise berücksichtigt wird als auch klare Ergebnisse entstehen, die sogleich messbar und abnehmbar sind.

Wer einen agilen Ansatz wählt, genießt den Vorteil schneller Feedbackzyklen und fortlaufender Optimierung. Gleichermaßen erhöht dies die Anforderungen an die Kommunikation, denn Auftraggeber müssen regelmäßig priorisieren und Kompromisse eingehen, wenn Budget oder Zeit nicht für alle Ideen reichen. Die Haftungsfragen lassen sich elegant lösen, indem man Zwischenabnahmen für jeden Sprint oder jedes Inkrement vorsieht, Mängel zeitnah meldet und an einer systematischen Dokumentation arbeitet. So ist nachvollziehbar, was bereits umgesetzt wurde und welche Änderungen neu hinzukommen.

Für mich als Anwalt im IT-Bereich zeigen agile Projekte immer wieder, wie wichtig es ist, die Methodik vertraglich sauber abzubilden, damit beide Seiten ein gemeinsames Verständnis von Zielen, Pflichten und Verantwortungen haben. Ein unterschätzter Punkt ist die Abgrenzung zwischen Entwicklungs- und Betriebsphase, um zu klären, ob und wie Wartungs- oder Supportleistungen erbracht werden. Wer das alles regelt, kann sich ganz auf die Vorteile der Agilität konzentrieren und vermeidet rechtliche Stolperfallen.

Letztendlich ist Agilität kein Allheilmittel, doch sie bietet ein dynamisches Vorgehensmodell, das vor allem in schnelllebigen Branchen klare Vorteile bringt. Damit diese Vorteile nicht von Misstrauen oder Rechtsunsicherheit überschattet werden, lohnt es sich, frühzeitig anwaltliche Beratung in Anspruch zu nehmen. Eine solide Vertragsbasis sichert ab, dass iterative Methoden nicht in unübersichtlichem Chaos enden, sondern in einer reaktionsfähigen und erfolgreichen Projektumsetzung.