Thought Leadership
Warum ist umfangreiche Erfahrung erforderlich, um agile Prinzipien effektiv anzuwenden? Zur Veranschaulichung nachfolgend eine wahre Geschichte.
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.
Zusammensetzung des Teams
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.
Was sagt das Scaled Agile Framework (SAFe)?
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.
Warum braucht es Erfahrung?
Aber warum braucht es eigentlich wirklich so viel Erfahrung, um agile Prinzipien erfolgreich in Softwareentwicklungsprozessen anwenden zu können? Ganz einfach: Weil man ansonsten die Prinzipien nicht wirklich versteht, in der Folge kontraproduktive Entscheidungen trifft und damit die ganze schöne agile Idee ad absurdum führt.
Im Klartext: Erfahrung ist ein wichtiger Faktor bei der erfolgreichen Implementierung von agilen Methoden in der Softwareentwicklung. Zunächst einmal wirken agile Ansätze wie Scrum oder Kanban wie einfache Prinzipien und Vorgehensweisen. Sie erfordern aber ein tiefes Verständnis für die ihnen zugrundeliegenden (Wirk-)Prinzipien. Erst durch Erfahrung lernt man, diese Prinzipien zu identifizieren und auch wirklich zu verstehen, wie man sie effektiv anwendet oder anpasst. Dazu werden eine flexible Denkweise, Reflexionsvermögen und Kreativität, ein Gefühl für Angemessenheit usw. benötigt. Wir reden also weniger über die reine Anwendung einer Methode, sondern eher über die Haltung, die die Wirkung von agilen Prinzipien fördern.
Im Endeffekt lässt sich anhand zweier Parameter eindeutig feststellen, ob die agilen Methoden erfolgreich eingesetzt wurden: Eine verbesserte Lieferfähigkeit des Unternehmens mit positiver Auswirkung auf die time2market sowie eine Verbesserung der Mitarbeiterzufriedenheit.
Man entwickelt mit zunehmender Erfahrung auch ein besseres Gespür dafür, wie Teams motiviert bleiben, Hindernisse beseitigt werden können und dabei noch der Entwicklungsprozess kontinuierlich verbessert werden kann. Weiterhin lernt man aus Fehlern und kann somit die Effizienz und Qualität der Softwareentwicklung steigern. Dabei wird das Lernen aus Fehlern inhärenter Bestandteil sowohl für das methodische Arbeiten (mit dem oder den Teams) wie auch für die Umsetzung von fachlich-inhaltlichen Anforderungen der agilen Arbeitsweisen. Flexibilität (Kreativität) und Lernbereitschaft (also Reflexionsvermögen) sind absolutes Erfordernis für „echtes“ agiles Arbeiten.
Außerdem macht zunehmende Erfahrung auch eine realistischere Einschätzung von allgemeinen Risiken und Herausforderungen, die bei der Nutzung agiler Prinzipien auftreten können, möglich.
Unsere Mitarbeitenden bei AOE verfügen über jahrelange Erfahrung bei der Anwendung agiler Prinzipien sowohl im Rahmen von Kundenprojekten wie auch in unserer internen Organisation. AOE ist also schon „aus dem Gröbsten raus“, eine Mannschaft von „Agile Adults“, die andere nachhaltig unterstützen können. Stetes Lernen auf allen Ebenen des Software-Developments (fachlich, technisch, methodisch, strategisch, architekturell, persönlich, organisatorisch usw.) ist für uns inhärenter Bestandteil unseres Selbstverständnisses sowie unseres Anspruchs an uns selbst.
Fazit
Wie unser Praxisbeispiel anschaulich gezeigt hat, reichen Trainings allein (auch wenn sie professionell durchgeführt wurden) nicht aus, um agiles Arbeiten erfolgreich in der Praxis anzuwenden. Neben dem Schlüssel-Faktor Erfahrung bedarf es einer offenen Einstellung, kontinuierlicher Weiterbildung und der Bereitschaft, aus Fehlern zu lernen.
Um diese erfolgskritischen Grundlagen auch den eigenen Kunden näherzubringen und sie zu befähigen, das Wesentliche im Blick zu behalten, lohnt es sich bisweilen auch, Negativbeispiele gemeinsam unter die Lupe zu nehmen. Dabei kann man das, was man besser lassen sollte, einfacher sichtbar machen und daraus lernen. Letztendlich hat der Status eines „Agile Adults” etwas mit dem Erwachsensein im Leben gemeinsam – er erfordert, individuelle Herausforderungen sorgfältig zu durchdenken – und die richtigen Praktiken und Arbeitsweisen für die vorhandene Situation abzuwägen und auszuwählen.
