Agilophil-Daily Podcast Episode 14: Der “Agile Festpreis” und andere Mythen…

Herzlich willkommen zu einer neuen Folge des agilophil-daily podcast. Hier bekommst Du immer Tipps und Hinweise bunt gemischt zu allen Themen im agilen Kontext – kurz vor unserem Corona lock-Down war ich in einem Projekt bei einem noch relativ klassisch aufgestellten Energieversorger und habe dort eine Disussion mitverfolgt,  in der es um die Vertragsgestaltung mit externen Dienstleistern ging…Irgendwann wurde deutlich, dass es konkret um das Thema „agiler Festpreis“ ging und dann konnte ich mich auch nicht mehr zurückhalten und habe schließlich meinen Senf dazu gegeben. Ohne jetzt auf konkrete Einzelheiten dieser speziellen Diskussion einzugehen, nehme ich das mal zum Anlass das Thema in eine Podcastfolge zu verwandeln…und Dir meine persönlichen Gedanken und Erfahrungen darüber mitzuteilen…Warum? Ich selbst habe mich dem Thema von ein paar Jahren in einem Projekt gewidmet – wir waren voller Hoffnung, Motivation und  guter Dinge, aber es waren an dem Projekt 4 verschiedene Parteien beteiligt – Ein Dienstleister auf IT Seite und “Die IT” als interner Dienstleister selbst – dann “Der Fachbereich sowie ein Dienstleister – also ein Beratungsgesellschaft auf Seite des Fachbereichs” und das macht insgesamt summiert 4 Verträge und 4 Möglichkeiten sich gegenseitig misszuverstehen oder Dinge falsch zu interpretieren…Das Ende vom Lied war tatsächlich unangenehm und das so vielversprechend gestartete Projekt wurde nach gut einem halben Jahr eingestellt. Sicherlich ist an sowas nicht allein die Vertragsgestaltung schuld und nach Schuldigen wollen wir ja auch gar nicht suchen. Trotzdem habe ich was gelernt…und das möchte ich hier mal weitergeben:

Am Anfang stellen sich folgende Fragen:

  • Worum geht es bei Vertagsverhandlungen mit externen Dienstleistern?
  • Was ist das Ziel des Projekts?
  • Was sind die Herausforderungen?

und – was führt zu Unzufriedenheit zwischen den Vertragspartnern?

was sagt das agile Manifest dazu?

Wie sollte man also vorgehen? – eins sage ich gleich vorweg – am besten gar keine agilen Festpreisverträge machen!

Agile Projekte sind Dienstleistungsprojekte und wenn dieser Vertragstyp irgendwie nicht passt, ist eigentlich an der Grundhaltung in den beiden Unternehmen – also dem Auftraggeber und dem Auftragnehmer –  schon was nicht passend – also  zum agilen passend – ich will nicht sagen, dass hier was grundsätzlich falsch läuft – das natürlich nicht!

Aber wenn Du bzw. Deine Firma sich in eine agile Organisation verwandeln willst, fängt es eben bei den Werten und im Mindset an…und ich kann sagen, dass die Überlegung einen agilen Festpreis auszuhandeln allein schonmal ein Kennzeichen dafür ist, dass der agile Reifegrad im Unternehmen noch nicht besonders hoch ist…

Wenn es also unbedingt ein agiler Festpreis-Vertrag sein soll, dann musst Du insbesondere auf folgende 5 Punkte achten, sonst werdet ihr – und das weiß ich aus eigener, leidvoller Erfahrung – echt Probleme im Projekt bekommen:

Punkt 1: Der Geist des Vertags spiegelt die Zusammenarbeit im Team wieder. Wenn der Vertag ein „Kontrollinstrument” darstellt, von Pönalen und Strafzahlungen bei Nichterfüllung die Rede ist und der Vertag als Instrument zum Aufbau von Druck auf den Dienstleister gemeint ist, dann wird dieser Druck auf der anderen Seite auch entstehen – alte physikalische Weisheit – Druck erzeugt Gegendruck!…Die Stimmung im Projekt wird sich auf kurz oder 

lang in ein „Angriff- und Verteidigungs-Szenario“ wandeln – der Auftraggeber fordert, drückt und kontrolliert und der Dienstleister rechtfertigt sich, und will nicht schuld sein – da waren die Anforderungen nicht ausreichend spezifiziert oder zu kurzfristig gestellt oder Fachbereichstkollegen waren für Rückfragen nicht erreichbar und so weiter und so fort. Du siehst…der Fokus (- erinnere Dich an die Werte-Folge!) verschiebt sich vom Kundennutzen zu Angriff und Verteidigung…es wird also weniger und weniger an den eigentlich wichtigen Themen gearbeitet und mehr und mehr Zeit verschwendet sich zu streiten. Das ist nicht agil. 

Punkt 2: Baue Flexibilität ein, wo immer es geht! – Auf sich verändernde Backlogs und Nutzen verweisen und nicht auf ein Commitment des Teams zur Umsetzung bestimmter Anforderungen oder – noch schlimmer – auf eine bestimmte Anzahl von Storypoints. Halte die fachlichen Themen raus aus dem Vertag, sonst bist Du nicht mehr flexibel und verlierst einen wesentlichen Vorteil des agilen Vorgehens. Und der Steuerungseffekt solcher Regelungen ist fatal: Wenn der Vertrag vorsieht möglichst viele Storypoints im Sprint umzusetzen, dann werden auch Storypoints umgesetzt – es geht aber bei der Umsetzung im Projekt gar nicht darum Storypoints umzusetzen, sonder Kundennutzen zu schaffen. Wenn Du vom Team viele Storypoints willst, wirst Du sie erhalten….Wenn Du dann noch die Storypoints in Geld umrechnest – obwohl das von ihrem Wesen her gar nicht sinnvoll ist, konzentrierst Du dich darauf möglichst viel Output zu schaffen und nicht Nutzen. Du förderst Ressourcenverschwendung – und das ist in vielerlei Hinsicht nicht nachhaltig. Mit wenig Arbeit hohen Nutzen zu schaffen, ermöglicht es dem Team mit der übrig gebliebenen Zeit noch mehr Nutzen zu schaffen oder die Zeit zu haben, notwendige Prozessverbesserungen zu entwickeln. Das hast Du nicht, wenn Du dich auf Output fokussierst!

Punkt 3: Baue den Festpreis am Team auf – also Teamkapazität von x Leuten mal Sprintdauer oder Monat…Dann kostet dich das Team immer gleich viel und Du kannst mit dem Team abstimmen „WAS“ gemacht werden soll – und das auf Basis des Nutzens und der technischen Realisierbarkeit. Vermeide Bottom-up Modelle, wo einzelne Anforderungen im Preis geschätzt und zusammengezählt werden. Sowas macht viel Arbeit und ist auch nicht genauer – genauer gesagt – egal, wie du es machst, wirklich richtig schaffst Du es nie. Aber mit der Teamkapazität kommst du ziemlich nah an die Wirklichkeit heran…und das auch noch ziemlich einfach

Punkt 4: Die wesentlich schlechtere Art Flexibilität einzubauen ist – aus meiner Sicht – das Exchange for Free Verfahren- aber immer noch besser als nichts!… Wenn eine neue Anforderung hinzu kommt,  muss eine alte – oder andere Anforderung aus dem Release verschwinden – diese Anpassung ist dann „for free“ – also nicht, wie im klassischen Projektgeschäft mit einem  Change Request verbunden. Das Schlechte daran, ist die Tatsache, dass man dann einzelne Anforderungen dabei monetär bewertet – also man ist wieder bei der bottom up Methode. Um also streitfrei festlegen zu können, dass eine Anforderung gegen eine gleichwertige andere ausgetauscht werden kann, muss klar sein, dass sie gleichwertig sind…und darin steckt schon wieder viel Potenzial für unterschiedliche Meinungen.

Punkt 5: Was ist der Abnahmegegenstand? – in Werkverträgen hat man Abnahmen – man kennt das vom Hausbau, da kommt der Begriff „Gewerk“ auch her – Der Bauherr oder Architekt oder sonst eine bevollmächtigte Person schaut sich die Leistung des Handwerkers an, prüft und nimmt sie als „ordnungsgemäß erledigt“ ab – darauf hin kann die Rechnung erstellt bzw. die Zahlung freigegeben werden. Vom Gefühl her ist das genau das, was ein Unternehmen als Sicherheit gedenkt zu brauchen, weil man die „Dienstleister“ ja kontrollieren muss, sonst machen die was sie wollen…oder man muss Druck aufbauen, sonst sind die „faul“ und arbeiten gar nicht…

Du siehst – hier schwingt eine Geisteshaltung mit, die ich unter „Command and control“ einordne – und das ist nicht wirklich agil sondern kommt aus der tayloristischen Weltsicht, die agile Unternehmen verlassen wollen…

Wie soll das also im agilen Kontext funktioinieren?

Im agilen Kontext kommt hier wieder die Wertebasis zum Tragen sowie das alt-bekannte agile Manifest: „Zusammenarbeit mit dem Kunden geht über Vertragsverhandlungen“ steht hier – und das wird durch die dazu gehörenden Prinzipien untermauert…Die für mich in diesem Kontext passendesten lauten:

  • Prinzip Nr. 4: Fachleute aus verschiedenen Bereichen müssen während des Projekts täglich zusammenarbeiten.
  • Prinzip Nr. 7: Funktionierende Dienstleistungen/Produkte sind das wichtigste Fortschrittsmaß.
  • Prinzip Nr. 8: Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, das Team und die Nutzer der Dienstleistung sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
  • Prinzip Nr. 11: Die besten Arbeitsrahmen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
  • Prinzip Nr. 12: In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und es passt sein Verhalten entsprechend an.

Ich übersetze das mal in den Kontext der Vertragsverhandlungen aus agiler Sicht:

Der Dienstleister ist ein Partner, der mit seinen Spezialisten mir als Auftraggeber hilft ein Problem zu lösen, welches ich ohne ihn nicht lösen kann…Der Dienstleister ist kein Gegner, gegen den ich kämpfen muss und auch kein Knecht, der mir lästige Dinge abnimmt…

In diesem Sinne ist der Dienstleister auch daran interessiert mir die passenden Lösungen und Produkte in hoher Qualität zu liefern und nicht möglichst wenig zu arbeiten und den Auftraggeber zu betrügen, wo es nur geht (was ja implizit bei einer entsprechenden Vertraggestaltung unterstellt wird). Und – aus Sicht des Dienstleisters ist es ja so: wenn man mir das schon unterstellt, dann komme ich vielleicht auch auf den Gedanken das auch so zu sehen… Währed den Anfängen kann ich da nur sagen!

Selbstorganisiert kann ein Team nur sein, wenn es keine versteckte Agenda zwischen den Teammitgliedern gibt. Ein „Knebelvertrag“ wäre Auslöser von solchen Denkeweisen, das ist ganz klar. Wenn wir gemeinsam im Vertag regeln, dass wir als Partner zusammenarbeiten und an einer ständigen Verbesserung arbeiten, dann entsteht die „Gegner-Sicht“ nicht. Und natürlich können wir das auch über im Vertag festgeschriebene Aktionen wie Retrospektiven einfordern – 

Doch wie können wir nun die gewünschte Rechtssicherheit herstellen, die sowohl dem Auftraggeber wie auch dem Auftragnehmer dient?

Wir vernachlässigen sehr oft den Kundennutzen – das was eigentlich das Ziel der Aktivitäten im Rahmen von agilen Projekten sein sollte – Anforderungen werden häufig nur nach Aufwand geschätzt und dann bepreist – eine Schätzung nach Kundennutzen erfolgt selten – dabei ist das der eigentliche Input, den wir bei der Priorisierung von Anforderungen nutzen sollten.

Wenn wir also den Kundennutzen einer Anforderung in Euro angeben können (wir müssen uns ja mal Gedanken darüber gemacht haben – sowas hat man früher „business case“ genannt), dann sollte es uns leicht fallen, ein Kriterium im Vertag zu verankern, das zur Erhöhung der Sicherheit dient.

Wir ermitteln den Nutzen, den ein Sprint haben wird – also  wir addieren die Beträge des Kundennutzens aller Anforderungen, die für einen Sprint geplant sind (und hier – kleine Nebenbemerkung –  werden wir uns genau in die Augen schauen und vertrauensvoll und wertschätzend – und vor allem ehrlich – miteinander umgehen müssen). 

Und wir ermitteln die Kosten für den Sprint (also Stundensatz/Tagessatz DL mal Anzahl Teammitglieder mal Arbeitstage im Sprint). Da ein Scrum-Team sich ja nicht ständig ändert und die Dauer des Sprints auch konstant bleibt, sollte das für jeden Monat gemittelt werden (also Feiertage rausrechnen, indem wir 20 Arbeitstage annehmen) und dann haben wir eine sehr gute und ziemlich feste und verlässliche Kostenberechnung. 

Wenn also dieser Betrag des erreichten Kundennutzens über den Kosten für den Sprint liegt, macht das Ganze Sinn. Bei einer sinnvollen Sprintplanung mit einer geeigneten Priorisierung durch den Product-Owner und einem ehrlichen Forecast durch das Team, werden wir also im Plus liegen. 

Das können wir als Abnahmekriterium im Vertrag festhalten. Wir nehmen also nicht eine Anzahl von Stories oder Storypoints als Maßstab, sondern den Kundennutzen. Wenn das Team den erstrebten Kundennutzen wiederholt nicht erreicht, können wir Pönalen im Vertrag festlegen. Das ist sowohl fair gegenüber dem Auftragnehmer, da es ein Ansporn für das Team ist, die gesetzten Ziele auch zu errreichen und sich ständig zu verbessern – und auch ein Ansporn für den Auftraggeber, nutzenorientiert vorzugehen und nicht ungebremst Output zu fördern.

Ich wiederhole es nochmal – im agilen Kontext sind Dienstleistungs-  bzw. Serviceverträge die beste Lösung. Darum die klare Empfehlung von mir – vermeide einen Werkvertrag!

Nun ist mir bekannt, dass es verschiedene Kontexte gibt, in denen eine derartig freie Vertragsgestaltung nicht anwendbar sind. Zum Beispiel müssen bei Ausschreibungen von öffentlichen Auftraggebern Festpreise angeboten und klare Gewerke festgeschrieben werden. Hier können wir allerdings mit Berücksichtigung unserer eigentlichen Intention einer partnerschaftlichen Zusammenarbeit verschiedene Mischformen anstreben – also feste Grundanforderungen (also sozusagen die Projektvision) mit einer Verankerung von Austauschmöglichkeiten über ein Exchange for Free Verfahren. 

Was auch möglich wäre, ist eine phasenweise Beauftragung von Sprints bzw. Iterationen, wodurch wir uns die Freiheit erhalten, jederzeit festlegen zu können, wann der gewünschte Nutzen erreicht ist. Wir werden damit in die Lage versetzt das Projekt auch frühzeitig zu beenden. Hier ergibt sich allerdings ein Nachteil für den Dienstleister (das ggf. veranschlagte Auftragsvolumen wird nicht ausgeschöpft). Das können wir wiederum mit einem Passus im Sinne von „wir teilen uns die Einsparung“ ausgleichen. Der Gedanke dahinter ist, den Gewinn aus dem frühzeitigen Ende gerecht aufzuteilen, was einen zusätzlichen Anreiz für den Dienstleister stellt, denn er wird belohnt, wenn er früh in bester Qualität fertig wird. Wenn wir einen Sprint zu x-1000,- € einsparen, dann erhält der DL die Hälfte des Sprintpreises als Bonus und kann sein Team bereits früher bei einem anderen Kunden einsetzen. Als Auftaggeber können wir ebenfalls die Hälfte der Sprintkosten als Kosteneinsparung verbuchen und bleiben so unter dem veranschlagten Budget. Eine klassische Win-Win Situation – niemand verliert – beide gewinnen…

Es gibt mit Sicherheit noch eine Menge weiterer Ideen für eine partnerschaftliche Vertragsgestaltung und das ist auch genau das, worauf es ankommt.  In diesem Sinne – agil beginnt hier – bei Dir – im Kopf…

Danke fürs zuhören und hinterlasse gerne einen Kommentar über meine Webseite agilophil-daily.de. Ich freue mich auch über eine Bewertung bei itunes bzw. Spotify oder Google  oder wo auch immer Du diesen Podcast hörst..

Solltest Du Wünsch zu Themen haben, über die ich mal sprechen soll, schick mir auch gerne eine PN über Linkedin oder Xing oder über mein Kontaktformular auf der Webseite.

Mach weiterhin das Beste draus…

Tschüß, dein agilophiler Frank