Als Division Leader Group IT Delivery bei der Raiffeisen Bank International (RBI) hat Elisabeth Geyer-Schall die Transformation der Bank in den letzten 3,5 Jahren entscheidend geprägt und vorangetrieben. Im Interview mit TechTalk erzählt sie von ihren bisherigen Erfahrungen, Fehlern und Learnings.

Christian Hassa begleitet mit seinem Team die RBI seit 2011 erfolgreich im Agilen Change. In den letzten Jahren war es Change-Arbeit auf Teamebene, genauso wie die Arbeit an Skalierungsthemen.

Wie hättest du die Transformation schneller durchführen können?

In der Raiffeisen Bank International (RBI) haben wir sehr darauf gesetzt, dass wir eine nachhaltige Veränderung mit Substanz erreichen – und zwar auf Ebene der Teams für ihre tägliche Arbeit. Wir sprechen also nicht von einem „Change auf Powerpoint“, der von Consultants ansprechend präsentiert wird und dann häufig nicht die Umsetzungsebene erreicht. In Anbetracht der Qualität und Tiefe, die wir erreicht haben, bin ich davon überzeugt, dass wir die Veränderung nicht wahnsinnig viel schneller hätten durchführen können. 

Die Geschwindigkeit des Changes ist für mich eine direkte Funktion der Qualität. Je schneller der Change ist, desto weniger tief gelingt die Veränderung. Ich bezweifle daher, dass eine nachhaltige Veränderung sehr viel schneller machbar ist, zumal ja sehr rasch Skalierungsthemen der Organisation zur Herausforderung werden. Diese müssen schon aus Risikogründen in kleinen Schritten adressiert werden, z.B. wie erfolgt die Steuerung und Transparenz der Teams, wie erfolgt die Verantwortungsabgrenzung der unterschiedlichen Rollen im agilen Team oder wie müssen sich HR- oder Finance-Prozesse verändern. Aber der Change hätte für alle Beteiligten weniger schmerzhaft ablaufen können.

Wie hättest du die Transformation denn weniger schmerzhaft gestalten können?

Zum einen hätten wir mehr Zeit investieren sollen, eine gemeinsame Sichtweise im Vorstand und im Change Team herzustellen. Wir hätten uns klarer abstimmen sollen, was die große Vision ist, welche Elemente vom Change betroffen sind und was in welcher Zeit realistisch ist. Ich denke, die wenigsten Executives sind sich dessen bewusst, wie umfassend der Change ist, an wie vielen Ecken ein Paradigmenwechsel erforderlich ist (Führung, Menschen, IT, Arbeitsorganisation, Kultur, Steuerung, etc.). Es muss sich das gesamte Organisationssystem und allen voran das Verhalten der Menschen adaptieren. Ein sehr komplexes Problem, das leider wenig vorhersehbar oder planbar ist und Zeit braucht. Dieser Change funktioniert nur schrittweise, mit „inspect and adapt“ und kontinuierlicher Weiterentwicklung. 

Zum anderen hätte ich auch das Thema „Zeit“ und die realistische Erwartung, was bis wann machbar ist, besser berücksichtigen können. Mit heutigem Wissensstand kann ich teilen, dass nach 3,5 Jahren 1000 Mitarbeiter der RBI in nachhaltig agilen Produkt-, Plattform- und Service-Teams arbeiten. Manche sind noch am Beginn, aber dennoch ist das agile Arbeiten und Mindset für sie alle völlig normal. Die Veränderung war eine grosse. Wir haben zudem auch davon profitiert, dass wir in der RBI seit 2011 mit „agilen Projekten“ experimentiert haben. 

Last but not least ist es wichtig zu verstehen, dass es bei diesem Change einzig und allein um die Menschen geht und wie wir mit ihnen umgehen. Alle anderen Themen sind auch komplex und brauchen viel Einsatz und neue Fähigkeiten (z.B. von einer traditionellen IT auf eine agile IT umzustellen). Trotzdem geht es immer um die Menschen, das Mindset und die Kultur. Damit die Organisation und die Menschen den Change gut schaffen, braucht es sehr viel Vertrauen, Zutrauen, Ermutigung und Sicherheit. Alle Ebenen müssen gemeinsam an der Veränderung arbeiten und regelmäßig offen reflektieren.

Außerdem braucht es eine starke Wertschätzung gegenüber dem „Bestehenden“, damit die Leute sich gut öffnen können für die nötigen Veränderungsschritte. Das ist der wohl wichtigste Beitrag der Leader. Auch diesem Thema würde ich beim nächsten Mal mehr Raum und Bedeutung geben. 

Welche Fehler hat hast du selbst gemacht?

Bei einer Veränderung dieser Größe gibt es viele kleine und große Fehler. Es ist wichtig, Fehler transparent zu behandeln, um möglichst schnell daraus lernen und darauf reagieren zu können.

Das hilft auch bei der Etablierung einer positiven Fehlerkultur, welche eine wichtige Grundlage für eine erfolgreiche Veränderung ist. 

Ich hätte den oben genannten Themen mehr Aufmerksamkeit schenken müssen und mich für noch mehr Alignment einsetzen sollen. Innerhalb des Change-Prozesses gab es ein sehr hohes Tempo. Hier hätte ich mehr Zeit für Reflexion einräumen sollen und stärker darauf achten sollen, das richtige Tempo zu finden. Für unsere IT war die Veränderung anfangs besonders schmerzhaft. Hier würde ich heute mit Unterstützung von externen Beispielen klarer kommunizieren, welche Veränderungen in der IT notwendig sind, um agiler liefern zu können.

Rückblickend haben wir es geschafft – vielleicht wäre es mit weniger Schmerz gegangen. Mir wird nachgesagt, sehr fordernd und konsequent zu sein – die richtige Balance zwischen Klartext und Diplomatie zu finden, ist jedenfalls eine Herausforderung. Ich hätte auch das Thema laufende Kommunikation an die breite Organisation früher starten müssen. Diesen Punkt habe ich zu Beginn unterschätzt. 

Ein weiterer Fehler war, dass wir den Change sehr fundiert bottom-up vorangetrieben haben und teilweise zu wenig in die „top-down-Komponente“ investiert haben. Wir haben uns zu Beginn sehr stark darauf fokussiert, mit den Teams selbstständig zu arbeiten. Das war auch eine gute Vorgehensweise. Allerdings ist es gleichzeitig wichtig, dass sich diese Veränderungen in einem nachgelagerten Schritt im Board widerspiegeln. Hierauf hätten wir uns noch stärker fokussieren können.

Außerdem hätten wir gerade zu Beginn stärker mit Work-in-Progress-Limits (WIP-Limits) arbeiten sollen und dadurch die Anzahl der angefangenen Arbeiten begrenzen sollen. In unserem Fall hätten wir die Anzahl der Teams, mit denen wir arbeiten, stärker einschränken und besser priorisieren können. Denn vor allem zu Beginn gab es ein große Nachfrage aus dem Unternehmen. Alle Teams waren motiviert, direkt mit dem Change-Prozess zu beginnen. Eine Arbeit mit allen Teams gleichzeitig ist bei dieser Unternehmensgröße jedoch nicht möglich. 

Bist du auf Widerstände bei der Umsetzung gestoßen? 

Natürlich gab es Widerstände, aber diese kamen immer mit einem relevanten Grund: Typischerweise war es ein Nichtverständnis, was von einem erwartet wird, ob man das leisten kann. Häufige Fragen gingen in Richtung Verantwortung. Teilweise war es ein unter Druck sein, weil die Kollegen den Eindruck erhalten, dass ihre bisherige Arbeit schlecht war. Teilweise war es auch eine Situation, dass das „Standard-Scrum-Setup“ für ihren Arbeitskontext nicht passte. Daher haben wir auch nicht religiös und starr umgesetzt, sondern haben das passende agile Setup auf Teamebene etabliert mit einem Agile Coach. Wir hatten vorher überhaupt keine Erfahrung mit echter Teamarbeit. Wir kommen aus einer Kultur der Einzelkämpfer und des gegenseitigen Wettbewerbs. Außerdem gab es viel Angst vor der hohen Transparenz, weil in unserem Umfeld diese sehr häufig missbraucht wurde. Zuvor wurden die Mitarbeiter oft „bestraft“ anstatt die Transparenz als den ehrlichen Weg zu sehen, die Situation zu verstehen und gemeinsam daran zu arbeiten. 

Nach fast vier Jahren sehe ich Widerstände gegen die Change-Arbeit überhaupt nicht mehr als „gemeine Blocker“, sondern sie sind praktisch immer ein Spiegel für ein kulturelles oder strukturelles Problem, das noch zu lösen ist.

Inzwischen bin ich sogar dankbar dafür, weil es eine ehrliche Reflexion ist. Außerdem müssen wir bedenken, dass neben dem Change unsere normale Arbeit und Lieferung weitergehen muss. Wir sind eine Bank in einem sehr regulierten Umfeld und kämpfen damit, wie viel Fehlertoleranz nach außen möglich ist. Dass wir den Change neben unserem normalen Tagesgeschäft tatsächlich so reibungslos geschafft haben, halte ich für außergewöhnlich. Nicht zuletzt ist das auf die hohe Identifikation aller Mitarbeitenden mit dem Unternehmen und deren Engagement zurückzuführen.

Gab es einen Punkt, an dem du aufgeben wolltest? Und wenn ja, wie hast du diesen überwunden?

Für mich persönlich gab es tatsächlich ein, zwei Punkte, an denen ich mir überlegt habe, ob mein Einsatz weiterhin zielführend ist. Es waren große strategische Weggabelungen. Ein entscheidender Punkt war, als wir die kritische Masse an Pilot-Teams erreicht hatten. An diesem Punkt haben mehr Teams nach der neuen Arbeitsweise gearbeitet als nach der Alten, und der Change konnte nicht mehr als ein abgekapseltes Pilotprojekt betrachtet werden, sondern er hatte Auswirkungen auf die Arbeitsweise des gesamten Unternehmens. Das führte zu großen, internen Diskussionen, ob dieser Change tatsächlich notwendig war. An dieser Stelle standen wir somit vor der kritischen Entscheidung: Führen wir diese Änderungen nun durch oder nicht. Hier war es wichtig, am Ball zu bleiben und die Auswirkungen auf allen Ebenen der Organisation zu behandeln und in den operationellen Prozessen der gesamten Organisation die notwendigen Änderungen durchzuführen. Zudem war bei der RBI als ein traditionelles Unternehmen bisher nur wenig Raum für eine offene Fehlerkultur.

Es ist eine große Herausforderung, die Zusammenarbeit zwischen den Teammitgliedern und den Vorgesetzten so zu etablieren, dass sich die Teammitglieder trauen, die wirklichen Problemen anzugehen –  auch wenn es möglich ist, dass sie damit scheitern.

Diese alte Denkweise, die generell noch sehr stark in der westlichen Unternehmenswelt verankert ist, ist auch bei vielen RBI-Mitarbeitern noch sehr präsent. Die Fehlerkultur innerhalb eines Teams lässt sich relativ schnell ändern. Ein teamübergreifende Änderung ist jedoch ein viel weitreichender, übergreifender Prozess. Änderungen in der Unternehmenskultur dauern deutlich länger als die eigentliche Transformation. Das ist mir im Nachhinein erst richtig bewusst geworden und hat auch zu einem Punkt geführt, an dem ich aufgeben wollte. Hier ist es besonders wichtig, dass man diesem Prozess ausreichend Zeit gibt und dran bleibt.

Wie gehe ich mit meinen Tiefpunkten um? Ich habe von einem Senior Change Profi gelernt, dass sich in gewisser Form der Change-Prozess der Organisation in mir abbildet, dass ich ihn an mir intuitiv wahrnehmen kann. Daher, wenn ich Tiefpunkte habe, erlaube ich mir, diese ernst zu nehmen und mit relevanten Leuten darüber zu reflektieren. Fast immer ergibt sich in diesen Reflexionsprozessen der nächste richtige Schritt.

Menschen, die mit mir arbeiten wissen, dass ich mich authentisch und mit Leidenschaft dafür einsetze, dass wir uns zu einer holistischen agilen Organisation entwickeln, die Wirkung hat für Kunden und Mitarbeitende. Das ist mein persönlicher Purpose, der mich leitet. 

In welcher Position würdest du die RBI-Transformation heute starten?

Schwierige Frage. Ich habe gestartet von einer Position des internen Change Consultants, also Organisationsentwicklung, aber mit starker Einbettung im COO/CIO-Bereich und damit einer großen Nähe zu Execution und IT. Parallel habe ich uneingeschränkten Support vom CEO erhalten. Nach zwei Jahren habe ich mehr direkte Verantwortung übernommen, indem ich die gesamte IT Organisation der Bank gemeinsam mit einem Kollegen restrukturiert und selbst die Bereichsleitung für IT-Delivery übernommen habe. Ich denke beide Schritte waren gut und richtig. 

Rückblickend scheint es mir am wichtigsten, dass der richtige Change Leader ausgewählt wird und dass er das Vertrauen und die Unterstützung des Vorstandes genießt. Ich halte es für wesentlich, dass der Change Leader und sein Team die Organisation und die Menschen kennt, und einen Draht zu ihnen hat, um so das Neue einbringen zu können.

Ein weiterer Erfolgsfaktor ist, dass die Mitarbeiter selbst erkennen, dass eine agile Arbeitsweise sinnvoll ist und sie weiterbringt, anstatt sie von oben vorgegeben zu bekommen.

Change gelingt nur gemeinsam. Meiner Erfahrung nach ist es hilfreich, wenn der Change Leader in diesem Prozess die Richtung und Vision vorgibt, aber auch durchaus bescheiden und zurückhaltend agiert, coachend und unterstützend – wie agile Leadership eben funktionieren soll. Darauf haben wir immer sehr geachtet und ich denke, das hat uns zum Erfolg verholfen. 

Welche Vorteile sind heute, nach fast vier Jahren, schon sichtbar und messbar?

Ich halte mich an unsere drei Hauptelemente, die wir bei den Teams messen: 

Product Value. Hier haben wir ein Level erreicht, dass sich unsere Arbeit voll und ganz auf den Mehrwert für das Unternehmen fokussiert. Das halte ich für einen großen Erfolg und es war eine weitreichende Veränderung. Wir sind mit einigen digitalen Initiativen speziell im Corporate Umfeld schon deutlich spürbar bei unseren Kunden. Ich freue mich, dass die Teams laufend einen Mehrwert für unsere Kunden schaffen. Da müssen viele Aspekte funktionieren. Es ist großartig, dass wir so weit sind. 

IT Architecture/Engineering. Die Produkte, die unsere automatisierte Deployment Pipeline nutzen und Test Automatisierung einsetzen, sind in den letzten Jahren stetig und steil angestiegen. Cloud, API, Microservices und neue Technologien gehören inzwischen zu unserem ganz normalen Alltag. Wir sind noch nicht komplett durch, aber die Richtung stimmt. Vor allem haben wir die Skills, Tools und Erfahrung, um weiter konsequent voranzukommen. Die Fortschritte sind messbar und äußern sich direkt in unserer Deployment Frequency und letztendlich in unserer Innovationsfähigkeit. 

People /Process/Culture. Wir holen regelmäßig Feedback aus den agilen Teams ein, was zum einen der laufenden Weiterentwicklung dient, und zum anderen zeigt, dass wir für unsere Mitarbeitenden die Rahmenbedingungen für ein besseres Umfeld geschaffen haben und weiterhin schaffen. Sie schätzen die Zusammenarbeit, die Autonomie, die Ausrichtung in Richtung Innovation und vor allem, dass ihre Arbeit auf den unmittelbaren Mehrwert für das Unternehmen fokussiert wird. Spürbar ist auch weniger Bürokratie. Ich höre von vielen Mitarbeitenden, dass es bisher die einzige Veränderung ist, die eine nachhaltige positive Auswirkung für sie hat und dass sie sich wohl fühlen. Bei diversen IT-Konferenzen und Meetups kommt das Erstaunen, dass eine traditionelle Bank, wie wir, so weit ist und so arbeitet. Unsere IT Engineers sind gefragte Contributoren in den externen Communities. Das macht mich extrem stolz und zeigt mir, dass wir gut unterwegs sind. 

Auf Organisationsebene haben wir inzwischen auch die Steuerungsprozesse adaptiert und haben damit eine völlig neue Qualität der Transparenz und Messung von Arbeit, die einen direkt Mehrwert liefert, erreicht. 

Der Change ist deutlich bis zur Mitarbeiterebene spürbar und es entsteht eine große Bewegung, sich auf den Mehrwert für den Kunden und Continuous Innovation zu fokussieren. 

Welche Erfolgsfaktoren sind wesentlich?

Ich denke die Erfolgsfaktoren lassen sich mit folgenden Punkten gut zusammenfassen: 

• Sense of Urgency: Wir haben eine ansprechende sehr breite Vision genutzt, die nicht zu eng gefasst war.
• Senior Leadership Alignment und Backing zum why/what/how: Das Senior Management muss verstehen, warum, was und wie die Veränderung stattfinden soll und diese Veränderung unterstützen.
• Enthusiasmus, Leidenschaft für den Change: Der Change sollte von einem oder mehreren Change Leadern getragen werden, die glaubwürdige Vorbilder sein müssen, eine Liebe für die Menschen haben und bereit sind, sich der Verantwortung zu stellen, die richtigen Schritte im Change-Prozess anzugehen. 
• Kompetentes Agile Coach Team: Dieses sollte die Mitarbeitenden im Change begleiten und anleiten. Es stellt sicher, dass die richtigen Wertschöpfungsketten aufgesetzt werden, dass richtig agil gearbeitet wird und dass schrittweise an der Denkweise im Unternehmen gearbeitet wird. Hier war für uns eine Mischung aus internem Team und externer Kompetenz wesentlich für den Erfolg. Die externe Begleitung durch dich und das TechTalk Team trug wesentlich zu einer klaren Ausrichtung und konsequenten Umsetzung unseres Changes bei. 
• Neue Realität über agile Teams schaffen: So kann der Change greifbar und konkret gemacht werden. Hier sind natürlich kompetente Product Owner ganz wesentlich für den Erfolg, ebenso wie Scrum Master und ein Team, dass das „Wie“ und die Lieferung abdeckt – auf Augenhöhe.  
• Passendes IT-Umfeld schaffen: Eine IT-Solution-Architektur und Engineering, welche regelmäßige agile Delivery ermöglichen, ein IT-Umfeld, das Autonomie gibt und technologische Innovation fördert. 
• Kommunikation, Reflexion, Sicherheit geben: Viel Kultur- und Leadership-Arbeit leisten. 
• Klare Linie vorgeben: Am Ende sehr wohl klar machen, dass es „the way to go“ ist und sich nicht vom Weg abbringen lassen, auch wenn es zwischendurch schmerzhaft ist. 

Welches Fazit kannst du nach fast vier Jahren Change-Arbeit ziehen?

Abschließend kann ich sagen, dass es bisher eine aufregende Reise war, voller Höhen und Tiefen. Persönlich konnte ich noch nie so viel lernen und wachsen, wie in diesem Change-Prozess. Basierend auf dem Feedback von vielen Mitarbeitenden bin ich davon überzeugt, dass wir Großartiges geschafft haben und noch viel Veränderung vor uns liegt.

Ich möchte mich ganz besonders bei meiner engagierten Agile-Coaches-Gruppe bedanken, die diesen Change mit den Mitarbeitenden getragen haben und Großartiges geleistet haben. Vor allem verhält es sich bei ihrer Arbeit mit den Teams fast genauso wie bei Nanny McPhee: „Wenn ihr mich braucht, mich aber nicht wollt, dann muss ich bleiben. Wenn ihr mich wollt, mich aber nicht mehr braucht, dann muss ich gehen.“ Kein einfacher Job! Großer Respekt! Ein Danke an dieser Stelle geht auch für die bereits langjährige Zusammenarbeit an Techtalk/Christian Hassa und Team für den wichtigen externen Impuls zur „richtigen Agilität“. 

Ein großes Danke geht auch an mein phänomenales IT-Führungsteam und die vielen IT-Change-Ambassadors. Gemeinsam haben wir die hierarchisch und projektzentrierte IT Organisation in ein Netzwerk von agilen Teams weiterentwickelt, wo Engineering und Agile Enablement im Vordergrund steht – bemerkenswerter Job in kurzer Zeit. 

Und last but not least auch ein großes Danke an alle Mitarbeitenden, die offen waren, den Weg mit zu gehen – auch wenn der Beginn fast immer schwierig war. 

Ich bin stolz und glücklich, dass es inzwischen so viele Agile Ambassadors und Practitioners in der RBI gibt, die sich vehement für den Kundenmehrwert, Continuous Innovation und glückliche Mitarbeiter einsetzen! 

Möchten Sie mehr über Business Agility erfahren?