Scrum – Innovative Lösung oder agiler Irrtum?
Agile Projektmethoden und besonders Scrum sind seit Jahren in aller Munde und erobern nach und nach vor allem die IT-Projektlandschaft. Kaum noch eine Projektausschreibung ohne die Forderung nach agiler Projektmethodik. Auch große Konzerne haben als Kunde die Scrum-Methodik für sich entdeckt und sehen in diesem Vorgehensmodell die Lösung vieler ihrer gefühlten Probleme aus der Vergangenheit, wie etwa fehlender Zielabgleich zwischen Auftraggeber und Auftragnehmer, fehlende Ergebnis- und Kostenkontrolle im Projekt. Auch allerlei Veröffentlichungen offline und online zum Thema werden nicht müde, die Vorteile der Scrum-Projektmethodik zu loben.
Weit seltener, um nicht zu sagen fast gar nicht, finden sich jedoch Veröffentlichungen zur Frage wann und wie Scrum überhaupt Sinn macht. Ebenso wenig ist darüber zu finden, welche tatsächlichen oder gefühlten Probleme der Kunde mit Scrum eigentlich lösen möchte. Vielmehr wird eher abstrakt die Ergebnisorientierung von Scrum gelobt und, um das Ganze zu untermauern, die guten alten Projektgeschichten aus der Vergangenheit bemüht, die sich stets um das monatelange, am Bedarf des Kunden vorbei arbeiten drehen.
Das alles wäre gut zu verschmerzen und kein Anlass für Kritik wenn Scrum bestenfalls eine überbewertete Vorgehensweise wäre, die im schlimmsten Fall auch keine besseren Ergebnisse als andere Methoden hervor bringt, aber eben auch nicht schadet.
Das muss allerdings, zumindest aus der Perspektive des Scrum-Auftragnehmers, ganz klar in Frage gestellt werden. Das gilt insbesondere dann, wenn Projekte in Scrum-Logik bearbeitet werden sollen, aber kommerziell als Werkverträge zu beurteilen sind, schlimmstenfalls noch mit einem Festpreis versehen. Wie soll das aber nun dem Auftragnehmer schaden? Und wie kommen deutsche Gerichte überhaupt dazu Scrum-Projekte schon ihrem Wesen nach als Werkvertrag zu qualifizieren?
Die Antworten auf diese Fragen finden sich in der Scrum-Logik und insbesondere in den klar beschriebenen Rollen dieser Vorgehensweise, etwa zu finden unter https://www.scrum.org/. Leider werden diese Erläuterungen aber in der Praxis offenbar selten bis gar nicht gelesen und dementsprechend auch nicht in Angeboten und Verträgen berücksichtigt. Im Projekt kommt es dann zu Auseinandersetzungen mit dem Kunden und am Ende bleiben oft nur Frust und eine negative Projektmarge. Ein genaueres Hinsehen lohnt also.
Wie unter anderem das Landgericht Wiesbaden (Urt. v. 1. Dezember 2016) zu Recht festgestellt hat, ist das gesamte Bestreben der Scrum-Logik darauf gerichtet, möglichst schnell, zu messbaren und klaren Arbeitsergebnissen zu kommen. Genau das ist das gesetzliche Verständnis eines Werkvertrages: es werden Arbeitsergebnisse bzw. ein Erfolg geschuldet, dessen Eintritt überprüft werden kann. Das Arbeiten im Scrum nicht als Gewerk zu verstehen, ist also eher abwegig. Soweit so gut.
Das alles wäre halb so schlimm käme jetzt nicht noch der Festpreis hinzu. Denn in der Praxis ist so, dass der Kunde trotz Scrum einen Festpreis verlangt um die Budgets auch weiterhin unter Kontrolle zu halten. Das ist aber ein klarer Widerspruch zur gesamten Scrum-Logik, der eifrig ignoriert wird. Geht man in die Ursprünge von Scrum zurück, so wird klar, dass diese Methode richtigerweise versucht Lösungswege für Situationen zu finden, in denen der Lösungsweg und das gesamte Endergebnis, eben noch nicht feststehen. Um sich auf diesen Wegen nicht zu verirren, wurde die Sprintlogik mit schnellen greifbaren Ergebnistypen entwickelt. Genau das ist aber ein evidenter Widerspruch zum Werkvertrag mit Festpreis. Wie könnte ein verständiger Unternehmer einen Festpreis für eine Lösung nebst Lösungsweg nennen, wenn beides doch unbekannt ist? Die Antwort ist: gar nicht! Der Kunde ignoriert diese Tatsachen und die Berater/Dienstleister schätzen ihre Preise mit dem ganz dicken Daumen um den Auftrag zu bekommen.
Zu guter Letzt tritt dann noch der Wunsch des Kunden auf den Plan eine bestimmte Rolle im Scrum übernehmen zu wollen: er möchte Product Owner sein. Das macht auch scheinbar Sinn. Denn ist es nicht die originäre Rolle des Product Owners die Interessen des Kunden zu vertreten? Scrummaster.de sagt dazu : „Er trägt die Verantwortung dafür, daß die richtigen Anforderungen im Product Backlog stehen und daß sie in einer sinnvollen Reihenfolge abgearbeitet werden. Dadurch hat er maßgeblichen Einfluss auf das Arbeitsergebnis und ist, so gesehen, wirklich die eine Person, deren "Hals gewürgt wird", wenn das Team - gemäß Vorgabe - Mist produziert.“
Na, das passt doch! Da kann der Kunde also ganz unmittelbar und ergebnisorientiert dafür sorgen, dass seine Wünsche auch ausreichend Gehör finden. Aber leider bleibt der Auftragnehmer als Werkunternehmer mit Festpreis voll verantwortlich für die Erstellung eines Gesamtergebnisses zu einem vorab festgelegten Preis. Und das während der Kunde als Product Owner agil, und ohne jedes Vetorecht des Werkunternehmers über das Backlog, das Werk quasi während des Projekts häppchenweise bis zum Ende definiert. Damit wird der Werkunternehmer praktisch Passagier auf seinem eigenen Schiff und das ist kommerziell kaum zu verantworten.
Warum aber ist das im Grunde so einfache Vorgehen von Scrum nun kommerziell-rechtlich so sperrig, wo es doch alles vereinfachen soll?
Die Antwort liegt wieder im Ursprung von Scrum: Scrum war nie als Vorgehen für ein Auftraggeber-Auftragnehmer-Verhältnis mit kommerzieller Außenkante gedacht. Vielmehr ging es von Beginn an darum Projektarbeit im eigenen Haus oder einer geschlossenen Organisation zu verbessern. Solange also nicht zwei Organisationen, durch einen Werkvertrag mit Fetspreis im Scrum-Modus vermengt werden, ist Scrum auch kommerziell-rechtlich beherrschbar, wenn auch aufwendiger als ein Wasserfall-Projekt..
Damit ist auch schon ein Teil der Lösung aus dem scheinbaren Dilemma skizziert: Wie gehabt kommt es auch hier darauf an, die richtigen Instrumente auf den richtigen Fall anzuwenden. Wenn der Kunde sein Ziel oder angestrebtes Ergebnis kennt, dann ist Scrum schlicht der falsche Weg und dient nur verkappt dazu, ein berechtigtes Kundenbedürfnis auf dem falschen Weg zu lösen. Kennt der Kunde sein Ergebnis nicht, dann ist Scrum möglciherweise der richtige Weg, aber sicher nicht als Werkvertrag mit Festpreis. Das gesamte Thema lässt sich mit einer kleinen Matrix in wenige Anwendungsfälle zerlegen.
Wie das aussehen kann zeigen wir in unserem Beitrag: Mit der Matrix aus dem kommerziellen Scrum-Dilemma.
