von Franziska Jandl
Bei agiler Softwareentwicklung bewegen sich Juristen im Spannungsfeld zwischen Risikominimierung und dem Wunsch nach Beschleunigung. Rechtsabteilungen profitieren, wenn sie die neuen Arbeitsmethoden selbst nutzen.
Das Wichtigste in Kürze
Die Vertragsgestaltung ist bei agiler Softwareentwicklung weiterhin anspruchsvoll.
Klippen lassen sich umschifffen, wenn Juristen sich eng mit Technikern austauschen und die Entwicklungsteams proaktiv dafür sensibilisieren, dass Compliance-Themen entscheidend zum Erfolg der Projekte beitragen.
Rechtsabteilungen, die sich die Erfahrungen aus der agilen Softwareentwicklung zu Nutze machen, profilieren sich als Business Partner für die digitale Transformation.
Statt einer Leistungsbeschreibung mit festen Abnahmekriterien steht noch gar nicht im Detail fest, wie das Ergebnis aussehen soll. Es soll aber sofort losgehen und nicht erst nach langen Vertragsverhandlungen. Was nach einem Albtraum für Juristen klingt, hat sich in der Praxis vielfach bewährt: „Die Entwicklung von Software wird durch agile Methoden in der Regel deutlich schneller, flexibler und kostengünstiger. Die Standish Group hat schon 2012 festgestellt, dass Projekte mit der Scrum-Methode dreimal so häufig erfolgreich enden wie traditionelle Projekte“, berichtet Dr. Peter Schichl, Chief Legal Tech Officer und Head of Legal Services Technology & Procurement bei der Deutschen Telekom in Bonn.
Viele Projekte sind zu komplex, um in vollem Umfang zu planen
Die Vorgehensweise nach Srum oder Kanban unterscheidet sich von der klassischen Wasserfallmethodik, weil der Projektplan ständig hinsichtlich Zeiten, Aktionen, Funktionen, Budgets und Beteiligten angepasst wird. Dies beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um sie in vollem Umfang zu planen. Ein wesentlicher Teil der Anforderungen und der Lösungsansätze ist zunächst unklar. Diese Unklarheit wird beseitigt, indem Zwischenergebnisse geschaffen werden. Fehlende Anforderungen und Lösungstechniken lassen sich so effizienter finden als durch eine abstrakte Klärungsphase.
Nicht nur das Produkt wird iterativ und inkrementell entwickelt, sondern auch die Planung: Der langfristige Plan, das Product Backlog, wird kontinuierlich verfeinert und verbessert. Der Detailplan (Sprint Backlog) wird nur für den jeweils nächsten Zyklus (Sprint) erstellt. Dadurch fokussiert sich die Projektplanung auf das Wesentliche. Es gibt keinen Projektleiter oder Manager, sondern eine Gruppe gleichgestellter Entwickler auf Augenhöhe mit dem Product Owner als Produktverantwortlichem und Schnittstelle zum Kunden sowie dem Scrum Master als Coach und Unterstützer. Alle Teammitglieder arbeiten auf Basis des agilen Manifests zusammen.

„Syndizi sollten sich mit dem Srum-Master zusammensetzen, um die Grundsätze der agilen Softwareentwicklung zu verstehen. Nur wer Werte, Prinzipien, Methoden und Prozesse nachvollzieht, kann sie in Verträge umsetzen.“
– Dr. Peter Schichl, Chief Legal Tech Officer und Head of Legal Services Technology & Procurement bei der Deutschen Telekom
Agile Methoden sind fast immer von Vorteil
Erfolgversprechend ist agile Softwareentwicklung immer dann, wenn sich eine Software in zahlreiche realisierbare Teilziele zerlegen lässt, also in verschiedene Funktionen oder Features. „Das ist fast immer der Fall und auch bei der Entwicklung von Legal-Tech-Anwendungen spricht nichts gegen den Einsatz agiler Methoden, selbst wenn Datenschutz- und Sicherheitsanforderungen im Zweifel höher sind“, weiß Peter Schichl als Chief Legal Tech Officer bei der Deutschen Telekom. Allerdings ist besondere Vorsicht geboten bei Software mit hohen Sicherheitsanforderungen, aber auch bei hohen wirtschaftlichen Risiken etwa hinsichtlich des geistigen Eigentums sowie im Bereich gesteigerter Sorgfaltsmaßstäbe bei Datenschutz- und Vertraulichkeit gegenüber Kunden und Partnern. „In diesen Spannungsfeldern kann der hohe Standard an Sicherheitschecks die Dynamik des Projekts verlangsamen“, ergänzt Bernhard Fischer, Chief IP Attorney bei SAP in Walldorf.
Black Box durch Abkehr vom Lasten- und Pflichtenheft
Doch die hohe Dynamik birgt juristische Fallstricke: „Um Haftungsrisiken zu minimieren, kann man bei der Beschreibung des gewollten Produkts grundsätzlich nicht genau genug sein“, so die Erfahrung von Peter Schichl. Die Abkehr vom klassischen Lasten- oder Pflichtenheft bei agilen Projekten führt dazu, dass unklare Leistungsbeschreibungen oder ungenaue Roadmaps als Fahrplan für die gezielte Weiterentwicklung zu den größten Schwierigkeiten und Herausforderungen für Syndizi in agilen Projekten zählen.
Einzelne Sprints lassen sich als Werkverträge ausgestalten
„In den Griff bekommen lässt sich das am Besten mit einem Hauptvertrag und projektspezifischen Anhängen für abnahmefähige Teilleistungen“, rät Schichl. Trotz Zeitdrucks und Unklarheiten sei in den Anhängen zu beschreiben, was mit welchen Spezifikationen zu liefern ist: etwa im Hinblick auf Leistungsfähigkeit, Kompatibilität und Sicherheit. Damit diese Anforderungen nicht doch in ein Lasten- und Pflichtenheft mutieren, soll diese Übersicht über alle Elemente des zu entwicklenden Produkts keinen Anspruch auf vollständige Durchplanung der Teilleistungen formulieren. Stattdessen soll sie eine Richtschnur sein für die Ausgangsschätzung der Anforderungen: „Die Abnahmekriterien und Nutzeranforderungen wie Schnittstellen und Übergabekriterien sollten soweit konkretisiert sein, dass sie als Benchmark für das Ergebnis des letzten Sprints dienen können. Dann ist es egal, was vorher in der Black Box passiert“, erklärt Peter Schichl.
Oft bereitet auch mangelhafte Kontrolle über die Sprints zum nächsten Teilziel Probleme oder unflexible Verträge, die nicht die Realität der Entwicklung widerspiegeln. Schichl rät deshalb, dass Auftraggeber und Entwickler regelmäßig Kontakt halten. So lässt sich zum einen Transparenz schaffen über den Fortschritt oder Hemmnisse des Projekts. Außerdem lassen sich Funktionalitäten prüfen und gegegebenenfalls anpassen.
Drei Prinzipien, um Komplexität und Unklarheit zu durchbrechen:
- Transparenz: Projektfortschritt, Risiken und Hemmnisse in kurzen Zeitabständen für alle Beteiligten dokumentieren.
- Kontrolle: Regelmäßig Funktionalitäten implementieren, testen, beurteilen und dokumentieren.
- Anpassung: ständige Neubewertung und gegebenenfalls Änderung der Anforderungskriterien.
Syndizi dürfen Dynamik nicht ausbremsen
Um im Spannungsfeld zwischen rechtlichen Anforderungen und der Dynamik agiler Entwicklung nicht als Bremser wahrgenommen zu werden, müssen Syndizi den engen Austausch mit Technikern und Entwicklern suchen und sich an deren Bedürfnissen orientieren: „Sie sollten sich mit dem Scrum Master zusammensetzen, um das Vorgehen bei agiler Softwareentwicklung nachzuvollziehen. Nur wer Methoden und Prozesse versteht, kann sie in Verträge umsetzen“, so die Erfahrung von Peter Schichl. Ansonsten sei man in der Praxis schnell überfordert, beispielsweise bei der Abgrenzung: „Was ist noch Gewährleistung, was schon Weiterentwicklung?“ Denn wenn das Projekt erst läuft, werden neue Anforderungen und Gewährleistungsansprüche häufig vermischt.
Das Gespräch mit Technikern eröffnet laut SAP-Jurist Fischer oft auch, dass ein juristisches Problem, über das in den Vertragsverhandlungen heftig diskutiert wird, gar keine Praxisrelevanz hat: „Die Diskussionen sind oft sehr theoretisch. Immer wieder stellt sich heraus, dass zunächst umkämpfte Klauseln im Einzelfall keine gesteigerte Bedeutung haben.“

„Juristen müssen sich flexibel zeigen und an die Bedürfnisse der Entwickler anpassen. Proaktive Aufklärung zu rechtlichen Belangen und Stolpersteinen wird dankbar aufgenommen.“
– Bernhard Fischer, Chief IP Attorney SAP SE Walldorf
Um ein Bewusstsein für Balance zwischen beschleunigter Entwicklung und Risikominimierung zu schaffen, rät Fischer, die Entwickler proaktiv durch Schulungen über juristische Belange und Fallstricke aufzuklären: “Das wird dankbar aufgegriffen“, so seine Erfahrung. Schließlich wird dadurch nicht nur über mögliche Risiken und Konsequenzen aufgeklärt, sondern die Handhabung der Prozesse in Rechtsbereichen für alle Beteiligten im Unternehmen vereinfacht.
Rechtsabteilungen werden selbst agil
Ursprünglich erarbeitet wurde agiles Projektmanagement für die Softwareentwicklung. Inzwischen untersuchen immer mehr Unternehmensbereiche, wie sie die Methoden nutzen können, um die digitale Transformation voranzutreiben, die in der Schnittmenge von unklaren Zielen und Lösungswegen stattfindet. Auch Rechtsabteilungen arbeiten zunehmend agil und schaffen Strukturen, um Prozesse bei komplexen, interdisziplinären Fragen zu beschleunigen. „Juristen müssen sich anpassen und Hierarchien aufweichen, damit sich niemand hinter Zuständigkeiten verstecken kann. Jeder muss selbst Initiative zeigen“, empfiehlt SAP-Jurist Fischer, der schon seit vielen Jahren Erfahrung mit agilen Methoden gesammelt hat. Um Abläufe zu beschleunigen hat er beispielsweise seinen Arbeitsplatz direkt in die Entwicklungsabteilung verlegt.
Manifest für Agile Softwareentwicklung
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
- 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
Das heißt, obwohl wir die rot markierten Werte wichtig finden, schätzen wir die anderen Werte höher ein.
Quelle: www.agilemanifesto.org
Bilder des Artikels: Post-Board: ©iStock.com/anathomy
Leave a Comment