So klappt es mit der Agilität

Vor fünf oder sechs Jahren galt Agilität noch als exotisch, heute ist die Methodik in den IT-Führungsetagen Allgemeingut. In „agile Vorgehensweisen“ stürzen sich die meisten Unternehmen Hals über Kopf. Sie lernen, was das Vorgehensmodell SCRUM bedeutet und experimentieren mit SAFe (Scaled Agile Framework). All dies ist positiv zu bewerten, da es eine hohe Wertschätzung für agile Methoden und ihre wesentlichen Bestandteile zeigt. Allerdings erweist sich die bestehende Unternehmens-IT und ihre Welt der Applikationen meistens als erstaunlich widerstandsfähig, sodass agile Ansätze oft ins Leere laufen. Der Grund sind vor allem die über Jahre und Jahrzehnte gewachsenen Anwendungslandschaften und -architekturen. Erschwerend kommen sogenannte „Datensilos“ sowie fehlende Schnittstellen hinzu. So macht sich nach der Anfangseuphorie in der Regel schnell Ernüchterung breit.

IT ist gleich Business

Mittlerweile haben Unternehmen dazu gelernt. Sie wissen um die Fallstricke von Buzzwords wie „IT der zwei Geschwindigkeiten“ und „bimodale IT“. Sie haben erkannt, dass die Zukunft in vielen unterschiedlichen Liefergeschwindigkeiten innerhalb eines Unternehmens liegt. So hat der CIO eines globalen Autoherstellers kürzlich das Ziel von „100 % Agilität“ ausgegeben und definierte Agilität dabei vor allem als die Fähigkeit, Produkte und Services in der jeweils notwendigen Geschwindigkeit liefern zu können: durchaus auch einmal langsamer, wenn Highspeed keinen Mehrwert bringt, und besonders schnell, wo es Geschäft und Kunde fordern. Damit liegt der Fokus nicht auf Geschwindigkeit per se, sondern auf der jeweils passenden Geschwindigkeit.

Es macht keinen Sinn, High-Performance-Plattformen für Software zu schaffen, die sowieso schon am Ende ihres Lebenszyklus angekommen ist. Umgekehrt gilt für Neuanwendungen und digitale Projekte: Bei ihnen sollte ein Unternehmen alle Möglichkeiten ergreifen, schon vom ersten Tag an mithilfe von DevOps der reinen Lehre der Agilität zu folgen. Doch leider stellt sich die Lage nicht so eindeutig dar. Denn 80 Prozent der Anwendungen liegen irgendwo in den unterschiedlich grauen Abstufungen zwischen diesen beiden Extremen. Dementsprechend muss sich die Debatte vor allem darum drehen, welche Geschwindigkeit für welche Abstufung von Grau am zielführendsten ist und mit welchem Aufwand sie sich erreichen lässt.

Der CIO einer weltweit operierenden Bank stellte in diesem Zusammenhang kürzlich eine sehr treffende Analogie mit der Funktion eines Schaltgetriebes her: „Anwendungen sollten in der jeweils notwendigen Geschwindigkeit laufen, indem man einfach hoch- oder runterschaltet, ohne den gesamten Motor auswechseln zu müssen. Und zugleich wird es immer eine jeweils eigene Nachfrage nach Sportwagen, Familienwagen und LKWs geben.“ Doch welche Auswirkungen hat ein solcher Ansatz im Detail und im Alltag? Zum Beispiel: Wird es dementsprechend für einen bestimmten Service unterschiedliche Service Level Agreements (SLAs) geben, die alle auf dem Parameter „Geschwindigkeit“ basieren?

Agil vorzugehen, heißt noch nicht, agil zu sein

Die Analyse vieler agiler Projekte in Unternehmen legt den Schluss nah, dass es nicht nur darauf ankommt, agil vorzugehen, sondern auch generell agil zu werden. Die Entwicklung führt vom Finden „des richtigen Wegs“ hin zum „jeweils passenden Weg“. Agilität besteht dann in der Freiheit, jeweils jenes Vorgehen zu wählen, das am besten zur jeweiligen Situation passt. Vor einigen Jahren hat der Informatikwissenschaftler Brian Henderson-Sellers – neben anderen – das Konzept des „Situational Method Engineering“ (SME) ins Spiel gebracht. SME beinhaltet Methoden, die auf spezifische Situationen und Entwicklungsprojekte zugeschnitten sind. Die Methoden können dabei flexibel aus einer Bibliothek wiederverwendbarer Methodenkomponenten zusammengesetzt werden. Die derart maßgeschneiderten und integrierten Methoden formen so eine immer neue, jeweils situationsspezifische Methodik.

SME ist zum Beispiel bei einem großen Chemie- und Life Science-Unternehmen im experimentellen Einsatz. In diesem Fall ist eine umfangreiche SAP-Landschaft mit fast 2.000 weiteren Anwendungen verbunden. Der Fokus der Serviceerbringung verschiebt sich derzeit von den SAP-Expertenteams (FI, CO, SD, MM etc.) hin zu Teams, welche die wichtigsten Geschäftsprozesse verantworten. Jedes dieser Teams ist der „Owner“ der SAP-Module und den damit verbundenen Systemen, welche die Anforderungen der einzelnen Geschäftsprozesse erfüllen.

Zugleich führen neue Geschäftsideen vom Rand der Organisation zu neuen digitalen Produkten in den Bereichen Landwirtschaft und Farben. Das Unternehmen hat es aufgegeben, eine übergreifende Methodik zu finden, die beiden Geschäftsbereichen gerecht wird und tendiert immer mehr zu drei bis vier situationsorientierten Methoden. Diese werden von Pilot-Teams erstellt. Sind sie erfolgreich, finden sie Eingang in eine Software Delivery-Methodik, die situationsbasiert aufgestellt ist – je nach Technologie, bereits eingesetzter Software, Ort und Umfang des Einsatzes und Lebenszyklus des jeweiligen Produkts. So existiert nun eine zentrale Gruppe des Methoden-Engineerings innerhalb der IT-Organisation, die sich vor allem damit beschäftigt, erfolgreiche Arbeitsweisen in spezifische Methoden zu überführen. Dies zeigt, dass SCRUM und Agilität auf der Ebene von Teams gut funktionieren, während SME die wesentlichen Herausforderungen bei umfangreichen Unternehmensanwendungen besser meistert.

Best Practice bringt nicht immer beste Ergebnisse

DevOps führt eine Entwicklung weiter, die mit Agile begann. Unternehmen entwickeln Software nicht mehr nur in agiler Weise, sondern liefern sie auch in immer kürzeren Abständen aus. Damit verschiebt sich der Fokus im Entwicklungsprozess. So gewinnen Prozesse der Software-Versionierung und -Auslieferung stark an Bedeutung. Und sie sind dann erfolgreich, wenn sie wiederholbar sind. Vor allem die DevOps-Community trägt zu diesem Bewusstsein maßgeblich bei.

Doch was bedeutet das für sehr große Unternehmen? Nehmen wir das Beispiel eines großen Industriefertigers, der im Zuge von DevOps Suiten für die kontinuierliche Software Delivery bei seinen Haupttechnologien geschaffen hat: Java/LAMP, Microsoft und SAP. Diese Software Delivery-Suites werden von einem zentralen Team perfektioniert. Dabei hat es der Leiter IT-Infrastruktur auf sich genommen, das Middleware-Team des Unternehmens fit zu machen, damit es diese Delivery-Suites planen, managen und betreiben kann. Insofern nimmt sich das Unternehmen immer mehr Freiheiten bei der Auswahl seiner Delivery-Methoden heraus, standardisiert aber weiterhin die Technologie der Delivery – denn nur Standardisierung führt zu Wiederholbarkeit und Geschwindigkeit.

Viele Unternehmens- und IT-Berater operieren mit Prozess-Frameworks, die dem Best Practice entsprechen. Doch scheitern sie oft bei der Einführung, weil das Delta zu den bestehenden Systemen und Prozessen zu groß ist. Stattdessen ist es wichtiger, darauf zu schauen, wo wirklicher Mehrwert entsteht (Value Stream), statt jeden individuellen Prozess im Detail auseinanderzunehmen – oder ihn sogar vollkommen neu aufzusetzen. Value Stream-Analysen und Kaizen-basierte, agile Implementierung von Veränderungen gehen hingegen immer von der jeweiligen Ist-Situation als Ausgangspunkt aus.

Jahresbudgets sind für agile IT zu starr

Der Weg zur Unternehmens-Agilität hört nicht bei der IT auf. Beispiel Finanzdienstleistung: Der CIO einer großen Bank hat seine Organisation so weit gebracht, dass sie bis zu 30 Prozent ihrer Projekte agil durchführt. Weitere Schritte behindern jedoch die nur im jährlichen Rhythmus verlaufenden Budgetzyklen. Die Kunst liegt hier nun darin vorherzusagen, wie Budgets geplant und zugewiesen werden. In diesem Zug entstehen interessante Verhaltensmuster: So werden etwa Budgets zum Teil nicht mehr Programmen, sondern Produkten oder Geschäftsprozessen zugewiesen. Auf diese Weise sind Verantwortlichkeiten klarer und das Verhalten verändert sich in positiver Hinsicht: Teams können die Budgets nun dazu verwenden, bereits existierende Software-Komponenten zu verwenden und diese flexibel kurzfristigen Bedarfen anzupassen, um bestimmte Ziele zu erreichen. Bislang musste man hingegen mehr gezwungen als freiwillig mit Langfristplanungen leben und diese von Anfang bis Ende befolgen. Diese Hinwendung zu produktbezogenen Budgets und Verantwortlichkeiten führt zu fundamentalen Strukturveränderungen in IT-Organisationen – wie sie bereits in zahlreichen Unternehmen etwa in den Niederlanden, Schweden oder Deutschland zu verzeichnen sind.

Fazit

Führende Unternehmen haben den Hype um neue Methoden bereits hinter sich gelassen und setzen auf eine Delivery der unterschiedlichen Geschwindigkeiten. Ansätze wie „Situational Method Engineering“ (SME) und eine produktorientierte Delivery versprechen pragmatische Lösungswege gerade für große Unternehmen mit komplexen und lang gewachsenen Anwendungslandschaften. Der Versuch, diese Vorgehensweisen zu standardisieren führt zu neuen, mehrfach einsetzbaren Services – im Sinne von Umgebungen und Plattformen, die eine kontinuierliche Delivery ermöglichen. Und Unternehmensverantwortlichen wird bewusst, dass Agilität in ihrem Unternehmen nicht nur die IT betrifft, sondern sich immer mehr auf weitere Unternehmensbereiche wie Controlling, Budgetierung oder Beschaffung ausdehnt. Schließlich gilt: Das Unternehmen ist als Ganzes nur so schnell wie das schwächste Glied in der Kette.