Scrum und Co.

Schlank planen, agil entwickeln, Kosten einhalten

10.09.2014
Von 
Prof. Dr. Volker Gruhn ist Mitgründer und Aufsichtsratsvorsitzender der adesso AG. Außerdem hat er den Lehrstuhl für Software Engineering an der Universität Duisburg-Essen inne. Gruhn forscht unter anderem über mobile Anwendungen und Cyber-Physical Systems.
Die agile Softwareentwicklung schafft Beweglichkeit und Flexibilität. Das ist gut für das Produkt und schlecht für die Kostenplanung. Trotz Agilität müssen Projektinvestitionen kalkulierbar bleiben.

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.