Im Artikel „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

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 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.