Selbst wenn die IT-Abteilung heute nach agilen Methoden arbeitet, bedeutet das noch lange nicht, dass die Zukunft des Geschäfts gesichert ist. Denn die Agilität darf nicht an der Grenze zwischen IT und Business aufhören, meint der Digitalisierungsberater Patrick Naef. Im Interview erklärt er, wie er sich die agile Organisation vorstellt und wie der CIO helfen kann, sie zu verwirklichen.

Patrick Naef: Nicht zwingend. Meiner Meinung nach hat sich agil in den letzten Jahren zu einem der meistmissbrauchten Schlagworte entwickelt. Alles scheint agil zu werden und jeder behauptet, agil zu sein. Haben Sie schon einmal jemanden sagen hören: «Nein, wir sind nicht agil»?

Auf dem Papier ist Agilität ein iterativer Ansatz für das Projektmanagement und die Software-Entwicklung, der Teams hilft, ihren Kunden schneller und in kleineren «Häppchen» einen Mehrwert zu liefern. Anstatt alles auf einen «Big Bang»-Launch zu setzen, liefert ein agiles Team die Arbeitsresultate in kleinen, einfacher konsumierbaren Schritten. Dabei werden die Anforderungen, Pläne und Ergebnisse kontinuierlich evaluiert, so dass die Teams über einen natürlichen Mechanismus verfügen, um schnell auf Änderungen reagieren und Prioritäten anpassen zu können. Kurze, iterative Zyklen (Sprints) und die Reduktion von Overhead und Bürokratie auf ein Minimum und damit die schnelle Lieferung kleiner Teile von nutzbaren Funktionalitäten mit echtem Mehrwert für das Geschäft ist die Essenz von Agile.

Naef: Genau. Geschwindigkeit (speed to market) ist das A und O, um in der heutigen Geschäftswelt wettbewerbsfähig zu sein, und das ist einer der Hauptgründe, warum agile Methoden so beliebt geworden sind. Oft wird Agile jedoch von Business Managern missverstanden und meist als reines «IT-Thema» gesehen. Sie glauben, dass mit der Einführung agiler Methoden durch ihre IT-Teams Projekte bei gleichem Umfang einfach schneller und kostengünstiger durchgeführt werden. Dies ist jedoch eine Illusion.

Naef: Meine persönliche Erfahrung, die ich als CIO bei einer agilen Transformation gemacht habe, hat mich gelehrt, dass das gesamte Unternehmen agil werden muss, um die wahren Vorteile agiler Methoden nutzen zu können – und das erfordert weit mehr als nur die Transformation der IT. Es reicht nicht aus, Methoden wie SAFe oder Scrum in der IT zu implementieren, ein paar Projekte nach dem agilen Ansatz durchzuführen und zu glauben, dass das Unternehmen dadurch schneller am Markt ist.

Naef: Nachdem wir jahrelang schon Rapid-Prototyping-Methoden eingesetzt und unsere IT-Teams mit den Fachbereichen physisch zusammengelegt hatten (co-location), begannen wir 2013 mit der Einführung agiler Methoden. Wir haben sehr schnell Vorteile erzielen können; indem wir in der Lage waren, kleinere Teile gebrauchsfertiger Software viel schneller zu liefern als bei der Anwendung des traditionellen Wasserfallmodells.

Als wir jedoch den Code in Produktion setzen wollten, blieben wir bei unseren eigenen IT-internen, ITIL-basierten Prozessen stecken. Unsere IT-Operations-Kollegen, die zu Recht den Auftrag haben, den «heiligen Gral» des sicheren und stabilen Betriebs zu bewachen, erlaubten nur zu vordefinierten Zeitpunkten, dass Software-Code auf der Grundlage strenger Abnahmekriterien und Prozesse in die Produktion freigegeben wurde. Zum Beispiel, wenn die monatlichen oder manchmal auch vierteljährlichen Release-Zyklen fällig waren. Uns war klar, dass wir diesen Engpass nur überwinden können, wenn wir die Mitarbeiter des IT-Betriebs in die agilen Teams (Squads) integrieren und sie und ihre Prozesse zum Teil der agilen Transformation machen. Dies war der Beginn von DevOps in der Organisation.

Viele Unternehmen stoppen ihre agile Transformation in diesem Stadium, weil sie agil als eine IT-Methode betrachten. Wir wollten aber weitergehen. Denn wir stellten fest, dass uns einige andere Bereiche des Unternehmens immer noch ausbremsten und daran hinderten, die wahren Vorteile der agilen Methoden voll zum Nutzen des Unternehmens umzusetzen.

Naef: Lassen Sie mich ein paar Beispiele nennen unabhängig von meinen früheren Arbeitgebern. Natürlich ist jede Ähnlichkeit mit tatsächlichen Personen oder Organisationen rein zufällig:

Ich könnte wahrscheinlich mit solchen Beispielen von Einheiten und Funktionen innerhalb der traditionellen hierarchischen Silos weitermachen, aber ich denke, Sie haben den Punkt verstanden: Sie können Agile nicht auf die IT beschränken, wenn Sie tatsächlich von der erhöhten Geschwindigkeit profitieren wollen, die agile Arbeitsweisen bieten. Stattdessen müssen Sie die Transformation durch das gesamte Unternehmen vorantreiben.

Naef: Auch wenn die traditionellen Planungs- und Projektmanagement-Methoden uns in der Vergangenheit gute Dienste erwiesen haben. Sie sind heute ebenso Altlasten wie die hierarchischen Strukturen sowie deren bürokratischen Prozesse, die oftmals nur dem Selbstzweck von Konzernfunktionen und Overhead-Strukturen von Unternehmen dienen. Diese hierarchischen Strukturen mit ihren starren Finanz-, Kontroll- und Planungsprozessen, die aus dem Industriezeitalter des letzten Jahrhunderts stammen – Stichwort: Taylorismus –, sind für das neue agile Paradigma nicht geeignet – und auch nicht damit kompatibel.

Naef: Korrekt. Ich habe beobachtet, dass in traditionell geführten Projekten – nach der Wasserfallmethode – die Teams viel Zeit damit verbringen, auf andere zu warten. In Projekt-Reviews lautete eine häufige Erklärung auf die Frage, warum das Projekt hinter dem Zeitplan zurücklag: «Wir warten darauf, dass Einheit A das Teilprodukt X liefert.» Dies konnte seine Ursache darin haben, dass die Geschäftsbereiche Spezifikationen oder Testfälle absegnen oder Abnahmetests durchführen müssen usw. Oder an der IT-internen Bürokratie, wie zum Beispiel Enterprise Architecture, um die Lösungsarchitektur freizugeben, Cybersecurity, um die Risiken abzuzeichnen, IT-Betrieb, um Server bereitzustellen, usw. Oder aber aufgrund externer Faktoren, wie zum Beispiel wenn ein Lieferant einer outgesourcten Komponente nicht pünktlich liefert.

Naef: Einfach gesagt wegen der strikten Aufgaben- und Rollentrennung des Industrialisierungsansatzes, die zu mehrfachen Übergaben (Hand-over) und zu Overhead führt.

Ein CIO-Kollege einer europäischen Bank, der selber starker Befürworter agiler Arbeitsweisen ist, sagte mir vor ein paar Jahren: «Bei Agile geht es darum, Hand-overs abzuschaffen. Hand-overs verlangsamen Prozesse und sind die Quelle von Fehlern.»

Im Roman «The Phoenix Project» beschreiben Gene Kim und Kevin Behr treffend, dass es bei Agile um die Fokussierung auf Einfachheit geht – die Kunst, die Menge nicht getaner Arbeit zu maximieren –, also alles Unnötige zu entfernen. Ähnlich wie bei Lean-Methoden in der Fertigung geht es um die Minimierung von «work in progress» (Halbfabrikaten) und das Vermeiden von Engpässen.

Naef: Eher nicht. Meiner Meinung nach geht es bei agilem Vorgehen weniger darum, noch eine weitere Methodik (Holokratie, Kanban, SAFe, Scrum, etc.) minutiös zu befolgen und damit wieder Bürokratie einzuführen. Sondern um eine Denkweise, die sich auf einige wenige Prinzipien im gesamten Unternehmen und nicht nur in der IT konzentriert:

Naef: Da agile Methoden in der IT bereits eine gewisse Tradition haben, ist der CIO gut dafür positioniert, auch die agile Transformation im gesamten Unternehmen voranzutreiben. CIOs sollten die Business-Kollegen dabei unterstützen, ebenfalls agil zu werden, indem sie diese Prinzipien übernehmen und ihnen helfen, den Mindset und die Kultur innerhalb ihrer Organisationen zu ändern. Dies ist ein wichtiger Teil der Rolle des modernen CIOs, der für sein Unternehmen einen echten Mehrwert schaffen und einen positiven Einfluss im Unternehmen ausüben möchte.

Von den CIOs von heute wird erwartet, dass sie aus dem Backoffice herauskommen, die traditionelle Rolle der IT als Support-Einheit verändern und aktiv die agile Transformation des gesamten Unternehmens vorantreiben.