Agile Softwareentwicklung lässt viel Spielraum für Entscheidungen - auch spät im Projekt. Das ist inhaltlich sinnvoll und in gewissem Maße unvermeidbar, denn viele Softwaresysteme sind - abstrakt betrachtet - soziotechnische Systeme: Sie können als organisierte Menge von Menschen und Technologien verstanden werden, die in einer bestimmten Weise strukturiert sind, um ein spezifisches Ergebnis zu produzieren. Und sie sind nicht vollständig beschreibbar. Selbst der Versuch einer möglichst weitgehenden Vorab-Spezifikation ist, zumindest für Informationssysteme ohne ausgeprägte Risiken, unwirtschaftlich. Vieles lässt sich erst während der Entwicklung festlegen, direkt umsetzen, notfalls neu bewerten. Darin liegt gerade der Charme der Agilen Entwicklung.
Nicht viel, sondern schlanke Software muss das Ziel sein
Nachvollziehbar ist aber auch der Wunsch nach Kostentreue. Wie teuer Software wird, muss von vornherein bekannt sein. Ansonsten lösen sich grundlegende Annahmen über die Planbarkeit wirtschaftlicher Aktivitäten in Luft auf. Das sieht auf den ersten Blick nach einem Dilemma aus, das sich beim genaueren Hinsehen aber auflösen lässt.
Dazu müssen alle wirtschaftlich beteiligten Stakeholder - beispielsweise alle Beteiligten mit Budgetverantwortung oder IT-Dienstleister - auf schlanke Software verpflichten werden. Nicht viel Software darf das Ziel sein, sondern die richtige Software. Software, deren Anwendung wirklich zur Wertschöpfung beiträgt. Das kann auch bedeuten, dass nicht alles automatisiert wird. Oder dass nicht jeder selten genutzte Dialog perfekt Usability-Engineered wird.
Solchermaßen schlanke Software hat verschiedene Vorteile. Zum einen kostet sie weniger in der Entwicklung und - wahrscheinlich noch wichtiger - überflüssige Bestandteile müssen nicht auch noch weiterentwickelt, gewartet und immer wieder mit getestet werden.
Doch es gibt Ziele und Wünsche, die einer schlanker Software im Wege stehen:
Auftragnehmer, die im "Times-x-Material"-Modell denken und arbeiten, können Ziele haben, die mit schlanker Software in Konflikt geraten.
Anwender und Fachbereiche, die lange auf neue Software gewartet haben, wollen nicht in erster Linie darüber nachdenken, was weggelassen werden kann.
Unternehmensarchitekten haben ein berechtigtes Anliegen an Software-Sekundäreigenschaften.
Daraus entstehen Herausforderungen, etwa: Was sorgt jetzt für schlanke Software? Wie können alle Beteiligten auf dieses Ziel verpflichtet werden?
Die Antwort auf diese Fragen bieten Shared-Pain-/Shared-Gain-Modelle, die den Fokus auf die oben geforderte schlanke Software legen. Eines vorab: Ohne Vertrauen funktionieren solche Modelle nicht. Sobald Juristen und klassische Einkäufer die Eckdaten für Software-Lieferverträge bestimmen und darauf beharren, dass Software genauso zu bestellen sei wie Bleistifte, sollten alle lieber bei "fetter Software" bleiben, Controller für epische Change-Request-Diskussionen und -Umsetzungen engagieren und sich an viel Software erfreuen.
Agilität im Spannungsfeld von Plan und Chance
Mehr als zehn Jahre nach dem Manifesto for Agile Software Development erfährt das Thema heute neuen Auftrieb. Vor allem der Punkt "Respondig to Change Over Following a Plan" spiegelt sich in moderner, agiler Softwareentwicklung wider. In digitalen Unternehmen müssen IT-Abteilungen mobiler, elastischer und auch agiler werden, um den wachsenden Anforderungen gerecht zu werden. Der Wunsch nach schnell sichtbaren Ergebnissen trägt agile Ansätze - Scrum, Feature Driven Development, Kanban oder Adaptive Software Development - zunächst in die Entwicklungsabteilungen. Von dort aus erobern sie weitere Bereiche. Agilität prägt so innerhalb kurzer Zeit das ganze digitale Unternehmen - gemeint sind damit Unternehmen, deren Kerngeschäftsprozesse nahezu komplett digitalisiert sind. Besonders Anwendungen des Mobile Computing und oberflächenintensive Lösungen erfordern kurze Entwicklungszyklen. Die Programmierer müssen Funktionen permanent an neue Anforderungen und Technologien anpassen.
Die schnell sichtbaren Zwischenergebnisse in der Agilen Entwicklung tragen dazu bei, dass der Auftraggeber Schritt für Schritt eine immer klarere Vorstellung von der vollständigen Anwendung bekommt. Ein bereits funktionierender Teil der Software vermittelt ein konkretes Bild des Endproduktes.
Bei aller Begeisterung für Agilität zeigt der Blick in die Unternehmensrealität: Zahlreiche agile Projekte sind mit hehren Zielen gestartet; am Ende waren das Beharrungsvermögen von Personen und Prozessen und die "Plan-Gravitation" aber stärker. Die Agilisierung von Anwendungsentwicklung, Betrieb und anderen Abteilungen ist häufig ein langwieriger und schwieriger Veränderungsprozess.
Agile Entwicklungskonzepte eignen sich nicht für jede Form von Software und jedes Unternehmen: Nicht für Software, die sicherheitskritisch ist, die von Hunderten Programmierern erstellt wird, die in Unternehmen mit "ausgewiesener Schuldzuweisungskultur" entwickelt wird oder an der technisch geprägte Entwickler ohne Branchenverständnis arbeiten.
Für Unternehmen geht es nicht um die Frage, ob agile Softwareentwicklung sinnvoll ist, sondern um das geeignete Maß an Agilität (siehe Balancing Agility and Discipline: A Guide for (text only) by B.Boehm.R.Turner). Gesucht wird "gezähmte Agilität". Eine der wichtigsten Fragestellungen jenseits der rein technischen Handhabung von Agilität ist, wie sich agile Vorgehensmodelle kommerziell niederschlagen.
Die Flexibilität des Starren: Agile Festpreise - oder etwas Ähnliches
Agile Festpreise in Reinkultur kann es nicht geben. Wenn das Modell es zulässt, dass regelmäßig neu priorisiert wird, können die Projektbeteiligten nicht zusagen, welcher Funktionsumfang bis wann geliefert wird. Und auch nicht, wie teuer er wird. Kurze Phasen - der nächste Sprint, vielleicht auch noch der übernächste - sind überschaubar. Für solche Phasen sind feste Preise möglich (siehe unten: "Agile Festpreise im ganz Kleinen").
Für lange Zeiträume wird es schwieriger; Agilität verbessert die Prognosefähigkeit nicht gerade. Und trotzdem gibt es Modelle, die das Einhalten von Preiskorridoren gewährleisten (siehe unten: "Agile Festpreise im Mittelgroßen"). Diese Modelle werden unter dem Namen "Shared Pain / Shared Gain" zusammengefasst. Auftraggeber gewinnen gemeinsam (bei "schlanker Software") und verlieren gemeinsam (bei "fetter Software"). Ein Beispiel für Shared-Pain-/Shared-Gain-Modelle ist adVANTAGE (siehe adVANTAGE: A Fair Pricing Model for Agile Software Development Contracting).
Agile Festpreise im ganz Kleinen (ein Sprint)
Für kurze Zeiträume können die Beteiligten Anforderungsstabilität annehmen und Anforderungsänderungen ausklammern. Selbst ohne vollständige Spezifikation können sie die Funktionalitäten, die sie in den nächsten vier Wochen realisieren sollen, abschätzen und kalkulieren (Die neben den zu entwickelnden Funktionen anfallenden Grundausgaben für Product Owner, Scrum Master, Elaboration, Integrationstest und Release-Erstellung werden im Preismodell durch eine Grundpauschale abgedeckt, die in geeigneter Weise auf die einzelnen Features umgelegt wird).
Das ist nichts anderes als ein fester Preis für ein kurzes Entwicklungsprojekt. Für einen kurzen Zeitraum schließt das Team späte Anforderungen aus und verschiebt sie in den nächsten Sprint. Am Ende steht kein agiler Festpreis für ein gesamtes Projekt, sondern viele Festpreise für viele aufeinander folgende Sprints. Allerdings ohne dass klar ist, wie viele Sprints folgen, wie lange das Projekt dauert und welche Funktionalitäten am Ende zur Verfügung stehen werden. Im Grunde also ein agiles Vorgehen mit festpreissicheren Einzelschritten.
Agile Festpreise im Mittelgroßen - ein paar Sprints
Eine Preisdiskussion für jeden Sprint kann schnell ermüdend sein. Oft können die Projektbeteiligten zusammenhängende, aufeinander folgende Sprints und die in ihnen zu entwickelnden Funktionalitäten zusammenfassen. Festpreisfähigkeit im engeren Sinn ist hier nicht mehr gegeben. Das Team kann den Aufwand nur grob abschätzen, entsprechend besteht das Risiko, dass die Schätzung überschritten wird. Jetzt greifen Modelle, in denen dieses Risiko zwischen Auftraggeber und Dienstleister geteilt wird.
Vereinbart ist ein Tagessatz von 1.000 Euro, für die Entwicklung einer Funktion schätzt das Team fünf Tage. Tatsächlich arbeiten sie sieben Tage an der Funktion. Die zwei zusätzlichen Tage werden nur mit einem geringeren Tagessatz – beispielsweise 600 Euro – vergütet. Beträgt die Entwicklungszeit aber nur vier statt der ursprünglich geschätzten fünf Tage, werden die tatsächlich eingesetzten plus der Hälfte der eingesparten Tage berechnet, also viereinhalb Tage. Wird ein geplantes Feature innerhalb eines Sprints nicht fertig, wird es nicht bezahlt. Die Vervollständigung wird für den nächsten Sprint eingeplant. An dem Preis des Features ändert sich nichts. Mit einem möglichen Overspent für dieses Feature im folgenden Sprint wird umgegangen wie oben beschrieben. |
So können Auftragnehmer und Auftraggeber gemeinsam verfolgen, welche durchschnittlichen Tagessätze pro Sprint zum Tragen kommen (siehe Abbildung unten). Auf dieser Grundlage lässt sich auch erkennen, ob bestimmte Arten von Features falsch geschätzt wurden oder ob bestimmte Features besonders teuer waren.
Foto: adesso
Einen Zeithorizont, der länger als ein paar Sprints ist, werden Kunde und Dienstleister so kaum überblicken können. Die Illusion der langlaufenden Festpreisprojekte ist aber aufgelöst; die Beteiligten erkennen die Kosten frühzeitig, die sich aus neuen Wünschen ergeben. Nämlich indem sich diese Wünsche in unmittelbar anstehende Sprints niederschlagen.
So etwas Ähnliches wie agile Festpreise im Großen - für ganze Projekte
Es klingt ein wenig nach der Quadratur des Kreises: Keine Spezifikation und trotzdem ein fester Preis? Und das im Großen, so dass er für das ganzes Projekt gilt? Ohne Change-Request-Theater? Hundertprozentig wir das nicht funktionieren; aber auch hier kommen die Beteiligten mit fair verteiltem Schmerz und fair verteilter Freude weiter.
Das "Shared Pain, Shared Gain" bezieht sich darauf, dass Auftraggeber und Dienstleister - als Projektpartner - die Risiken der Agilität auch im Budget gemeinsam tragen. Mithilfe des agilen Vorgehens wollen sie in jeder Beziehung zum optimalen Ergebnis gelangen. Und das gelingt am besten, wenn alle Beteiligten ein Interesse daran haben, möglichst schlanke Software zu erstellen.
Ein konkretes Shared-Pain-/Shared-Gain-Modell ist adVANTAGE. Dem Ansatz liegt folgender Gedanke zugrunde: Zunächst muss der Auftraggeber seine Erwartungen - das heißt Zweck, Einsatzgebiet, Benutzer und vieles mehr - grob beschreiben. Daraus werden sogenannte "User Stories" abgeleitet. Diese definieren zu entwickelnde Features unscharf. Sie reichen jedoch aus, um ein ungefähres Bild des Aufwandes zu erhalten, den die Implementierung umfasst. Pro Story wird der reine Entwicklungsaufwand geschätzt und durch die Ergänzung von Triangulation plausibilisiert. Die Zusammenfassung aller Schätzungen ergibt ein vorläufiges, grobes Gesamtbudget und umreißt einen Zeitrahmen.
Nachdem alle Anforderungen geschätzt sind, werden sie vom Auftraggeber priorisiert. Die Reihenfolge sollte sich dabei an diesen Fragen orientieren: "Welche Stories müssen unbedingt umgesetzt werden, um live gehen zu können?" Welche kann man zur Laufzeit nachreichen?" Dies sollten die entscheidenden Kriterien sein, nicht die Komplexität einer Funktion.
Foto: adesso
Die vorläufige und grobe Schätzung des nötigen Gesamtbudgets geht gemeinsam mit dem Zielbudget und dem Zieltermin in eine Priorisierung der Projektaufgaben ein. So entsteht ein gemeinsamer Orientierungspunkt für das Projektteam. Über den gesamten Projektverlauf hinweg sind diese Rahmenbedingungen (Zielbudget, Zieltermin und Schätzung einzelner Features) für alle Beteiligten transparent. Bei Hinzunahme und Weglassen von Features werden die Daten entsprechend angepasst.
Für diese grobe Schätzung (insbesondere die Suche nach vergessenen Aufgaben) benötigt das Unternehmen dreierlei:
Jemanden, der die aktuelle Anwendung und Anwendungslandschaft kennt und Auskunft darüber gibt.
Jemanden, der die Domäne kennt und vergleichbare Software auf angestrebter Technologie schon einmal gebaut hat.
Einige Wochen Zeit.
Nun müssen die Verantwortlichen das Unsicherheitsniveau bewerten. Typischerweise geht es hier um Fragestellungen wie: Stimmt die Schätzung mit hinreichend großer Sicherheit oder sind besonders auffällige Unwägbarkeiten aufgetreten? Hatten die Projektbeteiligten in den ersten Wochen bereits eine einheitliche Vorstellung oder muss erst noch ein Kompromiss gefunden werden? Stimmen die Ideen von Management beziehungsweise Projektsponsoren und zukünftigen Anwendern überein? Und - ganz entscheidend - gibt es eine klare Entscheidungsstruktur und Entscheidungsfreude?
Das Projekt umfasst 1.000 Personentage. Jeder Tag Aufwand wird mit 1.000 Euro berechnet. Da alle Beteiligten sich darüber im Klaren sind, dass es eine vage Schätzung ist, vereinbaren sie einen Ungewissheitskorridor: Wird das Projekt mit weniger als 1.000 Tagen Aufwand geliefert, erhält der Lieferant für jeden nicht geleisteten Tag zusätzlich 150 Euro. Werden mehr als 1.000 Personentage Aufwand benötigt, greift eine Preisstaffel: Zwischen 1.001 und 1.200 Personentagen kostet ein Personentag 800 Euro, zwischen 1.201 und 1.500 Personentagen 600 Euro, jenseits von 1.501 kostet er nichts. 100.000 Euro werden als Prämie gewährt, wenn 1.200 Personentage nicht überschritten werden. Werden – aus welchen Gründen auch immer – mehr Tage benötigt, entfällt die Erfolgsprämie komplett. In diesem Beispiel wird deutlich, wie das gemeinschaftliche Interesse an schlanker Software im Prozess verankert wird: Komplexe Lösungen sind für alle Beteiligten unattraktiv, effiziente Umsetzungen werden für beide Seiten belohnt. Planerisch wird die Budgetkalkulation so umgesetzt, dass von Beginn an der geleistete Aufwand mit der initialen Abschätzung und mit der Detailschätzung vor Implementierung verglichen wird. |
Grenzen agiler Festpreise
Nicht jedes Projekt eignet sich für agile Entwicklung. Genauso ist nicht jedes agile Projekt für die agilen Festpreise im Mittleren oder Großen geeignet. Bedingungen, die die Durchsetzung solcher Modelle erschweren sind:
Öffentliche Ausschreibungsverfahren und ähnliche Rahmenbedingungen, die annehmen, Softwareentwicklung wäre ein reiner Produktionsprozess: Wenn die Notwendigkeit der Reaktion auf späte Anforderungen und die Chance des flexiblen Umgangs mit frühen Anforderungen grundsätzlich verneint werden, hat der Agile Festpreis keine Chance.
Mangelndes Domänenwissen: Die Machbarkeit agiler Festpreise im Großen hängt an der Verlässlichkeit der initialen Schätzung. Die lässt sich ohne konkrete Erfahrungen mit ähnlichen Projekten, ohne umfangreiches Branchenwissen und ohne Marktverständnis nicht gewährleisten.
Mangelnde Entscheidungsfreude: In der Agilen Entwicklung, gerade im Kontext agiler Festpreise, muss kontinuierlich entschieden werden. Welches Feature wie umgesetzt und welches weggelassen werden kann. Und das in aller Regel, ohne dass die komplette Tragweite der Entscheidung sicher abgesehen werden kann. Das müssen die Beteiligten wollen und können; die Unternehmenskultur muss tolerant mit Fehlern umgehen.
Die Welt der Agilen Festpreise ist noch bunt und nicht ganz gesetzt. Die obigen Varianten sind der Versuch einer Ordnung. Weder sind sie trennscharf noch sind sie im Einzelnen fest definiert und in Stein gemeißelt. Jedes Projekt hat spezifische Rahmenbedingungen, die berücksichtigt werden müssen. Vielleicht gibt es nur Projektteile, die per agilem Festpreis behandelt werden können; vielleicht nur einzelne Features. Eventuell ändert sich die Festpreisaffinität sogar während der Projektlaufzeit.
Aber die Ausführungen zeigen: Die logische Unmöglichkeit agiler Festpreise im Großen kann nicht als Argument dafür herhalten, intelligente Modelle aus der Klasse "Shared Pain / Shared Gain" gar nicht erst zu betrachten. (jha)