26. März 2024
Get in touch
Ein bekannter Telekommunikations-Anbieter sucht öffentlich nach Unterstützung für seine agile Transformation. Die Verwendung von SAFe, einem skalierbaren agilen Framework als methodischer Leitfaden, ist bereits beschlossen und festgelegt. Sowohl spezialisierte agile Dienstleister als auch große Beratungsgesellschaften mit möglicherweise bestehenden Rahmenverträgen beim Auftraggeber bewerben sich um den Auftrag. Letztendlich erhält eine dieser großen Beratungsgesellschaften den Zuschlag, vermutlich aufgrund der Tatsache, dass ihre Tagessätze den Vorgaben des Auftraggebers entsprechen (siehe Rahmenvertrag).
Nachdem die Ausschreibung gewonnen wurde, werden die Mitarbeiter dieser Beratungsgesellschaft zeitnah für verschiedene Trainings beim oben genannten agilen Spezial-Dienstleister angemeldet. Dieser hatte ebenfalls ein Angebot abgegeben, jedoch den Zuschlag nicht erhalten. Die große Beratungsgesellschaft verfügt aber selbst nicht über ausreichend Berater mit den erforderlichen Kompetenzen für die gewünschte Transformationsleistung des Kunden.
Die nun vom Mitbewerber und eigentlichen Know-how-Träger schnell geschulten und zertifizierten Berater beginnen anschließend beim Auftraggeber damit, die im Framework festgelegten Trainings und Workshops durchzuführen. Als erstes soll die Teamzusammenstellung festgelegt werden, um möglichst wenige Abhängigkeiten zwischen den Entwicklungssträngen der einzelnen Teams entstehen zu lassen.
Die Zusammensetzung der Teams, die von den Beratern befürwortet wird, bleibt aber weiterhin innerhalb der Bereichs- und Abteilungsgrenzen des Auftraggebers angesiedelt. Wahrscheinlich wurden die Selbsterhaltungskräfte des Systems / der Organisation des Auftraggebers von den im agilen Bereich meist eben doch unerfahrenen Beratern unterschätzt. Die eigentliche Zielsetzung der Workshops, Teamarchitektur mit geringen Abhängigkeiten zwischen den Teams zu schaffen, wurde nicht oder nur pro forma erreicht (s. a. „Value Stream and ART Identification Workshop“). Dass die Abhängigkeiten zwischen den Teams diese lähmen werden, wurde vor dem Hintergrund von „erfolgreich“ durchlaufenen Schritten der Transformations-Roadmap vernachlässigt. Der Auftragnehmer erfüllt seinen Auftrag, stringent durch die Workshop- und Trainingsreihe zu führen, aber berücksichtigt eben leider nur formale Aspekte.
Des Weiteren wird die Bearbeitung von Konflikten, die sich aufgrund von Widerständen und Selbsterhaltungskräften der Organisation ergeben, nicht durchgeführt. Es gab sicherlich gute Gründe, die Firmen in Richtung Agilität weiterzuentwickeln. Die Rolleninhaber erhalten zwar neue Namen für ihre Rollen, jedoch sind sie weiterhin in der Lage, dieselben Aufgaben zu übernehmen und dieselben Entscheidungen zu treffen, wie auch die Bereiche und Abteilungen. Das System verändert sich zwar formal in Richtung Flexibilität, tatsächlich erhält es jedoch lediglich eine neue Verpackung…
Leider treten auch einige andere Veränderungen auf, die nicht unwesentlich sind, aber nicht unmittelbar sichtbar werden. In der scheinbar schönen neuen agilen Welt verlieren Rolleninhaber allmählich ihre Rechte und Verantwortungen. Sie verlieren beispielsweise das Recht, mit den Teams zusammenzuarbeiten, um die Entwicklungsstrategie für das Produkt selbstorganisiert zu bestimmen. Auch büßen Rolleninhaber die Pflicht ein, sich um die Entwicklung einzelner Mitarbeiter:innen und/oder ganzer Teams zu kümmern, diese zu fördern und zu fordern, Alignment herzustellen, Konflikte und Risiken zu mitigieren und letztlich so zu führen, dass Mitarbeitende und Teams gewillt sind, weiterhin zu folgen.
In Konsequenz für die Unternehmensstruktur bedeutet dies, dass Konflikte, die bereits in den Bereichen und Abteilungen stattgefunden haben und weiterhin auftreten, nicht mehr von den Abteilungen und Abteilungen selbst gelöst werden können, sondern erst durch die Interaktion der Teammitglieder sichtbar werden. Bedauerlicherweise ist es aber unmöglich, sie auf Teamebene zu lösen. Die Teams sehen sich also mit Konflikten, die vorher zwischen den Organisationsgrenzen prozessiert wurden, konfrontiert, ohne die Mittel, Mandate oder Möglichkeiten zu haben, diese zu heilen.
SAFe empfiehlt an dieser Stelle den Einsatz eines sogenannten LACE-Teams (Lean Agile Center of Excellence), um diese Herausforderungen zu bewältigen. Das LACE-Team ist ein Gremium, welches sich um eine kontinuierliche Verbesserung innerhalb dieser Strukturen kümmert, eine Art Scrum Master Gremium, bestehend aus einem Mentor für den ART (agile Release Train), erfahrenen Beratern, dem Release Train Engineer sowie Entscheidern aus dem konventionellen Umfeld, ggf. auch einem HR- oder/und BR-Vertreter. In unserem vorangegangenen Praxis-Beispiel wurde ein solches LACE-Team leider nicht eingesetzt.
Dies führte dazu, dass die von der agilen Transformation erhofften Effekte, nämlich die drastische Reduktion der time2Market und eine Steigerung der Zufriedenheit der Angestellten, nicht eingetreten sind. Es existieren weder Wettbewerbervorteile, noch wurde für die Angestellten ein Umfeld, in dem sie ihre Zufriedenheit mit der Arbeit durch Loyalität, Mitarbeiterbindung und intrinsische Motivation ausdrücken können, geschaffen. Das angestrebte Ziel wurde demnach völlig verfehlt, da man sich zunächst für einen Dienstleister entschieden hat, der keine ausreichende Praxiserfahrung im Bereich agiler Prinzipien besitzt.
