Rechtsanwalt & Fachanwalt für gewerblichen Rechtsschutz
T (+49) 040 / 7344 086-0
Rechtsanwältin, Fachanwältin für Informationstechnologierecht & Zertifizierte Datenschutzbeauftragte (TÜV)
T (+49) 040 / 7344 086-0
Rechtsanwalt & Spezialist für IT-Recht und Kryptorecht
T (+49) 040 / 7344 086-0
Blog News
Scrum eine agile Herangehensweise an die Produktentwicklung. Besonders im Software-Bereich erfreut sie sich einiger Beliebtheit. Simpel ausgedrückt geht es darum, den Entwicklungsprozess in mehrere Phasen aufzuteilen. Auftraggeber und Auftragnehmer treffen sich während des sog. Sprints in regelmäßigen Abständen. So gibt es stets Möglichkeiten, Feedback zum Entwicklungsstand zu erhalten, um die nächste Phase anzupassen. Allerdings gibt es offene Fragen zu der vertraglichen Ausgestaltung dieses Modells.
Das bereits angesprochene Scrum-Modell ist natürlich nicht die einzige Möglichkeit, eine Software zu entwickeln. Als weiteres Beispiel ist das sog. Wasserfall-Modell zu nennen. Dieses teilt die Projektentwicklung in seiner einfachsten Form in vier Phasen auf. Als erstes werden die Anforderungen definiert. Danach wird die Software designed und implementiert. Ist das geschafft, kann sie getestet werden.
Wie man schnell merkt, ist dieses Modell recht pauschal. Darum gilt es heutzutage auch als veraltet. Demgegenüber bietet das Scrum-Modell deutlich mehr Flexibilität. Das ist auch notwendig, denn Softwareentwicklung gestaltet sich regelmäßig komplex. Welche Probleme und Hürden während eines Projekts auftauchen werden, lässt sich anfangs unmöglich sagen. Darum sollte ein Modell auch so agil wie möglich sein.
Durch die verschiedenen Phasen in der Entwicklung soll das Scrum-Modell eine solche agile Alternative darstellen. Der Gedanke ist, dass man flexibel auf Probleme reagieren kann. So arbeitet man sich Schritt für Schritt vorwärts, bis das erwünschte Ergebnis erreicht ist.
Seinen Namen erhielt Scrum aus dem amerikanischen Football. Dort (und natürlich auch in anderen Sportarten) bereiten sich Teams auf ihre Spiele vor, indem sie durch regelmäßige Analyse ihrer bisherigen Fehler neue Fortschritte machen.
Zu Beginn wird ein sog. Product Backlog erstellt. Hierin werden für das Entwicklungsteam die wichtigsten Arbeitsschritte festgehalten. Deshalb wird der Product Backlog auch von dem Product Owner (regelmäßig dem Auftraggeber) erstellt. An ihn kann sich das Team also halten, sodass es den weiteren Weg und die Ziele stets vor Augen hat.
Sodann wird ein Sprint Backlog erstellt. Das ist ein genauerer Ablaufplan für die erste Entwicklungsphase, also den ersten Sprint. Er schreibt also vor, was das Team bis zur nächsten Besprechung zu tun hat. Was genau darin steht, bespricht der Product Owner direkt mit dem Entwicklerteam. So wissen alle, was auf sie zukommt.
Nun beginnt die erste Sprint-Phase. Hier arbeitet das Entwicklerteam an der Software und versucht, den ersten Teil des Product Backlogs umzusetzen. In der Regel dauert diese Phase zwei bis vier Wochen. Daily Scrums bilden tägliche Besprechungen, in denen das Team zusammenkommt und die jeweiligen Fortschritte zusammenträgt. Regelmäßige Kommunikation ist also ein Kernpfeiler des Scrum-Modells.
Ist die erste Sprint-Phase vorbei, setzt sich das Team wieder mit dem Product Owner zusammen. Dieser letzte Schritt im Zyklus wird Sprint Retrospective genannt. Wie der Name nahelegt, reflektiert das Team hier über den Sprint. Es wird zusammengetragen, was sich gut umsetzen ließ und wo Probleme aufgekommen sind. Ist alles besprochen, wird der nächste Sprint Backlog angefertigt und der Zyklus beginnt erneut. Dieser agile Prozess setzt sich so lange fort, bis die fertige Software entwickelt ist oder das Projekt abgebrochen wird.
Laut Erfahrungsberichten ist es am besten, wenn der Product Owner auch der Auftraggeber ist. Fallen diese Rollen auf verschiedene Personen, erschwert das die Kommunikation im Laufe des Entwicklungsprozesses. Insbesondere, da bei jedem zweiten Projekt die Anforderungen an ein Produkt während der Entwicklungsphase angepasst werden.
Zwar ist es für viele Product Owner anfangs schwer, eng in das Projekt eingebunden zu sein. Von ihnen wird ja auch erwartet, gemeinsam mit dem Team über die Sprints zu reflektieren. Nach einigen Sprints wachsen sie jedoch in die Rolle hinein und erkennen den Wert eines solchen Entwicklungsmodells.
Nun stellt sich jedoch die Frage, wie solch ein Prozess vertraglich einzuordnen ist. Selbstverständlich muss immer ein Vertrag bestehen, damit beide Parteien im Streitfall ihre Rechte und Pflichten möglichst klar und objektiv festgelegt haben.
Als erste Möglichkeit liegt nahe, einen Scrum-Vertrag an den zivilrechtlich bekannten Werkvertrag anzupassen.
(1) Durch den Werkvertrag wird der Unternehmer zur Herstellung des versprochenen Werkes, der Besteller zur Entrichtung der vereinbarten Vergütung verpflichtet.
(2) Gegenstand des Werkvertrags kann sowohl die Herstellung oder Veränderung einer Sache als auch ein anderer durch Arbeit oder Dienstleistung herbeizuführender Erfolg sein.
Beim Werkvertrag ist wichtig, dass ein fester Erfolg versprochen wird, welcher dann vom Unternehmer gegen Vergütung hergestellt werden soll. Der Besteller nimmt schlussendlich das fertige Werk ab. Grundsätzlich erhält der Unternehmer sein Geld also erst bei der Abnahme des fertigen Produktes.
Für Scrum als Werkvertrag ist problematisch, dass ein genaues Ergebnis vorgeschrieben werden muss. Und zwar von Anfang an, sodass bei der Abnahme nur geschaut wird, ob es erreicht wurde. Wie oben festgestellt, sollte der Prozess jedoch auf agile Weise gestaltet sein. Und je lockerer das zu erreichende Ergebnis formuliert wird, desto eher wird der Auftraggeber rechtlich verpflichtet sein, es abzunehmen – auch dann, wenn es ihm eigentlich nicht gefällt. Außerdem sieht der Werkvertrag das Erfolgsrisiko allein bei dem Auftragnehmer. Bei Scrum jedoch hat der Auftraggeber ebenfalls wesentlichen Einfluss auf den Lauf des Projekts.
Die zweite Möglichkeit wäre, Scrum als Dienstvertrag zu regeln.
(1) Durch den Dienstvertrag wird derjenige, welcher Dienste zusagt, zur Leistung der versprochenen Dienste, der andere Teil zur Gewährung der vereinbarten Vergütung verpflichtet.
(2) Gegenstand des Dienstvertrags können Dienste jeder Art sein.
Der Dienstvertrag unterscheidet sich vom Werkvertrag maßgeblich dadurch, dass hier eben kein festes Ergebnis vorgeschrieben wird. Geschuldet wird stattdessen lediglich die Erbringung einer durchschnittlich guten Leistung. Hier müsste der Auftraggeber zahlen, und zwar unabhängig davon, ob das von ihm erwünschte Softwareprogramm tatsächlich entsteht.
Teilweise wird es als optimale Lösung gesehen, einen Dienstvertrag mit Festpreis zu vereinbaren. Vor allem, wenn zwischen Auftraggeber und Auftragnehmer ein gutes Verhältnis besteht, kann ein Dienstvertrag sinnvoll sein. Ansonsten besteht jedoch das Risiko, dass der Auftraggeber vertraglich keine Erreichung des Ziels festgelegt hat.
Am besten sollte also keine starre Kategorisierung vorgenommen werden. Stattdessen kann man sich genau die Elemente des Werk- oder Dienstvertrags herausnehmen, die auf das konkrete Projekt passen.
Je genauer sich vorschreiben lässt, wie das fertige Ergebnis aussehen soll, desto näher kann man sich am Werkvertrag orientieren. Und die Projektplanungsphasen, z. B. die Sprintplanung, können eher dienstvertraglich ausgestaltet sein. So lässt sich das Ziel erreichen, eine agile Arbeitsweise beizubehalten und trotzdem vertraglich bestmöglich abgesichert zu sein.
Irgendwann muss jedoch auch objektiv festgestellt werden können, wann das Projektziel erreicht ist. Beim Werkvertrag spielt die Abnahme eine zentrale Rolle, denn hier gehen die Haftungspflichten vom Auftragnehmer auf den Auftraggeber über. Häufig stellt genau dieser Akt auch den Kernpunkt eines Rechtsstreits dar.
Darum sollten möglichst genaue Kriterien für die Abnahme festgelegt werden. Zusätzlich gibt auch die Option, Teilabnahmen durchzuführen. So können bestimmte Teile des Projekts für sich genommen abgenommen werden, sobald sie den Anforderungen entsprechen. In den kommenden Zyklen kann dann an den noch verbesserungsbedürftigen Teilen gearbeitet werden.
Was in der Theorie logisch klingt, kann in der Praxis schwierig sein. Bspw. nach dem ersten Sprint ist es häufig nur schwer absehbar, welche Projektteile wirklich schon abnahmebereit sind. Da sich das Projekt im Laufe des Scrum stetig weiterentwickeln wird, bilden Teilabnahmen also das Risiko, dass der abgenommene Teil letztendlich doch nicht gewollt war. Das ist jedoch eine notwendige Nebenfolge der agilen Arbeitsweise. Teilabnahmen sollten also nicht übermäßig eingesetzt werden.
Das Scrum-Modell bietet eine neue Perspektive auf den Umgang mit Mängeln. Das Zivilrecht sieht im Mängelgewährleistungsrecht grundsätzlich vor, dass Mängel nach einem Vertragsschluss zu Ansprüchen der Gegenpartei führen. Bei Scrum ist es jedoch so, dass nicht jeder Fehler direkt einen „Produktmangel“ darstellt, der rechtlich verfolgt werden sollte. Stattdessen dient gerade die Sprint Retrospective dazu, über Fehler zu reflektieren und den nächsten Sprint dahingehend anzupassen.
Es ist für Auftraggeber bzw. Product Owner also ratsam, sich auf den Prozess einzulassen. Statt zu früh Mängelgewährleistungsrechte geltend zu machen, sollten sie lieber aktiven Einfluss auf das Projekt nehmen und die Phasen zur Reflektion gut nutzen. So wird das volle Potenzial des Scrum-Modells optimal verwirklicht.
Rechtliche Verhältnisse werden häufig durch Verträge ausgestaltet. Das hat viele Vorteile, wie etwa eine Warnfunktion oder eine Beweisfunktion. Im Einzelnen kann die vertragliche Ausgestaltung jedoch rechtliche Herausforderungen begründen. SBS LEGAL hilft Ihnen dabei, sicher zu navigieren und sich konform zu jeglichen Vorschriften zu verhalten. So riskieren Sie nicht, unangemessen benachteiligt zu werden oder unwirksame Verträge abzuschließen.
Sie brauchen eine Beratung im Vertragsrecht oder einen Vertragsrechtsanwalt, etwa für das sichere Gestalten des Scrum-Modells für eine Projektentwicklung? Dann sind Sie bei uns richtig.