a Randstad company
Login
© Adobe Stock / Felix

Agil – aber richtig: vertragliche Ausgestaltung und agiler Festpreis

Agile Projekte in der Praxis – Teil 2

26.07.2018
Kristian Borkert – Rechtsanwalt und freiberuflicher Autor
Artikel teilen:

In Teil 1 unserer Serie „Agil – aber richtig: Wahl des passenden Vertragstyps“ sind wir auf grundsätzliche Überlegungen zur Wahl der passenden Vertragsform für agile Projekte eingegangen. Nun stellt sich die Frage, wie sich die agile Projektorganisation in die konkrete Vertragsgestaltung übersetzen lässt. Denn die typische Organisation in Sprints, die hohe Unschärfe bezüglich der Anforderungen sowie die Dynamik der Änderung der Anforderungen wirken sich auf die vertragliche Umsetzung genauso aus wie auf die Preisgestaltung.

Verträge dürfen für den Auftragnehmer nicht nur zum Ziel haben, bei Erfüllung Geld zu erhalten. Vielmehr geht es darum, den Rahmen für die gemeinsame Zusammenarbeit festzulegen. Denn Auftraggeber und Auftragnehmer wollen gemeinsam das Projektziel erreichen. Sie wollen gemeinsam eine funktionierende Lösung schaffen, die die Geschäftsprozesse des Auftraggebers bzw. dessen Geschäftsmodell maximal gut unterstützt. Dieses Projekt als gemeinsame Unternehmung kann ergo als ein „virtuelles Joint Venture“ bezeichnet werden.

Die Zusammenarbeit muss vertraglich und kaufmännisch so ausgestaltet werden, dass alle Beteiligten auch tatsächlich in einem Boot sitzen und auf das Projektziel zusteuern. Eine so starke Fokussierung des Teams gelingt nur, wenn es einen Anreiz gibt, besonders gut und schnell durch das Ziel zu fahren. Im umgekehrten Fall bedeutet dies aber auch, dass alle nasse Füße bekommen, wenn das Boot nicht rechtzeitig ankommt.

Freelancing-Verträge für Scrum & Co. in der Praxis

In Theorie und Praxis gibt es sehr unterschiedliche Ansätze, wie Scrum-Projekte vertraglich umgesetzt werden.

Ein Ansatz ist, dass je Sprint ein (Mini-) Werkvertrag geschlossen wird. Diese Variante ist sehr nah an dem inkrementellen Entwicklungsprozess von Scrum. Sie setzt voraus, dass nach jedem Sprint auch ein verwendbares Ergebnis steht. Allerdings gibt es durch den hohen Verwaltungsaufwand viele Nachteile. In der Praxis wird daher das Projekt laufen gelassen. Es ist einfach zu zeitaufwendig, sich für jeden Sprint, der in der Regel zwei, drei oder vier Wochen dauert, detailliert Gedanken über den Vertragsinhalt zu machen und eine Abnahme durchzuführen. Vielfach fallen am Ende aber Vertrag und Wirklichkeit auseinander. Sofern jedoch andere Ansätze gemeinsam mit dem Vertragspartner nicht umgesetzt werden können, ist ein Werkvertrag pro Sprint eine gangbare Möglichkeit.

Praktikabler ist es, einen Werkvertrag über das gesamte (Groß-)Projekt abzuschließen. Eine Variante hierzu ist es, den Elefanten in mehrere Scheiben zu schneiden. Gerade bei Großprojekten mit längeren Laufzeiten bietet es sich an, in einem Rahmenvertrag die Spielregeln für das gesamte Projekt abzustecken und sukzessive einzelne Phasen z.B. MVP (Minimum Viable Product) sowie folgende Releases erst verbindlich zu beauftragen, wenn die Sicht darauf klarer ist. Beide genannten Varianten können auch als agiler Festpreis (siehe nächster Abschnitt) vereinbart werden.

Selbstverständlich können Scrum-Projekte auch als Dienstleistung vereinbart werden, z.B. wenn nur die Leistung eines Scrum-Master benötigt wird. Geht es um die Integration einer externen Ressource in das Scrum-Team des Auftraggebers, kann ebenfalls eine Arbeitnehmerüberlassung in Betracht kommen.

Auch ein Gesellschaftsvertrag kann einem Scrum-Projekt zugrunde liegen, sofern das Scrum-Team mit dem Ziel arbeitet, ein Produkt gemeinsam zu entwickeln, zu bauen und auszuliefern. Dabei kann man an die typische Start-up-Situation denken. Es können sich aber auch zwei Unternehmen als Arbeitsgemeinschaft/Konsortium zusammenschließen, um einen größeren Auftrag zu erhalten.

Natürlich treten die fünf Varianten auch in Kombination auf. Beispielsweise kann ein Spezifikationsprojekt, eine Ramp-up-Phase oder die Erstellung eines MVP als Dienstleistung vorgeschaltet werden. Sobald die Produktvision hinreichend konkret und mit User Stories hinterlegt ist, schließen die Partner einen Werkvertrag.

Festpreis trotz agiler Methoden

Häufig wird zwischen den Parteien über einen Festpreisvertrag verhandelt. Die Bezeichnung ist jedoch unglücklich gewählt. Denn ein Fest- oder Pauschalpreis ist lediglich eine Preisabrede und kein Vertragstypus. Ebenso verhält es sich beim agilen Festpreis. Dabei geht es darum, die Produktvision hinreichend zu konkretisieren, sodass ein Budget und die Projektlaufzeit vernünftig festgelegt werden können. Im Kern ist der agile Festpreis eher eine Budgetobergrenze als ein Pauschalpreis.

Eingangs wird die Vision des Produktes definiert und auf die grobe Ebene der Epics heruntergebrochen. Ein Epic ist die Beschreibung einer Anforderung an eine neue Software auf einer hohen Abstraktionsebene. Im nächsten Schritt werden ein bis fünf Epics, die gut greifbar sind, mit User Stories hinterlegt. Die detaillierten User Stories dienen als Referenz für die vergleichende Schätzung des Gesamtprojektes. In einem Workshop mit allen am Projekt Beteiligten, d.h. der Fachbereich des Auftraggebers, die IT des Auftraggebers, ggf. der Einkauf und der Projektpartner, sollte der Projektscope auf dieser Basis diskutiert und gemeinsam transparent geschätzt werden.

Darauf basierend legen die Partner die Risikoverteilung fest und definieren, unter welchen Bedingungen sie sich nach der sog. Checkpoint-Phase, zumeist vier bis sechs Sprints, zum Erproben des Teams und der Zusammenarbeit, im schlimmsten Fall fair trennen würden.

Sie legen weiter fest, wie sie mit Scope-Änderungen umgehen werden. Zuletzt einigen sich die Partner auf ein Motivations- und Zusammenarbeitsmodell, welches die Interessen der Partner auf den gemeinsamen Erfolg des Projektes synchronisiert. Dazu werden zum Scope- Management Mechanismen wie „money for nothing“ oder „change for free“ sowie ein motivierender „gain share“ abgestimmt. Im Ergebnis schaffen die Vertragspartner die notwendigen Rahmenbedingungen, um das Projekt rechtzeitig und im Rahmen des Budgets mit einem änderungsrobusten Preismodell abzuliefern. Für die vertragliche Struktur empfiehlt sich insbesondere bei größeren, länger laufenden Projekten ein modularer Aufbau.

in Anlehnung an Opelt, Andreas: in sechs Schritten zum Agilen Festpreis: In Projektmagazin, 6/2014

In der Regel möchte ein Vertragspartner seine Allgemeinen Geschäftsbedingungen verwenden. Sie gelten üblicherweise nachrangig zu den Projekt- und Rahmenverträgen. Im Rahmenvertrag oder Master Service Agreement (MSA) werden die allgemeinen Themen zum Projekt vereinbart: Zusammenarbeit, Budget, Risk- und Gain-Share, Kündigung, Abnahme, Datenschutz, Nutzungsrechte, Haftung etc.

Basierend auf dem Rahmenvertag können die Parteien dann je nach Leistung und Phase Projektverträge bzw. Statements of Work (SoW) unterzeichnen und die jeweilige Leistung verbindlich beauftragen. Ein SoW enthält initial die genaue Leistungsbeschreibung, den Umfang, die geplanten Ressourcen, die Epics und User Stories für die Phase, die darauf basierende Schätzung von Zeit und Budget für die Phase etc. Durch den modularen Aufbau erhalten die Vertragspartner maximale Stabilität der Rahmenbedingungen bei hoher Flexibilität der Leistung. Bei kleineren, überschaubaren Projekten kann es effizienter sein, nur ein Vertragsdokument zu vereinbaren.

Fazit: Agiles Angebot als Wettbewerbsvorteil

Agile Methoden und die vorgestellten Vertragskonzepte bieten leistungsstarken Freelancern enorme Möglichkeiten, ihre Fähigkeiten in einen messbaren Wettbewerbsvorteil umzuwandeln und dies für den Kunden erlebbar zu machen. Bei größeren Aufträgen bietet es sich an, mit anderen vertrauten Freelancern eine Arbeitsgemeinschaft zu schließen, die den Vertrag hält. Durch die gemeinsame und transparente Schätzung sind Auftraggeber und Auftragnehmer kaufmännisch auf Augenhöhe. Sie können bewusst und ohne größeres Wissensgefälle die Entscheidung für das gemeinsame Projekt treffen.

Der Kunde behält die Kontrolle über sein Projekt auf der Wertschöpfungsebene. Gleichzeitig arbeitet das Projekt hoch transparent. Das schafft Vertrauen. Die Leistungsfähigkeit wird häufig bereits in der Checkpoint-Phase unter Beweis bestellt. Sollte es wider Erwarten doch nicht klappen, wurden partnerschaftliche Bedingungen für ein schnelles Ende vereinbart. „Fail fast, fail cheap“.

Durch das Risk- und Gain-Share-Modell muss der Auftraggeber nicht befürchten, dass der Auftragnehmer bewusst das Angebot kleingerechnet hat und sich später an den Change-Requests gesund stößt. Beide sitzen im gleichen Boot. Agile Methoden und die dargestellten Konzepte zeigen dem Auftraggeber, dass der Auftragnehmer ihn verstanden hat und ihn als Partner auf Augenhöhe wertschätzt. 

Lesermeinungen zum Artikel

2,3 von 5 Sternen | Insgesamt 3 Bewertungen und 4 Kommentare

  • Wie sonst?

    Jan am 30.08.2018 um 14.56 Uhr

    Meiner Meinung nach ein sehr interessanter Artikel, der realistische Ansätze des Vertragswesens bietet.

    @Andreas H. – Das bedeutet "wahrhaft agile" Entwicklung ist nur ohne Verträge, mit vollkommenem gegenseitigen Vertrauen möglich? Ignoriert das nicht ein wenig die menschliche Natur?

  • Interessent

    Burger am 13.08.2018 um 10.08 Uhr

    Ich verstehe die Bedenken der vorigen Kommentatoren, ich finde den Artikel dennoch interessant, weil es ein Thema ist, das immer öfter auftritt und wo ich mich nicht sehr sicher fühle. Das klassische Stundenkontingent scheint mir doch auch eine einfache Möglichkeit zu sein, agil zu arbeiten.

  • Wenn Juristen Projekte gestalten

    Alex B. am 27.07.2018 um 13.21 Uhr

    Mich erinnert das Ganze an eine alte Outsourcing-Weisheit. "Bei der Gestaltung eines Outsourcing-Deals dürfen Kaufleute und Juristen erst ins Boot geholt werden, wenn sich die Ausführenden (= die Experten bzgl. des Outsourcing-Gegenstandes) auf beiden Seiten komplett einig sind. Erst wenn diese Leute sagen, wir könnten ab morgen loslegen, ist es Zeit für Kaufleute und Juristen dem ganzen den notwendigen formalen Rahmen zu geben." Ansonsten werden Outsourcing-Verträge ausverhandelt, die zwar kostengünstig, rechtssicher und perfekt rückabwickelbar sind - aber das erfolgreichen Outsourcing verhindern.

    Dieser Artikel versucht etwas juristisch zu gestalten, dass mehr kaputt macht als das es hilft. Für den Projekterfolg ist entscheidend, dass sich alle Beteiligten mögen, vertrauen, kompetent sind und Spaß bei der Sache haben. Das juristische Rahmenkonstrukt hilft nur die Zahlungsmodalitäten zu klären, und im Falles des Scheiterns sich besser gegenseitig die Schuld in die Schuhe zu schieben. Projekte die so hochgezogen werden, machen mir und den meisten meiner Entwickler-Kollegen meist sehr schnell keinen Spaß mehr. Und dann konnten die Juristen und Erbsenzähler das Projekt endgültig an sich reißen. ==> Epic Fail.

  • Hier hat einer SCRUM nicht verstanden

    Andreas H. am 27.07.2018 um 11.20 Uhr

    Ich bin immer etwas verwirrt wenn man im Rahmen von Scrum oder Agile von Projekt spricht. Das Scrum Manifest spricht nicht umsonst davon ein Framework zu sein, um komplexe Produkte zu entwickeln, sie auszuliefern und zu erhalten. Es ist also ein Prozessrahmenwerk, nicht mehr und nicht weniger.

    Definition eines Projekts = Ein Projekt ist ein zielgerichtetes, einmaliges Vorhaben, das aus einem Satz von abgestimmten, gesteuerten Tätigkeiten mit Anfangs- und Endtermin besteht. Dies trifft in SCRUM lediglich auf den Sprint zu, dort wird auch der Begriff Projekt erwähnt.

    Und dort liegt die Krux. Agil sein bedeutet eben nicht, dass Contractor-Control Denken mittels dem z.B. Wasserfall Modell in diverse Miniwasserfälle aufzuteilen. Leider ist alles was in diesem Artikel steht, die Verfestigung dieser Denkweise! In der Realtität sieht es jedoch leider genau so aus, das vor allem in großen Firmen noch immer in Projekten gedacht wird. Ein Lenkungskreis (ich nenne sie gerne den Jedirat) sitzt um eine Glaskugel und entscheidet über die Vergabe und Initierung von Projekten. Ähnlich wie der Jedirat (der weder die Nähe eines der größten Sith und seinem Schüler erkennen konnten, ist auch der Lenkungskreis in beinahe jedem Top30 Konzern in dem ich gearbeitet habe) völlig planlos was die wirkliche Umsetzung und Erstellung von Assets im Rahmen einer Enterprise Architektur angeht. Aber genau diese bewerten dann das Projektvorgehen später und das häufig unter dem Paradigma: Ist das Projekt im (ursprünglich geplanten) Scope und vor allem Budget, aber eben nicht welchen Wert hat es uns gebracht!

    Softwareentwicklung bedeuten IMMER Risiko und Unsicherheit, wer das mit Werksverträgen, fixen Preisen und eine "Gewerkmentalität" versucht in Verträge zu gießen, hat in den letzten 30 Jahren nie in der IT gearbeitet. 60 Prozent der täglichen Arbeit in einem Sprint ist Kommunikation und das Lernen von neuen Fakten und damit Anpassung des Produkts und nicht wie häufig gedacht, coden coden coden. Genau diese Arbeit ist nicht in Form eines Gewerkes fassbar, es sei dann man ist Orakel. Exakt diese Erkenntnis hat doch dazu geführt, dass SCRUM überhaupt entstanden ist. SCRUM hat doch gerade den Charme, dass ich jederzeit das Produkt nicht mehr weiterentwickeln kann, wenn ich meine Produktidee nicht mehr weiterpivotieren möchte. Das ist doch die Antrittspremisse von SCRUM. Lerne und iteriere dein Produkt um den Wert zu maximalisieren. Wie soll ich als Zulieferer Dinge schätzen (am besten auf halbjahres Basis), die sich jederzeit ändern können und eben auch sollen?

    Diese Denkweise reduziert eben den Zulieferer auf einen Erfüllungsgehilfen oder Codemonkey und etliches innovatives Potential bleibt auf der Strecke.

    Aber natürlich hat der Artikel seine Relevanz, da vor allem in Deutschland die Angst vor Kontrollverlust und die Risikoaversion extrem hoch sind. Nur hat dies mit Agile und SCRUM wenig zu tun. Vorallem lässt man eigentlich 85% der Chancen, die einem ein agiles Mindset ermöglicht, außen vor. Gerade was Industrie 4.0 und die Digitalisierung angeht, ist eine wie im Artikel dargestellte Vorgehensweise leider der Versuch auf autonomes Fahren mit der Ausbildung von Fahrlehrern zu reagieren. Ich hätte mir in diesem Artikel eine etwas diversifizierter Meinung gewünscht, denn so liesst man diesen Artikel und denkt, man wäre "agile" wenn man in solchen Konstrukten Verträge schließt.

    Antwort von der GULP Redaktion

    Lieber Andreas H.,

    vielen Dank für Ihren Kommentar. Sie haben vollkommen Recht: es reicht nicht, wenn man den Vertrag nur mit dem Label "agil" abschließt, die Arbeitsweise muss in erster Linie gelebt werden. Aber uns war wichtig zu zeigen, wie man agile Arbeitsweisen bei einer Freelancer-Beauftragung in geeignete Vertragsbahnen gießen kann. Zur Begrifflichkeit: Mit Projekt meinten wir eher, die Beauftragungsart, einen Freelancer an Bord zu holen und mit diesem einen Vertrag abzuschließen. Ob dieser dann an einem (Wasserfall-)Projekt arbeitet oder agil in einem Framework tätig ist, steht auf einem ganz anderen Blatt.

    Ihr GULP Redaktion

Weitere Kommentare anzeigen

Ihre Meinung zum Artikel

Bitte verwenden Sie keine Links in Ihrem Kommentar.

Ihr Kommentar wird zunächst geprüft. Möchten Sie informiert werden, wenn er veröffentlicht wurde?
Bitte tragen Sie dazu Ihre E-Mail-Adresse ein:
Wir konnten Ihre Bewertung leider nicht speichern. Bitte geben Sie zuerst Ihr Feedback ab.
Lieber Leser, vielen Dank für Ihr Feedback.
Ihre Bewertung für den Artikel wurde gespeichert. Wir prüfen Ihren Kommentar bezüglich Netiquette und Datenschutzrichtlinien und veröffentlichen ihn danach in Kürze. Sie werden von uns per E-Mail darüber benachrichtigt.
Ihre GULP Redaktion.

Ähnliche Artikel