SAFe bei Atotech: Scaled Agile (Transformation in Specialty Chemicals)
Atotech ist eine Marke für Spezialchemietechnologie: Chemie, Equipment, Software und Services für Elektronik, Kommunikation, Computing, Automotive und Haushaltsgeräte.

Atotech ist eine führende Marke für Spezialchemietechnologie und liefert Chemie, Equipment, Software und Services für diverse Endmärkte. Dazu gehören Smartphones und andere Consumer Electronics, Kommunikationsinfrastruktur und der Computing-Sektor. Darüber hinaus bieten sie eine Reihe industrieller und Consumer-Anwendungen für Autos, schwere Maschinen und Haushaltsgeräte.
Hier ist die Geschichte einer SAFe-Transformation, erzählt von ihren zentralen Teilnehmenden – Artem Milevsky (Agile Coach), Maxim Lapo (Head of Engineering) und Nikolay Kuchuk (Head of Product).
Wir stehen in unserer Branche jeden Tag vor einer großen Zahl von Herausforderungen in dieser sich rasch wandelnden Welt. Wir müssen neue organisatorische „Fähigkeiten“ gewinnen und entwickeln, um relevant zu bleiben: Anpassungsfähigkeit, Geschwindigkeit der Solution Delivery und Kundenfokus.
Es gab einen Wendepunkt, den wir vor drei Jahren erreichten, als wir erkannten, dass wir Agile brauchten – ein Mindset, das unsere zentralen Schmerzpunkte adressierte: Entscheidungsfindung, Team-Alignment, Kollaboration und Outcome-Delivery.
Unsere Business-Agility-Transformation begann in Q3 2019, als unsere Digital-Solutions-Funktion, IT und andere Teams dieses Agile-Mindset annahmen.
Jeden Tag standen unsere Ingenieurinnen, Ingenieure und das Management vor Problemen in Arbeitskultur und Prozessen, die uns langsam, unvorhersehbar und nicht kundenorientiert machten.

Die schmerzhaftesten, auf die wir stießen, waren:
- Regeln und Verfahren hatten Vorrang vor schnellen Entscheidungen und einem kurzen Lieferzyklus für Geschäftswert.
- Taktik dominierte über Strategie: die IT-Seite ging Wertschöpfung immer reaktiv an. Statt Lösungen für bekannte und klare strategische Initiativen proaktiv vorzuschlagen, warteten unsere Engineering-Teams auf detaillierte Business-Requirement-Dokumentation, bevor sie etwas taten.
- Trotz zahlreicher Cross-Team-Abhängigkeiten arbeiteten Teams lieber an ihren Aufgaben, als wären sie völlig isoliert vom Rest des Unternehmens. Das bedeutete: wir hatten ein Problem, gemeinsame Ziele zu treffen.
- Es gab überhaupt keine definierten Feedbackschleifen von Kunden oder Stakeholdern.
- Fehler kamen teuer, weil die Qualität unserer Solutions unvorhersehbar war.
- Stakeholder wurden als „böse Bosse“ und Ingenieurinnen und Ingenieure als „unterdrückte Arbeiter“ gesehen, statt einer gesunden kooperativen Beziehung. Deshalb verschwendeten Teams Zeit mit Vorwürfen und Ausreden, statt gemeinsam nach den bestmöglichen Lösungen zu suchen.
Drei Jahre lang versuchten wir, das zu beheben, indem wir das Scrum-Framework und die Kanban-Methode in kleinen isolierten Engineering-Team-Umgebungen anwandten und experimentierten. Das war unser erster Fehlschlag! Gemeinsam mit unserem Leadership-Team betrachteten wir unsere Ergebnisse und erkannten, dass wir die Perspektive auf den gesamten Transformationsprozess ändern mussten.

Also entschieden wir uns, SAFe zu gehen! Mit seinen Transformationsprinzipien und Core Values fest im Herzen begann das neue Kapitel unserer Organisation!
Auf unserer Reise zu SAFe haben wir bisher:
● mehr als 70+ Personen in unserer Digital Solutions Division geschult.
● zwei Agile Release Trains aus vier Value Streams identifiziert, besetzt und gestartet.
● shared UX- und Post-Dokumentations-Teams eingeführt.
● ein PI-Planning-Event als Herzschlag unserer neuen kundenwertorientierten Struktur implementiert.
● von Silos zu teambasierten Netzwerken in unserer Organisationsstruktur gewechselt.
● neue Rollen definiert und das Design von Team und Agile Release Train gechartert.
● relative Estimation durch das ganze Team eingeführt.
● Centers of Excellence betrieben: Quality Assurance, Agile, DevOps, Automation Engineering und Product Engineering.
● von detaillierten Dokumenten zu minimalen Entwürfen und Stories als Requirements gewechselt.

Unsere Ergebnisse:
● Stakeholder, die am SDLC beteiligt sind, schätzen die Chance, früh im Prozess Feedback zu geben – statt ganz am Ende, wenn Feedback am wenigsten wertvoll ist.
● Teams haben 90 % Commitment-Erfüllung je PI erreicht.
● Wir haben jetzt eine Kultur, dedizierte Zeit und Mühe dem Erkunden neuer Praktiken oder dem Prüfen der eigenen Hypothesen der Teams zu widmen.
● Klare und messbare (und regelmäßig gemessene) Outcomes aus jedem Value Stream wurden zu einem nützlichen Werkzeug im Stakeholder-Expectation-Management.
● Entscheidungen basieren auf den Prozessmetriken der Teams und ARTs (Flow, Agile-Reife und Qualität).
● Die Einführung von Inspect-and-Adapt-Zyklen machte komplexe und systematische Themen sichtbar.
● Transparenz und Alignment stiegen auf jeder Ebene drastisch. Alle Abhängigkeiten, Meilensteine und Objectives werden über das Program Board kommuniziert und sind für alle Parteien verfügbar – einschließlich IT, Product Engineering, Business Development, Marketing und Contact Center.
● Über das System-Demo-Event können Stakeholder und Lieferanten die Produktvision und Entwicklungspläne direkt beeinflussen, indem sie rechtzeitiges und konstruktives Feedback geben.
● Schließlich ist das Mitarbeiterengagement deutlich gestiegen, und wir sehen 70 % Wachstum in der Produktkollaboration. Wir haben Teammitgliedern den Wert der Features verständlich gemacht, an denen sie arbeiteten. Durch regelmäßige Synchronisation, klaren Business-Kontext und transparente Ziele auf jeder Ebene haben wir die kreative Kraft unserer Teams freigesetzt.
Und das ist nicht das Ende unserer Reise! Wir werden weiterhin auf diesen Grundlagen, Core Values und Prinzipien fokussieren, die Teil der Kultur und Normen unserer Division geworden sind. Wir verbreiten das aktiv in unserer gesamten Organisation!