In dem letzten Jahr hatte ich das Privileg, ein herausragendes Team bei ihrer agilen Transformation nach dem SAFe-Framework zu begleiten. Heute bin ich besonders stolz, denn mein Kunde hat nicht nur die Transformation erfolgreich gemeistert, sondern auch eine beeindruckende Erfolgsstory im eigenen Unternehmen veröffentlicht. Und das Beste: Ich darf diese Erfolgsgeschichte nun mit meinem Netzwerk teilen!
In diesem exklusiven Einblick erfährst du, wie der Product-Manager und sein Team die Herausforderungen der Transformation angegangen sind und welche Strategien sie entwickelt haben, um nachhaltig erfolgreich zu bleiben. Die Zusammenarbeit war geprägt von Vertrauen und Verschwiegenheit, weshalb wir hier auf Klarnamen verzichten, um die Privatsphäre aller Beteiligten zu schützen.
Lars, Product-Manager:
Die agile Arbeitsweise an sich ist nichts Neues. Sie verspricht größere Flexibilität, eine effizientere Zusammenarbeit sowie schnellere und vor allem bessere Ergebnisse. Es gibt mittlerweile ausgefeilte Frameworks, wie das SAFe (Scaled Agile Framework), und ich dachte anfangs tatsächlich, es kommt jemand, der einem sagt, wie es geht. Und dann muss man das nur kopieren. Die Erkenntnis, dass es so einfach nicht ist und wir unsere Vorgehensweise individuell entwickeln müssen, hat uns letztes Jahr entscheidend vorangebracht.
Zu Beginn unserer agilen Reise vor einigen Jahren mit einem kleinen, einzelnen Scrum-Team haben wir schnell gemerkt, dass ein einfaches Copy & Paste bestehender Frameworks nicht möglich ist. Auch intern konnten wir nicht auf Bestehendes zurückgreifen. Wir bewegen uns in einem Setting, in dem die agilen Teams eingebettet sind in klassische Wasserfall-Prozesse, mit vorgegebenen sequenziellen Meilensteinen. Die sinnvolle Verbindung dieser beiden Vorgehensweisen und eine effiziente übergreifende Zusammenarbeit ist für alle herausfordernd, weshalb wir uns entschieden haben, externe Unterstützung einzuholen.
Zusammen mit unserem internen Lean & Agile Experten haben wir nach einer Marktanalyse die Berater Dr. Michael Gerstle (MEWS Partners GmbH) und Paul Weißhaar (Weißhaar Consulting GmbH) hinzugezogen. Beide haben nicht nur Erfahrung bei der Einführung und Optimierung agiler Arbeitsweisen, sondern kennen auch Airbus gut.
Nach dem Maturity Assessment, der Bewertung des Reifegrads, der agilen Bausteine wurden die wichtigsten Elemente zur Weiterentwicklung priorisiert. Diese Priorisierung erfolgte hauptsächlich durch die Teams selbst, was ihre Motivation bei der Umsetzung der Änderungen stärkte.
Einige Rollen im agilen Framework waren anfangs unbesetzt, so dass Kollegen mehrere Rollen gleichzeitig ausüben mussten. Die Berater unterstützten ihre Coachees im Arbeitsalltag und übernahmen bei Bedarf Moderations-Sequenzen – ein effektives on-the-job-Training. Diese Unterstützung war besonders hilfreich für mich, da ich zu Beginn drei Rollen gleichzeitig innehatte: die des Product Managers, Scrum Masters und Release Train Engineers (RTE). Mittlerweile hat eine neue Kollegin die Rolle des RTE übernommen, was mich weiter entlastet.
Auch für meine Scrum Master-Kollegin Susanne war es ein wichtiger Schritt, sich noch einmal innerhalb des Teams Gedanken darüber zu machen, wer im Team wofür zuständig ist, um das Rollenverständnis und deren Abgrenzungen zu schärfen. Was machen die Rollen: Scrum Master, Product Owner oder Entwickler, beziehungsweise Developer? Wie ist die Verbindung zum klassischen Projektmanagement? Im Groben: Für alle, die sich noch nie mit der agilen Arbeitsweise befasst haben: Der Product Owner sagt, was für Ziele wir erreichen müssen und bis wann. Der Entwickler sagt, wie wir es umsetzen müssen. „Jeder kann sich auf sein Spezialgebiet konzentrieren: Die Entwickler bekommen mehr Verantwortung, aber auch mehr Gestaltungsspielraum“, fasst sie den Vorteil durch die klare Abgrenzung zusammen. Als Scrum Master begleitet sie das Team auf der Reise, das agile Framework richtig und zielgerichtet einzusetzen. Gleichzeitig steht sie den Teammitgliedern als Coach zur Verfügung, um Komplexität und Hintergründe zu verstehen und sie bei der kontinuierlichen Verbesserung ihrer Arbeit zu unterstützen.
Am Anfang hatte ich konkrete Vorstellung und habe sie kommuniziert. Jetzt versuche ich, statt Vorgaben zu machen, vor allem zu verstehen und durch gezielte Fragen das Team eigenen Lösungen erarbeiten zu lassen. Dadurch werden die Veränderungen angenommen und auch gelebt.
– Susanne (Scrum Master)
Dass ein Scrum Master nicht in den technischen Prozessen steckt, sieht der Product Owner Robert noch kritisch. Er schätzt jedoch die Rolle besonders als Sparringspartnerschaft, um die Zusammenarbeit im Team aus menschlicher Perspektive zu betrachten, zu verbessern und effizienter zu gestalten.
Die Berater agierten nicht nur als Coaches, sondern als Katalysatoren für ein effektives Training „on the Job“. Diese Methode ermöglicht Teams, schnell in neue Rollen hineinzuwachsen und die agile Arbeitsweise selbstbewusst zu meistern.
Einige hat es überrascht, wie stark Führungskompetenzen in der agilen Arbeitsweise gefragt sind, obwohl es keine disziplinarische Führung in diesem Sinne gibt. Aber gerade bei der sogenannten lateralen Führung ohne Weisungsbefugnis sind sie entscheidend für die erfolgreiche Zusammenarbeit und waren Teil des Coachings. Elin in ihrer Doppelrolle als Scrum Master und Developer hat vor allem die Einblicke in verschiedene Kommunikationstypen weitergebracht:
Früher dachte ich, ich sollte alle so behandeln, wie ich selbst behandelt werden möchte. Doch nicht jeder hat die gleichen Bedürfnisse in der Kommunikation. Jeder kommuniziert anders. Das Verständnis der verschiedenen Typen hat mir sehr geholfen. Jetzt verstehe ich besser, wie ich auf Teammitglieder zugehen kann, was sie motiviert, und welche Ansätze funktionieren. Außerdem wurde mir klar, wie umfassend die Rolle des Scrum Masters ist. Diese Einblicke halfen mir, besser zu entscheiden, ob ich langfristig in dieser Rolle arbeiten möchte.
– Elin (Scrum Master & Developer)
Die agile Transformation hat gezeigt, dass Führung nicht von disziplinarischer Autorität abhängt, sondern von der Fähigkeit, durch Kommunikation, Verständnis und der Übernahme von Verantwortung zu leiten. Diese Erkenntnis revolutionierte die Teamdynamik und förderte eine Kultur der kontinuierlichen Verbesserung.
Die Auseinandersetzung mit den einzelnen agilen Rollen hat die Planung stark beeinflusst. Das PI Planning gibt agilen Teams eine klare Richtung und klärt, woran sie gemeinsam arbeiten sollen. Berater Paul Weißhaar sieht darin den größten Erfolg:
Die PI Plannings sind jetzt viel effizienter. Die Product Owner und der Product Manager stimmen das Backlog schon Wochen vorher ab. Dadurch bleibt genug Zeit, um sich mit Risiken und Abhängigkeiten zu befassen. Anfangs gab es oft Ratlosigkeit bei den Planungen, aber ein Mindset-Change hat das geändert.
– Paul Weißhaar (Berater)
„Wir haben uns anfangs damit schwergetan, keine Vorgaben zu haben, außer einem fernen Ziel an einem zukünftigen Datum“, meint dazu Product Owner Christoph. „Waren wir anfangs noch in einer Warteposition, ob da wohl noch was kommt, haben wir irgendwann entschieden, selbst einen Plan zu machen oder zumindest starken Einfluss zu nehmen und das Produkt in die Richtung zu lenken, die wir für richtig halten, solange niemand Einspruch erhebt. In unserem Team können wir tatsächlich relativ losgelöst von anderen arbeiten. Es ist klar, was die Plattform, die wir entwickeln, zukünftig enthalten muss, aber irgendwann gibt es doch Abhängigkeiten. Langsam kommen wir aus der Phase, in der wir Prototypen bauen, in einer Phase, in der mehr und mehr Software entsteht, die mit anderen Bereichen abgestimmt werden will, beziehungsweise muss. Diese Abstimmung muss laufen – organisatorisch, planerisch, aber auch technisch. Da die Rollen besser definiert und herausgearbeitet wurden, sind die Teams selbstständiger in der Feinplanung geworden. Wir Product Owner können uns dadurch mehr und mehr auf die Feature-Ebene und das große Zusammenspiel konzentrieren.“
Der wahre Motor der Veränderung war die Eigenverantwortung der Teams. Indem sie selbst entschieden, welche Bausteine zuerst angegangen werden und welchen Rahmen sie selbst stecken wollen, statt auf Vorgaben zu warten, wurde nicht nur die Motivation gesteigert, sondern auch der Erfolg der Transformation gesichert.
Anfangs wurden die agilen Tools und Rituale kritisch betrachtet. Noch läuft nicht alles reibungslos, aber die Teams prüfen jetzt bewusst, ob ein digitales Tool oder ein Ritual aus dem agilen Framework echten Mehrwert bietet beziehungswelche in welcher Form. Scrum Master und Release Train Engineer (RTE) sind entscheidend, da sie Wissen bündeln und den Austausch fördern.
„Über Tools und Rituale wird in agilen Transformationsprozessen immer geschimpft“, hat uns Paul Weißhaar verraten. „Nehmen wir zum Beispiel die Sprintdemos bei dem ein Entwicklungsteam die Ergebnisse eines Sprints vorführt. Sie werden ganz oft als Kontrollinstrument empfunden. Aber hier haben sich Architekt und Team irgendwann Gedanken gemacht, was wäre, wenn sie in drei Monaten einen richtigen Use Case präsentieren könnten. Darauf wurde das PI Planning entsprechend ausgerichtet. Am Ende gab es tatsächlich eine physische Demo in der Halle und für alle wurde erlebbar, was die einzelnen Teams machen und in drei Monaten Brauchbares schaffen. So was erlebt man im klassischen Projektmanagement nicht.“
Man bekommt im agilen Setting schnell Feedback, ob alles beachtet wurde, und man kann bei Bedarf schnell und rechtzeitig korrigieren. Bei großen und schwierigen Projekten wie diesem ist das wirklich ein Vorteil.
– Robert (Product Owner)
Die anfängliche Skepsis gegenüber agilen Tools und Ritualen wich der Erkenntnis, dass sie nicht nur Kontrollinstrumente sind, sondern Plattformen für Innovation und Zusammenarbeit. Die physische Demo in der Halle war ein greifbares Beispiel für den Mehrwert, den diese Tools bieten können.
Sprint-Ergebnisse motivieren und wecken Interesse an der Arbeitsweise. Der Fokus verschiebt sich von der Organisation zum Produkt. Jeder kann mitreden, muss aber auch etwas beitragen. Die schnell sichtbaren Ergebnisse stärken die Selbstwirksamkeit der einzelnen Teammitglieder. Routinen ermöglichen Entwicklern außerdem, frühzeitig kritische Themen anzusprechen und gehört zu werden.
Es ist nicht: ‚Das müsst ihr machen‘, sondern: ‚Wenn wir die Ressourcen und die Zeit beachten, wie können wir damit ein Ergebnis schaffen, das sich zeigen lassen kann.‘ Es zählt nicht nur der Output, sondern auch der Outcome, also der tatsächliche Mehrwert.
– Elin (Scrum Master & Developer)
„Das Team hat sich sowohl in seiner Selbstorganisation als auch im Verhalten verbessert. Diese Fortschritte in der Teamdynamik und Führung haben maßgeblich dazu beigetragen, ihren Erfolg bis heute zu erhalten und voranzutreiben.” Wie nachhaltig dieser Erfolg ist, den unser interner Agil & Lean Experte beschreibt, wird sich zeigen, wenn wir nun die nächsten Schritte ohne die methodische und strukturierte Begleitung gehen. Auch, ob wir dann weiter genau so schnell vorankommen. Die agile Arbeitsweise ist ein „Infinity Game“. Die richtigen Weichen sind jetzt gestellt, sodass wir die nächsten Schritte aus eigener Kraft gehen können.
Der Wechsel vom reinen Output-Denken hin zu einem Outcome-Fokus stärkt die Selbstwirksamkeit der Teammitglieder. Diese neue Perspektive ermöglichte es ihnen, nicht nur ihre Aufgaben zu erfüllen, sondern echten Mehrwert zu schaffen, der den Erfolg des Teams langfristig sichert.
Es wird immer wichtiger, diese Schnittstellen zur restlichen Organisation zu beachten.
„Manchmal ist es noch immer eine Herausforderung, die richtigen Informationen von den unterschiedlichen Stakeholdern zu bekommen“, meint unsere RTE Nidhi. „Je weiter das Projekt voranschreitet, desto wichtiger wird es, genau herauszufinden, was die Teams brauchen und wo es weitere Abhängigkeiten gibt, die wir noch nicht bedacht haben.“
Passen wir die agile Arbeitsweise weiter so individuell an unsere Organisation und Teams an, können wir langfristige Planbarkeit verbinden mit Flexibilität und der Fähigkeit, Fehler frühzeitig zu erkennen und den Kurs rechtzeitig zu ändern.
Es erfüllt mich mit Stolz, zu sehen, wie mein Kunde nun eigenständig die Früchte unserer Zusammenarbeit erntet. Diese Erfolgsgeschichte beweist: Mit der richtigen Unterstützung und einem engagierten Team ist jede Transformation möglich.
Ein besonderer Dank geht an Michael Gerstle und das Team von MEWS Partners GmbH. Ihre Expertise und unser kollegiales Sparring waren entscheidend für den Erfolg in diesem komplexen Umfeld. Bei einer agilen Transformation parallel zum Tagesgeschäft ist voller Einsatz gefragt. Der erfahrene Blick von außen und eine intensive Zusammenarbeit sichern den langfristigen Erfolg.
Paul Weißhaar
E-Mail: info@weisshaar-consulting.com
Tel.: 0152 27698435
Agile Arbeitsmethoden machen zukunftsfähige Unternehmen wettbewerbsfähig. Vorausgesetzt, das Team zieht mit. Erfahre, welche Voraussetzungen im Team gegeben sein sollten, damit agile Methoden nicht zum Rohrkrepierer werden, sondern zum Erfolg führen.
„Einmal mit Profis arbeiten!“ – Manche Führungskraft fühlt sich umgeben von Amateuren, würde sich lieber klonen oder alles selbst machen, statt täglich im chaotischen Büro-Zoo zu stecken. Das wäre allerdings keine gute Idee: Zum einen können sie nicht alles selbst machen und zum anderen braucht ein erfolgreiches Team die unterschiedlichsten Spezies.
Weißhaar Consulting GmbH
Große Bleichen 37
20354 Hamburg
Mail
info@weisshaar-consulting.com
Telefon
0152 27698435
© Weißhaar Consulting GmbH