Wie funktioniert die Preisgestaltung bei agilen Verträgen?

Bei der Preisgestaltung für Softwareverträge prallen zwei vollkommen gegensätzliche Interessen aufeinander: Der Auftragnehmer möchte einen möglichst hohen Stundensatz für das Projekt erzielen. Der Auftraggeber wiederum möchte die Projektkosten möglichst niedrig halten und den maximalen Nutzen mit dem eingesetzten Budget erreichen. Das ist natürlich ausschließlich die trockene, vertragliche Sicht, denn die Realität sieht nicht immer so aus.

Dennoch möchten wir ein Vertragsmodell finden, dass diese Interessen auch auf dem Papier gleichmäßig berücksichtigt. Wir zeigen Ihnen mögliche Fallstricke sowie einen alternativen Lösungsansatz, von dem beide Parteien in einem agilen IT-Projekt profitieren.

Risikoteilung: Ein entscheidender Aspekt für Softwareverträge

Bei einer Zusammenarbeit in agilen Projekten ist das Risiko für beide Vertragsparteien unumgänglich. Denn selbst, wenn es ein sehr genaues Briefing gibt und Anforderungen klar erscheinen, können und sollen sich während der Umsetzung Änderungen ergeben dürfen. Dieses Risiko versucht man mit einem agilen Vorgehensmodell einzugrenzen.

Ein konkretes Risiko, das auftreten kann, ist, dass die Umsetzung einer User Story deutlich länger dauert als geplant. Daher ist es wichtig, sich vor dem Abschluss eines Softwarevertrags mit dem Thema Risikoteilung zu beschäftigen. Denn je nachdem, wie Sie Ihren Softwarevertrag gestalten, tragen Auftragnehmer und Auftraggeber einen unterschiedlichen Anteil des Risikos.

In Folge zeigen wir, wie bei zwei gängigen Preismodellen (T&M bzw. Arbeitspreis pro Teamstunde und Preis pro Story Point) die Risikoverteilung aussieht:

Preis pro Teamstunde

Eine weit verbreitetes Abrechnungsmodell ist die Abrechnung auf Basis von Teamstunden. Dies ist ein klassisches T&M-Modell, bei dem das Risiko beim Auftraggeber liegt. Er bezahlt den Auftragnehmer für die abgearbeiteten Stunden, unabhängig vom Ergebnis der geleisteten Arbeit. 

Preis pro Story Point

Bei diesem Modell wird der Auftragnehmer bezahlt, wenn er einen Story Point fertiggestellt hat. Das soll das Team des Auftragnehmers motivieren, effizient zu arbeiten. Das Risiko bei diesem Modell liegt ganz klar beim Auftragnehmer. Wenn er keine fertiggestellten Story Points liefert, erhält er auch keine Bezahlung. Das Risiko, das natürlich trotzdem beim Auftraggeber verbleibt, ist, dass er keine lauffähige Software hat und die „Time to Market“ darunter leidet.

Wie Sie leicht erkennen können, haben die beiden Varianten einen entscheidenden Nachteil: Sie verteilen das finanzielle Risiko für die Zusammenarbeit sehr ungleichmäßig. Das Risiko liegt hauptsächlich bei einer der beiden Parteien. 

Doch es geht auch anders. Im Video zu diesem Blogbeitrag erklärt Richard Brenner, Agile Coach bei TechTalk, diesen Unterschied ausführlich und stellt einen alternativen Ansatz vor. 

Interessen von Auftraggeber und Auftragnehmer vereinen

Bei TechTalk beschäftigen wir uns schon seit vielen Jahren mit der Lösung dieses Problems. Um das Risiko auf beide Parteien gleichmässig zu verteilen, haben wir ein Modell entwickelt, welches die beiden Varianten Preis pro Teamstunde und Preis pro Story Point kombiniert.

Unser Modell „Pay per Story Point and Hour“ teilt die Projektrisiken zwischen Auftragnehmer und Auftraggeber auf, indem wir die Abrechnung aus folgenden Komponenten zu unterschiedlichen Teilen kombinieren:

  1. Preis pro Story Point: Fixpreis-Anteil pro gelieferter Funktionseinheit gemäß der zu Beginn angenommenen Lösungskomplexität
  2. Reduzierter Preis pro Story Point: Reduzierter Fixpreis-Anteil pro gelieferter Funktionseinheit, wenn zum Beispiel ein unvorhergesehener Story Point dazukommt
  3. Arbeitspreis pro Teamstunde: Variabler Preis-Anteil pro tatsächlich geleisteter Teamstunde des Auftragnehmers

Sehen wir uns ein konkretes Beispiel an, um dieses Modell mit seinen Auswirkungen in unterschiedlichen Szenarien genauer zu verstehen. 

Beispielrechnung für das kombinierte TechTalk-Modell

Gehen wir für das Beispiel von folgenden Annahmen aus: 

  • Der Aufwand für einen Story Point ist erfahrungsgemäß 8 Stunden für dieses Team in diesem Projekt. 
  • Der Preis für eine Teamstunde liegt bei 100 EUR. 

Damit beträgt der kalkulierte Verkaufspreis für einen Story Point 800 EUR (8 * 100 EUR pro Stunde). 

Dieser wird geteilt in:

  • Einen fixen Anteil von 400 EUR pro Story Point
  • Einen variablen Anteil von 50 EUR/Stunde (800 EUR – 400 EUR / 8 Stunden pro Story Point)

Zusätzlich wird ein reduzierter Preis für einen unvorhergesehenen Komplexitätszuwachs mit 100 EUR pro Story Point festgelegt.

In unserem Beispiel möchten wir den Anteil gleichmäßig splitten. Die Abbildung unten zeigt die Auswirkungen im Vergleich zu einer ausschließlichen Abrechnung über Story Points oder Stunden. Bei einer Abrechnung ausschließlich über Story Points oder Stunden liegt das volle Risiko immer bei einer der beiden Vertragsparteien. Nicht so beim kombinierten Modell. Bei diesem Modell wird das Risiko aufgeteilt.

Wie kann die Aufteilung erfolgen?

Sehen wir uns im nächsten Schritt an, wie sich diese Aufteilung auf drei unterschiedliche Szenarien auswirkt. Gehen wir hierfür davon aus, dass der Gesamtumfang des Angebots 1.000 Story Points beträgt. 

1. Szenario: Genaue Einhaltung der Planung

Es wurden folgende Leistungen erbracht: 

  • 1.000 Story Points
  • 8.000 Stunden

Diese wurden wie folgt abgerechnet:

  • 1.000 Story Points * 400 EUR = 400.000 EUR
  • 8.000 Stunden * 50 EUR = 400.000 EUR

Damit ergeben sich Gesamtkosten von 800.000 EUR und ein durchschnittlicher Verkaufspreis einer Teamstunde von 100 EUR. Die anfänglichen geschätzten Kosten bzw. der Verkaufspreis pro Teamstunde werden damit für beide Seiten erfüllt. 

2. Szenario: 5 % weniger Komplexität, 10 % weniger Aufwand

Es wurden folgende Leistungen erbracht: 

  • 950 Story Points (5 % Reduktion)
  • 6.840 Stunden (10 % Reduktion der Stunden pro Story Point * Anzahl der gelieferten Story Points)

Diese wurden wie folgt abgerechnet:

  • 950 Story Points * 400 EUR = 380.000 EUR
  • 6.840 Stunden * 50 EUR = 342.000 EUR

Damit ergeben sich Gesamtkosten von 722.000 EUR. Die Projektkosten für den Auftraggeber sinken. Der durchschnittliche Verkaufspreis einer Teamstunde beläuft sich auf rund 106 EUR. Der Verkaufspreis für eine Teamstunde steigt für den Auftragnehmer.

3. Szenario: 30 % mehr Komplexität, 15 % mehr Aufwand

Es wurden folgende Leistungen erbracht: 

  • 1.300 Story Points (30 % mehr Komplexität)
  • 15.600 Stunden (15 % mehr Aufwand pro Story Point * Anzahl der gelieferten Story Points)

Diese wurden wie folgt abgerechnet:

  • 1.000 Story Points * 400 EUR = 400.000 EUR
  • 300 Story Points * 100 EUR = 100.000 EUR (reduzierter Preis für unvorhersehbare Komplexität)
  • 15.600 Stunden * 50 EUR = 780.000 EUR

Damit ergeben sich Gesamtkosten von 1.280.000 EUR. Die Gesamtkosten für den Auftraggeber steigen. Der durchschnittliche Verkaufspreis einer Teamstunde liegt bei rund 82 EUR und sinkt demnach für den Auftraggeber.

Vereinfacht ergeben sich dadurch für Auftragnehmer und Auftraggeber folgende Konsequenzen abhängig vom jeweiligen Szenario:

Risikoteilung für Auftragnehmer und Auftraggeber

Die Bedeutung von Checkpoints

Eine wichtige Komponente des kombinierten Modells ist der Checkpoint. An diesem überprüfen Sie, ob die getroffenen Annahmen noch stimmen. Der Checkpoint kann zum Beispiel nach sechs Sprints gesetzt werden. Hier sollen Fragen geklärt werden, wie:

  • Stimmt die angenommene Effizienz der Umsetzung? 
  • Nimmt die Komplexität im Verlauf der Detaillierung sehr stark zu? 
  • Konnten wir die anfänglichen Annahmen prüfen und technische Risiken abmildern?

Erfahrung und Vertrauen sind entscheidend

Es ist wichtig, dass Sie den Aufwand pro Story Point und die Geschwindigkeit des Entwicklungsteams (Velocity) kennen. Daher sollte zumindest eine initiale Phase in genau dem Projekt-Setup starten, sodass eine realistische Einschätzung von Story Points möglich ist. Das kombinierte Modell ist somit ein Modell, dass auf Erfahrung basiert. Und auf Vertrauen. 

Sind Erfahrung und Vertrauen gegeben, ist diese Modell gut geeignet, um das Risiko zwischen den beiden Vertragsparteien gleichmäßig zu verteilen. Das kombinierte Modell schafft zwei Vertragsparteien, die gleichberechtigt miteinander kommunizieren und arbeiten können.


Richard Brenner TechTalk

Haben Sie Fragen?

  • Sie wollen mehr zum Thema Preisgestaltung für Software Verträge wissen ?
  • Sie wollen in Ihrem Unternehmen ein Umfeld entwickeln, um die Arbeit nach agilen Methoden zu ermöglichen?

BItte kontaktieren Sie Richard Brenner gerne via eMail oder auf LinkedIn mit Ihren Fragen.

 

Wie finde ich den passenden agilen Anbieter für mein Projekt?

Der Preis ist häufig das entscheidende Kriterium, wenn es um die Auswahl eines agilen Anbieters geht. Denn es ermöglicht, die verschiedene Angebote einfach zu vergleichen und so eine scheinbar sichere Auswahl zu treffen. Zumindest auf den ersten Blick. 

Wenn Sie jedoch die Eignung des Anbieters außer Acht lassen oder zu gering bewerten, können sich die anfänglichen Einsparungen schnell revidieren. So kann es sein, dass der Anbieter die Anforderungen des Projektes nicht erfüllt und das Projektteam darunter leidet. Wenn Sie am falschen Ende sparen, sind die zusätzliche Kosten und der Zeitaufwand deutlich höher, als die Einsparungen zu Beginn. 

Wir zeigen Ihnen, welche Qualitätskriterien aus unserer Sicht wichtig für agiles Vorgehen sind und wie Sie in einem strukturierten Prozess den richtigen Anbieter für Ihr agiles Projekt auswählen können.

Kriterien für die agile Anbieterauswahl

Es ist wichtig, dass Sie sich bereits vor dem Auswahlprozess mit dem Thema Qualitätskriterien beschäftigen. Nur so können Sie wissen, worauf Sie bei den Auswahlgesprächen achten müssen. Unser Meinung nach sollten Sie auf jeden Fall folgende Kriterien berücksichtigen:

  • Erfahrung Agilität: Je mehr Erfahrung ein Anbieter mit agilen Methoden hat, desto besser. Nur wenn eine „Agile Culture“ gelebt wird, kann auch eine agile Projektentwicklung erfolgreich sein.
  • Eingespieltes Team: Ein eingespieltes Team ist einem neu zusammengestellten Team vorzuziehen. Denn eingespielte Teams können oftmals ein Vielfaches der Produktivität eines neuen Teams erzielen. Bei längeren Projekten sollten Sie außerdem die Fluktuation im Team berücksichtigen. Wir kennen die Thematik insbesondere bei Offshore-Teams, in denen einzelne Entwickler jederzeit getauscht werden können.
  • Direkte Kommunikation: Dieser Faktor ist für agile Projekte besonders wichtig. Es muss sichergestellt sein, dass Ihre Experten mit den Experten des Anbieters direkt zusammenarbeiten können — im Idealfall sogar im gleichen Scrum-Team. Aus unserer eigenen Erfahrung kommt es häufig zu Problemen, wenn es zu viele Übergaben zwischen den einzelnen Teammitgliedern gibt. Entscheidungen müssen schnell, ohne langwierige Entscheidungswege getroffen werden können. 
  • Erfahrung Domäne: Die Erfahrung in der Domäne spielt ebenfalls eine wichtige Rolle — vor allem auf dem Level der Teammitglieder. Es werden oft internationale Referenzen genannt, das entsprechende Team besitzt diese Erfahrungen jedoch nicht. 
  • Culture Fit: Es wichtig, das Mindset und die Entwicklungsprozesse des Anbieters zu verstehen. Sie sollten im Vorfeld prüfen, inwieweit diese zum eigenen Unternehmen passen und eine enge Zusammenarbeit ermöglichen.
  • Grad der Abhängigkeit: Es ist sinnvoll, zu überlegen, wie man den Grad der Abhängigkeit zum Anbieter auch im weiteren Verlauf gering hält. Eine Möglichkeit ist es, auf offene Standards zu setzen. Diese ermöglichen zu einem späteren Zeitpunkt einen leichteren Anbieter wechseln bzw. eigene Entwickler zu schulen, die am Produkt entwickeln. 
  • System Architektur: Es ist entscheidend, dass die Architektur der neuen Lösung zur bestehenden Systemlandschaft passt. Ein völlig neuartiges System mit neuen Technologien erhöht die Komplexität und erschwert später die Wartung, wenn die Skills nicht ausreichend innerhalb der Organisation vorhanden sind. Die Abhängigkeit zum Hersteller wird dadurch auch erhöht.
  • Wartung: Nachdem die Software entwickelt ist, beginnt die Wartungsphase. Diese dauert bekannterweise weitaus länger als die Entwicklung. Daher sollten Sie die Strategien der Anbieter für diese Phase prüfen und testen, wie schnell sie z. B. auf unvorhergesehene Fehler wie Produktions-Incidents reagieren.

Neben den Qualitätskriterien sollten Sie als Kunde Ihre wichtigsten NFRs (Nichtfunktionale Anforderungen; engl. Non-functional Requirements), wie Security, Skalierbarkeit, Testbarkeit  kennen. Nur so können Sie im Auswahlprozess überprüfen, ob die Anbieter diese erfüllen können und diese direkt kommunizieren. Andernfalls kann es zum Beispiel sein, dass Sicherheitsanforderungen zu deutlich höheren Kosten oder im schlimmsten Fall gar nicht vom System umgesetzt werden können. Bekannterweise beeinflussen NFRs die System-Architektur stärker als funktionale Anforderungen. Daher kann es im schlimmsten Fall sein, dass ein Produkt diese NFRs gar nicht mehr umsetzen kann.

In 4 Schritten zum passenden agilen Anbieter 

Diese Vorüberlegungen bieten die Grundlage für einen strukturierten Prozess, mit dem Sie die Anbieter anhand der wichtigsten Kriterien in vier Schritten auswählen können. 

1. Vorauswahl treffen

Wenn Sie eine Ausschreibung für ein agiles Projekt starten, werden Sie eine Reihe von Angeboten erhalten. Im ersten Schritt geht es darum, eine Vorauswahl der Angebote vorzunehmen. 

In der Regel wird die Vorauswahl von der Einkaufsabteilung getroffen. Diese wählt die Anbieter anhand der zuvor beschriebenen Qualifikationskriterien und des Preises aus. 

 2. Intensive Gespräche führen

Nachdem die Vorauswahl getroffen wurde, finden intensive Gespräche zwischen Ihren Experten und den Experten des Anbieters statt. Diese Gespräche dienen dazu, den ersten Eindruck zu validieren. 

Zusätzlich können in dieser Phase Anforderungen, wie die NFRs angesprochen werden, um den Anbietern eine detaillierte Vorstellung zu geben, was von ihm während der Projektumsetzung erwartet wird.

 3. Prototypen-Phase durchführen

Die Prototypen-Phase ist eine entscheidende Phase, die jedoch häufig nicht gemacht wird. Vor allem, wenn Sie mit den Anbietern noch nicht zusammengearbeitet haben, sollten Sie diese Phase auf keinen Fall überspringen. 

Die Prototypen-Phase wird im Idealfall sogar mit mehreren ausgewählten Anbietern durchgeführt. Das Ziel dieser Phase ist es, die Zusammenarbeit anhand von lauffähiger Software zu beurteilen. Dadurch erhalten Sie ein viel besseres Verständnis, ob die Zusammenarbeit mit einem Anbieter funktioniert und ob alle Qualitätskriterien erfüllt werden können. 

Wichtig hierbei: Sie sollten bei der Prototypen-Phase darauf achten, dass diese mit dem finalen Team durchgeführt wird. Die Mitarbeiter, die für die spätere Produktentwicklung zuständig sein werden, sollten bereits in dieser Phase in der finalen Konstellation am Prototypen arbeiten.

4. Produktentwicklung starten

Die Software, die während der Prototypen-Phase entsteht, sowie das Feedback der Experten über die Zusammenarbeit mit dem Anbieter dient als Entscheidungsgrundlage, um die Auswahl weiter zu reduzieren. Am Ende dieser Phase sollten Sie einen Anbieter auswählen, mit dem Sie die Produktentwicklung durchführen.
Bevor es jedoch in die Entwicklungsphase geht, steht die Vertragsverhandlung an. Bei agilen Projekten gibt es einige Fallstricke, auf die Sie bei der Vertragsgestaltung achten sollten. Wir haben Ihnen die wichtigsten Tipps zusammengefasst, um eine solide Vertragsgrundlage für Ihre agilen Projekte zu schaffen.

Der Auswahl-Funnel zur Findung des passenden agilen Anbieters

Der Preis ist nicht das entscheidende Kriterium

Der Preis ist in der Regel nicht das beste Auswahlkriterium, selbst wenn es auf den ersten Blick so scheint. Es sich wichtig, sich im Vorfeld über die wichtigsten Qualitätskriterien bewusst zu sein und diese in einem strukturierten Prozess für die möglichen Anbieter zu validieren.

Der folgende Fragenkatalog bietet Ihnen dabei eine erste Hilfestellung zur Beurteilung der Anbieter-Qualität:

  • Wie groß ist die Erfahrung des Anbieters mit agilen Methoden?
  • Ist sichergestellt, dass ich ein eingespieltes, erfahrenes Team bekomme? Habe ich direkten Einfluss auf die Personen, die in meinem Team arbeiten?
  • Ist eine direkte Kommunikation der Teammitglieder zwischen Kunde und Anbieter sichergestellt?
  • Hat der Anbieter und insbesondere das Team, das mein Projekt umsetzt Erfahrung in meiner Domäne?
  • Bei länger laufenden Initiativen: Wie hoch ist die Fluktuation der Personen im Team?
  • Kennen Sie Ihre nicht-funktionalen Anforderungen?
  • Wie direkt können Sie mit dem Umsetzungsteam kommunizieren?
  • Ist das Umsetzungsteam vielleicht direkt Teil des eigenen Teams?
  • Wie gut ist der agile Anbieter in der Wartungsphase?

Richard Brenner TechTalk

Haben Sie weitere Fragen zur Auswahl von agilen Anbietern?

Oder wollen Sie in Ihrem Unternehmen ein Umfeld entwickeln um die Arbeit nach agilen Methoden zu ermöglichen?

Bitte kontaktieren Sie Richard Brenner via eMail oder auf LinkedIn mit Ihren Fragen.


Klassische oder agile Verträge: So finden Sie die passende Vertragsart

Klassische Projekte und deren Verträge haben eine entscheidende Schwäche. Obwohl sie ein großes Maß an (vermeintlicher) Budget-Sicherheit bieten, können sie bei der Geschwindigkeit der schnelllebigen Unternehmenswelt kaum noch mithalten.

So wird aus der Sicherheit, genau zu wissen, wann ein Produkt fertig ist und welche Funktionen es umfasst, die Gefahr, ein veraltetes Produkt zu erhalten, das nicht mehr den aktuellen Anforderungen entspricht.

Gerade bei komplexen Softwareproblemen stoßen Sie mit klassischen Verträgen schnell an die Grenze. Denn in der modernen Softwareentwicklung wird zunehmend agil entwickelt. Das bedeutet: Weder das Produkt, das geliefert wird, noch wann das Produkt fertig wird, stehen zu Beginn der Zusammenarbeit eindeutig fest. Vertraglich lässt sich dies nur über Verträge abdecken, die eine agile Zusammenarbeit ermöglichen.

In diesem Artikel erfahren Sie, was genau „agile Verträge“ ausmacht und ob sie auch für Ihr Projekt geeignet sind.

Vier entscheidende Unterschiede von klassischen und agilen Verträgen

Zunächst einmal schauen wir uns an, wie sich klassische und agile Verträge unterscheiden. Ich habe die wichtigsten Unterschiede in einem kurzen Video auf den Punkt gebracht:

Es lässt sich festhalten, dass sich die beiden Vertragsarten vor allem in vier grundlegenden Punkten unterscheiden:

  1. Projektumfang: Bei einem klassischen Werkvertrag ist der Projektumfang meistens auf einen langen Zeitraum festgelegt. Das bedeutet, alle Anforderungen werden in einem Pflichtenheft gesammelt und anschließend abgearbeitet. Nicht so bei einem agilen Vertrag. Hier können Änderungen nach jedem Sprint vorgenommen werden. Dadurch kann das Entwicklerteam Feedback zeitnah berücksichtigen. Die Basis ist jedoch auch hier ein Backlog, bei dem der Aufwand zu Beginn geschätzt wird.
  2. Projektzeitraum: Der Zeitpunkt der Releases und Milestones ist bei klassischen Verträgen festgelegt. Bei agilen Verträgen gilt: Das Projekt ist beendet, sobald das Produkt fertig ist. Natürlich können Sie auch einen Zeitraum bzw. eine fixe Anzahl an Sprints festlegen. Ergebnisse, die zu diesem Zeitpunkt bereits vorhanden sind, können Sie übernehmen.
  3. Release-Zyklen: Die Release-Zyklen bei klassischen Projekten betragen mehrere Monate bis Jahre. Bei agilen Verträgen gibt es im Idealfall nach jedem Zyklus (Sprint) einen Prototypen, der getestet werden kann.
  4. Budget: Das Budget kann bei beiden Vertragsmodellen sowohl nach T&M (Time & Material, oder auf deutsch Vertrag auf Zeit und Materialbasis) abgerechnet werden oder auch fixiert werden. Im agilen Fall heißt das, dass eine bestimmte „Run-Rate“ des Teams budgetiert wird.
  5. Steuerung: Hier gilt Output vs. Outcome. Bei klassischen Verträgen wird zum Beispiel gemessen, ob das Entwicklerteam zum Zeitpunkt X den entsprechenden Milestone erreicht hat. Bei agilen Verträgen wird geprüft, ob das Produkt die Anforderungen der Kunden erfüllt.

Zusammenfassend lässt sich festhalten, dass bei klassischen Verträgen ganz klar die Budget-Sicherheit im Vordergrund steht. Agile Verträge geben dem Entwicklerteam deutlich größere Freiheiten, auf kurzfristige Änderungen zu reagieren und regelmäßig Feedback zu sammeln, um schlussendlich das beste Produkt für Kunden zu entwickeln.

So finden Sie die passende Vertragsart

Ob agile oder klassische Verträge die bessere Wahl sind, hängt von zwei grundlegenden Faktoren ab: der Projektkomplexität und der Arbeitsweise in Ihrem Unternehmen.

Komplexe Projekte brauchen agile Verträge

Agile Verträge sind nicht für jedes Projekt die richtige Wahl. Es ist entscheidend, dass Sie sich im Vorfeld Gedanken machen, welche Aufgaben im Projekt anfallen und wie gut Sie sie definieren können. Hierbei können Ihnen folgende Fragen helfen:

  • Sind Sie sich sicher, dass sich die Rahmenbedingungen während des Projekts nicht ändern werden? 
  • Sind Sie sicher, dass sich der Wert für Ihr Unternehmen genauso erreichen lässt, wie Sie es definiert haben?
  • Bestehen die Aufgaben ausschließlich aus wiederkehrenden Tätigkeiten?
  • Sind die Risiken der technischen Implementierung gering bzw. sind die Anforderungen klar formulierbar? 
  • Ist das Projekt eher klein und nicht langfristig angelegt, sodass Sie kein Team für die Betreuung und Weiterentwicklung des Produkts benötigen?
  • Kaufen Sie ein standardisiertes Produkt, dass keine Integration in ein bestehendes Produkt benötigt? 

Wenn Sie alle Fragen mit „Ja“ beantworten können, ist vermutlich ein klassischer Vertrag ausreichend. Ihr Projekt und die Anforderungen lassen sich im Vorfeld bereits genau definieren. Anders sieht es aus, wenn Sie nur einige der Fragen mit „Ja“ beantworten können. In diesem Fall ist es lohnenswert, sich das Thema agile Verträge genauer anzuschauen.

Keine agilen Verträge ohne agile Arbeitsweise

Die Komplexität Ihres Projekts ist allerdings nicht der einzige entscheidende Faktor. Wenn Sie in Ihrem Unternehmen nicht in der Lage sind, agile Projekte umzusetzen, bringt Sie auch ein agiler Vertrag nicht weiter.

Denn um das bestmögliche Produkt agil zu entwickeln, muss bei einer Anbieter-Kunden-Beziehung eine Kultur herrschen, die eine enge Zusammenarbeit und Anpassungsfähigkeit ermöglicht. Die Grundlage bilden hierbei die Prinzipien des agilen Manifestos. Ursprünglich stammt das Manifesto aus der Softwareentwicklung. Es lässt sich jedoch auch auf Unternehmen übertragen. 

Überlegen Sie sich, ob Sie in Ihrem Unternehmen eine Basis für agile Projekte besitzen und folgende Punkte gewährleisten können:

  • Feedback-Zyklen: Sie sind in der Lage, schnelle Feedback-Zyklen (idealerweise alle 2 bis 4 Wochen) umzusetzen und dem Entwicklerteam kontinuierliches Feedback zu geben.
  • Transparenz: Sie können während des Projekts vollständige Transparenz gewährleisten. Das bedeutet das Entwicklerteam hat einen Zugang zum Backlog, dem Fortschritt der Implementierung unterschiedlicher Features und den Ergebnissen nach jedem Feedback-Zyklus.
  • Variabler Projektumfang: Sie sind damit einverstanden, dass das Feedback nach jedem Zyklus mit in die weitere Produktentwicklung einfließt. Projektumfang und Aufgaben können entsprechend angepasst werden. Die Option muss auch vertraglich festgehalten werden, zum Beispiel über eine „Changes for free“ Klausel. Sie ermöglicht Änderungen im Backlog, sofern sie keinen Mehraufwand bedeuten.
  • Effektive Zusammenarbeit: Sie können eine enge Zusammenarbeit zwischen sich, dem Entwicklerteam und dem Endkunden gewährleisten. Idealerweise arbeitet das Team an einem Ort, sodass eine direkte und informelle Kommunikation möglich ist. Wenn der Anbieter eine Person vor Ort stellt, die eine aktive Rolle im Projekt übernimmt (keine Managementrolle, die nur als Verbindung zum Entwicklerteam dient) ist dies von Vorteil.

Wenn Sie die folgenden Punkten umsetzen können und außerdem komplexe Projekte haben, sind agile Verträge vermutlich eine gute Wahl. Sollten Sie noch kein agiles Mindset in Ihrem Unternehmen etabliert haben und dennoch mit agilen Projekten arbeiten wollen, können Sie sich mit Workshops diesem Ziel nach und nach annähern. Schreiben Sie uns gerne, wenn Sie weitere Informationen benötigen. 

Wann ist eine agile Arbeitsweise sinnvoll?

Kein Projekt ist wie das andere. Und kein Unternehmen gleicht dem anderen. Daher können für die Zusammenarbeit mit Ihren Kunden und Partnern nicht immer die gleichen starren Rahmenbedingungen gelten.

Überlegen Sie sich im Voraus, welche Rahmenbedingungen Sie für das jeweilige Projekt benötigen und ob Ihr Unternehmen eine agile Arbeitsweise lebt. Vor allem, wenn Sie komplexe Projekte umsetzen wollen, bieten eine agile Arbeitsweise bzw. agile Verträge eine solide Grundlage.


Haben Sie weitere Fragen zur Umsetzung von Projekten mit agilen Verträgen?

Oder wollen Sie in Ihrem Unternehmen ein Umfeld entwickeln um die Arbeit nach agilen Methoden zu ermöglichen?

Bitte kontaktieren Sie mich gerne via eMail oder auf LinkedIn mit Ihren Fragen.