Was verhindert oder behindert agile Transformationen? Warum werden die gesetzten Ziele zur Veränderung von Unternehmen torpediert  – nicht selten von den Initiatoren selbst? Warum erfolgt das Unterlaufen von Change-Prozessen kurioserweise oft durch die Anwendung von agilen Prinzipien?

Dies sind Fragen, die in vielen Fällen erst dann gestellt werden, wenn das Scheitern offensichtlich wird. Dabei sind es meist grundsätzliche Gründe, die den Weg in eine funktionierende agile Organisation versperren. Einige werden hier formuliert.

Es gibt viele Möglichkeiten, eine agile Transformation als spezielle Form einer sehr grundsätzlichen Veränderung eines Unternehmens anzugehen. Und am Anfang ist meist nicht klar, wie grundsätzlich der Change tatsächlich sein muss/wird. Entsprechend werden wesentliche Fragen nicht konsequent angegangen. 

die richtige Reihenfolge

Ein Grund für die unbewusste (oder bewusste) Verhinderung liegt in der Reihenfolge von Transformationsschritten oder im schlichten Übergehen notwendiger Teile.

Haben Unternehmen zunächst einen kleinen Bereich “agilisiert” – also z.B. ein oder einige wenige Scrum Teams eingerichtet – und finden das Experiment gelungen, entsteht der Wunsch nach mehr. Und folglich  irgendwann der Anspruch, die Arbeit der Teams an integrierten Produkten und Lösungen arbeiten zu lassen. Folglich ist eine Skalierung von agilen Arbeitsweisen erforderlich. Manche suchen eigene Wege, manche versuchen, bekannte skalierte Frameworks wie Nexus, Less oder SAFe zu implementieren.

Andere Unternehmen haben Einsichten wie “wir müssen schneller werden…”, “wir brauchen mehr Innovation…”, “unsere Strukturen sind zu starr zur schnellen Reaktion…” etc.. Und kommen auf den Trichter, eine agile Transformation gleich umfassend mit Skalierung anzugehen.

Beide Wege und auch Mischformen davon sind nicht per se falsch. Wird aber spätestens im Zuge der Entscheidung zur Skalierung nicht hinreichend geklärt, wie umfassend der Prozess sein muss, welche Organisationsteile einbezogen werden, welche Menschen beteiligt oder betroffen sind, ist der Fail vorprogrammiert. Deshalb stellt SAFe im Kontext seiner Implementation-Roadmap die Ausbildung von Führungskräften und Change-Leadern ganz an den Anfang. Dann erst folgt die Ausbildung von Mitarbeitern und die Ausprägung von Wertströmen und zugehöriger Organisation.

Diese ersten wichtigen Schritte werden häufig übergangen. Motto: “erstmal die Leute ans (agile) Arbeiten bekommen, Führungskräfte und die bestehende Organisation können sich immer noch anpassen”. Dies ist grundsätzlich ein falscher Ansatz, weil die skalierte agile Arbeit i.d.R. durch bestehende Silos nicht inhaltlich gesteuert werden kann. So wie ein einzelnes ScrumTeam in weiten Teilen selbstorganisiert arbeitet und Entscheidungen trifft, so muss auch eine skalierte Organisation für sich autark sein. Release Trains und Solution Trains in einer SAFe Organisation sind meist quer zu bestehenden Silos aufgestellt. Bricht man diese Silos nicht anfänglich auf – oder zeigt zumindest den Transformationsbedarf auf – wird es immer Störungen der agilen Arbeit in Teams und Trains geben. Das sind kulturelle Veränderungen, die gewollt werden müssen und für die es ein Committment der gesamten Leitung geben muss. Deshalb sind die vorbereitenden Maßnahmen auf Führungsebene so wichtig. Wer dabei nicht mitspielen möchte, ist sofort ein großer Risikofaktor für die Transformation.  Und es muss offen darüber gesprochen werden, wie solche Risiken mitigiert werden. Werden solche in Einzelpersonen und/oder Siloorganisationen liegenden Risiken ignoriert oder nicht hinreichend adressiert, besteht kaum eine Chance auf eine gelungene Transformation.

das Autarkieproblem

Ein anderer Aspekt findet sich in der merkwürdigen Strategie, auf neue Probleme und Situationen mit bekannten Methoden und Mustern zu reagieren. Alte Antworten für neue Fragen anzusetzen. Das funktioniert nicht in der Klimakrise und nicht in (Neu-)aufstellung von Unternehmen. Perfektioniert wird dieser Ansatz bei Unternehmen, die einen Teil von sich selbst für innovative Produkte herauslösen und eine “digitale” Tochter gründen. Mit dem Anspruch, auf agile Art und Weise die Zukunft zu sichern – natürlich auch für die große Mutter gleich mit. Das könnte sogar funktionieren, wenn der neue Bereich:

• tatsächlich autark arbeiten und entscheiden kann
• keine Gängelung durch die Mutter erfolgt
• seine eigenen Prozesse definiert (wo welche gebraucht werden)
• die Ressourcen bekommt, die er benötigt

Was geschieht statt dessen? 

• statt crossfunktional kompetente Menschen zu rekrutieren, werden ganze Abteilungen in den neuen Bereich transferiert
• der “Einfachheit” halber werden bestehende Prozesse für die Produktentwicklung mit übernommen.
• gleiches gilt für Einkaufs- und HR-Prozesse. Es ist ja so praktisch, wenn sich Menschen im Konzern um diese lästigen Dinge kümmern
• dem neuen Bereich wird nicht vertraut. Sondern über alle Aktivitäten, Ideen und über jeden ausgegebenen Euro muss Rechenschaft abgelegt werden. 
• das Ganze wird als Projekt angesehen. Mit entsprechenden Berichtspflichten.

Die Folgen?

• (skalierte) agile Prinzipien wie dezentrale Entscheidungen und kurze Lernzyklen werden unterminiert, 
• jede (Eigen-)Initiative wird abgewürgt durch dauernde Rechtfertigung,
• Kultur der Angst wird nicht abgebaut, es erfolgt kein Ausprobieren und Verwerfen, kein mutiges Voranpreschen,
• Menschen verstecken sich hinter Regeln und Prozessen, diese werden nicht hinterfragt,
• Entscheidungen werden eskaliert, aufgeschoben und verzögert,
• Beschaffung notwendiger Ausrüstung wird verzögert, weil dies z.B. nicht zum Standardkatalog gehört und der  zentrale Einkauf blockt,
• Einflussnahme und Steuerung von Inhalten durch den Konzern verhindert neue Lösungen, z.B. durch Drängen nach Wiederverwendung,
• es entsteht kein Produktentwicklungszyklus,
• zentrale Präferenz für Effizienz statt Effektivität unterläuft Denken in Lernzyklen und dem Streben nach dem besten Produkt,
• Verbesserung erfolgt allenfalls in kleinen Schritten, disruptive Ansätze werden grundsätzlich verworfen oder zerredet.

Die Autarkie einer agilen Organisation ist keine Gnade der Mutterorganisation, sondern notwendige Voraussetzung für eine erfolgreiche Arbeit. Agilität ohne Autarkie ist wie Bahnfahren ohne Schienen. Es ist schlicht unmöglich. Das Ziel wird nicht erreicht.

Committment Falle

Viele kennen das: nach einem Sprint-Planning haben sich die Teammitglieder auf den Sprint-Inhalt committed oder in einem PI-Planning wurde ein gutes Confidence Vote erreicht. Kurz danach gibt es erste Ansinnen von Führungskräften, doch mal eben etwas “Wichtiges” einzuschieben. Unreife Teams und skalierte Organisationen schaffen es nicht, diese Torpedos abzuwehren – und müssen sich am Ende des Zykluss auch noch rechtfertigen, warum ihr Content nicht fertig ist.

Es ist ein grundsätzlicher Fehler zu glauben, dass Committments Einbahnstraßen wären. Im agilen Kontext ist dies eine bidirektionale Verpflichtung. In eine Richtung: “ja wir liefern…..”; in die andere Richtung: “ja, wir sorgen dafür, dass Ihr liefern könnt”

Der zweite Teil bedeutet zum Einen die notwendigen Ressourcen bereit zu stellen, zum Anderen, die Teams und Trains von zusätzlicher ungeplanter unpriorisierter Arbeit frei zu halten. 

Jede Führungskraft, die diese Richtung des Committments unterläuft, wird mit dafür sorgen, dass die agile Transformation nicht voran kommt. Das große Wort der Agilität ist Vertrauen. Das gibt es nur mit beiderseitiger Verlässlichkeit.  

Es gibt in der skalierten agilen Organisation bottom up Committments über anstehende Lieferungen. Die werden aber nur eingehalten, wenn die top-down Committments ebenso eingehalten werden.

Dazu gehört z.B. auch, die Errungenschaften der Teams und Trains nicht über abstrakte Statusberichte abzufragen, sondern als Führungskraft, Business Owner oder anderer Stakeholder aktiver Teil von SystemDemos, Reviews oder sonstigen Formen der Demonstration zu sein. Ein Statusbericht hat noch kein Produkt gut gemacht, sondern nur das Feedback der Kunden und Nutzer. Deshalb ist frühes Feedback so wichtig.

Fazit:

Wir haben einige wichtige Gründe genannt, warum agile Transformationen scheitern können. Wenn wir also  

• die richtige Reihenfolge für die Transformationsschritte wählen,
• den Raum schaffen für eine wirklich umfassende Veränderung,
• möglichst die Fesseln aus bestehenden Organisationen ablegen,
• die Autarkie der agilen Organisation sicherstellen,
• Committments als bidirektionale Verpflichtung verstehen,

haben wir wesentliche Faktoren berücksichtigt, dass die Transformation gelingt kann. Weitere Voraussetzung ist z. B. die konsequente Anwendung von agilen Prinzipien und Werten und der entsprechenden Ausrichtung der Menschen sowie vor allem Haltung. Practises und Methoden, Rollen und Events können immer im individuellen Fall diskutiert werden. Die grundsätzlichen Prämissen stehen hingegen nicht zur Disposition.