Alle sind agil – oder doch nicht?

Oft ist im agilen Wandel Selbsttäuschung im Spiel

Die meisten Unternehmen verwenden agile Ansätze für die Bereitstellung neuer Software oder Funktionen. Der 14. „Annual-State-of-Agile“-Bericht, der im Mai 2020 von Digital.ai veröffentlicht wurde, ergab, dass 95 Prozent der Befragten in ihren Organisationen nach agilen Methoden arbeiten. Ihre Motive sind die schnellere Softwarebereitstellung, kürzere Reaktionszeiten bei sich ändernden Anforderungen sowie mehr Produktivität.

Nicht immer erzielen aber die Unternehmen die erwarteten Vorteile in vollem Umfang. Das liegt auch daran, dass die Verantwortlichen die Augen vor hartnäckigen Problemen verschlossen halten. „Alle sagen heute, 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, die sie angestrebt haben“, bilanziert Dave West, CEO von Scrum.org. Welche Fehler machen also die Unternehmen, und wo neigen die Verantwortlichen dazu, sich selbst zu belügen? Wir haben die häufigsten Fehleinschätzungen und Selbsttäuschungen zusammengetragen und uns dabei auf die Aussagen von 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 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, Tools 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.“

2. „Techniker brauchen keine Schulungen“

Das deutsche Finanzinstitut DZ 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 DevOps 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.

IT-Führungskräfte gehen offenbar häufig davon aus, dass ihre IT-Spezialisten gern und ohne große Anleitung die neuesten Tools aufgreifen und nutzen wollen. Wie Ehm erfahren musste, braucht aber auch diese Expertengruppe Schulungen und Strategien für das Change Management. „Techniker spielen gern 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 heute mehr auf die Menschen und darauf, sie dorthin zu bringen, dass sie Technologien optimal nutzen.

3. „Die Teams werden ihre Meetings schon kurz halten“

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 dreimal 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 ver

schiedener 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 arbeiten.

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 dafür 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 dagegen vorgehen, indem sie in verschiedenen Bereichen des Unternehmens die gleiche Technologie einsetzen und gleichzeitig ihre Mitarbeiter übergreifend schulen, sodass 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 fragten 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 hat.

Natürlich, so betont West, ist jede neue Aufgabe und Situation irgendwie einzigartig. Doch die den agilen Methoden zugrunde liegenden 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 beim Technologieforschungs- und Beratungsunternehmen ISG, 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 Unter

nehmen 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 lang dauert, ehe neue Geschäftsmöglichkeiten aufgegriffen werden können. Ebenso dauert es viel zu lang, 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 empfiehlt, IT-Verträge mit Lieferanten so abzufassen, dass alle Parteien agile Methoden verwenden, damit schnell neue Funktionen und Verbesserungen in vorhersagbaren Schritten geliefert werden könnten. Mit strukturierten, erfolgsbasierten Zahlungen in Häppchen lasse sich solch ein Vorgehen sinnvoll unterstützen.

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

Dave 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, wir sind fertig. Hier gibt es nichts mehr zu verbessern. Die Führungskräfte glaubten das sogar auch dann 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“, warnt West. „Dabei wird das so wichtige Element der kontinuierlichen Verbesserung komplett ausgeblendet.“Ohne kontinuierliche Verbesserung sei eine agile Organisation nicht denkbar. Wer seine Augen davor verschließe, werde früher oder später in Schwierigkeiten geraten. Nicht umsonst heißt es im Agilen Manifest: „In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden kann. Dann stimmt es sein Verhalten entsprechend ab und passt es an.“