Agile Vertragsmodelle – Arbeiten mit firmenübergreifenden Teams

Wer agil arbeitet beschäftigt sich zunächst mit der Methodik und macht sich mit agilen Rollen, Arbeitsweisen und Prinzipien vertraut. Doch egal welches Regelwerk Sie befolgen: nirgends gibt es Vorgaben für die Zusammenarbeit firmenübergreifender Teams. Mit dem folgenden Artikel können Sie diese wichtige Lücke schließen: Sie erfahren,

1. wie eine firmenübergreifende Zusammenarbeit aussehen kann,
2. welche Vor- und Nachteile die Rollenverteilung mit sich bringt und
3. wie Sie das Ganze vertraglich abhandeln.

Sie finden dazu eine Sammlung verschiedener Vertragsmodelle – speziell für den Einsatz in agilen Projektumgebungen.

Wie arbeiten agile Teams?

Zur Erinnerung: Ein agiles Team – in den meisten Fällen ein Scrum-Team – besteht aus Product Owner, Scrum Master und 3-9 Entwicklern. Sie arbeiten in Iterationen, genannt Sprints, fokussiert auf die Neu- oder Weiterentwicklung eines Produkts. Diese sollten spätestens zum Ende eines jeden Sprints vorzeigbar und in lieferbarem Zustand sein.

Entwicklungszyklen sollten nicht länger als einen Monat dauern. Der Product Owner gibt vor, was von Stakeholder-Seite her erwartet wird. Der Scrum Master agiert dabei als Teamcoach und Prozessmanager. Er hilft besonders mit Scrum noch nicht ganz vertrauten Teams, sich an den „neuen“ Rhythmus zu gewöhnen.

Lesen Sie passend dazu „Agiles Projektmanagement –Grundlagen“

Was ist der „Product Owner“?

Ein agiles Team muss kein Scrum-Team sein. Es kann einfach eine Gruppe von Menschen sein, die zusammen mit Kanban arbeiten. Es können auch Teams sein, die hybride Ansätze umsetzen und agile und klassische Vorgehensweisen kombinieren.

In jedem Fall gibt es aber normalerweise eine Person, die für die Klärung, Dokumentation und Weitergabe von Anforderungen zuständig ist. Oft heißt diese Rolle auch in nicht-Scrum-Teams „Product Owner“. Aber auch „Requirements Engineers“, „Business-Analysten“ oder einfach „Kunden“ können die Rolle übernehmen.

Der Einfachheit halber nennen wir die Rolle in diesem Artikel „Product Owner“.

Vertragsmodelle für agile Projekte: Wer stellt den Product Owner?

Tatsächlich stellen firmenübergreifende Scrum-Teams eher die Regel dar, als rein interne. Entsprechend viele agile Teams stehen vor der Herausforderung, die Regeln und Ideale des Scrum Guides ohne entsprechende Vorgaben umzusetzen.

Zunächst gilt es zu klären, auf welcher Vertragsseite der Product Owner stehen soll. Dabei sollten Sie sich folgende Fragen stellen:

• Wie gut ist das Verhältnis zwischen Kunden und Lieferanten? Kann ein Product Owner auf Kundenseite eng genug mit dem Entwicklerteam zusammenarbeiten und hohe Verfügbarkeit bei Bedarf garantieren? Und: Vertrauen sich Product Owner und Entwickler, oder stehen sie sich eher misstrauisch gegenüber?
• Wer ist an den Stakeholdern dran und kennt die Anforderungen? Wer hat das Bewusstsein für den Markt? In aller Regel sollte dies das auftraggebende Unternehmen sein.
• Wer ist umgekehrt am Entwicklerteam dran und kennt dessen Methoden?
• Wer kann Kundenanforderungen für die Umsetzungsebene bestmöglich übersetzen und priorisieren?
• Wie vertraut sind die Beteiligten mit agilen Methoden? Gibt es auf einer Seite jemanden, der oder die bereits Erfahrungen mit der Product Owner-Rolle hat?

Für einen Product Owner auf Lieferantenseite spricht also:

• Technische Versiertheit
• Nähe am Umsetzerteam
• Vertrautheit mit internen Entwicklungsprozessen

Für einen Product Owner auf Kundenseite spricht hingegen:

• Nähe am Markt, an den Endkunden / Stakeholdern, an den Anforderungen
• „Weisungsbefugnis“ bzw. Autorität durch Stellung als zahlender Kunde

Unser Tipp: Besprechen Sie zwischen Auftragnehmer und Auftraggeber in einem Scrum-Projekt am besten schon bei den Vertragsverhandlungen die Rollenaufteilung und halten Sie diese vertraglich fest. Sollten Sie zu dem Schluss kommen, dass die Product Owner-Verantwortlichkeiten unter den Parteien aufgeteilt werden, ist eine Einigung über die genaue Rollendefinition umso wichtiger. Dies kann gar nicht genug betont werden, da manche der schwerwiegendsten Konflikte in Projekten zwischen mehreren Firmen gerade aus unklaren Rollendefinitionen entstanden sind. Dies hatte oft sogar gerichtliche Folgen.

Sie möchten Ihre agile Methodenkenntnisse erweitern? Hier finden Sie passende Seminare: Scrum-Seminar – Grundlagen und Basis-Zertifizierung oder Agile Projektmanagement-Kompetenz nach PMI®

Was ist ein „Proxy Product Owner“?

Neben der Möglichkeit, die Rolle des Product Owners einseitig auf einer der Vertragsparteienseite zu besetzen, gibt es auch „hybride“ Konstrukte. Diese nennen sich dann z.B. „Proxy Product Owner“. Hierbei sehen wir einen Product Owner auf Auftragnehmerseite und eine Person, die als Schnittstelle zum Kunden fungiert, auf Auftraggeberseite.

Meist haben Proxy Product Owner aber eine schwache Stellung. Sie verfügen über eher wenig Entscheidungsbefugnis und nehmen vielmehr eine Filterrolle im Hinblick auf Anforderungen ein.

Diese und weitere Ausprägungen typischer Herrausforderungen für Product Owner hat Roman Pichler in seinem Blogartikel „Avoiding Common Product Owner Mistakes“ beschrieben.

Unser Tipp: Finden sich Menschen in einer Rolle als Proxy Product Owner wieder hilft es nur, die Situation wieder aufzulösen. Statten Sie die Person mit der Autorität aus, die ein „True Agile Product Owner“ benötigt. Oder übergeben Sie die Autorität an jemanden anderen. Rollenkonflikte gefährden ansonsten jegliche Priorisierungsbemühungen in der Produktentwicklung.

Was Sie noch in einem Vertrag für agile Projekte beachten sollten

Sie haben die durchaus anspruchsvolle Aufgabe geklärt, wer als Product Owner die Verantwortung trägt? Gut! Dann gibt es weitere Dinge, die in einen Vertrag für ein agiles Projekt gehören:

• Gemeinsame Interessen und eine Partnerschaft basierend auf dem Prinzip von „Treu und Glauben” sollten schriftlich fixiert werden.
• Es sollte allen klar sein, welche Einstellungen und Führungsprinzipien im Projekt insgesamt vorherrschen.
• Stakeholder des Kundenunternehmens sollten regelmäßig an inhaltlichen Besprechungen teilnehmen.
• Das Entwicklerteam sollte im gegebenen Rahmen weitgehend zur internen Selbstorganisation befähigt sein. Dessen Mitglieder sind die technischen Experten bei der Umsetzung.

Alle 14 Tage – der TPG Projektmanagement Podcast für Unternehmen. Schicken Sie uns doch gerne Ihre Themenwünsche und Feedbacks an podcast@theprojectgroup.com.

Agile Vertragsmodelle im Überblick

In den folgenden Abschnitten finden Sie Details zu möglichen Vertragsmodellen für agile Projektumgebungen.

Festpreismodelle

1. Festpreisverträge minimieren das Kundenrisiko, für Kostenüberschreitungen aufkommen zu müssen. Es gibt mit diesen Modellen für agile Projekte aber einige Probleme. Dazu gehören:
2. Sie können Risiken der Terminverzögerungen, oder dass ein für den Kunden nutzloses Produkt entwickelt wird, nicht effektiv abdecken.
3. Die Anwendung agiler Methoden fördert zwar eine eng am Kundennutzen orientierte Entwicklung. Aber es ist sehr schwer, sich überhaupt auf einen Fixpreis zu einigen, wenn die volle Funktionalität noch gar nicht definiert ist.
4. Ein Festpreisvertrag definiert oft nur den Zeitraum der Entwicklung des Erstproduktes. Alles danach (Weiterentwicklung, Wartung, Support) wird zunächst ausgeblendet.

Der folgende Dokumentenablauf kommt in solchen Vertragsprozessen oft zum Tragen:

Lastenhefte enthalten normalerweise wichtige Informationen für den Kunden und sind Teil der Angebotseinholung von möglichen Anbietern. Diese entwickeln, sobald die Zusammenarbeit beschlossen wurde, eine detailliertere Beschreibung von Inhalt und Umfang (Pflichtenheft o.ä.). Manchmal geschieht dies auch durch Vorlage des Kunden.

In agilen Projekten, wo die Anforderungen erst „entdeckt“ werden, sind solche Beschreibungen bei der Innovation oft eher hinderlich. Hier wird lieber mit leichtgewichtigeren Dokumenten wie dem Product Backlog gearbeitet.

Festpreis mit einigen agilen Elementen

Wenn Sie Festpreismodelle für agile Projekte passender machen wollen, müssen Sie darin einige agile Prinzipien anwenden. Die folgenden Faktoren könnten also Berücksichtigung finden:

1. Funktionalitäten sind zu Beginn nicht komplett durchdefiniert – die Vertragsparteien bestätigen sich gegenseitig ihr Bewusstsein dieser Tatsache
2. Es gibt ein gemeinsames Verständnis über die Projektziele, etwa die Produktvision und eine Roadmap. Eine vertragliche Verpflichtung zum kontinuierlichen Austausch in Gesprächen, nicht nur mithilfe von hin- und hergesendeten Dokumenten findet statt.
3. Bei Problemen werden kooperative Ansätze zur Lösung gewählt und das „Agile Mindset“ (~Einstellung) betont, statt mehr Distanz aufzubauen. Dies setzt auf Vertrauen und Ermächtigung aller Beteiligten. Eine Referenz zu einem bestehenden Ansatz kann vertraglich aufgenommen werden. Das kann etwa ein Bezug zum Scrum Guide sein, wenn das Team nach diesem Rahmenwerk arbeitet.
4. Die Fertigstellungskriterien (Definition of Done), auf die sich das Umsetzungsteam mit Product Owner und Stakeholdern geeinigt hat, können ebenfalls in den Vertrag. Dabei sollten Sie aber verdeutlichen, dass diese im Lauf des Projekts Abänderungen unterliegen können. Die Vertragsparteien müssen verstehen, was eine Definition of Done genau ist, warum sie nicht das Gleiche wie Akzeptanzkriterien ist und warum sie eine Teamvereinbarung darstellt. Akzeptanzkriterien können ebenfalls in den Vertrag geschrieben und als Grundlage für die Definition of Done verwendet werden. Außerdem können festgelegte Timeboxen für Iterationen (in Scrum: Sprints) und Meetings sowie deren Häufigkeit in den Vertrag.
5. Rollenklärungen und Team Charter sind weitere Dokumente, die in angepassten Festpreisverträgen für agile Projekte aufgenommen werden können.
6. Statt Scope Statement bzw. Pflichtenheft gibt es eine vertragliche Einigung auf die Notwendigkeit eines Product Backlogs.
7. Rollen im Projekt werden klar definiert und vertraglich beschrieben. Ebenso, wer an welchem Meeting teilzunehmen hat. So sollten möglicherweise Auftragnehmer und -geber beide Vertreter in die Sprintplanung schicken, um vertragsrelevante und unangenehme Überraschungen zu vermeiden.
8. Schätzmethoden können so gehandhabt werden, wie sie gut funktionieren. Eine Verpflichtung zu agiler Größen- und Aufwandsschätzung gibt es per se nicht. Das gilt vor allem dann nicht, wenn es bereits bewährte Methoden gibt. Die Parteien können sich mit agiler Schätzung aber näher beschäftigen, wenn sie glauben, dass dies dem Projekt zuträglich ist. Natürlich kann dann auch eine Einigung auf Release-Burndown-Charts zur Fortschrittsmessung in den Vertrag.

Priorisieren in agilen Projekten

Wenn sich Schätzungen als falsch herausstellen und Probleme aufkommen, müssen Sie reagieren. Schlimmstenfalls ist das Projekt vorzeitig abzubrechen. Andernfalls müssen Dienstleister Rückstellungen bilden und Prioritäten im Projektportfolio neu bewerten, um das schlecht laufende Projekt auszugleichen und so die eigene Liquidität zu erhalten.

Es hat sich bewährt, eingehende Anforderungen nach Risiko in Kombination mit vermutetem Nutzen wie folgt einzuschätzen:

 

Auf diese Weise soll riskantere Arbeit früher erledigt werden als andere. So sind die Optionen noch vielfältiger und die bereits getätigten Ausgaben im Projekt noch nicht so hoch.

Agiler Festpreis

Die bis hierhin beschriebenen Beispiele dienen der langsamen Einführung agiler Prinzipien in klassische Umgebungen und Vertragswerke. Darüber hinaus gibt es die Möglichkeit, den Vertrag an sich in seiner ganzen Form „agiler“ zu gestalten.

Beim Modell “Agiler Festpreis” beschreiben Sie zuerst den vertraglich vereinbarten Projektumfang auf Grundlage der Produktvision und sehr grobe Beschreibungen von Features.

Dann schätzen die Beteiligten den Gesamtaufwand mithilfe von Story Points und übersetzen diese in Personentage. Dies erfolgt zum Beispiel, indem das erste Sprintplanungs-Meeting simuliert und eine Referenz geschaffen wird.

Als Sicherheitsmaßnahme kann zu diesem Zeitpunkt das Projekt immer noch abgebrochen werden, wenn Sie feststellen, dass der Aufwand doch zu hoch wird. Außerdem werden Vereinbarungen zur Risikoteilung zwischen den Projektbeteiligten getroffen. Auftragnehmer können zusichern, alle „Must-Haves“ unter den Anforderungen umzusetzen und Features darüber hinaus nur zu entwickeln, wenn dann noch Budget übrig ist.

Ein Sondertyp bei den Vertragsformen für agile Projekte ist in diesem Zusammenhang auch das sogenannte Modell „Money for Nothing, Change for Free“ des Scrum-Miterfinders Jeff Sutherland. Dabei werden zunächst vom Kunden recht klassisch gewünschte Anforderungen beschrieben, und der Anbieter antwortet mit einem Umsetzungsangebot zum Festpreis. Mit dem Start der Umsetzung nimmt der Kunde die Rolle des Product Owners ein und verwaltet das Product Backlog.

In jedem Sprint Review Meeting, in dem der Dienstleister die Ergebnisse der vorangegangenen Iteration präsentiert, kann der Kunde – wie typisch in Scrum – Feedback geben und das Product Backlog überarbeiten. Allerdings ist die Besonderheit aufgrund der Situation eines Festpreis-Vertragsprojekts die, dass eine Vereinbarung gilt: Für jede neu ins Backlog aufgenommene Anforderung, etwa in Form einer User Story, muss eine im Umsetzungsaufwand in etwa gleich große aus dem Backlog entfernt werden. Dies ist der „Change for Free“-Teil des Vertragsmodells.

Eine weitere Besonderheit ergibt sich aus dem „Money-for-Nothing“-Prinzip. Diese gilt für den Fall, dass sich Anbieter und Dienstleister zu irgendeinem Zeitpunkt einig sind, das Produkt nicht mehr weiter zu entwickeln und die Zusammenarbeit bei diesem Thema somit zu beenden. Sollten zu dem Zeitpunkt noch Gelder aus dem ursprünglichen Budget übrig sein, so teilen sich die Vertragsparteien dieses Geld zu einem im Vertrag vorab vereinbarten Prozentsatz.

So innovativ dieses „Money-for-Nothing“-Prinzip ist und so gut es in agilen Entwicklungsumgebungen passen könnte: Oft ist hierbei ein Problem, dass bestehende Prozesse in den meisten Unternehmen keine Restbudget-Aufteilung erlauben.

Die „Change-for-Free“-Idee hat sich hingegen in echten Projekten schon häufig als erfolgreich bewährt.

Festpreis: Zahlung pro Sprint

Sie können Ihre Vertragsgrundlage auch „agilisieren“. Das passiert, indem Sie sich auf einen an den Sprint-Rhythmus angepassten Zahlungszyklus einigen, also einen Festpreis pro Sprint.

In diesem Modell „Festpreis pro Sprint“ haben die Vertragsparteien de facto viele kleine Festprojekte, wobei jede Iteration ein Miniprojekt darstellt. Jede Sprintplanung führt zu einem neuen Vertrag, und jedes Review stellt ein Abnahmemeeting dar. Der Umfang wird also zeitlich auf Sprintebene spezifiziert.

Ähnliche Modelle werden häufiger von US-Regierungsbehören eingesetzt – so genannte “Blanket Purchase Agreements“ oder auch „Indefinite Delivery / Indefinite Quantity“ (IDIQ).

Time & Material (T&M)

Bei Time-and-Material-Verträgen sichert der Kunde dem Auftragnehmer zu, nach entstandenen Zeitaufwänden sowie verwendeten Materialien zu bezahlen. Dieses Prinzip harmoniert gut mit den besonders zu Anfang weniger durchspezifizierten agilen Projektsituationen.

Allerdings ist es zwingend notwendig, dass Auftragnehmer eine solche Situation nicht ausnutzen und in der Dokumentation entstandener Aufwände ehrlich und vertrauenswürdig bleiben. Außerdem haben sie weniger Anreiz, effektiver zu arbeiten.

Sollten sich zwei Vertragsparteien in einem T&M-Projekt vor Gericht wiederfinden, kommt erschwerend hinzu, dass das Verhältnis als eine Form von Arbeitnehmerüberlassung interpretiert werden könnte.

Abhilfe können Abwandlungen von T&M-Verträgen wie etwa „Design to Cost“ oder „Pay per Productivity“ schaffen:

•  „Design-to-Cost”-Verträge fixieren Budgets, während der Projektumfang weiter flexibel gehalten wird. Dies funktioniert insbesondere dann gut, wenn Auftragnehmer die Möglichkeit haben, aufgrund vergangener ähnlicher Projekte einen für sie passenden Preisvorschlag zu machen.
• Bei „Pay per Productivity” sichert der Auftragnehmer eine bestimmte Produktivitätsrate vertraglich zu, basierend auf vereinbarten Kriterien. Er sollte dadurch den Anreiz haben, die Qualität des Produkts hochzuhalten. Ansonstengeht ein großer Anteil der bezahlten Produktivität lediglich in die Wartung und Behebung von Problemen. Das Modell trägt aber wenig zum Fokus auf den Kundennutzen bei, da Teams prinzipiell auch hochproduktiv an Funktionen arbeiten können, die an Bedürfnissen des Kunden und der Endnutzer vorbeigehen.

T&M: Zahlung pro Sprint

Das Modell „Pay what you get” ähnelt Festpreis-pro-Sprint-Konstrukten. Allerdings gibt es die explizite Vereinbarung, dass der Kunde nur das bezahlt, was im Sprintreview abgenommen wird. Dies kann bei großem Vertrauen von Auftragnehmern gegenüber ihren Kunden funktionieren.

Ansonsten geht das eher nicht, da der Lieferant über die Sprintdauer hinweg in Vorleistung gehen muss.

Weitere Misch- und Sonderformen agiler Verträge

Neben den „Haupttypen“ Festpreis und Time & Material gibt es noch unzählige weitere Misch- und Sonderformen. Davon haben sich in agilen Projekten in der Vergangenheit unter anderem folgende Ideen als denkbar herausgestellt:

Nutzenorientierte Vertragsmodelle

Die Entwicklung möglichst nutzenorientiert zu halten, ist eine Kernidee agiler Ansätze. Keines der bis hierhin vorgestellten Vertragsmodelle hilft, solche Bemühungen sicherzustellen. Rechtsexperten sind deshalb oft nicht sehr vertraut mit solchen Prinzipien in Verträgen. In ihnen könnte aber die Lösung stecken beim Umgang mit hoher Komplexität und Unsicherheit in modernen Softwareprojekten.

Nutzen-Kosten-Verhältnisse müssen beim Einsatz entsprechender Vertragskonstrukte kontinuierlich überwache werden. Aufwand und Ergebnis müssen in einem vernünftigen Verhältnis zueinander stehen, das sich über längere Zeit aufrechterhalten lässt.

Nutzenorientierte Prämienverträge

Es gibt Vertragsmodelle, bei denen der Kunde einen relativ niedrigen Tagessatz bezahlt, um die Kosten des Auftragnehmers zu decken. Damit letzterer auch einen Profit daraus für sich erzeugen kann, wird immer dann zusätzlich eine Prämie gezahlt, wenn ein vorab vereinbartes Ziel in Bezug auf den erzeugten Nutzungswert erreicht wurde.

Dazu muss natürlich für alle klar sein, was für den Kunden wertvoll ist und wie dies gemessen wird – etwa mithilfe von Impact Maps.

“Pay per Use”

Auch nutzungsbasierte Zahlungsvereinbarungen, wie viele Lizenzmodelle heutiger SAAS-Lösungen, zählen zu nutzenorientierten Vertragsmodellen. Sie passen ebenfalls gut zu agilen Projekten.

Wann ist welcher Vertragstyp geeignet?

Zusammenfassung und Fazit

Projekte sind einzigartige, temporäre Unterfangen. Kein Vertragsmodell wird somit für jedes Projekt das genau richtige sein. Projektmanager und alle anderen an Vertragsverhandlungen Beteiligte müssen ein Modell finden, das am besten zur Situation und Umgebung des Projektes passt. Dies gilt insbesondere auch für agile Projekte mit all der Unsicherheit, die sie mit sich bringen.

In diesem Artikel haben Sie für die Auswahl des passenden agilen Vertragsmodells das nötige Rüstzeug erhalten. Sie kennen jetzt die jeweiligen Vor- und Nachteile bei der Zuweisung des Product Owners auf Kunden- und Lieferantenseite. Zudem haben Sie einen guten Überblick über verschiedene agile Vertragsmodelle bekommen:

• Sie kennen jetzt die Gründe, die für Festpreisansätze oder für Abrechnungen nach Aufwand oder andere Metriken sprechen.
• Sie haben einige mögliche Vertragswerke kennengelernt, die sich für agile Projekte besonders gut anwenden lassen – und deren Grenzen.
• Sie haben außerdem erfahren, was Sie über das gewählte Vertragsmodell hinaus inhaltlich in Kooperationsverträgen für agile Projekte berücksichtigen sollten.

Letzter Tipp zum Schluss: Die Wichtigkeit des Prinzips von „Treu und Glauben“, ist bei agilen Projekten fast noch wichtiger als ohnehin in Projektverträgen: Vertragspartner sollen für das Erreichen gemeinsamer Ziele kooperieren und sich nicht über den Tisch ziehen wollen.

Das Motto sollte immer sein, dass der Projekterfolg im Mittelpunkt steht. Wenn dies wirklich klappt, wird die Wahl eines passenden Vertragsmodells zur notwendigen, aber machbaren Formsache.

Haben Sie Erfahrung mit agilen Vertragsmodellen? Worauf sollte Ihrer Meinung nach besonders geachtet werden? Bitte schreiben Sie jetzt unten einen kurzen Kommentar.

von Antje Lehmann-Benz

ARTIKEL DRUCKEN