Wenn ich Vorträge oder Workshops zu agilen Geschäftmodellen gebe, lautet eine meiner ersten Fragen an das Publikum „Wer von Ihnen ist eher Auftraggeber?“ Meist haben sich ein oder zwei Auftraggeber in das Publikum verirrt, der Rest stammt aus Softwarehäusern, die gerne agil arbeiten wollen, aber „nicht wissen, wie ich meinen Kunden dazu bringe“.

Das erstaunt: Es sollten eigentlich die Auftraggeber sein, die agile Entwicklung einfordern. Sie haben den wesentlichen Nutzen aus den Techniken:

• Sie erhalten regelmäßig lauffähige Software, die bereits früh eingesetzt werden kann. Das verringert das Risiko eines Totalausfalls erheblich und bietet zudem die Chance, bereits während der Entwicklung umzusteuern
• Sie müssen nicht alle fachlichen Inhalte ganz am Anfang festlegen, sondern können sich Optionen offen lassen, bis die Entwicklung an dieser Stelle angekommen ist
• Fachliche Diskussionen laufen am konkreten Beispiel. Ihre Fachexperten müssen nicht in abstrakten Methoden geschult werden, um eingesetzt werden zu können
• Das Controlling ist wesentlich verbessert: Statt vieler grüner Ampeln, die acht Wochen vor Systemstart „überraschender Weise“ auf rot schalten, wird Fortschritt in abgenommener Funktionalität gemessen – ein wesentlich zuverlässigeres Maß
• Sie erhalten die aus Ihrer Sicht wichtigsten Teile zuerst und behalten über die gesamte Laufzeit die Kontrolle über das, was als nächstes angegangen wird
• Sie können das Projekt beenden, wenn Sie feststellen, dass die bisher erreichte Funktionalität ausreicht; nicht erst, wenn alles implementiert ist, was Sie sich zu Anfang einmal ausgedacht haben. Das kann die Kosten schon mal um 60 oder 80 Prozent reduzieren

Warum sind dennoch eher wenige Auftraggeber an agile Konzepten interessiert? Ich denke, da kommen verschiedene Gründe zusammen:

• Die Macht der Gewohnheit führt dazu, dass sich viele Auftraggeber längst mit Prozessen arrangiert haben, die sie eher knebeln, als ihnen die nötige Freiheit zu geben. Die internen Strukturen sind an Werkverträge zum Festpreis angepasst. Andere Formen benötigten andere Strukturen, die erst aufgebaut werden müssten
• Die Vorstellung, Individualsoftware sei als „Gewerk“ behandelbar, das einmal spezifiziert nach definierter Zeit „frei Bordsteinkante“ geliefert wird, hält sich hartnäckig vor allem unter fachfremden Entscheidern, wie Juristen und Betriebswirtschaftlern. Hier ist es uns noch nicht gelungen, das notwendige Problembewusstsein zu schaffen. Zudem fehlen bisher Standard-Vertragsmodelle, um agile Entwicklung abzudecken — auch wenn es durchaus vielversprechende Ansätze gibt
• Gängige Risikobewertungen unterschätzen häufig die enorme Kosten, die von scheiternden strategischen Projekten ausgehen ebenso, wie die Wahrscheinlichkeit, dass der GAU eintritt. Zur Risikoabwehr werden Vertragsklauseln bemüht. Das verkennt, dass solche Klauseln höchstens die direkten Kosten auf den Vertragspartner abwälzen — kein Trost, wenn man selbst wegen Softwareproblemen Konkurs geht oder man den Vertragspartner schon mit einem Bruchteil des Schadens ruinieren würde
• Agile Entwicklung verlangt Entscheidungsfähigkeit auf Seite des Auftraggebers. Nicht jede Organisation kann das gewährleisten
• Last but not least: Wir haben bisher versäumt, auch nicht-technischen Auftraggebern die Ideen agiler Entwicklung nahe zu bringen.

Fazit: Agile Entwicklung ist vor allem für die Auftraggeber interessant, denen am Erfolg ihres Auftrages gelegen ist. Dann lassen sich auch organisatorische Hürden schleifen und Vertragsmodelle gestalten, die die benötigte Flexibilität aufweisen ohne beide Seiten unnötig einzuschränken.