Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanban & Co.

ausdrücklich vereinbart werden, dass der Auftragnehmer keinen Erfolg schuldet, sondern
umgekehrt der Auftraggeber die Verantwortung für den Projekterfolg trägt. Der Auftraggeber
„kauft“ bei dieser Gestaltung also letztlich Programmierzeit des Auftragnehmers, ohne eine
konkrete Zusage für das Ergebnis zu bekommen.
Aus mehreren Gründen ist eine solche Vertragsgestaltung allerdings problematisch: Der
Auftraggeber ist nur in den seltensten Fällen bereit, das alleinige Risiko für den Projekterfolg
zu übernehmen. Es ist auch nicht recht plausibel, dass der Auftraggeber als technischer Laie
die Verantwortung behält und der Auftragnehmer als Experte keine Erfolgsverantwortung
übernimmt. Schließlich passt diese Konstruktion nicht zu dem Umstand, dass in der Regel
der Auftragnehmer das Projekt steuert, wenn auch mit Unterstützung des Auftraggebers.
Den Softwareerstellungsvertrag als reinen Dienstvertrag zu gestalten, ist also zwar rechtlich
möglich, allerdings in der Praxis wohl kaum gegenüber dem Auftraggeber durchsetzbar und
in den meisten Fällen nicht interessengerecht.
9.7. Bedarfsgerechte Vertragsgestaltung
Ziel der Vertragsgestaltung muss es deswegen sein, einen gleichermaßen bedürfnis- wie
interessengerechten Zwischenweg zu finden.
Insbesondere bei Scrum können etwa die Planung der Sprints („Sprint-Plannings“) und das
„Sprint-Review“ sowie Scrum-Meetings auf Ebene eines Dienstvertrages geregelt werden.
Für die einzelnen Sprints kann davon abweichend eine werkvertragliche oder
werkliefervertragliche Gestaltung gewählt werden. Geschuldet ist dann jeweils ein Ergebnis
mit der Funktionalität wie im Sprint-Backlog beschrieben.
Die so erzielte Aufspaltung in viele kleinere Werkverträge vermindert das Risiko auf beiden
Seiten. Flexibilität wird dadurch sichergestellt, dass beide Parteien nach jedem oder einer
bestimmten Zahl von Sprints den Vertrag kündigen können. Dabei kann entweder anhand
des voraussichtlichen Aufwands die Vergütung eines einzelnen Sprints jeweils separat
vereinbart, oder vertraglich ein fester Preis pro Sprint festgelegt werden.
Dies führt zwar möglicherweise ideologisch zu einer Vermengung von agiler und klassischer
Entwicklungsweise. Zum einen scheint eine Zwischenlösung jedoch aus
Interessengesichtspunkten sachgerecht und zum anderen ermöglicht sie auch konservativen
Auftraggebern, die Vorteile agiler Entwicklungsmethoden nutzen zu können, ohne vollständig
auf die gewohnte „Projektumgebung“ verzichten zu müssen.
Letztlich ist für die Vertragsgestaltung also nicht die Projektmethode maßgeblich.
Entscheidend ist die Ausgestaltung der Zusammenarbeit für das konkrete Projekt. Erst auf
dieser Basis kann ein sachgerechter Vertrag überhaupt entworfen werden. Inwieweit Werkund
Dienstvertrag diese Gestaltung beeinflussen, ist allein abhängig von dem Parteiwillen
und nicht nur an die Frage der Projektmethode geknüpft.
9.8. Zusammenfassung
Agil oder klassisch? Aus vertragsgestalterischer Sicht ist die Frage nur von untergeordneter
Bedeutung. Entscheidend ist letztlich, dass der Vertrag das von den Parteien beabsichtigte
Vorgehen abbildet und alle wesentlichen rechtlichen Punkte, die damit in Zusammenhang
stehen, regelt. Das setzt voraus, dass sich die Parteien über die grundlegenden Aspekte der
Vorgehensweise bei der Projektumsetzung und über die Verteilung der Verantwortlichkeiten
für den Projekterfolg einig sind. Dazu genügt es nicht, sich auf ein „agiles Vorgehen“ zu
einigen. Denn das sagt noch nichts Konkretes über die Leistungspflichten aus und lässt eine
Einordnung des Vertrages und eine sachgerechte Vertragsgestaltung nicht zu.
TechDivision GmbH – Agiles Projektmanagement
39