Wir schätzen „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung“, so lautet der dritte Punkt des agilen Manifests. Diese Aussage wird in der Praxis sehr unterschiedlich interpretiert.
Interessant ist, dass hier vom Kunden (im englischen Original auch „Customer“) die Rede ist, die gängigen agilen Standards aber die Frage, in welchem Rechtsverhältnis der Kunde zu seinem Gegenüber steht, völlig außen vor lassen.
Wer ist Kunde?
Im Scrum-Guide kommt das Wort „Kunde“ nicht vor. Es gibt das Scrum Team und das „besteht aus einem:einer Scrum Master:in, einem:einer Product Owner:in und Developer:innen. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien“. Und weiter: „Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt“. Daraus könnte man schließen, dass ein Product Owner den Kunden repräsentiert, denn der Wert eines Produkts kann nur durch seine Nutzung und den daraus resultierenden Nutzen für den Kunden ermittelt werden. Die Software als solche kann technisch hervorragend sein, die Architektur bzw. der Code kann elegant sein usw., ohne die Nutzung in einem konkreten Anwendungskontext („Business Case“) kann der „Wert des Produkts“ nicht bestimmt werden.
Ein IT-Unternehmen, das sich auf Scrum als Standard beruft, definiert die Rolle Product Owner so: „Mitarbeiter:in des Kunden, der:die die inhaltliche Verantwortung für den Backlog trägt und alle Aufgaben erfüllt, in denen der Kunde als verantwortlich genannt wird“. In diesem Fall und bei allen größeren Projekten handelt es sich regelmäßig um zwei getrennte Unternehmen, in denen jeweils ein Management für den Unternehmenserfolg verantwortlich ist. Der Umsatz des einen sind die Kosten des anderen, insofern gibt es ein natürliches Spannungsverhältnis. Wenn der Scrum Guide also Subteams und Hierarchien innerhalb des Scrum Teams ausschließt, bleibt das Vertragsverhältnis zwischen Auftraggeber und Auftragnehmer offen. Es wird auch eine Harmonie zwischen den beteiligten Personen (bzw. deren Rollen) vorausgesetzt, die nicht immer gegeben ist, nicht einmal unter den Mitgliedern ein und desselben Unternehmens. Manchmal soll es sogar Spannungen und Konflikte zwischen den Abteilungen eines Unternehmens geben, wurde mir berichtet .
Das agile Team, eine Insel der Glückseligen?
Das Scrum-Team scheint sich auf wundersame Weise von seiner Umwelt zu isolieren, die durch eine Vielzahl rechtlicher Regelungen bestimmt wird. Das sehe ich als die beste Erklärung für den überwältigenden Erfolg von Scrum, denn es wird hier ein Paradies für Entwickler:innen geschaffen. Es gibt keine Deadlines, keine Budgets, keine vordefinierten Geschäftsprozesse etc. Wer wünscht sich das nicht? Wolfram Müller verdanke ich die Erkenntnis, warum mit Scrum bessere Ergebnisse erzielt werden als mit traditionellen Vorgehensweisen: Scrum schützt diejenigen, die etwas von der Sache verstehen, vor Störungen durch ein Management, das einflussreich ist, aber nichts von der Sache versteht. Viel erfolgreicher wären wir aber, wenn die Entwicklungsarbeit in ein förderliches Managementumfeld eingebettet wäre.
Nun gehe ich hier nicht auf die Frage ein, was ein förderliches Management ausmacht, das ein anderes Mal. Ich frage nach den vertraglichen Rahmenbedingungen eines agilen Projekts. Ich bin kein Jurist, sondern Projektmanager, habe aber im Laufe meines Berufslebens mit hervorragenden Juristen zusammenarbeiten dürfen und viel von ihnen gelernt. Ich habe aber auch negative Erfahrungen gemacht, aus denen ich gelernt habe, wie man es nicht machen sollte.
Man kann nicht keinen Vertrag schließen
Grundlegende Erkenntnis frei nach Paul Watzlawick: Es gibt immer einen Vertrag. Verträge sind nicht an die Form gebunden, sie entstehen auch durch mündliche Vereinbarungen, heute durch Mails oder auch durch die geübte Praxis („konkludente Handlungen“). Bei allen größeren Projekten gibt es jedoch einen schriftlichen Vertrag, und sei es nur ein Angebot, das vom Auftraggeber angenommen wurde. Die Frage ist, ob der Vertrag die Projektarbeit unterstützt oder behindert.
Hier gibt es eine Reihe von Praktiken, die je nach Kontext mehr oder weniger gut funktionieren:
a. Wir schließen nach wie vor klassische Werkverträge ab, handhaben sie aber nicht so streng. Die Schwelle für die Notwendigkeit von Change Requests wird angehoben, das Ergebnis wird akzeptiert, wenn es funktioniert, auch wenn es von der ursprünglichen Anforderungsdefinition abweicht.
b. Wir schließen Verträge mit reiner Aufwandsverrechnung ab, starten mit Anforderungen der Kategorien „Vision“ und „Epic“ und einer Budgetierung, die auf einer groben Aufwandsabschätzung auf Basis von Erfahrungswerten basiert.
c. Wir mischen die beiden Ansätze bis hin zum „agilen Festpreis“, den ich als Wunder bezeichnen würde, wenn er tatsächlich das wäre, was er vorgibt zu sein.
Aus der Praxis kann ich berichten, dass jeder der genannten Ansätze funktionieren kann, wenn die Rahmenbedingungen stimmen. Das mag überraschen, ist aber so. Problematisch wird es erst, wenn ein Vertrag abgeschlossen wird, der nicht zum Projektansatz passt, und – das ist das Entscheidende – wenn er dann auch noch exekutiert wird.
Was sollte ein Projektvertrag regeln?
Die umfassendste Darstellung relevanter Vertragsinhalte mit beispielhaften Musterverträgen, die mir bekannt ist, stammt vom Agile Business Consortium und steht dessen Mitgliedern zur Verfügung. Hier eine komprimierte Liste der dort genannten Vertragsinhalte.
1. Definitionen: Klärung von Begriffen und Interpretationen, um Missverständnisse zu vermeiden.
2. Vorgehensmodell: Festlegung des agilen Ansatzes und der Zusammenarbeit zwischen den Parteien.
3. Leistungen: Beschreibung der zu erbringenden Dienstleistungen, einschließlich Beratung, Entwicklung/Customizing, Schulung und Produktlieferungen.
4. Machbarkeit: Vorgehen zur Bestimmung der technischen und finanziellen Machbarkeit des Projekts.
5. Grundlagenplanung: Schaffung eines grundlegenden Verständnisses der Geschäftsanforderungen, Definition der Lösungsarchitektur und Festlegung des Projektlebenszyklus.
6. Projektablaufplanung: Entwicklung eines Lieferplans, der während des Projekts weiterentwickelt werden kann.
7. Entwicklungsphase: Definition der Aufgaben des Lösungsentwicklungsteams und Entwicklung der Lösung in Iterationen.
8. Deployment: Überprüfung und Abnahme der entwickelten Lösungen vor der Inbetriebnahme.
9. Änderungsmanagement: Verfahren zur Anpassung der Projektanforderungen und des Lieferplans.
10. Projektmanagement: Definition der Projektorganisation und der Schlüsselrollen im Projekt.
11. Personal: Anforderungen an das Personal, einschließlich Qualifikationen, Verfügbarkeit und Maßnahmen im Falle von Ausfällen.
12. Vergütung: Festlegung der Vergütung und der Zahlungsbedingungen für die erbrachten Leistungen.
13. Vertraulichkeit: Umgang mit vertraulichen Informationen und deren Schutz.
14. Datenschutz: Umgang mit personenbezogenen Daten gemäß den gesetzlichen Bestimmungen.
15. Gewährleistung: Zusicherungen und Verpflichtungen des Auftragnehmers.
16. Geistiges Eigentum: Regelungen zu Rechten an geistigem Eigentum, die während des Projekts entstehen oder von einer der Parteien in das Projekt eingebracht wurden (z.B. Standardsoftware).
17. Haftung für Schutzrechte: Entschädigung bei Verletzung von Rechten an geistigem Eigentum Dritter.
18. Haftungsbeschränkung: Begrenzung der Haftung der Parteien.
19. Versicherung: Verpflichtung zum Abschluss und Aufrechterhaltung einer angemessenen Versicherung.
20. Laufzeit und Beendigung: Regelungen zur Laufzeit und Beendigung des Vertrags, einschließlich der Folgen der Beendigung.
21. Streitbeilegung: Verfahren zur Beilegung von Streitigkeiten, einschließlich Schlichtung, Mediation und Gerichtsverfahren.
22. Kommunikation: Anforderungen an die Kommunikation zwischen den Parteien.
23. Allgemeine Bestimmungen: Verfahren zur Abänderung des Vertrages, Rechte von Dritten, Umgehen mit höherer Gewalt, Abwerbeverbot etc.
Viele dieser Punkte unterscheiden sich nicht voneinander, egal nach welchem Paradigma man ein Projekt abwickelt, sie sind in einem agilen Projekt genauso zu regeln wie in einem Wasserfallprojekt, nur eben inhaltlich unterschiedlich.
Wie sollte man agile Projekte vertraglich regeln?
Seit fast einem Jahr bin ich Solution Partner von agile.agreement, einem Netzwerk, dessen Gründer in der Schweiz tätig sind. Unsere Überzeugung ist, dass Projektverträge in hohem Maße von erfahrenen Projektmanager:innen bestimmt werden müssen. Es braucht eine interdisziplinäre Zusammenarbeit auf Augenhöhe mit Jurist:innen, die für die korrekte „handwerkliche“ Umsetzung unverzichtbar sind und die auch eine Reihe von Regelungen treffen müssen, für die wir als Projektmanager:innen keine Expertise beanspruchen können. Ein Blick auf die obige Liste der relevanten Vertragsinhalte sollte deutlich machen, was ich jeweils wie zuordne.
Die Mitglieder von agile.agreement vereinen eine Fülle von praktischen Erfahrungen mit agilen Projekten. Diese sind in einem „agile.agreement Canvas“ verdichtet und mit Best Practices unterlegt. Wir geben agilen Teams – gemeinsam mit darauf spezialisierten Jurist:innen- den notwendigen und passenden vertraglichen Rahmen.
Gemeinsam mit einem der Gründer von agile.agreement, Michael Arm und mit Gernot Silvestri, meinem langjährigen Freund und oftmaligen Partner in anspruchsvollen Projekten, habe ich am 25. Juni 2024 ein Webinar durchgeführt, bei dem wir unsere wichtigsten Erkenntnisse aus mehreren Jahrzehnten Berufspraxis zur Diskussion stellten.