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.