Hinweise zur Vertragsgestaltung bei agilen Softwareprojekten

Hinweise zur Vertragsgestaltung bei agilen Softwareprojekten

Seit einigen Jahren sind agile Methoden wie z.B. Scrum bei der Softwareerstellung in aller Munde. Höhere Kundenzufriedenheit sollen sie bringen, weil der Kunde schon früh im Projekt brauchbare Software erhält, und die leidigen „Scope“-Diskussionen sollen vermieden werden. Die Vertragsgestaltung wird dabei zumeist äußerst stiefmütterlich behandelt: Entweder man unterschreibt lediglich einen LOI, oder man nimmt irgendein Muster für einen (herkömmlichen) IT-Projektvertrag. Beides ist, vorsichtig ausgedrückt, suboptimal. Denn bei der Vertragsgestaltung für agile Softwareprojekte gibt es einiges zu beachten. Hier ein paar praktische Hinweise am Beispiel von Scrum:

1.

Die agile Projektmethode sollte im Vertrag ausdrücklich vereinbart werden. Denn für die erfolgreiche Anwendung agiler Projektmethoden ist es unabdingbar, dass der Auftraggeber die agile Projektmethode kennt, im besten Fall bereits Erfahrung damit hat, und vor allem dass er mitmacht. Projekte, bei denen nur der Auftragnehmer nach einer agilen Projektmethode arbeitet und der Auftraggeber erklärt, er könne den agilen Prozess nicht implementieren, sind zum Scheitern verurteilt.

2.

Vor allem bei Auftraggebern, die mit agilen Projektmethoden gar nicht oder nur wenig vertraut sind, empfiehlt es sich, im Vertrag gewissermaßen eine Anleitung für den Auftraggeber niederzulegen, also beispielsweise in den Definitionen die Scrum-spezifischen Begriffe zu erklären und gegeneinander abzugrenzen.

3.

Wie bei herkömmlichen IT-Projektverträge auch müssen die Mitwirkungspflichten des Auftraggebers konkret im Vertrag vereinbart werden. Insbesondere muss klar geregelt werden, welche Partei welche Rollen (Product Owner, Scrum Master, Entwicklungsteam) zu besetzen hat, und die Aufgaben der Inhaber dieser Rollen müssen konkret beschrieben werden. Sinnvollerweise sollte der Product Owner aus dem Unternehmen des Auftraggebers stammen und von diesem für die Wahrnehmung seiner Aufgaben im erforderlichen Umfang freigestellt werden. Damit kann dem Problem begegnet werden, dass die Mitarbeiter des Auftraggebers für die Arbeit am Projekt wie beispielsweise die Formulierung der Anforderungen oder die Beantwortung von Fragen des Auftragnehmers keine Zeit haben.

4.

Auch die Aufgaben des Product Owners, etwa die Erstellung, Ordnung und Verwaltung des Product Backlogs sollten im Vertrag vereinbart werden. Sinnvoll ist des Weiteren, dem Product Owner die Formulierung der Definitions of Done und die Entscheidung am Ende jedes Sprints, ob die gelieferte Funktionalität akzeptabel ist, zu übertragen. Denn wenn der Auftragnehmer die Definitions of Done formuliert, sind diese bereits deshalb als Abnahmekriterien untauglich.

5.

Die frühe Auslieferung brauchbarer Softwareteile, die im Idealfall unmittelbar nach ihrer Auslieferung in den Produktivbetrieb übernommen werden können, legt es nahe, zugunsten des Auftragnehmers Teilabnahmen der jeweils ausgelieferten Softwareteile zu vereinbaren.

6.

Bei der Vergütung wird eine Kombination einer aufwandsabhängigen und einer erfolgsabhängigen Vergütung den Interessen beider Parteien am ehesten gerecht, also z.B. eine am Ende jedes Sprints zu zahlende Pauschalvergütung und eine mit erfolgter Endabnahme zu zahlende weitere Vergütung.

7.

Besondere Sorgfalt sollte den Bestimmungen zur vorzeitigen Beendigung des Projekts gewidmet werden. In agilen Projekten empfiehlt sich insofern insbesondere eine Projektevaluierung zu einem genau definierten Zeitpunkt.

Weitere Hinweise finden Sie in einem ausführlichen Aufsatz von Dr. Truiken J. Heydn in Heft 5 der MMR 2020, Seiten 284 ff.

  • Twitter
  • LinkedIn