Voller Euphorie startete unser Transformationsteam bei einem großen Retail-Unternehmen mit knapp 100.000 Angestellten die Initiative zur Erstellung eines eigenen Frameworks für agile Arbeitsweisen. Mit einem Playbook, welches alle Regeln des Frameworks ausführlich beschreibt, wollten wir erreichen, dass nicht mehr nur einzelne Teams mit agilen Methoden experimentieren. Vielmehr wollten wir agiles Arbeiten im Vorgehensstandard der Organisation einführen, um digitale Lösungen besser, schneller, sicherer und mit zufriedeneren Mitarbeitenden zu entwickeln. Doch nur ein paar Monate später mussten wir uns eingestehen: Das Playbook ist gescheitert, und wir haben über agiles Arbeiten mehr theoretisch diskutiert, als dass es tatsächlich stattgefunden hat.

Wir stellten daraufhin unser eigenes Framework ein und wechselten zum Standard-Framework SAFe. Knapp ein Jahr später arbeiten über 1.000 Mitarbeitende aus den Abteilungen Business und IT skaliert agil, und wir haben eine lean-agile Reise als kontinuierliche Kulturentwicklung angestoßen. Doch auch hier zeigen sich neue Herausforderungen!

In diesem Beitrag rolle ich die Geschichte eines gescheiterten eigenen Frameworks auf. Ich habe sie in meiner Rolle als Head Lean Portfolio & Agile Transformation mitverantwortet. Ich zeige die Gründe für das Scheitern des eigenen agilen Frameworks und unsere Erkenntnisse daraus auf. Anschließend analysiere ich die Erfolgsfaktoren für die agile Transformation mithilfe eines Standard-Frameworks – und erläutere welche neuen Herausforderungen daraus entstanden.

Erste Schritte zur Agilität

2018 startete die zentrale IT-Abteilung der Unternehmensgruppe mit ersten Maßnahmen zur Steigerung der Agilität. So wurden im Rahmen einer großen IT-Transformation alle IT-Mitarbeitenden in Agile Basics geschult. Diverse Projektleitungen, Product Owner:innen oder Scrum Master:innen erhielten die Möglichkeit, an weiteren (Scrum-)Zertifikatsschulungen teilzunehmen.

Nach dieser flächendeckenden Schulungsinitiative wollten wir das agile Arbeiten auch im Alltag etablieren. Unterstützt von externen Agile Coaches wurden erste Projekte mit Scrum umgesetzt – zuerst naheliegende Vorhaben wie die Weiterentwicklung der Website, zunehmend aber auch Projekte in einem Umfeld, in dem eher nach traditionellen Projektmanagement-Methoden gearbeitet wird, wie beispielsweise die Einführung eines neuen Kassensystems oder Weiterentwicklungen im SAP-Umfeld.

Entstehen und Scheitern des eigenen Playbooks

Um die Agilität der gesamten Organisation zu steigern, sollte der nächste Schritt ein Wechsel von der Projekt- zur Produktorganisation sein – also der Aufbau von festen Teams, die Ende-zu-Ende für ein Produkt verantwortlich sind. Das verantwortliche Transformationsteam, bestehend aus zwei agilen Coaches und den betreffenden Führungskräften, stellte hierfür Pilotteams zusammen. Diese sollten sehr nah an diesem "Target Operating Model" organisiert sein. Darunter fielen vor allem interdisziplinäre Teams, welche bereits agile Methoden wie Scrum nutzten und an Produkten ohne festgelegtes Enddatum arbeiteten.

Da zu diesem Zeitpunkt nur sehr wenige Teams in der Organisation diesen Kriterien entsprachen, wurde mit allen Team- und Abteilungsverantwortlichen gesprochen, die potenziell Interesse daran haben könnten, an einem solchen Piloten teilzunehmen.

So wurden acht Pilotteams, bestehend auf ca. 6-11 Mitarbeitenden aus den Abteilungen "Digital Marketing" (Business) und "Digital Technologies" (IT) gefunden, welche im Umfeld des "digitalen Business" bereits mit Scrum arbeiteten und dabei eine sehr enge Zusammenarbeit zwischen IT und Business vorwiesen.

Grundprinzip des agilen Frameworks