Agile und TBM: IT zum Besseren verändern

*Dean Leffingwell ist der Entwickler des Scaled Agile Framework (SAFe) und Mitbegründer von Scaled Agile, Inc. Er arbeitet mit Firmen zusammen, die agile Prozesse von wenigen auf Dutzende – oder sogar Hunderte – von Teams skalieren, die große Systeme und Softwarelösungen entwickeln. 

Ein IT-Analyst fasst es treffend zusammen: „Vor ein paar Jahren setzten Unternehmen noch auf agile Lösungen und gaben 5 bis 10 Millionen US-Dollar für agile Programme aus. Auf der Grundlage relativer Investitionen und Governance spielte es keine Rolle, wie und wofür das Geld ausgegeben wurde. Es war ein interessantes Experiment, und den Unternehmen gefielen die Ergebnisse. Doch jetzt stehen Programme an, die Investitionen von 50 bis 100 Millionen US-Dollar oder mehr erfordern und die mit Agile umgesetzt werden. Das ändert alles.“

Dieser Aspekt hat die Aufmerksamkeit der C-Suite auf sich gezogen, da vor allem CIOs und CFOs erkennen, dass sie die flexible Methodik nicht länger ignorieren können – sie ist dabei, die meisten Prozesse im Unternehmen zu übernehmen. Wenn sie jetzt keine neuen Finanz- und Governance-Modelle einführen, werden sie überrollt.

Heute zeigt sich die Leistung von Unternehmen, die agile Entwicklung erfolgreich skaliert haben, in einer häufigeren Veröffentlichung, einer schnelleren Markteinführung, einer höheren Qualität und einer besseren Mitarbeitermotivation. Die Produktivität kann erheblich steigen, um etwa 30–50 %, was die Markteinführungszeit in der Regel um das Zwei- bis Dreifache oder sogar noch mehr verkürzt. Das Mitarbeiterengagement steigt, da der Code der Mitarbeiter schneller auf den Markt kommt und sie schneller Feedback von den Benutzern erhalten.

Fakt ist: Agile ist keine Modeerscheinung. Es ist ein Megatrend, der die Wirtschaft – und die IT – zum Besseren verändert.

Agile erfordert heute eine andere Art der Auseinandersetzung mit dem Unternehmen. Früher sagte das IT-Team vielleicht: „Okay, hier ist das, wonach Sie gefragt haben.“ Das Unternehmen reagiert möglicherweise auf die Lieferung (ein Jahr später) und sagt: „Es ist nicht wirklich das, was wir wollten – und übrigens, die Bedürfnisse des Unternehmens haben sich so entwickelt, dass jetzt etwas anderes erforderlich ist.“

Die IT hatte traditionell ein gutes Konzept: Zusammenarbeit mit den Business-Analysten, Notieren der Spezifikationen, Erstellen des Business Case, Erstellen der Lösung und dann weiter.

Aber so funktioniert es nicht wirklich. Die Lösung der IT ist nur dann gut, wenn die Geschäftsinhaber sie für gut befinden. Es spielt keine Rolle, ob es so in den Spezifikationen stand. Es kommt nur darauf an, ob der Geschäftsinhaber sagt, dass sein Problem gelöst wurde und dass er die Zusammenarbeit fortsetzen möchte.

Hier kommt Agile ins Spiel. Die Mitarbeiter in den Geschäftsbereichen, die von diesen Anwendungen profitieren sollen, müssen in die Entwicklung der Lösung einbezogen werden. Es gilt nicht das Prinzip: „Spezifikation notieren, bezahlen und gehen“. Die Auswirkungen auf das Unternehmen sind jetzt beträchtlich, aber auch das erforderliche Engagement ist höher. Eine Lösung kann nur gemeinsam entwickelt werden.

Das skalierte flexible Modell bezieht den Geschäftsinhaber direkt in Feedback, Entscheidungsfindung, kontinuierliche Priorisierung der Arbeit und alles Notwendige ein, um sicherzustellen, dass das Ergebnis den aktuellen Anforderungen entspricht. Die traditionelle Übergabe hat sich geändert. Flexibles Lösungsentwicklung ist keine isolierte Funktion oder eine Reihe von Spezifikationen. Es ist kein Business Case, der diesen Punkt theoretisch beweist. Vielmehr sind es Menschen, die über den gesamten Entwicklungszeitraum hinweg kollaborativ zusammenarbeiten.

Leider funktionieren traditionelle projektbasierte Finanzierungsmodelle nicht für Agile. Diese Projekte schaffen „Zeitarbeit für Zeitarbeiter“. Das ist zwar eine bequeme Art, neue Aufgaben zu organisieren, es unterstützt jedoch keinen kontinuierlichen Wertefluss.

Bei Agile wird die Arbeit anders organisiert. Es geht nicht um einzelne Aufgaben und den Zeitaufwand, sondern um kleine Wertsegmente, die in Echtzeit durch das System fließen sollen. Die Auswirkungen sind sofort sichtbar, wenn jemand sagt, dass sein Unternehmen funktional organisiert ist und Projekte gestartet und die Nutzung gemessen werden.

Das flexible Mantra lautet: Produkte, nicht Projekte. Dies bedeutet eine erhebliche Veränderung in der Art und Weise, wie das Unternehmen über Investitionen, Finanzen und Rendite nachdenkt, und es erfordert Werkzeuge, die eher wert- als aufgabenorientiert sind. Vieles von dem, was heute in der traditionellen Buchhaltung im Zusammenhang mit projektbezogener Arbeit existiert - Stundenzettel, Aufzeichnung und Erfassung - ist ein großes Hindernis für den Wertfluss.

Bei Agile geht es darum, auf Veränderungen zu reagieren, statt einem Plan zu folgen. Und das erfordert eine Verschiebung auf objektive Beweise: Feedback, Frühindikatoren und Vorhersehbarkeit. Haben die agilen Teams das getan, was sie in einem bestimmten Zeitrahmen tun wollten? Wenn ein Geschäftsinhaber etwas anderes tun möchte, können agile Teams umschwenken?

Insgesamt verlagert sich das Modell vom ROI zur hypothesengetriebenen Entwicklung und zum minimal funktionsfähigen Produkt (MVP). Die theoretische Vorstellung des ROI ist ebenso verlockend wie eine konkrete Zahl, aber der ROI ist nur eine Schätzung, wie hoch die Rendite sein könnte, wenn alles nach Plan läuft. Und die Dinge laufen selten nach Plan. Und selbst wenn dies der Fall ist, stehen die Daten erst zur Verfügung, wenn es zu spät ist, da der ROI während der Entwicklung kein Feedback liefert.

Um die Effektivität von Agile zu verstehen, suchen wir stattdessen nach Frühindikatoren und sogenannten Innovationsbilanzierungsmaßnahmen. Wir definieren die Prädiktoren für einen guten Nutzen. Diese Prädiktoren stehen weit vor dem ROI. Letztendlich müssen die Systeme nicht nur auf die Kosten ausgerichtet sein, sondern auch auf den Nutzen, den die Nutzer erhalten.

In der anfänglichen Investitionsdiskussion geht es zunächst um die Hypothese und dann darum, wie sie bewiesen werden kann. Und natürlich, wie viel es kostet, diesen ersten Punkt zu erreichen. In der Regel ist dies ein Bruchteil der Gesamtinvestition, da die Teams innerhalb eines vereinbarten Zeitrahmens (z. B. einiger Wochen oder Monate) Feedback zum MVP erhalten. Schließlich wird besprochen, ob man die Investition fortsetzen oder sich um etwas anderes kümmern soll.

Der Vorteil besteht darin, dass dieses schlanke Modell weitgehend immun gegen Kostenfallen ist. In der traditionellen Welt muss sich eine Investition von 5 Millionen US-Dollar auszahlen. Stakeholder sprechen nicht gern von Verschwendung oder Experimenten. Abwehrmechanismen wie die Genehmigung weiterer 10 bis 20 Millionen US-Dollar, um den Traum am Leben zu erhalten, unabhängig davon, ob der Wert vorhanden ist oder nicht, könnten greifen.

Agile Unternehmen tun dies nicht. Rollierende Finanzierungswellen, MVPs, Ignorieren von Kostenfallen und das Treffen von Entscheidungen auf Grundlage objektiver Maßstäbe basierend auf der Innovationsbuchhaltung – so erledigen agile Unternehmen ihre Arbeit, eine Hypothese nach der anderen.

Bei der flexiblen Entwicklung wartet man nicht jahrelang auf etwas. Wenn Sie sich ein großes Programm ansehen, werden die Prüfpunkte innerhalb der ersten sechs bis zwölf Wochen sichtbar. Nach einigen Programmschritten wird der Beweis zeigen, ob dieser längere Weg eingeschlagen werden soll oder nicht.

Indirekte und direkte Metriken können dabei helfen, den Wert von Produkten zu messen, die durch Agile bereitgestellt werden. Sie können indirekt die Geschwindigkeit oder die Anzahl der Storys oder Story-Points messen, die Teams in einer Zeiteinheit erreichen können. Anstatt sich den Projektstrukturplan anzusehen, können Sie auswerten, wie ähnliche Arbeiten in der Vergangenheit diese Kapazität genutzt haben.

Es ist wichtig, zunächst auf Vorhersehbarkeit zu achten: Haben Sie den Wert, den Sie versprochen haben, innerhalb des Zeitrahmens geliefert? Dann können Sie Anpassungen vornehmen und Gespräche darüber führen, warum dieses Ziel so viel wichtiger ist als die anderen. Es ist auch einfach, beispielsweise einen NPS zu überprüfen, um die Ergebnisse mit den Geschäftsinhabern zu bewerten. Wie groß ist Ihr Selbstvertrauen? Werden Sie die bewerteten Teams anderen empfehlen?

Der Übergang von Wasserfall zu Agilität stellt den konventionellen Umgang mit Investitions- und Betriebskosten infrage. Die FASB-Regeln besagen, dass Sie zum Zeitpunkt des Nachweises der Machbarkeit und der Genehmigung durch das Management Arbeitskräfte aktivieren und diese über die Nutzungsdauer des Projekts abschreiben können, was sich auf den Umsatz auswirkt.

Im Wasserfallmodell können Sie, nachdem die Anforderungen und der Entwurf festgelegt und genehmigt wurden, die Kapitalisierung vornehmen. Bei Agile gibt es kein solches Etappenziel. Sie entwickeln die Lösung Stück für Stück, können aber trotzdem profitieren.

Es gibt noch viel Arbeit in den Bereichen Innovation, Forschung, Infrastruktur und allen bei möglichen Dingen, die nicht direkt mit dem Hinzufügen von Funktionen zum System zu tun haben. Diese werden immer noch nicht kapitalisiert. Bei Agile gibt es jedoch „Storys“, in denen neue Funktionen implementiert werden. Wenn Sie eine Story für eine Funktion wie einen neuen Single-Sign-On-Mechanismus haben, können Sie kapitalisieren. Und Sie benötigen dafür vielleicht nicht einmal Arbeitszeittabellen. Die Kapitalisierung erfordert jedoch eine Erklärung, ein Gespräch, das stattfinden muss.

Heute wirkt sich Agile im großen Maßstab auf Stakeholder aus, die für Governance und Investitionen verantwortlich sind. Da IT-Abteilungen oft noch mit begrenzter Kostentransparenz arbeiten, kann die Wahrnehmung des IT-Finanzmanagements sein: „Hier ist unsere große Kostenstelle. Hier sind die Ausgaben. Im Laufe der Zeit haben wir verschiedene Geschäftsergebnisse, und ja, es ist wirklich schwierig, sie mit der Investition in Beziehung zu setzen. Wir verteilen die Kosten.“

Um ihren Mehrwert nachzuweisen, müssen IT-Führungskräfte bei der Transformation zu Agile verstehen, wie sie die finanziellen Auswirkungen und den Wert einer kontinuierlichen Entwicklung messen, wann sie Arbeit kapitalisieren, und wie sie finanzierte Initiativen transparent machen können. Sie brauchen das richtige Maß an Transparenz, um festzustellen, ob Sie in der IT in die richtigen Dinge auf die richtige Weise investieren. Hier nutzen IT-Führungskräfte Technology Business Management (TBM).

TBM ist eine Disziplin, die Geschäftsergebnisse verbessert, indem sie Unternehmen eine konsistente Möglichkeit bietet, Technologieinvestitionen in geschäftlichen Nutzen zu übersetzen. TBM definiert die Tools, Prozesse, Daten und Personen, die für die Verwaltung des Technologiegeschäfts benötigt werden. Es basiert auf einer standardisierten TBM-Taxonomie und einem Framework, das die Probleme strukturiert, die Technologie- und Unternehmensleiter lösen möchten – einschließlich der Finanzierung von Agile in großem Maßstab.

TBM verfügt über eine standardisierte Taxonomie und Berichterstattung, egal ob Wasserfall- oder agiles Modell. Diese Funktionen helfen Unternehmen dabei, Metriken für die Agile-basierte Anwendungsentwicklung transparent zu machen und Ressourcen und Ergebnisse in wertstromspezifischen Aktivitäten zu organisieren. Die Ergebnisse sind eine Ausrichtung auf die Geschäftsergebnisse und ein steigender Geschäftswert.

Einige der weltweit größten Unternehmen beschäftigen etwa 10.000 IT-Mitarbeiter, von denen vielleicht 5.000 oder 6.000 Anwendungen entwickeln – ein erheblicher Kostenfaktor. Ist das eine Kostenstelle oder eine Investitionsstelle? Es ist eine Frage der Perspektive, aber man muss wissen, wie man die flexible Entwicklung verfolgt, wenn man verstehen will, wofür das Geld ausgegeben wird. Der Prozess erfordert eine Planung, wie Sie flexible Produkte initiieren, finanzieren und messen.

Um als Wertschöpfungspartner betrachtet zu werden, müssen Sie den Wertfluss sowie die Ausgaben für Daten und Kommunikation verstehen. Diese Überlegungen sind wichtig, aber die Diskussion verlagert sich mehr darauf, wie man mit neuen Lösungen konkurrieren kann.

Es ist verständlich, dass alles vorhersehbar, planmäßig abgebildet und mit zukünftigen Budgets korreliert sein soll. Aufgrund der damit verbundenen Kosten ist dies jedoch einschränkend.

Ja, Sie möchten im Voraus wissen, was nicht bekannt ist, und den ROI für das Unbekannte sicherstellen, aber das ist nicht realistisch. Wenn Sie in der Lage sind, mit den Interessenvertretern auf der Vorstandsebene zusammenzuarbeiten und aktuelle Investitionen und Ergebnisse zu erläutern, anstatt sich auf Mehrjahrespläne festzulegen, können Sie wettbewerbsfähig sein.

Die gute Nachricht ist, dass Agile all diese ROI-Spekulationen durch objektive Beweise in Echtzeit ersetzt. Anstatt mit den Anforderungen für die nächsten zwei Jahre zu arbeiten, erarbeiten Sie das erste Stück und liefern es. Jetzt.

Die größte Stärke von agiler Arbeitsweise ist die Fähigkeit, ein umfangreiches Vorhaben in Teile aufzuteilen und fast sofort einen Mehrwert zu schaffen. Der Kompromiss besteht darin, dass Sie eher früher als später herausfinden, ob Sie auf dem richtigen Weg sind.

Aufgrund des rasanten Tempos der Technologie müssen mehr Unternehmen agile Methoden wie das Scaled Agile Framework (SAFe) einführen, um schnell auf sich ändernde Geschäftsmodelle, Märkte und Technologien reagieren zu können. Als Ergebnis müssen sie ihre steigenden Technologieausgaben verwalten und Transparenz über die IT-Kosten herstellen. Unternehmen können TBM und SAFe zusammen nutzen, um mehr Wert mit mehr Transparenz zu liefern und so eine bessere geschäftliche Agilität und Partnerschaft zu erreichen.