Klassisch oder agil?

Agilität oder Festpreis: Stehen Flexibilität und (Budget-)Sicherheit im Widerspruch?

Dirk Dorsch, Tilman Boller

© Shutterstock / VintageTone

Klassisch oder agil, Festpreis oder Time and Material, Sicherheit oder Flexibilität? Vor diesen Entscheidungen steht jedes im Auftrag umgesetzte Softwareprojekt. Wie schafft man es aber, die Vorteile der agilen Softwareentwicklung und das Bedürfnis nach Budgetsicherheit miteinander zu vereinen?

Agilität oder Festpreis?

Bis zum Zeitpunkt der Vertragsverhandlungen sind sich Fachabteilung und Softwarehersteller meist einig: „Lasst uns ein großartiges Stück Software bauen.“ Die Entscheidung zwischen klassisch und agil kann häufig durch die inhaltlich/fachliche Struktur des Projekts getroffen werden. Sind die Anforderungen einfach und präzise abzuschätzen, so wird häufig der klassischen Entwicklung der Vorrang gegeben. Ist ein Projekt technisch oder inhaltlich komplex und somit schwer a priori abschätzbar, fällt die Entscheidung zugunsten eines agilen Vorgehens. Bei der Suche nach einem geeigneten vertraglichen Modell für ein agiles Vorgehen treffen die konträren wirtschaftlichen Interessen von Auftraggeber und Lieferant aufeinander. So ist dem Einkauf die budgetäre Sicherheit das höchste Gut, dem Verkauf des Dienstleisters ein minimales, wirtschaftliches Risiko. Auf vertraglicher Ebene muss also zwischen Festpreis und Time and Material entschieden werden. Die Standpunkte sind hierbei klar definiert, die Interessen der durch die Fachabteilung vertretenden Endanwender gehen bei der Suche nach einem Kompromiss schnell verloren. Von Gerrit Beine wurde das Geschäftsmodell im Bereich der Individualsoftware an sich in Frage gestellt. Die Interessen von Auftraggeber und Lieferant scheinen nicht miteinander vereinbar, da der Auftraggeber mit möglichst geringen Kosten den größtmöglichen Funktionsumfang, der Lieferant aber eine Gewinnmaximierung erzielen möchte. Dieser Konflikt tritt unabhängig vom gewählten Vertragsmodell auf. Oberflächlich betrachtet liegt bei einem Festpreis das Risiko vollständig beim Lieferanten, während ein Time and Material als Freibrief zur Übervorteilung durch den Lieferanten angesehen werden kann.

Auf vertraglich/finanzieller Ebene scheinen die Interessen der Vertragsparteien gänzlich disjunkt. Eine Lösung für die vertraglich konträren Positionen lässt sich nicht finden. Jedoch kann durch den Aufbau von Vertrauen und einem gemeinsamen Verständnis auf das Projektziel mit beiden Modellen erfolgreich gearbeitet werden. Essenziell hierbei ist die Bereitschaft der Vertragsparteien, in einem Kompromiss die Interessen der jeweils anderen Partei zu verstehen und zu berücksichtigen. Die verhärteten Standpunkte müssen zugunsten einer vertrauensvollen Verhandlung bezüglich der Interessen aufgegeben werden. Anstatt einen Kompromiss bezüglich der Standpunkte zu wählen, sollte eine Kooperation auf Basis der Interessen angestrebt werden.

Von Kompromissen zu Kooperationen

Zwischen Festpreis und Time and Material haben sich einige Kompromisse herausgebildet. Diese scheinen immer dann notwendig, wenn auf Seiten des Auftraggebers keine konsequente Entscheidung zwischen Agilität und klassisch/Wasserfall getroffen werden kann. Der Konflikt entsteht zwischen dem Standpunkt des Lieferanten, ohne detailliertes Pflichtenheft kein gesichertes Festpreisangebot abgeben zu können, und der Fachabteilung, dieses nicht bieten zu können, und dem Wunsch nach einer kurzen Time to Market. Dennoch vertritt der Auftraggeber den Standpunkt, eine verlässliche Aussage bezüglich der zu erwartenden Kosten zu benötigen. Dieser Konflikt wird teilweise auch in das beauftragende Unternehmen hinein getragen, da die Fachabteilung den Standpunkt einer höchstmöglichen Flexibilität, der Einkauf den der höchstmöglichen Sicherheit vertritt. Zwischen diesen Standpunkten lassen sich Kompromisse bilden, bei denen jedoch beide Parteien Einschränkungen hinnehmen müssen.

Ein Festpreis kann beispielsweise mit einem Time-and-Material-Bedarfsbudget abgefedert werden. Dies garantiert dem Auftraggeber eine Budgetsicherheit, und der Lieferant kann sein wirtschaftliches Risiko durch das Bedarfsbudget abfangen. Dieser Kompromiss verschiebt den Konflikt allerdings in die Durchführungsphase. Diskussionen über die Zuordnung von Aufwänden zur Bringschuld aus dem Festpreis oder zum Bedarfsbudget sind unvermeidlich. Dennoch bietet dieser Kompromiss während der Durchführung den umsetzenden Rollen sicherlich mehr Flexibilität als formale Change-Request-Prozesse.

Die Umkehr dieses Konzepts ist ein Time-and-Material-Vertrag mit einem garantierten Maximalpreis. Der Lieferant hat hier das wirtschaftliche Risiko minimiert, der Auftraggeber hat innerhalb des garantierten Maximalpreises eine Budgetsicherheit. Zusätzlich sind während der Projektdurchführung Einsparungen für den Auftraggeber möglich. Da der Auftraggeber seinen Kapitaleinsatz minimieren möchte, gleicht diese Verhandlung über den Maximalpreis jedoch der bezüglich eines einfachen Festpreises.

Während diese beiden Ansätze den Kompromiss auf monetärer Ebene suchen, kann als weitere Option eine Dynamik in den umzusetzenden Funktionen in Betracht gezogen werden. Hierbei wird zu einem Festpreis ein minimaler Umfang an Funktionen umgesetzt. Weitere Funktionen werden bis zum Erreichen der Festpreisgrenze hinzugefügt. Dieser Ansatz verlagert allerdings Unsicherheit und Risiko auf die Fachabteilung und den potenziellen Erfolg des Projekts, da der exakte Lieferumfang erst spät im Projekt bekannt wird.

Das Modell des agilen Festpreises [1] umgeht die Nachteile der Kompromisse, indem es verstärkt auf kooperative Ansätze setzt und die Interessen der Einzelnen bestmöglich zu berücksichtigen versucht. Der agile Festpreis regelt zunächst den rechtlichen Rahmen und die wesentlichen Projektziele und Inhalte. In einem gemeinsamen Workshop werden die Anforderungen erarbeitet und bezüglich der Aufwände bewertet. Auf Basis der Aufwände wird ein, nicht vertraglich bindender, indikativer Festpreisrahmen definiert. In einer Checkpoint-Phase wird mit der Umsetzung des Projekts begonnen und abschließend auf Basis der gewonnenen Erkenntnisse die ursprünglichen Annahmen bewertet. Sofern eine gemeinsame Fortsetzung des Projekts gewünscht ist, wird der indikative Festpreis nachjustiert und vertraglich bindend. Neben Vereinbarungen bezüglich der Risikoverteilung bei Überschreiten des Festpreises werden unter anderem Konditionen für eine vorzeitige Beendigung des Projekts im Sinne aller Beteiligten festgelegt.

Grundsätzlich ist die Entscheidung für eines der Modelle eine Abwägung zwischen den Interessen der jeweiligen Stakeholder. In einigen Fällen ist eine Entscheidung zugunsten eines der Modelle oder einer der Interessengruppen durch Rahmenbedingungen vorgegeben. Häufig ist in einem der beteiligten Unternehmen auch bereits eine Grundsatzentscheidung zwischen Agilität und Wasserfall gefallen. Oftmals ist eine solche Entscheidung aber nicht offensichtlich und hat erhebliche Konsequenzen auf die Ergebnisgüte. Wesentlichen Einfluss auf die Entscheidung nimmt das Vertrauen zwischen Lieferant und Auftraggeber. Dieses kann schrittweise durch die Zusammenarbeit in einem kontrollierten Kompromiss aufgebaut werden und somit den Weg zu einer agilen Zusammenarbeit ebnen.

Trusted Time and Material

Ziel des Modells ist die Transformation des Verhältnisses zu einer vertrauensvollen Zusammenarbeit und der Versuch der Berücksichtigung der Interessen aller Beteiligten im Laufe des Projekts. Die an sich konträren Modelle aus Festpreis und Time and Material haben innerhalb des Lebenszyklus einer Geschäftsbeziehung eine unterschiedliche Daseinsberechtigung. Zu Beginn einer Geschäftsbeziehung ist häufig das notwendige Vertrauen für ein Time and Material noch nicht gegeben. Sofern Agilität in der Umsetzung gewünscht ist, ist dieses Modell aber zwingend notwendig. Ein dauerhaftes Festhalten an Kompromissmodellen wird zu anhaltenden Einbußen führen. Eine Möglichkeit, gegenseitiges Vertrauen aufzubauen, ist zunächst die Durchführung eines oder mehrerer kleiner Projekte in einem der etablierten Vertragsmodelle, oder die aus dem agilen Festpreis bekannte Checkpoint-Phase. Für den Auftraggeber ist jedoch auch in dieser Phase entscheidend, einen gesicherten Umsatz zu haben. Ebenso sollte für den Auftraggeber im optimalen Fall, auch nach einer solchen Ramp-up-Phase, etwas Verwertbares entstanden sein. Während der agile Festpreis einen vertrauensvollen und gerechten Festpreis anstrebt, verfolgt das Trusted Time and Material ein aufwandsbezogenes Modell als Ziel und instrumentalisiert den Festpreis für den Vertrauensaufbau.

Das Trusted-Time-and-Material-Modell verbindet die Interessen der Vertragsparteien durch eine Aufteilung des Projekts in zwei Phasen und bindet so die tendenziell ineffiziente Phase des Vertrauensaufbaus in eine produktive Projektphase ein. Ziel dieses Modells ist es, in einer ersten Phase schrittweise das Vertrauen zwischen beiden Parteien aufzubauen, um so die Grundlage für ein von Vertrauen geprägtes Time and Material in der zweiten Phase zu legen. Motivation für dieses Modell ist das aus der agilen Projektplanung bekannte Konzept des Feature Puffers [2]. Hierbei wird die Gesamtheit der Anforderungen berücksichtigt und entsprechend priorisiert. Abhängig von der Priorität und der Unsicherheit der Aufwände einzelner Anforderungen wird ein Release oder Projekt zweigeteilt. Der eine Teil wird verbindlich zugesichert, der zweite Teil als Feature Puffer definiert. Der Feature Puffer stellt somit einen erweiterten, optionalen Funktionsumfang dar. Hierbei gilt jedoch nicht, dass dieser im Regelfall nicht umgesetzt wird, sondern nur im Ausnahmefall weggelassen wird.

Übertragen auf ein Vertragskonstrukt wird so die Gesamtheit aller Anforderungen zweigeteilt. Diese Aufteilung erfolgt entlang des gemeinsamen Verständnisses im Dialog von Fachabteilung und Lieferant. In einem ersten Schritt wird dieses gemeinsame Verständnis auf hoher Abstraktionsebene erarbeitet. Dies kann in einem oder mehreren gemeinsamen Anforderungsworkshops stattfinden, die je nach Umfang durch den Auftraggeber bezahlt werden. Die entstandenen Ergebnisse dienen entweder als Grundlage der gemeinsamen Zusammenarbeit oder können vom Auftraggeber bei Verhandlungen mit alternativen Lieferanten dienen. Um den minimal geforderten Umfang des Projekts festzulegen, wird entlang der entwickelten Anforderungen eine Priorisierung der Anforderungen vorgenommen. Für den obligatorischen Funktionsumfang wird gemeinsam ein Pflichtenheft light erstellt. Umfang und Ausgestaltung werden hierbei pragmatisch zwischen den Vertragspartnern definiert. Das Pflichtenheft light dient dem Lieferanten, bezogen auf den obligatorischen Funktionsblock, als Basis für eine verbindliche, maximale Preisgarantie in Form eines Festpreises. Die verbleibenden Anforderungen werden, in Anlehnung an den Feature Puffer, als optionaler Block betrachtet. Die Umsetzung des optionalen Blocks ist nicht im Festpreis impliziert und wird in einem Time-and-Material-Modell umgesetzt. Entgegen der Nennung eines Festpreises auf Basis des Pflichtenhefts durch den Lieferanten, definiert der Auftraggeber für diesen Block das zur Verfügung stehende Budget. Anhand des Budgets wird der optionale Umfang nochmals bewertet. Im Allgemeinen entstehen bereits in dieser Phase der Zusammenarbeit zwischen Fachabteilung und Lieferant weitere Anforderungen, die in der Priorisierung den Status einer Vision erhalten.

Die Umsetzung des obligatorischen Blocks wird von einem aufwandsbezogenen Controlling begleitet. Dieses wird zusammen mit den Größenverhältnissen der Anforderungen aus dem optionalen Block ins Verhältnis gesetzt und für die Projektplanung des optionalen Blocks instrumentiert. Wird der Festpreis nicht in Gänze aufgebraucht, wird das restliche Budget für Anforderungen aus dem optionalen Block eingesetzt. Dies ermöglicht dem Lieferanten ein genügend hohes, risikominimierendes Festpreisangebot zu definieren, schützt aber gleichzeitig den Auftraggeber vor einer Übervorteilung durch einen überhöhten Festpreis.

Das Interesse des Lieferanten nach Gewinnmaximierung kann hier nicht befriedigt werden, ist aber an sich auch im Sinne einer vertrauensvollen Zusammenarbeit zurückzustellen. Die Transparenz bezüglich des Gesamtbudgets für den optionalen Teil ermöglicht dem Lieferanten eine Betrachtung des gesamten Umsatzpotentials. Das Übervorteilungsrisiko ist nun begrenzt auf die Menge optionaler Anforderungen, die bereits im Festpreis umgesetzt werden könnten. Hier besteht für den Lieferanten die theoretische Möglichkeit, die Arbeiten zu verlangsamen, um das Budget für den optionalen Anforderungsblock voll ausschöpfen zu können. Erfahrungsgemäß ist dies aber nicht notwendig, da das Budget in den seltensten Fällen für den gesamten optionalen Block ausreicht. Sollte dies in Ausnahmefällen dennoch zutreffen, so wird die Fachabteilung das Budget in der Regel ausreizen, um weitere Anforderungen der Vision umzusetzen.

Kontinuierliches Project Refinement

Das skizzierte Vertragsmodell teilt das Projekt in zwei grundlegende Phasen. In Phase 1 werden die obligatorischen Funktionen umgesetzt, während in Phase 2 die optionalen Anforderungen realisiert werden. Während die vertraglichen Bedingungen in beiden Phasen stark variieren, muss der gemeinsame Prozess dennoch vertragsagnostisch gestaltet sein. Das in Abbildung 1 skizzierte Prozessmodell illustriert die Integration eines kontinuierlichen Project Refinements in das Scrum-Modell. Der Kernprozess Scrum kann durch jeden beliebigen iterativen Prozess ersetzt werden, der es ermöglicht, das Budget-Controlling und Project Refinement regelmäßig durchzuführen.

dorsch_festpreis_1

Abb. 1: Kontinuierliches Project Refinement

Das Budget-Controlling erweitert das Sprint-Review um Budgetaspekte. Der Zielerreichungsgrad des jeweiligen Sprints wird so unmittelbar und explizit bezüglich seiner Auswirkungen auf den Stand innerhalb des Festpreises oder des optionalen Budgets betrachtet. Die Relevanz der Budgetbetrachtung nimmt im Laufe der ersten Phase stetig zu. Sowohl der prozentuale Anteil bereits umgesetzter obligatorischer Funktionen, sowie der relative Stand innerhalb des Festpreises ermöglichen so frühzeitig eine Schärfung der Gesamtprognose. Während der Umsetzung der obligatorischen Funktionen ist das Budget-Controlling essenzieller Einflussfaktor für das Project Refinement.

Das Project Refinement lehnt sich an das im Scrum übliche, wenn auch im Scrum Guide nicht verbindlich vorgeschriebene, Backlog Refinement an. Im Project Refinement findet eine regelmäßige Verfeinerung der im Product Backlog definierten Anforderungen statt. Das Project Refinement kann als eine kontinuierlich in den Prozess integrierte Pflichtenheftphase verstanden werden. In Phase 1, also der Umsetzung des obligatorischen Funktionsumfangs, sind die Anforderungen bereits durch das Pflichtenheft light hinreichend spezifiziert. Somit kann in dieser Phase das Project Refinement für die Entwicklung eines Prozessverständnisses, aber auch zum Aufbau von Vertrauen genutzt werden und bietet von Beginn an hinsichtlich einer Ergebnisoptimierung die Vorteile der agilen Projektsteuerung. Neben der Verfeinerung der Anforderungen ist dieser Prozessschritt um eine explizite Kostenbetrachtung erweitert und lässt so eine Sensibilisierung für ein Kostenbewusstsein entstehen. Das initiale Regelwerk sowie die äußeren Schranken sind durch das für Phase 1 vereinbarte Pflichtenheft light definiert.

Am Project Refinement sind alle relevanten Stakeholder, also Fachabteilung, Projektleiter, Konzeption, QA, Entwicklung, beteiligt. Die gemeinsame, intensive Betrachtung der im Pflichtenheft definierten Anforderungen ermöglicht dem Projekt bereits zu Beginn, das Optimierungspotenzial agiler Methodik auszuschöpfen. So können zum einen gemeinsam Vereinfachungen an den Anforderungen identifiziert werden, die allerdings nicht vom Lieferanten zu einer Übervorteilung ausgenutzt werden können. Diese Vereinfachungen werden entweder zu einer Ersparnis im optionalen Teil des Projekts führen oder ermöglichen, den optionalen Teil um weitere Anforderungen aus der Vision zu ergänzen. Das Project Refinement schafft zum einen ein gemeinsames Verständnis, dient aber insbesondere allen Beteiligten als Identifikationsfaktor mit dem Projekt. Die Beteiligten ordnen so langsam, in den kontrollierten Bahnen des Pflichtenhefts, ihre originären Eigeninteressen denen des gemeinsamen Projekts unter. Das Project Refinement, inklusive Kostenbetrachtung und dem vorausgehenden Budget-Controlling in Phase 1, schafft die Grundlage für die weitere vertrauensvolle Zusammenarbeit in der Time-and-Material-basierten Umsetzung der optionalen Anforderungen in Phase 2.

Angelehnt an den Build-Measure-Learn-Loop aus Lean Startup [3] werden mehrere Sprints in einer übergreifenden MVP-Iteration zusammengefasst. Während einzelne Sprints gemäß Scrum ein funktionierendes Inkrement liefern, definiert die MVP-Iteration als Ausgang ein Minimal Viable Product. Dieses definiert stets den kleinsten sinnvollen Funktionsumfang, der ein Release rechtfertig. Die erstellten MVP-Inkremente werden unmittelbar Tests bezüglich der Akzeptanz im künftigen Nutzerkreis unterzogen. Die Erkenntnisse aus diesen Nutzertests fließen so unmittelbar in den Project-Refinement-Prozess ein. In Phase 1 ist es essenziell, dass nur die Erkenntnisse Einfluss auf die obligatorischen Funktionen nehmen, die eine Aufwandsersparnis versprechen. Die Aufnahme weiterer, aufwandstreibender Anforderungen in die obligatorische Phase sollte vermieden werden, da dies den Festpreis konterkariert und unter Umständen zu ungewollten Konflikten führen kann. Sofern durch diesen Prozess bereits genügend Aufwände eingespart werden konnten, sind hier in beidseitigem Einvernehmen stets unbürokratische Ausnahmen denkbar. Das MVP kann phasenübergreifend genutzt werden, die Time to Market weiter zu optimieren. Sind die obligatorischen Funktionen vollständig implementiert, hat der Auftraggeber nach jeder MVP-Iteration die Option, das Budget weiter zu optimieren und einen vorzeitigen Projektabschluss zu finden.

Im Project Refinement findet zum einen eine stark fachliche, umsetzungsgetriebene Sichtweise und zum anderen eine eher inhaltliche, budgetbetrachtende Sichtweise statt. Wenn auch ein unmittelbarer Beitrag der Entwicklung zur Bestimmung der Aufwände budgettechnische Relevanz hat, sind die daraus resultierenden Priorisierungs- und Detailaspekte nicht zwingend für diese relevant. Ebenso werden technische Umsetzungsdetails, die lediglich geringe Auswirkungen auf das Budget haben und für die Fachabteilung nicht zwingend von Belang sind, thematisiert.

Je nach Konstellation und Rahmenbedingungen des Projekts ist es also erforderlich, das Project Refinement anzupassen oder aufzuteilen. Hierzu können, wie in Abbildung 2 illustriert, zwei zeitlich voneinander entkoppelte und inhaltlich abgegrenzte Prozessschleifen implementiert werden. Der erste, zeitlich vorgelagerte, Prozess bildet das planerische Project Refinement ab und dient einer Positionsbestimmung innerhalb des Budgets. Zwingend erforderlich in diesem Prozess sind Fachabteilung, Projektleiter, sofern vorhanden die Konzeption und mindestens ein Vertreter der Entwicklung. Diesem nachgelagert folgt die eigentliche Umsetzung in einem unter Umständen lieferanteninternen Prozessschritt. Dieser nutzt die im Unternehmen des Lieferanten etablierten Prozesse und Methoden (Abb. 2 unterstellt einen Scrum-Prozess).

Der Projektleiter vollzieht hier einen steten Wechsel zwischen der externen Rolle eines Projektleiters und den internen Aufgaben eines Product Owners. Diese Entkopplung verringert allerdings die Identifikation einiger Beteiligten mit dem gemeinsamen Projektzielen. Um dieser Entwicklung entgegenzuwirken, kommt der (Doppel-)Rolle des Projektleiters/Product Owners eine zentrale, integrative Bedeutung zu. In dieser Rolle muss der Konflikt zwischen den Interessen der (kundenseitigen) Fachabteilung und der (lieferantenseitigen) Entwicklung aufgelöst werden. Sofern es die Unternehmenskultur des Lieferanten zulässt, kann dieser entstehende Rollenkonflikt aufgelöst werden, indem der Projektleiter/Product Owner vom Auftraggeber gestellt wird. Die wirtschaftlichen Interessen des Lieferanten müssen dann durch das Entwicklungsteam gewahrt werden.

dorsch_festpreis_2

Abb. 2: Abgegrenztes Project Refinement

Fazit

Auf den ersten Blick scheinen sich die wirtschaftlichen Interessen der Vertragsparteien nicht miteinander vereinen zu lassen. Der Mangel an Vertrauen und die Angst vor Übervorteilungen zwingen im besten Falle dazu, Kompromisse zu definieren. Naturbedingt machen bei einem Kompromiss beide Seiten Abstriche von ihren Positionen und Standpunkten. Diese Abstriche manifestieren sich in vernachlässigten Interessen der eigentlich relevanten Stakeholder des Projekts, nämlich der Fachabteilung und der durch sie vertretenen Endanwender. Die Standpunkte der randbeteiligten Gruppen aus Vertrieb und Einkauf führen so schnell zu einem Kompromiss auf Kosten der Akzeptanz des Produkts. Die Einschränkungen der kompromissmotivierten Modelle lassen sich nur durch die Entscheidung zu einem vertrauensbasierten, kooperativen Ansatz auflösen.

Aufmacherbild: Stock Market Information via Shutterstock / Urheberrecht: VintageTone

Geschrieben von
Dirk Dorsch
Dirk Dorsch
Dirk hat seit 2008 nahezu alle Rollen in der Java-basierten (mobile) Enterprise-Entwicklung durchgemacht. In den Jahren als Entwicklungsleiter vermisste er das Hands-on und legt nun den Fokus wieder auf die Entwicklung.
Tilman Boller
Tilman Boller
Nach Abschluss seines Studiums der Geografie, Schwerpunkt Geoinformatik, begann Tilman Boller bei der Heidelberg mobil International GmbH als Business Development Manager im Bereich ortsbasierter Systeme zu arbeiten. Nach mehrjähriger Erfahrung in Verkauf, Konzeption und Projektmanagement leitete er zwei Jahre das Produktmanagement. Nach Übernahme der Geschäftsbereichsleitung führt er gegenwärtig die Vertriebs- und Marketingabteilung bei HD Mobil.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: