Anfang der Woche kam in einer Online-Gruppe die Frage auf, wie man denn mit Werkverträgen im agilen Kontext umgeht. Nun. Am besten gar nicht. 🤷🏻‍♂️

Das Problem mit Werkverträgen ist, dass sie eine klar definierte Arbeit (Werk) zusichern. Was in der physischen Produktion in der Regel eine gute Lösung ist, da sich der Arbeitsumfang sehr genau definieren lässt, ist in der Wissensarbeit tödlich. Meistens. Die Ausnahmen lassen sich schnell umreißen: Das Produkt ist bereits fertig und muss nur noch ausgeliefert werden, ohne das weitere Wissensarbeit notwendig ist. Oder der Umfang ist minimal, die Aufgabe Routine und die Abschätzung somit sehr, sehr genau möglich.

Für alles andere gilt: Finger weg vom Werkvertrag. Um den Grund dafür zu verstehen, hilft uns das Magische Dreieck aus dem Projektmanagement, auch unter „triple constraint“ bekannt:

Klassischerweise ist in einem Projekt vor allem der Funktionsumfang fix und sowohl die Ressourcen als auch der Zeitplan in gewisser Weise variabel, hier im linken Dreieck dargestellt. Wer die Ressourcen bezahlt, wenn sie aus dem Ruder laufen, sei an dieser Stelle mal dahingestellt, in der Regel versucht man dieses Risiko durch möglichst genaue Vorausplanung zu reduzieren. Auch der Zeitplan soll von vornherein möglichst detailliert ausgeplant sein.

Kommt es allerdings zu einer Änderung des Funktionsumfangs, müssen sowohl Ressourcen als auch Zeitplan überarbeitet werden, es tritt meist ein definierter Change-Prozess in Kraft. Der wiederum kostet selbst Zeit und Ressourcen.

Bei der agilen Arbeitsweise sind im Gegensatz zum klassischen Dreieck sowohl Ressourcen als auch Zeitplan fix. Für die Kundin ist klar, wieviel das Projekt kostet und bis wann es fertig ist. Womit sie allerdings leben muss, ist eine Unsicherheit im Funktionsumfang. Da bei der Wissensarbeit erst im Laufe der Umsetzung klar wird, wie komplex oder kompliziert eine Aufgabe wirklich ist, lässt sich der Umfang naturgemäß nicht vorher klar eingrenzen. Daher ist es wichtig, dass eine enge Zusammenarbeit zwischen Auftraggeberin und Auftragnehmerin gewährleistet ist, um den größtmöglichen Wert zu liefern.

Zusammenfassend ergibt sich also folgende Vertragsvariante: Verträge zu agilen Projekten oder Arbeiten sollten (müssen) Dienstverträge sein, die Dauer und Kosten der Leistung klar umreißen. Ferner sollten die Verträge genau definieren, wie die Mitwirkungspflichten der Kundin sind. Im Idealfall wird festgelegt, dass von Auftraggeberinnenseite eine bevollmächtigte Person (Product Owner o. ä.) gestellt wird, die Entscheidungen für das zu erstellende Produkt treffen und die Arbeit verbindlich priorisieren kann. Auch eine grobe (!) Intention, was gemeinsam entwickelt werden soll, sollte der Vertrag enthalten. Hier ist aber eine starre Festlegung zu den Inhalten zu vermeiden.

Soll der Vertrag besonders auftraggeberinnenfreundlich sein, kann zudem festgelegt werden, dass ein Ausstieg jederzeit oder zu definierten Zeitpunkten (zum Beispiel zu einem Sprintende bei Einsatz von Scrum) möglich ist. Durch die agile Arbeitsweise ist dabei trotzdem sichergestellt, dass der größte Wert zuerst geliefert wird.

Natürlich ließe sich dieses Thema noch deutlich komplexer diskutieren, aber für die meisten Fälle reicht die oben vorgenommene Eingrenzung aus. Wer als Auftragnehmerin von vornherein sicherstellen will, dass Arbeiten immer nach einem agilen Modell geliefert werden, kann die meisten genannten Punkte auch in den AGB aufnehmen. Das erspart dann unter Umständen Verhandlungen und Definitionsarbeit.

Wie bei allem Vertragswerk gilt natürlich: Lasst eure Verträge von Leuten prüfen, die das gelernt haben. Anwälte sollen darin ganz gut sein, hab ich gehört …

[waglerit-newsletter-block]