Agile Transformation zwischen Steintafel und Fokussierung auf Wirkung

Stossen Experten und Coaches auch die agile Transformation in Ihrem Unternehmen an und voran? Das ist auch unabdingbar, erfordert die Transformation praktisches Erfahrungswissen aus mehreren Erfolgen und Misserfolgen. Doch: Die Wahl der Coaches ist entscheidend dafür, ob es uns mit der Unterstützung der Coaches gelingt eine Schatztruhe zu öffnen oder ob die Transformation zum Ballast wird.

 

Gratulation, sicher haben Sie Ihre Gründe für die digitale Transformation und die Zielsetzung für das Transformationsprogramm bereits gefunden. Jetzt wird’s spannend und kritisch zugleich. Ihre Auswahl des richtigen Coaches ist mitentscheidend für den Erfolg oder Misserfolg der Transformation. Fast entscheidender als die Wahl des Frameworks. Warum? Alle Frameworks wie z.B. SAFe sind umfassende, generische Werke, die sich für alle Situationen verwenden / adaptieren lassen. Tausende Seiten sind die Dokumentationen stark und erklären alle Details. Und genau hier beginnt der springende Punkt, wenn es um die Wahl der Coaches geht. Als die zwei Extrempole der Ausprägung eines Coaches können in der Praxis zwei Grundorientierungen ausgemacht werden:

  • Der wirkungsorientierte, erfahrene Pragmatiker:
    Er schafft es Kraft seiner Erfahrung Vertrauen aufzubauen und fokussiert auf die wesentlichen Kernelemente zum Gelingen der Transformation. Bei ihm steht (wie im Grundsatz vieler agiler Frameworks) die Orientierung an der Wirkung (für den Endkunden sprich Unternehmenserfolg) im Vordergrund. Das Framework ist ihm Richtschnur und bildet die notwendige Basis. Es bleibt aber Mittel zum Zweck. Er schält in jeder Situation die wesentlichen Treiber heraus, sodass diese sich wie einzelne Puzzleteile zum Gesamtbild zusammenfügen. Dank seiner Erfahrung befähigt er die Teams in der Wahl des in ihrem Kontext optimalen Weg. Er stellt so fast unbemerkt sicher, dass das Framework nachhaltig Wirkung entfaltet. So begleitet er das Unternehmen gezielt auf seinem Weg des gesamtheitlichen, wirkungsorientierten Gelingens der Transformation.
  • Der Framework-Sachverständige:
    Er hat die ganzen Seiten Frameworkbeschreibung intus und kann auf jede Frage eine theoretische präzise Antwort geben. Er stellt sicher, dass sämtliche Artefakte des Frameworks korrekt im Unternehmenskontext dokumentiert werden. Er erklärt allen – meist mit einem lehrmeisterlichen Unterton – die Welt und erstickt jede konstruktiv kritische Frage mit einem Essai aus der Theorie. Schnell wird die Last seiner Steintafeln mit tausend und einem Framework-Gebot zum erdrückenden Ballast für die Teams, die mit ihm zusammenarbeiten müssen. Unmut macht sich breit und der Sinn der Transformation wird von den Mitarbeitenden nicht gesehen. Dies, weil sie sich in Administrivialitäten aufreiben, die als unnötig und wertfrei empfunden werden.

Klar, ist, dass nur wenige Coaches den Extrempol besetzen. Leider. Es gibt jedoch eindeutige Zeichen, bei denen es als Transformationsverantwortlicher zu Handeln gilt, wenn ein Coach im System ist, der mehr und mehr zur Belastung wird. Ein Beispiel zur Illustration: Sie führen in der Rolle des Solution Managers ihr erstes Pre-PI-Planning (nach SAFe) durch und der Business Owner fragt: «Habe ich das richtig verstanden, im PI-Planning sind alle Leute anwesend? Wie viele Leute sind im System?» Dass diese Frage zu diesem späten Zeitpunkt überhaupt kommt, ist Indiz genug, dass der Coach im Management kein Vertrauen ins Framework aufbauen konnte. Der Coach hat es offensichtlich nicht geschafft dem Business Owner im Vorfeld aufzuzeigen, welche positive Wirkung er aus diesen zwei Tagen intensivem Business-IT-Alignement hat und wieviel stärker am Outcome orientiert die Features dadurch werden. Schreitet der Coach bei dieser vernichtenden Frage zudem nicht ein und stellt sich Kraft seiner Erfahrung schützend vor Sie, ist der ultimative Moment gekommen sich von ihm zu trennen. Das kann passieren. Seien Sie aber ehrlich mit sich selbst und den Teams: Handeln Sie im Interesse aller!

 

Hintergrund zur agilen Transformation bei der SBB

Wurden 2013 durch die SBB-IT noch 4’000 Softwareänderungen an Systemen eingespielt, waren es 2019 bereits 80’000 – bei über 400 IT-Projekten pro Jahr. Das IT Operating Model blieb unverändert: Planung in den Fachabteilungen, Übergabe der Anforderungen an die IT, Umsetzung in Projekten, dann Übergabe an die Betriebsorganisation. Die vielen Abhängigkeiten waren kaum mehr zu koordinieren, die digitale Wertschöpfung war zerstückelt. Als Antwort wuchs bei der SBB seit einigen Jahren die agile Zusammenarbeitsform. Diese verändert das Team, aber nicht die Strukturen. Die reale Welt und das formale Organisationsmodell gilt es wieder zu vereinen. Das Transformationsprogramm «Gemeinsam Digital» ist nicht einfach eine IT-Reorganisation, es ist die Zusammenarbeit zwischen Business und IT und die Kultur, um die SBB in einem gemeinsamen Vorgehen zu digitalisieren.

Beitrag teilen

Matthias Meyer

Matthias Meyer ist Program Manager bei der SBB und bloggt aus dem Unterricht des CAS IT Management & Agile Transformation.

Alle Beiträge ansehen von Matthias Meyer →

Schreibe einen Kommentar