Der Mechanismus des Scheiterns

Im Zuge der „Digitalisierung“ suchen viele Unternehmen aktuell Mittel und Wege, wie sie ihre eigene Version einer „Digitalisierungsstrategie“ ausbilden können. Sobald sich ausprägt, was dies inhaltlich bedeuten könnte, stellt sich die Frage - gerade bei historisch wenig IT-affinen Unternehmen - wie die entwickelten Ansätze praktisch umgesetzt werden können. Auf oberster Abstraktionsebene läuft dies auf eine klassische Make-or-Buy-Entscheidung hinaus … allerdings mit einer besonderen Herausforderung: das was hier geschaffen werden soll hat den Anspruch, in Zukunft nicht nur maßgeblich zur Wertschöpfung beizutragen, sondern muss zu jedem Zeitpunkt der Entwicklung hochgradig wandelbar sein, um der Marktentwicklung folgen zu können. Darüber hinaus besteht häufig der Anspruch, etwas "Neues" zu erschaffen, dessen strategische Bedeutung für das Unternehmen so groß ist, dass es vernünftig erscheint, dass das entstehende Asset vollumfänglich in Eigenregie und -produktion entsteht. Um diesen Aspekten gerecht zu werden,  fällt die Entscheidung ungewöhnlich häufig auf "Make".

Diesen Weg der Entscheidungsfindung und mögliche Alternativen möchte ich an dieser Stelle gar nicht weiter diskutieren - auch wenn es für sich genommen ein hochinteressantes Thema ist. Was nun vielmehr im Fokus stehen soll ist die Frage: Was passiert, wenn eine vollumfängliche "Make"-Entscheidung gefällt worden ist?

Unternehmen ohne Erfahrung in der Erstellung von Softwareprodukten sind gezwungen eine neue Organisation aufzubauen. Eine Weiterentwicklung bestehender IT-Strukturen schließt sich in der Regel aus: Das tatsächliche methodische und technische Know-How der IT-nahen Organisationsteile, deren bisheriger Fokus allein die Aufrechterhaltung und Weiterentwicklung des Legacy-IT-Betriebs war, ist hierfür nach Befinden aller - häufig auch der betroffenen Organisationsteile selbst - nicht hinreichend.

Die neue Struktur soll dann auch nach den augenblicklich modernsten Kriterien handlungsfähig sein. Ein reichhaltiges, externes Beratungsangebot hilft den Unternehmen hierbei, ihr Zielbild zu entwickeln. Das Ergebnis ist in der Regel die Empfehlung zum Aufbau einer von der Hauptorganisation entkoppelten IT-Zweigs mit einer lupenrein agilen Ausrichtung. Erstere Entscheidung folgt der Überlegung, dass eine solche organisatorische Abbildung der strategischen Bedeutung des Vorhabens am Besten gerecht wird und die Loslösung von womöglich einengenden Konzernrestriktionen darüber hinaus aus vielerlei Gründen vernünftig sein mag.

Aber wie kommt es zu der Überzeugung, dass die Organisation agil sein soll? Die bis zu diesem Zeitpunkt handelnden Entscheider haben - mit Verlaub - in der Regel nicht die leiseste Ahnung, was das für sie und die neue Organisation bedeutet. Die Entscheidung fällt dennoch in diese Richtung,

• weil das Beratungsumfeld dies forciert,
• weil die großen, international erfolgreichen Softwarekonzerne agil arbeiten (und diese das Vorbild für die zukünftige Geschäftsentwicklung sind),
• weil man sich in der Frühphase des Aufbauprozesses der neuen Organisation bereits  erfahrene IT-Manager als zukünftige Führungsriege an Bord geholt hat, die entweder aus eigener Erfahrung den agilen Ansatz favorisieren oder weil es gerade en vogue ist,
• weil die oberflächliche Selbstbeschäftigung des Managements mit dem Thema im Ergebnis häufig nur ein sehr reduziertes Bild erzeugt: Agilität erhöht Time-to-Market und ermöglicht Flexibilität - im schlimmsten Fall glaubt man auch noch, nachweislich günstiger Software erstellen zu können. Mögliche Nebeneffekte dieser methodischen Assets bleiben im Hintergrund.

So startet die neue Innovationstochter losgelöst vom Konzern in agilem Gewand. Je nach Führungsmannschaft der ersten Stunde besteht tatsächlich die Chance, dass die Unternehmenskultur vorbildlich im Sinne agilen Managements ist. Mitbestimmung, Verantwortungsteilung, Fehlertoleranz und flache Hierarchien bestimmen das Miteinander. Der Ergebnisdruck ist von Anfang an erheblich, dem wird mit hoher Motivation und ohne politische Schönfärberei begegnet. Das wird konzernseitig anfangs als exotisch charmant aber mit der Zeit als zunehmend unprofessionell wahrgenommen.
Der Druck wächst und äußert sich zunächst in einem beschleunigten Organisationsaufbau. Das steht einem agilen Managementansatz auch nicht entgegen, dient aber nicht der Sache. In der Softwareentwicklung gilt selten das Motto "viel hilft viel" und eine stark skalierende Scrum-Organisation erzeugt in sich neue Herausforderungen, die nicht unmittelbar auf den extern wahrgenommenen Geschäftswert des Softwareproduktes einzahlen.

So lässt der Konzern seine neue Tochter agieren, bis ein Punkt erreicht wird, an dem die Zusammenarbeit an den Schnittstellen beginnt zu brechen. Hierfür gibt es ein Spektrum an möglichen Gründen, die im Kern immer auf dasselbe Problem hinauslaufen: die bestehenden, konzernseitigen Erwartungshaltungen werden im Hinblick auf die Umsatzentwicklung, die Entwicklung neuer Features oder der Kundenzahlen enttäuscht. Hierbei muss man sich vor Augen führen, dass in der Regel die Verantwortlichen der agilen Tochtergesellschaft entweder in die Zielfindung gar nicht eingebunden oder nach dem Duktus eines klassischen Management-Commitments verpflichtet wurden.

Ist dieser Punkt erreicht, so gerät die agile Organisation in existenzielle Gefahr. Der Konzern verliert das Vertrauen und beginnt methodisch fremde Projektcontrollingmechanismen einzufordern oder bereits durch äußeren Zwang in der Organisation umzusetzen. Es werden langfristige fachliche Commitments eingefordert, Releasepläne eingeführt und deren Einhaltung peinlichst überwacht. Dies geschieht maßgeblich aus dem in der klassischen Geschäftswelt tief verankerten Wunsches eines langfristigen Plans, der dem Manager bei einer aktuell nicht befriedigenden Geschäftsentwicklung ein Gefühl der Sicherheit suggeriert, dass am Ende alles zum Erfolg kommt.

Diese "Planwirtschaft" ist tatsächlich aber der Sargnagel für den Erfolg. Agile Methoden dienen dazu, Kreativität in Kombination mit Flexibilität in der Produktentwicklung zu vereinen, um in einem sich schnell entwickelndem Markt- und Technologieumfeld ein Produkt herstellen zu können, was zur richtigen Zeit in der richtigen Weise den Kunden adressiert. Der Weg dahin ist nicht linear, sondern gespickt von Fehlentscheidungen. Die den agilen Methoden inhärente Flexibilität erlaubt die Kostenkontrolle darüber, indem sie die Möglichkeiten bieten, einmal identifizierte Fehlentwicklungen auch unmittelbar zu beenden und - mit viel Kreativität und hoher Geschwindigkeit - eine Neuausrichtung vorzunehmen.

Wird jedoch das Produkt in seiner aktuellen Ausprägung festgeschrieben und nur noch die Abarbeitung eines Umsetzungsplans erwartet, kann nur noch sehr viel Glück dazu führen, dass nicht das gesamte Vorhaben scheitert und die Investition verloren geht.

Dies weiß das agile Management der neuen IT-Organisation natürlich sehr genau und man sollte erwarten, dass es sich gegen den methodischen Strategiewandel massiv wehrt. Der Versuch wird auch fraglos unternommen, der Kampf geht meistens verloren. Woran liegt das?

Agile Organisationen verfügen in der Auseinandersetzung mit klassischen Konzernstrukturen über keine Abwehrmechanismen. Tritt der agile Manager in den Konflikt mit seinen Ansprechpartnern auf der Konzernseite - als Vertreter einer untergeordneten Tochtergesellschaft - so steht ihm nicht die Wahl der Waffen zu. Die Waffen sind diejenigen, die die Kultur des Konzerns vorschreibt.

Dies hat zur Folge, dass der agile Manager bei Anwendung der in seiner Organisation üblichen Konfliktlösungsansätzen grandios scheitert. Die Fehler, die er in der Eskalationssituation begeht, sind vielfältig:

• Zunächst nimmt er an, dass er und seine Gegenspieler dasselbe Ziel verfolgen. Dies ist aber mitnichten so: die monetären Steuerungsmechanismen und intern wettbewerbsorientierten Aufstiegspfade im Konzernumfeld prägen auf den mittleren und höheren Managementebenen häufig Charaktere aus, deren persönliche Weiterentwicklung in ihrem Konzernhabitat wichtiger ist als das Unternehmenswohl selbst. Dies heisst nicht, dass ein bewusster Wille bestände, Schaden zu erzeugen. Aber sollte der Erfolg der agilen Organisation die Position oder den persönlichen Karrierepfad des Konzernmanagers gefährden, so wird er sich - auch wieder besserer Argumente - gegen die agile Organisation aufstellen.
• Der agile Manager wird mit der Erwartung in die Deeskalation treten, dass alle in dem Kontext relevanten Themenfelder gemeinsam diskutiert werden. Dies ist dem Konzernmanager zuwider: er ist gewohnt seine Pfründe gegen Einflussnahme zu schützen und empfindet es als Schwäche, wenn man aus für ihn nicht nachvollziehbaren Gründen dies nicht tut. Eröffnet der agile Manager auch nur die kleinste Option zur äußeren Beeinflussung seiner eigenen Themen, so wird der Konzernmanager versuchen diese neue Wirkungssphäre dauerhaft zu für sich zu sichern und den agilen Manager mittel- bis langfristig zu verdrängen.
• Bei der Bewältigung der Eskalation wird der agile Manager mit Transparenz, offener Selbstreflektion und Fehlertoleranz auftreten. Dies ist ein gefundenes Fressen für den Konzernvertreter: Fehler seinerseits wird er niemals einräumen, sondern sie kaschieren und die Schuld anderen in die Schuhe schieben. Räumt der agile Manager einen Fehler seiner Organisation ein, so wird der Konzernmanager dies weidlich kommunikativ ausnutzen, um den agilen Kollegen zu schwächen und seine eigene Einflusssphäre zu erweitern.
• Anders als der agile Manager dies erwartet, besteht kein Teamzusammenhalt zwischen ihm und dem Konzernkollegen. Selbst wenn es gelingt, einvernehmliche Entscheidungen zu treffen, muss der agile Manager davon ausgehen, dass im Falle, dass sich diese als falsch erweisen, der Konzernkollege geübte Cover-your-ass-Strategien in der Hinterhand hat, um bei der Klärung der Schuldfrage seinen agilen Kollegen deutlich in ein schlechtes Licht zu rücken.

Auch wenn hier eine andere Anmutung aufkommen mag: ich halte den Konzernkollegen nicht für einen Bösewicht. Er bewegt sich schlicht nach den Spielregeln seines Kulturkreises, in dem er sozialisiert wurde. Und diese Spielregeln weichen fundamental von denen einer agilen Organisation ab.

Die Abweichungen sind leider dergestalt, dass in der direkten Auseinandersetzung der agil denkende Mensch das Nachsehen hat. Die Waffenungleichheit wird dadurch fundamental, dass der Konzernkollege mit seinem Handeln den Erwartungen der finalen Entscheidungsträger im Konzern entspricht, wohingegen die Herangehensweise des agilen Managers bestenfalls als zu methodenorientiert und schlimmstenfalls als esoterisch wahrgenommen wird.

Die Lösung für den agilen Manager besteht erfahrungsgemäß nicht in dem Versuch, einen Kulturkampf zu führen und den Konzern zu „agilisieren". Berater der agilen Szene betonen gerne, häufig und richtigerweise, dass das Management eines Unternehmens Agilität in allen Konsequenzen verstanden haben muss und idealerweise auch leben sollte, damit diese sich in den kreativen Teilorganisationen wirklich entfalten kann. Wie bereits beschrieben, sind diese Voraussetzungen jedoch in der Regel schlichtweg nicht gegeben. Wenn der agile Manager versucht, die aus Konzernsicht klare Sachdiskussion darum, warum Ziele hinsichtlich Zeit, Budget und Fachlichkeit nicht eingehalten werden auf einer kulturell-methodische Ebene zu führen, so erarbeitet er sich nur den Ruf eines wenig zielorientierten, esoterischen Spinners. Seine Demontage wird beschleunigt und der agilen Organisation in der Notlage nicht geholfen.

Wie gelingt es also der agilen Organisation, sich selbst zu schützen? Paradoxerweise nur dadurch, dass das agile Management die Bereitschaft mit sich bringt, an den Schnittstellen zum Konzern ihre eigenen Ideale zu verraten. Darüber hinaus ist hinreichende Erfahrung vonnöten, um sich in der Auseinandersetzung mit dem Konzernmanagement kulturell an die Gegenspieler anzupassen und wenn nötig ihre Mittel zu adaptieren und gegen sie zu richten. Erforderlich ist eine moralische Kaltblütigkeit, wie sie auch immer wieder in politischen Kontexten gefragt ist: inwieweit folge ich meinen eigenen Grundsätzen wenn ich gefordert bin das System, an das ich glaube, zu verteidigen?

Dieser Anforderung an das agile Management zu genügen ist wahnsinnig schwer. Menschen, die Agilität mit der Muttermilch aufgesogen haben, sind tendenziell ungeeignet. Ihnen fällt nicht nur die moralische schizophrene Positionierung schwer - ihnen fehlt auch in der Regel die nötige Erfahrung im Umgang mit ihren kulturell fremden Gegenspielern. Besser geeignet erscheinen Menschen, die aus einem klassischen Konzernumfeld kommen und die Klaviatur der konzernpolitischen Auseinandersetzung beherrschen. Gleichzeitig müssen sie aber erfahren in agilen Managementmethoden sein, die sie in ihrer eigenen Organisation aus wahrer Überzeugung leben können.

Mit der Etablierung von solchen, wehrhaften Charakteren an den Schnittstellen zu nicht-agilen Organisationsbestandteilen gelingt es dann auch womöglich, dem Scheitern agiler Substrukturen in Konzernorganisationen etwas von seinem deterministischen Charakter zu nehmen.

Der Mechanismus des Scheiterns folgt seinen eigenen Regeln. Mit diesen muss man umzugehen wissen.