Wie CIOs sich selbst belügen

Tatsächlich erzielen aber viele Organisationen die Vorteile, die sie sich erhofft haben, gar nicht oder nur teilweise. Das liegt auch daran, dass die Verantwortlichen die Augen vor hartnäckigen Problemen verschlossen halten. "Heute sagen alle, dass sie agil sind, aber viele sind es in Wirklichkeit nicht oder sie erreichen zumindest nicht das Ausmaß und die Qualität von Agilität, das sie angestrebt haben", bilanziert Dave West, CEO von Scrum.org.

Welche Fehler machen also die Unternehmen, beziehungsweise die CIOs und wo neigen sie dazu, sich selbst zu belügen? Wir haben die häufigsten Fehleinschätzungen und Selbsttäuschungen zusammengetragen und uns dabei auf die Aussagen von versierten Praktikern verlassen.

1. "Wir nutzen die Begriffe, also sind wir agil"

Laut West sind vielen IT-Teams die Begrifflichkeiten der agilen Methoden in Fleisch und Blut übergegangen. Sie haben aus ihren Projektmanagern Scrum-Master gemacht und Arbeitsgruppen in Tribes verwandelt. Natürlich ist es nicht verkehrt, das richtige Fachvokabular zu verwenden, wichtiger ist es aber, die Umstrukturierung der Organisation tatsächlich voranzutreiben, damit die neuen Titel und Bezeichnungen auch gerechtfertigt sind. "Allzu oft arbeiten die Leute im Prinzip noch so wie vorher, auch wenn sie es nun anders nennen. Sie ändern Bezeichnungen und Titel, aber nicht ihre Arbeitsmethode", beobachtet West.

Dem kann Christine Hales, Vice President Technology beim US-Finanzdienstleister Capital One, nur zustimmen. "Agil zu arbeiten, bedeutet wirklich einen kulturellen Wandel. Wenn man isoliert auf Prozesse, ToolsTools und Bezeichnungen blickt, wird man die Chancen nicht nutzen können", sagt Hales. "Die Menschen müssen im Team anders arbeiten als bisher, darin liegt die zentrale Veränderung." Alles zu Tools auf CIO.de

2. "Unsere Techniker brauchen keine Schulungen"

Das deutsche Finanzinstitut DZ BankDZ Bank hat im Laufe der Jahre immer wieder neue Produkte und Tools eingeführt, um seine DevOps-Praxis weiter zu verbessern. Unsere US-Kollegen von CIO.com zitieren Henning Ehm, Head of DevOpsDevOps bei der Frankfurter Bank. Er stellt fest, dass die Einführung solcher Tools nicht immer ein Treffer war. Es sei ein Fehler, für Techies neue Technologie bereitzustellen und anzunehmen, dass sie diese Tools schon akzeptieren und richtig einsetzen werden. In vielen Fällen habe es Widerstand gegeben. Top-500-Firmenprofil für DZ Bank Alles zu DevOps auf CIO.de

IT-Führungskräfte gehen offenbar häufig davon aus, dass ihre IT-Spezialisten gerne und ohne große Anleitung die neuesten Tools aufgreifen und nutzen wollen. Wie Ehm erfahren musste, braucht aber auch diese Expertengruppe Schulungen und StrategienStrategien für das Change Management. "Techniker spielen zwar gerne herum, aber das vollständige Potenzial aus den Tools herauszuholen und für unsere Prozesse zu nutzen, ist harte Arbeit", sagt der DevOps-Profi. Er konzentriere sich inzwischen mehr auf die Menschen und darauf, sie dorthin zu bringen, dass sie Technologien optimal nutzen. Alles zu Strategien auf CIO.de

3. "Die Teams werden ihre Meetings schon kurzhalten"

Lange formelle Treffen sind in agilen Methoden nicht vorgesehen. Stattdessen gibt es bekanntlich in hoher Frequenz Kurzbesprechungen, auch als Daily Standups oder Daily Huddles bezeichnet. Darin berichten Teammitglieder über ihre Arbeitsfortschritte und über Hindernisse, die ihrer Zielerreichung im Weg stehen.

Viele Mitarbeiter haben sich daran gewöhnt, aber nicht alle. Alte Gewohnheiten lassen sich nun mal nur schwer ablegen. Ehm berichtet etwa von Scrum-Sitzungen, die eigentlich nur 15 Minuten dauern sollten, dann aber drei Mal so viel Zeit in Anspruch nahmen. Die Teilnehmer begannen plötzlich alle möglichen Anliegen und Themen anzusprechen.

"Besprechungen im agilen Umfeld haben einen ganz bestimmten Zweck. Daran sind viele Leute aber nicht gewöhnt", beobachtet Ehm. Er empfiehlt den Verantwortlichen, ihre Teams genau darüber aufzuklären, welche Rolle Besprechungen bei der Einführung von Agilität haben und wie sie ablaufen sollten. Zeitliche und thematische Beschränkungen müssten unbedingt durchgesetzt werden. "Heute diskutieren wir in den agilen Meetings eine Sache - und nur diese eine Sache", sagt Ehm.

4. "Die freie Wahl von Tools und Prozessen führt zu mehr Speed"

Obwohl agile Teams zu Recht dazu ermutigt werden, Tools und Wege so zu wählen, dass sie für sie funktionieren, hat dieses Vorgehen auch eine Kehrseite. Amit R. Bhandarkar, Director of Engineering bei American Express Global Business Travel, kennt die Nachteile: Seine Teams hätten oft mit verschiedenen Tools für Continuous Integration und Delivery (CI/CD) gearbeitet - manche mit Open-Source-Lösungen, andere mit kommerziellen Angeboten verschiedener Hersteller. "Sie erzielten das gleiche Ergebnis auf unterschiedliche Weise. Das hat die Agilität beeinträchtigt; einige Teams waren überfordert, andere scheiterten", blickt Bhandarkar zurück.

Als Reaktion darauf hätten die Entwicklungsteams sich schließlich verbindlich auf Standards geeinigt und seien so in eine einheitliche, konsistente Umgebung gewechselt. Die Resultate seien vergleichbarer geworden, zudem hätten die Entwickler weniger Zeit in Maintenance-Aufgaben investieren müssen. Bhandarkar empfiehlt deshalb, die Wahlmöglichkeiten einzuschränken und verlässlich in den Ansagen zu sein, egal ob es um Methoden, Tools oder die Länge von Sprints gehe. Nur so lasse sich gewährleisten, dass alle Beteiligten synchron arbeiteten.

5. "Meine Teams sind flexibel einsetzbar"

Steve Berez, Partner bei Bain & Co. und Mitautor von "Doing Agile Right", arbeitete einmal für eine Fluggesellschaft, die ihre Entwickler kurzfristig anders einsetzen wollte. Experten, die monatelang mit dem Erarbeiten von Kundensystemen beschäftigt waren, sollten nun Lösungen entwickeln, mit denen der Flugbetrieb optimiert werden sollte. Es zeigte sich, dass die Spezialisten nicht flexibel genug waren.

Laut Berez ist das ein weit verbreitetes Problem. Oft könnten Entwickler nicht für andere einspringen und deren Aufgaben übernehmen. Seiner Meinung nach können CIOs dieses Problem lösen, indem sie in verschiedenen Bereichen des Unternehmens die gleiche Technologie einsetzen und gleichzeitig ihre Mitarbeiter übergreifend schulen, so dass diese sich mit mehreren Technologien vertraut machen können. "Oft bedeutet das, neue Entwicklungen auf der Basis von Microservices vorzunehmen und in den verschiedenen Funktionsbereichen die gleiche Programmiersprache für diese Microservices zu verwenden", empfiehlt der Bain-Manager.

6. "Diese Regel gilt nicht für uns"

Wie alle Methodologien sehen auch agile Frameworks die Nutzung von Best Practices vor. West hat jedoch erlebt, dass viele Organisationen von den empfohlenen Abläufen abweichen, weil sie sich mit ihrer Aufgabe als "besonderen Fall" beziehungsweise als Ausnahme sehen. Später fragen sie sich dann, warum sie trotz ihres agilen Vorgehens die erwarteten Früchte nicht ernten konnten.

Der CEO von Scrum.org hat auch erlebt, dass Organisationen bestimmte Geschäftsbereiche - zum Beispiel das Marketing - explizit vom agilen Vorgehen ausschließen. Die Prozesse dort seien zu einzigartig, laute in der Regel die Begründung. In Wirklichkeit scheuten die Verantwortlichen in solchen Unternehmen meistens den Konflikt mit den Bereichsfürsten. Die Bereitschaft, "territoriale Schlachten" zu schlagen, gehe den Managern ab. Zu sagen 'Ich bin etwas Besonderes' sei eine probate Entschuldigung, wenn man in Wirklichkeit keine Lust auf Auseinandersetzung und Veränderung habe.

Natürlich, so betont West, ist jede neue Aufgabe und Situation irgendwie einzigartig. Doch die den agilen Methoden zugrundeliegenden Lehrsätze seien absolut übertragbar auf die unterschiedlichsten Szenarien. "Wenn Sie also ein agiles Prinzip brechen wollen, müssen Sie klar sagen, warum Sie das tun. Und sie müssen die Konsequenzen verstehen, die sich daraus ergeben", warnt West.

7. "Unsere Unternehmensstrukturen sind nicht betroffen"

Prashant Kelker, Partner bei der ISG, einem Technologieforschungs- und Beratungsunternehmen, warnt davor, sich nur mit den agilen Methoden zu beschäftigen und andere Aspekte zu vernachlässigen. "Allzu oft wird die parallel stattfindende strukturelle Veränderung im Unternehmen ignoriert", sagt der Experte. Was nutze methodische Vollkommenheit, wenn Abteilungsstrukturen, Positionen und Strategiefragen vernachlässigt würden?

Als Beispiel nennt Kelker die Mitarbeiterentwicklung. "Hier bekommt man es mit Ego-Themen wie Berufsbezeichnungen, Karrieren und beruflichem Fortkommen zu tun." Auch mit solchen Themen müssten sich Unternehmen in der agilen Neuaufstellung befassen.

8. "Budgets einmal im Jahr festzulegen, reicht weiter aus"

Zwar haben die meisten Organisationen heute agile Methoden eingeführt, doch an ihren Budgetierungspraktiken haben sie nichts geändert. "Was wir in vielen, vielen Organisationen sehen, ist, dass es viel zu lange dauert, ehe neue Geschäftsmöglichkeiten aufgegriffen werden können. Ebenso dauert es viel zu lange, Arbeiten zu stoppen, wenn sich abzeichnet, dass der erwartete Wert oder Nutzen nicht eintreten wird", beobachtet Berez.

Eine der Hauptursachen sei der Budgetprozess, der in den meisten Organisationen immer noch für das gesamte Geschäftsjahr erfolge. Laut Berez haben es erfolgreiche agile Organisationen geschafft, zu einem flexibleren Budgetprozess zu wechseln. Dort werden nun immer wieder kleinere Beträge freigegeben, wenn die Arbeit voranschreitet und sich Werte nachweislich einstellen. Dieses Vorgehen ähnele dem von Risikokapital-Gesellschaften mit ihren Finanzierungsrunden für Startups. Andere wenden einen Prozess an, bei dem bereitgestellte Mittel an erreichte Meilensteine gekoppelt werden. "Solche Budgetierungsansätze", so Berez, "schaffen mehr Flexibilität und Agilität".

9. "Meine Partner und Lieferanten müssen nicht agil sein"

IT-Führungskräfte denken meistens nur an ihre eigenen Teams und Prozesse, wenn es gilt agiler zu werden und den Geschäftseinheiten oder dem Markt schnell neue Produkte und Services bereitzustellen. Doch so einfach ist es nicht: Wer nicht über die Grenzen seines Unternehmens hinausschaut, wird irgendwann von Partnern und Dienstleistern eingebremst.

ISG-Analyst Kelker fragt: "Was ist denn, wenn Ihre Verträge mit Lieferanten alt sind und die Entwicklung nach dem Wasserfall-Modell vorsehen? Was ist, wenn die Art und Weise, wie Sie einkaufen, weiter nach dem guten alten Plan-Build-Run-Modell erfolgen muss? Was, wenn Ihr Sourcing kein DevOps zulässt?" IT-Teams könnten die Vorteile der Agilität nur dann in vollem Umfang nutzen, wenn sie auch ihre Lieferanten und Partner dazu bewegten, auf ihren Kurs einzuschwenken.

Kelker empfiehlt, dass IT-Verträge mit Lieferanten so abgefasst werden sollten, dass alle Parteien agile Methoden verwenden, damit schnell neue Funktionen und Verbesserungen in vorhersagbaren Schritten geliefert werden könnten. Mit strukturierten Zahlungen lasse sich solch ein Vorgehen sinnvoll unterstützen.

10. "Wir haben agile Methoden implementiert, also sind wir gut"

West von Scrum.com arbeitete einmal mit einem Softwareunternehmen zusammen, das seine agilen Fortschritte weiter vorantreiben wollte. Dabei habe das Management den Standpunkt vertreten: Scrum ist eingeführt, genauso wie alle anderen wichtigen agilen Prinzipien, hier gibt es nichts mehr zu verbessern. Die Führungskräfte glaubten das auch noch, als das Unternehmen nach mehreren separaten Sprints keine Produkte ausliefern konnte.

"Zu glauben, dass Agilität irgendwann abgeschlossen und der Gipfel erreicht ist, ist der ultimative Elefant im Raum. Dabei wird das so wichtige Element der kontinuierlichen Verbesserung komplett ausgeblendet", warnt West. Ohne kontinuierliche Verbesserung sei eine agile Organisation nicht denkbar. Wer seine Augen davor verschließe, werde früher oder später in Schwierigkeiten geraten. (hv)