Agilität bedeutet nicht Beliebigkeit

31.03.2020

Aus Sicht der Softwareentwickler sind agile Verfahren die Lösung. Die Beschaffung von Entwicklungsleistungen ist für den IT-Einkauf jedoch eine besondere Herausforderung:

In einem Bietermarkt mit wenigen Wettbewerbern sind die Preise meistens schlecht zu verhandeln und die Bewertung der Projektergebnisse bei Festpreisprojekten ist oft schwierig.

Aus Sicht der Softwareentwickler sind agile Verfahren die Lösung

Das Zeitalter verwirrender Verfahren zur Sicherung der Ergebnisse in der Softwareentwicklung ist mit dem agilen Manifest beendet. Es erwartet uns ein geradezu zauberhaftes Zeitalter, in dem Individuen gemeinsam mit dem Kunden eine funktionierende Software durch Interaktion erstellen. Veränderungen sind Teil dieses Entwicklungsprozesses, der durch einfache Methoden in der Zusammenarbeit geregelt wird. Kosten müssen nicht mehr verhandelt werden, da sie durch das vom Auftraggeber festgelegte Budget fixiert sind. Der IT-Einkauf muss lediglich die Tagessätze akzeptieren.

Bilder aus einem sonnigen Kalifornien?

Bedauerlicherweise sieht die Realität anders aus. Projekte werden nicht abgeschlossen, Kosten explodieren und Fachabteilungen sind sowohl unzufrieden als auch überfordert. Die Verheißungen einer agilen Welt sind nicht erfüllt worden. Enttäuschung breitet sich aus, und es stellt sich die Frage: War früher alles besser?

Seit den fünfziger Jahren gibt es Software, die unabhängig von der Hardware entwickelt wird. Damit verbunden ist die Herausforderung, die Erstellung von Software zu organisieren und betriebswirtschaftlich zu bewerten.

Mit der Spezialisierung von Softwareentwicklern ist die Notwendigkeit entstanden, die Vorstellungen der Anforderer mit der Umsetzungskompetenz von Entwicklern zu verknüpfen. Die daraus entstandenen Verfahren haben sich primär an klassischen Projektvorgehen orientiert und diese für die IT-Konzepte spezifiziert. Wasserfall- und V-Modell, Lasten- und Pflichtenheft, Function Point Methode und COCOMO waren und sind die Mittel zur Steuerung der Softwareentwicklung. Diese dienten auch dem IT-Einkauf in der Bewertung von Preisen und in der vertraglichen Festschreibung von Abnahmebedingungen.

Nostalgische Gefühle an eine goldene IT-Zeit, die täuschen. In der Vergangenheit hat es gleichermaßen Projektverzug, Budget-überschreitung und unzufriedene Endanwender aufgrund schlechter Software gegeben. Gerade weil die etablierten Verfahren in der Softwareentwicklung nicht so funktionierten, wie es in der Theorie beschrieben wird, wurde Scrum so populär.

Wie lassen sich die Vorteile der jeweiligen Methoden mit den Anforderungen an die Beschaffung von Softwareentwicklungsleistungen optimal kombinieren?

Inditango hat ein Vorgehen entwickelt, dieses Problem zu lösen. Die Elemente einer partnerschaftlichen Vertragsvereinbarung bestehen aus der externen Vergabe des Requirements Engineering, der Vereinbarung eines Sprintfestpreises, der Risikoteilung und der Verlässlichkeitsbelohnung (Bounty-Regel).

Im Requirements Engineering erhält der Dienstleister eine Vergütung auf Zeit und Material für seine Konzeption und hat eine erhöhte Chance, bei der Ausschreibung der Leistungen den Zuschlag zu erhalten. Der Auftraggeber hat eine erhöhte Sicherheit bezüglich des geforderten Leistungsumfangs und der zu erwartenden Kosten.

Durch den Sprintfestpreis kann der Auftragnehmer seinen Gewinn bei effizienter Entwicklung verbessern und der Auftraggeber erhält dafür Kostensicherheit und eine geklärte Gewährleistung.

Die Risikoteilung ermöglicht es dem Aufragnehmer, zu Beginn des Projektes realistisch zu schätzen und dem Auftraggeber, bei eintretender Budgetüberschreitung die zusätzlichen Kosten fair zu verteilen.

Die Bounty-Regel erhöht zwar im Falle vollständiger Zuverlässigkeit des Dienstleisters die Kosten für den Auftraggeber.
Zugleich sichert sie aber, dass die Güte der Software erhöht und die Methoden agiler Entwicklungsverfahren gestärkt werden.

Um die vier genannten Vertragselemente in einer Zusammenarbeit mit einem Dienstleister zu verankern, müssen sie in ein Vertragskonstrukt überführt werden.

 

Zurück