Wenn ITler Verträge machen steht der Schutz des eigenen Hinterteils im Vordergrund, und in Wahrheit versteht keiner die Konsequenzen des geschriebenen. Am Ende wird er ohnehin nichtig und durch einen Vergleich ersetzt, bei dem Anwälte das Bauchgefühl der Mandanten verhandeln, um nicht bei einem vollständig sachfremden Richter ein blaues Wunder zu erleben. Aber was hilft dann, wenn der Inhalt eines Projektes erst am Ende wirklich feststeht, und die meisten schwierigen Fragen sich erst im Verlauf ergeben?

1. LIES
Lügen,
schlimme Lügen
&IT-Verträge
Guten Morgen!
Ich freue mich, dass doch noch ein paar Leute da sind. Obwohl das Thema - IT-Verträge - alles andere als spannend ist und der Abstract schräg kopiert war, der zweite
Teil war eigentlich nur Anmerkung für das Board. Damit die den nicht mit dem agile-Verträge-Talk verwechseln, weil darum geht es mir heute nur ein bisschen.

2. Seitdem ich IT
mache nervt es
…
Ich bin ein typischer IT-Nerd, und ich möchte coole Sachen mit Computern machen, die meine Kunden begeistern. Damit ist der Vertrag mein natürlicher Feind, denn er
möchte verhindern, dass ich coole Dinge mache, die meine Kunden begeistern. Er möchte, dass ich genau das mache, was im Vertrag steht. Deshalb haben Verträge
und ich schon immer ein gespaltenes Verhältnis.

3. IANAL.
Eins vorweg - natürlich bin ich kein Anwalt. Und ich rate hier auch nicht zu Verträgen, und Rechtsberatung darf ich sogar rechtlich nicht machen. Ich weiß ehrlich gesagt
noch nicht mal, ob die Aussage, dass das keine Rechtsberatung ist, schon eine Rechtsberatung wäre. Aber mir geht es auch eigentlich um einen anderen Punkt :-)

4. „There are three kinds of lies: lies,
damned lies, and statistics.“
Mark Twain credited this to Disraeli. (that’s a lie)
Wer den Titel gesehen hat weiß natürlich, wo der herkommt.
Es gibt drei Arten von Lügen - Lügen, schlimme Lügen und Statistic.
Bezeichnenderweise ist auch dieses Statement selbst eine Lüge, denn obwohl Mark Twain es Disraeli anhängt hat dieser es so nicht gesagt - als Politiker, der Statistik als
Basis seiner Arbeit nimmt, wäre das vermutlich auch unklug.
Deshalb hat auch Churchill nicht gesagt, dass er keiner Statistik glaubt, die er nicht selbst gefälscht hat. Das hat Göbbels über ihn behauptet, und das ist auch eine Lüge
gewesen.

5. Wieso das denn?
Statistiken dokumentieren
doch nur die Realität?
Warum glaubt man Statistiken nicht? Statistiken fassen doch meist nur echte, gesammelte Daten zusammen?
Hat jemand eine Idee?
Genau, weil Statistiken Kontext haben - und im Richtigen Kontext angewandt sind sie wahr, man kann sie mit neuem Kontext auch gut missbrauchen.

6. „Dienst nach Vorschrift.“
In Deutschland gibt es den Begriff von Dienst nach Vorschrift. Auch hier würde man denken „Hey, ist doch super, wenn alle Leute es so machen würden wie die Vorschrift
es fordert.“
Gerade wir Deutschen, die gerne mal mitten in der Nacht einsam und verlassen auf die grüne Fussgängerampel warten sollte das doch eine völlige Superidee sein.
Wenn Ihr mit jemand kooperiert der Dienst nach Vorschrift macht, wäre das eine Superidee?

7. „Der Bundesgerichtshof sah
1973 ein derartiges Verhalten
von deutschen Fluglotsen, die als
Beamte nicht regulär streiken
durften, als rechtswidrig an.“
Quelle: https://de.wikipedia.org/wiki/Dienst_nach_Vorschrift
Faktisch ist Dienst nach Vorschrift sogar höchstrichterlich durch den Bundesgerichtshof verboten worden. Es ist eine Form des Streiks, genau nach Vorschrift zu
arbeiten.

8. „Du machst Dich strafbar, wenn
Du Dich genau so verhält,
wie wir es im Arbeitsvertrag
vereinbart haben.“
Das muss man sich mal auf der Zunge zergehen lassen:
Der Staat kann seine Angestellten verklagen, wenn sie sich genau so verhalten, wie es Ihre Vorschriften vorsehen.

9. IT-Verträge
Schauen wir uns das doch mal in der IT an.

10. „Vertrag:
Vereinbarung, die erst
wirksam wird,
wenn das Vertragen endet.“
Aber kommen wir zu den Verträgen. Auch zu denen gibt es sehr viele Zitate, und ich habe mal ein paar gesammelt. „Der Vertrag ist eine Vereinbarung, die erst wirksam
wird, wenn das Vertragen endet.“.
Wäre nicht eine Vereinbarung besser gewesen, die macht, dass man sich verträgt?

11. "Jeder Vertrag enthält einiges,
was er nicht enthält."
Ein Vertrag enthält einiges, was er nicht enhält. Offensichtlich gibt es da Dinge, die wichtig sind, die man aber mit einem Vertrag nicht in den Griff bekommen kann.

12. „Vor dem Richter
und auf hoher See
sind wir in Gottes Hand.“
Und dann gibt es da noch den schönen Satz „Vor dem Richter und auf hoher See sind wir in Gottes Hand.“ - offensichtlich hat man wenig Einfluss auf das, was passiert,
wenn man vor Gericht steht. Während der Durchschnittshamburger die hohe See für ein kalkulierbares Risiko hält, auf das man sich mit den richtigen Massnahmen
einstellen kann.

13. „Eines der obersten Ziele bei der
Vertragsgestaltung ist die
Vermeidung von Risiken. Der
schönste Vertrag nutzt Ihnen
nicht viel, wenn er hohe Risiken
birgt.
Kapitel 1 Absatz 1 „Gestaltung und Management von IT-
Verträgen“
Wozu gibt es IT-Verträge? Eines der obersten Ziele bei der Vertragsgestaltung ist die Vermeidung von Risiken. Der schönste Vertrag nutzt Ihnen nicht viel, wenn er hohe
Risiken birgt.
Das ist der erste Absatz im ersten Kapitel des guten Buches „Gestaltung und Management von IT-Verträgen.“.
Im Umkehrschluss: wenn ich einen guten Vertrag habe, dann habe ich auch keine hohen Risiken mehr?

14. Chaos Report 2012
18 %
43 %
39 %
Successful
Challenged
Failed
Das sind die Zahlen aus dem Chaos Report 2012. Etwa 20% werden ohne Ergebnis beendet, der größte Teil erfüllt nicht das, was im Vertrag - nämlich Scope & Budget -
vereinbart wurde. Nur knapp 40% liefern das, was vereinbart war.

15. Das scheint ja nu nicht so gut geklappt zu haben. Das Hauptziel der Verträge ist, es grosse Risiken zu vermeiden, und trotzdem klappt das nur in 40% der Fälle? Na, Ihr
Rechtsanwälte seit ja mal eine Grosse Hilfe gewesen.

16. WTF?
Offensichtlich ist da was Fischig mit den Verträgen. Die scheitern grandios an der gestellten Aufgabe, und trotzdem machen wir sie? Sollte man sich da nicht etwas
besseres erlauben?

17. Cynefin
Lebensraum, Platz
Um an das Problem näher heranzukommen brauche ich mal Cynefin. Nachdem sich jetzt die Welt entschlossen hat, das weitestgehend frei und nicht
walisisch auszusprechen halte ich mich daran. Wer das kennt: tut mir leid, da müsst ihr jetzt durch, ich beeile mich. Wer das nicht kennt: das ist nützlich.

18. Komplex Kompliziert
Chaotisch Offensichtlich
Verwirrung
Cynefin ist ein Sensemaking-Model, also ein Modell das hilft, um Dinge zu verstehen.
Gartner: “By 2016, the Cynefin framework will be used in 10% of IT operations organizations as a sensemaking methodology.“.
Und hier hilft es.
Es unterscheidet Dinge, die zB in Unternehmen passieren, in 5 Quadranten - komplex, kompliziert, chaotisch & offensichtlich.

19. Ping
Pong
OffensichtlichDer Zusammenhang zwischen Ursache und Wirkung ist bekannt, vorhersagbar und wiederholbar.

20. Kompliziert
Ping
Einfach
Pong
Kompliziert
Ursache und Wirkung sind über Zeit und Raum getrennt, aber nachvollziehbar und wiederholbar.
Das ist nicht trivial, aber machbar. Es ist besser, wenn ich eine Ausbildung und/oder Erfahrung mitbringe. Wird auch Knowable genannt, man kann es also
sicher wissen, wenn man will. Komplizierte Welten können komplizierte Teile enthalten, aber alles verhält sich vorhersagbar, wenn man sich nur genug Zeit
nimmt.

21. Chaotisch
Pong
In Chaotisch wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung. In chaotischen Teilen weiß ich nicht, was warum
passiert. Ich mache Dinge und Dinge passieren, warum das so ist und wie die zusammenhängen - keine Ahnung.

22. Komplex
Einfach
Einfach
Chaotisch
Komplex
Kompliziert
Einfach
In komplexen Welten wird es etwas anstrengender. Wie in der komplizieten Welt enthält ein komplexes System offensichtliche und komplizierte Teile, es kann aber auch
chaotische und selbst komplexe Teile enthalten.

23. Komplex
Einfach
Einfach
Chaotisch
Komplex
Kompliziert
Einfach
Diese stehen wieder in Beziehung, sie beeinflussen sich - in einer oder in beide Richtungen.

24. Komplex
Einfach
Einfach
Chaotisch
Komplex
Kompliziert
Einfach
verstärkend
dämpfend
Rück-
kopplung
Und sie wirken aufeinander, sie können sich verstärken und dämpfen - und es gibt Rückkopplungen. Und diese Schleifen machen uns das Leben schwer- denn sie
lassen sich nur schwer vorausberechnen und vorhersagen. Auch die chaotischen Anteile sind nicht vorhersagbar, und das gleiche gilt natürlich auch für die komplexen
Anteile, die enthalten sind.

25. Komplex
Einfach
Einfach
Chaotisch
Komplex
Kompliziert
Einfach
verstärkend
dämpfend
Rück-
kopplung
Und als ob es noch nicht genug wäre, gibt es in komplexen Systemen natürlich noch externe Einflüsse, die nicht vorhersagbar sind.

26. Ursache und Wirkung sind erst im
Nachhinein zu verstehen.
Im Vorhinein ist es nicht möglich.
KomplexUnd das macht das komplexe System zu einem gemeinen. Ursache und Wirkung verstehen wir erst im Nachhinein. Erst wenn wir wissen, welche externen Einflüsse es
gab, welche Rückkopplungen, welche Verstärkungen, welche Schleifen wie gewirkt haben können wir sagen, was relevant für das Ergebnis war und was nicht.

27. Es gibt unbekannte Unbekannte
- man weiß noch nicht mal,
nach was man fragen sollte.
KomplexIch weiß also vorher auch nicht, welche Variablen ich mir angucken muss. Das sind unbekannte Unbekannte, also Dinge, von denen man gar nicht weiß, dass man sie
nicht weiß.

28. Das Ergebnis kennt man erst
wenn es existiert.
KomplexDamit kann man offensichtlich nicht vollständig planen - ich weiß weder, wie Ursache und Wirkung zusammenhängen wird, noch weiß ich, welche Fragen ich stellen
müsste.

29. Komplex
Egal wie viel Zeit man mit
Analyse verbringt, es ist nicht
möglich, die Risiken zu
identifizieren oder die Lösung
oder den Aufwand zur
Problemlösung vorherzusagen.
Jetzt könnte man sagen: ja, da haben die halt nicht genug recherchiert. Da hätten Sie einfach noch mehr planen müssen. Das Problem ist aber, dass selbst ein endlos
grosser Aufwand für Planung weder die Lösung bestimmen kann, noch die Risiken erkennen kann, noch den Aufwand zur Problemlösung selbst bestimmen kann.
Das klingt wie ein Paradoxon: es ist billiger etwas zu machen als es zu planen.

30. Komplizierte Systeme
Wir Informatiker mögen komplizierte Systeme, da kann man brillanten Kram machen und mit Brain-Fu punkten. Mit genug Nachdenken ist jedes Problem verlässlich
lösbar.
Also wäre es doch super, wenn alle unsere Aufgabenstellungen komplizierte wären, weil wir darin so gut sind?
Wie sieht es denn in der Praxis aus?

31. Einfach
Kom
pli
ziert
Komplex
Chaotisch
Lösung
klar
Lösung
unklar
Anfoderung
unklar
Anforderung
klar
Die Stacey-Matrix gibt einem die Möglichkeit, die Aufgaben einzuordnen - und zwar nicht nur in die Quadranten aus Cynefin, sondern auch klassifiziert
nach Verstandenen Anforderungen und Lösung.
Es gibt viele IT-Probleme, die in einfach stattfinden - die 20te Landing-Page und das 12te CMS. Wenn der Kunde aber noch nicht weiß was er will befinden
wir uns im linken komplizierten Umfeld, da muss dann der Requirementsmanager klären um was es tatsächlich geht, wenn wir den XML-Import eines
Lieferanten integrieren müssen sind wir im rechten komplizierten Feld erst analysieren müssen, wie das XML aussieht, ob da alles drinsteckt was wir
brauchen und die Schnittstelle selbst überhaupt funktioniert.

32. Einfach
Kom
pli
ziert
Komplex
Chaotisch
Lösung
klar
Lösung
unklar
Anfoderung
unklar
Anforderung
klar
Ich habe Stacey-Chart oft in der IT gemacht, und meist landen IT-Projekte im komplexen. Die Anforderungen sind nicht völlig klar, dafür aber auch die Lösung nicht. Aber
man weiß, was man tut.

33. 6 Monate
6 Personen
50% Scope-Creep
„Looks like there are unknown unknowns.“
David J Anderson von Agile Manager hat mehrere tausend Projekte analysiert, und die bekommen - grob als Faustformel - während der 6 Monate noch etwa die Hälfte an
Aufwand mit dazu. Das erklärt auch die schlechte Trefferquote in Time & Budget im Chaos-Report.

34. !
"
#
$
%
&
Workflow Engine
Supplier Service
User Management
ERP
E-Commerce-Module
Web Frontend
Das ist auch nicht weiter verwunderlich - denn innerhalb unserer Lösungswelten selbst findet eine ganze Reihe von komplexen Systemen statt. Das Zusammenspiel
zwischen verschiedenen Komponenten in einer IT-Landschaft ist zB ein klassisches komplexes System.

35. Sales-Guy
Management
Project Lead
Endkunde
Product Development
Developer
Aber auch im Wetwarebereich passiert das. Das Team, die Kooperation mit dem Dienstleister.

36. Und auch wenn es manchmal aussieht als wäre es ganz einfach - faktisch stecken praktisch überall komplexe Elemente drin.

37. Einfach
Kom
pli
ziert
Komplex
Chaotisch
Lösung
klar
Lösung
unklar
Anfoderung
unklar
Anforderung
klar
Die meisten IT-Projekte finden also im komplexen Bereich statt. Bei den anderen müssen wir uns keine Sorgen machen, ausser sie sind chaotisch.

38. IT-Verträge
Kommen wir zurück zu den Wertverträgen. Welche beiden grossen Typen gibt es da?

39. Werkvertrag
1. Vereinbarung
2. Implementierung
3. Abnahme
4. Mängelbeseitigung
5. Bezahlung
Werkverträge - und auch Kaufverträge, mit ein paar Abweichungen - bestehen auf der Zeitlinie im wesentlichen aus der initialen Vereinbarung, also dem Vertrag und der
Definition des Werkes selbst, dann folgt die Implementierung, dann die Abnahme, es gibt Mängel die erkannt und beseitigt werden, und natürlich wird auch irgendwann
noch einmal bezahlt.

40. • Vereinbarung
• Detaillierte Aufgabenstellung
• Fertigstellungstermin
• Kosten
• Gewährleistungen
• Haftung …
Die initiale Vereinbarung besteht aus diesen Teilen:
der detaillierten Aufgabenstellung, dem Fertigstellungstermin, den Kosten, der Handhabe von Gewährleistung und Haftung.

41. • Detaillierte Aufgabenstellung
„Das Ergebnis kennt man erst
wenn es existiert.“
Schauen wir uns die Punkte doch mal im Detail an.
Wir brauchen also eine detaillierte Aufgabenstellung. Zeitgleich wissen wir aus dem Verhalten komplexer Systeme, dass das Ergebnis erst bekannt ist, wenn man durch
die ganze Schoose durch ist.
Wer kennt Pflichtenheft mit mehr als 500 Seiten?
Wurde die Software so implementiert?
Wenn ja: war der Kunde damit zufrieden?

42. 500Seiten Pflichtenheft,
anyone?
Wer von Euch hat es schon mal mit kompletten Bäumen zu tun gehabt, wenn es um Pflichtenheft geht? . Wenn es hinreichend vollständig definiert ist, enthält es auch
Widersprüche. Und die kann ich zwar in ein Word-Dokument schreiben, implementieren kann ich sie aber nicht.

43. • Fertigstellungstermin
• Kosten
Aber schauen wir weiter. Fertigstellungstermin und Kosten.
Wir ITler werden gerne gefragt, und faktisch können wir nur Daumenpeilen und schätzen. Statistisch sind unsere Schätzungen immer unvollständig. Das muss so sein,
schließlich handelt es sich um ein komplexes Systen.

44. • Fertigstellungstermin
• Kosten
Egal wie viel Zeit man mit
Analyse verbringt, es ist nicht
möglich, die Risiken zu
identifizieren oder die Lösung
oder den Aufwand zur
Problemlösung vorherzusagen.
Wir bräuchten tatsächlich beliebig viel Zeit, um in einem komplexen Projekt die Risiken zu identifizieren, die Lösung selbst auszudefinieren und damit auch Ihre Kosten zu
bestimmen.

45. 18 %
43 %
39 %
Successful
Challenged
Failed
• Fertigstellungstermin
• Kosten
Da sind wir wieder bei ihm hier. Das klappt dann ja immerhin in 39% der Fälle.

46. Standish Group Chaos Report
Successful
!=
in Scope, Time & Budget
Es wird noch besser. Für den kommenden Standish Group Chaos Report wurde auf Bitte der Kunden die Definition von Successful verändert. Bislang waren das alle
Projekte, die in Scope, Time & Budget waren. Sie haben gesagt: das hat mit dem Projekterfolg eigentlich praktisch gar nichts zu tun. Statt dessen wird jetzt geschaut, ob
der Wert des Projektes wahrgenommen werden kann. Tatsächlich ist Scope, Time & Budget offensichtlich nicht Projekterfolg.

47. • Abnahme
• Mängel / Abweichungen
• Gewährleistung
Ursache und
Wirkung sind erst
im Nachhinein zu
verstehen.
Im Vorhinein ist
es nicht möglich.
Kommen wir zur Abnahme. Nachher verstehe ich also, was ich am Anfang hätte haben wollen - und fordere es ein, denn es macht jetzt total viel Sinn.
Das kannte der Dienstleister aber zu dem Zeitpunkt nicht, also konnte er das nicht liefern.

48. Werkverträge sind
inkompatibel
zu Komplexität.
Implizite Anforderungen
Werkverträge / Kaufverträge haben also so ihre Probleme mit komplexen Aufgabenstellungen. Und sie können die in sie gestellte Aufgabe, alles abzudecken, das Werk,
die Risiken und den Aufwand zu Regeln nicht gerecht werden. Sie können nicht vollständig sein, und müssen implizite Anteile enthalten.

49. Opportunistischer Exploit
Feature Creep:
Hey, das war doch völlig
offensichtlich. Das hatte
ich doch auch im Meeting
erklärt, und Sie hatten
genickt.
Das kann man natürlich auch ausnutzen. Auf Auftraggeber kann man das ausnutzen indem man die impliziten Anforderungen vollständig als gegeben ansieht. Und dies
hätte der Dienstleister ja berücksichtigen können, weil im Vertrag auf die Grafik als mitgeltendes Dokument verwiesen wird, und zu dieser Grafik wurde ja in einem
Meeting erklärt, wie sie zu verstehen ist.

50. Opportunistischer Exploit
Feature uncreep
Wir implementieren nur was
explizit angefordert war. Alles
andere ist Change Request.
Das gleiche gilt auch auf Auftragnehmerseite. Hier macht der Dienstleister Dienst nach Vorschrift - wie im Vertrag vereinbart. Plötzlich wird aus dem eben noch
hochintelligenten Developer ein Post-Lobotomie-Patient, dessen Koordinationsfähigkeiten gerade zum Verweis auf Anforderungsdokument und Projektmanagement
taugt.

51. Opportunistischer Exploit
Max(Features/Aufwand)
==
Min(Qualität)
Wenn Werksverträge nur auf die äusseren Eigenschaften des Werkes eingehen, dann können wir ja die inneren so machen wie wir wollen. Und mit Copy & Paste,
Qualitätsproblemen, unbehandelten Fehlern, schlechtem Design so weit gehen, dass unsere eigene Arbeitszeit minimal ist.

52. Juristische Lösung
§243 Absatz 1 BGB
Bei fehlender konkreter
Vereinbarung wird eine Lösung
„mittlerer Art und
mittlerer Güte“
geschuldet.
Natürlich gibt es eine rechtliche Regelung, wenn Dinge nicht explizit sind. Sofern nicht anders vereinbart, nimmt man mittlere Art und mittlere Güte an. Das gilt für beide
Parteien - der eine darf nicht mehr verlangen, der andere muss nicht mehr liefern.

53. Juristische Lösung
§243 Absatz 1 BGB
Gesetzlich
garantiertes
Mittelmass.
Das ist auch wieder ganz spannend - man baut eine neue Software. Und die gesetzliche Incentivierung zeigt nicht auf das beste, was für das Geld zu haben ist, sondern
auf eine mittelmässige Lösung.

54. Change Request! Implizite
Anforderung! Bug!
Und wer klärt, was eine Mittelmässige Lösung ist? Meist gibt es einen offiziellen Change Management Prozess, bei dem man sich einigt. Die Grundlage ist der Vertrag,
überall wo es daraus nicht hervorgeht zählt das Mittelmass. Weil wir aber gerade in einer komplexen Umgebung sind, ist das keineswegs so einfach. Und jeder von uns,
der mal bei solchen Dingen dabei sein durfte, weiß, wie viel man dort im Nebel navigiert und sich auf seinen Bauch verlässt.
Eine verbindliche Extrapolation des Expliziten gibt es nicht, und sie orientiert sich auch nicht am für das Projekt Optimalen - denn das kennen wir auch noch gar nicht, wir
sind schliesslich in einem komplexen System.

55. Also lieber Dienstvertrag!
Es wird Bemühen geschuldet,
nicht der Erfolg.
Das Risiko liegt
beim Auftraggeber.
Also, sagen wir Dienstleister, dann doch gleich lieber Dienstvertrag. Dann können wir zu jedem Zeitpunkt das sinnvolle machen, und brauchen uns nicht in
Vetragsinterpretationsdiskussionen aufzureiben.

56. Also lieber Dienstvertrag!
Komplexes Environment: Check.
Tatsächlich sind Dienstverträge das übliche Werkzeug der Wahl, wenn das Environment hinreichend komplex oder gar chaotisch ist. Wenn Anforderungen, wenn
technische Lösung oder die Kombination von beidem schlecht verstanden ist bildet Dienstvertrag praktisch die klassische Basis der Kooperation.

57. Opportunistischer Exploit
Der Dienstleister erhöht
seinen Gewinn
indem er langsamer
arbeitet.
Und es gibt noch einen Grund, warum wir Dienstleister solche Verträge mögen - wir werden für schlechte Performance über kurz nicht nur nicht bestraft, sondern sogar
belohnt. Wenn eine Leistung sehr langsam erbracht wird, dann steigt bei uns sowohl Umsatz als auch Gewinn.

58. Und was macht man als Auftraggeber? Man kontrolliert, um sicherzustellen, dass man nicht ausgenutzt wird. Kein Spass, es gibt Auftraggeber, die stichprobenartig
Zeitbuchungen, Tickets und Commits nebeneinanderlegen, um zu prüfen, ob wirklich schnell genug gearbeitet wurde.
Wer würde hier heute noch nach Lines of Code bezahlen? Genau.

59. Dienstvertrag
Das ist als Idee gut, und im Obvious-Quadranten, wo alles einfach und nachvollziehbar ist funktioniert das auch. Im Komplexen Quadranten wiederum machen komplexe
Systeme, was komplexe Systeme so machen - und es gibt zB Schmetterlingseffekte. Wer kennt den Schmetterlingseffekt? Genau, ein einziger Flügelschlag eines
Schmetterlings zum rechtzeitigen Zeitpunkt erzeugt einen Orkan auf der anderen Seite der Welt.

60. Dienstvertrag
Inverse Butterfly Effect
Bei komplexen Umgebungen gibt es aber auch den umgekehrten Fall - es wird sehr viel Aufwand betrieben, um am Ende kommt sehr wenig heraus.

61. Da gab es ein
Netzwerkproblem mit Docker.
Den inverse Butterfly Effect sehen wir vor allem dann, wenn Dinge mal wieder etwas länger dauern. Wenn ich mal ein bisschen Zeit für Facebook braucht, oder meinen
Urlaub buchen möchte, oder vielleicht den neuen Wagen online konfigurieren will, dann sage ich einfach „Da gab es ein Netzwerkproblem mit Docker.“

62. Irgendwie kann ich die Tests nicht
aus der IDE in Vagrant starten.
Otto
Auch ein hervorragender Tipp, glaubwürdig zu erklären, warum ich ein paar Tage nichts geliefert habe: „Ich musste meine IDE erst so konfigurieren, dass die Tests sauber
in der virtuellen Maschine durchlaufen.“

63. Wir mussten für dieses Feature
die Library auf die aktuelle
Alpha upgraden und alles
anpassen. Aber da gab es einen
Bug und wir haben alles
rückgängig gemacht.
Das ist bei uns schon fast ein monatlicher Javascript-Klassiker. JavaScript, da, wo man die Library alle 2 Monate upgraden muss. Und wo es immer Bugs gibt.

64. Und natürlich die agile Variante. Beim Refactoring merkt man, dass man eigentlich noch mehr Refactoren sollte, weil das auch nicht schön ist. Und während man das
refactored merkt man, dass man eigentlich noch mehr Refactoren sollte, weil das auch nicht schön ist. Und während man das refactored merkt man, dass man
eigentlich noch mehr Refactoren sollte, weil das auch nicht schön ist.

65. Man kann
komplexe Arbeit
nicht kontrollieren.
Man kann komplexe Arbeit nicht kontrollieren. Als Auftragnehmer ist es in einem Dienstvertrag einfach, mehr Arbeit zu verursachen als sinnvoll ist - und das ist für den
Auftraggeber praktisch nicht feststell- und nachvollziehbar.

66. Die deutschen Vertragstypen
taugen nicht für
komplexe IT-Projekte.
Fazit: eigentlich unterstützen unsere grossen Vertragstypen keine komplexen Projekte. Jura und Verträge kommen aus dem komplizierten Quadranten, und sie versuchen
Problem zu lösen, die im komplexen Quadranten passieren.

67. Komplex Kompliziert
Chaotisch Offensichtlich
Verwirrung
Und da kommt der fünfte Quadrant, den ich vorhin in Cynefin unterschlagen habe. Wenn ich nicht weiß, in welchem Quadranten ich mich befinde - oder
wenn ich es zwar denke zu wissen, aber meine Welt sich anders verhält - dann bin in Disorder, und die Resultate meiner Methoden decken sich nicht mit
dem, was ich eigentlich erreichen wollte.
Und was machen wir ITler, wenn ein komplexes System nicht das macht, was wir von ihm wollen?

68. Hacken!
Genau, wir setzen unsere Skimasken auf, nehmen unseren Hammer und hacken es.

69. Agile Verträge
Oxymoron (ὀξύμωρος):
rhetorische Figur, bei der eine Formulierung aus zwei
gegensätzlichen, einander widersprechenden oder sich
gegenseitig ausschließenden Begriffen gebildet wird.
Den Versuch Verträge auf Komplexität zu hacken nennt man „agile Verträge“. Analog zur Gnu Public License, bei denen ein Lizenzvertrag sich selbst aushebelt hebeln sie
den vordefinierten Umfang aus, den ein normaler Werkvertrag enthält - oder hacken die Unverbindlichkeit des normalen Dienstvertrages.

70. Dienstvertrag
für Erwachsene
Klassischer Dienstvertrag, aber ...
- der Kunde kann Sprintbezahlung verweigern
- ohne Angabe von Gründen
- nach dem zweiten Mal können wir kündigen
'
Und so hackt man den Dienstvertrag, bei dem der Dienstleister normalerweise nur dafür bezahlt wird, Zeit mit einer Aufgabe zu verbringen.

71. Opportunistischer Exploit
Am Projektende
nicht bezahlen.
Aber natürlich kann man das auch ausnutzen, als Auftraggeber kann ich bei diesem Vertrag einfach am Projektende auf die Bezahlung verzichten.

72. „Money for Nothing and
Your Change for free“
Basis: Standard-Festpreis-Werksvertrag +
Dienstvertrag für Änderungen
Dann gibt's Money for Nothing and Change for Free als Variante für den Werksvertrag. Da werden zunächst alle Sachen geschätzt und mit gutem Buffer
bepreist. Und dann beginnt man zu arbeiten, und arbeitet strict nach Businessvalue zu Aufwand priorisiert.

73. „Money for Nothing and
Your Change for free“
Und jetzt kommen wir zum ersten spannenden Teil: Change for Free. Der Kunde kann neue Features einführen, und im Gegenzug weniger wichtige
Features herauswerfen - vorrausgesetzt, beide Seiten stimmen in der gemeinsamen Bewertung überein.

74. „Money for Nothing and
Your Change for free“
Der zweite Teil, Money for Nothing, und der ist ein echter Mindbender für klassische ITler: Der Auftraggeber kann jederzeit abbrechen, wenn der
Geschäftswert der nächsten Anforderung die Erstellungskosten unterschreitet - und es sich für ihn also nicht mehr lohnt. In diesem Fall bekommt der
Auftragnehmer 20% des Restbudgets, und der Auftraggeber spart 80% der Kosten ein.

75. Variante: Fixed Profit
Es wird ein fixer Gewinn für das
Projekt vereinbart, bezahlt und
nach Selbstkosten gearbeitet.
Die nächste ist Fixed Profit - ich bepreise nach Festpreis, und zerlege meine Berechnung dann in Gewinnanteil und Kosten. Der Gewinnanteil ist fix. Der Kostenanteil
flexibel, aber eben nur zu Selbstkosten.

76. Variante: Fixed Profit
Resultat: beide Parteien profitieren
von einer frühen Fertigstellung.
Beide Parteien sind hier incentiviert, das Projekt möglichst schnell fertig zu bekommen.

77. Opportunistischer Exploit
• Dienstleister optimiert nach
Auslastung.
• Auftraggeber will Budget behalten
und alles Geld aufbrauchen.
Und wie immer gibt es auch hier Exploits. Als Dienstleister habe ich die Leute lieber in Selbstkosten als ohne Auftrag, und als Auftraggeber will ich das Budget möglichst
überziehen, damit ich im nächsten Jahr mehr bekomme. Und als Auftragnehmer kann ich auch hier Qualität minimieren, und bei den Folgeaufträgen dann deutlich
grösser werden - weil es ja auch tatsächlich deutlich länger dauert, mit der fiesen Qualität, die ich jetzt habe.

78. Kein Vertrag ohne Risiko?
Warum gib es überhaupt Verträge, wenn sie ihr Kernziel, die Vermeidung von Risiko, auch nicht annähernd treffen.

79. Unvollständige
Verträge
Die Juristen sind natürlich keine Idioten, und deshalb kennen die das Problem. Die nennen das unvollständige Verträge.

80. Unvollständige Verträge
• implizit
• weitestgehend informell
• eingeschränkt rechtsverbindlich
• sehr flexibel
• Vertragstreue kaum erzwingbar.
https://de.wikipedia.org/wiki/Unvollständiger_Vertrag
Das sind die Eigenschaften von unvollständigen Verträgen:

81. „Dienst nach Vorschrift.“
Arbeitsverträge sind
unvollständige Verträge.
Arbeitsverträge sind unvollständige Verträge. Deshalb kann man Leute verklagen, die sich ganz genau an diesen Vertrag halten. Und genau deshalb ist Dienst nach
Vorschrift strafbar.

82. Unvollständige Verträge
• implizit
• weitestgehend informell
• eingeschränkt rechtsverbindlich
• sehr flexibel
• Vertragstreue kaum erzwingbar.
Smells like
IT spirit.
Mal ehrlich, für mich hört sich diese Liste _sehr_ nach IT an. Das ist quasi mein zuhause.

83. Wo ist die Lösung?
Vertrag
Nicht hier
Und wo ist die magische Lösung für die Kooperation, wenn sie nicht im Vertrag zu finden ist?

84. Wo ist die Lösung?
Vertrag
hier.
Offensichtlich ausserhalb des Vertrages.

85. Unvollständige Verträge
•langfristige Zusammenarbeit
•Symmetrische
Informationsverteilung
•Vetrauen / Altruismus
•Investitionen klein halten
Unvollständige Verträge funktionieren, wenn die Anreize zu Opportunismus verringert werden. Das kann man auf ein paar Weisen machen. Die erste ist offensichtlich. Ich
verhindere den kurzfristigen Opportunismus, indem ich länger zusammenarbeite. Einen langfristigen Opportunismus - etwa durch Vendor Lock-in - verhindere ich damit
aber nicht.

86. Informationssymmetrie herstellen
Rituale zur Informationssymmetrie
Also nächster Punkt - Informationssymmetrie herstellen, damit Asymmetrien nicht als Werkzeug zum Exploit genutzt werden können - und Opportunismus von beiden
Seiten schnell erkannt werden kann. Wir machen das, auch in bestehenden Projekten, gerne als Rituale gemeinsam. Zunächst wird Rahmen und Ziel des Projektes, zB
über das Elevator-Pitch-Template, hergestellt.

87. Informationssymmetrie herstellen
Alternativ und zusätzlich wird der Lean Startup Canvas / der Business Model Canvas erstellt.

88. Informationssymmetrie herstellen
Wir definieren die Personas und Ihre Ziele, und machen auf der Basis einen Storymapping-Workshop - ebenfalls auch um das bestehende Projekt zu dokumentieren und
auf ein gemeinsames Verständnis zu bringen.

89. Informationssymmetrie herstellen
Der aktuelle Status wird ebenfalls über Rituale - zB über Sprint Reviews etc - auf einen gemeinsamen Stand gebracht.

90. Informationssymmetrie herstellen
Das gilt auch für Produktion und Featureerfolg.

91. Transparenz!
Vertrauen
Nächster Punkt ist Vertrauen. Das klingt jetzt esoterisch, ist aber tatsächlich ein massgeblicher Punkt, damit unvollständige Verträge funktionieren. Analog zum
Arbeitsvertrag bedingt eine gute Kooperation Vertrauen. Eine einfache Variante zum Herstellen von Vertrauen ist Transparenz von beiden Seiten. Das heisst: geteilte
Meetings, geteilter Chat, Ticketing, Confluence, Monitoring, Tests etc.

92. Transparenz!
Vertrauen
Net
Promoter
Score
Aber nicht nur Objektivität zählt hier, auch subjektives - bei Vertrauen offensichtlich. Wir nutzen dazu gerne den Net Promoter Score. Alle zwei Wochen stellen wir die
Vertrauensfrage in der Form „Auf einer Liste von 1-10, wie sehr würdet Ihr uns weiterempfehlen?“ „Und was müssen wir machen, damit wir einen Punkt besser werden“.
Das wird protokolliert, und auch die Verbesserungsmassnahmen sind nachvollziehbar - man hat also ein arbeitsfähiges Vertrauensthermometer.

93. Ship early &
ship often
Vertrauen
Der Klassiker zum Vertrauensaufbau: Resultate. Wer regelmässig zugesagte Resultate bringt, dem wird vertraut. Das gilt auch wieder in beide Richtungen.

94. Vertrauen
Und dann gibt es natürlich die soziale Variante. Teambuilding ist im Kontext des Arbeitsumfeldes, wo auch unvollständige Verträge stattfinden, gang und gebe. Bei IT-
Verträgen ist das vermutlich eher Golf, es schadet aber nicht, das ebenenübergreifend zu machen.
TODO: für Vortrag in Hamburg. In München unbedingt durch Augustiner austauschen.

95. Aktive Fehlerkultur
Altruistisches Handeln
Vertrauen
Und Investitionen von der eigenen Seite schaffen Vertrauen. Wer Fehler zugibt, wer zugunsten der anderen Partei handelt, der schafft Anreiz, dass die andere Partei sich
auch so verhält.

96. Fallback auf
Tit for Tat
Vertrauen
Ok, natürlich kann man jetzt sagen: ja, schön, in der perfektesten aller Welten vielleicht, Johann. Was passiert denn, wenn das Vertrauen missbraucht wird?
Dann braucht es einen Anreiz, aus dem opportunistischem Verhalten wieder in ein kooperatives zu gehen. Die einfachste Variante ist „Tit for Tat“ - auf opportunistisches
Verhalten ummittelbar auch mit opportunistischem Verhalten reagieren, das explizit machen, und bei kooperativen Verhalten ebenfalls wieder kooperativ Arbeiten.

97. Nicht offensichtlich, aber wahr:
Kleine Cycletime für beide.
Kleine Cycletime
Investitionen reduzieren
Und wie hält man Investitionen klein?
Denkt man nicht, ist aber so: durch kleine Cycletime. Cycletime ist die Zeit von Arbeitsbeginn bis zur Produktivnahme des Arbeitsergebnisses.

98. Investition für Auftraggeber:
Kosten, bevor es Wert schafft.
Investition für den Auftragnehmer:
Kosten, bevor es bezahlt wird.
Cycle-Time: Dauer & Größe dieser Kosten minimieren.
Kleine Cycletime
Investitionen reduzieren
Warum ist das so?
Die Investitionen vom Auftraggeber sind die Kosten die Auftreten bevor er einen Wert daraus schöpfen kann. Die Investitionen des Auftragnehmers sind die Kosten, bevor
er die Erstattung dafür vom Auftragnehmer bekommt.
Wenn ich diese Zeiten kurz bekomme ist die Investition für beide Seiten klein und damit auch mein Risiko.

99. • Schnelle Implementierung
• Continuos Deployment
• Qualität hoch -> wenig Rückläufer
• Schnell in Produktion
• Nutzen in Produktion messen
Kleine Cycletime
Investitionen reduzieren
Wie man Cycletime kleinbekommt wissen wir alle - da gibt es hier auf der CodeTalks vermutlich mehr als genug Vorträge zu.

100. &tldr;
Der Vertrag alleine rettet
bei komplexen Aufgaben nicht.
Kooperation schon.
Fazit: Verträge sind nicht für komplexe Verträge gemacht. Wir können welche machen, die weniger schlimm sind. In jedem Fall können wir bei komplexen Aufgaben aber
aktiv an der Kooperation arbeiten.