Vertraege in Agilen Projekten

10,800 views

Published on

Agile Werte basieren auf Vertrauen & Kooperation. Welche Vorgehens- und damit Vertragsmodelle sind dabei möglich? In diesen Slides versuche ich der Frage nachzuspüren und stelle dabei verschiedene Modelle, ua. auch Money for Nothing, Changes for Free, vor.

Der Vortrag wurde initial in einem Webinar gehalten, auf http://bit.ly/agilervertrag finden Sie das Video sowie weitere Information.

Die Slides werde ich im Rahmen der kontinuierlichen Bearbeitung des Themas regelmäßig hier aktualisieren.

Published in: Technology

Vertraege in Agilen Projekten

  1. 1. Verträge in Agilen Softwareprojekten „Vertrauen & Kooperation“ Björn Schotte // @BjoernSchotte // bjoern.schotte@mayflower.de MAYFLOWER GmbH Disclaimer: keine Rechtsberatung! http://creativecommons.org/licenses/by-sa/3.0/deed.de
  2. 2. Über den Referenten: Björn Schotte ‣ Unruhestifter ;-) ‣ Geschäftsführer MAYFLOWER GmbH ‣ Senior Consultant ‣ hilft Kunden, die Herausforderungen ihres Geschäfts im Online Umfeld zu lösen. Berät konzeptionell & im Umfeld Agiler Methoden (Scrum, Enterprise Lean Startup) ‣ MAYFLOWER: 60+ Devs, Individualsoftware Web, Mobile & E- Business/E-Commerce
  3. 3. Ausgangslage Software-Entwicklung ‣ Cynefin (/ˈkʌnɨvɪn/) Modell Softwareentwicklung: Complex & Chaotic
  4. 4. Antwort auf Komplex & Chaotisch ‣ Agiles Projektvorgehen, emergente Praktiken ‣ Ich weiss heute nicht genau, was morgen sein wird ‣ Ich setze enge Korridore (Sprints), um kontinuierlich kleine Pläne „auf Sicht“ zu schmieden
  5. 5. Antwort auf Komplex & Chaotisch ‣ Upfront Design nur so viel wie notwendig und möglich ‣ ... denn ich will gerade Flexibilität im Vorgehen haben ‣ Lasten-/Pflichtenheft: Irrglaube, die Dinge „im Griff“ zu haben, teure CRs, sehr viel höhere TCO
  6. 6. Ausgangslage Vertragswesen ‣ Verträge versuchen, Bekanntes zu regeln ‣ Verträge versuchen, Sicherheit zu bieten ‣ Verträge versuchen, Risiken zu verteilen ‣ Verträge versuchen, Lösungen für Probleme zu liefern ‣ Verträge werden (gemeinhin) dann genutzt, wenn sich die Parteien nicht mehr vertragen
  7. 7. Ausgangslage Vertragswesen ‣ Kunden haben oftmals schlechte Erfahrungen mit Dienstleistern gemacht und versuchen sich durch Verträge abzusichern (Risiko komplett auf Dienstleister abwälzen) ‣ dt. Werkvertragsrecht aus einer Zeit, als es noch keine Softwareentwicklung gab ‣ ... was heisst denn eigentlich „Werkvertrag“?
  8. 8. Ausgangslage Vertragswesen Definition Werkvertrag, Wikipedia: „der Werkunternehmer schuldet dem Werkbesteller die Herstellung eines Werkes, das heißt die Herbeiführung eines bestimmten Erfolges tatsächlicher Natur.“ „Die Fälligkeit der Vergütung des Werkvertrages tritt mit der Abnahme des Werkes ein.“
  9. 9. Ähm ...
  10. 10. Softwareentwicklung ...
  11. 11. KOMPLEX ...
  12. 12. Ich habe ein Problem, für das ich die Lösung noch nicht genau kenne
  13. 13. != Werkvertrag
  14. 14. Hey, lass uns doch einfach T&M machen!
  15. 15. Pures T&M = Risiko 100% auf Auftraggeberseite
  16. 16. Conclusio?
  17. 17. 1. Verträge eignen sich scheinbar nicht für agile Vorgehensweisen
  18. 18. 2. Software-Entwicklung = „für (un)bekannte Probleme mit noch unbekannten Lösungen“ (Scrum) Komplex!
  19. 19. 3. Software-Entwicklung = „für unbekannte Probleme mit noch unbekannten Lösungen“ (Lean Startup) Chaotisch!
  20. 20. Drama, Baby?
  21. 21. Annäherung, Teil 1
  22. 22. GPL, GNU General Public License
  23. 23. Kooperation durch Tit-for-Tat
  24. 24. Nutze den Source, verändere ihn. Das ist okay.
  25. 25. Verteilst du die neue Software, liefere den gesamten Quellcode mit. Inklusive deiner Änderungen.
  26. 26. Verhinderung von Missbrauch durch Hack des Vertrages (Lizenz). Erzwingt Kooperation.
  27. 27. Übertragbar auf unsere Problematik?
  28. 28. Annäherung, Teil 2
  29. 29. „missbrauche“ Vertragsrecht zum Kooperationszwang
  30. 30. Zweck des Vertrages wandelt sich
  31. 31. weg von Definition von Bekanntem (wir wissen es eh nicht 100%ig) hin zur Definition Rahmen, der Kooperation regelt und Verletzung von Kooperation ahndet
  32. 32. Auch im Vertrag Konzentration auf die Stärken agilen Vorgehens
  33. 33. Emergente Erkenntnisse nutzen, um flexibel am Markt zu agieren
  34. 34. Konzentration auf Generierung von hohem Business Value
  35. 35. Rahmen gestalten, der Kooperation ermöglicht und Pflichten/Rechte definiert
  36. 36. Mangelnde Kooperation ahnden
  37. 37. Nein, nicht mit Pönalen. Es gibt viel schlauere Lösungen.
  38. 38. Conclusio?
  39. 39. 1. Vertragsgestaltung „hacken“
  40. 40. 2. Konzentration auf Kooperation und Generierung von Nutzen
  41. 41. 3. Realität anerkennen. Empirie & emergentes Wissen zu Lösungen entsteht während des Projekts
  42. 42. Ergebnis: Auflösung Unvereinbarkeit Agiles Vorgehen - Vertragsrecht
  43. 43. Beispiele für Vorgehens-/ Vertragsmodelle
  44. 44. Disclaimer - für alles gilt: ‣ fragen Sie Ihren Anwalt ‣ fragen Sie Mayflower :-) ‣ have fun & viele erfolgreiche Projekte!
  45. 45. T&M - the „good old one“ ‣ bei klassisch T&M Bezahlung jeder Stunde (zB Sprint-weise) ‣ Risiko 100% auf Auftraggeber-Seite ‣ ohne weitere Elemente (zB enges Scrum, hohe Motivation etc) wenig Anreiz für den Dienstleister, hohen BV zu liefern ‣ dennoch: je nach Situation, Klarheit von Anforderungen, Möglichkeiten des Kunden kann pures T&M Sinn ergeben
  46. 46. „T&M mit Abbruch“ ‣ bei klassisch T&M Bezahlung jeder Stunde (zB Sprint-weise) ‣ Kunde merkt nach N Sprints, dass nicht mehr viel Business Value zu holen ist ‣ mit einem Vorlauf von zB 1 Sprint kann der Kunde jederzeit nach einem Sprint das Projekt beenden ‣ Vorlauf notwendig, damit der Dienstleister die Ressourcen umplanen kann
  47. 47. „T&M mit Abbruch“: Beispiel ‣ Projekt ursprünglich auf 10 Sprints geplant ‣ gegen Ende Sprint 6 stellt der Kunde fest, dass kaum mehr BV zu holen ist, da sich die Marktbedingungen geändert haben ‣ Ende Sprint 6: Ankündigung, dass das Projekt mit dem Ende von Sprint 7 beendet wird ‣ Vorteile für beide Seiten, Kooperation wird gestützt: ‣ kein BV mehr realisierbar? Abbruchmöglichkeit ‣ DL hat genügend Vorlauf zur Umplanung
  48. 48. T&M on steroids
  49. 49. Warnung: nur für echte Männer
  50. 50. Regel 1: T&M, sprint-weise Abrechnung aller Stunden
  51. 51. Steroids! Regel 2: Kunde kann ohne Angabe von Gründen einen Sprint nicht bezahlen
  52. 52. Steroids! Regel 3: Sonderkündigungsrecht DL, wenn der Kunde das 2. Mal einen Sprint nicht bezahlt
  53. 53. Ergebnis: Verkettung beider Seiten in Kooperation
  54. 54. der Kunde überlegt sich sehr genau, wann er einen Sprint nicht bezahlt
  55. 55. der Dienstleister hat ein Interesse an guter, ergebnisorientierter Arbeit
  56. 56. Achtung: macht nur Sinn für Projekte, bei denen DL-Wechsel sehr schmerzhaft (teuer) ist und somit eine Garantie zur Kooperation benötigt wird Steroids!
  57. 57. MAYFLOWER nutzt „T&M on steroids“ erfolgreich in Projekten.
  58. 58. Na, schon Herzrasen bekommen?
  59. 59. Ok, schalten wir einen Gang zurück.
  60. 60. Vertrag, klassisch, mit Gewerk und Jedöns...
  61. 61. Klassischer Vertrag, Agil mit Festpreis ‣ Regel 1: im Vertrag ist Scrum-Vorgehen definiert ‣ Regel 2: beiden Parteien bewusst, dass kein fixes Feature-Set geliefert werden kann. Das Budget ist fix definiert. ‣ Regel 3: es kann kein Gesamtwerk definiert werden „Ein Gewerk brauche ich für Gewährleistung. Ich brauche Sicherheit. Hilfe, was kann ich tun?“
  62. 62. Klassischer Vertrag, Agil mit Festpreis ‣ Regel 4 (!): eine einzelne User Story stellt ein Mini-Gewerk da, auf das Gewährleistungsregeln angewandt werden ‣ Regel 5 (!): das Team kann User Stories ablehnen, wenn diese aus ihrer Sicht nicht ausreichend spezifiziert/schätzbar sind („können wir das Werkvertragsrisiko hier übernehmen?“) ‣ Regel 5 (! Variation): nach beidseitiger Rücksprache kann eine einzelne User Story dienstvertraglich behandelt werden „Puh... ich hab Gewerk drin. Check. Doch wie ist das mit der Abnahme?“
  63. 63. Klassischer Vertrag, Agil mit Festpreis ‣ Regel 6 (!): Abnahme des Mini-Gewerks im Sprint Review. Bei Nicht-Abnahme (weil Story nicht errreicht!) kommt die Story zurück ins Backlog und wird zB für den nächsten Sprint wieder eingeplant. ‣ Regel 7 (!): monatlicher Zahlungsplan aufgrund der erbrachten Leistungen ‣ Regel 8 (!): wird eine bereits realisierte User Story durch eine neue US erweitert/ersetzt, so beginnt die Gewährleistung neu „Ok. Entkopplung Bezahlung von Gewährleistung/Abnahme. Nur wenn im Nachhinein, also im Betrieb, etwas Abgenommenes nachweislich nicht stimmt, muss kostenlos gefixt werden. Das ist fair.“
  64. 64. Kooperation auf beiden Seiten.
  65. 65. Vorgehen im Vertrag festgelegt.
  66. 66. Mini-Gewerke statt großes Gewerk.
  67. 67. Stakes von Legal & Procurement erfüllbar.
  68. 68. MAYFLOWER nutzt „Klassisch- agiler Festpreis“ erfolgreich in Projekten.
  69. 69. Back to Innovation: Money for Nothing, Changes for Free
  70. 70. Exkurs zurück ...
  71. 71. Verträge, old school: „Ich kenne die Features, ich kenne den ROI, ich kann alles definieren und regeln.“
  72. 72. Das stimmt so nicht
  73. 73. Daher Agile Logik:
  74. 74. Ich investiere (und bezahle) Arbeitszeit
  75. 75. Ich erzeuge maximalen Business Value
  76. 76. und mache so lange weiter
  77. 77. bis es sich nicht mehr lohnt (Kosten Feature >> BV)
  78. 78. = bis es sich nicht mehr lohnt, weiter zu machen
  79. 79. Ausprägung dieses Prinzips ist „Money for nothing, Changes for free“
  80. 80. Regel 1: Standard fixed price Contract mit T&M für Changes
  81. 81. Regel 2: Tausch von Features gleicher SP Zahl möglich, sofern an US noch nicht begonnen (Changes for Free)
  82. 82. Regel 2a: Neue Features möglich, wenn Low Prio Features gleicher SP-Zahl wegfallen
  83. 83. Anforderung an Kunde & DL: es gibt ein qualitativ gutes Backlog, Gesamt-Features sind gut schätzbar! Achtung!
  84. 84. Regel 3: hält der Kunde sich nicht an Scrum, wandelt sich das Projekt in reines T&M
  85. 85. Nun zum „Money for Nothing“ ...
  86. 86. Regel 4: ebenfalls nur gültig, wenn Scrum Vorgehen eingehalten
  87. 87. Regel 5: beide Parteien können sich auf SP Estimates einigen. Ansonsten Umwandlung in T&M
  88. 88. Regel 6: wenn Kosten Feature >> BV dann Projekt-Abbruch
  89. 89. Regel 7: Ausgleich für frühzeitige Beendigung des Projekts: 20% des übrig gebliebenen Budgets geht zusätzlich an DL („Money for Nothing“)
  90. 90. Hmm. Wann ist der Einsatz von M4NC4F sinnvoll?
  91. 91. Nur bei BV Optimierung! Nur wenn klar ist, dass ich das Budget nicht bis zum Ende aufbrauchen will. Achtung!
  92. 92. M4NC4F lohnt sich nicht, wenn das Budget sowieso gut und sinnvoll genutzt werden kann.(iSv gute Business Value Generierung regelmäßig möglich) Achtung!
  93. 93. MAYFLOWER nutzt M4NC4F erfolgreich in Projekten.
  94. 94. Finale ... ein paar Empfehlungen
  95. 95. Konzentrieren Sie sich auf vertrauensvolles Arbeiten auf Augenhöhe
  96. 96. Setzen Sie im Vertrag nur einen Rahmen, der Kooperation garantiert und Verletzung von Kooperation ahndet.
  97. 97. Typische aus Legal & Procurement getriebene Pönalen sind tabu. Sie ergeben im agilen Kontext keinen Sinn.
  98. 98. Ahnden Sie Verletzung der Kooperation mit Abbruchmöglichkeiten (= Hebel für Auftraggeber) oder T&M Wandlung (= Hebel für Auftragnehmer)
  99. 99. Legal & Procurement müssen mit ins Boot. Und intensiv beraten werden.
  100. 100. Noch ein Tipp für Ihre Feature-Planung. Steroids!
  101. 101. Die User Story muss den Nachweis erbringen, dass der Wert erwirtschaftet wird Steroids!
  102. 102. Es wird der erwartete Wert angehangen. (Business Value Poker) Steroids!
  103. 103. Ich beschreibe den Test, was ich mir durch dieses Feature erwarte (zB 5% mehr Conversion Rate) Steroids!
  104. 104. Nach Release validiere ich meine Erwartung. Steroids!
  105. 105. Lerne & Adaptiere. Steroids!
  106. 106. Liege ich regelmäßig mit meinen Erwartungen daneben? Hmm. Dann werden meine Feature-Wünsche nicht mehr berücksichtigt. Steroids!
  107. 107. Buch- und Linktipps
  108. 108. Buch „Der Agile Festpreis“ (Boris Gloger) mit weiteren Ideen
  109. 109. Google-Suche zu „10 contracts for your next agile project“
  110. 110. „Lasst uns agile Projekte besser machen. Durch gegenseitiges Vertrauen & Kooperation“ http://mayflower.de/

×