Source: https://legal-revolution.com/de/the-legal-revolutionary/wirtschaft-und-management/scrum-und-die-zpo?tmpl=component&print=1
Timestamp: 2020-08-11 12:40:33+00:00

Document:
Eine rechtsvergleichende Betrachtung zweier Rahmenwerke
Autor: Dr. Hanns Martin Lücke
Warum Juristen das agile Rahmenwerk "Scrum" weniger fremd ist, als es auf den ersten Blick scheint.
Die meisten Leser werden folgende Situation bereits erlebt haben: Man lernt jemanden kennen und ist sich sicher, er würde sich mit einem anderen Freund blendend verstehen. Die beiden kennen sich nicht. Sind beide Seiten kontaktfreudig und offen, vermittelt man die Nummer und wendet sich anderen Dingen zu. Was nun, wenn Vorbehalte im Weg sind oder die beiden schlicht nicht die offenen Charaktere sind? Man wird einen Anlass finden, den Boden bereiten und feststellen können, ob die eigene Einschätzung richtig war. Die beiden Freunde in dieser Arbeit sind die zivilrechtliche Prozessführung und das "Scrum-Rahmenwerk". Diese Arbeit soll den Boden bereiten.
{loadmodule custom,Werbebanner intern LRM Artikel}
Diese Arbeit ist nach den Methoden eines Rechtsvergleichs erstellt.[1] Zunächst habe ich erwogen, die juristische Methodenlehre mit Scrum zu vergleichen. Letztlich wäre die juristische Methodenlehre jedoch das, was der einzelne Entwickler in Scrum anwendet. Deswegen ist meine Wahl im zweiten Schritt auf den Zivilprozess und im Wesentlichen auf die Zivilprozessordnung (ZPO) gefallen, wobei einige funktionale Regelungen auch in anderen Gesetzen zu finden sind. Beide Rahmenwerke haben gemeinsam, dass der Inhalt offenbleibt und es ein Regelwerk ist, welches die Problemlösung in geordnete Bahnen lenken soll. Scrum hat seinen Ursprung in der Softwareentwicklung der 1990er Jahre und sollte das als zu starr empfundene „Wasserfallmodell“ ablösen.[2] Die Zivilprozessordnung entstammt dem vorletzten Jahrhundert und sollte als Teil der Reichsjustizgesetze eine Vereinheitlichung des Rechtswesens herbeiführen.[3]
Anregung zum besseren Verständnis
Da die Vorkenntnisse der Leser sehr unterschiedlich sein können, wird diese Arbeit nicht immer die passende „Tauchtiefe“ für den einzelnen Leser bieten können. Gegebenenfalls rege ich an, ein Schaubild über den „Gang des Zivilprozesses“ oder über den „Ablauf von Scrum“ bei der Lektüre griffbereit zu haben.
Rollen in den Regelwerken
In Regelwerken werden Aufgaben und Kompetenzen abstrakt an Rollen verteilt. In unterschiedlichen Verfahren können die selben Personen unterschiedliche Rollen inne haben.
Scrum kennt innerhalb des Regelwerks drei Rollen. Zunächst die Entwickler als Team von mindestens drei Personen, dann der Scrum Master und schließlich der Product Owner.[4] Die wesentlichen Personen außerhalb des Regelwerks sind die Key Stakeholder. Der Product Owner übersetzt die Anforderungen der Key Stakeholder in einen strukturierten Aufgabenvorrat, der Product-Backlog genannt wird.[5] Er priorisiert auch die Aufgaben, aber weist sie – anders als im klassischen Projektmanagement – nicht zu.
Der Scrum Master hat die Aufgabe, alle Hindernisse für die jeweiligen Aufgaben zu beseitigen, um die Produktivität des Teams zu fördern.[6] Die Lösungen können von der Vermittlung von Methodenkompetenz bis zur Beseitigung von Mängeln der Ausstattung reichen.
Das Entwicklungsteam ist eine Gruppe von drei bis neun Entwicklern, die die gesamte Fähigkeitenpalette für die gestellte Aufgabe mitbringen.[7] Innerhalb des Teams gibt es keine Hierarchie und das Team ist nach außen immer als Ganzes verantwortlich und zuständig.[8] Dementsprechend gibt es nur sehr wenige Regeln, wie das Entwicklungsteam arbeiten soll und keine Regeln, wie der einzelne Entwickler arbeiten soll.
Rollen im Zivilprozess
Im Zivilprozess gibt es Parteien (Kläger und Beklagter), die in der Regel durch Prozessbevollmächtigte vertreten werden.[9] Daneben gibt es das Gericht, das durch einen oder mehrere Richter Recht spricht. Dies geschieht auf Basis von Gesetzen, die der Gesetzgeber vorgibt.
Die Arbeit des Rechtsanwalts selbst, ist nach § 1 BORA frei, selbstbestimmt und unreglementiert, soweit Gesetz oder Berufsordnung ihn nicht besonders verpflichten. Er ist nach § 3 BRAO der berufene Vertreter in allen Rechtsfragen. Seine Aufgabe ist die Vertretung seiner Partei. Dabei ist er gleichzeitig Organ der Rechtspflege nach § 1 BRAO.
Die Freiheit der Richter ist sogar in Art. 97 I GG geregelt. Er ist gleichzeitig der Moderator und Entscheider des Verfahrens. Als Moderator hat er beispielsweise nach § 139 ZPO die materielle Prozessleitung inne, legt die Verfahrensweise nach § 272 ZPO fest und ordnet Maßnahmen zur Terminsvorbereitung nach § 273 ZPO an.
Vergleich der Rollen
Nun gibt es einen scheinbar grundlegenden Unterschied zwischen der Rollenausrichtung in beiden „Regelwerken“. Die Rollen im Zivilprozess sind auf ein kontradiktorisches Verfahren ausgelegt. Mit der Brille der Rechtspflege streiten jedoch beide Prozessvertreter für die „richtige“ Lösung. Aber auch innerhalb des Entwicklungsteams im Scrum kann es unterschiedliche Auffassungen geben, was die richtige Lösung ist. Gemeinsam haben beide Rahmenwerke die hohe Bedeutung der Selbstorganisation. Als Ausfluss der materiellen Prozessleitung hat der Richter ebenfalls die Aufgabe, Hindernisse zu beseitigen. Überträgt man die Scrum Rollen auf den Zivilprozess, so wäre der Richter in der Moderatorenrolle der Scrum Master, die Rechtsanwälte gemeinsam mit dem Richter in der Entscheiderrolle die Entwickler und der antragstellende Prozessbevollmächtigte der Product-Owner. Seine Partei wäre dann Key Stakeholder. Die Rolle des Richters fällt in diesem Zusammenhang jedoch aus dem Rahmen, da diese Rolle Elemente der beiden anderen Rollen hat. Dies hat zur Folge, dass die Moderation bereits mit Blick auf die Entscheidung geführt wird. Das spart Ressourcen, führt jedoch dazu, dass die Rechtsanwälte regelmäßig nicht alle Hindernisse offenlegen, was den Vorteil wieder kassieren kann. Interessant wäre auch darüber nachzudenken, wie man Transparenz auf Seiten der Anwälte belohnen könnte. Im Hinblick auf Zivilprozessordnung stellt sich die Frage, ob der Richter angesichts der Breite seiner Aufgabe überhaupt in der Lage sein kann, alle Aspekte seiner Rolle auszufüllen. Vielleicht wäre es hilfreich, wenn der Richter zumindest seine aktuelle Rolle offenlegen würde.
Ereignisse in den Regelwerken
Ein Regelwerk ist darauf ausgerichtet, ein gemeinsames Zusammenwirken zu ermöglichen. Dazu wird Ereignissen ein bestimmter Zweck zugewiesen. Ereignisse haben dabei immer eine temporale Komponente. Entweder handelt es sich um Zeiträume oder sie unterscheiden zwischen vor einem Zeitpunkt davor und danach.
Scrum kennt fünf Ereignisse. Der Sprint ist dabei der „Container“ mit einer Zeitdauer von maximal einem Monat, der sich ständig wiederholt und andere Ereignisse in sich aufnimmt.[10] Innerhalb dieses Containers gibt es Sprint-Planning, Daily Scrum, Sprint Review und Retrospektive.[11]
Beim Sprint-Planning werden die Anforderungen in kleinere Aufgabenpakete zerschnitten und notwendige Arbeitsschritte hinzugefügt. Dies ist das längste Meeting im Scrum.
Der Daily Scrum ist ein tägliches Meeting, bei dem sich das Entwicklerteam über den aktuellen Stand austauscht und Hindernisse weitergibt.
Beim Sprint-Review wird das Arbeitsstück des Sprints daraufhin betrachtet, ob es den Erwartungen entspricht.
Die Retrospektive schließlich ist ein Meeting, dass der Verbesserung der gemeinsamen Zusammenarbeit gewidmet wird.
Ereignisse im Zivilprozess
Auch der Zivilprozess kennt bestimmte Zeiträume und Termine, die eine wesentliche Bedeutung für das Verfahren haben.
Zunächst die Klageerhebung nach § 253 ZPO, ohne die das Verfahren nicht in Gang gesetzt wird.
Durch die Verteidigungsanzeige (bei schriftlichem Vorverfahren nach § 276 ZPO) und Klageerwiderung (§ 277 ZPO) erfolgt der Übergang in ein streitiges und aufwendigeres Verfahren.
Es folgt eine mündliche Verhandlung (§ 279 ZPO) ggf. mit Beweisaufnahme (§ 284 ZPO), soweit sich die Parteien nicht auf eine Entscheidung im schriftlichen Verfahren nach § 128 ZPO einigen.
Schließlich folgt die Urteilsverkündung auf die eine Rechtsmittelfrist folgt.[12] Das Urteil soll der unterlegenen Partei erklären, warum Sie verloren hat. Die obsiegende Partei hat abseits von „Musterverfahren“ im untechnischen Sinne regelmäßig kein besonderes Interesse an der Begründung.
Die Rechtsmittel und Rechtsbehelfe möchte ich als ein großes Überprüfungsereignis zusammenfassen, auch wenn dies die Sache etwas verkürzt. Hier sind mit wenigen Ausnahmen spätestens Rechtsanwälte involviert.
Vergleich der Ereignisse
Im Zivilprozess gibt es Ereignisse in Schriftform, wie die Zustellung der Klage. Scrum hat keine schriftlichen Ereignisse und ist auch nicht auf eine Verteilung des Teams an unterschiedlichen Orten ausgelegt. Dementsprechend ist der Inhalt der Ereignisse im Scrum auch weniger dokumentiert. Wobei an dieser Stelle darauf hingewiesen werden soll, dass der Vorrang von funktionierender Software vor Dokumentation[13] nicht die Abschaffung der Dokumentation bedeutet. Die Zivilprozessordnung wirkt darauf hin, dass der Rechtstreit durch einen einzigen Termin bearbeitet werden kann. Hier ist wiederum eine Gemeinsamkeit, weil beide Regelwerke darauf ausgerichtet sind, Besprechungen bzw. Termine auf ein Mindestmaß zu reduzieren. Die Zivilprozessordnung sieht jedoch nur wenige formalisierte Feedbackschleifen vor. Eine handwerkliche Überprüfung von Handlungen der Prozessvertreter erfolgt allenfalls in einem Verfahren der Anwaltshaftung. Qualitatives Feedback erhält aber auch der Richter nur durch Rechtsmittel und Rechtsbehelfe der Prozessparteien. Gelegentlich gibt es auch Feedback über Hinweise oder Schriftsätze, dies ist jedoch weder formalisiert noch strukturiert. Scrum hat mit den immerwährenden Schleifen der Sprints auch keinen Schlusspunkt. Das ist ebenfalls ein Unterschied zum Zivilprozess, dessen Urteil maßgeblich auch einen Schlussstrich unter die Streitigkeit ziehen soll. Die „Definition of Done“[14] im Scrum ist hingegen ausdrücklich flexibel. Die mündliche Verhandlung hat hingegen deutliche Ähnlichkeiten mit dem Review. Der Richter fasst den Sach- und Streitstand zusammen und sodann werden die noch offenen Punkte besprochen oder eben die Anträge gestellt, soweit die Sache entscheidungsreif ist. Dennoch bleiben die Optionen für Feedbackschleifen im Zivilprozess deutlich hinter den Möglichkeiten zurück. Das mag auch an der herrschenden Fehlerkultur in der Juristerei liegen.[15]
Artefakte in den Regelwerken
Schließlich lassen sich noch die Artefakte vergleichen. Artefakte sind bestimmte Arbeitsergebnisse des Scrum Teams.
Zum einen das Product-Backlog, das Sprint-Backlog und das Inkrement. Das Product-Backlog ist der Aufgabenvorrat für das gesamte Projekt. Das Sprint-Backlog ist der ausgewählte Teil, der in diesem „Sprint“ bearbeitet werden soll. Das Entwicklungsteam fertigt mindestens ein Inkrement pro Sprint. Dabei handelt es sich um ein fertiges Produktstück.
Im Zivilprozess liegt die Ausrichtung auf dem Fertigen von verfahrensbeendenden Schriftstücken. Hier wird aus dem Vortrag in Schriftsätzen und Terminsprotokoll – soweit das Verfahren streitig endet –ein Urteil.[16]
Im Zivilverfahren erfüllen die Anträge als besonderer Teil der Schriftsätze die Aufgabe des Product-Backlogs. Die Anträge bestimmten den Streitgegenstand und damit den Kern des Verfahrens.[17] Diese sind in Grenzen änderbar und geben damit Raum für einen Funken iteratives Vorgehen. Ein Sprint-Backlog, das bestimmte Aufgaben im Hinblick auf ein Produkt-Inkrement beschreibt, geht am ehesten in die Richtung eines Beweisbeschlusses, welcher zu einem Teilurteil führt. Die ZPO ist nach § 300 I ZPO auf die abschließende Beendigung ausgelegt und nicht auf ein inkrementelles (schrittweises) erreichen der Lösung. Insbesondere die Befriedungsfunktion eines Urteils würde durch echtes inkrementelles Vorgehen behindert. Diese Hinderung ist teilweise schon durch die vorhandenen Rechtsmittel spürbar.[18] So stellt sich die Lösung der Spannung bei einem rechtsmittelfähigen Urteil in der Regel noch nicht nach Verkündung des Urteils oder der Gründe ein, sondern erst wenn das Urteil „in Rechtskraft erwachsen“ ist.
Würden sich das Scrum-Regelwerk und das Regelwerk für den Zivilprozess verstehen, wenn man sie einander vorstellt? Sie hätten sicherlich übereinstimmende Einstellungen. Für beide Rahmenwerke ist der selbstbestimmte Entwickler zentral. Auf der Seite des Zivilrechts gilt dies für die Anwälte, aber auch für den Richter in der Entscheiderrolle. Beide Regelwerke haben außerdem das Ziel, zusätzliche Termine zu vermeiden. Beide mögen keine Verschwendung.
Unterschiedliche Sichtweisen haben die beiden jedoch darin, was sie von der Welt erwarten. Scrum strebt nach schleifenartiger und potentiell endloser Verbesserung. Ein Zivilprozess soll einen Schlussstrich unter eine Streitigkeit setzen. Auch der Richter hat eine sehr umfassende Rolle, die sich nicht ohne weiteres in die Scrum-Welt übertragen lässt. Hier besteht Raum für Missverständnisse.
Raum für Vertiefung besteht hinsichtlich der Frage, wie Anreize zur Transparenz in einem kontradiktorischen Verfahren gesetzt werden können. Sehr interessant ist ebenfalls, dass die Zivilprozessordnung einen „flexiblen“ Aufgabenvorrat in Form der Anträge anordnet und damit über 100 Jahre vor Scrum einen Ansatz für Agilität bereitstellt.
Ausblickend könnte der richtige Anwendungsbereich für Scrum, die anwaltliche Arbeit sein. Hier wären das Gericht und der Mandant die Stakeholder. Der Endpunkt wird extern durch den Richter bestimmt. Innerhalb der begrenzten Zeit, soll ein möglichst gutes Ergebnis aus den vorhandenen Ressourcen erzielt werden und innerhalb des Teams ist eine ständige Verbesserung der Arbeitsweise sehr erwünscht – zumindest, wenn nicht auf Stundenbasis abgerechnet wird. Das Anwaltsteam ist in einer ähnlichen Situation, wie das Scrum-Team. Inhaltlich ist der Mandant besser informiert. Das fachliche Wissen liegt jedoch fast ausschließlich auf der Teamseite. So kommen vom Mandanten immer wieder neue Sachverhaltsstücke. Nutzen muss das Produkt am Ende der Richter.
[1] Vgl. Brand JuS 2003, 1086f.
[2] Auer-Reinsdorff/Conrad § 11 Rn. 140, Wirdemann S.2.
[3] Saenger Rn. 22.
[4] Scrum Guide S. 6.
[6] Scrum Guide S. 7, Wirdemann S. 4.
[9] §§ 50, 253, 313 für die Partein, §§ 330, 331 für Bezeichnungen, §§ 78,79 für die Prozessbevollmächtigten.
[10] Scrum Guide S. 9.
[11] Scrum Guide S. 10 -14.
[12] §§ 310, 311, 313 für das Urteil, §§ 517, 548 für die Rechtmittel.
[13] Vgl. zum agilen Manifest Auer-Reinsdorff/Conrad § 11 Rn. 142.
[14] Scrum Guide S. 18.
[15] Zur Fehlerkultur vgl. Diel/Schanze AnwBl, 408.
[16] Vgl. § 313 ZPO.
[17] MüKO ZPO § 253 Rn. 66.
[18] Vgl. Trimbach, NJW 2009, 401ff.

References: § 1
 § 3
 § 1
 Art. 97
 § 139
 § 272
 § 273
 § 253
 § 276
 § 128
 § 300
 § 11
 § 11
 § 313
 § 253