Agile Kooperation über Organisationsgrenzen

Es wird viel darüber geredet, wie sich ein Unternehmen aufstellen muss, wenn es agil arbeiten will. Es werden Hierarchien und Führungsstile über Bord geworfen, da werden Unternehmen reorganisiert, Fehler gefeiert, detaillierte Planungsverfahren und Bonussysteme gekippt, weil sie extrinsisch motivieren. In der Zusammenarbeit über die eigene Unternehmensgrenze hinweg neigt man währenddessen so zu tun als wäre alles beim alten geblieben: die Einkaufsabteilung drückt den Preis, es werden heimliche Buffer eingeplant und Fehler versteckt. Wir sind der Meinung, dass agile Zusammenarbeit anderes braucht - und stellen unsere Vorschläge dazu vor.

Transcript

1. Agile Kooperation über Organisations- grenzen hinweg Wir wissen inzwischen viel darüber, wie ich in der Firma agil arbeite. Wie Führung in agilen Umgebungen funktioniert. Viele Dinge haben sich geändert. Aber seltsamerweise hat sich wenig geändert, wenn man über die Grenze des eigenen Unternehmens hinausschaut.
2. „Fehlerkultur mit dem Dienstleister“ Um mal ein Beispiel zu nennen: Wer Agilität im Unternehmen hat redet auch immer über Fehlerkultur. Fehler sollen gefeiert werden, Fail fast and cheap, fail to learn. Aber wie sieht das aus, wenn man über die Abteilungs- oder Unternehmensgrenze hinausgeht? Wenn ich mit einer internen Abteilung rede, wenn ich den internen Dienstleister beauftrage?
3. „Soll ich den Hoster für die Downtime feiern?“ Soll ich jetzt den Hoster dafür feiern, wenn wir der Shop mitten im Weihnachtsgeschäft 3 Tage offline ist, weil das bestimmt eine hervorragende Gelegenheit für Learnings ist? Also: wen die Antwort auf diese Frage interessiert, der ist herzlich eingeladen, den Rest des Talks auch zu hören :-)
4. Hallo, ich bin Johann, von der Mayflower GmbH. „Chief Tailwind Officer“ Also: Hallo, ich bin Johann, Gründer und Geschäftsführer bei der Mayflower GmbH. Wir haben hier einen Stand, für Rückfragen bin ich also erreichbar. Mayflower ist ein schlimm agiler IT-Dienstleister in Berlin, München und Würzburg. Ich nenne mich „Chief Tailwind Officer“, weil wir in den vielen Jahren Agilität - wir arbeiten seit 2005 agil - gemerkt habe, dass wir einen klassischen CTO nicht mehr brauchen. Aber Rückenwind.
5. 1992 Wer kennt die beiden jungen Herren oben noch, die - tatsächlich - ihre Hosen verkehrt herum tragen? Das ist 1992 gewesen, da waren sie als „Kriss Kross“ mit „Jump“ mehrere Monate auf Platz 1 der Charts. Und ich habe meinen ersten Job in der IT bekommen. ***************
6. Arbeitsvertrag Und ich habe meinen ersten Arbeitsvertrag bekommen. Das war noch während meines Studiums, aber kontinuierliche 20 Stunden die Woche, das heisst: ein normaler Arbeitsvertrag, und bei dem blieb ich auch mehrere Jahre.
7. Bitte mache A, dann B und dann C. Die Firma hatte etwa 30 Mitarbeiter, deshalb gab es da keine Standardprozesse oder Arbeitsanweisugen, sonden nur viele Kollegen, die Ihren Job gemacht haben. Und weil ich meinen ja noch nicht kannte, bekam ich von meinem Teamleiter haarklein erklärt, was ich zu tun hatte.
8. Ich brauche D. Und zwar morgen. Nachdem ich das eine Weile gemacht hatte wusste ich wie es geht, und mir wurde nicht mehr gesagt, welcher Schritt in welcher Reihenfolge zu tun war - sondern was das Ergebnis sein sollte.
9. Wir brauchen Ende des Quartals folgendes: Und nach einer Weile kam ich auch da an, wo die meisten Wissensarbeiter landen. Mir wurde erzählt was das Ziel ist, und wie und was ich in dem Quartal gemacht habe um das Ziel zu erreichen - das war mir selbst, in Absprachen mit den anderen Beteiligten, überlassen.
10. Arbeitsvertrag? Den Arbeitsvertrag habe ich mir tatsächlich nie angesehen. Und ich vermute, dass er so aussieht wie die Arbeitsverträge, die meine Kollegen heute bei uns abschliessen: bis auf wenige Worte, die die ungefähre Himmelsrichtung vorgeben handelt es sich um rechtlich erforderliche Rahmenbedingungen. Die eigentliche Klärung der Arbeit findet während der Arbeit statt, nicht mit dem Arbeitsvertrag.
11. Unvollständige Verträge • implizit • weitestgehend informell • eingeschränkt rechtsverbindlich • sehr flexibel • Vertragstreue kaum erzwingbar. https://de.wikipedia.org/wiki/Unvollständiger_Vertrag Das liegt daran, dass ein Arbeitsvertrag ein unvollständiger Vertrag ist, also ein Vertrag, der sich wenig dazu äussert, was wer liefert, was wer macht, und woran man den Erfolg feststellt. Die meisten Dinge ergeben sich erst implizit aus ihm, die Rahmenparameter dazu sind nicht formell geklärt, er ist schwierig rechtlich durchzusetzen. Was genau passiert ist flexibel - und muss es auch sein, sonst wären die 3 Kooperationsformen, die ich erlebt habe, gar nicht möglich gewesen. Und die Vertragstreue ist schwer erzwingbar.
12. Dienst nach Vorschrift • Dienst nach Vorschrift bedeutet, dass Arbeitnehmer sämtliche Arbeitsanweisungen und Dienstvorschriften peinlich genau nehmen .. um hierdurch eine Störung des Arbeitsablaufes zu verursachen … https://de.wikipedia.org/wiki/Dienst_nach_Vorschrift Wäre die Vertragstreue zum Arbeitsvertrag, zu den Dienstvorschriften und den Arbeitsanweisungen vollständig, dann würde „Dienst nach Vorschrift“ nach einer guten Sache klingen. Das klingt es aber nicht.
13. Dienst nach Vorschrift Streik Verboten In vielen Ländern, zum Beispiel Österreich, Frankreich und Spanien, wird Dienst nach Vorschrift als Form des Streiks angesehen, zum Beispiel von Fluglotsen. In Deutschland ist das seit dem Fluglotsenurteil von 1973 nicht mehr möglich. In Deutschland ist „Dienst nach Vorschrift“ inzwischen für viele Berufe verboten, und wird sonst als Form der Schlechtleistung bewertet. Rechtlich durchsetzbar ist es in der Praxis also meist nicht.
14. Nicht ausreichend Offensichtlich ist also der Knackpunkt einer guten Kooperation also nicht die vertragliche Gestaltung, sondern andere Faktoren stehen im Vordergrund.
15. 2000 Im Jahr 2000 habe ich dann mit ein paar Freunden die Mayflower GmbH gegründet, und wir bekamen die ersten angestellten. Und was habe ich gemacht?
16. 2000 Ich brauche D. Und zwar morgen. Wir haben natürlich auch damit angefangen, direkte Anweisungen zu erteilen.
17. 2003 Und natürlich haben wir auch unsere Standardprozesse dokumentiert, Arbeitsanweisungen erstellt und viele Dinge dokumentiert. Und uns beschwert, wenn man sich nicht daran gehalten hat.
18. Quartalsweise Zielvereinbarungen & Bonus Management by Objectives Und natürlich haben wir ebenfalls Management by Objectives mit Zielvereinbarungen und Bonus bei 120%iger Zielerreichung implementiert.
19. Big Design Upfront Und damit unsere Pläne tatsächlich funktionieren haben wir viel Wert auf Planung gelegt, und versucht alles zu durchdenken.
20. 500 Seiten Pflichtenheft, anyone? Big Design Upfront Und beliebig viel Dokumente produziert, um es zum laufen zu bringen.
21. Meanwhile, in Reality https://twitter.com/braddo/status/436532514782707712 In der Praxis liefen unsere Projekte währenddessen immer völlig anders. Egal wieviel wir planten, es kam immer anders.
22. Seltsamerweise hat es immer dann am besten funktioniert, wenn wir - wann immer wir gute Gründe dafür hatten - vom Plan abwichen.
23. Und nicht nur das - sogar die Kunden waren dankbar dafür, dass wir so schnell auf Änderungen reagieren konnten.
24. 2005 Das, was in der 
 Praxis funtioniert, 
 hat einen Namen AGIL! 2005 haben wir dann endlich mitbekommen, dass dieses Vorgehen keineswegs Anarchie war, sondern einen richtigen Namen hatte - nämlich agil.
25. 2005 SCRUM eXtreme Programming Crystal Clear AGIL! Wir haben damals auf das Methodenset gesetzt, das vor 13 Jahren aktuell war - Scrum, eXtreme Programming und Crystal Clear.
26. Arbeitsorganisation WAS WIE Das hatte unmittelbare Folgen für die Arbeitsorganisation. Während vorher Arbeitsweise und Arbeitsziel Sache der Führungsfunktionen war wurden die jetzt umverteilt. Während vorher das WAS und WIE über die Führungsfunktion an die Kollegen ging, …
27. Explizite Änderungen WAS WIE … kümmert sich heute das Team beim Wie bzw der Product Owner beim WAS darum
28. Explizite Änderungen VISION Empower! Und auch die Aufgabe der Führungskraft ändert sich - sie vertritt jetzt die Vision, an der sich der PO und das Team orientiert, und übergibt die Macht an das Team - es wird empowered.
29. Implizit: Fehlerkultur FEHLER GEHÖREN GEAHNDET!! Fehler sind zum Lernen notwendig! Aber es gibt nicht nur explizite Änderungen - auch implizit hat agil einiges geändert. Einer der Punkte ist die Fehlerkultur. Es ist erwartetes Verhalten, dass nicht alle Dinge so klappen wie man sie geplant hat. Agil steht solchen Fehlern positiv gegenüber - sie werden als Learning gesehen. Während vorher Fehler vorher als vermeidbar galten rechnet man nun mit ihnen, und freut sich darüber, dass man sie bemerkt hat.
30. Implizit: Fehlerkultur Fail Fast & Learn Fast Kleine Inkremente Schnelles Feedback Adaption Und wie gehe ich mit Fehlern um, wenn ich ehedem weiß, dass sie passieren werden? Ich versuche, den Schaden klein zu halten und schnell zu verstehen, was das richtige statt dessen wäre. Schnelles Feedback in meinen Iterationen, schnelles Validieren vor dem Kunden, billige Spikes in der Entwicklung - alles Maßnahmen, um schnell aus meinen Fehlern lernen zu können.
31. Quartalsweise Zielvereinbarungen & Bonus Management by Objectives Und weil der Fokus vom Planen zum Lernen gewandert ist mussten wir auch die wenige Jahre zuvor eingeführten Management By Objectives-Zielvereinbarungen wieder abschaffen.
32. 500 Seiten Pflichtenheft, Big Design Upfront Und die grossen Lasten- und Pflichtenheft wurden durch Elevator Pitches, Storymaps, Deep Backlogs und kontinuierliche Kooperation ersetzt.
33. Und mit Kunden & Geschäfts- partnern? Das haben wir - wie beschrieben - in 2005 und den folgenden Jahren gemacht. Für alle internen Prozesse war das Gold wert, aber welche Wirkung hatte das da, wo wir mit Partnern arbeiten? Ich kann Ihnen garantieren: 2005 hat noch kein Konzern der Welt den Dienstleister nach agiler Arbeit gefragt.
34. Wo es vorher 
 gut funktionierte wurde es noch besser. Trotzdem: dort, wo es vorher gut funktionierte, da funktionierte es sogar noch besser als vorher. Dort haben agile Methoden einen Rahmen geboten für das, was die Zusammenarbeit braucht. Aber: Agil selbst war nicht der Feenstaub, auf den es ankam …
35. Wo es vorher 
 nicht gut funktionierte blieb es gleich. … denn an anderer Stelle hat es nicht funktioniert, obwohl wir die gleichen Methoden eingesetzt haben.
36. Kooperationen mit der „alten Kultur“: Kontrolle Steuerung Risikovermeidung Fehlervermeidung Das war insbesondere dort der Fall, wo die Strategien des Kooperationspartners klassisch aufgestellt waren, also vor allem versucht haben über Kontrolle und Steuerung Gewinnen zu maximieren und Risiken und Fehler zu vermeiden. Das ergibt alles Sinn, weil natürlich sind das die Ziele des Unternehmens.
37. Werkvertrag • Detaillierte Aufgabenstellung • Fertigstellungstermin • Kosten • Gewährleistungen • Haftung … Und was macht man, wenn man das Risiko über Kontrolle und Steuerung reduzieren will? Man legt sich vertraglich fest. Mit einem Werkvertrag, weil der einem zusichert, was ich zu welchem Zeitpunkt bekommen, und wie teuer das ist.
38. Agiler Werkvertrag • Deep Backlog über Storymap • Grössenordnung über Estimation • Ausdefinieren im Refinement • Neue & geänderte Stories im Sprint Planning Und weil wir jetzt agil waren, haben wir agil im Werksvertrag gearbeitet - das heißt: wir haben kein Lasterhaft / Pflichtenheft mehr gemacht, sondern einen Storymapping- Workshop. Das ganze wurde dann über Magic Estimation geschätzt und auf der Basis bepreist. Aus den ganzen Storycards wurden dann User-Stories im Backlog, und der wurde Sprint für Sprint ausdefiniert. Und natürlich kann man Stories tauschen, solange sie noch nicht im Sprint sind, wenn man gleichkrosse Stories dafür aus dem Backlog wirft.
39. Agiler Werkvertrag In der Praxis hat das auch gut ausgesehen - denn wir konnten die Änderungen einfach so durchbringen, und war nicht mehr auf Konstrukte wie Change Request Boards und ähnliches angewiesen.
40. … ist ein unvollständiger Vertrag • implizit • weitestgehend informell • eingeschränkt rechtsverbindlich • sehr flexibel • Vertragstreue kaum erzwingbar. https://de.wikipedia.org/wiki/Unvollständiger_Vertrag • „Detaillierte Aufgabenstellung“ geht nicht. Aber: damit haben wir den Werksvertrag zu einem unvollständigen Vertrag gemacht. Das ist auch klar - denn wir wollen ja tatsächlich keine detaillierte Aufgabenstellung, weil wir schon wissen, dass die Planung nicht im Detail erfolgreich sein kann.
41. Unvollständiger Werksvertrag • Viele vorvertragliche Themen sind jetzt nachvertraglich. https://de.wikipedia.org/wiki/Unvollständiger_Vertrag • Das erzeugt Handlungs- und Entscheidungsfreiräume im Verlauf Und damit laufen wir in die Folgen von unvollständigen Verträgen - wie es oben beim Arbeitsvertrag schon der Fall ist. Viele Themen, die normalerweise vorvertraglich geregelt sind (der Jurist nennt das ex ante) müssen jetzt im Verlauf (das nennt er ex post) geklärt werden. Und das erzeugt Handlungs- und Entscheidungspielräume für beide Parteien. Klar, denn es ist ja nicht festgelegt, wie sie sich verhalten müssen, das ist das unvollständige Element des Vertrags.
42. As a <user role> I want <goal> so that <benefit> „A user story is a promise to have a future conversation; it is not meant to document every aspect of the work, as you might in a series of traditional requirements statements.” Hier haben wir ein klassisches Beispiel für einen Handlungs- und Gestaltungsspielraum. Es gibt keine vertragliche Festlegung darüber, wie die User-Story genau auszusehen hat. Und das macht auch solche Dinge wie Teilabnahmen so schwierig - ich habe gar nicht die Details, an denen man - wie im alten Werksvertrag beschrieben - auf einer gemeinsamen Basis abnehmen könnte, sondern hier besteht noch viel Freiraum.
43. Diese Freiräume erzeugen
 „Moral Hazards“ Bei der Gestaltung der Freiräume kann man Informationsasymmetrien ausnutzen. Opportunistisches Verhalten auf Kosten der anderen Partei. Und diese Freiräume erzeugen Moral Hazards, auf deutsch „moralische Risiken“ oder „moralische Versuchungen“. Weil ich etwas nicht definiert habe, kann jede beteiligte Partei versuchen, diese Lücke zum eigenen Vorteil zu nutzen, indem sie Informationen zurückhält oder nicht darlegt, wie ein Zustand zustande kam.
44. Diese Freiräume erzeugen
 „Moral Hazards“ „Dienst nach Vorschrift“ 
 ist ein Moral Hazard bei Arbeitsverträgen. Den Dienst nach Vorschrift, den wir vorhin bei den Arbeitsverträgen hatten - ist ein Moral Hazard. Weil der Kollege weiß, welche Dinge er jenseits der Richtlinien, der Arbeitsanweisungen etc tun muss, damit seine Aufgabe gut erledigt werden kann hält er diese zurück - und kann den Arbeitgeber so zwingen in seinem Sinne zu handeln.
45. Moral Hazard durch Informationsasymmetrie As a <user> I want <register> so that <i can use the app> „Natürlich meinten wir mit Registration auch über Facebook, Google, Twitter. Und WCAG- Konform. Wir kennen diese Moral Hazards auch aus unserer Welt: Da kommt uns eine User-Story entgegen, die wir schon 100 Mal gesehen und implementiert haben - ein Nutzer soll sich registrieren. In unserer Schätzung haben wir uns also daran gehalten, vielleicht mit etwas Buffer. Es wird aber viel aufwändiger, denn der Auftraggeber braucht eine viel anspruchsvollerer Lösung, die unter normalen Umständen mehr gekostet hätte.
46. Moral Hazard durch Informationsasymmetrie As a <user> I want <register> so that <i can use the app> „Schätz das mal auf 20 SP. Ich habe das zwar schon auf Halde, aber dann haben wir mehr Buffer.“ Diese Asymmetrie gibt es natürlich auch in der anderen Richtung.
47. Moral Hazard durch Informationsasymmetrie As a <user> I want <register> so that <i can use the app> „Eigentlich müsste das alles refaktoriert werden, Abe da fehlt uns die Zeit..“ Diese Asymmetrie gibt es natürlich auch in der anderen Richtung.
48. Zurückhalten von Informationen, die Risiko oder Schaden auf der eigenen Seite bewirken können. Moral Hazard durch Informationsasymmetrie Und ich incentiviere auf die Zurückhaltung von Informationen, die zu meinem Nachteil sein könnten. Der Klassiker ist „eigentlich müsste ich das jetzt mal refaktorieren, wo ich schon mal dran bin.“. Und statt Boyscout-Rule wird es in den Refactoring-Backlog genommen, wenn man das Glück hat, auf so etwas zurückgreifen zu können.
49. Moral Hazard durch Informationsasymmetrie Dieses Problem ist in praktisch allen agilen Festpreisverträgen zu finden. Und weil dieses Problem der Tatsache geschuldet ist, dass es sich um einen unvollständigen Vertrag handelt lässt es sich auch nicht wirklich über vertragliche Parameter umgehen. Das scheint also nicht der Feenstaub zu sein, den ich brauche.
50. Agile IT-Verträge sind 
 gewollt unvollständig. Wie stelle ich trotzdem 
 eine gute Kooperation her? Ein agiler Vertrag ist durch die Flexibilität immer ein unvollständiger Vertrag, der - aus guten Gründen - viele Entscheidungen auf einen späteren Zeitpunkt vertagt. Was ist also die magische Zutat für gut funktionierende Kooperationen?
51. Prinzipal Agent Theorie https://de.wikipedia.org/wiki/Prinzipal-Agent-Theorie Glücklicherweise sind wir aber nicht die ersten, die sich mit diesem Problem auseinander setzen. Da gibt es die Prinzipal-Agenten-Theorie, die sich mit diesem Dilemma auseinander setzt, ein Auftraggeber, ein Auftragnehmer, und jeder versucht seinen Nutzen zu maximieren, indem er asymmetrische Informationen ausnutzen. Zugegebenermassen ist die Weltsicht hinter der Theorie etwas pessimistisch - das heisst aber nicht, dass die resultierenden Empfehlungen uns nicht nutzen.
52. Was können wir lernen? … ein paar alte Bekannte, aber auch ein paar neue Gesichter. Und einige der Empfehlungen, die aus dieser Theorie kommen kennen wir schon gut, andere sind zwar neu - decken sich aber mit unseren Erfahrungen. Aber schauen wir uns das mal konkret an.
53. 1. Kulturellen Fit prüfen Werte Ziele Präferenzen Kompetenzen Kein agiles Werkzeug, aber es deckt sich mit unseren Erfahrungen. Eine ähnliche Unternehmenskultur erleichtert die Arbeit sehr. Wenn Werte, Ziele und Präferenzen fällt das gegenseitige Verständnis leichter. Und das erlaubt gemeinsames Lernen
54. 2. Informationssymmetrie herstellen Wenn Informationsasymmetrie schadet hilft es, sie zu reduzieren. Dazu gehört, den Businesscase des Projektes zu verstehen. Warum funktioniert es, was sind die Annahmen, was ist der kritische Pfad. Das heißt zu Beginn einer Zusammenarbeit, dass man gemeinsam durch den das Businessmodel geht, es kritisch hinterfragt und versteht, wie es funktionieren soll. Das gegenseitige Wissen macht es nicht nur einfacher, lokale Entscheidungen im Sinne des Produktes zu treffen. Es fällt auch eher auf, wenn man sich in eine andere Richtung bewegt - für beide Seiten.
55. 2. Informationssymmetrie herstellen Wir nutzen ebenfalls gerne Story-Mapping, Design-Thinking oder Event Storming Workshops - selbst dann, wenn der Backlog oder ein Teil des Produktes schon existiert. Denn die Aufgabe an dieser Stelle ist ja nicht das erstellen derselben, sondern das Herstellen von Informationsymmetrie.
56. 2. Informationssymmetrie herstellen Ein gemeinsamer Story- Mapping-Workshop lohnt sich auch dann, wenn der Backlog schon existiert. Und das ist ein ganz spannendes Ergebnis: ein gemeinsamer Story-Mapping-Workshop lohnt sich auch dann, wenn der Backlog schon existiert. Die Informationsymmetrie hat einen Wert für sich, die den gemeinsamen Workshop schon rechtfertig.
57. 2. Informationssymmetrie herstellen Softwaredesign & Qualität Architekturentscheidungen Das gilt natürlich auch in der anderen Richtung. Wenn Architekturentscheidungen getroffen werden werden sie gemeinsam in Workshops erarbeitet. Der Status von Design und Codequalität ist immer transparent, zum Beispiel über CodeClimate oder Codacy.
58. Transparenz im Vorgehen 3. Informationssymmetrie erhalten Zur Transparenz in beiden Richtungen gehört natürlich auch das Tooling. Welche Tickets gibt es, was wird im Chat besprochen, welche Commits passierten. Hier sieht man auch schnell, warum der kulturelle Fit so wichtig ist - wenn hier eine Partei den Entwickler feiert, der die meisten Zeilen beiträgt, und die andere denjenigen, der am meisten Zeilen Code entfernt - dann kann das nur zu Missverständnissen führen.
59. 3. Informationssymmetrie erhalten Aber nicht nur die Entwickler ziehen blank, das gleiche gilt auch für die Informationen auf Kundenseite. Wurden die Features wirklich so angenommen, wie wir es geplant hatten? Hat sich die Conversion geändert? Kostet das Feature mehr als es einbringt, oder ist es eher umgekehrt?
60. 3. Informationssymmetrie erhalten Und natürlich helfen alle gemeinsamen Alignment-Rituale, von Refinement, Planning, Review über Retrospektive. Das gleiche gilt für das gemeinsame Verständnis von Ziel und Zielerreichung. Wenn es zeitliche Abhängigkeiten nach aussen gibt machen wir ebenfalls gerne noch ein gemeinsames Confidence-Rating, wie sehr wir glauben, dass wir unsere Zeitlinien schaffen. Dieses Explizit-Machen der eigenen Einschätzung trägt ebenfalls zur Informationssymmetrie bei und macht das Verstecken von relevanten Informationen schwieriger.
61. 3. Informationssymmetrie erhalten Rituale für Kontinuierliche Auftragsklärung In agilen Umgebungen ändern sich aber in der Regel nicht nur die Inhalte der User-Stories. Wenn das eintreffende Kundenfeedback zeigt, dass einige Basisannahmen falsch waren, dann ergibt es keinen Sinn die darauf basierende Strategie weiter zu verfolgen. Es braucht also nicht nur ein Ritual für die Klärung im kleinen, es braucht auch ein Ritual für die Klärung im grösseren Kontext.
62. Kleine Leadtime 4. Investitionsrisiken 
 reduzieren Kommen wir zu Punkt 4: Investitionsrisiken reduzieren. Das wirkt sich zum Beispiel bei Features aus - um so schneller ich das Ergebnisse aus einer Implementierung sehe, um so schneller ist das Investitionsrisiko wieder eingefangen.
63. 4. Investitionsrisiken 
 reduzieren Im Dienstvertrag: 
 Kurze Kündigungsfrist für den Auftraggeber Das gilt aber auch für die Makroebene: Wenn ich einen Dienstvertrag habe - und dort liegt das grössere Investitionsrisiko ganz offensichtlich beim Auftraggeber - dann reduziere ich das Risiko, indem ich einseitig kurze Kündigungsfristen anbiete.
64. 5. Anreizsysteme für 
 Kooperation Was muss ich tun, um vom konkurrierenden zum gegenseitigen und gemeinsamen Nutzen zu kommen? Der nächste Punkt ist ein Anreiz für freundliche Kooperation an gemeinsamen Zielen. Unser Werkzeug dafür heisst „Cooperation Feedback Questionnaire“, kurz CFQ. Etwa alle 4 Wochen setzen wir uns zusammen und schauen nicht auf das Produkt und die Entwicklung, sondern direkt auf die Kooperation.
65. 5. Anreizsysteme für 
 Kooperation „Cooperation Feedback Questionnaire“ Alle 4 Wochen ein gemeinsamer dokumentierter Kooperationsreview: Der nächste Punkt ist ein Anreiz für freundliche Kooperation an gemeinsamen Zielen. Unser Werkzeug dafür heisst „Cooperation Feedback Questionnaire“, kurz CFQ. Etwa alle 4 Wochen setzen wir uns zusammen und schauen nicht auf das Produkt und die Entwicklung, sondern direkt auf die Kooperation.
66. „Cooperation Feedback Questionnaire“ Net Promoter Score Gegenseitig: Wie gut kooperieren wir? Wie gut verstehen wir den anderen? Wie gut trägt er andere zum 
 Fehler erkennen, zum Lernen und Verbessern bei? Und da wird es konkret, und wir bitten explizit um Tacheles. Zunächst fragen wir ganz konkret, was das wichtigste zu tun ist, welche Kompetenzen wir aufbauen sollten, und natürlich den Net Promoter Score. Wer kennt den? Danach wird es aber eigentlich spannend - da wir nämlich gegenseitig gepokert: Wie gut kooperiert die jeweils andere Seite? Wie gut fühlt man sich selbst verstanden? Wie gut hilft mir die andere Seite, meine Fehler zu erkennen, etwas zu Lernen und zu verbessern?
67. 5. Anreizsysteme für 
 Kooperation In agiler Kooperation profitieren beide Vertragspartner von gegenseitigem altruistischem Verhalten. Der nächste Punkt ist ein Anreiz für freundliche Kooperation an gemeinsamen Zielen. Unser Werkzeug dafür heisst „Cooperation Feedback Questionnaire“, kurz CFQ. Etwa alle 4 Wochen setzen wir uns zusammen und schauen nicht auf das Produkt und die Entwicklung, sondern direkt auf die Kooperation.
68. Gute Kooperation 
 in 5 Schritten kulturellen Fit prüfen Informationssymmetrie herstellen Informationssymmetrie erhalten Investitionsrisiken reduzieren Anreizsysteme für Kooperation Also, das ganze noch mal zusammen.
69. „Soll ich den Hoster für die Downtime feiern?“ Also. soll ich den Hoster für die Downtime feiern? Wenn ich ihn gut verstehe, wenn er mich gut versteht, wenn ich gut mit ihm kooperiere und weiß, wie er arbeitet. Wenn ich weiß, dass er durch Rollback, durch Canary Deploys, durch Backup von Storage und Datacenter mein Investitionsrisiko vernünftig abgebildet hat - dann ist der Fehler vermutlich nicht vermeidbar gewesen. Und so sehr es mich schmerzt, dann werden wir ein gemeinsames Post Mortem machen und den Fehler, der dazu geführt hat, feiern.
70. &tldl; Kooperation über Organisationsgrenzen braucht mehr als nur Vertrag und Agilität. Wer Praxiserfahrungen möchte - einfach melden :-) 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.