In dem Bestreben, die Softwarebereitstellung zu beschleunigen, gehen IT-Unternehmen agil vor, aber allzu häufige Selbsttäuschungen und hartnäckige Probleme bleiben meist auf der Strecke. [...]
Die meisten Unternehmen verwenden heute agile Software-Bereitstellungsmodelle mit dem Ziel, neue Funktionen so schnell wie möglich bereitzustellen.
Bedenken Sie die Zahlen: Im 14. Jahresbericht zum Stand der Agilität, der im Mai 2020 von Digital.ai veröffentlicht wurde, gaben 95 Prozent der Befragten an, dass ihre Unternehmen agil arbeiten und dass die Hauptgründe dafür die Beschleunigung der Software-Bereitstellung, die Verbesserung der Fähigkeit zur Bewältigung sich ändernder Prioritäten und die Steigerung der Produktivität sind.
Ungeachtet solch ehrgeiziger Ziele sagen agile Experten und Praktiker jedoch, dass viele Unternehmen nicht die angestrebte Geschwindigkeit erreichen, weil sie die Augen vor hartnäckigen Problemen in ihrer Arbeitsweise verschlossen haben.
„Alle geben an, dass sie agil sind, aber viele sind es nicht oder sie tun es nicht so viel oder nicht so gut, wie sie es sich wünschen“, erklärt Dave West, CEO von Scrum.org.
Wo also versagen Unternehmen, ohne sich dessen bewusst zu sein? Hier sind 10 häufige Selbsttäuschungen, die nach wie vor die Bereitstellung von Software verlangsamen.
1. Wir sind agil, weil wir die Begriffe verwenden
Im Westen haben IT-Teams die Nomenklatur der agilen Methoden übernommen, Projektmanager in Scrum-Master umbenannt und Arbeitsgruppen in Tribes. Zugegeben, die Verwendung der richtigen Begriffe kann wichtig sein, aber oft handelt es sich dabei nur um eine oberflächliche Änderung. Solche Schritte müssen durch die substantiellere Arbeit der Umstrukturierung des Unternehmens unterstützt werden, damit die geleistete Arbeit mit den neuen Titeln übereinstimmt.
„Allzu oft machen die Leute dasselbe, sie nennen es nur anders. Sie mögen die Namen geändert haben, aber nicht die Bestandteile. Und die meisten Leute geben zu dieser Erkenntnis nur Lippenbekenntnisse ab“, sagt West.
Christine Hales, Vizepräsidentin für Technologie bei Capital One, stimmt dem zu.
„Das ist wirklich ein kultureller Wandel. Wenn man es als ein Bündel von Prozessen und Tools angeht, verpasst man das, was wirklich möglich ist“, sagt Hales. „Menschen müssen als Teams anders zusammenarbeiten; das ist ein kultureller Wandel.“
2. Tech-Spezialisten brauchen keine Schulung für Tools und Prozessänderungen
Das deutsche Finanzinstitut DZ Bank hat im Laufe der Jahre eine Reihe von Technologien eingeführt, um seine langjährige DevOps-Praxis zu unterstützen, aber Henning Ehm, Leiter von DevOps bei der in Frankfurt am Main ansässigen Bank, stellte fest, dass die Einführung solcher Tools ein Glücksfall war.
„Ich dachte: ‚Ich tue etwas Gutes, um den Menschen zu helfen, ich werde die Technologie entwickeln und sie werden sie richtig einsetzen. Aber was wir beobachteten, war viel Widerstand“, sagt er.
Es ist nicht ungewöhnlich, dass IT-Führungskräfte davon ausgehen, dass ihre eigenen Technologen automatisch die neuesten Tools aufgreifen und ihre Nutzung schnell steigern werden. Doch wie Ehm gelernt hat, brauchen Technologen eine Schulung und profitieren auch von Strategien zum Änderungsmanagement.
„Technologen spielen gerne herum, aber das wahre Potenzial aus Tools herauszuholen und sie in unsere Prozesse einzuführen, ist harte Arbeit. Man muss sich sehr um den Änderungsprozess bemühen“, meint Ehm. „Jetzt konzentriere ich mich mehr auf die Menschen und darauf, wie man sie dorthin bringt, wo sie die Technologie optimal nutzen können“.
3. Teams halten die Meetings kurz
Agile Praktiken verzichten auf lange formelle Treffen zugunsten kurzer Huddles und anderer solcher Engagements, aber alte Gewohnheiten lassen sich nur schwer ablegen. Ehm berichtet zum Beispiel, er habe Scrum-Sitzungen erlebt, die 15 Minuten dauern sollten und dreimal so lange dauerten, wobei die Teilnehmer die Zeit nutzten, um alle möglichen Anliegen und Themen anzusprechen.
„Besprechungen sollten einen ganz bestimmten Zweck haben, und viele Leute sind das nicht gewohnt“, meint er und verweist auf die Notwendigkeit, dass Manager die Teams darüber aufklären müssen, wie Besprechungen bei der Einführung von Agilität funktionieren sollten, sowie auf die Notwendigkeit, dass Manager die zeitlichen und thematischen Beschränkungen durchsetzen müssen.
„Jetzt diskutieren wir in unseren Meetings nur über eine Sache und nur über diese eine Sache“, sagt Ehm.
4. Die Freiheit, Tools und Prozesse frei zu wählen, ermöglicht Schnelligkeit
Obwohl moderne Praktiken Teams dazu ermutigen, Wege zu wählen, die für sie funktionieren, hat Amit R. Bhandarkar, Leiter der Technik bei American Express Global Business Travel, die Kehrseite dieses Ansatzes erkannt.
Er berichtet, dass seine Teams am Ende mit unterschiedlichen CI/CD-Tools arbeiteten, wobei einige Open-Source-Lösungen und andere Angebote verschiedener Anbieter nutzten. „Sie erzielten das gleiche Ergebnis, aber auf unterschiedliche Weise, und das beeinträchtigte die Agilität; einige Teams waren völlig überfordert, andere hatten Probleme“, sagt Bhandarkar.
Als Reaktion darauf standardisierten die Entwicklungsteams und gingen zu einer einzigen, konsistenten Umgebung über, die einheitlichere Erfolgsraten unterstützt und auch den Wartungsaufwand für die Entwickler verringert.
Bhandarkar glaubt, dass daraus eine Lehre gezogen werden kann. „Sie sollten in Ihrem Ansatz überall dort, wo es Wahlmöglichkeiten gibt, präskriptiv sein; ob es nun um die spezifische Methodik geht, die Sie wollen, oder um die Länge Ihrer Sprints, Sie sollten präskriptiv und konsistent sein, damit alle miteinander abgestimmt sind“, sagt er.
5. Meine Teams sind flexibel genug
Steve Berez, Partner bei Bain & Co. und Mitautor von Doing Agile Right, arbeitete einst mit einer Fluggesellschaft zusammen, die ihre Ingenieure brauchte, um neue Fähigkeiten für ihren Flugbetrieb zu schaffen, während sie gleichzeitig weniger Arbeit an den Kundensystemen brauchte; aber die Anzahl der Ingenieure, die am Flugbetrieb arbeiten konnten, war begrenzt, so dass die IT-Abteilung weniger auf wechselnde Geschäftsanforderungen reagierte.
Das ist ein weit verbreitetes Problem, sagt Berez und fügt hinzu, dass „die Ingenieure nicht fungibel genug sind“.
Seiner Meinung nach können CIOs dieses Problem angehen, indem sie vermehrt gemeinsame Technologien in verschiedenen Bereichen des Unternehmens einsetzen und gleichzeitig ihre Mitarbeiter stärker übergreifend schulen, so dass die Mitarbeiter an mehreren Technologien gleichzeitig arbeiten können.
„Was es oft bedeutet, ist, dass neue Entwicklungen unter Verwendung von Mikrodiensten durchgeführt werden und für diese Mikrodienste sogar über die verschiedenen Funktionsbereiche hinweg dieselbe Entwicklungssprache verwendet wird“, erklärt er.
6. Diese Regel betrifft uns nicht
Wie alle Methodologien befürworten agile Frameworks die Verwendung einer Liste von Best Practices.
Der Westen hat jedoch erlebt, dass viele Unternehmen die Notwendigkeit der Befolgung einiger vorgeschriebener Prozesse abtaten und sich selbst als ausgenommen betrachteten – nur um sich dann zu fragen, warum sie nicht so viele Vorteile von agilen Frameworks sehen, wie sie erwartet hatten.
Er hat zum Beispiel erlebt, dass Unternehmen eine bestimmte Geschäftsgruppe – wie das Marketing – von agilen Teams ausschließen mit der Begründung, dass es in ihrem Unternehmen einfach nicht funktionieren wird, weil ihre Prozesse viel zu einzigartig sind, während es in Wirklichkeit nur eine Territorialschlacht ist, die niemand schlagen will.
„Das ‚Ich bin etwas Besonderes‘ ist eine gute Entschuldigung für das ‚Ich kann das nicht in Ordnung bringen'“, erklärt er.
West fährt fort: „Jeder Mensch ist einzigartig, aber in Wirklichkeit sind sie es und sie sind es nicht. Es stimmt, dass jede Situation einzigartig ist, und dass ein Modell nicht für alles und jede Situation gilt, aber die zugrundeliegenden Lehrsätze schon. Wenn Sie also [ein agiles Prinzip] brechen wollen, müssen Sie klar sagen, warum Sie es tun, und die Konsequenzen verstehen, die sich daraus ergeben.“
7. Prozessänderung ist genug
„Im Moment wird so viel Wert auf agile Methoden und Zeremonien gelegt, dass alle die Struktur ignorieren“, so Prashant Kelker, Partner bei ISG, einem Technologieforschungs- und Beratungsunternehmen.
Ihm zufolge müssen agile Befürworter innerhalb des Unternehmens auch überlegen, wie sie ihre Abteilungen und ihre Produkte umstrukturieren, indem sie zum Beispiel bestimmen, ob solche Elemente auf Kunden oder Prozesse ausgerichtet sind.
Das ist ein schwieriger Bereich, räumt Kelker ein. „Wenn man einmal anfängt, über Struktur zu sprechen, dann befasst man sich mit dem Ego, den Berufsbezeichnungen, der Karriere und dem beruflichen Aufstieg der Mitarbeiter“, sagt er, betont aber dennoch die Notwendigkeit, sich mit Struktur zu befassen.
8. Unser Budgetierungsprozess bremst uns nicht
Obwohl die meisten Unternehmen agile Methoden eingeführt haben, erkennen nach Ansicht von Management-Experten viele von ihnen nicht die Notwendigkeit an, langjährige Budgetierungspraktiken zu aktualisieren.
„Was wir in vielen, vielen Unternehmen sehen, ist, dass es zu lange dauert, den Prozess der Verfolgung einer neuen Geschäftsmöglichkeit zu beginnen. Und es dauert zu lange, die Arbeit an etwas einzustellen, wenn sich herausstellt, dass der von ihnen [erwartete] Wert nicht vorhanden ist“, sagt Berez. „Das kommt oft daher, dass viele Unternehmen immer noch Projekte auf jährlicher Basis finanzieren“, meint er.
Berez erklärt, dass die erfolgreichsten agilen Organisationen von der Entscheidung, welche Initiativen jährlich finanziert werden sollen, zu einem Budgetierungsprozess übergegangen sind, bei dem kleinere Beträge häufiger ausgezahlt werden, wenn die Arbeit voranschreitet und sich ihr Wert beweist – ein Prozess, der der Risikokapitalfinanzierung ähnelt. Andere wenden einen Prozess an, bei dem befugte Produkteigentümer über einen bestimmten Zeitraum gestreckte Mittel einsetzen, um bestimmte Geschäftsergebnisse zu erzielen.
Solche Budgetierungsansätze, so Berez, „schaffen mehr Flexibilität und Agilität“.
9. Meine Partner und Lieferanten müssen nicht auch agil sein
IT-Führungskräfte sind im Allgemeinen davon überzeugt, dass sie durch Änderungen an ihren eigenen Teams und internen Prozessen die Geschwindigkeit und Agilität erhalten, die sie benötigen, um neue Fähigkeiten so schnell bereitzustellen, wie es ihre Geschäftseinheiten und der Markt erfordern.
Das reicht jedoch nicht aus, sagt Kelker. Sie müssen auch ihre Partner mit ins Boot holen.
Er fügt hinzu: „Was ist, wenn die Verträge mit Ihren Lieferanten nur einen Waterfall zulassen? Was, wenn die Art und Weise, wie Sie einkaufen, ein Plan-Build-Run ist? Was, wenn Ihre Beschaffung keine DevOps zulässt?“
Kelker sagt, dass IT-Teams in Unternehmen die Vorteile der Agilität nur dann in vollem Umfang nutzen können, wenn – und solange – sie ihre Lieferanten und Partner dazu bewegen, diesem Beispiel zu folgen. Er weist darauf hin, dass IT-Verträge mit ihren Drittlieferanten so verfasst werden sollten, dass sichergestellt ist, dass alle Parteien agile Methoden verwenden, um schnell neue Funktionen und Merkmale sowie inkrementelle Verbesserungen zu liefern – mit strukturierten Zahlungen zur Unterstützung dieser Entwicklung.
10. Wir haben Agile implementiert, also sind wir gut
West arbeitete mit einem Softwareunternehmen zusammen, um seine agilen Praktiken zu skalieren, als er einen der Führungskräfte nach der Effektivität der Scrum-Praktiken des Unternehmens fragte. Der Geschäftsführer war ablehnend und sagte, das Unternehmen habe diese Praktiken bereits eingeführt. Er hielt die Scrum-Praktiken (wie auch die anderen agilen Prinzipien, die das Unternehmen im Laufe der Zeit eingeführt hatte) für beschlossene Sache und war der Ansicht, dass an dieser Denkweise nichts auszusetzen sei, auch wenn sein Unternehmen nach mehreren separaten Sprints keine Produkte liefern konnte.
„Sie glauben, dass Agilität machbar und durchsetzbar ist: Das ist der letzte Elefant im Raum. Sie vergessen völlig das Element der kontinuierlichen Verbesserung“, erklärt West. „Und wenn Sie die Augen davor verschließen, wenn Sie keinen Plan haben, wie Sie für Ihre agilen Praktiken kontinuierliche Verbesserungen erzielen können, dann haben Sie am Ende ein Problem.“
*Mary K. Pratt ist freiberufliche Journalistin mit Sitz in Massachusetts.
Be the first to comment