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.
Vertrauen als Vertragsbasis (Agile Contracts 2015, München)
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
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
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
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!
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
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.