Als Methodik für Softwareanpassungen und Neuerstellungen rückt Scrum immer mehr in den Vordergrund der Diskussionen. IT-Unternehmen wenden immer wieder ein, dass die von Anwälten verwendeten Vertragsgrundlagen falsch seien, da sie die Methodik der Scrum Prozesse nicht richtig aufgriffen. Das ist auf der einen Seite vermutlich richtig und nicht von der Hand zu weisen. Um zu verstehen, warum hier Frakturen entstehen, sei kurz auf folgendes hingewiesen: Dem BGB liegt eine gewisse Typologie zugrunde. Diese Typologie stammt aus dem 19ten Jahrhundert (das BGB wurde am 1.1.1900 verabschiedet und von 1896 bis 1900 bearbeitet), die natürlich nicht direkt auf Softwareprojekte anwendbar ist. Nach Ansicht des BGH ist diese Typologie aber immer anwendbar, wenn gesonderte vertragliche Regelungen fehlen. Mehr noch: Da normalerweise im Bereich IT die meisten Verträge als Allgemeine Geschäftsbedingungen zu klassifizieren sind, sind die gesondert erstellten Regelungen der IT-Verträge auch noch daran zu messen, ob sie der Typologie des 1900 Jahrhunderts entsprechen.
Die Arbeit des Juristen besteht also immer darin, Anforderungen aus dem Jahre 2012 mit einer Typologie zu synchronisieren, die niemals für die Anforderungen geschrieben wurde und dabei auch noch einen „fairen“ Ausgleich der Interessen zu gewährleisten.
Mithin ist Scrum in meiner täglichen Arbeit auch nur ein Anstoß für ein Denkmodell und mir ist es nicht so wichtig, Scrum methodenrein in die juristische Welt zu übersetzen. Es ist meines Erachtens richtig, wenn die Kollegen Hengstler (ITRB 12,113) und Witte (ITRB 2010,44) Fragen danach aufwerfen, ob man Verträge, die die Scrum Methodik in die Welt des BGB übersetzen als Werk- oder Dienstvertrag qualifizieren kann, oder ob man nicht viele gute Ideen liegenlässt, die das Vorgehen nach Scrum beinhaltet (so Hengstler, der gerade in der Agilität einen großen Vorteil sieht), wenn man Scrum dem Werkvertragsrecht zuordnet.
In meiner Welt, also desjenigen, der die Verträge auch am Markt verkaufen muss, ist es aber ein müßiges Unterfangen, Fragen nach der reinen Lehre des Scrum zu stellen und breit zu erörtern, wenn der Markt auf der Seite der Auftraggeber partout und mit guten Gründen das Werkvertragsrecht zur Anwendung bringen will.
Der Auftraggeber will Planungssicherheit. Welchen Erfolg bekomme ich mit welchen Mitteln innerhalb welcher Zeit? Die Antwort des IT-lers ist, dass diese Planungssicherheit meist nur eine scheinbare ist, weil viele Erkenntnisse erst im Laufe des Projekts sichtbar werden. An beiden Positionen ist nichts auszusetzen.
Der Auftraggeber möchte, bevor er einen Vertrag unterschreibt wissen, was er für sein Geld bekommt. Der IT-Ler weiß aus Erfahrung, daß viele Dinge erst während des Projektes erkennbar werden und er sich nicht vertraglich verpflichten kann, einen Zustand zu erreichen, den er zum Zeitpunkt der Eingehung des Vertrags nicht kennt.
Das BGB sagt: Im Werkvertrags- wie im Kaufrecht gibt es einen Sollzustand – namentlich die vertragliche Vereinbarung – gegen den erstellt bzw. geliefert werden muss. Methodische Regelungen zur nachträglichen Veränderung des Sollzustands kennt das Gesetz nicht. Sofern sich der Sollzustand während der Laufzeit des Vertrags ändern kann und man flexibel bleiben will, gibt es den Dienstvertrag: Dort hat der Arbeitgeber „die Projekthoheit“ (also Weisungsbefugnisse im täglichen Leben) und der Angestellte unterliegt selbst dann dem Dienstvertragsrecht, wenn er die Erreichung eines bestimmten Ziels schuldet. Oder es gibt als Alternative gesellschaftsrechtliche Konstruktionen, bei deren Anwendung die Vertragsparteien täglich Beschlüsse darüber fassen können, was operativ geändert oder getan werden muss. Das Problem dieser beiden Vertragstypen besteht darin, dass Sie den IT-ler aus jeder Haftung befreien. Er kann versprechen, was er will, wird das Ziel des Projekts nicht erreicht, gibt es keine Gewährleistungsansprüche und das Dienstleistungsbudget wird verdient, wenn nicht grobe methodische Fehler gemacht werden.
Das Gesetz sagt: Ist nach dem Willen des Auftraggebers ein bestimmtes Ziel oder Erfolg geschuldet, so ist Werkvertragsrecht anwendbar; ist nur eine Bemühung oder Arbeit geschuldet, Dienstvertragsrecht.
In IT-Projektverträgen wäre Werkvertragsrecht eigentlich anwendbar, ist aber ungeeignet, weil spätere Änderungen des Sollzustandes nicht von der Typologie des BGB vorgesehen sind. Dienstvertragsrecht wäre anzuwenden, passt aber nicht, weil es dem Auftraggeber keine dem Werkvertragsrecht immanente Planungssicherheit gewährt.
Zweiter Teil: Warum Scrum Denkanstöße in die richtige Richtung setzt und nicht methodenrein umzusetzen ist.
