Agile Contracting braucht einen
neuen Bewertungsmaßstab

Seit die agile Transformation in vollem Gange ist, geraten nun auch die Verträge, die mit Outsourcing-Lieferanten geschlossen werden immer weiter in den Fokus. Mit der Wasserfall-Implementierungsmethodik kommen nun auch die klassischen Festpreis-Werkverträge und die Time-and-Material-Dienstleistungsverträge (T&M) zunehmend unter Druck und aus der Mode. Die Gründe dafür liegen auf der Hand. Festpreis-Werkverträge lassen das Risiko ausschließlich auf der Lieferantenseite, während T&M-Dienstleistungsverträge genau das Gegenteil tun. Sie verschieben das Risiko vollständig auf die Seite des Auftraggebers.

 

Da Software heute immer komplexer wird, gleichzeitig die Time-to-Market Anforderungen immer härter werden und demzufolge gute Spezifikationen schlichtweg nicht mehr möglich sind, enthalten Projekte für beide Seiten zu große Risiken, um Verträge auf Basis von Festpreisen oder T&M schließen zu können. Selbst wenn beide Parteien mit großartigen Vorsätzen und wechselseitigen Versprechungen ins Rennen gehen, folgt der baldigen Enttäuschung in der Regel eine noch größere Ernüchterung unter der die Geschäftsbeziehungen sehr leiden.

 

In Deutschland kommt seit 2017 noch die besondere AÜG Situation hinzu, die das Ganz noch besonders belastet bzw. eine noch schnellere Lösung erfordert.

 

Im Grunde sind von der Problematik nahezu alle Unternehmen betroffen. Einige wissen es vermutlich nur noch nicht. Aber die Zahl agiler Projekte dürfte bald die 80 Prozent erreicht haben, Tendenz schnell steigend.

 

Wenn eine zu implementierende Software nicht detailliert und gut beschrieben ist, gibt es immer Probleme. Der Verzicht auf eine vollständige und detaillierte Spezifikation ist sicher der größte Kompromiss, der in der Softwareentwicklung gemacht werden kann. Agile Entwicklung gibt es nun schon eine gewisse Weile und alle Beteiligten haben inzwischen mit ihren Festpreisverträgen oder T&M Verträgen hinreichend schlechte Erfahrungen gesammelt. Die Zeit ist nun wirklich mehr als reif, um dieses Problem anzugehen, aller objektiven Schwierigkeiten zum Trotz.

 

Und es gibt die ersten Ansätze auch schon

Gekappte T&M Verträge, indikative Festpreise, Verträge auf Basis von Storypoints sind einige dieser Ansätze. Alle nicht ganz problemlos. Aber alle haben sie das Ziel, das Risiko einigermaßen gleichmäßig zwischen beiden Parteien zu verteilen. Was ihnen aber allen irgendwie fehlt und was die Sache daher etwas unbefriedigend erscheinen lässt, ist, dass ihnen ein objektiver Bewertungsmaßstab fehlt.

 

Storypoints beispielsweise eigenen sich nicht besonders, weil sie relativ und individuell sind. Zudem ist die Frage, wie technische Stories oder auch Bugfixings gewertet werden, etc. Dennoch lassen sie sich wenigstens irgendwie in Zahlen ausdrücken und sind Bestandteil der agilen Methodik.

 

Es gab mal ein Maß, welches objektiv und absolut war, die Functionpoints. Sie wurden bereits in den 1970er Jahren entwickelt und drücken eigentlich das aus, was wir gerne hätten: ein unabhängiges Maß für die funktionale Größe einer Software, ohne dabei Bezug auf bestimmte Funktionalität (Features) zu nehmen. Kurz, ich könnte bei einem Lieferanten 5 Kilogramm (Functionpoints) Software bestellen und überlege mir die konkreten Features erst im Verlaufe der Entwicklung. Dies ist eine etwas verkürzte Darstellung, aber im Prinzip funktioniert das. Und das schon seit den 1970ern und genau darin liegt ihr Problem. Wenn sie es in den letzten 50 Jahren nicht geschafft haben populär zu werden, dann passiert das aller Voraussicht nach wohl auch nicht mehr. Schuld daran ist vermutlich unter anderem, dass die Erhebung – wenn sie auch nicht besonders kompliziert ist – dann den meisten wohl aber doch zu aufwendig erscheint.

 

Wir benötigen ein Maß und/oder ein Verfahren, welches zur agilen Methodik nicht im Widerspruch steht, d.h. sie muss möglichst einfach, transparent und nahezu voraussetzungslos einsetzbar sein. Dafür werden wir aber bereit sein müssen, einige Kompromisse in Kauf zu nehmen. Eine Hundertprozent-Lösung ist kaum zu erwarten und möglicherweise auch gar nicht erforderlich. Wir brauchen eine Lösung, die aufgrund der oben genannten Eigenschaften von beiden Seiten akzeptierbar ist, weil sie die Interessen beider Parteien reflektiert.

 

Was wir gerne hätten, wären so etwas wie „Agile Functionpoints“ und dazu ein Verfahren, welches in der Lage ist, diese hinreichend präzise, einigermaßen objektiv, vor allem aber einfach zu erheben.

Agile Functionpoints im Einsatz

Ein solches Verfahren könnte folgendermaßen aussehen. Schauen wir uns zunächst noch einmal die Storypoints an. Bei allen Nachteilen haben sie den Charme, dass sie bereits Bestandteil der agilen Methodik sind und damit – wenn auch oft missverstanden und falsch verwendet – eine gewisse Übung in ihrem Umgang vorausgesetzt werden darf. Storypoints repräsentieren die Komplexität einer Story in Bezug zu ihrem Aufwand. Sie sind strenggenommen weder Komplexität noch Aufwand, sondern etwas dazwischen, was erklärt, warum sie so gerne missverstanden werden. Ihr Zweck ist nicht ein Estimate in Bezug auf ein Commitment herzustellen, sondern vielmehr einen Trend des Besserwerdens (Velocity) erkennbar zu machen. Daher sind sie (team)individuell und relativ und verwenden die Fibonacci-Folge, welche ja erfunden wurde, um Wachstumspopulationen mathematisch zu beschreiben. In jedem Fall sind sie relativ leicht zu schätzen.

 

Functionpoints sind nahezu das Gegenteil. Sie bestimmen objektiv und absolut die funktionale Größe einer Software. Ursprünglich wurden sie mal von IBM erfunden, um sogenannte make-or-buy-decisions zu unterstützen. Sie haben allerdings nichts mit Aufwand zu tun und sind in der agilen Welt weitgehend unbekannt. In jedem Fall fokussieren sich Functionpoints, wie der Name ja schon sagt auf die Funktionalität einer Software. Das kommt dem agilen Ansatz, der ja eine effektive und daher featureorientierte Entwicklung einführt, schon sehr nahe, getreu dem Motto aus dem agilen Manifest: business value first.

 

Wenn wir beides in bestimmter Weise einsetzen, dann ist der Weg zu „agile Functionpoints“ vielleicht gar nicht mal so weit. Natürlich setzen wir mehr auf die dahinter liegende Idee und vermischen nicht einfach beide Welten. Wir wollen ja die Vorteile extrahieren, nicht beim Vermischen auch die Nachteile in Kauf nehmen. Wir extrahieren nur die Vorteile der Konzepte, soweit wie möglich. Und wir konzentrieren uns auf das eigentliche Ziel: einen fairen Kompromiss zwischen Auftraggeber und Auftragnehmer in der Gestaltung eines agilen Vertrags zu finden und dies auf eine einfache, transparente und agile Art und Weise. Die Einfachheit ist hier ein ganz entscheidendes Kriterium. Komplizierte Verfahren setzen sich nie durch.

 

Sehr abstrakt und stark vereinfacht, aber nicht ganz falsch sehen wir Storypoints zunächst für ein Maß des Aufwandes. Nicht sehr präzise, nicht sehr korrekt, aber dem Prinzip nach akzeptabel.

 

In gleicher Weise stehen Functionpoints für den Nutzen. Schön nach dem Motto: viel Funktionalität, viel Nutzen. Auch nicht ganz korrekt und im Bewusstsein, dass feature-creep natürlich hier ein Risiko darstellt.

 

Dennoch ist mit beiden irgendwie Aufwand und Nutzen einigermaßen beschrieben. Jetzt brauchen wir einen sehr einfachen Weg, um beide in eine Größe zusammenzubringen, also „agile Functionpoints“ zu erzeugen.

 

Wir gruppieren Stories, für die später Storypoints geschätzt werden in drei Gruppen, die ihren funktionalen Charakter beschreiben und geben jeder Gruppe einen Multiplikator Wert.

Technische Story: dies sind Stories, die technical Depts behandeln oder Enabler sind oder tatsächliche notwendig technische Refactorings. Diese sollten in Scrum eigentlich gar nicht auftreten, praktisch tun sie es leider. Da wir sie nicht lieben, erhalten sie den Faktor 0,5. Die vermindernde Wirkung dieses Faktors hat natürlich auch eine psychologische Komponente.

Funktionale Stories: Dies sind Stories, die bestehende Funktionalität verändern oder erweitern. Wir geben solchen Stories den Faktor 1,0.

Hochfunktionale Stories: Diese sind Auftraggebern am Liebsten. Es sind Stories, die neue Funktionalität implementieren, insbesondere Kernfunktionalität. Sie erhalten den Faktor 1,5.

 

 

Allen Graubereichen zum Trotz die zwischen den einzelnen Gruppen liegen mögen, beschränke ich mich hier auf nur drei Gruppen. Wir erinnern uns, das Verfahren muss extrem einfach sein.

 

Wenn wir nun die geschätzten Storypoints mit dem funktionalen Faktor multiplizieren, nehmen wir damit eine funktionale Gewichtung vor. Damit erreichen wir, dass sowohl Auftraggeber als auch Auftragnehmer ein gleichermaßen hohes Interesse haben, dem Produkt möglichst schnell Kernfunktionalität zuzufügen, ohne komplett technische Architekturen außer Acht zu lassen.

 

Im Verfahren bringen wir nun viele der ganz oben erwähnten Ansätze zusammen. Ein Projekt startet zunächst mit einer kurzen T&M Phase, in der die ersten Stories geschätzt und implementiert werden. Damit werden die ersten Benchmarks für Storypoints gesetzt und der Dienstleister wird sehen, wieviel tatsächlicher Aufwand bei der Implementierung von Stories mit solcher Komplexität getätigt wird (lesen Se hier wie die Velocity richtig berechnet wird). Damit nicht sinnloser Aufwand betrieben wird, also der Aufwand in einem guten Verhältnis zum Nutzen – sprich zur Funktionalität – stehen bleibt, werden die Stories mit „agile Functionpoints“ versehen und es wird ein Preis ermittelt, der sowohl Aufwand repräsentiert als auch Funktionalität belohnt.

 

Daraus kann dann entweder ein inidikativer Festpreis hochgerechnet werden, oder beide Parteien einigen sich auf ein Kontingent von „agile Funktionpoints“, da diese nun einen Preis haben. Es liegt jetzt im Interesse des Lieferanten, die Velocity seines Teams zu erhöhen und eine so stabile und flexible Architektur zu wählen, dass er möglichst wenig Architektur refactoren muss und künftig mit wenig Aufwand viel Funktionalität hinzufügen kann. Glücklicherweise hat der Auftraggeber das gleiche Interesse und darin liegt das große Potential dieses Verfahrens.

 

Auch die Storypoints wirken hier als gutes Korrektiv, da die Zahl der Storypoints nicht steigt, wenn die technische Architektur verhundst ist und der nominelle Aufwand für neue Implementierungen immer weiter steigt. Der relative Aufwand – und dafür stehen ja Storypoints – steigt nicht, da die Storypoints die Komplexität einer Story in Bezug auf den Aufwand im Vergleich zu einer Referenzstory abbilden.

 

Klar ist natürlich auch, dass solche Einrichtungen wie „Definition of Done“ und „Definition of Ready“ in agile Contracts mehr sein müssen, als nur ungelesene Vertragsanhänge oder hübsche Confluence-Pages.

 

Gut möglich bis gewiss, dass dieser Ansatz noch nicht alle Fragen klären wird. Das Konzept von agile Funtionpoints wird ganz sicher noch weiterentwickelt werden müssen. Wir sind aktuell noch am Beginn einer Reise in vollständige Agilität. Aber die Zeit drängt und wir benötigen heute einen Ansatz, mit dem wir arbeiten können.