in Agilität, Methoden, Standards, Vertragsphilosophie, Wasserfallmodell

Agil ist erfolgreicher als Wasserfall! Mag sein, aber was sagt die Rechtsabteilung dazu?

Die Standish Group, deren Chaos-Report seit 1994 jährlich die Erfolgs- bzw. Misserfolgsquote von IT-Projekten darstellt, kommt auf Grundlage von über 10.000 analysierten Software-Projekten zu einem klaren Befund: „The results for all projects show that agile projects have almost four times the success rate as waterfall projects, and waterfall projects have three times the failure rate as agile projects. … However, note that the smaller the project, the smaller the differenence is between the agile and the waterfall process“ (CHAOS Report 2015).
Agile Ansätze haben allerdings in stark budgetgetriebenen Unternehmen und bei öffentlichen Auftraggebern viele Vorurteile zu überwinden. Ein Dilbert-Cartoon bringt diese sehr gut auf den Punkt. Hier wird Agilität offenbar als das Chaos gesehen, bewirkt aber laut Chaos-Report genau das Gegenteil, nämlich eine höhere Erfolgsrate.

Warum ist der Umgang mit agilen Vorgehensweisen für viele Unternehmen so schwierig? Spitz könnte man sagen, weil Agilität ehrlich ist. Es wird klar gesagt, dass jedes größere Softwareprojekt mit einer Reihe von beträchtlichen Unsicherheiten behaftet ist. Kein noch so genaues Lasten- und Pflichtenheft garantiert, dass alle Eckpunkte des magischen Dreiecks (Ergebnis, Budget, Termin) im Voraus fixiert werden können. Je mehr man versucht, diese Vorgaben zu fixieren, umso schlimmer wird es: zwischen Projektinitialisierung und Fertigstellung vergeht entsprechend mehr Zeit. Selbst wenn anfangs die Anforderungen wirklich vollständig und eindeutig beschriebenen worden wären, durch die Entwicklung der Projektumwelt werden sie bis zum Fertigstellungstermin in großen Teilen obsolet. Je schneller man also liefert, umso eher werden die anfangs getroffenen Annahmen halten.

Dass der Aufwand eines Software-Projektes von sehr vielen Faktoren abhängt, die nur mit vielen Annahmen und entsprechender Unsicherheit prognostiziert und kontrolliert werden können, habe ich in einem anderen Beitrag schon beschrieben. Ist trotzdem eine Kombination von Agilität und Fixpreis möglich? Im Prinzip ja, man muss nur genügend hohe Risikozuschläge akzeptieren. Also de facto nein!

Letztlich gilt hier eine Unschärferelation wie in der Physik. Wenn man eine oder zwei Ecke(n) des magischen Dreiecks genau bestimmt, ist die bzw. sind die verbleibende(n) Ecke(n) entsprechend ungenauer bestimmbar. Also konkret: Ergebnis fix – Aufwand variabel. Aufwand fix – Ergebnis variabel. Und wenn man z.B. nur den Aufwand fixiert kann man sowohl beim Ergebnis als auch beim Termin drehen usw.

Ein Buch macht Hoffnung.

Wenn man es allerdings liest, kommt die Ernüchterung. Es werden durchaus sinnvolle Methoden beschrieben, Aufwandsschätzungen zu erstellen und schrittweise zu verfeinern, die wunderbare Quadratur des Kreises gelingt allerdings nicht. Die Lektüre lohnt sich trotzdem, nur darf man den verkaufsfördernden Titel nicht beim Wort nehmen.

Die Vertragsphilosophie agiler Projekte

Ich habe in der Festschrift für den CIO des österreichischen Justizministeriums versucht, die implizite Vertragsphilosophie agiler Projekte zu beschreiben. Da dieses Buch nicht mehr verfügbar ist, hier eine aktualisierte Darstellung:

Jedes Projekt agiert auf Grundlage von Vereinbarungen zwischen den beteiligten Organisationseinheiten bzw. Unternehmen, wobei diese mehr oder minder explizit und formalisiert sein können. Ob diese Vereinbarungen tatsächlich als schriftlicher und detaillierter Vertrag vorliegen oder nicht, ist unwesentlich. Professionelle Verträge sind immer ein wesentlicher Erfolgsfaktor, wenn allerdings ein Vertrag in Widerspruch zum tatsächlichen Vorgehen im Projekt steht, behindert dies die Projektarbeit ebenso schwerwiegend, wie ein guter Vertrag diese wesentlich erleichtert. Daher wird hier von einer Vertragsphilosophie gesprochen, die dem Handeln aller Beteiligten zugrunde liegen sollte, wenn ein Projekt mit sinnvoll eingesetzten agilen Elementen abgewickelt werden soll.

Zunächst muss festgehalten werden, dass für wesentliche Teile eines typischen IT-Projektes klassische Vertragsmodelle sinnvoll und notwendig sind, so z.B. für Planungsleistungen, Lizenzen, Infrastrukturleistungen etc. Ebenso gilt dies für die Schätzung des Gesamtaufwandes des Vorhabens (z.B. anhand eines Lastenheftes). Dies ist ja schon eine notwendige Grundlage für die Entscheidung, ob ein Projekt überhaupt gestartet werden soll.

Für jene Teile des Projektes, in denen die Entwicklung und/oder die Anpassung von Software erfolgt, gelten teilweise andere Regeln. So wird für die agil abzuwickelnden Teile des Vorhabens ein passendes Leistungsvolumen (Skills, Kapazitäten, Durchlaufzeit) eingekauft. Die Laufzeit des Entwicklungsprojektes wird in gleich lange Intervalle („Iterationen/Sprints“) aufgeteilt, wobei in jeder Iteration Software geliefert wird, die vom Kunden/Anwender getestet werden kann.

Die Feinsteuerung erfolgt aufgrund einer Aufwandsbewertung der Features („Story Points“/Planaufwand). Die konkreten Iterationsinhalte werden zu Beginn nur grob geplant, nach jeder Iteration erfolgt eine Aktualisierung, die Inhalte der jeweils nächsten und meist auch übernächsten Iteration werden im Detail fixiert.
Ein Spezifikum agiler Projekte ist auch die unveränderliche Iterationsdauer („Time Boxing“), innerhalb einer Iteration nicht realisierte Features werden nicht durch Terminverschiebung nachgeliefert, sondern zurück in den „Backlog“ gestellt und in einer späteren Iteration eingeplant.

Auf Grundlage der tatsächlichen Iterationsergebnisse wird eine regelmäßige Hochrechnung durchgeführt, die je Iteration abgearbeiteten Features („User Stories“) werden in dem für agile Projekte typischen „Burn-Down-Chart“ dargestellt. Letztlich ist dies die allgemein bekannte Earned-Value Darstellung, wenn auch mit umgekehrten Vorzeichen: man zeigt, wie die noch zu leistende Arbeit reduziert wird („burned down“), während der Earned Value die bereits geleistete Arbeit abbildet.
Da am Ende jeder Iteration funktionierende Software geliefert werden muss, zeichnet sich die Fortschrittsmessung solcher Projekte durch eine höhere Aussagekraft und Robustheit gegenüber Fehleinschätzungen des Arbeitsfortschritts aus. Werden Abweichungen vom geplanten Fortschritt je Iteration („Velocity“) erkannt, bleibt auch solchen Projekten nicht erspart, darauf mit den üblichen Maßnahmen zu reagieren, die da sind:
– Projektabwicklung optimieren
– Features streichen/zurückstellen
– Kapazität erhöhen
– Zusätzliche Iterationen und Verschiebung des Endtermins.

Als Auftraggeber von Projekten mit agilen Elementen ebenso wie als Projektmanager muss man darauf achten, die spezifischen Herausforderungen der mit agiler Methodik abgewickelten Projektteile zu erkennen und darauf adäquat zu reagieren. Wird in Projektaufträgen bzw. in Verträgen eine Philosophie der Projektsteuerung festgeschrieben, die das nicht richtig adressiert, gerät man entweder in einen vertragsfreien Raum oder man kollidiert ständig mit Vertragsbestimmungen, die nicht zum tatsächlichen Vorgehen passen.

Generell muss man feststellen, dass agile Softwareentwicklung im Kern auf einer Aufwandsverrechnung beruht, da ein fixer Werklohn mangels detaillierter Ergebnisbeschreibung nicht definiert werden kann. Vieles spricht dafür, auch in einer agilen Welt zu Beginn eine Spezifikation zu erarbeiten, ob das ein „traditionelles“ Fachkonzept ist oder User-Stories, kommt auf die Kultur und die verfügbaren Skills der beteiligten Personen und das Umfeld des Projektes an.

Man darf den Detaillierungsgrad nicht übertreiben und vor allem muss man sich dessen bewusst sein, dass es jedenfalls Veränderungen während der Umsetzung geben wird. Es bleibt also auch hier eine gewisse Unschärfe. Diese wird allerdings nach den Erfahrungen des Autors von Entscheidungsträgern, die agilen Methoden skeptisch gegenüberstehen bzw. damit keine Erfahrung haben, stark überschätzt: Jeder weiß aus eigener Erfahrung, dass Fixpreise trotz detaillierten Lasten- und Pflichtenheften durch Change Requests regelmäßig ausgehebelt werden. Daher erscheint eine Aufwandschätzung mit eingestandener Bandbreite sowie einer darauf aufsetzenden Projektsteuerung durch Burn-Down-Charts als die ehrlichere und de facto auch wirksamere Methode. Man muss allerdings der hier sichtbar gemachten Unsicherheit ins Auge blicken können, wozu nicht alle Auftraggeber bereit und in der Lage sind.
Eine zentrale Herausforderung ist also: professionelle Projektsteuerung ersetzt detaillierte Ergebnisdefinition. Abweichungen werden früh erkannt, können aber nicht an einem vertraglich fixierten detaillierten Pflichtenheft gemessen werden. Daher müssen geeignete Prozesse (auch vertraglich) definiert und gelebt werden.

Sachlich gesehen, ist das Vertrauen in die Angemessenheit der Aufwände des Realisierungspartners ein entscheidender Erfolgsfaktor. Das Aushandeln des Verzichts auf Features, um das Budget und den Endtermin zu halten, funktioniert nur, wenn die vom Auftragnehmer geschätzten Realisierungsaufwände vom Auftraggeber als angemessen und nachvollziehbar gesehen werden. Regelmäßig als überhöht empfundene Aufwandschätzungen können durchaus auf Architekturmängel zurückzuführen und daher in Wirklichkeit korrekt sein, sie sind also einer unzureichenden Projektvorbereitung geschuldet. Damit bleibt aber das Problem gleich, nur die Ursache liegt in der Vergangenheit.

Agile Projekte können daher nur gelingen, wenn es aktive und sachkundige Mitwirkungsleistungen des Kunden gibt, wobei dies im Falle einer externen Beauftragung nicht nur für die Anwenderbereiche („Business“) gilt, sondern auch für die IT-Abteilung des Auftraggebers. Dies erscheint gegenüber einem Wasserfallmodell als Mehraufwand. Ich wage die Behauptung, dass der tatsächliche Gesamtaufwand gut gemanagter agiler Projekte geringer, aber anders verteilt ist als bei Projekten nach einem Wasserfallmodell.

Ebenso gilt: Agiles Vorgehen erfordert eine vertrauensvolle Zusammenarbeit. Dafür müssen Bereitschaft und Fähigkeit zu interdisziplinärer Arbeit und social skills bei allen Beteiligten verfügbar sein.

Nachtrag im Oktober 2019: Im Preview zu SAFe 5.0 gibt es auch eine ausführliche Stellungnahme zur Vertragsgestaltung in agilen Projekten, hier der Link.

Was heißt eigentlich „agil“?

Die Standish Group macht keine klaren Aussagen, wie sie Agilität definiert. Tatsächlich gibt es verschiedene Ausprägungen. Dazu eine Übersicht mit Links zu den Quellen:

Die Grundlage für alles: Das agile Manifest.
Der Marktführer: Scrum.
Leider zu wenig bekannt ist DSDM: Dynamic Systems Development Method.
Verdient ebenfalls mehr Aufmerksamkeit: Lean Software Development.
Flexibel mit anderen Ansätzen gut kombinierbar: Kanban.
Mein Favorit, wenn es in einem Projekt eng wird: Extreme Programming. 
Der Geheimtipp auf Grundlage der „Theory of Constraints: Critical Chain Project Management. 
Eine Integration verschiedener agiler Methoden auf Unternehmensebene, wenn auch starr und überladen: SAFe.
Der ideale Rahmen, um die Vorgehensweise zu finden, die in der konkreten Situation am besten funktioniert:
Disciplined Agile.

Schreibe einen Kommentar

Kommentar