Gewerke in agilen Projekten

Avatar von Björn Schotte

In agilen Festpreisprojekten sind meist zwei Komponenten für den Auftraggeber wichtig: fixed price und Gewährleistung auf die gelieferten Leistungen. In klassischen Werkverträgen gilt dabei die Gewährleistung auf das Gesamtwerk.

In agilen Projekten, bei denen die gewünschten Funktionalitäten ein moving target sind (und dies aus Gründen der Flexibilität und Nicht-Vorhersehbarkeit über die gesamte Projektdauer gewünscht ist), muss man hier jedoch anders vorgehen. Da sich durch die Priorisierung im Product Backlog zwischen den einzelnen Sprints die Prioritäten von Funktionalitäten ändern können und damit zu Beginn eines Projekts das Gesamtwerk nicht vollständig definierbar ist, kann der Auftragnehmer natürlich auch keine Gewährleistung auf das Gesamtwerk geben.

Um dieses Problem zu lösen, gibt es mehrere Wege. Doch vorab: I am not a lawyer und dies stellt keine Rechtsberatung dar. :-) Ein Ansatz (es gibt hier mehrere), der unserer Erfahrung nach gut funktioniert ist, jede einzelne User Story als Gewerk zu definieren und gegen Ende des Sprints abzunehmen. Somit besteht das Projekt aus einzelnen Mini-Gewerken, für die jeweils eine entsprechende Gewährleistung gilt.

Damit kann also die schwierige werkvertragliche Gesetzgebung auch auf agile Projekte abgebildet werden.

Wie handhabt Ihr das in agilen Projekten? Welche anderen Wege geht Ihr, um werkvertragliche Regelungen in agilen Projekten abzubilden, und für welche Form von Projekten eignen sich diese Regelungen?

[smartblock id=6342]
Avatar von Björn Schotte

Kommentare

5 Antworten zu „Gewerke in agilen Projekten“

  1. Gewerke in agilen Projekten http://t.co/WVlP7WKF via @mayflowerphp

  2. Gerrit Beine frug auf Xing, welche alternativen Möglichkeiten es noch gibt: mir fällt zum Beispiel ein, dass man auch einen Sprint als Gewerk bezeichnen könnte, da ein Sprint ja eine fix definierte Menge an Stories enthält.

    Hierbei sollte IMHO darauf geachtet werden, dass nur die im Sprint Review vom PO abgenommenen User Stories als ein Gewerk gelten, um Fälle wie „Tausch gleichwertiger User Stories im Sprint“ abzudecken. Ich persönlich finde jedoch die User Story als Gewerk am attraktivsten, da es mir als kleinste atomare Einheit erscheint.

  3. Also Werkvertrag lohnt sich m.E. gar nicht. Wenn der Kunde bei der Abnahme nachlässig ist, weil er schnell live gehen möchte und dann ständig Bugs meldet, ist das nur Aufwand. Ich habe auch schon Verträge von einem Fernsehsender gesehen, der dann die Bugs innerhalb von 6 Stunden behoben haben wollte, da hat man keinen Spaß.
    Typischerweise wollen die Kunden auch sofort die Entwicklung starten, statt ständig Spezifikation schreiben, da kommt dann oft „machen sie einfach mal“, schon aus Angst dass man Änderungen für falsche Vorgaben später zahlen muss. Viele Kunden liefern auch bewusst keine Details, um bei der Abnahme den Preis nochmal drücken zu können.
    Einige Agenturen verkaufen die Spezifikation der User Stories nach Tagessätzen, weil unerfahrene Kunden bei kleinsten Dingen ewig diskutieren. Manche Kunden versäumen auch gerne mal die Meetings oder die Server werden nicht rechtzeitig bestellt, dann hat man gleich 1-2 Wochen Stillstand. Wenn man eine vernünftige Spezifikation schreibt, kostet das meist so viel wie der Code selbst, das versteht aber kein Kunde.
    Werkverträge wurden ursprünglich für kleine Projekte wie Tische, Stühle und Schränke entwickelt, nicht für komplexe Software mit Millionen Zeilen Code. Wenn ich zu Audi gehe und denen sage, dass sie mir ein Auto bauen sollen und ich gebe denen dann jede Woche ein paar User Stories, die würden mich sofort rauswerfen. Ich habe auch noch keinen Anwalt gesehen, der mir für seine Dienste einen Werkvertrag anbietet. Mit einem Dienstvertrag für jeweils 3 Monate sind beide Seiten meist viel besser dran.

    1. Hallo Arno,
      vielen Dank für deinen interessanten Kommentar. Ich versuche hier mal auf die einzelnen Punkte einzugehen:

      Werk- vs. Dienstvertrag: ja, es kann gut der Fall sein, dass ein Projekt auf Dienstvertragsbasis mehr Sinn macht als auf werkvertraglicher Basis. Vielleicht nicht unbedingt aus den von dir genannten Gründen (Schuld/Risikoverschiebung beim/auf den Kunden). Wir sehen zum Beispiel in manchen Projektkonstellationen auf Dienstvertragsbasis vor, dass der Kunde nach einem Sprint das Recht hat, das Projekt schlicht zu beenden (hoffentlich, weil genügend Value da ist und nicht, weil er mit uns unzufrieden ist). Es kommt eben ganz auf die Projektart und -konstellation an. Zudem unterscheiden wir in der Regel auch zwischen werkvertraglichen und dienstvertraglichen Aufwendungen, womit sich ein „gemischter“ Vertrag ergeben kann: manche Dinge, wie zB Sprint Meetings, Konzept-Spikes, Support o.ä., lassen sich eben nicht werkvertraglicher Natur erledigen.

      Spezifikation der User Stories: wir haben gute Erfahrung damit gemacht, in einem „Sprint 0“ das initiale Setup inkl. Spezifikation der ersten User Stories durchzuführen (auf Basis der Dokumente/Konzepte, die der Kunde bisher hat). Solch ein „Sprint 0“ ist natürlich eher Aufwandsbasiert (die Kosten ergeben sich durch die Teamkapazität, die für diesen Sprint 0 benötigt wird) und führt dazu, dass ein erstes, priorisiertes Backlog nach Abstimmung mit den Stakeholdern (dem Kunden) existiert. Alle Folgesprints sind dann wieder werkvertraglicher Natur.

      „Bei kleinsten Dingen ewig diskutieren“: es kann sinnvoll sein, in Absprache mit dem Kunden zu definieren, dass bei der Realisierung einer User Story die „technisch einfachste Variante“ realisiert wird. So vermeidest du unnötige Diskussionen – schließlich soll ja das Devteam entscheiden, wie es die User Story technisch implementiert.

      Meetings versäumen, Server nicht rechtzeitig bestellen: nun, das kann ich jetzt so nicht nachvollziehen. Ich glaube, dass der Product Owner (in diesem Fall also auf Dienstleisterseite) schon auch die Verantwortung hat, zu den entsprechenden Meetings rechtzeitig einzuladen. Das ist ja das schöne an der agilen Vorgehensweise: du hast einen festen Rhythmus (zum Beispiel 14-tägig), der sich einpendelt und immer fix ist. Das Gleiche für das Bestellen von Servern: als Dienstleister unterstützen wir natürlich den Kunden und erinnern ihn rechtzeitig daran, dass die Server bestellt werden müssen (oder erledigen dies gleich für ihn mit, so dass er sich nicht darum kümmern muss).

      Ich gebe dir abschließend insofern Recht, dass es schwierig ist, Werkverträge für Software zu etablieren, da Werkverträge qua Gesetz durchaus für andere Dinge vorgesehen sind. Für den Kunden sind jedoch meist Planungs-/Budget“sicherheit“ wichtig sowie Gewährleistung, und ich meine hierfür kann man Lösungen bieten, die vielleicht nicht 100%-ig sind (100%ige Sicherheit gibt es sowieso nie), aber ein partnerschaftliches Miteinander auf Augenhöhe ermöglichen. Das ist gerade für Konzernumfelder sehr wichtig.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.