Agile Contracting braucht einen neuen Bewertungsmaßstab
Seit die agile Transformation im Zuge der digitalen Transformation in vollem Gange ist, geraten nun auch die Verträge, die mit Outsourcing-Lieferanten geschlossen werden immer weiter in den Fokus. Wie die 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 noch sicher und für alle zufriedenstellend schließen zu können.
Selbst wenn beide Parteien mit großartigen Vorsätzen und wechselseitigen Versprechungen und Vertrauen ins Rennen gehen, folgt der baldigen Enttäuschung in der Regel eine noch größere Ernüchterung unter der die Geschäftsbeziehungen oft sehr leiden.
In Deutschland kommt seit 2017 noch die besondere AÜG Situation hinzu, die das Ganze noch besonders belastet bzw. eine noch schnellere Lösung erfordert, denn die T&M Variante fällt praktisch für langlaufende Projekte aus. 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 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, bzw. heute gemacht werden muss.
Agile Entwicklung gibt es nun schon eine gewisse Zeit 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 eignen sich nicht besonders, weil sie relativ und individuell sind. Zudem ist die Frage, wie technische Backlog Items (Enabler Storys, Spikes, Tasks) 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 von IBM 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 so. 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.
- Story Points
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. Story Points 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. SAFe stört sich inzwischen etwas an der Team-individualtät und schlägt deshalb in skalierten Umfeldern sogenannte „normalisierte Storypoints“ vor. Ein nicht uninteressanter Ansatz, der für unseren Zweck sicher hilfreich wäre, da sie in das Ganze etwas mehr Objektivität hineinbringen würden.
- Functionpoints
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. Vermutlich waren sie damals ihrer Zeit zu weit voraus, denn heute in der agilen Entwicklungswelt würden sie sehr viele Probleme lösen helfen.
In jedem Fall fokussieren sich Functionpoints, wie der Name ja schon sagt auf die Funktionalität einer Software, genau genommen auf die funktionale Größe eines Features. 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 Faktoren Aufwand und Nutzen einigermaßen beschrieben. Jetzt brauchen wir noch einen sehr einfachen Weg, um beide in eine Größe zusammenzubringen, also „agile Functionpoints“ zu erzeugen.
- Agile Functionpoints
Wir gruppieren Storys, für die später Storypoints geschätzt werden in drei Gruppen, die ihren funktionalen Charakter beschreiben und geben jeder Gruppe einen Multiplikator Wert.
Dies sind Product Backlog Items (PBI), die technical Depts behandeln oder Enabler sind oder tatsächliche notwendig technische Refactorings. Diese sollten in Scrum eigentlich gar nicht so oft auftreten, praktisch lassen sie sich aber auch nicht vermeiden. Da wir sie nicht lieben, erhalten sie den Faktor 0,5. Die vermindernde Wirkung dieses Faktors hat natürlich auch eine psychologische Komponente.
Dies sind PBIs, die bestehende Funktionalität verändern oder erweitern. Wir geben solchen Storys den Faktor 1,0.
Diese sind Auftraggebern am Liebsten. Es sind User Storys, 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 und das ist uns diesen Kompromiss absolut wert. 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.
SAFe setzt hier insbesondere bei Features und Epics in Vorbereitung auf PI Plannings auf sogenannte Value-Points, die wiederum in Fibonacci-Zahlen ausgedrückt werden und auch relativ zu anderen Backlog Items bestimmt werden. Ziel dabei ist es die WSJF (weighted shortest job first) Priorisierungsmethodik zu unterstützen. Es wird sich zeigen, ob dieses Verfahren vom Markt eine Chance erhält und Verbreitung findet. Entscheidend wird sein, wie einfach es zu handhaben ist und wie leicht es die Akteure (Business Owner, Stakeholder, etc.) verstehen und natürlich ob es vertragstauglich ist.
Agile Contracting
Jetzt ist es Zeit, mit allen Zutaten, das Verfahren zu beschreiben, wie ein „agile Contract“ zustande kommt. Hier bringen wir nun viele der ganz oben erwähnten Ansätze zusammen.
⇒ Lesen Sie hier wie die Scrum Velocity richtig berechnet wird
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 schon mal arbeiten können und den wir unseren Vertragspartnern zumuten können.