Direkt zum Hauptbereich

Der Rahmendienst-Sprintwerkvertrag für Scrum-Projekte

Auf der #AgileCologne hatten wir eine gute Diskussion über die Vertragsgestaltung für Scrum-Projekte. Kunden möchten immer gern Festpreisprojekte haben; Lieferanten wollen lieber nach Time & Material abrechnen. Wie kommen wir aus diesem Dilemma raus? Mein Vorschlag ist der Rahmendienst-Sprintwerkvertrag.


Hinweis: Es geht hier um vertragliche und rechtliche Grundlagen. Wenn Sie nicht verstehen, was hier beschrieben ist, fragen Sie bitte Ihren Rechtsanwalt oder Ihre Rechtsabteilung um Rat.

Ich habe schon etwas über agile Verträge geschrieben:
  • Im ersten Teil beschreibe ich, welche Vertragsarten es gibt /1/.
  • Im zweiten Teil schreibe ich etwas über das Profil von Scrum-Projekten /2/. Da weder die genauen Anforderungen noch das genaue Design vor Projektstart bekannt sind, können die Vertragsparteien keinen Werkvertrag schließen. (Mehr über Projektprofile können Sie in unserem Vortrag vom Scrum-Day nachlesen: http://archiv.scrum-day.de/archiv/scrumdayjun13berlin/vortraegedownload/Mit_Projektprofilen_Scrum_besser_verkaufen.pdf)
  • Im dritten Teil zeige ich auf, wie man den Nutzen von IT-Systemen herausfinden kann /3/. Das ist wichtig, weil man die Projektkosten immer in Bezug zum Wert setzen sollte, den man sich erhofft. Mein Richtwert ist, dass der Nutzen das dreifache der Projekt- und ggf. Betriebskosten sein sollte.
  • Im vierten Teil habe ich schon einen groben Vorschlag für die Vertragskonstruktion gemacht /4, 5/.
Den Vorschlag möchte ich hier weiter erläutern.

Brauchen wir wirklich Verträge?

Scrum bedeutet nicht, dass wir keine Verträge mehr schließen. Vom Prinzip sprinten wir solange, bis das Geld verbraucht ist. Kunde und Lieferant haben aber verschiedene Bedürfnisse, die sie vorher vertraglich absichern sollten.

Der Kunde möchte Planungssicherheit und Kompetenz. Er hat Angst, dass ihn der Lieferant zur Mitte des Projekts wegen eines noch besseren Kunden verlässt.

Der Lieferant hat Verantwortung für seine Mitarbeiter und möchte ihre Auslastung sicher stellen. Wenn der Kunde das Projekt spontan abbricht, hat er ein Problem. Der Lieferant braucht auch Planungssicherheit. Erfahrungsgemäß überziehen Kunden den Festpreis. Dann macht der Lieferant Verlust. Das ist auch nicht gut. Es gibt auch ganz praktische Fragen: Wie plane ich Urlaubs- und Krankheitszeiten der Mitarbeiter ein?

Also: Verträge helfen uns. Sie geben beiden Seiten Planungssicherheit. Wenn wir aber Anforderungen und Design noch nicht kennen, wie können wir trotzdem einen Vertrag schließen?

Vorschlag für einen agilen Vertrag

Mein Vorschlag ist folgender:
  • Für den Projektrahmen wird ein Dienstvertrag geschlossen, d. h. der Lieferant sichert dem Kunden zu, über einen gewissen Zeitraum, kompetentes Personal zu stellen. Auch wenn die genauen Anforderungen nicht bekannt sind, haben beide Seiten ein gutes Gefühl oder Erfahrungswerte, wie lange ein solches Projekt dauert.
  • Das Projekt wird in eine Setup-Phase und Sprints aufgeteilt. Für die Setup-Phase und die Sprints werden konkrete Ergebnisse geplant. Ergebnisse in der Setup-Phase sind die Architektur und das initiale Product Backlog. Ergebnisse der Sprints sind die umgesetzten User Storys. Scrum schreibt eine Planung und ein Review vor. Dies entspricht vom Prinzip her einem werkvertraglichen Vorgehen. Jeder Sprint ist ein Mini-Werkvertrag.
Dieser Vertrag ist ein Rahmendienst-Sprintwerkvertrag. Die wesentlichen Punkte und das Vorgehen sind im Rahmenvertrag festgehalten. Das unterschriebene Protokoll der Sprintplanung ist gleichzeitig der Werkauftrag für den nächsten Sprint. Das Protokoll des Reviews ist eine vorläufige Annahme der Liefergegenstände. Sie brauchen kein eigenes Dokument für den Werkvertrag. Sie lassen nur die Dokumente unterschreiben, die eh schon erstellt werden. Nach jedem Sprint wird abgerechnet. Die folgende Abbildung zeigt den Vertrag im Überblick.
Abb. 1: Der Rahmendienst-Sprintwerkvertrag im Überblick

Anmerkungen



Kommentare

  1. Interessant - das gent aber davon aus, dass das, was in jedem Sprint geliefert wird, bereits im Planning "wasserdicht" definiert wird. Das aber widerspricht Scrum. Dort nämlich heisst es:
    "After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal... The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint... In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint."

    Und der Sprint-Review ist KEINE FORMELLE Abnahme:
    "This is an ***informal*** meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration."

    Also: Das, was auf Basis solcher Verträge gemacht wird kann sicher funktionieren - ist aber nicht Scrum

    AntwortenLöschen
  2. Hallo Unknown,

    ja, der Scrum-Guide legt Wert darauf, dass es eben keine formale Beauftragung und keine formale Abnahme ist. Aus Vertragssicht ist das Vorgehen aber ein werkvertragliches Vorgehen. Wir können den Review daher als vorläufige Abnahme nutzen.

    Scrum sagt ja auch nichts zur Beauftragung, zum Projektstart und woher die User Storys kommen. Trotzdem können wir es vertraglich regeln.

    Sollte ich das Wort "Scrum" wieder aus dem Titel nehmen?

    Beste Grüße, Jan

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Teamleitungen gesucht

Was macht Teams erfolgreich? Kann man das lernen? Ab Herbst starten unsere Kurse für aktuelle und künftige Teamleitungen. Jetzt gibt es die Gelegenheit, den Kurs zu testen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Nachschau zum Lean Coffee-Spezial "Agil einfach machen" (Interaktive Buchvorstellung)

Bei unserem Lean Coffee-Spezial Ende Mai waren wir von Lean Coffee Karlsruhe/Frankfurt Zeugen einer Buchvorstellung, doch nicht nur das – natürlich gab es auch einen nicht unbeträchtlichen Anteil an eigener Aktion, denn bei unseren Spezialterminen ist traditionell „Teilgabe“ angesagt. Das Autorenduo Christian Baron und Janick Oswald zeigte uns, was es mit „Agil einfach machen“ auf sich hat.  

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen. 

Kleine Organisationsveränderungen, die direktes Feedback erzeugen

Große Veränderungen sind in einer Organisation schwer zu messen. Oft liegt zwischen Ursache und Wirkung ein langer Zeitraum, sodass die Umsetzer:innen nicht wissen, was genau gewirkt hat. Hier ist eine Liste mit kleinen Maßnahmen, die schnell etwas zurückmelden.

Wie Agilität den Kundennutzen steigert - Einige Argumente für Berater:innen

In Zeiten wirtschaftlicher Unsicherheit fragen sich viele, ob agile Beratung noch eine Zukunft hat. Die Antwort liegt in der konsequenten Orientierung am Kundennutzen. Qualität setzt sich durch, wenn sie messbare Verbesserungen bei Umsatz, Kosten und Leistungsfähigkeit bewirkt, anstatt sich in Methoden und zirkulären Fragen zu verlieren. Dieser Artikel zeigt, wie agile Beratung nachhaltige Veränderungen in Unternehmen schafft und warum gerade jetzt gute Berater:innen gebraucht werden, um Organisationen widerstandsfähiger zu machen.