Die zunehmende Technisierung von Unternehmensprozessen bedingt eine steigende Komplexität von IT-Projekten. Teil dieser Entwicklung ist leider auch, dass ein nicht unerheblicher Teil der Projekte anders endet, als ursprünglich geplant – mit Kostenüberschreitungen, anderem Funktionsumfang oder sogar Abbruch.
Gründe für ein Scheitern sind häufig unklare Vertragstypologien, fehlende Projektstrukturen, ungenügende Pflichtenhefte, fehlende Abnahmekriterien, mangelnde Kommunikation oder fehlende Projekterfahrung.
Agile Projektmethoden versuchen einen Teil dieser Fehler zu vermeiden, werfen aber gleichzeitig Fragen nach einer passenden Vertragsgestaltung auf.
1. Rückblick: Klassische Projektmethoden
Bei den klassischen Vorgehensmodellen, zum Beispiel Wasserfall- oder V-Modell, wird die Planungs-/Konzeptionsphase streng von der Implementierungsphase getrennt. Sie konzentrieren sich darauf, bereits zu Beginn eines Projektes die größtmögliche Planbarkeit des Projektes zu erzielen und die Software im Vorfeld klar, eindeutig und vollständig zu beschreiben.
Die Erfahrung aus größeren Projekten belegt jedoch, dass diese zunächst logisch erscheinende Aufspaltung häufig nicht durchgängig praktikabel ist, da sich jedenfalls bei längerer Entwicklungsdauer regelmäßig die Anforderungen des Auftraggebers ändern. Die Folge sind sogenannte Change Requests und oft lebhafte Diskussionen der Vertragsparteien, ob der „Change Request“ nicht doch schon im usprünglichen Leistungsumfang enthalten war.
2. Agile Projektmethoden
Die agilen Projektmethoden gehen einen anderen Weg. Bei ihnen ist von vornherein klar, dass zu Beginn eines Projekts noch nicht alle Details feststehen und im Projektverlauf von den Parteien gemeinsam erarbeitet werden müssen.
Der derzeit wohl populärste Vertreter dürfte Scrum sein. Zu Projektbeginn wird hier zunächst nur eine „Produktvision“ definiert. Die einzelnen Funktionalitäten werden als User Stories in einem Product Backlog gesammelt, welches das initiale Scrum-Projekt beschreibt. Eine User Story ist knapp formuliert und besteht in der Regel aus einer Überschrift und Beschreibung in ein bis zwei Sätzen aus Anwendersicht.
In sogenannten Sprints von maximal 30 Tagen werden diese dann umgesetzt. Es wird zunächst entschieden, wie viele und welche User Stories in einem Sprint abgearbeitet werden können. Sodann werden diese vom Product Backlog in das jeweilige Sprint Backlog eingestellt und anschließend abgearbeitet. Am Ende des Sprints werden dem Auftraggeber die erarbeiteten Stories vorgestellt, die produktiv eingesetzt werden könnten, und in einer Retrospektive analysiert, was für den weiteren Projektverlauf verbessert werden kann. Planung und Konzeption sind somit vollständig in den Projektverlauf integriert.
Schön und gut, aber was bedeutet das agile Vorgehen für die vertragliche Gestaltung?
3. Agile Verträge
Dienstvertrag?
Da zu Beginn eines Projektes zunächst nur eine Produktvision, einige User Stories und keine genaue Leistungsbeschreibung existieren, kommt eine dienstvertragliche Gestaltung (§ 611 ff. BGB) in Betracht, da die Zusammenarbeit mündlich gesteuert und „auf Zuruf“ erfolgt. Nachteil für den Auftraggeber ist, dass die Erfolgsverantwortung – anders als bei einem Werkvertrag – bei ihm und nicht beim IT-Dienstleister liegt. Daher ist jedenfalls auf Kundenseite die Bereitschaft zum Abschluss derartiger Verträge in der Regel überschaubar.
Den dienstvertraglichen Regelungen des BGB fehlt außerdem ein Nachbesserungsanspruch. Dieses müsste also vertraglich vereinbart werden, wird aber trotzdem nicht die gleiche Qualität wie eine Abnahme erreichen.
Gesellschaftsvertrag?
Ebenfalls in Betracht kommt die Bildung einer Gesellschaft bürgerlichen Rechts. Gemäß § 705 BGB verpflichten sich die Gesellschafter, also Auftragnehmer und Auftraggeber, durch den Gesellschaftsvertrag gegenseitig, die Erreichung eines bestimmten Zwecks zu fördern. Zweck in diesem Falle wäre die Erstellung einer Software mit genauer Leistungsspezifikation.
Allerdings sehen die wenigstens Projekte nach Abschluss eine gemeinsame Vermarktung der Software durch die Gesellschafter vor. Diese vertragliche Konstruktion dürfte daher nur für Forschungs- und Entwicklungskooperationen in Betracht kommen.
Werkvertrag!
Bleibt also des Auftraggebers Lieblingskind: der Werkvertrag. Er ist dadurch gekennzeichnet, dass der IT-Dienstleister einen Erfolg schuldet, eine Abnahme erfolgt und eine Gewährleistungszeit besteht.
Aber ist eine derartige Konstruktion bei einem agilen Projekt überhaupt denkbar? Die Erfolgsverantwortung für den Auftragnehmer übernehmbar? Ja!
Zunächst ist die Frage zu beantworten, wie man zu einem Werkvertrag kommt, wenn zu Beginn noch nicht jedes Detail klar ist. Wie soll Erfolg definiert werden? Einerseits ist während der Laufzeit des Projekts der Planungsanteil erheblich: es sind Anforderungsprofile zu ermitteln und zu erstellen, das Projekt als solches ist zu steuern, bestimmte Artefakte zu erstellen und Teilprojektziele zu erreichen, die am Ende zu einem runden Ganzen führen sollen. Auch der einzelne Sprint kann als „Mini-Werk“ angesehen werden.
Obwohl es zu agilen Projekten bisher keine verwertbare Rechtsprechung gibt, die sich mit dieser Frage auseinandergesetzt hat, sprechen gute Argumente für die Möglichkeit einer werkvertraglichen Gestaltung.
Bleibt die Betrachtung, welche Aspekte in einem agilen Vertrag zu regeln wären.
Vorgehensbeschreibung/methodisches Vorgehen
Es sollte zunächst dargestellt werden, nach welchem Vorgehensmodell das Softwareprojekt entwickelt wird. Hier sollte aber nicht nur auf das Modell verwiesen, sondern der Projektablauf skizziert, die Prinzipien beschrieben und die Standardbegriffe der jeweiligen Projektmethode definiert werden. Festzulegen sind auch die Dauer der Sprints und die Zeitpunkte der stattfindenden Meetings. Zwar bedingt dieses Vorgehen, dass der Vertragstext länger wird, stellt aber sicher, dass im Streitfall auch dem Gericht ein umfassendes Bild der Vereinbarungen vorliegt.
Vertragsgegenstand
Zu Beginn eines agilen Projektes besteht lediglich eine Vision des Projektergebnisses und dessen, was Leistungsgegenstand in schuldrechtlichem Sinne sein soll. Die Produktvision sollte dabei unter Berücksichtigung von Zielgruppe, Kundenbedürfnissen, Produktattributen und Wettbewerbsposition so weit konkretisiert werden, dass sich im nächsten Schritt Anforderungen formulieren lassen und dadurch der Projektumfang für beide Vertragspartner kalkulierbar wird.
Mitwirkungsleistungen des Auftraggebers
Die Mitwirkung des Auftraggebers ist das A und O eines agilen Projekts. Es ist aus meiner Sicht daher unabdingbar, dass die Mitwirkungspflichten des Auftraggebers als Hauptpflichten vereinbart werden. Beispielhaft seien aufgezählt: Verpflichtung des Auftraggebers zur Begutachtung der gemeinsam entwickelten User Stories innerhalb eines bestimmten Zeitraums, Teilnahme an den (Abnahme-)Workshops, Zusammenstellung von Mängellisten, Teilnahme entscheidungsbefugter Personen an gemeinsamen Besprechungen. Je konkreter, desto besser.
Dokumentation
Agile Projektmethoden verzichten grundsätzlich auf eine Dokumentation sowie ein Pflichtenheft. Sollte Dokumentation vom Auftraggeber dennoch gewünscht sein, empfiehlt es sich, diese explizit zu vereinbaren und konkret zu benennen. Nicht selten gibt es im Rahmen der Abnahme unterschiedliche Ansichten, welche Dokumentation zu erstellen und zu liefern gewesen wäre.
Abnahme und Gewährleistung
Eines der Grundelemente agiler Projekte ist die regelmäßige Auslieferung und Prüfung von Zwischenergebnissen mittels lauffähiger Software im Rahmen der Sprint Reviews. Dies kann eine bloße Funktionsprüfung oder schon eine Teilabnahme sein. Egal, wie man sich hierzu vereinbart, der Vertrag sollte sich ausdrücklich dazu verhalten. Dann lässt sich auch gleich die Anschlussfrage klären: wann beginnt die Gewährleistungsfrist und wie lange soll sie laufen.
Nutzungsrechte
Allgemein werden die Nutzungsrechte nach Abschluss eines agilen Projekts genauso behandelt wie bei einem klassischen Entwicklungsprojekt. Allerdings entsteht schon mit jedem erfolgreich abgeschlossenen Sprint ein Stück nutzbare Software. Zu regeln ist daher, welche Nutzungsrechte insbesondere bei vorzeitiger Beendigung eines Projekts wem und zu welchem Zeitpunkt zustehen.
Vergütung
Dieser Punkt ist herausfordernd, wenn nicht schlicht „time & material“ vereinbart wird. Möglich ist die Einigung auf einen sogenannten „agilen Festpreises“. Es handelt es sich hier um einen indikativen Maximalpreis, der vom Auftragnehmer auf Basis von geschätzten Anforderungen in sogenannten Story- oder Function-Points errechnet wird.
Dafür wird ein Teil der Anforderungen komplett geplant und der Aufwand anhand der so ermittelten Story- oder Function-Points auf den Rest des Projektes hochgerechnet. Der Auftraggeber kann im Rahmen des Gesamtumfanges der Punkte Anforderungen streichen und für die frei gewordenen Maßeinheiten andere Anforderungen stellen. Die im Laufe des Projektes wegfallenden, sich verringernden oder hinzukommenden Leistungseinsätze werden saldiert.
4. Zusammenfassung
Agile Projekte werden zunehmend Alltag in der Softwareentwicklung. Für die juristische Gestaltung der dazugehörigen Projektverträge gibt es jedoch noch keinen „de facto-Standard“.
Der erste Impuls, dass agile Projekte nur mit einem Dienstvertrag zu vereinbaren sind, ist nicht zwingend. Der Abschluss eines Werkvertrages ist möglich. Dies wird jedenfalls in den allermeisten Fällen dem Wunsch des Auftraggebers entsprechen und ist auch aus Sicht des Auftragnehmers nicht unangemessen, wenn auf oben genannte Aspekte Augenmerk gelegt wird.