Es ist immer spannend zu beobachten, wenn ein weltbekannter Konzern neue Wege geht, traditionelle Organisationsmuster überwindet und ernsthaft anstrebt, sich dynamikrobust aufzustellen. Erfahrungswerte aus solchen Transitionsprojekten sind meist sehr erhellend und inspirierend auch für andere Enterprise-Unternehmen, die ebenfalls in Agile- Transformationen stecken.

Für mein neues Buch We run on Agile habe ich mich mit Marcus Raitner unterhalten, der als Agile Transformation Agent bei der BMW Group IT arbeitet und dort die Agile-Skalierung des Konzerns vorantreibt. In einem längeren Gespräch hat er mir ein paar interessante Einblicke und Einschätzungen gegeben; die wichtigsten möchte ich hier mal teilen. (Das gesamte Interview können Sie in unserer Infothek nachlesen.)

Übrigens wird Marcus auch auf unserer Tools4AgileTeams-Konferenz am 3. und 4. Dezember über seine Erfahrungen mit Scaled Agile bei BMW berichten.

LeSS: Skalierung im Kleinen starten

Wie in vielen großen Unternehmen ist auch bei BMW mit unterschiedlichen Konzepten experimentiert worden, um den besten Weg für die Skalierung agiler Methoden zu finden. Marcus ist indes ein bekennender Anhänger des Frameworks Large Scale Scrum, besser bekannt unter der Abkürzung LeSS. Auf die Frage, welchen entscheidenden Vorteil LeSS in einem großen Konzern habe, hat Marcus eine klare Antwort:

"Es ist so, dass nur ganz wenig Struktur vorgegeben wird. Es geht im Wesentlichen darum, Scrum in größerem Maßstab anzuwenden: eigentlich die typische Scrum-Lehre, nur größer, mit möglichst wenig festgelegten Rollen und möglichst wenig Framework – LeSS steht für so wenig Framework wie möglich."

Das Scaled Agile Framework SAFe sieht Marcus dagegen sehr kritisch:

"SAFe ist im Gegensatz dazu so viel Framework wie möglich."

Er erkennt Parallelen zum traditionellen Wasserfallmodell: Die Gefahr sei, dass die Rollen bloß umbenannt würden, jeder fände seine Wasserfall-Rolle als SAFe-Rolle wieder – und letztlich ginge alles so weiter wie zuvor. Marcus vertritt einen anderen Ansatz:

"Wenn du in Richtung Agilität einen großen Sprung machen willst, dann musst du mit LeSS anfangen. Damit schaffst du ein verstörendes Moment, und genau das wollte ich. [...] So bringst du die Leute zum Nachdenken, wie man vielleicht wenigstens doch ein Stückchen in die neue Richtung gehen könnte."

Überzeugend an LeSS sei, dass Organisationen nach diesem Konzept zunächst klein beginnen und aus diesem Kleinen ins Große kommen. Es ginge erstmal darum, Verkrustungen und Abhängigkeiten aufzulösen:

"Das ist auch so ein Vorwurf von SAFe: Du wirst relativ schnell relativ groß und du verwaltest nur noch die Abhängigkeiten. Ich will die Abhängigkeiten aber loswerden. Ich will also Architekturen wählen, die die Abhängigkeiten, die Systeme entkoppeln."

Wann kann SAFe funktionieren und wann sind andere Konzepte eher zielführend?

SAFe könne durchaus funktionieren, wenn eine Organisation einfach ein sehr großes Software-Produkt entwickelt, meint Marcus, aber kaum in einem Unternehmen, das dutzende unterschiedliche IT-Systeme nun einfach als "ein Produkt" bezeichnet:

"Den Begriff des Feature-Teams in dem Sinne, dass jeder im Team sich im ganzen Produkt einbringen kann, finde ich in der Theorie zwar ein tolles Ziel – aber wenn ich mir unsere Produkte anschaue, dann ist das einfach nicht der Fall. [...] Wir haben zwar durchaus ähnliche Fachprozesse, sonst hätten wir die Systeme nicht gebündelt, aber technisch und zum Teil auch fachlich kann nicht jeder jeden Detailprozess in der Tiefe kennen. Deswegen haut dieses Feature-Team bei uns so nicht hin."

Ebenso wie SAFe brauche jedoch auch LeSS die Unterstützung des Managements. Diese Top-down-Strategie müsse allerdings umfassen, dass man klein anfängt und dann allmählich ins Große vorstößt. Ansonsten lauere eine große Gefahr:

"Wenn du das zu schnell in zu großem Maßstab machst, dann hast du Probleme, dann wird es einfach zu schnell industrialisiert. Dann industrialisierst du Scrum zu Tode."

Skalierungskonzepte, die zu tatsächlichen Veränderungen führen

Konkrete Vorgaben für die Agile-Skalierung hat es im Konzern indes nicht gegeben. Der Ausgangspunkt des Transitionsprozesses bei BMW sei lediglich die agile Produktentwicklung gewesen: Verschiedene IT-Produkte sollten zu einem Produkt gebündelt werden. Nach welchem Modell die Verantwortlichen dabei vorgehen, ob Scrum oder Kanban zum Einsatz kämen, ob ein eigenes Scaled-Agile-Framework gebraucht würde (und welches), sei jedoch offen geblieben.

Bei BMW sei es tatsächlich zu einigen nachdrücklichen Veränderungen gekommen, wie Marcus Raitner zu erzählen weiß. Er nennt das Beispiel einer Abteilung, die statt zwei Releases pro Jahr nun 50 Deployments am Tag ausliefert:

"Jetzt müssen sich die Leute was überlegen. Würde der Chef statt zwei Releases jetzt vier Releases machen, kannst du das immer noch manuell hinbekommen, kannst es also immer noch irgendwie so wie vorher machen. Aber wenn er sagt, er will 50 Mal am Tag deployen, dann musst du das halt automatisieren. [...] Dann hast du keine Wahl mehr."

Die IT als Impulsgeberin

Marcus sieht seinen Unternehmensbereich – der IT – auch in einer gewissen Vorreiterrolle mit Einfluss im gesamten Konzern, die andere Abteilungen anrege, sich in eine moderne Organisationsrichtung zu orientieren:

"Die lassen sich natürlich von dem, was wir da angezündet haben, inspirieren. Ich war auch schon im Marketing und vielen anderen Stellen eingeladen, um zu dem Thema 'Wie können wir unsere Arbeit agiler gestalten?' etwas zu sagen. Man kann sagen, es strahlt von der IT ausgehend auf alle Prozesse aus, weil natürlich alle Prozesse von der IT unterstützt werden. Sie bildet sozusagen eine Schnittstelle, und deswegen verbreitet sich auch das Gedankengut weiter."

Aber bei der Strategie, die ganze IT eines Konzerns agil aufzustellen (und von dort aus weiter zu skalieren), ergeben sich doch sicher so einige Herausforderungen. Das ist tatsächlich so, wie Marcus resümiert. Insbesondere der Ergebnisdruck sei nicht zu leugnen:

"So ein Top-down-Commitment vom CIO: 'Wir machen alles agil, wir machen überall agile Produktentwicklung' – das ist erst einmal super, es gibt ein Riesenschwung, führt aber automatisch auch zu einer gewissen Erwartungshaltung an die Organisation. Das heißt, du musst das auch relativ schnell umsetzen."

Diese Erwartung stünde gewissermaßen der LeSS-Devise entgegen, klein anzufangen und viel zu lernen. Und wenn die Skalierung recht schnell und in einem relativ großen Rahmen erfolgt, gäbe es das Risiko, dass sie in neuen Prozessen, Regeln und Vorgaben münde, die zwar gut gemeint seien, doch bei einer organischen Skalierung letztlich wohl nicht entstanden wären. Aber:

"Das hätte dann zehn oder 20 Jahre gedauert und nicht ein Jahr. Dennoch: Gegen diese Ungeduld würde ich heute viel stärker ankämpfen, wenn wir diesen Prozess noch einmal initial durchlaufen würden."

An dieser Stelle noch einmal vielen Dank an Marcus Raitner für den spannenden Austausch und weiterhin einen erfolgreichen Weg mit BMW! Und wie oben schon erwähnt: In unserer Infothek finden Sie das Gespräch im Wortlaut.

SAFe mit Atlassian-Tools: Jetzt Agile Hive kennenlernen!

Wollen Sie mehr über die Software-gestützte Umsetzung von SAFe mit Agile Hive wissen? Gerne diskutieren mit Ihnen über Ihre Anforderungen an ein unternehmensweites agiles Produktentwicklungs- und Produktmanagement und demonstrieren Ihnen die Funktionen der Lösung in einer persönlichen Session. Melden Sie sich bei uns! In unserer Infothek finden Sie Details zu unseren Agile-Hive-Einführungsprojekten.

Weiterführende Infos

Scaled Agile: Was ist SAFe? Und warum mit Jira und Agile Hive?
Scaled Agile: SAFe in Jira versus SAFe in Jira mit Agile Hive
Einführungsprojekte zu SAFe und Agile Hive
SAFe setzt auf Alignment – Mit Agile Hive zu Transparenz im Daily Business