Agile IT – vom Exoten zum Standard

DevOps, Microservices, Multicloud: Immer mehr Unternehmen nutzen agile Methoden und Dienste zur Entwicklung von Anwendungen. Doch wenn die Lösungen skaliert und produktiv eingesetzt werden sollen, benötigen die agilen Teams Übergabepunkte in die klassische Organisationsstruktur. Dies funktioniert mit Hilfe von drei Ansätzen. 

„Wir müssen flexibler werden.“ Diese Forderung klingt seit Jahren durch die Hallen vieler etablierter Großunternehmen. Die Konkurrenz durch Startups und Cloud-native Disruptoren hat die Führungsebenen bereits vor einigen Jahren aufgeschreckt. Sie reagierten häufig mit der Übernahme kleiner, innovativer Firmen oder der Ausgliederung einer eigenen Abteilung. In beiden Fällen sollten agile Methoden und Prozesse die Entwicklung neuer Ideen und Lösungen voranbringen. 

Dies hat in vielen Fällen auch gut funktioniert. Doch derzeit bilden die agilen Teams oft eine isolierte, vom Gesamtunternehmen fast völlig getrennte Einheit. Das wird auch durch die vorherrschende „traditionelle“ Organisationsstruktur gefördert. Sie ist in erster Linie auf Stabilität ausgerichtet. In dieser statischen, siloartigen, streng strukturierten Hierarchie werden die Ziele und Entscheidungsrechte von oben nach unten weitergegeben – mit den mächtigsten Leitungsgremien an der Spitze. Sie funktioniert durch lineare Planung und Kontrolle, um den Wert für die Aktionäre zu steigern.  

Eine solche skelettartige Struktur ist zwar stark und auf langfristige Ziele ausgerichtet, aber oft auch starr und langsam in der Bewegung. Häufig werden Kunden- und Lieferantenbeziehungen mit Hilfe von KPIs gemessen und mit SLAs verwaltet. Der Fokus liegt hier auf Effizienz. Dies führt zu einer maximalen Spezialisierung der Mitarbeiter in ihren Rollen und Zuständigkeiten, wodurch sie jedoch häufig keine Verantwortung mehr für das finale Gesamtprodukt besitzen.

Ganz anders in der agilen IT: Hier arbeiten die Teams abteilungsübergreifend zusammen, um möglichst flexibel und schnell neue Lösungen zu entwickeln. Dabei behalten sie den Nutzen für den Anwender sowie für das eigene Unternehmen immer im Blick. So sind sie auch für das Gesamtprodukt verantwortlich, insbesondere in Bezug auf Performance, Sicherheit und Mehrwert im laufenden Betrieb.  

Dies ist ein völlig anderer Ansatz im Vergleich zur traditionellen Struktur. Daher haben produktorientierte, agile Teams zur Digitalisierung in der Vergangenheit häufig als eigene Einheiten unabhängig vom „bestehenden Geschäft“ und der hierarchischen Organisation gearbeitet.  

Aber mit zunehmendem Geschäftserfolg der agilen Teams kann diese Trennung immer weniger funktionieren. Mit der Skalierung der digitalen Geschäftsmodelle müssen diese Einheiten wieder mit dem normalen Betrieb verbunden werden. Denn mit zunehmender Bedeutung möchten Unternehmen die Verantwortung für den Betrieb und die Weiterentwicklung der digitalen Services wieder in den bestehenden Einheiten wie Vertrieb und IT übernehmen, um deren Effizienz und Stabilität für den „Regelbetrieb“ zu erhöhen. 

Doch dies ist leichter gesagt als getan. Denn wie sollen Unternehmen eine agile mit einer hierarchischen Struktur vereinen? Und wie schnelle Innovationen nach dem Motto Fail-fast mit langfristiger Effizienz zusammenbringen? In der Praxis erfordert dies eine komplexe Transformation. 

Hier hilft es, sich im ersten Schritt zu fragen, woran der Erfolg im agilen und im traditionellen Kontext gemessen wird. Bei der traditionellen Organisation steht in der Regel das Effizienz-Management im Vordergrund. Sie verfolgt im Prinzip das Ziel, mit möglichst wenig Aufwand einen stabilen IT-Betrieb zur Sicherung des Geschäftserfolges zu erzielen. Im Gegensatz dazu geht es in der agilen Organisation vor allem um eine möglichst flexible Umsetzung der Anforderungen Einfachheit, Kundenorientierung und Geschwindigkeit.  

Um eine Brücke zwischen der agilen und der traditionellen Welt zu schlagen, sollten Unternehmen drei Bereiche berücksichtigen: Service-Basisbetrieb, Cultural Management und produktorientierte IT. 

Der Service-Basisbetrieb muss einen strukturierten Transitionsansatz schaffen, um agile Lösungen in die stabile, traditionelle Organisation zu überführen. Dazu sind folgende Punkte zu beachten: 

Im Bereich Cultural Management sind Arbeitsweisen und Zielsetzung der jeweils anderen Teams (agil und traditionell) zu kommunizieren und verständlich darzustellen. Beim agilen People Management folgt das Rollenverständnis der Führungskraft statt dem klassischen disziplinarischen Vorgesetzten nun dem Motto „Management by walking around“. Hier sind die Mitarbeiter zu befragen: Was kann ich für dich tun? Hast du alles, um effizient zu arbeiten? Die Autonomie muss jedoch von beiden Seiten gelebt werden. So sollten Mitarbeiter dabei unterstützt werden, sich vom Befehlsempfänger zu einem eigenverantwortlichen und selbstständigen Kollegen zu wandeln. Dies erfolgt über ein geeignetes Change Management. Darüber sollten auch im klassischen Umfeld schrittweise agile Prinzipien eingeführt werden.  

Dabei sind drei Anforderungen der Mitarbeiter zu erfüllen: Autonomy, Mastery und Purpose. Autonomy bedeutet, dass Mitarbeiter eine gewisse Entscheidungsfreiheit wünschen und Verantwortung übernehmen möchten, um eigenständig arbeiten zu dürfen. Mastery beschreibt die Weiterentwicklung der eigenen Kompetenzen und deren zielführenden Einsatz, um eigenständig arbeiten zu können. Purpose steht für einen Grund, ein Ziel oder eine Vision für die tägliche Arbeit, um deren Sinn und Nutzen zu begreifen sowie eigenständig arbeiten zu wollen. Umgekehrt müssen den agilen Innovationsteams die Restriktionen der klassischen IT verständlich gemacht werden, insbesondere warum Punkte wie Sicherheit, Stabilität oder Skalierbarkeit notwendig sind.  

Schließlich erfolgt der mittelfristige Umbau der traditionellen IT in Richtung einer produktorientierten IT. Hierbei spielt die Customer Centricity eine wichtige Rolle, also die Orientierung an den Bedürfnissen der Fachbereiche mit ihren jeweiligen Geschäftsprozessen und eingesetzten Produkten. Das bedeutet, der Wertbeitrag des Portfolios für die internen Kunden steht hier im Mittelpunkt. Der Zuschnitt der IT-Service-Portfolios sowie des Business-Service-Katalogs erfolgt dann anhand von Business-Prozessen und Fähigkeiten mit klaren Ansprechpartnern in der Geschäftseinheit – und nicht mehr anhand von IT-Prozessen wie Entwicklung, Betrieb und Security.