Warum agile Softwareentwicklung?
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.
Agile Contracting - ist das die Lösung?
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:
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.
Agile in a day
Wir trainieren Ihr Team, coachen Ihre Stakeholder und führen Ihr Projekt zum Erfolg.
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.
1. Storypoints
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.
WHITEPAPER
Ein konkurrenzloses Geschäftsmodell
Der Digitalisierungsdruck ist eine tickende Zeitbombe. Die wichtige Frage hier: Wie können Sie diese Bombe „schmerzfrei“ oder mit anderen Worten: kosteneffizient, entschärfen?
2. 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.
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.
created by agile natives for agile natives
Die erste all-in-one scaled agile Projektmanagement Suite für SharePoint.
3. Agile Funktionpoints
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.
Enabler Story & Spikes
User Story
Hochfunktionale Story
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
Wie kommt ein "Agile Contract" zustande?
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.
So führen Sie Agile Contracting in Ihrem Projekt ein: 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.
