Agiles Arbeiten Vs. Schwerfälliges Denken

Die risikoaverse Juristerei und die freigeistige IT ?

Kan Ban, Scrum, XP, Design Thinking, ITIL4, Stakeholder-Orientierung.

Diese Buzzwords haben alle eines gemein. Sie entspringen den Gedanken und Anschauungen der „freigeistigen“ IT-Welt. Eine IT-Welt die nach mehr Agilität lechzt.

Für einen Außenstehenden mag dieses für agile Projekte typische tägliche hin- und her im Team und mit den Kunden, wie bei einer „Tischtennis-Olympiade“, befremdlich vorkommen. Dabei hat sich die agile Herangehensweise längst nicht nur in der IT-Branche etabliert, sondern verbreitet sich wie ein Lauffeuer auf alle anderen Branchen.

Um Projekte erfolgreich und rechtssicher zu gestalten, kann es daher hilfreich sein, sich den Mechanismus eines agilen Projektes zu vergegenwärtigen und in einen ITler hineinzuversetzen.

Die Phänomenologie des freigeistigen Informatikers

Permanente Change Requests des Kunden und plötzlich auftretende Komplikationen in der Softwarentwicklung zwingen den ITler von seiner bisherigen unflexiblen Ablaufstruktur, der starren und hierarchischen Arbeitsweise (sog. Wasserfall-Modell) auf eine Arbeitsweise umzusteigen, die sich neudeutsch agil nennt.

Die Agile Methode ist eine spezielle Herangehensweise, bei der in kurzen Iterationen (von wenigen Wochen), in kurzen inkrementellen Abfolgen und mit kleinen selbstbestimmten Teams, step by step (sog. Sprints) kleine Teilerfolge gefeiert werden, um funktionierende Zwischenergebnisse zu produzieren, die ihrerseits Ausgangspunkt für weitere Entwicklungszyklen darstellen. Aus den konkreten Produktvorstellungen des Wasserfall-Modells werden sogenannte Produkt- oder Servicevisionen.

Agiles Arbeiten ist so gesehen die Arbeit an einem lebenden Objekt. Schnelles Feedback vom Kunden, effiziente Fehlererkennung und schnelle Revisionen stehen an der Tagesordnung.

Das transformative und gleichzeitig emanzipative Potenzial liegt in den kleinen Teams, die sich in kleinen Arbeitsschritten und in kurzen Zeiträumen, – ohne Abteilungsleiter – fast „kybernetisch“ selbst verwalten und eigenständige Entscheidungen treffen sollen. Quasi ein Unternehmen im Unternehmen.

Übergeordnetes Ziel des agilen Arbeitens ist die Erzeugung eines dauerhaften kreativen Prozesses.

Im Manifest der agilen Methode werden die Zielvorstellungen wie folgt statuiert (https://agilemanifesto.org/):

Individuen und Interaktionen mehr als Prozesse und Werkzeuge,
Funktionierende Software mehr als umfassende Dokumentation,
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung,
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Versuch und Irrtum – Fail Fast-Kultur

„Bei der Eroberung des Weltraums sind zwei Probleme zu lösen: die Schwerkraft und der Papierkrieg. Mit der Schwerkraft wären wir fertig geworden.“ (Wernher von Braun)

Agile Projekte sind ergebnisoffen und geben dem „freigeistigen“ ITler oder seinem Team die Möglichkeit sich selbst zu organisieren. Auch wird einem üblicherweise keine Deadline gesetzt und somit kein Druck aufgebaut. Der ITler ist in einem laufenden Projekt, gewissermaßen „sein eigener Chef“. Es entstehen innerhalb eines Unternehmens in gewisser Weise, kleine selbstorganisierte Einheiten, die wiederum wie kleine Unternehmen funktionieren und handeln können.

Dementsprechend wird auch gar nicht erst versucht die vertragliche Leistung en Detail zu erfassen. Denn diese entwickelt sich erst im Laufe des Projekts. Am Anfang steht nur eine übergeordnete Produkt-/ oder Servicevision.

Dieses Vorgehen basiert auf dem Prinzip von „Versuch und Irrtum“. Strikte Pläne mit immensen Steuerungsaufwand, Spezifikationen, hartkonturierte Festlegungen, technische Vorgaben, aber auch anderweitige Abhängigkeiten innerhalb des Unternehmens wirken wie schwerfällige Reglementierungen und Innovationshemmer. Der ITler schafft sich diese „Innovationshemmer“ vom Leib. Honoriert wird nun vielmehr seine freischaffende Leistung. Er folgt von nun an dem Prinzip: Wer versucht und irrt, der lernt daraus; gewinnt neue Erkenntnisse und kann neue Wege einschlagen. Die agile Methode schafft dem ITler so gesehen mehr Raum für freies Denken und erhofft sich hierdurch mehr Innovationen und eine gesteigerte Produktivitätsrate.

Risikophobie des Juristen und Kontrollverlust

Aus „Kontrolle“ wird Steuerung, aus Resultaten werden Ziele und Visionen. (Ich frage mich wer bei Visionen auch immer an Helmut Schmidt denken muss)

Für einen Juristen kommt das Prinzip von „Versuch und Irrtum“ einem Kontrollverlust gleich. Juristen handeln naturgemäß risikoavers. Und das nicht zu Unrecht! Schließlich sind Juristen dazu da, um vor rechtswidrigen Entscheidungen und Risiken zu warnen.

Problematisch wird es, wenn die Weitsichtigkeit des Juristen in eine Risikophobie umschlägt. Agile Projekte sind nun mal von der Wiege bis zur Bahre ein riskantes und in gewisser Weise unkontrollierbares Unterfangen. Risiken lassen sich hier nicht in Gänze eindämmen oder gar abschalten. Der Jurist muss sich einen holistischen Eindruck vom Gesamten schaffen, um dann angemessen zu agieren.

Expertenkontrolle

Eine weitere fundamentale Losung des agilen Arbeitens lautet: Power to the Entwicklungsteam. Das Management wird verdrängt durch ein selbstständig agierendes Team. Um es in den Worten von J.W. von Goethe auszudrücken: „Alle Männer vom Fach sind darin sehr übel dran, daß ihnen nicht erlaubt ist, das Unnütze zu ignorieren.“

Ziel ist es also die Entscheidungskontrolle von der höchsten Etage runter auf die Kenner, das Entwicklungsteam, zu bringen. Damit wird letztlich das erstellt, was wirklich vom Kunden gebraucht wird und nicht das was ursprünglich geplant wurde.

Kooperation und Interaktion

Der Umgang mit den Kunden ist sehr eng und kooperativ ausgestaltet. Man umarmt den Kunden quasi mit all seinen innovativen Ideen, ohne weiterhin die konkrete Leistung festzulegen. Zudem wird der Kunde regelmäßig als sog. Stakeholder in den ganzen Prozessablauf mit eingebunden.Er bewertet stetig die Resultate und bringt eigene Ideen mit ein. Dadurch fühlt der Kunde sich wertgeschätzt und als Teil des Ganzen.

Die juristische Kehrseite: Hierdurch entstehen beim Auftraggeber offensichtlich vermehrt Mitwirkungspflichten. Der Auftraggeber ist nun nicht mehr als Außenstehender zu betrachten, sondern bedarf, um seine Mitwirkungspflichten in Gänze zu erfüllen, auch Beschäftigte, die über das nötige Knowhow verfügen. Beschäftigte des Auftraggebers, die ohne Absprache eigenständige Konfigurationen vornehmen oder eine Software in Gänze nicht nachvollziehen können, tragen auch oftmals ihren Anteil bei gescheiterten Projekten und könnten in der rechtlichen Bewertung eine Rolle spielen.

Da kribbelts´ dem Juristen unter den Fingern

Möglichst viel Freiheit für den ITler = Innovation und größtmöglicher Nutzen für den Kunden?Da kribbelts beim Juristen unter den Fingern. Da würde der Jurist nur zu gerne einen Vertrag auflegen und alles bis ins Detail regeln um seinen Mandanten vor diesem „agilen Kontrollverlust“ zu bewahren. Denn prinzipiell gilt: Was vertraglich nicht vereinbart wurde, da kommt das Gesetz zur Anwendung.

Aber vorbei sind die Zeiten, in denen Verträge mit starren Formen und strikten Parametern für maximale Rechtssicherheit gesorgt haben. Um nicht als Störfaktor wahrgenommen zu werden, müssen sich Juristen daher künftig auf den Zeitgeist einlassen und diesen neuen Regelmechanismus zunächst einmal anerkennen. Den Regelmechanismus anerkennen bedeutet, dass das Primat der starren Ordnungs- und Trennungsprinzipien auf den Primat der kooperativen Bindung zwischen Auftraggeber und Auftragnehmer übergeht. Der Schwerpunkt der juristischen Arbeit liegt bei der möglichst genauen, aber nicht zu genauen, Beschreibung der Leistung. Hierfür müssen Juristen ein Gespür entwickeln.

Je nach Szenario und je nach Interessenlage könnte man beispielhaft folgendes regeln:

die Beschreibung von erwarteten Resultaten hinsichtlich der Funktionalität,
die Konkretisierung der Produktvision,
die Definition der Scrumbestimmungen wie Product-Backlog, Spring Backlog, Definition of Done, Epics und Themes
die Regelung der Ressourcenallokation (Wie ist umzugehen, wenn mehr Experten benötigt werden?)
Prozessmanagement
die Regelung eines Zahlungsplans nach Sprints,
die Regelung von Zwischen- und Endabnahmen,
die Regelung eines Meetingzyklus und der Geltung des Besprochenen,
die Festlegung von Mitwirkungspflichten,
die Form und der Zeitpunkt von Dokumentationspflichten,
die Regelung von Preisabweichungen,
die Festlegung eines Streitschlichtungsmechanismus,
das Vorgehen bei einer Insolvenz (Hinterlegungsklauseln)

All diese Regelungen und Weitere können je nach Fall dabei dienlich sein die Eskalation eines Projektes zu verhindern, ohne dabei in das grazile Uhrwerk der agilen Methode erheblich einzugreifen.

Vor Gericht auf hoher See

2016 qualifizierte das LG Wiesbaden mangels unterzeichneten Vertrages, die Erstellung einer Onlineplattform mit agiler Vorgehensweise als Werkvertrag. Begründet wurde dies damit unteranderem, dass ungeachtet der Anwendung der ergebnisoffenen agilen Methode, ein konkretes Resultat anvisiert wurde und der Auftragnehmer für die Durchführung des Projektes faktisch verantwortlich war. (LG Wiesbaden, 30.11.2016 – 11 O 10/15). Der Werklohnanspruch der Auftragnehmerin scheitert dann daran, dass nach der Einholung des schriftlichen Sachverständigengutachtens zur Überzeugung des Gerichts feststand, dass die von ihr erbrachten Teilleistungen mangels einer hinreichenden Dokumentation für den Auftraggeber unbrauchbar und damit letztlich wertlos waren.

Dieses Urteil zeigt zum einen, dass das LG Wiesbaden den Sinn von agilen Projekten noch nicht ganz durchdrungen hat und dadurch eine Kette in Gang gesetzt hat, die die Ansprüche eines Auftragnehmers fortwährend gefährden könnten. Glücklicherweise hat das OLG Frankfurt die Entscheidung des LG Wiesbaden aufgehoben (OLG Frankfurt/M., Urteil vom 17.8.2017 – 5 U 152/16). Allerdings entschied auch das OLG nicht hinsichtlich des Vertragstypus.

Entscheidungen wie die des LG Wiesbaden zeigen auf, dass im Widerstreit zwischen Agilität und eindeutigen Bestimmungen, in wichtigen Frage den eindeutigen Bestimmungen der Vorzug zu gewähren ist. Ansonsten entscheidet im Zweifel ein Gericht mit fehlender IT-Kompetenz oder wie heißt es so schön „vor Gericht und auf hoher See ist man in Gottes Hand“.

Wenn zwei Welten aufeinander prallen

Da möchte der Informatiker ein Beispiel aus seinem alltäglichen Leben aufzeigen. Aktuell hat er mit einem Anwalt zu tun. Nun schrieb er dem Anwalt tatsächlich (wie kann er es nur wagen) täglich eine Mail. Natürlich war er nicht so blauäugig, um zu erwarten, dass sich seine Angelegenheit von heute auf morgen lösen würde. Seine Nachfrage basiert vielmehr darauf, dass bestimmte Daten angefordert wurden. Deshalb schlug er auch direkt einen „Call“ vor. Daraufhin meinte der Anwalt nur: „Mein Lieber wir sind nicht bei dir in deiner agilen Projektwelt.“

Ende der Geschichte!

Weitere Beispiele:

Beispiel 1: Wenn die IT-Abteilung einer Bank aufgrund diverser Gesetzesveränderungen bzgl. technischer Standards wie die MaRisk (Mindestanforderungen an das Risikomanagement) juristische Hilfestellung bedarf, dann müssen sich Juristen künftig in das agile Gehege zurecht finden. Die IT muss immer up-to-date bleiben und die Juristen dürfen nicht hinterherdackeln.

Beispiel 2: Wenn das Entwicklerteam dem Juristen/der Juristin eine MVP (minimum viable product – Vorprodukt zum Vorzeigen beim Kunden) vorstellt, dann muss sich der Jurist schnell in die Produktvision einfinden und die Weiterentwicklung mit dem Entwicklerteam mitdenken, um eine juristische Empfehlung abzugeben.