Scrum ist die agile Methode, die am weitesten verbreitet ist. Das jedenfalls ergibt sich erneut aus der renommierten Studie „Status-quo-agile 2016/2017″ von Prof. Dr. Ayelt Komus. 85% der Studienteilnehmer nutzen Scrum.
Nach dem Agilen Manifest sind Vertragsverhandlungen wichtig. Aber die die Zusammenarbeit mit dem Kunden ist wichtiger. Und das ist auch für mich als Jurist völlig in Ordnung. Denn so hilfreich ein guter Projektvertrag für den Projekterfolg auch sein mag, er erledigt keine Arbeitspakete.
Es gibt dennoch ein paar Punkte die Projektleiter, Business Owner und Einkäufer bei der Verhandlung und Gestaltung von Scrum-Projekt-Verträgen beachten sollten.
Scope und Preis des Projektes
Je länger ein Projekt dauert, desto stärker ändert sich der Scope des Projektes und damit der Leistungsgegenstand des Vertrages.
Die Gründe dafür sind so vielschichtig wie die Faktoren, die Einfluss auf ein Projekt haben. Sie reichen von kranken Mitarbeitern über Schlüsselfiguren mit Kopfmonopolen, die aus Angst um ihre Position ihr Wissen nur unvollständig weitergeben, bis hin zu den typisch überlasteten internen Experten für das spezielle Thema.
Außerdem verändert sich die Umwelt des Projektes ständig. Gesetze ändern sich, neue Prozesse werden überarbeitet oder eine hippe neue App muss eingebunden werden. Die Liste ist nahezu unendlich. Schon Charles Darwin hat gesagt: „Nichts in der Geschichte des Lebens ist beständiger als der Wandel.“
Vor diesem Hintergrund Verträge zu gestalten, die annehmen, bei Vertragsunterschrift, sei der Projektscope fixiert und verändere sich eigentlich nicht mehr, erscheint mir weder clever noch smart.
Scrum hat in dem Umfang mit Veränderung eine seiner Stärken. Es begreift Veränderung als Antrieb statt als Fremdkörper. Daher empfehle ich Verträge für Scrum-Projekte mit einem änderungsrobusten Preismodel auszustatten.
Der Vertrag für ein Scrum- Projekt muss ein bewegliches System für Leistung und Preis enthalten. Änderungen müssen transparent und einfach nachvollzogen werden können.
Ein guter Start ist erfahrungsgemäß die gemeinsame Schätzung des Projektes. Die Projektpartner schätzen dabei nach dem Verfahren ihrer Wahl – egal ob Planning Poker, Magic Estimation oder „mit der [berühmten] Hand am Arm“- den Aufwand den sie für die Herstellung der Funktionalität benötigen.
Abnahme und Gewährleistung bei Scrum
Ein Projekt oder ein Gewerk abzunehmen bedeutet, dass das Werk grundsätzlich in Ordnung ist und bis auf ein paar Mängel, als Erfüllung des Vertrages angesehen wird. Erst wenn ich das Werk abgenommen habe, kann ich meinen Auftragnehmer dazu bringen, die Mängel zu beseitigen. Erst dann wird die Zahlung an den Auftragnehmer fällig.
Bei Scrum erklärt der Produkt Owner am Ende von jedem Spring, dass Inkrement, also das Teilgewerk, sei ok bzw. wird unter der Behebung von z.B. 5 Defiziten die Erwartungen erfüllen. Geliefert wird dann in einem der folgenden Sprints.
Ohne eine vertragliche Vereinbarung könnten Menschen, insbesondere solche mit richterlicher Entscheidungsgewalt, auf die Idee kommen, das Teilgewerk wird als Inkrement am Ende von jedem Sprint abgenommen. Bei einem Projekt mit 10 Sprints, also mit einer Projektdauer von einem guten halben Jahr, ergibt das 10 Teilgewerke, mit unterschiedlichen Abnahmen. Damit beginnt die Gewährleistung an 10 unterschiedlichen Zeitpunkten.
Da die Inkremente regelmäßig aufeinander aufbauen, stellt sich die Frage, welche Iteration der Fehler zugerechnet werden muss, wann er abgenommen wurde und ob er noch korrigiert werden muss oder der Anspruch bereits verjährt ist.
Ob die Applikation als Ganzes gut funktioniert, ist ohne dann auch nur schwer festzustellen und durchzusetzen, Daher empfehle ich, vorausschauende Regelung zu den Zwischenabnahmen der Sprints und zu der Endabnahme im Sinne eines finalen Integrationstestes in einem End2End-Szenario zu treffen.
Als Basis für die Zwischenabnahmen oder inhaltlichen Freigaben der Sprints bieten sich die Detailspezifikationen aus dem Sprint Planning an. Die Definition of Done enthält zusätzliche Aussagen zu der zu liefernden Qualität.
Zusammenarbeit im Scrum- Projekt und Projektorganisation
Scrum stellt die Zusammenarbeit mit dem Kunden in den Mittelpunkt. Scrum bewertet die Zusammenarbeit noch wichtiger als das Verhandeln von Verträgen.
Vielen Kunden ist dabei nicht klar, dass sie in einem Scrum Projekt besonders gefordert sind. Sie müssen in in erheblichem Maße mitwirkten. Es empfiehlt sich, die Mitwirkungspflichten transparent zu machen.
Sofern die Projektpartner besondere Zusammenarbeitsmodelle, wie z.B: der agile Festpreis im Projekt anwenden möchten, sollten sie diese im Vertrag beschreiben und vereinbaren.
Berichtswege im klassischen Sinne weiter zu „füttern“, ist vielen Unternehmen weiter wichtig. EIn einziges agiles Projekt ändert daran nichts.
Vor dem Hintergrund bietet es sich an, Meilensteine und Zeitplanung in entsprechenden Themenkomplexen zu bilden. Dann kann der Auftraggeber z.B. seinen Webshop mit rudimentären Funktionen in der Holzklasse Schritt für Schritt thematisch weiterentwickeln.
Gleichzeitig können Sie sehr gut im Unternehmen darstellen, dass neue Funktionen auch mehr kosten. Geld gegen Leistung ist ein Prinzip, dass nicht nur im Controlling oder Management viele Freunde hat.
Scrum- Spezifisches und Eskalation
IT-Projekte sind kaum Gegenstand einer gerichtlichen Auseinandersetzung. Bei Scrum ist die Quote wohl eher noch geringer. Daher ist es unwahrscheinlich und es wäre ein riesen Glücksgriff, wenn der Richter selbst Scrum-Master wäre. Dann könnte er die 3 Rollen, 4 Meetings / Events und 3 Artefakte des Scrum-Frameworks aus eigene Expertise unterscheiden.
Dies aber quasi vorauszusetzen, ist nicht vertretbar. Um unnötige Risiken zu vermeiden, müssen die Scrum-spezifischen Regelungen und Prozesse klar vertraglich definiert sein.
Sicher ist es auch sehr hilfreich, einen projektbegleitenden Eskalationspfad zwischen den Partien zu vereinbaren. Dieser sollte durch die Expertise eines unabhängigen, agilen Sachverständigen begleitet werden.
Die Vertragsverhandlung ist wichtig. Hier werden die Grundlagen gelegt, damit die praktische Umsetzung des Projektes und vertragliche Dimension der Unternehmung nicht auseinanderfallen. Die folgenden 8 Punkte sollten Sie nach alledem bei Verträgen für Scrum-Projekte beherzigen: