Scrum und Co.

Schlank planen, agil entwickeln, Kosten einhalten

Prof. Dr. Volker Gruhn gründete 1997 die adesso AG mit und ist heute Vorsitzender des Aufsichtsrats. Er ist Inhaber des Lehrstuhls für Software Engineering an der Universität Duisburg-Essen. Sein Forschungsschwerpunkt in diesem Bereich bezieht sich auf mobile Anwendungen. Gruhn ist Autor und Co-Autor von rund 200 nationalen und internationalen Veröffentlichungen und Konferenzbeiträgen.
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.