Agile Transformation und Veränderungen - Logische Folge

Wie agile Teams zwangsläufig Änderungen herbeiführen, erfahren Sie hier

ls ein Unternehmen, welches jeden Tag mit Veränderungen in Markt, Produktlandschaft und Kundenerwartungen konfrontiert ist, setzen wir uns bereits seit geraumer Zeit mit agilen Methoden auseinander und tauschen gemachte Erfahrungen regelmäßig mit Kunden und Mitbewerbern aus. Dabei fällt auf, dass die tatsächlichen Ergebnisse der meisten Einführungen deutlich hinter den gesetzten Erwartungen zurückbleiben, nicht nur was die Produktivität, sondern auch die Qualität der Ergebnisse und nicht zuletzt die Zufriedenheit der Beteiligten angeht. Einen möglichen Grund – nicht anpassungsfähige Unternehmensstrukturen – wollen wir in diesem Blogbeitrag etwas näher unter die Lupe nehmen.


In den letzten Jahren war eine interessante Entwicklung zu beobachten, für diejenigen unter uns, die das Thema “Agile Softwareentwicklung” schon etwas länger verfolgen. Nach langen initialen Widerständen gegen die Ideen an sich durchlief der Begriff “Agile” einen klassischen Hype Cycle – angefangen bei fundamentaler Ablehnung (“Das funktioniert doch nie”), über die ersten Erfolgsgeschichten, gefolgt von teilweise nicht mehr fundierter Begeisterung, Entstehung eines eigenen Industriezweiges “Agile-Consulting”, teilweise überstürzter Einführungen unter weitgehender Nichtbeachtung der dahinterliegenden Prinzipien, später Ausverkauf, Rückschläge, Desillusionierung. Viele der Gescheiterten aus der ersten Welle erklärten öffentlich ihren Rückzug aus dem Thema, auch wenn die Ursache für die Misserfolge laut ihnen nun nicht mehr in der Methode selbst, sondern in den “besonderen Rahmenbedingungen” ihres Unternehmens (sprich: grundsätzlicher Inkompatibilität mit agilen Methoden) zu suchen wäre. Gleichzeitig haben einige der Vordenker und Visionäre der ersten Stunde für die letztendliche Umsetzung ihrer Ideen kaum mehr als Kopfschütteln übrig. Während Teile der Wirtschaft sich jetzt erst mit agilen Denkweisen auseinandersetzen, haben andere, insbesondere Early Adopter, bereits den Slogan “Agile is dead” ausgegeben.

Enttäuschte Erwartungen

Bei wieder anderen Unternehmen scheint dagegen ein neuer Realismus eingesetzt zu haben. Denkfehler aus der ersten Einführung werden diskutiert, Methoden wie Scrum nun ernst genommen. Die früher belächelte Rolle des Scrum Masters wird (oft gut bezahlt) in hunderten von Stellenanzeigen quer durch alle Branchen ausgeschrieben, offen bleibende Stellen über Weiterbildungen bestehender Mitarbeiter gefüllt. Und trotz “agiler” Teams, über 125.000 Scrum.org-Zertifikatinhabern weltweit, unzähliger Konferenzen voller überzeugender Keynotes, dem steigenden Interesse an technischen Ansätzen wie testgetriebener Entwicklung, Continuous Delivery und DevOps, scheint der erhoffte Erfolg nach wie vor auszubleiben. Geschichten, die von 500% Produktivitätssteigerung berichten, werden auch sechzehn Jahre nach dem “Agile Manifesto” noch mit skeptischen Blicken aufgenommen. Nach einer häufig initial unruhigen Einführungsphase scheinen sich Unternehmen zunehmend damit zu arrangieren, dass ihre Teams nun im wesentlichen dieselbe Leistung erreichen wie zuvor, nur dass die neuen Methoden eben häufigere Planung und vor allem auch häufigere Releases erlauben. Zufrieden ist zwar nun niemand wirklich – wo sich das Business mehr und neue Möglichkeiten versprochen hatte, hatte die Entwicklung unter anderem weniger Stress und mehr Effektivität erwartet, und beide Seiten wurden häufig enttäuscht. Eine solche Einführung agiler Methoden muss früher oder später verkümmern, bestenfalls stagniert sie auf niedrigem Erfolgsniveau.

Überraschend dabei ist, dass ja die eingeführten Methoden, in ihrem Kern, bereits einen Prozess der kontinuierlichen Verbesserung vorsehen. Im Scrum ist die Sprint-Retrospektive ein wesentlicher Teil des Prozesses, Kanban sieht mit Kaizen eine evolutionäre, inkrementelle Veränderungsstrategie vor – selbst schon im Manifest spricht Prinzip 12 von der Selbstreflektion mit dem Ziel gesteigerter Effektivität. Wie kann also ein Team, welches die laufende Selbstverbesserung lebt und ernst nimmt, nicht auf Dauer erfolgreicher werden als klassisch operierende Teile des Unternehmens?

Cartoon-Parodie zu agilem Arbeiten
Quelle: http://geek-and-poke.com/

Agile Transformation als Motor der Veränderung

Die Antwort ist sicher zum Teil darin zu suchen, dass, nach dem Beheben teaminterner Impediments (etwa fehlerhafte Kommunikation oder Kollaboration, Mangel an Selbstorganisation, geringes Verantwortungsgefühl, fehlende Nutzer- und Nutzenorientierung, fehlendes technisches Know-How), das Team häufig an die Grenzen seiner Einflusssphären stößt. Für operativ tätige Scrum Master ist schnell der Punkt erreicht, an dem die größten Hürden für das Team nicht ohne die Mitarbeit und Unterstützung der umgebenden Organisation aus dem Weg geräumt werden können – schließlich existieren auch agile Teams nicht im luftleeren Raum, sondern sind intensiv mit der Organisation verdrahtet und auf dessen (häufig kurzfristige) Unterstützung angewiesen! Diese muss nun die Teams ihrerseits als “Kunden” verstehen, sich selbst zu einem effektiven Dienstleister der Teams entwickeln und früher oder später in der Lage sein, bei der kurzfristigen Planung und dem hohen Arbeitstakt dieser Teams mithalten zu können – zuliefernde Einheiten stellen sich daher wiederum selbst als agile(re) Teams auf und brauchen ebenfalls kontinuierliche Verbesserungsprozesse, um ihre Services immer und immer wieder an sich ändernde Bedürfnisse anzupassen.

Von einer derartigen “agilen Transformation” werden, Bewusstsein und Unterstützung vorausgesetzt, früher oder später weite Teile der Organisation erfasst. Nicht nur unmittelbare Kontaktpunkte der Teams, wie etwa Personalabteilung, Projektmanagement, interne IT-Services oder Vertrieb, sind betroffen – auch auf tiefer liegende Abteilungen wie Finance, Legal oder Office Management kommen neue Herausforderungen zu. Nicht zuletzt ist ein klassischer Unternehmensaufbau, der vor allem die Organisation der beteiligten Menschen zum Ziel hat, auf Dauer nicht mit dem Anspruch “Organize the work, not the people” selbstorganisierter Teams kompatibel. Es müssen Fragen gestellt (und beantwortet) werden, die an fundamentale Eigenschaften der Organisation rühren – wie z.B. kann ein Product Owner wirklich empowered werden wenn er auf einer unteren Ebene eines hierarchisch-pyramidenförmigen Organigramms zu finden ist? Wie lässt sich der Anspruch, langfristig das beste Produkt zu bauen, mit einer quartalsweisen Betrachtung des finanziellen Ergebnisses in Einklang bringen? Sind im Kunde-Dienstleister-Verhältnis beide Parteien wirklich bereit für eine Kollaboration als gleichberechtigte Partner, bei der sich Entscheidungen und Verantwortlichkeiten teilweise nicht mehr sauber auf einzelne Personen zurückführen lassen?

Der Blick nach vorne

Konsequent zu Ende gedacht, lässt sich mittlerweile ein recht klares Bild zukünftiger agiler Organisationen zeichnen. Sicherlich ist es sinnvoll, die Organisation vor allem auf die Identifikation und Verwaltung anfallender Arbeiten zu konzentrieren, und weniger auf die Verwaltung der beteiligten Personen. Mitarbeiter können im Umkehrschluss eine oder mehrere Rollen einnehmen, die an der Erledigung der anfallenden Aufgaben in unterschiedlicher Weise beteiligt sind, und deren Existenzberechtigung untrennbar mit ihrem Nutzen für die restliche Organisation verknüpft ist. Auf diese Weise müssen sich Rollen und Organisationseinheiten regelmäßig kritisch hinterfragen und ihrerseits kontinuierliche Verbesserungsprozesse durchlaufen, deren Ziel die laufende Neuausrichtung auf die Bedürfnisse ihrer (internen oder externen) “Kunden” ist. Methoden wie etwa Holacracy, wenn auch für ihre teils starre Formalisierung und Bürokratie kritisiert, sind in dieser Hinsicht vielversprechende Ansätze.
Nicht zuletzt ändert sich auch die Rolle des Managements, welches kein Selbstzweck sein kann, sondern im Sinne einer Servant Leadership Orientierung und Vision, aber auch Raum und Unterstützung für Verbesserungsprozesse bieten muss. Die häufig gerühmten “flachen Hierarchien” sind daher nicht Verbesserungsmaßnahme per se, sondern vielmehr ein zwangsläufiger Nebeneffekt der Verschlankung der Organisation auf diejenigen Instanzen, die für das System als Ganzes tatsächlich einen objektiven, signifikanten und messbaren Mehrwert anbieten können.