Klassisch: Low Trust, Agil: High Trust. Das spiegelt sich in den heute üblichen Verträgen wieder. Sie sind von Misstrauen geprägt. Das führt zu Abgrenzung, Zurückhalten von Informationen und schlechtem Risikomanagement. Es gibt Vertrauen in Intentionen und in Fähigkeiten. Was Verträgen zugrunde liegt, ist Angst. Angst, dass die der Vertragspartner falsche Intentionen verfolgt oder die notwendigen Fähigkeiten nicht hat. Auch bei vertrauensbasierten Verträgen müssen wir den Ängsten Rechnung tragen. Allerdings begegnen wir diesen Ängsten mit Kooperation statt Abgrenzung. Durch Kooperation und häufige Face-2-Face-Kontakte wächst Vertrauen. Vertrauen selbst reduziert soziale Komplexität und erlaubt damit agilen Verfahren überhaupt erst, sich richtig zu entfalten. Über Feedback-Schleifen kann sichergestellt werden, dass Vertrauen nicht missbraucht wird.

1. Vertrauen als Vertragsbasis
Ist Vertrauen wirklich der Anfang von allem?
Stefan Roock
stefan.roock@it-agile.de
Twitter: @StefanRoock

2. Habe ich was zu sagen?
Festpreisprojekte
(30+ Entwickler)
Vertrauen als Basis der
Unternehmensorganisation
Keine
Festpreise
mehr
Das Richtige zu
tun ist wichtiger
als Geld

3. 1. Agil = High Trust,
klassisch: Misstrauen
4. Aufbau von
Vertrauen
Dieser Vortrag
3. Vorteile von
Vertrauen
2. Misstrauen als
Vertragsbasis
5. Kontrolle?
6. Veträge und
Vertrauen

4. Auftraggeber Anwender Dienstleister Entwickler
sieht
Auftraggeber
als
Anwender
Dienstleister
Entwickler

5. Some companies manage by rules. Some by hierarchies.
IBM manages by its values.
IBMers value:
Dedication to every client's success
Innovation that matters, for our company and for the world
Trust and personal responsibility in all relationships
Vertrauen als
Unternehmenswert
http://www-03.ibm.com/employment/our_values.html

6. Vertrauen?NaKlar?

7. klassisch = Low Trust
Agil = High Trust
Meine Behauptung

8. Problemlösung klassisch
Problem
erkennen
mehr
Vorgaben
Einhaltung der
Vorgaben
sicherstellen
Experte analysiert
das Problem

9. Problemlösung agil
Unzufriedenheit
formulieren
Kooperation im
Problembereich
Gemeinsames
Lernen
Optionen
schaffen
Situation
verbessern
„Zusammenarbeit
mit dem Kunden
wichtiger als
Vertragsverhandlungen“

10. Unzufriedenheit
formulieren
Im Problembereich
kooperieren
Gemeinsam
lernen
Optionen
schaffen
Situation
verbessern
Problem
erkennen
mehr
Vorgaben
Einhaltung
der Vorgaben
sicherstellen
Experte analysiert
das Problem
Agil = High Trust
klassisch = Low Trust

11. Ergebnis eines
Low-Trust
-Ansatzes

12. Klassische Verträge
Ängste
• Das Vorhaben wird zu teuer.
• Vertragspartner schadet mir, um seinen
eigenen Nutzen zu optimieren.
• Vertragspartner hat die notwendigen
Fähigkeiten nicht.
Vertrauen in
Intention?
Vertrauen in
Fähigkeiten?
Vertrag
• Möglichst genau festlegen,
was zu welchem Preis zu
liefern ist.
Resultat
• Schlechte Qualität
• Zurückhalten von Informationen
• Schlechte Entscheidungen
• Wirtschaftlicher Schaden

13. IEEE Code of Ethics
• … avoid real or perceived conflicts of
interest whenever possible, and to
disclose them to affected parties when
they do exist;
• … be honest and realistic in stating
claims or estimates based on available
data;
These: klassische
Verträge machen es den
Mitarbeitern sehr
schwer, diesem Code of
Ethics zu entsprechen

14. Zwischenergebnis
Angst
Misstrauen
Abgrenzender
Vertrag
Wirtschaftlicher
Schadenloose-loose-
Situation

15. Vertrauen

16. „Vertrauen. Ein Mechanismus der
Reduktion sozialer Komplexität.“

17. „Vertrauen. Ein Mechanismus der
Reduktion sozialer Komplexität.“

18. @somesheep - LeanUX NYC 2015
Trusting creates options
in relationships
TRUST IS AN OUTCOME

19. Der VAST-Zyklus
Verletzlichkeit
Authentische
Verbindung
Die Wahl
haben
Sicherheit /
Offenheit
Vertrauen /
Trust
Quelle: Sahota / Lewitz

20. Aufbau von Vertrauen
• Häufiger Face-2-Face-Kontakt (z.B.
Entwicklung beim Auftraggeber)
• Kleine Commitments machen und die
einhalten (Sprints, Vorprojekt)
• Authentisch sein (z.B. Probleme früh
thematisieren; Projektabbruch empfehlen)
• Transparenz alleine reicht nicht!

21. Zwischenergebnis
Vertrauen muss
wachsen
Vertrauen
erzeugt Optionen
Vertrauen
reduziert
Komplexität

22. „es kommt halt immer auf deine Fressfeinde an.
Vertrauen gut, aber nicht immer sinnvoll,
leider.“ @WolfgangKraus (über Twitter)

23. Und was ist mit
„Vertrauen ist gut, Kontrolle ist besser“?

24. Problem Spezifikation System
Vertrag
Erfolg: Soll=Ist
Viele Verträge regeln das Falsche…
klassische
Denkweise

25. Problem Spezifikation System
Vertrag
Erfolg: Soll=Ist
Erfolg: Wertschöpfung (ROI); agiles Mindset
Viele Verträge regeln das Falsche…
…, weil es schwieriger ist, das Richtige zu regeln.
klassische
Denkweise

26. „Agilität ersetzt
Vertrauen durch Feedback.“
Boris Gloger

27. Weinberg über Ford 1/3
FließrichtungdesFlusses

28. Weinberg über Ford 2/3
FließrichtungdesFlusses
X

29. Weinberg über Ford 3/3
FließrichtungdesFlusses
X
Feedback-Zyklus:
Mein Mist fällt mir selbst auf die Füße.

30. Beispiel: Spesen @ it-agile
Simple Rules
„Jeder bucht seine Reisen so, wie er dies für den
Kunden, sich selbst und it-agile für richtig hält. Nach den
Prinzipien:
• Wir vermeiden Verschwendung.
• Wir leisten guten Service für unsere Kunden
• Wir kompensieren nach steuerlichen Regeln.
• Wir machen unser Reiseverhalten transparent für alle
Kollegen.“

31. Vertragsform: Time & Material
• Dienstleister rechnet nach Aufwand ab.
• Kunde kann nach jedem Sprint die Zusammenarbeit
beenden, wenn er unzufrieden mit der Leistung ist.
Interesse an Leistungssteigerung mitunter nur
einseitig beim Auftraggeber vorhanden.

32. Vertragsform: Garantierte Produktivität
• Dienstleister garantiert Preis je Function Point für
definierten Zeitraum (z.B. 2 Jahre).
Interesse an Leistungssteigerung beim Dienstleister.
Adressiert Sorge des Auftraggebers bzgl. Kostenexplosion.

33. Problem Spezifikation System
Vertrag
Erfolg: Soll=Ist
Erfolg: Wertschöpfung (ROI); agiles Mindset
Viele Verträge regeln das Falsche…
…, weil es schwieriger ist, das Richtige zu regeln.
klassische
Denkweise
Kostenorientierte
Verträge
Wertorientierte
Verträge

34. Kosten / Nutzen?
• Entwicklungskosten sind meist untergeordnet.
• Verzögerungskosten (Cost of Delay) sind meist
relevanter.
• Verzögerungskosten unbekannt? -> Herausfinden!
WSJF = Cost of Delay / Duration
(WSJF: Weighted Shortest Job First)

35. Vertragsform: Buy what you see
• Dienstleister geht jeweils einen Sprint in Vorleistung.
• Bekommt beim Sprint-Review das Produktinkrement
und die Rechnung präsentiert.
• Kunde entscheidet im Sprint-Review, ob er das
Produktinkrement kauft (ob der gelieferte Wert die
Kosten übersteigt).
• Wenn der Kunde das Produktinkrement nicht kauft,
kann der Dienstleister die Zusammenarbeit beenden.
Dienstleister vertraut darauf, dass er wertvolle
Software für den Kunden schaffen kann.

36. Vertragsform: Proviant und Prämie
• Dienstleister bekommt Selbstkosten nach Aufwand
bezahlt.
• Dienstleister bekommt Prämie bei Zielerreichung.
Beide Partner haben ein Interesse daran, das Ziel
möglichst schnell und preisgünstig zu erreichen.

37. Vertragsform: Pay per Use
• Dienstleister entwickelt auf eigene Kosten.
• Dienstleister wird am geschaffenen Nutzen beteiligt
(z.B. Umsatzbeteiligung).
Beide Partner haben ein Interesse daran, den
Nutzen für den Auftraggeber zu optimieren.

38. Zwischenergebnis
Feedback-Zyklen ersetzen
Fremdkontrolle und -steuerung durch
Selbstkontrolle und -steuerung.
Vertrag sollte nicht primär auf einen
Soll-/Ist-Abgleich hinauslaufen,
sondern auf Wertschöpfung.

39. agil = high trust
klassische Verträge: low trust
Vertrauen reduziert soziale Komplexität und
schafft Optionen.
Vertrauen muss wachsen (Face-to-Face,
Commitment, Authentizität)
Klassische Verträge regeln des Falsche
(Soll-Ist-Abgleich statt Wertschöpfung)
Verträge basierend auf Feedback-Loops
können Wertschöpfung adressieren.
Zusammenfassung

40. Vielen Dank für die Aufmerksamkeit
Stefan Roock
stefan.roock@it-agile.de
Twitter: @StefanRoock
Agil auf allen Ebenen