Agile Verträge: Rechtssicherheit bei Scrum | IT-Medienrecht

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, wodurch Unsicherheiten entstehen.

Dabei ist die grundlegende Idee agiler Methoden rechtlich durchaus erfassbar. Voraussetzung ist, dass der Vertrag die iterative Vorgehensweise und die laufende Einbindung des Auftraggebers klar abbildet. Ein wichtiger Aspekt ist die Balance zwischen Flexibilität und Rechtssicherheit. So können beide Parteien auf Änderungen reagieren, ohne endlosen Nachverhandlungen ausgesetzt zu sein.

Grundlagen Agiler Arbeitsmethoden

Agiles Arbeiten setzt auf kurze Entwicklungszyklen, sogenannte Sprints. In diesen werden kleine, gut umsetzbare Schritte definiert. 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, da Fehler schneller erkannt und korrigiert werden können. Andererseits erfordert es eine intensive Kommunikation und klare Prozesse. Dadurch wird vermieden, dass sich iterative Änderungen und vertragliche Pflichten widersprechen. Insbesondere die Frage, wie der Leistungsumfang definiert und abgenommen wird, ist entscheidend, um Streitigkeiten über den Endzustand der Software zu vermeiden.

Vorteile und Herausforderungen für Auftraggeber

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. Schnelle Iterationen können dann ins Leere laufen. Als Anwalt betone ich daher die Notwendigkeit einer klaren Festlegung der Rollen und Verantwortlichkeiten im Vertrag. So kann niemand im Ernstfall behaupten, seine Mitwirkung sei nicht eingefordert oder nicht vertraglich geregelt gewesen.

Vertragliche Gestaltung Agiler Projekte

Wer Agilität rechtskonform in ein Projekt integrieren will, sollte in der Vertragsphase wichtige Punkte regeln. Dazu gehört:

• Wie mit sprintbezogenen Abnahmen umgegangen wird.
• Wie veränderte Funktionswünsche berücksichtigt werden.
• Wie eine dynamische Priorisierung von Anforderungen erfolgt.

Damit lässt sich der Prozess strukturieren, ohne das iterative Grundprinzip zu ersticken. Letztlich schafft eine solche vertragliche Einbindung auch Vertrauen beim Auftraggeber. Er kann sicher sein, dass trotz Flexibilität ein verbindlicher Rahmen existiert.

Agile Methoden im Projektumfeld

Agiles Arbeiten zeichnet sich durch häufige Feedback-Schleifen und zeitlich kurz getaktete Iterationen (Sprints) aus. Zudem erfolgt eine stete Anpassung des Product Backlogs an aktuelle Anforderungen. 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. Dies gilt insbesondere, 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.

Inkrementelle Entwicklung und Anforderungen

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. Diese werden unmittelbar mit dem Auftraggeber (Product Owner) abgestimmt.

Dabei ändern sich Anforderungen nicht nur, sie werden verfeinert oder neu priorisiert. Dies ist in starren Festpreisverträgen schwer abzubilden. 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. Andere Aufgaben müssen dann verschoben werden. 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 nicht zur Folge haben, dass dem Auftraggeber jede Kostenkontrolle entgleitet. Vielmehr können regelmäßige Sprint-Reviews in den Vertrag aufgenommen werden. Bei diesen werden einerseits die Ergebnisse präsentiert und andererseits Budget oder Funktionen gemeinsam evaluiert. 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, da 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. Zusätzliche Features gelten dann als optionale Pakete.

Kombination beider Vertragsarten

Viele Mandanten, die ich berate, sind überrascht, dass eine Kombination beider Vertragsarten durchaus sinnvoll sein kann. Beispielsweise kann 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. Dadurch entsteht ein Teil des geschuldeten Werkes quasi sukzessive. So wird eine Stück-für-Stück-Fertigstellung ermöglicht, ohne auf Agilität verzichten zu müssen.

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, da dieses schon nach wenigen Sprints überholt sein könnte.

Dennoch ist es in der Vertragsgestaltung wichtig, wenigstens einen groben „Scope“ festzulegen. So wissen beide Seiten, 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.

Vermeidung von Unstimmigkeiten

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. So kann man Änderungen und neue Ideen sofort integrieren, 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.

Kombinierte und flexible Vergütungsmodelle

Eine gängige Lösung besteht in der Kombination: Ein Grundbudget, das auch einen Risikopuffer enthält, soll die wesentlichen Anforderungen abdecken. Zusätzliche Wünsche oder starke Veränderungen werden nach Time & Material abgerechnet. 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. Hier erfolgt die Abrechnung zwar nach Aufwand, aber ein Oberlimit (Cap) wird gesetzt, 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. So entstehen keine Diskussionen über abrechnungsfähige Tätigkeiten.

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 bei agilen Projekten

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. Die andere Partei erachtet hingegen die fortlaufende Erbringung von Entwicklungsleistungen als ausreichend. 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.

Teilabnahmen und Mängelklassifizierung

Wer ein agiles Projekt in Sprints aufteilt, kann für jedes Inkrement eine Teilabnahme vorsehen. Nach deren Ablauf wird ein Sprint-Ergebnis offiziell abgenommen oder gerügt. 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. So ist sofort erkennbar, wie schnell Probleme behoben werden müssen.

Gerade im agilen Umfeld ist schnelles Feedback entscheidend. Wer beispielsweise 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 (SLAs) 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 auch nach Fertigstellung kontinuierliche Updates oder Bugfixes erwartet, 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.

Transparenz durch SLAs

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. Gerade im agilen Kontext ist das Projektende nicht immer eindeutig definiert. 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. Daher werden am liebsten keine konkreten Milestones oder Festpreise zugesagt. 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: Der Entwickler fordert Flexibilität, 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. Der Auftraggeber befürchtet, irgendwann ein Vielfaches des ursprünglichen Budgets zahlen zu müssen.

Lösungsansätze für das Spannungsfeld

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. Nur so haben beide Seiten ein gemeinsames Verständnis von Zielen, Pflichten und Verantwortungen. 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.