vertrauen als vertragsbasis (agile contracts 2015, münchen)
TRANSCRIPT
Vertrauen als Vertragsbasis Ist Vertrauen wirklich der Anfang von allem?
Stefan Roock [email protected] Twitter: @StefanRoock
Habe ich was zu sagen?Festpreisprojekte (30+ Entwickler)
Vertrauen als Basis der Unternehmensorganisation
Keine Festpreise
mehr
Das Richtige zu tun ist wichtiger
als Geld
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
Auftraggeber Anwender Dienstleister Entwicklersieht
Auftraggeber
als
Anwender
Dienstleister
Entwickler
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
Vert
raue
n? N
a Klar
?
klassisch = Low Trust Agil = High Trust
Meine Behauptung
Problemlösung klassischProblem erkennen
mehr Vorgaben
Einhaltung der Vorgaben
sicherstellen
Experte analysiert das Problem
Problemlösung agilUnzufriedenheit
formulieren
Kooperation im Problembereich
Gemeinsames Lernen
Optionen schaffen
Situation verbessern
„Zusammenarbeit mit dem Kunden
wichtiger als Vertragsverhandlungen“
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
Ergebnis eines Low-Trust -Ansatzes
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
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
ZwischenergebnisAngst
Misstrauen
Abgrenzender Vertrag
Wirtschaftlicher Schadenloose-loose-
Situation
Vertrauen
„Vertrauen. Ein Mechanismus der Reduktion sozialer Komplexität.“
„Vertrauen. Ein Mechanismus der Reduktion sozialer Komplexität.“
@somesheep - LeanUX NYC 2015
Trusting creates options in relationships
TRUST IS AN OUTCOME
Der VAST-Zyklus
Verletzlichkeit
Authentische Verbindung
Die Wahl haben
Sicherheit / Offenheit
Vertrauen / Trust
Quelle: Sahota / Lewitz
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!
Zwischenergebnis
Vertrauen muss wachsen
Vertrauen erzeugt Optionen Vertrauen
reduziert Komplexität
„es kommt halt immer auf deine Fressfeinde an. Vertrauen gut, aber nicht immer sinnvoll, leider.“ @WolfgangKraus (über Twitter)
Und was ist mit „Vertrauen ist gut, Kontrolle ist besser“?
Problem Spezifikation System
VertragErfolg: Soll=Ist
Viele Verträge regeln das Falsche…klassische Denkweise
Problem Spezifikation System
VertragErfolg: Soll=Ist
Erfolg: Wertschöpfung (ROI); agiles Mindset
Viele Verträge regeln das Falsche…
…, weil es schwieriger ist, das Richtige zu regeln.
klassische Denkweise
„Agilität ersetzt Vertrauen durch Feedback.“
Boris Gloger
Weinberg über Ford 1/3
Fließr
ichtun
g des
Flus
ses
Weinberg über Ford 2/3
Fließr
ichtun
g des
Flus
ses
X
Weinberg über Ford 3/3
Fließr
ichtun
g des
Flus
ses
X
Feedback-Zyklus: Mein Mist fällt mir selbst auf die Füße.
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.“
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.
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.
Problem Spezifikation System
VertragErfolg: 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
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)
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.
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.
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.
ZwischenergebnisFeedback-Zyklen ersetzen
Fremdkontrolle und -steuerung durch Selbstkontrolle und -steuerung.
Vertrag sollte nicht primär auf einen Soll-/Ist-Abgleich hinauslaufen,
sondern auf Wertschöpfung.
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
