Agile Projekte in Auftrag geben Jens Coldewey (BDU) Coldewey Consulting Toni-Schmid-Str. 10 b D-81825 München Germany Tel: +49-700-COLDEWEY Tel: +49-700-26533939 Fax: +49-89-74995703 jens.coldewey@coldewey.com http://www.coldewey.com 24. November 2006 XPDays 2006, Hamburg
Was erwartet Sie in den kommenden 45 Minuten? Das Problem: Auftragsentwicklung und Agilität Warum Juristen den Wasserfall propagieren Warum Agilisten das nicht tun Warum Einkäufer Werkverträge mögen Ein paar juristische Grundbegriffe Agile Entwicklung aus Sicht des Werkvertrags Agile Entwicklung und Wartungsverträge Lieferantenmanagement
Warum Juristen den Wasserfall propagieren Spezifikation = Gewerkbeschreibung Design Test Akzeptanztests = Gewerkabnahme Realisierung = Gewerkerstellung Ein korrekter Wasserfall würde direkt dem juristischen Konstrukt Werkvertrag entsprechen wenn es ihn denn gäbe
Warum Agilisten das nicht tun (und Fachmanager das nicht tun sollten) Werkvertrag Änderungshäufigkeit Spezial- Infrastruktur z.b. Virenschutz Standardprodukte z.b. E-Mail Strategische Waffen Individualsoftware Agile Entwicklung Differenzierungspotenzial
Warum Einkäufer Werkverträge mögen Werkverträge bieten theoretisch Vergleichbarkeit der Angebote Kalkulierbarkeit Planbarkeit Klare Haftungsregeln Problemdelegation zum Auftragnehmer Schadenersatzpflicht was in der Praxis nicht immer funktioniert Extrem unterschiedliche Qualität der Arbeit Nur wenn Planung funktioniert Nur bis zur Umsetzung Fehler oder CR? Wenn die Software nicht kommt, hat der Auftraggeber das Problem Strategische Schäden sind nicht einklagbar Werkverträge bieten nur Scheinsicherheit
Juristische Vertragsarten Dienstleistung Leistung Preis Leistung Preisberechnung Agile Entwicklung Gewerk Inhalt Termin Preis Festpreis Inhalt Termin Preisberechnung Aufwand
Agile Entwicklung aus Sicht des Werkvertrages Aufteilung in Rahmenvertrag Preis (z.b. pro Inkrement) Vorgehen (z.b. ein Inkrement pro Monat) Auftrags- und Abnahmeprozess (z.b. Planungsspiel, Abnahmetests) Beistellungen (Kunde im Team!) Juristische Teile (Kündigung, Haftung, Vertragsstrafen ) und Serie von Einzelverträgen Ein (leichtgewichtiger) Vertrag pro Inkrement Inhalt des Inkrements Auslieferungstermin Zeitpunkt des Anschlussvertrages: Früh genug, um nahtlos weiter arbeiten zu können Spät genug für Erkenntnisse aus laufendem Inkrement
Vor- und Nachteile des Serien-Werkvertrages Vorteile: Kein vertraglich festgelegter Gesamtumfang Bildet agile Entwicklung sauber ab Kommt mit erprobten juristischen Mitteln aus Sollte im Rahmen bestehender Einkaufsstrukturen möglich sein Nachteile: Kein vertraglich festgelegter Gesamtumfang Erheblicher bürokratischer Aufwand
Alternative 1: Change-Management und noch mal Change-Management Idee: Ein kompletter Werkvertrag, jede Inkrementenplanung wird als CR eingephast Vorteile: Kompatibel mit echten Werkverträgen Juristische Abstimmung läuft wie bisher Nachteile: Der Vertrag passt nicht mehr zur Absicht Erhebliches Risiko für den Auftragnehmer
Alternative 2: Gerade noch ausreichende Auftragsgestaltung Idee: Ein Werkvertrag mit bewusst unscharfer Formulierung des Inhalts Vorteile: Kompatibel mit üblichen Werkverträgen Der Vertrag passt zur Absicht Formal nichts neues (Weg des geringsten Widerstandes) Nachteile: Der Vertrag ist juristisch kaum brauchbar Erhebliches Risiko für beide Seiten Vorteile des Werkvertrages gehen verloren, Nachteile bleiben
Agile Entwicklung aus Sicht des Dienstvertrags Agile Entwicklung ähnelt der Wartung: Veränderung existierenden Codes Kurzfristige Zieldefinition in enger Abstimmung Langfristiges volatiles Ziel durch Fachlichkeit gesteuert Warum nicht auch so beauftragen? Dienstleistungsvertrag regelt Prozess, Service Level und Konditionen (z.b. Gesamtbudget, wichtige Termine) Teilaufgaben werden informell dokumentiert abgestimmt (Sprint Meeting, Planning Game) Kündigung bei Unzufriedenheit Dieser Gedanke stammt von Tobias Valtinat vom ZLW/IMA in Aachen
Agile Entwicklung auf Basis eines Wartungsvertrags Vorteile Existierendes Vertragskonstrukt, keine Innovationen nötig Entspricht der Absicht, zu arbeiten Keine unnötigen bürokratischen Aufwände Nachteile Formal übernimmt der Auftragnehmer weniger Verantwortung Inhaltliches Ziel nicht juristisch bewehrt Beim Einkauf schwer durchsetzbar
Alternative zur Haftung: Zielführendes Lieferantenmanagement Verträge können den Erfolg eines Softwareprojekts nicht erzwingen Some people deliver software, some don t (Dave Thomas) Es gilt, die Lieferanten zu finden und zu halten, die Erfolge erzielen Lieferantenmanagement nach Erfolg und Zufriedenheit, nicht nach Verhandlungsopportunität
Fazit Bei agiler Entwicklung kann man den Erfolg genauso wenig juristisch erzwingen, wie bei traditioneller Agile Entwicklung macht das schon zu Beginn des Projekts deutlich Der Auftraggeber hat die Wahl: möglichst viel Fassade retten ( verbogener Werkvertrag ) oder faktisches Risiko auch juristisch übernehmen (Dienstvertrag) Der bessere Weg hängt von politischen Faktoren ab Fundiertes Lieferantenmanagement hilft, Ziele zu erreichen Agile Entwicklung liegt im Interesse des Auftraggebers