Agile Auftragsentwicklung verändert auch massiv die Art der Zusammenarbeit zwischen Lieferant und Kunde und damit die Art der Vertragsgestaltung. Die neue Konferenz “Agile Contracts” von Gerhard Versteegen und seinem Team von HLMC schafft eine Plattform für den Austausch zwischen Entwicklung, Einkauf und Rechtsabteilung.
Sebastian Schneider und ich ware ohnehin für den Donnerstag der Konferenz gebucht um mit unserer bewährten und beliebten ;) Workshop-Methodik der TOC-Denkprozesse ein wenig Licht in das Dunkel der agilen Vertragsgestaltung zu bringen. Am Tag vor der Konferenz erreichte mich ein Hilferuf von Gerhard Versteegen: Björn Schotte, gebucht für einen Workshop und einen Vortrag sei krankheitsbedingt ausgefallen, ob ich einspringen könne. Nun ist ja Vertragsgestaltung nicht gerade mein Spezialgebiet, so haben wir beschlossen Björn mit Themen von allgemeinem Interesse zu ersetzen: Am Dienstag gab es somit neu im Programm: “Teamwork einmal anders”, meinen Workshop zum Thema Team Resource Management für agile Teams. Am Mittwoch habe ich dann über die Gedankenwelt von Don Reinertsen geplaudert, dem Blick auf Entwicklungsprozesse mit der Brille von Warteschlangentheorie, Lean, militärischer Führung usw. Die Teilnehmer, angereist der Verträge wegen, goutierten diesen plötzlichen Themenwechsel nicht und begaben sich in Scharen zum parallelen Track, wo etwas “Verträglicheres” geboten wurde (haha unbeabsichtigtes Wortspiel, wer das Flow-Buch von Don kennt, weiß was ich meine).
Doch genung von meinen Heldentaten, ich möchte hier ein paar Gedanken zu der Vertragsgestaltung einbringen. Dazu zunächst eine kleine Wiederholung zu den klassischen Verträgen:
Was bisher geschah
Bisher wurde Softwareentwicklung wie folgt beauftragt: Der Kunde schreibt eine Spezifikation, von der er annimmt dass sie eindeutig, vollständig und seinem Business dienlich ist. Der Lieferant sagt zu, zu einem Festpreis eine Software (oder ein Produkt) zu entwickeln, welche die Spezifikation erfüllt (auch noch zu einem bestimmten Datum) und los geht die Entwicklung. Änderungen unterwegs werden dann nach Absprache bepreist und irgendwann sind beide Parteien glücklich, oder vor Gericht, oder irgendwas dazwischen. Halten wir aber fest, dass die Investitionssumme für den Kunden fix ist, das wirtschaftliche und technologische Risiko also vom Lieferanten getragen wird (zumindest vordergründig, aber dazu später mehr).
Wir haben also ausgehend vom Problem im Business des Kunden zwei Artefakte und zwei Transitionen.
Erste Transition und erstes Artefakt: Der Kunde übersetzt sein Business-Problem in eine Spezifikation, von der er annimt, dass sie sein Problem löse.
Zweite Transition und zweites Artefakt: Der Dienstleister wandelt die Spezifikation in ein Software-Produkt um.
Wenn nun nach einigen Monaten oder Jahren Entwicklungszeit die Software auf dem Tisch liegt, lässt sich einigermaßen brauchbar überprüfen, ob die Software der Spezifikation entspricht, also ob die zweite Transition gelungen ist. Ob jedoch das Produkt das Business-Problem des Kunden löst (und ob sein Problem nach der Entwicklungszeit noch dasselbe ist) kann so nicht überprüft werden. Hier kommt der agile Ansatz ins Spiel.
Agile Entwicklung
In der agilen Entwicklung gibt es bei Projektstart keine festgezurrte Spezifikation, eher ein grobes Konzept. Denn beide Parteien sind sich einig, dass der Wert der Software nur im Business des Kunden ermittelt werden kann und dass Entwicklung nicht so sehr kalkulierbar ist, wie das immer angenommen wurde. Das Produkt wird in engem Kontakt entwickelt, mit einer lauffähigen Version alle paar Wochen und mit entsprechendem Feedback des Kunden. Endlich also ein Regelkreis der beide oben beschriebene Transitionen überprüft.
Die Frage die bleibt: Wie wird der Lieferant bezahlt? Nach Aufwand? Oder lässt sich ein Festpreis vereinbaren, trotz weicher Spezifikation? Das war das Thema auf der Agile Contracts. Im Folgenden nun ein paar Statements denen ich auf der Konferenz begegnet bin.
Statements Agile Contracts 2015
Boris Gloger beschäftigt sich schon länger mit dem Thema, sagt aber auch, dass die Modelle in seinem Buch “Der agile Festpreis” als Versuche zu betrachten sind, aus denen sich etwas weiterentwickeln soll. Boris ist der Meinung, dass der Dienstleister keine Kosten mehr angeben sollte, sondern der Auftraggeber die entwickelten Features nach deren Wert bezahlen sollte. Also nach dem Wert im Business des Auftraggebers. Interessantes Statement in Boris Keynote: “Agilität ersetzt Vertrauen durch Feedback”. Das ist schon mal spannend, denn ein Blick in die Agenda zeigt: Vertrauen müsste die neue Basis für Zusammenarbeit sein. Das Statement von Boris, Vertrauen zu ersetzen geht also genau in die andere Richtung. Was bleibt ist die Diskussion was denn nun der Unterschied zwischen Kontrolle (negativ belegt) und Feedback (positiv belegt) ist.
Die Diskussion über den Business Value statt über die Kosten finde ich ganz interessant. Auf den ersten Blick sieht das ja so aus, als ob dann die Gewinnchancen des Kunden zum Dienstleister durchgereicht würden und somit Risiko und Gewinn ungleich verteilt wären. Aber auch bei der Kostenbetrachtung der Zulieferung hat der Kunde ja seine Gewinnmöglichkeiten durch die beauftragte Software im Hinterkopf und wägt diese gegen die Kosten (Angebot des Dienstleisters) ab. Nur bisher geschah das immer auf Produktebene. Auf Feature-Ebene würde es dann ja so aussehen, dass der Kunde ein Feature verlangt und gleich dazu sagt, was es ihm wert wäre. Der Dienstleister sagt dann bei jedem Feature Ja oder Nein. So viel zur Theorie. Aber was geschieht realistischerweise bei einem Nein? Der Kunde fragt, was denn der minimale Einsatz dafür wäre und schon sind wir wieder bei der Kostenbetrachtung. Ausserdem schwingt hier die Angst des Kunden mit, in Unkenntnis des Realisierungsaufwands zu viel zu bezahlen und somit seinen Gewinn zu schmälern. Es lohnt sich aber im eigenen Kontext darüber nachzudenken: Ist es handhabbar mit einer Art Festpreis pro Feature zu arbeiten und: Warum muss der Lieferant den Preis ansagen, kann das nicht auch der Kunde?
Eine Geschichte ist bei mir besonders hängen geblieben: Stefan Roock berichtet aus der Zeit als seine Firma “it-agile” noch als Entwicklungsdienstleister unterwegs war: In einem agilen Setup gab es immer wieder Diskussionen, wenn die Entwickler nach Fertigstellung eines Inkrements noch Verbesserungsvorschläge hatten. Die Kunden waren inhaltlich von den Vorschlägen begeistert, jedoch stets der der Meinung die Kosten für deren Umsetzung wären vom Dienstleister zu tragen, entsprang doch die Idee dazu den Köpfen seiner Entwickler. In der Folge kamen immer weniger Vorschläge von den Entwicklern, weil die dargestellten Diskussionen stets eine Verschlechterung des Projektklimas verursachten.
Ich erlaube mir, Stefans Geschichte auf einen einfachen Nenner zu bringen:
“Festpreise tauschen Innovation gegen Sicherheit ein.”
Das gefällt mir. Das war meine Zusammenfassung von Stefans Keynote in einem Satz. Und ich wollte in den weiteren Vorträgen ausprobieren, wo dieser Satz überall passt.
Über seine Erfahrung mit Vertragsgestaltung berichtete der Anwalt Jan Schneider. Er (bzw. seine Mandanten) hat die besten Erfahrungen mit Verträgen gesammelt, in denen mit Festpreisen gearbeitet wird (auf Basis eines Grobkonzeptes). Dabei ist es wichtig, bei Änderungen oder Detailspezifikationen für die Inkremente zu unterscheiden: “Ist das eine Detaillierung des Grobkonzepts oder ist das ein neues Feature?”). Diese Unterscheidung kommt zunächst ein mal nicht besonders agil daher, auch wenn sie funktioniert. Aber wenn sie für beide Seiten OK ist, warum nicht. Letztendlich ist es gegenüber der reinen Agilität lediglich (obacht, mein Auftritt) “ein Tausch von Innovation gegen Sicherheit”.
Wer trägt das Risiko?
Auftraggeber lieben den Festpreis, denn sie bekommen definierte Leistung zu definiertem Preis. Der Dienstleister trägt wie oben beschrieben das technologische und das wirtschaftliche Risiko. Doch die Realität sieht anders aus. Wenn das Projekt scheitert oder sich verzögert ist der Schaden auch für den Auftraggeber erheblich. Sein Business ist schnellebig und die Software soll ihn unterstützen. Dass er im Extremfall keine Kosten für das gescheiterte Projekt trägt, ist nur die halbe Miete. Die Verzögerungskosten (Cost of Delay) trägt er auf jeden Fall. Auch wenn nicht alle Juristen und Betriebswirte diese Kosten sehen oder gar berechnen können (siehe auch mein Artikel zur Vollauslastung).
Hingegen sind Time and Material Projekte im agilen Umfeld sehr angenehm für den Dienstleister, in diersem Modell trägt er kaum Risiko, verkauft seine Zeit. Sein Risiko ist, dass der Kunde abspringt wenn die Performance nicht stimmt. Wenn aber hier der Auftraggeber das Risiko trägt, entspricht das Setup einem internen Entwicklungsprojekt. Die Grenze zwischen Kunde und Dienstleister fällt weg. Naja doch nicht, denn der Dienstleister ist eine eigene wirtschaftlich operierende Organisation, sollte also auch (nach meinem Verständnis) ein Risiko übernehmen.
Formen der Zusammenarbeit
Je mehr ich über die beschriebenen Risiko-Verteilungen nachdenke, desto mehr bin ich der Meinung: Es gibt keine Musterlösung für Verträge in agilen Entwicklungsprojekten, solange wir in der Art der Zusammenarbeit nicht umdenken. Aus Sicht der Auftraggeber ist ein Festpreis schon ein gute Sache, man sollte sich nur bewusst sein, dass die damit angestrebte Sicherheit durch minimierte Innovation erkauft wird. Für maximale Innovation (Time and Material?) hingegen trägt der Auftraggeber den Hauptteil des Risikos, analog zu einer Eigenentwicklung. Das heisst, dass der Auftraggeber Verantwortung und Risiko für einen größeren Teil der Wertschöpfungskette trägt als er eigentlich will. Und damit sind wir bei der Kernfrage:
“Kann in Wertschöpfungsketten agil entwickelt werden?”
Ich denke die Lösung liegt nicht in der Suche nach neuen Vertragsgestaltungen in herkömmlichen Lieferketten. Agilität erfordert ein Miteinander statt einem Über- und Untereinander.
“Ein Joint Venture für jedes Projekt?”
Das wäre vielleicht übertrieben, wir brauchen eine Form der Zusammenarbeit, die mit minimalem Aufwand auf Projektebene umzusetzen ist. Und wärend ich auf der Konferenz über dieses Thema nachgedacht habe, wurde ich von einem unserer Workshopteilnehmer auf eine sehr spannende Lösungsmöglichkeit hingewiesen. Der Kollege (Jurist) trat mit aller Vehemenz dafür ein, Entwicklungsprojekte in Zukunft in BGB-Gesellschaften zwischen Auftrageber und Dienstleister durchzuführen. Das ist der Ansatz, der für mich nach einigem Grübeln vorerst am plausibelsten erscheint. Vielen Dank an diesen Teilnehmenr (Name leider unbekannt) für diese Erleuchtung. Zusammen mit meiner Innovationsthese von oben, sage ich also heute:
“Agile Projekte können zur Innovationsmaximierung bei gleichzeitig schlüssiger Risikoverteilung nur in Form von Joint Ventures durchgeführt werden. Eine BGB-Gesellschaft zwischen Auftraggeber und Auftraggnehmer kann dabei eine leichtgewichtige Lösungsmöglichkeit sein.”
Bin gespannt, was die Zukunft bringt…