Agile Transformation im Logistikkonzern: Von traditionellen Strukturen zu stabilen IT Delivery-Rhythmen.
Agile Transformation im Logistikkonzern:
Von traditionellen Strukturen zu stabilen IT Delivery-Rhythmen.
Ein internationaler Logistikkonzern hat vor wenigen Jahren seine IT-Entwicklungseinheiten auf das SAFe-Rahmenwerk (Scaled Agile) umgestellt und agile Release Trains implementiert. In der Praxis arbeiteten viele involvierte Teams jedoch weiterhin in einer Mischform aus klassischem Wasserfall-Projektmanagement und neuen agilen Ansätzen, also einer hybriden Struktur, die oft zu operativen Unklarheiten und Verzögerungen führte.
Ein neu gebildetes IT-Team mit ca. 15 Entwickler:innen war entsprechend betroffen, da diese sehr wenig bis keine Vorerfahrung mit agilen Methoden hatten und die Entwicklungsprozesse relativ unstrukturiert waren. Auch die Abstimmung mit Stakeholdern verlief mitunter mühsam, da viele Manager und Führungskräfte nur unzureichend mit den neuen Entwicklungsabläufen nach SAFe vertraut waren.
Mein Ziel war daher klar: Ich wollte dem Team Scrum und SAFe nicht theoretisch und „nach Lehrbuch“ vermitteln, sondern es mit maßgeschneiderten, realistisch umsetzbaren Methoden dort unterstützen, wo es konkret steht. Parallel galt es, auch die externe Stakeholder-Landschaft in den Fachbereichen für agile Arbeitsweisen zu sensibilisieren, um die Zusammenarbeit langfristig effizienter und reibungsärmer zu gestalten. Beides musste praxisnah und iterativ erfolgen, da ich aufgrund der hohen Organisationskomplexität bezweifelte das eine rigide “Big Bang”-Einführung in die Agilität nachhaltig akzeptiert werden würde.
Mein Vorgehen: Iteratives und praxisnahes "Fine-Tuning" der Entwicklungsabläufe.
Ergebnisse
Stabile
Zielerreichung
Die Zielerreichung des Teams stieg von ca. 70% im ersten SAFe Planning Intervall auf Werte von bis zu 130% und zeigte mitunter eine klare Übererfüllung. Vor meinem Ausstieg aus dem Projekt hat sich die Zielerreichung stabil bei Werten um ca. 95% eingependelt.
Zuverlässigste Delivery
im Release Train
Bei der erstmaligen Erhebung der zum damaligen Zeitpunkt neuen KPI „Sprint-Zuverlässigkeit“ erreichte das Team direkt einen Wert von 90% und konnte sich damit sehr positiv im Release Train profilieren und die effektiven Planungsprozesse des Teams belegen.
Höhere Motivation & Zufriedenheit
In den Retrospektiven berichteten die Teammitglieder regelmäßig von einer besseren Arbeitsatmosphäre und einem klareren Verständnis der eigentlichen Business-Ziele. Durch smartere Planung und Priorisierung konnte auch die Überlastung und das Überstundenkonto zentraler Teammitglieder reduziert werden.
Nachhaltige
Strukturen
Sowohl das Team-Setup, als auch die Meeting-Formate und Scrum-Rituale, die eingeführt wurden, blieben auch nach meinem Ausstieg fester Bestandteil des Entwicklungsteams und stützen weiterhin die hohe Zielerreichung.
Ein internationaler Logistikkonzern hat vor wenigen Jahren seine IT-Entwicklungseinheiten auf das SAFe-Rahmenwerk (Scaled Agile) umgestellt und agile Release Trains implementiert. In der Praxis arbeiteten viele involvierte Teams jedoch weiterhin in einer Mischform aus klassischem Wasserfall-Projektmanagement und neuen agilen Ansätzen, also einer hybriden Struktur, die oft zu operativen Unklarheiten und Verzögerungen führte.
Ein neu gebildetes IT-Team mit ca. 15 Entwickler:innen war entsprechend betroffen, da diese sehr wenig bis keine Vorerfahrung mit agilen Methoden hatten und die Entwicklungsprozesse relativ unstrukturiert waren. Auch die Abstimmung mit Stakeholdern verlief mitunter mühsam, da viele Manager und Führungskräfte nur unzureichend mit den neuen Entwicklungsabläufen nach SAFe vertraut waren.
Mein Ziel war daher klar: Ich wollte dem Team Scrum und SAFe nicht theoretisch und „nach Lehrbuch“ vermitteln, sondern es mit maßgeschneiderten, realistisch umsetzbaren Methoden dort unterstützen, wo es konkret steht. Parallel galt es, auch die externe Stakeholder-Landschaft in den Fachbereichen für agile Arbeitsweisen zu sensibilisieren, um die Zusammenarbeit langfristig effizienter und reibungsärmer zu gestalten. Beides musste praxisnah und iterativ erfolgen, da ich aufgrund der hohen Organisationskomplexität bezweifelte das eine rigide “Big Bang”-Einführung in die Agilität nachhaltig akzeptiert werden würde.
Mein Vorgehen: Iteratives und praxisnahes "Fine-Tuning" der Entwicklungsabläufe.
Agile Einführung auf Augenhöhe
Vorträge allein haben wenig Impact. Deshalb konzipierte ich praxisnahe Workshops, die das SAFe-Rahmenwerk konkret auf die Arbeitsrealität des Entwicklungsteams und der Organisation übertrugen. Für Entwickler:innen gestaltete ich interaktive Simulationen (z. B. zu Story-Point-Schätzungen), für Stakeholder fokussierte Sessions mit bspw. Best Practices zur präzisen Formulierung und Kommunikation fachlicher Anforderungen im SAFe-Kontext.
Maßgeschneiderte Meeting-Formate, die zu den tatsächlichen Bedürfnissen passen
Anstatt starr am agilen “Lehrbuch” festzuhalten und Meeting-Formate wie das Daily Standup schlicht zu kopieren, habe ich Terminformate auf die Informationsbedürfnisse des Teams angepasst. So gab es bspw. einen organisch kombinierten und effizient moderierten Kombi-Termin für die Sprint-Reviews und -Plannings, wohingegen zusätzliche Zeit für ein eigenes „Weekly Learning“-Format, zur Diskussion neuer technischer Impulse und Ideen, eingeräumt wurde.
Lernunterlagen, die nichts dem Zufall überlassen
Neben dem Entwicklungsteam schulte ich auch weitere Stakeholder, wie bspw. Fachexpert:innen, die bisher überwiegend in traditionellen Projektmanagement-Rahmenwerken agierten. Anstatt mich auf bereits existierende Lernunterlagen der großen Anbieter oder konzernintern erstellte Foliensätze zu verlassen, die zwar umfangreich waren aber nicht konkret und klar genug auf die Realität der Zielgruppen eingingen, produzierte ich ein eigenes Lernvideo und diverse Präsentationen zu Scrum und SAFe. Der Aufwand lohnte sich, da die maßgeschneiderten Inhalte besser verstanden und angenommen wurden.
PO-Sparring & Leadership-Support
Durch die hohe Organisationskomplexität war eine kontinuierliche Abstimmung und gemeinsame Planung zwischen meiner Rolle als Team Coach und dem Product Owner essenziell. Daher führten wir wöchentliche bis tägliche „Sparring-Sessions“, in denen wir Themen systematisch nachhielten, die Vorgehensweise und Kommunikation ggü. verschiedenen Stakeholder-Gruppen schärften und team-interne Herausforderungen und Überlastungen durch klare Priorisierung abfederten.
Retrospektiven als Treiber
Die Retrospektiven waren keine Standardtermine, die ich jedes Mal wiederholte, sondern individuell gestaltete Workshops mit ansprechenden Visualisierungselementen und wechselnden inhaltlichen Schwerpunkten. So gelang es, über die Zeit hinweg das Terminformat als eine sehr positiv wahrgenommene gemeinsame Teamaktivität zu etablieren und immer wieder neue Entwicklungsimpulse im Team zu setzen und die Zusammenarbeit kontinuierlich zu verbessern.
Ergebnisse
Stabile Zielerreichung
Die Zielerreichung des Teams stieg von ca. 70% im ersten SAFe Planning Intervall auf Werte von bis zu 130% und zeigte mitunter eine klare Übererfüllung. Vor meinem Ausstieg aus dem Projekt hat sich die Zielerreichung stabil bei Werten um ca. 95% eingependelt.
Zuverlässigste Delivery
im Release Train
Bei der erstmaligen Erhebung der zum damaligen Zeitpunkt neuen KPI „Sprint-Zuverlässigkeit“ erreichte das Team direkt einen Wert von 90% und konnte sich damit sehr positiv im Release Train profilieren und die effektiven Planungsprozesse des Teams belegen.
Höhere Motivation
& Zufriedenheit
In den Retrospektiven berichteten die Teammitglieder regelmäßig von einer besseren Arbeitsatmosphäre und einem klareren Verständnis der eigentlichen Business-Ziele. Durch smartere Planung und Priorisierung konnte auch die Überlastung und das Überstundenkonto zentraler Teammitglieder reduziert werden.
Nachhaltige Strukturen
Sowohl das Team-Setup, als auch die Meeting-Formate und Scrum-Rituale, die eingeführt wurden, blieben auch nach meinem Ausstieg fester Bestandteil des Entwicklungsteams und stützen weiterhin die hohe Zielerreichung.
des Teams
Positives Feedback zum Projekt:
Bereit, Ihr Team voranzubringen?
Besprechen wir wo es hakt und wie ich dabei helfen kann.
Bereit, Ihr Team voranzubringen?
Besprechen wir wo es hakt und wie ich dabei helfen kann.
