In vielen Unternehmen haben die klassische „Wasserfall“- oder „V-Modell“-Projektmethoden den agilen Methoden Platz gemacht. Dabei finden diese Methoden zunehmend auch ausserhalb von IT-Projekten Anwendung. Die Gründe kennen wir: bessere Bewältigung komplexer Aufgaben, Berücksichtigung des raschen Technologiewandels und Risikoreduktion („fail fast – learn fast“). Das klassische Pflichtenheft mit der finalen Endabnahme viele Monaten nach der Vertragsunterzeichnung wird durch mehrere, kurze „Sprints“ (Teilprojekte) mit verbindlichen Teilzielen ersetzt. Zentral für den Erfolg solcher Projekte ist die enge Zusammenarbeit zwischen Kunde und Anbieter sowie das Etablieren der dazu notwendigen, verbindlichen Rahmenbedingungen. Klassische Werkverträge haben den Fokus primär auf das Ziel, agile Verträge auf das Warum und Wie.

Beziehungsebene steuert Sachebene

Das 2. Axiom des Kommunikationsforschers Paul Watzlawik besagt sinngemäss, dass die Beziehungsebene die Sachebene steuert. Daher hiess erfolgreiche Zusammenarbeit schon immer, sich menschlich gut zu verstehen und gestützt darauf gemeinsam die Höhen und Tiefen eines Projektes zu meistern. IT-Mitarbeitende sind daher in der Regel recht angenehme Zeitgenossen – wenn man sie machen lässt. In der Vergangenheit hatten sie aber zu oft „auszubügeln“, was ihnen „die da oben“ eingebrockt hatten. Was typisch für die noch in vielen Unternehmen herrschende, zunehmend lähmende „Silo“-Kultur ist. Bei agilen – rasch umzusetzenden – Projekten fehlt den Ausführenden die Zeit für nachträgliches Klären grundsätzlicher Fragen und Rückfragen über alle Hierarchiestufen hinweg. Deshalb gilt: Zuerst die (gemeinsame) Basis, dann die Arbeit! Selbstverständlich tauchen grundsätzliche Fragen auch bei agilen Projekten immer mal wieder auf – aber je früher die Beteiligten Vertrauen und damit eine gute Beziehung aufbauen konnten, umso leichter und rascher lassen sich diese Sachfragen klären.

Agile Projektverträge

Am Anfang von agilen Projekten steht das Etablieren von tragfähigen Rahmenbedingungen. Erst das ermöglicht den Projekterfolg. Die Parteien müssen zu Beginn ihre Werte, Ziele, Erwartungen, zeitliche und finanzielle Rahmenbedingungen oder Vorgehensweisen gemeinsam klären – zu einem gemeinsamen Grundverständnis kommen. Ein einseitig zur Unterschrift vorgelegter Standardvertrag genügt daher nicht (mehr).

Ein gutes Instrument der vor Projektbeginn gemeinsam zu klärenden Punkte ist der von Thomas Molitor entwickelte „agile.agreement-Canvas“:

CC-credits: agileagreement.com

Der Canvas leitet die Parteien durch die wichtigsten Fragen ihrer künftigen Zusammenarbeit. Im Zentrum steht die Partnerschaft mit gegenseitigen Mitwirkungspflichten, geklärten Wertvorstellungen, gemeinsam formulierten Vorgehensweisen und Zielen, Controls etc. Einseitige Haftungsklauseln („Schuldzuweisung“) machen in solchen Verträgen regelmässig einer fairen Risikoverteilung zwischen den Parteien Platz. Ziel ist ein verbindlicher Rahmenvertrag, der während der Realisierungsphase zusätzlich durch die schriftlich vereinbarten „Sprints“ (Teilprojekte) ergänzt wird.

Es ist offensichtlich, dass agile Beschaffungs-/Projektverträge – zumindest wenn es sich nicht um Kleinprojekte handelt – nicht mal eben schnell ausgehandelt und unterschriftsreif formuliert werden. Die Vertragsparteien mögen zwar die im Canvas umschriebenen Punkte alleine ausdiskutiert haben, deren Formulierung und Vertiefung benötigt jedoch juristische Expertise kombiniert mit Moderationsgeschick.

Fazit

Klassische Projektverträge sind für die Regelung agiler Projekte untauglich. Agile Projektverträge legen den Fokus auf das „Wie“ der Zusammenarbeit, nicht auf das Resultat. Sie müssen moderiert und nicht vorgelegt werden. In der Realisierungsphase müssen die Parteien die Ziele ihrer „Sprints“ (Teilprojekte) schriftlich festhalten.