Lügen, schlimme Lügen und IT-Verträge

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 Begriﬀ 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. Oﬀensichtlich gibt es da Dinge, die wichtig sind, die man aber mit einem Vertrag nicht in den Griﬀ 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.“ - oﬀensichtlich hat man wenig Einﬂuss 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? Oﬀensichtlich 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. Cyneﬁn Lebensraum, Platz Um an das Problem näher heranzukommen brauche ich mal Cyneﬁn. 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 Cyneﬁn ist ein Sensemaking-Model, also ein Modell das hilft, um Dinge zu verstehen. Gartner: “By 2016, the Cyneﬁn 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 oﬀensichtliche 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 beeinﬂussen 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 Einﬂü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 Einﬂü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 oﬀensichtlich 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 identiﬁzieren 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 Treﬀerquote in Time & Budget im Chaos-Report.

34. ! " # $ % & Workﬂow Engine Supplier Service User Management ERP E-Commerce-Module Web Frontend Das ist auch nicht weiter verwunderlich - denn innerhalb unserer Lösungswelten selbst ﬁndet 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 ﬁnden 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 Deﬁnition 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 Pﬂichtenheft 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 Deﬁnition 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 oﬀensichtlich 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 Graﬁk als mitgeltendes Dokument verwiesen wird, und zu dieser Graﬁk 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 oﬃziellen 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 Schmetterlingseﬀekte. Wer kennt den Schmetterlingseﬀekt? Genau, ein einziger Flügelschlag eines Schmetterlings zum rechtzeitigen Zeitpunkt erzeugt einen Orkan auf der anderen Seite der Welt.

60. Dienstvertrag Inverse Butterﬂy 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 konﬁgurieren, 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 Cyneﬁn unterschlagen habe. Wenn ich nicht weiß, in welchem Quadranten ich mich beﬁnde - 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 vordeﬁnierten 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 Proﬁt Resultat: beide Parteien proﬁtieren 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 ﬁesen 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 treﬀen.

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 ﬂexibel • 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 ﬂexibel • 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 ﬁnden ist?

84. Wo ist die Lösung? Vertrag hier. Oﬀensichtlich 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 oﬀensichtlich. 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 deﬁnieren 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, Conﬂuence, Monitoring, Tests etc.

92. Transparenz! Vertrauen Net Promoter Score Aber nicht nur Objektivität zählt hier, auch subjektives - bei Vertrauen oﬀensichtlich. 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 stattﬁnden, 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 schaﬀen Vertrauen. Wer Fehler zugibt, wer zugunsten der anderen Partei handelt, der schaﬀt 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.