Weswegen es für ein mittelständisches Unternehmen Sinn ergeben kann, für mehrere Millionen Euro ein organisationales Fertigkonzept einzukaufen
Auf der Ebene eines Teams mit klar umrissenen Aufgaben und weniger als einem Dutzend Mitarbeiter lassen sich agile Methoden einfach einführen. Wenn ein Team weitgehend autonom an der Entwicklung eines Produkts arbeiten kann, ist es vergleichsweise einfach, diese über die Position eines „Produkt Owners“ an Bedürfnissen von Kunden auszurichten, den Entwicklungsprozess über ein- oder zweiwöchige Sprints zu organisieren und über tägliche „Stand-ups“ kurzfristige Abstimmungen vorzunehmen. Schwierig wird es immer, wenn eine Entwicklungsaufgabe eine Vielzahl von Teams erfordert, die miteinander koordiniert werden müssen.
Beratungsunternehmen haben deswegen Konzepte entwickelt, die es ermöglichen sollen, das auf der Ebene von einzelnen Teams erfolgreiche agile Konzept auf die ganze Organisation zu übertragen. Skalierung agiler Arbeitsformen ist das Zauberwort, das dafür verwendet wird. Das Versprechen der Beratungsunternehmen an ihre potenziellen Kunden ist simpel. Wir haben für Euch ein Werkzeugkasten, in dem sich nicht nur bewährte, unmittelbar anwendbare Werkzeuge befinden, sondern diese Werkzeuge auch alle präzise aufeinander abgestimmt sind.
Bei diesen Konzepten wird alles zusammengemischt, was gerade im Managementdiskurs „en vogue“ ist. Es werden Methoden wie Scrums, Kanbans, Backlogs, Key Performance Indicators, Portfolios und Value Streams verwendet, angereichert um Konzepte wie Customer Centricity, Design Thinking, Continuous Exploration und Iterations. Beigemischt werden angesagte Rollenbeschreibungen wie Product Owner, Business Owner, Epic Owner, Scrum Manager, Product Manager, System Architect, Enterprise Architects und Team Coach. Natürlich dürfen auch die üblichen Schlagworte wie Lean-Agile Mindset, Core Values, Visions, Objectives and Key Results, Artificial Intelligence, Shared Service, Community of Practice nicht fehlen. Die visuelle Darstellung dieser Konzepte ähnelt den beliebten Wimmelbildern, in denen man aufgrund der Unübersichtlichkeit immer wieder etwas Neues entdecken kann.
Ein französisches Maschinenbauunternehmen mit zehntausend Mitarbeitern leidet darunter, dass die einzelnen Entwicklungsprozesse immer komplexer werden und nur noch schwer aufeinander abgestimmt werden können. Sie überlegen deswegen eines der standardisierten Agilitätsmodelle einzuführen. Die zuständigen Bereichsleiter entscheiden sich vor der Einführung dieser Methode, durch eine kurze Analyse herausarbeiten zu lassen, ob die aufwendige und kostspielige Einführung eines solchen Modells Sinn ergibt.
Bei dieser Analyse kommt heraus, dass für die Beschleunigung der Produktentwicklung lediglich zwei Elemente aus dem skalierten agilen Framework relevant sind. Der eine zentrale Hebel ist, dass die einzelnen Produktentwicklungen durch autonome Produktentwicklungseinheiten vorangetrieben werden sollen. Dies soll zu einer Beschleunigung führen, weil die Produktentwickler nicht mehr an mehreren Entwicklungsprojekten gleichzeitig arbeiten müssen, sondern sich in einem „Agile Release Train“ auf ein einzelnes Entwicklungsprojekt konzentrieren können. Der zweite Hebel ist die Überlegung, dass die sieben zentralen Entwicklungsprojekte des Unternehmens sich alle vier Wochen an einem Tag ihre jeweiligen Entwicklungsfortschritte präsentieren und ihre anstehenden Entwicklungen synchronisieren.
Weil die anderen hundertzwölf Ansatzpunkte des agilen Rahmenwerks für die Erhöhung der Entwicklungsgeschwindigkeit irrelevant sind, empfehlen die Organisationsanalytiker das agile Rahmenwerk nicht als Ganzes einzuführen, sondern sich auf die Einführung der autonomen Produktentwicklungsteams und die zeitliche Taktung der jeweiligen Entwicklungsschritte der Teams zu konzentrieren. Das Argument ist, dass die konsequente Arbeit an den beiden zentralen Hebeln für einen Erfolg bei der Produktentwicklung sorgt, da sonst die Einführung des ganzen umfassenden Rahmenwerks aus dem Fokus geraten würde. Es besteht die Sorge, dass ohne die Fokussierung auf die beiden Hebel, die Organisation nicht die Kraft haben wird, alle Mitarbeiter nur noch exklusiv einem Entwicklungsvorhaben zuzuordnen und die verschiedenen Entwicklungsvorhaben in den Rhythmus von vierwöchigen Sprints zu bringen.
Die Geschäftsführung lehnt diesen Vorschlag der Organisationsanalytiker ab und beschließt für mehrere Millionen das gesamte skalierte agile Rahmenwerk einzuführen. Das Argument ist, dass im Unternehmen zu viele unterschiedliche Auffassungen, zu viele verschiedene Prozessverständnisse, zu viele Insellösungen existierten und es deswegen ein zentral vorgegebenes Rahmenwerk bräuchte. Dieser Gedanke widerspricht auf den ersten Blick der Idee der Agilität, weil im Veränderungsprozess nicht inkrementell gearbeitet wird, sondern die neue Struktur der Entwicklungsorganisation mit einem langfristigen Masterplan eingeführt wird. Die Entscheidung des Managements hat aber eine eigene Rationalität. Das Unternehmen ist im Entwicklungsprozess so zerfranst, die mikropolitischen Verwerfungen so ausgeprägt, dass die Organisation zu einer pragmatischen Arbeit an den zwei Strukturhebeln gar nicht in der Lage ist. Es scheint ein skaliertes Rahmenwerk zu brauchen, das sich als Industriestandard verkaufen lässt, um die Einheiten durch eine „Paketlösung“ in eine einheitliche Struktur zu zwingen und Widerstände mit dem Argument auf eine vermeintliche Best Practice auszuhebeln.
Aus „Managementmoden nutzen. Eine sehr kurze Einführung“ (Springer VS 14,90). Die Publikation der Auszüge soll die Auseinandersetzung mit den Überlegungen zu Managementmoden ermöglichen.
Schreibe einen Kommentar