Weil es immer wieder Thema ist - ein paar Überlegungen zur Gestaltung von Verträgen für "Agilisten".
Weder Dienstverträge noch Werksverträge scheinen das passende Modell für die Gestaltung von Verträgen zu sein, wenn es um agile Softwareentwicklung geht.
Obwohl es mittlerweile viele Informationen zu diesem Thema gibt – einen Einstieg in das Material geben die Links am Ende des Beitrags –, finde ich ein paar konkretere, direkt umsetzbare Ideen notwendig.
Normale Vertragsmodelle
Das deutsche Recht unterscheidet in diesem Bereich im Wesentlichen zwischen zwei Vertragsmodellen und in diesem Raum bewegen wir uns größtenteils, solange wir uns unter "fremden Dritten" bewegen.
Dienstverträge
Dienstverträge – insbesondere unter der offiziellen Überschrift "Beratung" – haben einen besonderen Charme für den Auftragnehmer: Das einzige was wirklich einklagbar ist, ist die Zeit, die der Auftragnehmer für den Auftraggeber arbeitet. Bestimmte Resultate oder Eigenschaften der Arbeitsergebnisse sind hier nicht wirklich erstreitbar.
Werkverträge
Werkverträge auf der anderen Seite sind scheinbar sehr von Vorteil für den Auftraggeber, da hier gerade die Resultate und Eigenschaften einklagbar sind, die vertraglich festgelegt wurden – unabhängig davon wie lange der Dienstleister tatsächlich braucht. Das Problem in der Software-Entwicklung ist, dass eine vollständige, "korrekte" Spezifikation zu schreiben (zumindest aus mathematischer Sicht) exakt so aufwändig ist, wie das schreiben der Software selber und somit die Erstellung des Vertragswerks unangemessen teuer wird.
Diese beiden Varianten fallen also schon mal aus - zumindest als Einzellösungen.
Alternative Verträge für agile Projekte
Aber wie sieht es mit einer Kombination der Lösungen aus?
Wenn wir im Auge behalten wollen, dass wir uns im deutschen Vertragsraum aufhalten und trotzdem einfache Verträge schließen wollen, dann lassen sich durch eine Trennung der Bezahlung der Zeit einerseits und der Inhalte und Qualität andererseits die Verträge sehr stark vereinfachen.
Die meiner Ansicht nach sinnvollste Lösung hat Henrik Klagges in seinem aktuellen Vortrag [4] sehr schön umrissen:
Modell “Proviant und Prämie”
- Der Lieferant bekommt einen niedrigen T&M [Dienstvertrags]-Stundensatz, der garantiert ist und nicht zurückgefordert werden kann
- Zusätzlich gibt es bei Erreichen von definierten Erfolgskriterien eine Prämie
Der Dienstvertragsanteil
Die erste Hälfte dieser Variante ist einfach - da das BGB und das HGB die meisten Aspekte der Vertragsgestaltung für Dienstverträge weitaus besser geklärt haben als der durchschnittliche Individualvertrag lässt sich ein einfacher Dienstvertrag meistens in weniger als einer Seite abhandeln - schließlich geht es nur darum, den Stunden- oder Tagessatz festzulegen und die Form des Zeitnachweises abzustimmen. Selbst Verschwiegenheitserklärungen und Wettbewerbsregelung lassen sich auf dieser einen Seite unterbringen, wenn man sich an die herrschende Rechtslage hält und einfach auf die entsprechenden Paragraphen verweist.
Der Prämienanteil
Der Prämienanteil ist um einiges schwieriger zu gestalten, denn letztendlich handelt es sich hierbei um einen Werksvertrag – oder sogar um eine ganze Reihe davon. Und dies ist die Stelle, an der sich die Geister scheiden - soll die Prämie beispielsweise für das Erreichen bestimmter Meilensteine gezahlt werden?
- 50% der Funktionen am 31.12.?
- Wenn <Liste der features> erfüllt ist?
- Bei Produktionsstart in vollem Umfang am <Datum>?
Meine Meinung ist hier ein ganz klares Nein – zumindest bei dieser Form der Meilensteine.
Diese Art der Meilensteine bezieht sich ja wieder auf die funktionalen Beschreibungen. Die nur mit sehr hohem Aufwand formal vollständig erstellbar sind. Und genau hier sollen ja eigentlich agile Methoden weiterhelfen, indem die Anforderungen durch kurze Rückkopplungsschleifen und direkte Zusammenarbeit zwischen Kunde und Auftragnehmer innerhalb der Projektlaufzeit im Detail erarbeitet werden können. Für die Inhalte der Prämienverträge brauchen wir also andere "Meilensteine" - und eine andere Möglichkeit sie zu bewerten.
Bewertung nicht-zeitlicher Meilensteine
Wichtig für die Bewertung der Meilensteine ist natürlich vor allem, wie sie gestaltet sind – sie müssen sich auf das Ergebnis und nicht auf die Form der Umsetzung beziehen, wenn sie im Kontext agiler Softwareentwicklung sinnvoll sein sollen. Also
"Wir sind in der Lage, Änderungen innerhalb von X Minuten – komplett getestet – ohne manuelle Eingriffe für Endanwender Verfügbar zu machen"
statt
"Wir haben einen Continuous Integration Server aufgesetzt".
Nicht nur, dass die technische Aussage mit dem Continuous Intergration (CI) Server für die Kunden nur schwer nachvollziehbar ist, auch ist die technische Umsetzung noch lange kein Garant dafür, dass die erste Formulierung erfüllbar ist, wie die vielen CI-Server beweisen, die ich in den letzten Jahren gesehen habe, bei denen eine Erfolgsrate von weniger als 25% der Veröffentlichungen vorlag.
Natürlich ist die Zeit bis zur Auslieferung nur ein Aspekt - die Liste der mögliches Aspekte ist lang und sicherlich von Unternehmen zu Unternehmen und da noch mal von Projekt zu Projekt unterschiedlich.
Um aber zur Bewertung dieses Aspekts zu kommen wird der Kontext sogar noch wichtiger - den die finanziellen Auswirkungen sind natürlich von Fall zu Fall sehr unterschiedlich. Ist nur ein einziges Release pro Jahr geplant, weil es sich um embedded Software handelt und das Produkt in dem sie sich befindet nur einmal pro Jahr verschickt wird, dann ist ein hoher manueller Aufwand möglicherweise kein Problem und die (hypothetisch) notwendigen Wochen des Aufsetzens und Konfigurierens des Servers wären viel teurer als 2 Personen, die ein mal im Jahr das Zusammenstellen der Auslieferungspakete 2 Tage lang betreuen. (Die anderen Probleme fehlender kontinuierlicher Integration betrachte ich hier vorsätzlich nicht - sie sind nicht in dem genannten Ziel enthalten und sollten m.E. als separate Ziele beschrieben und bewertet werden)
Um jetzt zu einer Zahl für den Vertrag zu kommen sind allerdings tatsächlich andere Disziplinen notwendig als die Informatik – hier sind wir eher im Bereich der Betriebswirtschaft und Finanzmathematik.
Das konkrete Beispiel – automatisierte Auslieferung – würde ich noch mal unterscheiden, und zwar nach einem komplett neuen Projekt mit eigener Infrastruktur und einem Projekt, das bereits läuft bzw. sich in eine existierende Projekt-Infrastruktur eingliedern soll.
Einfache Zielbewertung bei bestehenden Vergleichsdaten
Wenn wir über die Fähigkeit des Projektes reden Änderungen ohne manuelle Eingriffe verfügbar zu machen, dann fällt die Bewertung bei einem bestehenden Projekt sehr leicht, obwohl sie durchaus aufwändig sein kann. Hier mit hypothetischen Zahlen:
| Releases pro Jahr | 5 mal |
| Bugfix-Releases pro Release bei manuellem Verfahren | 2 |
| Tage manueller Arbeit pro Release | 2 tg |
| Personen beteiligt am Release | 3 ppl |
Ergibt einen minimales Kostenpotential von (5*1 + 5*2)*2*3 = 90 Tagessätzen. Bei einer angenommenen projektierten Projektlaufzeit von 5 Jahren sind das 450 Tagessätze. Ohne Betrachtung des Zinsverlaufes (Barwertbetrachtung der Zahlungsreihe), der bei fünf Jahren auch schon interessant sein kann. Hier wäre eine Prämie für die Zielerreichung von 45 Tagessätzen sicherlich angemessen.
Wohlgemerkt: die eigentliche Arbeit wird nach Aufwand im Rahmen des Dienstleistungsvertrages abgerechnet - die Prämie wird für den Mehrwert der Fähigkeit fällig. Dadurch sind beide Seiten gefordert sich sehr ernsthaft mit der Frage auseinander zu setzten, welche Fähigkeiten wie wichtig sind.
Interessant werden diese Berechnungen, wenn man sie mit dem Businessplan des Projektes vermengt - nehmen wir an, dass wir ein Unternehmen (oder eine Abteilung) mit 40 Mitarbeitern haben, das sich nach 3 Jahren aus den Erträgen der Softwarenutzung selbst finanzieren soll. Nehmen wir das Bundesweite Durchschnittsgehalt im Sektor Information und Kommunikation von 2011 laut Allensbach von 4430 € kommen wir auf einen monatlichen Bedarf von (4430 € * 40) = 177.200 € oder, geteilt durch 30, 5906 € am Tag.
Nehmen wir des weiteren an, das die beiden Bugfix-Releases deshalb nötig waren, weil das System nur eingeschränkt zur Verfügung stand und in den insgesamt 20 Tagen der Bugfix Releases noch mal 50% Umsatzeinbußen zu verzeichnen sind haben wir auf einmal weitere 59.060 €, die der Auftraggeber an Mehrwert hat, wenn der Auftragnehmer einen Teil seiner Arbeitszeit dafür einsetzt diese Fähigkeit zu erreichen.
Ähnlich lassen sich auch andere Fähigkeiten wie z.B. die Fähigkeit Regressionsfehler zu erkennen, die Vorlaufzeit für neue Anforderungen zu kennen oder zu reduzieren etc. tatsächlich finanziell bewerten - je nach Kontext und Situation.
Diese Bewertung ist aber qualitativ anders als eine klassische Meilensteinbewertung nach umgesetzten Funktionen, da wir hier tatsächlich erreichten Fähigkeiten des Prozesses, des Projektes und letztendlich des gesamten Software entwickelnden Systems - Auftraggeber und Auftragnehmer - bewerten.
Planung und Absichtserklärung für neue Situationen
Anders als bei der "einfachen" Betrachtung im Falle der bestehenden Rahmenbedingungen wird die Betrachtung bei komplett neuen Projekten um einiges komplizierter - dafür hat man hier aber auch mehr Spielraum für die Betrachtung nicht-finanzieller Werte.
Diese Aspekte des Vertragswerkes abzuklären ist nicht mit einer einfachen Checkliste wie bei der Auswahl des Sonderzubehörs für ein neues Sportcoupé zu vergleichen, sondern erfordert tatsächlich eine eingehende Beschäftigung mit den Werten von Auftraggeber und Auftragnehmer – sowohl im Sinne von moralisch-ethischen Werten (Mitarbeiterzufriedenheit ist uns wichtig) als auch im Sinne von finanziellen Werten (Neue Mitarbeiter einzuarbeiten kostet uns im Schnitt 150 Tagessätze im Jahr).
Und im Gegensatz zu den ohnehin nur schwer vorab abstimmbaren Details der Funktionen können Vertragsverhandlungen, durch die jene Werte die beide Vertragspartner in der Zusammenarbeit sehen deutlich machen und abstimmen nicht nur schlecht sein.
Hier liegt auch mein (Teil-) Wiederspruch zum agilen Manifest: Obwohl das agile Manifest sagt "Wir schätzen Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung" können Vertragsverhandlungen sehr hilfreich sein, wenn es darum geht, sich über Werte zu einigen. Sofern man sich in der Lage fühlt, Verträge über Werte statt über Tätigkeiten abzuschließen.
mögliche qualitative Meilensteine
- Lead Time (Zeit von der Idee bis zur Nutzbarkeit)
- ist bekannt
- ist bei N Tagen
- Anzahl wieder auftretender Fehler (Regressionsfehler)
- ist bekannt
- liegt bei (oder unter) N pro Release
- Kundenzufriedenheit
- ist messbar
- liegt bei (messbarer Größe)
- Dauer des Realease-prozesses
- Nachvollziehbarkeit der Reviews
- Testabdeckung
- Rollbackfähigkeit (nicht nur für Fehlersituationen)
- Velocity ist bekannt
- ... to be continued - by you! ...
Diese Liste ist in keiner Weise vollständig sondern nur ein Startpunkt für eigene Diskussionen - oder für die Ergänzung hier auf der Website in den Kommentaren
Weitere Aspekte
Was ist mit der Variante: Der Kunde bezahlt einfach nur die Zeit und in echter agiler Manier werden gemeinsam die aktuellen Inhalte erarbeitet?
Bei einem perfekten, vertrauensvollen Verhältnis der Parteien funktioniert dies sicher, aber – wie immer bei zeitbasierter Abrechnung – ist der größte Ökonomische Wert für den Auftragnehmer in diesem Modell zu erreichen, wenn er möglichst langsam arbeitet. Und auch wenn dies überhaupt nicht der Fall ist besteht ein gewisses Risiko, dass dem Auftraggeber in Zeiten, in denen das Projektfahrwasser rauer wird, genau diese Idee überwältigend einleuchtend erscheint und sich darüber die schöne Idee der kooperativen Zusammenarbeit ins negative wandelt.
Persönliche Fußnote:
Links:
[1] 10 Contracts for your next Agile Software Project | Agile Software Development
[2] Primer-Website: Agile Contracts
[4] Vortrag über Agile Verträge bei Agileworld
[5] Contracting for Agile Software Projects, Part 1 | Agile Software Development
