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.
- Knackpunkte in agilen Entwicklungsteams
Seit die Verfasser des "Agilen Manifests" im Jahr 2001 den klassischen Phasenmodellen wie Wasserfall und V-Modell den Kampf angesagt haben, erlebt die Softwareentwicklung eine tief greifende Veränderung. Mittlerweile ist Agilität fast zu einem Hype-Begriff geworden. Darüber gerät gelegentlich aus dem Blick, was die Methode tatsächlich leisten kann und an welchen Stellen das ursprüngliche Dokument von 2001 aufgrund von Projekterfahrungen aus mehr als einer Dekade präzisiert werden sollte. - Crossfunktionale Teams aus Spezialisten und Generalisten bilden
- Teamübergreifende Governance sichern
- Verantwortungsvolles und pro-aktives Handeln der agilen Teammitglieder
- Ständige Kommunikation innerhalb und zwischen Sprint-Teams
- An agiler Community aktiv teilnehmen und auf Best Practices setzen
- Verständigung über technisches Rahmenwerk (Architektur) herstellen
- Bereitstellung von Testdaten und Ausführung von Integrationstests sichern
- Dokumentation im Hinblick auf Compliance nicht vernachlässigen
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.