Agile vs. klassische Projektmethoden Teil 3

Vertragsgestaltung bei agiler Entwicklung

Im dritten Teil der Interviewreihe mit Henning Wolf von der it-agile GmbH möchte ich mit Henning Wolf über die Möglichkeiten der Vertragsgestaltung in agilen Projekten sprechen, gerade in Hinblick auf Alternativen zu "Festpreis" und "Time & Material", die bei der Einführung von ERP-Software häufig die Klassiker sind.

Agilität bei Vertec

Die Vertec Gruppe ist Hersteller einer zukunftssicheren Branchenlösung für projektorientierte Dienstleister. Auch wenn wir keine ausschließlichen Entwicklungsdienstleitungen anbieten, verstehen wir uns als agiles Unternehmen, denn das Vorgehen in Vertec Einführungsprojekten ist agil.

Auf Basis einer Standardsoftware erarbeiten wir gemeinsam mit den Kunden mittels "Rapid Prototyping" kundenspezifische Lösungen, bis diese für den Kunden passen. Die Grundwerte der agilen Welt, wie zum Beispiel der Fokus auf die Zusammenarbeit mit unseren Kunden und ein funktionierendes Produkt, sowie die adäquate Reaktion auf gewünschte Veränderungen stehen hierbei im Vordergrund.

Natürlich gehören in einer seriösen Kundenbeziehung auch eine umfangreiche Dokumentation des Projektes und Vertragsverhandlungen, also insbesondere die Angebotserstellung dazu, bei der wir ein gut geschätztes Budget für das bevorstehende Projekt erarbeiten. Das Budget kann sich bei nicht vollständig ausspezifizierten Features nur in einem ungefähren Rahmen bewegen, denn die Anzahl an Iterationen oder der genaue Umfang und Automatisierungsgrad sind zu Beginn noch weitestgehend unklar, sprich man nähert sich flexibel, oder eben agil, einer Lösung an.

Natürlich wünschen manche unserer Kunden, gerade wenn sie wenige Berührungspunkte mit agilen Vorgehensweisen haben, gerne einen genau abgesteckten Funktionsumfang und manchmal sogar einen Festpreis. Ein Festpreis gibt finanzielle Sicherheit, aber eben auch Nachteile für den Auftraggeber und den Auftragnehmer. Die Gründe liegen auf der Hand:

1. Es müssen die Features im Voraus sehr genau ausspezifiziert werden, ein Aufwand, der bereits in die agile Umsetzung fließen könnte.
2. Das Angebot muss dann Sicherheiten im Budget für Unvorhergesehenes beinhalten. Es wird also dadurch etwas teurer für den Kunden
3. Die Agilität, in der Umsetzung verschiedene Varianten aufzuzeigen und gemeinsam sich dem idealen Ziel anzunähern, bleibt auf der Strecke. Es wurde so nicht im Vorfeld spezifiziert und ist nicht Teil des Budgets.

Die Praxis aus mehreren hundert Einführungsprojekten hat gezeigt, dass die Projekte, die Spielraum für Flexibilität oder eben Agilität lassen, meistens die besten Lösungen für den Kunden hervorbringen. Denn in agilen Projekten spricht der Auftraggeber permanent mit, nicht nur am Anfang. Änderungen können kontinuierlich in der Einführung mit einfließen und werden nicht als Change Request hinten angestellt.

Manche Neukunden, die uns noch nicht kennen und bei der Budgetschätzung skeptisch sind, oder die eben zu Controlling-Zwecken oder aus Budgetgründen einen definitiven Festpreis benötigen, können von einer solchen Agilität weniger profitieren.

Um die gegenseitigen Risiken zu minimieren und sich gegenseitig besser kennenzulernen, bieten wir unseren Kunden häufig ein Vorprojekt an, in welchem wir die relevantesten Anforderungen in Zusammenarbeit mit unseren Kunden erarbeiten und in einem Einführungskonzept festhalten. Wenn man sich dann auf ein gemeinsames Einführungsprojekt einigt, steht die Vertragsgestaltung an.

Welche Learnings in puncto Vertragsgestaltung können wir als ERP Anbieter aus der agilen Welt zeihen?

Tobias: Henning, bevor wir über unterschiedliche Vertragsarten in agilen Projekten sprechen, bleiben wir noch mal kurz bei der Auswahl des richtigen Anbieters. Im Buch "Agile Verträge" (mehr dazu hier) steht zur Anbieterauswahl, dass der Preis ein ungünstiges Auswahlkriterium ist, wenn es um die Entscheidung für einen Softwareanbieter oder eine Softwarelösung geht.
Das ist ja auch nachvollziehbar. Denn wenn ich z.B. ein möglichst tolles Auto kaufen will, dann gehe ich nicht nur nach dem Preis, sondern habe andere Auswahlkriterien, wie Qualität, Leistung, Image usw. Der Preis spielt erst dann eine Rolle, wenn alles andere zwischen zwei Anbietern gleich gut zu sein scheint.

Henning: Ja, das ist ja auch das Argument in dem besagten Buch. Wenn man den billigsten Anbieter aussucht, darf man sich hinterher auch nicht wundern, dass der nicht alles kann.

Tobias: In unseren Verkaufsterminen, zumindest in Deutschland, spielt aus unserer Erfahrung der Preis für die Interessenten häufig eine zentrale Rolle und kommt manchmal viel zu früh zur Sprache, wenn noch gar nicht klar ist, welche Ziele der Interessent genau verfolgt. Gibt es denn deiner Erfahrung nach in agilen Vertragsanbahnungen eine Entwicklung weg von "Was kostet es denn?" hin zu "Wir reden mal über die Lösung und dann über den Preis."?

Henning: Dass ein Unternehmen, wenn es Vertec Lizenzen kauft und Dienstleistungen für kundenspezifische Anpassungen benötigt, grundsätzlich das Interesse verfolgt, die Investitionskosten möglichst genau zu kennen, finde ich zunächst total verständlich. Die Frage ist, wann man das auf den Tisch bringt. Natürlich kann man auch erst mal über die konkreten Anforderungen sprechen. Denn vorher kann man doch sowieso nichts dazu sagen, was es genau kosten wird.

Tobias: Richtig. Doch manche Gesprächspartner wollen die Reihenfolge umdrehen und vor der detaillierten Formulierung der Anforderungen sehr genau wissen, was es kosten wird. Das funktioniert natürlich nicht, wenn diese Anforderungen nicht ausformuliert sind. Ein grobes Budget lässt sich schon nennen, aufgrund von Erfahrungswerten. Aber heißt das dann, dass es Kunden gibt, die einfach nicht reif genug sind für eine agile Herangehensweise?

Henning: Das kann sicherlich auch mit einer der Gründe sein. Allerdings würde ich nicht per se sagen, dass diese Interessenten deshalb nicht geeignet sind, agil vorzugehen. Sondern sie haben eben eine sehr starre Vorstellung davon, was "Vertrag" bedeutet. Und am Ende haben sie vielleicht auch eine bestimmte Erwartungshaltung, was "Produkt" bedeutet und was die dazugehörigen Anpassungen betrifft. Wenn du einen Anzug kaufst, der 500 EUR kostet, dann würdest du nicht erwarten, dass der Änderungsschneider noch mal 500 EUR aufruft.

Die Leute sind vielleicht noch nicht gewohnt, solche Art von Software-Produkten zu kaufen. Hier helfen Referenzen weiter, die eine Vorstellung davon haben, dass das sehr wenig Geld ist, was die Anpassung bedeutet in Relation zu dem Nutzen der dabei entsteht. Das hat erst mal nicht so viel mit agil oder nicht agil zu tun, sondern viel mehr, ob das entsprechende Vertrauen vorhanden ist. Möglicherweise ist auch das Budget fix. und der Kunde kann nicht mehr Geld investieren als x EUR. Die Fragestellung ist entscheidend und müsste justiert werden von "Was kostet mein Traum?" hin zu "Was bekomme ich für mein Budget?"

Tobias: Spannend. Der Umfang der Anpassungen hängt bei Vertec Kunden ja davon ab, wie individuell die Prozesse sind und wie weit vom Standard der Kunde weg möchte. Wir haben Kunden, da passt der Standard wunderbar und es sind nur sehr wenige Dienstleistungen erforderlich. Andere Kunden wünschen sich in Vertec individuelle Prozesse und Funktionaltäten. Hier sind wir stark, vor allem wenn wir das mit dem Kunden agil erarbeiten.

Ich habe Dir ja kurz unsere Vorgehensweise in Vertec-Einführungsprojekten geschildert. Wie sind hier Deine Erfahrungen? Was ist zu tun, um mit dem Kunden möglichst agil eine Lösung zu erarbeiten, ohne dass vorher alles starr in eine vertragliche Form gegossen werden muss? Hierbei ist natürlich auch wichtig, dass der Kunde ein erforderliches Maß an Sicherheit behält.

Henning: Der leichteste Weg ist, miteinander zu arbeiten. Sprich, vielleicht muss der Auftraggeber damit leben, dass das erste gemeinsame Projekt kein riesiges Projekt wird. Dass man grundsätzlich bei einem sehr großen Projekt leicht nervös wird und ein hohes Bedürfnis hat, sich vertraglich abzusichern, ist ja absolut verständlich. Insofern sollte man über eine Zusammenarbeit in kleineren Einheiten erstmal Vertrauen aufbauen.

Tobias: Also sind wir hier ja mit dem Vorprojekt gut aufgestellt, da es die Risiken minimiert, man sich kennenlernt und die gegenseitigen Erwartungen ausformuliert. Da bekommt man auch ein gutes Gefühl gibt, wie die Zusammenarbeit im Einführungsprojekt aussehen wird.

Henning: Richtig. Das ist ein sinnvolles Vorgehen und auch in klassischen Projekten gar nicht so unüblich.

Tobias: Sprechen wir doch mal ein bisschen über die unterschiedlichen Vertragsarten, wenn wir sich zwei Parteien im agilen Umfeld handelseinig geworden sind. Das Buch, welches ich vorhin angesprochen habe, heißt ja: "Agile Verträge". Darin habe ich gelesen, dass die kostenorientierten Vertragsarten "Festpreis" und "Time and Material", also nach Aufwand, eigentlich die Klassiker sind, wenn es um Einführung von Standardsoftware geht.

Das trifft auch auf unsere Vertec-Welt zu und ist mit den entsprechenden Vor- und Nachteilen verbunden. Festpreise schränken die agilen Möglichkeiten ziemlich ein und Time & Material bietet zwar sehr viel Freiheit und eine gute Grundlage für agile Ansätze, setzt aber wenig Anreize für den Anbieter, schnell zum Abschluss des Projektes zu kommen, was zu Unsicherheiten beim Auftraggeber führen kann. Daher gibt es hier ja in der agilen Welt Ansätze, nach Produktivität zu bezahlen, um dem Auftraggeber entsprechende Sicherheiten zu geben, sprich nutzenorientiere Verträge. Deren Ziel ist es, die Bezahlung an den Nutzen zu koppeln und sie bieten sehr viel mehr Flexibilität.

Gibt es hier Learnings für uns für sehr große Projekte mit komplexen Anforderungen fernab vom Standard? Das besagte Buch beschreibt diverse Vertragsformen, hier würde ich gerne mal zwei Beispiele Aufgreifen, "Proviant und Prämie" und "Money for Nothing, Change for Free".

Was wir auch in eher größeren Projekten gelegentlich anbieten, ist ein Kostendach "light". In dem Fall schätzen wir die Umsetzung eines bestimmten Features dann auf 20 Personentage (PT) und ab dem 21. PT zahlt der Kunde einen reduzierten Stundensatz. So ist es beiden Seiten daran gelegen, mit dem Feature fertig zu werden und das Risiko wird sich dann geteilt, wenn das Budget reicht. Der Grundgedanke ist ja ähnlich wie bei "Proviant und Prämie ".

Henning: Richtig. Bei "Proviant und Prämie" ist die Reihenfolge allerdings umgekehrt. Der Auftragnehmer arbeitet zu einem kostendeckenden, geringen Stundensatz (sein Proviant), um einen Nutzen zu erreichen, der mit dem Auftraggeber vereinbart wurde. Wird dieser erreicht, bekommt der Auftragnehmer seine Prämie. Spannend ist dabei, und das ist bei Eurem "Kostendach light" auch so, dass beide Seiten bemüht sind, möglichst schnell das Ziel zu erreichen. Verschätzt man sich, was die Aufwände bis zur Zielerreichung betrifft, decken die reduzierten Sätze zumindest die Kosten des Auftragnehmers und reduzieren die Risiken des Auftraggebers.

Tobias: Genau, ein spannender Ansatz. Und dann gibt es ja noch "change for free, money for nothing" als weitere Vertragsart. Diese Variante war mir vorher nicht geläufig. Wie sind da deine Erfahrungen, funktioniert denn das in der Praxis wirklich? Ich habe es so verstanden, dass man beispielsweise vereinbart: Als Projektbudget werden 400 Tage vereinbart.

Wenn bereits nach 350 Tagen beide Parteien meinen, jetzt ist es super, wir sind fertig, wird sich die Differenz zum Gesamtbudget geteilt. Sprich, jetzt kriege ich trotzdem noch Geld vom Kunden. Die Reaktion wäre dann vermutlich. "Ja, Moment mal, dann zahle ich 350 und nicht 375 Tage".

Henning: Die Frage ist hierbei, womit du das vergleichst. Wenn du das mit dem klassischen Festpreis vergleichst, sind von vornherein 400 Tage vereinbart und es gibt meist eine Abnahmeverpflichtung für das gesamte Kontingent. Auch wenn du im Projektverlauf merkst, ich brauche gar nicht mehr Dienstleistungen. Das muss man also miteinander vergleichen.

Wir haben in unserer Firmenhistorie zwei oder drei Mal, "money for nothing" angeboten. Wir haben uns mit dem Kunden bereits auf dieses Modell geeinigt und theoretisch hätte er es auch so beauftragt. Wir haben dann die Ausschreibung leider nicht gewonnen, aber es war zumindest im Gespräch soweit, dass er gesagt hat: „Okay, ich verstehe das. Ihr habt ja auch ein Problem, wenn plötzlich eure Ressourcen wieder frei sind nur weil wir plötzlich das Projekt erfolgreich beenden."

Es geht also darum, das Risiko zu teilen. Was passiert, wenn wir eigentlich gar nicht mehr alles haben wollen bzw. brauchen. Wenn man nach 350 Tagen fertig ist von 400, dann fangen die meisten Leute mit Changes an, um das Budget zu verbrauchen. Für die anderen 50 Tage fallen ihnen schon noch Sachen ein, die sie auch gerne hätten. Es passiert einfach extrem selten, dass jemand sagt: Ich habe keine Ideen mehr.

Tobias: Richtig, eine Lösung "polieren" kann man dann immer noch. Heisst das dann für die Praxis, "money for nothing, change for free" Verträge sind noch eher die Exoten in der Vertragsgestaltung?

Henning: Viele Vertragsarten sind noch nicht weit etabliert. Der "change for free" Teil ist aber tatsächlich für agile Verträge sehr gängig. Das haben wir auch schon oft gemacht.

Anmerkung: Bei "change for free" ist die Idee, dass im Product Backlog definierte Features durch andere Features im gleichen Umfang ausgetauscht werden können, ohne dass dadurch höhere Kosten entstehen.

Tobias: Prima, besten Dank für Deine Zeit Henning.

Möchten Sie mehr Details zu Vertragsgestaltungen?

Wer Interesse hat, mehr über agile Vertragsgestaltung zu erfahren, dem kann ich das Buch "Agile Verträge" empfehlen. Es zeigt sehr verständlich die Unterschiede zwischen starren und flexiblen, bzw. kosten- und nutzenorientierten Verträgen auf und liefert gute Ideen für Vertragsgestaltungen. Festhalten lässt sich, dass es diverse Vertragsarten gibt, die sich unterschiedlich gut für agile Entwicklungen eignen.

Die Verträge sollten aber den Kooperationsgedanken der beiden Parteien unterstützen, daher kommen Risk-Sharing-Prinzipien dem Ansatz sehr entgegen, wie beispielsweise bei "Proviant & Prämie". Daher sollte aber auch über Profit-Sharing nachgedacht werden, denn auch an dem Erfolg tragen beide Parteien ihren Anteil. Wie ich es auch in der Praxis erlebe, kommen die Autoren in dem Buch zu dem Fazit, dass Time & Material und Festpreise nach wie vor die gängigsten Modelle sind- Für die Einführung von Standardsoftware sind diese Verträge ja auch nach wie vor gut geeignet.

Was komplexe Softwareentwicklungsprojekte betrifft, schließen die Autoren mit dem Fazit ab, dass die Softwareindustrie bezüglich der Vertragsgestaltung noch ganz am Anfang stehe und es nicht den einen richtigen Vertrag für agile Entwicklungen gibt, sondern das passende Modell zum jeweiligen Kontext passen muss.

Über it-agile

Die it-agile GmbH wurde 2005 gegründet - als erstes Unternehmen, das sich ausschließlich dem agilen Ansatz in der Softwareentwicklung verschrieben hat. In den letzten mehr als zehn Jahren hat it-agile seine Kunden auf allen Ebenen beraten und unterstützt.

Das Angebot von it-agile umfasst:

• Einführung von Scrum und Kanban auf Projekt-, Team-, Abteilungs- und/oder Organisationsebene
• Management-Beratung für agile Wertschöpfungsketten und Unternehmensstrukturen
• Coaching von agilen Teams und Führungskräften
• Schulungen rund um Scrum, Kanban und agiles Management (öffentlich und Inhouse)
• Bereitstellung von Interims-Scrum-Mastern und -Product-Ownern für Ihr Team
• Technisches Coaching für die Entwicklern im Team: agile Architekturen und Entwurfsprinzipien sowie agile Entwicklungspraktiken

Buchtipp

Agile Verträge: Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche von Fritz-Ulli Pieper und Stefan Roock,

ISBN 978-3-86490-400-4