Verträge zu Scrum & Co: Vertragsgestaltung bei agilen Programmiermethoden – Teil 2

Während der erste Teil dieses Beitrags eine die Grundlagen der agilen Softwareerstellung und um das Spannungsfeld zwischen agilen Eigenheiten und der gesetzlichen Vertragstypen darstellt, geht es in diesem zweiten Teil um Vergütungsmodelle und die Kommunikation im Projekt.

Vergütung: Die Quadratur des Kreises

Befragt man Besteller von Individualsoftware nach Ihrer Vorstellung von der Vergütung, lautet die Antwort meist: „Festpreis“. Gemeint ist damit ein im Voraus festgesetzter Preis für sämtliche Leistungen des Entwicklers. Dieser Wunsch ist nachvollziehbar, zumal der Besteller je nach Größe, Branche und Struktur seines Unternehmens nicht nur ein Budget planen muss, sondern eine Kostenexplosion ggf. ruinöse Dimensionen annehmen kann.

So verständlich dieser Wunsch des Bestellers ist, so sehr stört er regelmäßig im agilen Projekt, wenn sich dieses durch einen geringen Planungsgrad und damit mangelnde Vorhersehbarkeit der zu ergreifenden Schritte auszeichnet. Besteht der Besteller auf einen Festpreis, wird der Entwickler seinerseits auf eine detaillierte Ausarbeitung der Anforderungen mit entsprechenden Vergütungsklauseln für Änderungswünsche (Change Request) bestehen. Die eigentliche Programmierung kann dann selbstverständlich noch immer agilen Methoden folgen, die ausgedehntere Planungsphase wird dann jedoch zu einer längeren Projektdauer führen und mit höheren Kosten als übliche Planungsphasen in agilen Projekten verbunden sein. Zudem wird jeder vernünftige Entwickler einen Sicherheitszuschlag in die Kalkulation aufnehmen.

Demgegenüber bietet eine reine Aufwandsvergütung zwar die ideale Äquivalenz zwischen Leistung und Gegenleistung. Besteller können eine solche wegen der mangelnden Kostenplanbarkeit jedoch kaum verantworten und werden hierauf allenfalls dann zurückgreifen, wenn sie selbst über einen hinreichend kompetenten und personenstarken IT-Mitarbeiterstab verfügen, der die Software im Fall der Kostenexplosion selbst und ohne Hilfe des Entwicklers in einen lauffähigen Zustand bringen und zumindest notdürftig pflegen und fortentwickeln kann.

Als Lösung wird häufig die Festlegung des MVP (minimum viable product), also desjenigen Zustandes des Produkts, der gerade so die Mindestanforderungen erfüllt, gepriesen. Dieser soll gegen Festpreis oder in einem bestimmten Kostenrahmen erreicht werden, um wenigstens ein Mindestmaß an Planungssicherheit zu gewinnen, während für den weiteren Ausbau andersartige Regelungen gelten können. Daneben werden häufig auch asymmetrische Kündigungsfristen, die dem Besteller den zeitnahen Projektausstieg ermöglichen, als Lösungsansatz genannt.

Tatsächlich ist die Bandbreite der möglichen Lösungen ebenso groß wie diejenige der möglichen Produkte. Die aufgeführten Lösungsansätze sind daher immer nur so gut, wie sie zum individuellen Projekt passen. Der Besteller muss seine Interessen wie Flexibilität, Planbarkeit, Kostenbegrenzung und schnelle Ergebnisse definieren und gewichten. Nur dann kann ein passendes Wechselspiel zwischen Planung, Entwicklung und Vergütung erreicht werden.

Der häufigste Knackpunkt: Die Kommunikation bei der Durchführung

So wichtig eine gute Planung – sowohl die rechtliche als auch die technische – für ein Softwareprojekt ist, so wenig darf übersehen werden, dass die häufigste Ursache für das Scheitern derartiger Projekte die mangelnde Kommunikation zwischen den Vertragsparteien ist. Dies gilt für alle Arten von Softwareprojekten, auch für solche mit herkömmliche Programmiermethoden, insbesondere aber für agile Projekte, die vom ständigen Dialog der Vertragsparteien leben. Die meisten Entwickler sind im ständigen Dialog geübt; größere Defizite sind häufig eher auf Bestellerseite zu finden. Dies gilt insbesondere für mittelgroße, wachsende Unternehmen, die zwar mit viel fachlichem Know-how, aber mit wenig Projekterfahrung ausgestattet sind, und sich damit schwertun, einen geeigneten Projektmanager abzustellen. Für die enge und konstruktive Zusammenarbeit ist es jedoch unerlässlich, dass dem Entwickler ein ständiger Ansprechpartner gestellt wird, der an sämtlichen gemeinsamen Sitzungen teilnimmt, mit dem Einsatzgebiet des zu erstellenden Produkts hinreichend vertraut ist und über die erforderlichen Entscheidungskompetenzen verfügt. In den wenigsten Fällen sind hierfür Geschäftsführer geeignet, die zwar über die maßgeblichen Befugnisse verfügen und häufig eine Vorstellung vom fertigen Produkt haben, die jedoch neben dem Alltagsgeschäft regelmäßig zu geringe Zeitkapazitäten für die dauerhafte intensive Begleitung des Projekts haben und bisweilen Schwierigkeiten haben, fertige oder geplante Softwareteile aus der Anwenderperspektive zu betrachten.

Die enge Einbindung des Bestellers in den Entstehungsprozess beinhaltet auch einen neben der Vergütung weiteren nicht unerheblichen Kostenblock, den der Besteller im Rahmen der Budget-Planung berücksichtigen muss. Der vom Besteller benannte Projektmanager hat während der Projektdauer für seine übliche Kernaufgabe nur eingeschränkt Zeit. Dies wird der Besteller kompensieren müssen, etwa durch vorübergehende Einstellung weiterer Arbeitskräfte. Unterbleibt dies, besteht für den Projektmanager der Anreiz zu Nachlässigkeiten bei der Projektbetreuung – mit ganz erheblichem Schadenspotential.

Zusammenfassung

Agile Softwareprojekte beruhen auf dem Gedanken der iterativen Entwicklung und der Aufgabenverteilung nach Kompetenz statt nach Unternehmenszugehörigkeit. Die Verantwortlichkeiten verschwimmen, und weder die im BGB bestimmten Vertragstypen noch die üblichen Vergütungsregelungen passen ideal zu agilen Projekten. Zudem erfordert ein agiles Projekt auf Bestellerseite ein hohes Maß an Dialogbereitschaft und Zeitaufwand. Wer bereit ist, sich hierauf einzulassen, kann von kurzen Entwicklungszeiten, früher Einsatzfähigkeit des Produkts und einem hohen Maß an Flexibilität profitieren.

Wegen dieser Eigenheiten agiler Projekte verbieten sich Vertragsmuster aus der Schublade; ein für jedes Projekt passendes Vertragsmuster kann es nicht geben. Dabei bietet es sich die frühzeitige Entwicklung von Konzepten der Vertragsgestaltung an. Denn der im ersten Teil genannte Widerstreit zwischen den Eigenheiten agiler Methoden und konventioneller Vertragstypen des BGB, verlangt nicht nur Verständnis und Kreativität bei der Vertragsgestaltung; der rechtliche Rahmen hat auch umgekehrt Einfluss auf die tatsächliche Projektgestaltung. Bei verständiger Auslotung der Interessen der Vertragsparteien können aber individuell passende Regelungen gefunden und zum Grundstein einer großen Erfolgsgeschichte werden.