Agilität: Wirkung und Nebenwirkung

Unser IT-Kostenbenchmark, den wir seit 2000 jährlich durchführen, zeigt seit einigen Jahren ein klares Muster: Die Aufwände für die IT steigen, während AuM und Bilanzsumme nicht im gleichen Mass wachsen. Dies hat mannigfaltige Ursachen und darf nicht den agilen Transformationen allein angelastet werden. Obwohl schon seit einigen Jahren eingeführt, haben sie diese Entwicklung kaum gebremst – in einzelnen Fällen eher verstärkt. Wie mit Agilität ein besseres Verhältnis zwischen Ertrag und Aufwand ermöglicht werden kann, wollen wir in diesem Artikel nachgehen.

Die Nutzung von KI als mächtiger Werkzeugkasten zahlt seit einigen Jahren ebenfalls in diese Gleichung ein. Um Komplexität zu reduzieren, zeigen wir im Folgenden lediglich mögliche «Hooks» für KI und vertiefen diese in nachfolgenden Artikeln.

Agilität ist in Schweizer Banken angekommen: Scrum Teams, Value Streams, Sprint Reviews, Jira, Confluence. Die Rituale sind etabliert, die Rollen besetzt, die Boards gefüllt.

Bessere Software zu tieferen Kosten entsteht daraus jedoch oft nicht. In Geschäftsleitungen hört man weiterhin dieselben Sätze wie vor zehn Jahren: «Wir wissen nicht, wann was fertig ist.» «Wir haben zu viele Vorhaben.» «Die Teams halten ihre Zusagen nicht ein.»

Dies sind Symptome. Die Ursachen liegen tiefer: 
Agilität wird einerseits zu stark auf Werkzeuge, Prozesse und Rituale – auf das Doing – reduziert. Gleichzeitig wird gerade auf dieser Ebene nicht selten übertrieben. Die Methode wird zum Selbstzweck.

Das Ergebnis: höhere Kosten, weniger Planbarkeit – und deutlich weniger Nutzen als erwartet. Wir haben grosse Agilitätsvorhaben in unterschiedlichen Rollen begleitet – als VR, als Risk Manager, als CTO und COO.

Unsere Erfahrung: es geht besser. Was wir dabei gelernt haben, möchten wir weitergeben – und mit Ihnen diskutieren (mehr dazu am Schluss).

Kennen Sie diese typischen Symptome?

• Kontrolle statt Steuerung. Die Geschäftsleitung will zu Recht wissen, was wann zu welchen Kosten geliefert wird. Aus diesem berechtigten Anspruch wird jedoch rasch Kontrolle und Micro-Vorgabe statt Steuerung.
• Zu viele parallele Vorhaben. Eine wirksame Priorisierung auf Portfolioebene findet nicht statt; neue Initiativen kommen hinzu, ohne dass andere beendet oder verschoben werden.
• Fehlende Mittelfristplanung. Kurzfristige Sprints ersetzen einen belastbaren, bewusst groben Planungsrahmen.
• Zusagen verlieren ihren Wert. Was in einem Sprint nicht gelingt, rutscht in den nächsten – die Zusagen der Teams waren faktisch nie verbindlich.
• Diffusion der Verantwortung. Mit der Einführung der agilen Methode vervielfachen sich Ansprechpartner für Budget, Termine, Methodik und Inhalt. Ein Verantwortungsträger fehlt.
• Methode vor Ergebnis. Die korrekte Anwendung der Methode erhält mehr Aufmerksamkeit als die Wirkung für Kunde und Unternehmen.

Wer diese Symptome isoliert behandelt – noch ein Coach, noch ein Tool, noch ein Framework-Update – löst die eigentlichen Probleme nicht. Es lohnt sich deshalb, genauer hinzusehen: Wofür wurde Agilität eigentlich konzipiert, welche Voraussetzungen braucht sie, und wo kippt sie vom Mittel zum Selbstzweck?

Ausgehend von den Ursprüngen der Agilität zeigen wir, weshalb viele Einführungen heute an einem, wie oben beschriebenen Punkt stehen und skizzieren welche Hebel auf Ebene Geschäftsleitung und Verwaltungsrat entscheidend sind.

Agilität – der Ursprung

Ab den 1990er-Jahren traf die Softwareentwicklung auf ein Umfeld, das volatiler, unsicherer und vielschichtiger wurde. Lange Spezifikationsphasen und mehrjährige Umsetzungen passten immer weniger zu Märkten, Technologien und Kundenbedürfnissen, die sich während eines Projekts bereits wieder stark veränderten.

Das Agile Manifest von 2001 verdichtete den Gegenentwurf dazu in vier Wertpaaren:

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
• Funktionierende Software ist wichtiger als umfassende Dokumentation.
• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung.
• Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Wichtig – und oft überlesen: Das Manifest hält ausdrücklich fest, dass auch die rechte Seite dieser Wertepaare ihren Wert behält. Pläne, Dokumentation und Prozesse abzuschaffen, war nie gemeint.

Die Idee war überzeugend: kürzere Lieferzeiten, schnellere Reaktion auf neue Anforderungen und letztlich mehr (Kunden-) Nutzen pro investiertem Franken.

Formuliert wurde das Manifest von 17 erfahrenen Softwareentwicklern, darunter prägende Köpfe der damaligen Szene. 
In geeigneten Kontexten zeigte sich der Ansatz dem klassischen Wasserfallmodell deutlich überlegen – insbesondere dort, wo kleine, leistungsfähige Teams eng mit Kunden arbeiteten und rasch belastbares Feedback erhalten.

Warum der Nutzen ausbleibt

Getrieben durch das Nutzenversprechen schneller mehr und passgenauere Funktionalität in der Software zu erhalten, wurde Agilität ab den 2010er-Jahren, breit eingesetzt und skaliert: über die Softwareentwicklung hinaus auf IT-Grossprojekte, Produktentwicklung und ganze Organisationen. Das erklärte Ziel blieb dasselbe: schneller mehr Kundennutzen erzeugen.

Heute stellen viele Unternehmen ernüchtert fest, dass dieser Nutzen nur teilweise eingetreten ist.

Nach unserer Erfahrung gibt es dafür zwei grundlegend unterschiedliche Hauptursachen:

• Agilität im falschen Kontext: Ein Vorhaben eignet sich nur begrenzt für agiles Arbeiten. Es ist also nicht die Umsetzung das Problem, sondern Agilität ist schlicht die falsche Methode.
• Falsch dosierte Agilität: Agilität als Methode passt, sie wird jedoch meist unausgewogen und teilweise dogmatisch überdosiert eingesetzt.

Falscher Kontext - wann Agilität nicht die Antwort ist

Agilität ist kein Allheilmittel und kein Selbstzweck, sie eignet sich besonders für Vorhaben mit hoher Unsicherheit und Veränderungsdynamik. Typisch sind drei Merkmale:

• Ergebnisoffen: Nutzen und Machbarkeit sind zu Beginn nicht gesichert – es gibt Hypothesen statt Anforderungen.
• Neuartiger Wertbeitrag: ein neues Angebot, ein neuer Prozess oder ein neues Geschäftsmodell mit erkennbarem Kundennutzen oder Wettbewerbsvorteil.
• IT als Enabler oder Kern: Software, Daten, Plattformen oder KI sind für die Umsetzung entscheidend, nicht nur Begleitmassnahme.

Fehlen diese Merkmale, ist ein agiles Vorgehen of nur begrenzt sinnvoll, etwa bei:

• Vorhaben mit stabilem oder regulatorisch weitgehend fixiertem Ergebnis, etwa bestimmte Compliance-Umsetzungen oder Migrationen mit klar definiertem Zielbild.
• Arbeiten mit harter externer Terminvorgabe und geringem Gestaltungsspielraum.
• Einführung von Standardsoftware, wenn der Lösungsraum wesentlich durch das Produkt vorgegeben ist.
• Legacy-Ablösungen, bei denen im Wesentlichen bestehende Funktionalität ersetzt werden soll.

Solange der Wertfluss durch das Unternehmen noch ungeklärt ist, sollte man nicht mit der Methodeneinführung beginnen. Sonst entstehen Zeremonien ohne Wirkung – und die Glaubwürdigkeit der Agilität leidet gerade dort, wo sie tatsächlich helfen könnte.

Falsche Dosis: ausgewogenes Doing, Being und Enabling erforderlich

Doing, Being und Enabling sind drei Dimensionen einer Transformation, die in Balance gehalten werden müssen, wenn die Veränderung nachhaltig in der Organisation ankommen und ihre Wirkung vollständig entfalten soll.

Wir beobachten, dass der häufigste Einstieg in die agile Transformation über das Doing vorgenommen wird, denn Werkzeuge, Rollen und Zeremonien sind sichtbar, schulbar und beschaffbar. Dieser Einstieg kann sinnvoll sein. 
Leider bleibt die Transformation aber leicht dort stecken, wenn die ebenfalls notwendige Transformation auf den Dimensionen Being und Enabling ausbleibt. Mit dem Resultat, dass nach zwei Jahren detaillierte Rollenmodelle, Tools und Zertifikate existieren – die alten Steuerungsprobleme jedoch nach wie vor vorhanden sind.

Positive Praxisbeispiele zeigen, dass es wirksamer ist, bei Enabling und Being anzusetzen und das Doing daraus abzuleiten. Alle drei Elemente entwickeln sich dann gemeinsam weiter – in einem Tempo, das zur bestehenden Kultur passt.

Konkret heisst das:

Enabling: Voraussetzungen schaffen

Das ist primär Aufgabe von Geschäftsleitung und Verwaltungsrat, nicht von Coaches.

• Das Jahresbudget beibehalten, darunter aber rollierend planen – entlang definierter Eignungskriterien entscheiden, wo Teams oder Value Streams statt einzelner Projekte finanziert werden.
• Auf Portfolioebene konsequent priorisieren und die Zahl paralleler Vorhaben explizit begrenzen.
• Entscheidungskompetenz dorthin delegieren, wo die Arbeit stattfindet und das Wissen ist – verbindlich und nachvollziehbar, nicht nur als Absichtserklärung.
• Die Organisation stärker entlang der Wertschöpfung ausrichten und die Konsequenzen für Linienfunktionen mitdenken.
• Eine Mittelfristplanung als bewussten Orientierungsrahmen beibehalten: grobkörnig genug für Anpassungen, konkret genug für Steuerung.
• Hier sehen wir potentiell Hooks zu KI-Nutzung.

Being: Neue Haltung durch gelebte Führung prägen

Haltung entsteht weniger durch Schulung als durch beobachtbares Führungsverhalten. Bei erfolgreichen agilen Transformationen haben wir typischerweise folgende Veränderungen in der Führung festgestellt.

• Die Führung fragt nicht nur nach Kennzahlen, sondern auch nach Hindernissen und unterstützt bei deren Beseitigung.
• Die Führung unterstützt dabei, Probleme und Fehler früh sichtbar zu machen, ohne die Person zu sanktionieren.
• Ein qualifiziertes Nein zu einem Vorhaben wird als gewünschtes Verhalten anerkannt, nicht als Mangel an Engagement.
• Die Geschäftsleitung lebt diese Prinzipien vor – mit klaren Prioritäten (bewusste Reihenfolge und Verzicht), und einem begrenzten eigenen Backlog.

Doing: bewusst einfach beginnen

Auf obiger Grundlage werden die Werkzeuge – bewusst minimalistisch - eingeführt: ein Board, ein Rhythmus, eine Definition of Done. Jedes zusätzliche Element muss seinen Nutzen rechtfertigen. Dies gilt auch für den Einsatz von KI, die auf dieser Stufe viele Hooks hat.

Was das für Geschäftsleitung und Verwaltungsrat heisst

• Agilität ist ein Steuerungsthema, kein Methodenthema. Diese Steuerung lässt sich nicht an Coaches oder einzelne IT-Bereiche delegieren; relevante Prinzipien müssen auch auf Stufe Geschäftsleitung/Verwaltungsrat definiert und wirksam werden.
• Einsatzfeld bewusst abgrenzen. Legen Sie fest, wo Agilität eingesetzt wird und wo nicht, welche Rahmenbedingungen Sie bereit sind, zu schaffen (Delegation von Verantwortung, Budget) und woran Sie nach dem ersten Lernzyklus erkennen, ob sie wirkt.
• Messen Sie Wirkung statt Einführung. Entscheidend sind nicht Anzahl Teams, Zertifikate oder Velocity, sondern Durchlaufzeit von der Idee bis zum Nutzen, Zahl paralleler Vorhaben und Termintreue über mehrere Quartale.

Einladung zum Erfahrungsaustausch

Kommt Ihnen diese Symptomatik bekannt vor? Eine strukturierte Aussensicht kann rasch zeigen, ob die Ursachen primär in den Teams, in der Führung oder in den organisatorischen Rahmenbedingungen liegen.

In einem kuratierten, halbtägigen und kostenfreien Erfahrungsaustausch mit senior IT-Leadern von Schweizer Banken und Versicherungen wollen wir Erwartungen, Symptome und unterschiedliche Ursachenbilder vergleichen. Vorgängig erheben wir in einer kurzen Umfrage die Ausgangslage und verdichten die Antworten zu Hypothesen als Startpunkt für die Diskussion.

Ziel ist keine weitere Methodendebatte, sondern eine belastbare gemeinsame Sicht auf die aktuelle Situation – und konkrete Ansätze, mit denen Agilität wieder stärker auf ihren eigentlichen Zweck ausgerichtet werden kann, sodass in kürzerer Zeit wirklich passgenauere Funktionalität entsteht.