Derzeit ist zu beobachten, dass bei agilen Transformationen nur die Geschwindigkeit zählt, mit der neue Funktionen für den Endkunden implementiert werden. In Sprints werden so immer komplexere Strukturen geschaffen, die sofortigen Mehrwert für den Benutzer erzeugen sollen.
So weit, so gut – aber ist das nachhaltig?
Denn oftmals werden die zugrundeliegenden IT-Architekturen für Zwecke eingesetzt, für die sie niemals gedacht waren. Ursprüngliche Use Cases werden ausgedehnt und für Themen eingesetzt, die man eigentlich ganz anders lösen würde. Um trotzdem möglichst schnell neue Funktionen bereitzustellen, kommt es zu Kompromissen in der Umsetzung, deren Folgen sich mit der Zeit zu technischen Schulden («technical debt») anhäufen.
Keiner mag diese technischen Schulden. Sie sind in der Regel der letzte Punkt auf dem Backlog. Trotzdem müssen sie bewirtschaftet, gewartet und minimiert werden, denn ihre Entstehung lässt sich nicht vermeiden. Es braucht daher Strukturen, um solche Schulden im Laufe der Zeit proaktiv zu reduzieren, bevor sie die Umsetzung neuer Use Cases verhindern. Sprich, auch das technische Fundament muss weiterentwickelt werden.
Nur: Wie bringe ich der budgetverantwortlichen Person aus der Fachabteilung bei, dass sie in das Fundament investieren soll, wenn dies keine unmittelbaren neuen Funktionen abwirft?
Ziel: Projektrisiken ausgewogen verteilen
Zum mangelhaften technischen Fundament kommt ein weiteres Problem hinzu. In unserer Rolle als Lieferant von IT-Dienstleistungen beobachten wir, dass heute bei agilen Projekten fast ausschliesslich der Kunde die Risiken trägt. Der Lieferant stellt nur noch die vordergründig geeigneten Personal-Kapazitäten bereit – an den Arbeitsergebnissen wird er nicht mehr gemessen.
Im Gegenteil: Der Lieferant hat gar keinen Anreiz mehr, gute Qualität zu liefern, denn jede aufgeschriebene Stunde bedeutet mehr Umsatz.
Dabei haben viele Lieferanten durchaus das Profil und auch das Wissen, nicht nur Projekt- und Lieferrisiken zu übernehmen. Sie sind sogar bereit, sich am Geschäftserfolg der Applikation messen zu lassen.
Wieso teilt man den Erfolg einer Lösung nicht mit deren Schöpfer und macht ihn so zu einem integrierten Teil der Wertschöpfungskette? Dies wäre auch eine konsequente Umsetzung von agilen Paradigmen, wonach sich alle Beteiligten um die Wertsteigerung des Produkts und der Services kümmern sollten. Da gehören auch die Lieferanten dazu.
Zwei Fliegen mit einer Klappe schlagen
In so einem Zusammenarbeitsmodell übernimmt der Lieferant nicht nur die Verantwortung für den raschen Einbau neuer Funktionalitäten und Unterstützung bei Problemen in der Produktion, sondern auch für das Fundament der Applikation. Damit sorgt er dafür, dass technische Altlasten erst gar nicht entstehen bzw. abgebaut werden. So geht umfassendes Technologie-Management einer ganzen Applikation aus einer Hand!
Dabei ist für den Lieferanten noch ein anderer Aspekt äusserst interessant: Es wird immer schwieriger, Arbeitskräfte zu finden, die bereit sind, sich mit den alten Technologien auseinanderzusetzen. Wenn sie aber in der Lage sind, selber das Fundament auf dem aktuellen Stand zu halten, wirkt sich das positiv auf die Attraktivität der Arbeit aus. Und für die Kunden löst sich ein Problem, dessen sich viele noch so gerne entledigen möchten.
Der Lieferant hat also ein eigenes Interesse daran, gute Qualität zu liefern und neue Technologien einzusetzen, während der Kunde seine Projektrisiken aufteilen kann. Eine klassische Win-win-Situation.
Die Vergütung orientiert sich an der Erreichung gemeinsam definierter KPIs, die für den Geschäftserfolg des Kunden relevant sind. Diese KPIs sollten auch Elemente der Software-Qualität berücksichtigen. Wenn der Kunde erfolgreich ist, ist es der Lieferant auch – und umgekehrt. Sprich, Risiken werden geteilt und der Lieferant übernimmt Verantwortung.
Anwendung von DevOps-Prinzipien
Bei der Umsetzung der einzelnen Arbeitspakete besitzt der Lieferant einen sehr hohen Freiheitsgrad, solange er sich an die Architektur-, Compliance- und Reporting-Vorgaben des Kunden hält. Das Entwicklerteam organisiert sich dabei selber und im Sinne von DevOps-Prinzipien. Der Kunde nimmt die Rolle des Product Owner ein und erhält alle Rechte an der gebauten Lösung.
Dieser Ansatz hat einen weiteren positiven Effekt: Die Ausgaben können in der Unternehmensbilanz als operative Kosten (OPEX) aktiviert werden und binden dort kein Kapital (CAPEX). Die Bilanz wird also entlastet und flexibler, weil keine langen Abschreibungszyklen erforderlich sind. Ausserdem lassen sich diese Kosten direkt dem Verursacher zuschreiben – es entsteht eine Kostentransparenz, die es bisher nicht gab.
Für den Kunden kommt es am Ende des Tages einzig darauf an, dass er eine solide gebaute, performante und sichere Applikation nutzen kann, die für ihn über lange Zeit einen messbaren Mehrwert generiert.
