Von der Organisationsfunktion zur Kompetenz

Controlling ist seit einigen Jahrzehnten organisatorisch fest in den Unternehmensstrukturen verankert. Die Rolle, Funktion und das operative Instrumentarium variieren mit der jeweiligen Organisationsform und den Mechanismen der Wertschöpfung - die Grundlagen des Handelns sind aber robust.

Die Zusammenfassung der Aufgaben in einer eigenen, dem Management sehr nahe stehenden Abteilung ist die Regel. Hier wird das System definiert, welches für die Beschaffung von Zahlen, Daten und Fakten aus den produktiven Organisationseinheiten sorgt und diese nach geeigneter Aufbereitung und Aggregation dem Management als Zustandsinformationen zur Steuerung des Unternehmens zur Verfügung stellt. Es unterstützt das Management in der Zielfindung, Planung und Risikoabwägung. Getragen wird das Handeln von dem Selbstbewusstsein, das betriebswirtschaftliche Gewissen des Unternehmens darzustellen.

Dieser Zustand der Stabilität wird in den letzten Jahren punktuell gestört. Gerade in den innovativsten Unternehmen mit intensiver Produktentwicklung werden die Herstellungsprozesse zunehmend nach agilen Vorgehensmodellen ausgerichtet. Größter Treiber dieses Trends ist die Softwareentwicklungsbranche.

Nur die Spitze des Eisbergs

Die Herausforderung für das Controlling in der agilen Softwareentwicklung ist vielfältig. Planänderungen (auch kurzfristige) sind Teil des Vorgehensmodells. Die Klärung dessen, was Ergebnis eines Projekts ist, ist Teil des Projekts selbst. Die Steuerungsmechanismen sind neu, da die Verlagerung von Verantwortung in die Entwicklungsteams eine Abkehr von klassischen „command and control“-Strukturen nach sich zieht. Mögliche Lösungsansätze für diese Situation zielen darauf ab, eine Mediationsschicht zwischen der agilen Organisation und dem Unternehmensumfeld zu bilden, die die Ergebnisse der Entwicklungsorganisation in zentral interpretierbare KPIs übersetzt - sofern dies möglich ist.

Welchen Ansatz man auch bemüht - die Vergangenheit hat immer wieder gezeigt, dass die geschaffenen Schnittstellen nicht friktionsfrei sind. Der Begehr des klassisch operierenden Controllings nach langfristiger, robuster Planbarkeit erzeugt Spannungen in der Wechselwirkung mit der Softwareentwicklungsorganisation, die häufig aufgrund der internen Machtverhältnisse zur Auflösung der agilen Ansätze führen.

Mittlerweile erlebt man jedoch häufiger die gegenläufige Entwicklung: die agilen Managementprinzipien finden über die Softwareentwicklungsorganisation hinaus Anklang und erste Umsetzung - auch in anderen Kontexten als der Softwareentwicklung allein. Abschottungsstrategien sind damit nicht mehr möglich. Das etablierte Controlling muss sich der Herausforderung in neuer Weise stellen.

Das Menschenbild macht den Unterschied

Das moderne Controlling erkennt durchaus Organisationsform und Unternehmenskultur als Variablen an, die in der Bildung eines wirksamen Controlling-Systems Berücksichtigung finden müssen. Hier gibt es vielfältige Ansätze unterschiedlichen Szenarien gerecht zu werden, ohne dass Grundprinzipien in Frage gestellt werden müssten.

Es gibt jedoch eine immanente Größe, die unabhängig dieser Variablen fundamentbildend für die Ausprägung des heutigen Controllings wirkt: der Mensch - insbesondere der Manager - wird als sich stets bemühendes, aber letztlich nur begrenzt zu rationalem Denken befähigtes Individuum begriffen. Um ihn muss ein ausgefeiltes System der Fremdkontrolle aufgebaut werden, welches den Manager in seinen Entscheidungen mal unterstützt, mal reflektiert und ggf. sogar eingrenzt. Es fehlt an Vertrauen.

In agil geführten Organisationen ist dies anders: das Vertrauen in die einzelnen Mitarbeiter wird bewusst gestärkt und ihnen werden Entscheidungskompetenzen eingeräumt. Paradoxerweise wird hier dem Mitarbeiter mehr Vertrauen geschenkt als dies in der klassischen Controlling-Theorie gegenüber dem Management geschieht. Der Mensch wird als potenziell unternehmerisch und wirtschaftlich sinnvoll handelnd betrachtet - sowohl der Mitarbeiter als auch der Manager.

Von der Organisationsfunktion zur Kompetenz

Die Dimension der Veränderung durch dieses neue Menschenbild im Hinblick auf die heute üblichen Controlling-Strukturen ist fundamental. Mit dem Bild eines mündig handelnden Managers und Mitarbeiters vor Augen entwickelt sich Controlling von einer Organisationsfunktion eher zu einer Kompetenz, die im Unternehmen in der Breite vermittelt werden muss.

Unternehmerisches Denken und wirtschaftliches Gewissen ist kein Identifikationsmoment einer spezifischen Organisationseinheit mehr - wie dies im klassischen Controlling der Fall ist. Vielmehr handelt es sich um Eigenschaften, die die Mitarbeiter (und Manager) sich aneignen müssen. 

Eine Herausforderung für alle

Welche - ursprünglich dem Controlling zugeordneten - Kompetenzen gehen auf Mitarbeiter und Manager über? Jeder Verantwortung tragende Kollege muss in die Lage versetzt werden, das Gesamtsystem in seinen Kennzahlen zu verstehen, daraus Schlüsse zu ziehen und Konsequenzen umzusetzen. Mit steigender Managementebene ist der Blick auf diese Informationen zwangsläufig globaler - aber auch diese Perspektiven dürfen dem einfachen Mitarbeiter nicht verwehrt werden. Wissensmonopole jeglicher Art sind aufzulösen und alle sind zu befähigen, das Wissen auch richtig einordnen und verarbeiten zu können. Die Mitarbeiter tragen speziell in ihrem unmittelbaren Wirkungskreis - aber auch im Hinblick auf das Gesamtsystem - die Verantwortung für die Beibringung korrekter Informationen, deren Zusammenführung allen zur Steuerung dient. 

Was als dedizierte Controlling-Rolle bleibt sind dann Aufgaben wie Coaching und Training, Hilfestellung bei der Informationsaggregation und Kommunikation in die breite Unternehmensöffentlichkeit - mit dem Ziel der Befähigung einer Vielzahl von Mitarbeitern zu sinnvollem, wirtschaftlichen Handeln. Die Rolle des "Management-Beraters" entfällt weitestgehend - die Zielgruppe der Beratung wird vielmehr deutlich verbreitert. Koordinationsaufgaben - insbesondere bei der übergeordneten Unternehmensplanung - können wie zuvor bei einer Controlling-Rolle sinnvoll verortet werden.

Neben Prozessorientierung, Zahlenaffinität und wirtschaftlichen Kenntnissen werden nun in gleicher Gewichtung die Fähigkeit zur Wissensvermittlung, Empathie und Konfliktlösungskompetenzen vom Controller erwartet.

Die Herausbildung einer agil geführten Organisation bedeutet so letztlich für ein Controlling kein Bedeutungsverlust, wenn es der Entwicklung folgt. Tatsächlich sind die neuen Aufgaben, die es erwartet, anspruchsvoller als zuvor.

Mitarbeiterentwicklung: fachliches Hierarchiedenken oder Eigenverantwortung mit individueller Anerkennung?

Die sukzessive Umsetzung agiler Managementprinzipien in Softwareentwicklungsunternehmen fordert nicht nur dem Management massive Veränderungen ab. Auch seitens des Mitarbeiters ist ein Umdenken erforderlich. Dies betrifft in besonderer Weise – wenn auch nicht ausschließlich – den Blick auf den persönlichen Karrierepfad und die Art und Weise, wie dieser beschritten wird.

Junior – Experte – Senior – Architekt?

In klassischen Organisationen wird der Weiterentwicklung von Entwicklern in der Regel mit dem Ansatz begegnet, dass der Arbeitgeber vergleichbar einer hierarchischen Struktur fachliche Rangstufen definiert. Diese sind häufig mit der Gehaltsentwicklung verknüpft, ohne jedoch eine konkrete Veränderung der Rolle mit sich zu bringen. Klassifiziert und honoriert wird eine Persönlichkeitsentwicklung – wobei die Kriterien, wie die jeweils nächste Stufe erreicht wird, zumeist unklar sind.

Ist das Alter ein Kriterium? Oder die Anzahl der Projekte? Die Dauer der Unternehmenszugehörigkeit? Die Begleitung bestimmter Fortbildungen? Die Einschätzung der fachlichen Kompetenz durch den disziplinarischen Vorgesetzten? Bei der individuellen Entscheidung für einen Mitarbeiter, ob die nächste Stufe erreicht wurde, wirken vielfach mehrere dieser Aspekte mit - gewürzt von einer ordentlichen Portion Willkür.

Architekt. Und was nun?

Mit zunehmendem Alter, Erfahrung und langjähriger Betriebszugehörigkeit erreichen Softwareentwickler nahezu automatisch den obersten Rang: ob der nun „Senior Architect“, „Chief developer“ oder gar „Heavy chief“ heißt. Was passiert dann? Ist die Persönlichkeitsentwicklung mit 38 Jahren abgeschlossen? Oder ist die Voraussetzung für eine weitere Entwicklung des Mitarbeiters eine fachlich bzw. organisatorische Veränderung – was letztlich heißen kann, dass er nicht mehr das tun kann, was ihm am meisten liegt.

Es ist offensichtlich: selbst in klassischen Organisationen ist dieses Entwicklungsmodell wenig überzeugend. Umso erstaunlicher ist seine große Verbreitung. In agilen Organisationen entsteht der Bruch bereits in der Konzeption: wieso sollte ich eine differenzierte, fachliche Hierarchie aufbauen, wenn ich mich auf der anderen Seite bemühe, organisatorische Hierarchiestrukturen zu nivellieren?

Mitarbeiter und Management sind ratlos

Mit der zunehmenden Etablierung agiler Managementansätze in der Organisation tritt das Problem offen zutage. Der Mitarbeiter wünscht sich einen Entwicklungspfad und ist typischerweise in der Denkweise verhaftet, die er von früher – oder aus anderen Unternehmen – kennt. Schulterklappe und Visitenkarte haben noch ihren Wert.

Der agile Manager steht dem hilflos gegenüber: er kann die fachlichen Fähigkeiten des Mitarbeiters nur bedingt bewerten, da er auch keine fachliche Führung übernimmt (die erfolgt im Team). Die Einführung von Hierarchiestufen innerhalb von agilen Entwicklungsteams wird als kontraproduktiv wahrgenommen. Darüber hinaus ist das Bild dessen, was einen guten Softwareentwickler ausmacht, in einer agilen Entwicklungsorganisation deutlich vielschichtiger als es sich gewohnterweise darstellt. In einem gut positionierten Team ist der immer fröhliche, stets motivierende, aber fachlich nur mittelmäßige Entwickler ein genauso wertvolles Mitglied wie der introvertierte Spezialist, der die schwierigsten Probleme wegräumt. Auf welcher Basis verteilt man da Ränge?

Weniger Kontrolle, mehr Verantwortung

Die Herausforderung besteht darin, einen Weg zu finden, der die Entwicklung heterogener Persönlichkeiten in einem prinzipiell rangfreien Umfeld unterstützt.

Wie bei vielen Teilaspekten agiler Transformation steht und fällt der Erfolg damit, im Management Kontrolle abzugeben und dem Mitarbeiter Verantwortung zu überlassen – der diese auch annehmen muss. Hierin verbirgt sich insbesondere auf Mitarbeiterseite die maßgebliche Leistung des Umdenkens: es liegt an ihm eigene Ziele zu entwickeln, sowohl mittelfristig als auch langfristig. Unterstützt wird der Mitarbeiter hierbei durch sein Team, welches - bei genügender Reife - in der Lage sein sollte, ihm in den regelmäßigen Retrospektiven ein Bild zu vermitteln, wie seine jeweiligen Kompetenzen ausgeprägt sind.

Die Rolle des Managements besteht darin, den Mitarbeiter in diesem Prozess zu begleiten. Es reflektiert seine Ideen, hilft ihm sein Selbstbild mit den äußeren Wahrnehmungen in Einklang zu bringen und unterstützt ihn bei der Ableitung der nächsten Schritte. Angereichert wird dies durch richtungsweisende Impulse fundierend auf der technischen und strategischen Ausrichtung des Unternehmens und daraus abgeleiteten, unmittelbaren Entwicklungsangeboten.

Individuelle Weiterbildung einfordern

Die zentralen Angebote sind ein Mittel des Managements, die Mitarbeiter zu aktivieren. Dadurch werden sie aber nicht der Verantwortung enthoben, selber initiativ zu werden: es gilt grundsätzlich aus Sicht des Mitarbeiters das Pull-Prinzip. Vorgekaute Fortbildungsprogramme, definierte, fachliche Karrierepfade mit Entwicklungsstufen, die nach Abschluss bestimmter Zertifizierungen zu neuen Rangstufen führen, sind explizit nicht Bestandteil des Vorgehens. Wichtig ist allein, dass der Mitarbeiter für sich erkennt, wo seine individuellen Stärken und Schwächen liegen. Er muss den Eigenwillen mitbringen, seine Stärken zu entwickeln und Strategien zu erarbeiten, einen geeigneten Umgang mit seinen Schwächen zu finden oder diese mittel- bis langfristig zu relativieren.

Vielfalt ermöglichen

Die entstehenden Weiterentwicklungsmöglichkeiten sind vielfältig. Sie basieren auf einer Gesamtreflektion des Könnens und Vermögens des Mitarbeiters und beschränken sich nicht allein auf seinen fachlichen Fokus. So kann das Ziel von individuellen Weiterentwicklungsangeboten auch darin bestehen, die Präsentationsfähigkeit zu stärken, die Fähigkeit zu entwickeln, qualifiziertes Feedback zu geben oder Wissen zu vermitteln.

Es obliegt dem Management, hier die richtige Gratwanderung zwischen den Anliegen des Mitarbeiters zu finden, die eher seiner privaten Persönlichkeitsbildung dienen und denjenigen, die letztlich die Arbeit des Teams unterstützen und damit dem Unternehmen dienen. Der mögliche Raum ist jedoch weit gesteckt.

Was macht den Erfolg aus?

Für alle Seiten – Management, Team und Mitarbeiter – bleibt der Wunsch, die Summe der Bemühungen langfristig im Blick zu behalten. Dies kann in einfacher Weise durch die Dokumentation konkreter Fortbildungs- und Coachingaktivitäten erfolgen. Die Auseinandersetzung zwischen Mitarbeiter und Manager im Hinblick auf getroffene Maßnahmen und erzielten Wirkungen ist dann steter Bestandteil der weiteren Personalentwicklung.

Häufig stellt dies aber gerade die Mitarbeiter nicht abschließend zufrieden. Es besteht das verständliche Bedürfnis, nicht nur eine Maßnahmendokumentation in Händen zu halten, sondern auch eine Dokumentation der persönlichen Erfolge.

An diesem Punkt könnten Führungskräfte wieder auf die eindimensionale Betrachtungsweise „Junior – Senior – Architekt“ zurückfallen, in dem sie den Versuch unternehmen, die unterschiedlichsten Aktivitäten in Themenblöcke zu fassen und die Titelvergabe nach „Zielerreichungsgraden“ in den jeweiligen Kontexten zu richten. Damit würden sie das Vorgehen jedoch ad absurdum führen: Die mühsam geschaffenen Voraussetzungen zur Abbildung von Individualität und Vielfalt gehen neuerlich verloren und wir stoßen wieder auf die Endlichkeit des Konzepts im Hinblick auf die Dokumentation der persönlichen Weiterentwicklung.

Viel besser ist es hier, die tatsächlichen Erfolge, die durch die Weiterentwicklung erzielt werden, als solche zu feiern. Ein Mitarbeiter, der zuvor Schwierigkeiten hatte, vor unbekannten Menschen die Stimme zu erheben und nun seinen ersten Vortrag auf einer Konferenz hält, hat einen nennenswerten Erfolg erzielt. Dieser sollte erwähnt und zumindest symbolisch individuell belohnt werden. Stellt der Mitarbeiter fest, dass ihm die Vortragstätigkeit sogar richtig Spaß macht und wiederholt sein Engagement auf unterschiedlichen Konferenzformaten, so ist auch das ein guter Grund für eine besondere Auszeichnung.

Bei der Bewertung des Erfolgs spielt natürlich – davon kann sich niemand lösen – die persönliche Berufserfahrung eine Rolle. Diese Dimension bleibt, sofern sie nicht an Jahren der Berufserfahrung oder Ähnlichem festgemacht wird, zwangsläufig subjektiv.

Von Spielen lernen: Neue Entwicklungen im Badge-System

Die individuelle Würdigung gelingt durch die Einführung eines differenzierten Systems von kontextabhängigen „Abzeichen“ (oder auch als Anglizismus „Badges“), die Mitarbeiter unter bestimmten Rahmenbedingungen gewinnen können, die unternehmensöffentlich sind und auch Niederschlag in den Personalinformationen bis hin zum Arbeitszeugnis finden können.

So gelingt äußerst leicht die Abbildung von hochdifferenzierten Weiterentwicklungsmöglichkeiten weniger mit Blick auf die zugrundeliegenden Maßnahmen, sondern vielmehr mit dem Fokus auf den individuellen Erfolg, der aus den Maßnahmen resultiert. Dem Umfang des Badge-Systems sind faktisch keine Grenzen gesetzt, womit das Problem der „Endlichkeit“ des Weiterentwicklungskonzepts entfällt.

Bei einem durchdachten Design des Badge-Systems wird noch ein maßgeblicher, positiver Zusatzeffekt erzielt: es können dieselben Anreizmechanismen greifen, die auch Grundlage von herkömmlichen Spielkonzepten sind. So wirkt dann für den Mitarbeiter nicht mehr allein der abstrakte Gedanke an Weiterentwicklung motivierend, sondern darüber hinaus der Ehrgeiz, das nächste „Badge“ für sich zu gewinnen.

Sorgsam sollten Führungskräfte hier allerdings darauf achten, dass die persönliche Motivation des Mitarbeiters und das Badge-System nicht so interagieren, dass im Ergebnis der Mitarbeiter den Fokus auf seine Kerntätigkeit verliert. Hier ist wieder die Wechselwirkung mit Team und Management als regulierende Faktoren entscheidend.

Alle gewinnen

Gelingt es, den Mitarbeitern diesen Weg nahezubringen und gleichzeitig das Management zu befähigen, eine zielgerichtete Begleitung zu ermöglichen, gewinnen alle. Der Mitarbeiter lernt, selbst seine Ziele zu stecken und entwickelt sich ihnen entsprechend weiter. Er sieht dies dokumentiert und als Bestandteil seines Lebenslaufs. Über das Badge-System erfolgt eine Strukturierung des Erreichten mit dem Fokus auf den Erfolgen und weniger auf dem Abarbeiten von Lerninhalten.

Das Management verschiebt seinen Fokus von einer Führung der Mitarbeiterentwicklung auf ein Coaching des Mitarbeiters zu einem selbstgestaltenden, mündigen und vermehrt eigenmotivierten Kollegen. Damit stärkt der Mitarbeiter das Team und kann seinen Beitrag zum gemeinsamen Erfolg des Unternehmens erhöhen.

Und schließlich: fachliche Ränge gehören der Vergangenheit an.

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.

Hilf Dir selbst, dann hilft Dir Gott ...

1 ... 10 ... 100 Personentage Aufwand. Diesen Optionsraum erlebte ich als Standardantwort auf Umsetzungswünsche zur Anpassung der internen IT-Systeme bei verschiedenen Unternehmen. Kategorie "1" drückte großes Wohlwollen aus, Kategorie "10" signalisierte grundsätzliche Machbarkeit und überschaubare Widerstände. Kategorie "100" deutete an, dass man sich grundsätzlich gegen die Entwicklungswünsche zu sperren beabsichtigte. Ließ man an diesem Punkt nicht von seinem Anliegen ab, so wurde aus den 100 Personentagen Entwicklungsaufwand 1.000 und die IT-Leitung forderte einen Business Case für die Anpassungswünsche an. Eine Umsetzung wurde damit in der Regel erfolgreich abgewendet.

Die Ursachen für dieses hilflos und unkonstruktiv erscheinende Verhalten waren vielfältig. Der IT Bereich gehörte häufig zum Finanzressort und wurde im Sinne von kurzfristiger Kostenoptimierung und weniger von mittel- bis langfristiger Prozessoptimierung geführt. Ein qualifiziertes Anforderungsmanagement gegenüber den Fachbereichen existierte nicht: Es fehlte an qualifiziertem Personal und - was noch schlimmer ist - zugleich an der notwendigen Erkenntnis, dass dies erforderlich ist. Das IT-Management war durch Entrepreneure der IT-Frühzeit besetzt: Charaktere, die eher Goldgräbermentalität als Organisationskompetenz in sich bargen und deren technische und methodische Kompetenzen bei genauerer Betrachtung bereits vor Jahren als veraltet gegolten hätten. Diese fundamentale Inkompetenz stieß auf eine IT-Landschaft, die durch schnelles Wachstum, insbesondere auch anorganischer Natur, extrem diversifiziert war. 

Wen wundert es, dass in einem solchen Umfeld eine Schatten-IT gedieh? Mitarbeiter versuchten, in dem Gefühl im Stich gelassen worden zu sein, sich selber zu helfen. In der Regel führten diese Ansätze über komplexe Excel-Tabellen nicht hinaus. Dennoch bauten schnell komplexe Geschäftsprozesse darauf auf, wobei die Systematik in der Tiefe nur von wenigen Einzelkämpfern verstanden wurde. Hieraus entstand im Verein mit minimaler Skalierbarkeit ein echtes unternehmerisches Risiko, welches dann - im Prinzip zu Recht aber im Hinblick auf die Ursachen eher paradoxerweise - von der internen IT angeprangert wurde.

Ich spreche von Vorgängen, die in meiner Erfahrung z.T. zehn Jahre zurück liegen. Haben sich die Zeiten seit dem maßgeblich geändert? Dem Augenschein nach ja, da die Technologieentwicklung und die methodischen Ansätze in der Softwareentwicklung riesige Fortschritte verzeichnen konnten. Die Organisationen hinken dem jedoch dramatisch hinterher. Wem wird heutzutage in der Mehrzahl der Unternehmen zugetraut, das eigene Geschäftsmodell auf die nächste Ebene der Digitalisierung zu heben? In der Regel nicht der institutionalisierten Bestands-IT, die seit Jahren an der Vereinfachung der internen Abläufe - mit mehr oder minder großem Erfolg - arbeitet. Vielmehr versuchen gerade die großen Unternehmen hierfür separate und neue Teilorganisationen ins Leben zu rufen, die eine möglichst geringe Überschneidung mit den Bestandsinstitutionen aufweisen. Die Gründe hierfür dürften - von Unternehmen zu Unternehmen in Nuancen variierend - jedoch im Kern dieselben sein, die in der Vergangenheit zu meiner regelhaften Wahrnehmung der geringen Leistungsfähigkeit interner IT-Organisationen führte.

Um diesem Problem Herr zu werden gibt es zwei mögliche Ansätze. Der erste liegt trivialerweise auf der Hand: Restrukturierung und Modernisierung der internen IT, um diese zeitgemäß und ggf. erstmals serviceorientiert aufzustellen. Auf die Herausforderungen dieses Weges möchte ich in der Folge nicht weiter eingehen.

Gerade für mittelständische Unternehmen eröffnen sich Alternativen, die dem gestandenen IT-Leiter bei erster Betrachtung Schauer des Entsetzens bescheren. Wie wäre es, wenn man die Schatten-IT aus ihrer Schmuddelecke hervorzieht und ebenso legitimiert wie professionalisiert? Ist das ein denkbarer Weg?

Dies ist es. In mehrerlei Hinsicht sind die Voraussetzungen für ein solches Vorgehen heutzutage gegeben. Erstens gibt es mittlerweile zahlreiche rapid development Umgebungen, die hinreichend mächtig sind, um durchaus auch komplexe fachliche Anwendungen flexibel abzubilden (Microsoft Access, Filemaker, caspio, oracle APEX, ninox, etc.). 

Zweitens hat sich die mittlere Affinität der Mitarbeiter zu IT-basierten Medien massiv erhöht, so dass die Einstiegshürde in der Auseinandersetzung mit diesen Entwicklungsumgebungen viel niedriger ist als früher. Zu guter letzt bieten mittlerweile bewährte, agile Vorgehensmodelle in der Softwareentwicklung ein Grundgerüst, welches bei richtiger Anwendung der Denkweise der Fachabteilungen sehr entgegenkommt. Damit das Vorhaben gelingt, muss man allerdings einige wichtige Randbedingungen im Blick behalten:

• Die Mitarbeiter müssen eine Grundidee für die Formulierung und Verarbeitung von Anforderungen gewinnen. Wer diesen Weg geht wird feststellen, dass die Mitwirkungsbereitschaft der Fachabteilung an dieser Stelle viel ausgeprägter ist, wenn die Mitarbeiter die Entwicklung in eigener Hand halten.

• Pro Fachabteilung sind wenigstens zwei Kollegen erforderlich, die in der Lage sind, sich mit der erwählten rapid development Umgebung auseinanderzusetzen und in hinreichender Tiefe einzuarbeiten. Das Argument "dafür haben meine Leute keine Zeit" gilt nicht: sie werden beobachten, dass bei den Mitarbeitern verblüffende Kapzitätsreserven mobilisiert werden (bis hin zum privaten Engagement), sobald sie merken, dass sie die Chance erhalten, wirksam und selbstbestimmt ihren Arbeitsalltag zu optimieren.

• Die Schnittstellen zu relevanten Umsystemen müssen abgestimmt werden. Hier spielt wiederum der zentrale IT-Bereich eine wesentliche, teils beratende, teils mitwirkende Rolle.

• Die Betriebsfrage muss geklärt werden. Die Fachabteilung sollte in die Verantwortung für den reinen Applikationsbetrieb treten, Plattform- und Infrastrukturkomponenten müssen jedoch durch den zentralen IT-Bereich übernommen werden.

• Die Mitarbeiter des Fachbereichs müssen eine Vorstellung eines "minimum viable products" (MVP) entwickeln. Dies ist die Mindestentwicklung, die erforderlich ist, um erste Erleichterungen für ihre Fachbereichskollegen zu erzielen. Davon ausgehend kann in regelmäßigen Releasezyklen sukzessiv eine Anreicherung von Fachlichkeiten erfolgen. Dies ist elementar, da gerade unerfahrene Organisationen dazu neigen, ihre Erstentwicklung mit Feature-Wünschen so zu überfrachten, dass eine Fertigstellung in einem realistischen Zeitfenster nicht mehr möglich ist.

• Bei den Mitarbeitern muss das Bewusstsein geweckt werden, dass sie Anteil an geschäftskritischen Entwicklungen haben. Dem zur Folge ist Qualität ein maßgebliches Kriterium, welchem man nur durch eine hinreichende Testkultur - sei es automatisiert oder per Testfallkatalog - gerecht werden kann. 

• Es sollten feste Releasezyklen definiert werden. Diese sind im agilen Sinne zu begreifen und bedeuten keine zwingend langfristig vorgeschriebene Roadmap. Es gilt das Motto: "Kleinvieh macht auch Mist" - auch geringe Fortschritte sind es immer wert für alle Kollegen produktiv bereitgestellt zu werden.

• Bei zunehmender Reifung der Organisation kann dann auch über komplexere, nicht funktionale Anforderungen nachgedacht werden: Applikationssicherheit und Skalierbarkeit. Da der Anwenderkreis in erster Instanz klein ist, sollte dies jedoch stets vor dem Hintergrund des Istzustands und des sinnvoll Machbaren bewertet werden. Gerade für das Thema Sicherheit heißt dies stets: stellt der neue Zustand eine reale Verschlechterung gegenüber dem alten dar? Diese Frage dürfte in der Regel mit "Nein" beantwortet werden.

Dies erscheint auf den ersten Blick für ein mittelständisches Unternehmen ohne besondere IT-Affinität recht aufwändig und kompliziert zu sein. Doch nicht alle Rahmenbedingungen sind im ersten Schritt zu erfüllen und es bleibt stets die Möglichkeit, sich für einen begrenzten Zeitraum einen Berater mit entsprechenden Know-How an Bord zu holen. Hierbei ist jedoch sorgfältig darauf zu achten, dass derjenige nicht darauf abzielt alles selbst zu entwickeln sondern gemeinsam mit den Mitarbeitern tragfähige Strukturen für die Zukunft etabliert.

Geht man diesen Weg, so ist viel zu gewinnen. Ich erlebte, wie ein Mittelständler binnen zwei Jahren so über vier Fachabteilungen hinweg eine konsolidierte Systemlandschaft beginnend bei der Personalverwaltung  bis hin zum CRM aufbaute. 

Die Einstiegshürden und Startrisiken sind gering (wo nichts Funktionsfähiges ist, kann man auch nichts kaputt machen). Probieren Sie es aus!

Digitalisierung und warum wir darüber sprechen ...

Man muss kein sonderlich aufmerksamer Leser der Tagespresse sein, um seit ca. zwei Jahren sowohl im politischen, gesellschaftlichen als auch unternehmerischen Kontexten regelmäßig auf das beschworene Phänomen der "Digitalisierung" zu stoßen. Aufmerksam muss man allerdings gewesen sein, um zu bemerken, dass das Jahr 2015 seitens der Bundesregierung zum "Jahr der Digitalisierung" berufen wurde. Angesichts drängenderer Themen gerieten hieraus resultierende, mögliche Aktivitäten und Maßnahmen verständlicherweise ins Hintertreffen.

Gemeint ist mit der Kurzform "Digitalisierung" die Subsummierung aller Phänomene, die in Korrelation mit der Einführung computergestützter Technologien stehen: vom Smartphone über die 3d-Brille bis zum Roboter. Hierbei reicht die Spannweite der Betrachtungen von der Analyse gesellschaftlicher Veränderungen bis hin zu der Frage, wie unsere individuellen Denkprozesse durch die Nutzung moderner Informationstechnologie beeinflusst werden.

Die grundsätzliche Fragestellung ist ja an und für sich nichts Neues. Die Technologieentwicklung erzielt seit nunmehr 30 Jahren Breitenwirkung. Warum gerät das Thema gerade jetzt so in den gesellschaftlichen und politischen Fokus?   

Der mögliche Grund hierfür mag darin liegen, dass wir in eine neue Entwicklungsphase eingetreten sind. Diese Phase zeichnet sich dadurch aus, dass IT-gestützte Dienste vermehrt beginnen in offensiver Form bestehende Märkte und ihre großen Mitspieler wenigstens spürbar zu bedrängen, wenn nicht sogar in ihrer Existenz zu gefährden. Dies grenzt sich deutlich von dem noch anhaltenden, vertrauten Veränderungsprozessen ab, im Rahmen derer Informationstechnologie maßgeblich neue Märkte eröffnete, bestehende durch effizientere Prozessabbildungen veränderte und ggf. die Verdrängung kleinerer oder bereits angeschlagener Marktteilnehmer bewirkte. Nun geraten jedoch größere Unternehmen oder ganze Branchen, die eigentlich über effiziente Lobbyorganisationen verfügen, unter Druck. 

So ergeben sich Szenarien, in denen bestehender Bedarf  durch IT-gestützte Dienste in völlig neuer Weise gedeckt wird. Die gewählten Ansätze  der neuen Marktteilnehmer bewirken eine nachhaltige Veränderung der Wertschöpfungskette, wodurch die bestehenden Anbieter der Leistung von der Teilhabe am Markt aus strukturellen Gründen und Kostengründen faktisch ausgegrenzt werden. Uber im Transport- und airbnb im Hotelwesen stellen hierfür geeignete Beispiele dar: ihre Leistung besteht darin, die Dienstleistungserbingung zu sozialisieren und die Markteintrittshürde für den Einzelnen zu marginalisieren. Dies hat fatale Folgen für die bestehenden Marktteilnehmer: wie will sich ein Taxiunternehmen gegen dutzende, private Gelegenheitsfahrer zur Wehr setzen?

In einem anderen - weniger disruptiven - Szenario geht es  nicht mehr um IT-Nutzung zur Prozessoptimierung oder als Basis eigenständiger, neuer Geschäftsmodelle. Es zeichnet sich vielmehr ab, dass bekannte, zunächst IT-fern erscheinende Produktwelten durch eine intelligente IT-Nutzung neue Wertigkeit erlangen.  Die Leistung wird sozusagen hybrid: ein Produkt aus der klassischen Welt wird durch IT-Leistungen veredelt - so weit, dass die durch IT-Leistung getragenen Eigenschaften für den Verbraucher zunehmend die Wertigkeit des Produkts definieren.

Ein Beispiel hierfür: Sowohl google als auch Apple liebäugeln mit dem Bau eigener Automobile. Wann erreichen wir den Punkt, wo ein Auto maßgeblicher aus Software denn aus solider Mechanik besteht?  Beide Firmen sind extrem starke Marken, die bei einer solchen Entwicklung die Kraft haben die bekannten Automobilhersteller zu schlichten Zulieferern zu degradieren. 

Letztlich erleben wir neuerdings auch, dass in der Informationstechnologie und im Dienstleistungssegment tief verankerte und nachhaltig erfolgreiche Unternehmen (die gab es lange Zeit nicht ...) ihr Geschäftsmodell ausdehnen und so tradierte Geschäftsmodelle angreifen. 

Als Beispiel kann hier Amazon dienen. Das Unternehmen  baut aktuell sein Logistiknetz aus und übernimmt damit zukünftig in weiten Teilen selbst die Zustellungen aus dem eigenen Versandhandel. Dies ist an sich bereits ein spürbarer Effekt für das inländische Paketgeschäft der Post. Zunächst optimiert Amazon damit nur ihre Wertschöpfung. Im Folgeschritt liegt es für einen erfahrenen Plattformbetreiber wie Amazon nahe, das Logistiknetz auch als eigenes Produkt für Dritte zu öffnen. Wie das funktioniert, wurde bereits in der Vergangenheit durch die Öffnung der Amazon Rechenzentren in Form von an Cloud-Angeboten gezeigt. Was so für Amazon nur eine intelligent genutzte Teilleistung in der eigenen Herstellungskette ist, entwickelt sich für die Post zu einem ernstzunehmenden Wettbewerbsangebot.

Die Platzhirsche der "alten" Geschäftsmodelle haben in allen geschilderten Szenarien große Schwierigkeiten auf diesen externen Druck angemessen zu reagieren: es fehlt an nötigem IT-Know-How ebenso wie an einer geeigneten Unternehmenskultur, um den in der IT-Branche üblichen, rasanten Veränderungsprozessen stand halten zu können. 

So werden die Risikoszenarien zwar häufig hinreichend frühzeitig erkannt und durchaus wirksame Maßnahmen definiert. Die Umsetzung derer wird jedoch in den etablierten Unternehmensstrukturen erfolgreich boykottiert: IT als wirksamer Bestandteil des Geschäftsmodell mit einer Repräsentationskraft bis in die oberste Führungsebene erzeugt neue Strukturen und gefährdet so bestehende Pfründe und erweckt Neid. Darüber hinaus stellen abweichende Arbeitsweisen und Haltungen die gewohnten Steuerungsmechanismen querschnittlich wirkender Abteilungen in Frage. Nur wenigen kann man zutrauen, diesen Wandel erfolgreich zu meistern - und alle anderen werden mit einem schwierigen Schicksal, beginnend bei Bedeutungsschwund und endend bei Totalverlust leben müssen.

Die Politik weiß hier wenig beizutragen. Neulich durfte ich ein Interview mit Hannelore Kraft verfolgen, in der sie auswies, dass Nordrhein-Westfalen das erste Bundesland mit einer Digitalisierungsstrategie sei. Zum Inhalt wurde jedoch nur gesagt, dass man einen Plan habe, die breitbandige Internetversorgung der Bevölkerung zu verbessern. Das grundlegende Missverständnis ist offensichtlich: solche Aktivitäten sind wichtig und löblich - helfen aber im Wesentlichen denjenigen Marktteilnehmern, die Dienste anbieten, die diesen erhöhten Kapazitätsbedarf in den Privathaushalten auch erforderlich machen. Und das sind die Unternehmen, die bereits "digitalisiert" sind und die keine "Digitalisierung" mehr durchlaufen müssen.

Was ist der wahre Grund für die Aufmerksamkeit? Mein Fazit: die geringe Wandlungsfähigkeit vieler großer, deutscher Unternehmen gefährdet mittel- bis langfristig ihre Existenz. Die Politik erahnt diese Entwicklung bloß und lässt sich durch Schlagworte treiben. Die Melange aus beidem gefährdet den Wirtschaftsstandort, unseren gewohnten Wohlstand und damit letztlich die gesellschaftliche Stabilität.

Banken in der Sinnkrise

Folgt man den Außendarstellungen der maßgeblichsten deutschen Banken, so betrachten diese den deutschen Mittelstand und insbesondere mittelständische Unternehmen als Zielkunden. Mir wurde als Geschäftsführer einer solchen Unternehmung in der Vergangenheit das daraus resultierende, besondere Interesse der Banken häufiger zuteil. Diese Kontakte waren in der Regel konstruktiv und hilfreich.

Die grundsätzlichen Rahmenbedingungen haben sich in der Finanzbranche aber bekanntermaßen in den letzten Jahren deutlich verändert. Wo früher einfache Lösungen zumindest punktuell unbürokratisch herzustellen waren, kämpft man nun gegen anonyme Rating-Systeme in Kombination mit Vertriebsorganisationen, die jeglicher Entscheidungsfreiheit beraubt zu sein scheinen und häufig nicht in der Lage sind, die Entscheidungen der Marktfolge überhaupt zu erklären. Sicherheiten gelten nicht mehr als Sicherheiten und Faktoren wie Zahlungsmoral, Länge von Geschäftsbeziehungen und eine mittel- wie langfristig solide Geschäftsentwicklung spielen nur noch eine untergeordnete Rolle.

So fällt es den Geldhäusern in einem erdrückenden, zum Teil selbstauferlegten, zum Teil von Seiten Dritter aufoktroyiertem Risikomanagement zunehmend schwer, bestehende Geschäftsbeziehungen auszubauen oder Neukunden zu gewinnen.

Woher kommt ein solches Verhalten? Es folgt aus dem Reflex, mit dem die Banken auf die Krisen der jüngsten Vergangenheit reagieren. In erschütternder Offenheit reduzieren sich die Unternehmen in ihren strategischen Zielen auf einen reinen Überlebenskampf. So liest man hierzu an einschlägiger Stelle:

• "Wir investieren in unsere Ertragskraft"
• "Wir optimieren unsere Kapitalausstattung"
• "Wir setzen unser striktes Kostenmanagement fort"

als Eckpunkte der aktuellen Strategie. Es handelt sich nicht um einen Ausschnitt der Strategiesarstellung, sondern abschließend um alle strategischen Aussagen, die die Bank formuliert - verbrämt lediglich von erklärendem Text.

Eine andere deutsche Großbank äußert sich hierzu wie folgt:

• "Wir wollen <die Bank> einfacher und effizienter gestalten"
• "Wir wollen das Risikoprofil der Bank reduzieren"
• "Wir wollen besser kapitalisiert sein"

Also steht keineswegs solides Wachstum, Kundengewinnung, Kundenzufriedenheit oder gar die Wahrnahme eines volkswirtschaftlichen Auftrags im Zentrum des Agierens - sondern vielmehr Effizienzsteigerung, Kostenreduktion und Risikominimierung. Nach meinem Dafürhalten hat ein Unternehmen, dessen strategische Ziele sich dergestalt ausprägen, das Ende des Lebenszyklus seines tradierten Geschäftsmodells erreicht. 

Bestätigung findet diese These auch darin, dass die Geldhäuser offensichtlich nach neuen Dienstleistungsansätzen suchen. Jüngst wurde ich in diesem Zusammenhang mit folgendem Angebot konfrontiert: da unser Finanzierungswunsch durch die Bank abschlägig beurteilt wurde (Begründung: unverständlich, siehe oben) wartete sie nach vier Monaten Bedenkzeit mit einem Alternativvorschlag auf. Man könne den Zugang zu einem Marktplatz bieten, in dem die Bank direkte Finanzierungen zwischen wohlhabenden Finanziers und kapitalsuchenden Mittelständlern vermitteln würde. 

Dies erscheint zunächst ein plausibler Ansatz - bei näherer Betrachtung läuft es dem Betrachter jedoch kalt den Rücken runter. Warum macht die Bank einen solchen Vorschlag? Genau aus zwei Gründen:

1. Die Bank will selber kein Finanzierungsrisiko eingehen - auch nicht, wenn dies höhere Zinserträge bei entsprechend höherem Risiko verspricht.
2. Die Bank ist nicht in der Lage, ihren wohlhabenden Kunden attraktive Verzinsungen zu bieten.

Die beiden Gründe bedingen einander: wenn ich mich grundsätzlich verweigere, selber höhere Risiken in der Kapitalanlage einzugehen, nehme ich mir die Möglichkeit, meinen Anlegern attraktive Verzinsungen anzubieten. 

Mit diesem Handeln macht sich die Bank faktisch überflüssig. Sie sieht sich nicht mehr in der Lage eine eigene Risikobündelung durchzuführen und so ihre Kunden vor individuellen Anlagerisiken zu schützen, sondern reduziert sich selbst auf die Rolle eine Finanzmaklers.

Und man bedenke: wir sprechen hier nicht über Finanzierungen im Start-Up Bereich, sondern über solide, mittelständische Unternehmen. Diese Form des Risikomanagements lässt den Eindruck entstehen, dass die Finanzkrisen der letzten Jahre durch Fehlinvestitionen im deutschen Mittelstand verursacht worden wären.

Abschließend sein noch ein strategisches Ziel erwähnt, welches eines der führenden deutschen Geldhäuser als vierten strategischen Eckpfeiler ausweist:

• "Und schließlich wollen wir eine besser geführte Bank sein"

Dieser Punkt erregt meine besondere Aufmerksamkeit. Ich versuche mir die Situation vorzustellen, in der ich als Geschäftsführer eine Unternehmenspräsentation vor Vertretern einer Bank mit dem Ziel der Findung einer Finanzierungslösung halte. Und ich weise als einer meiner vier strategischen Ziele den hehren Wunsch einer besseren Unternehmensführung aus. Würde es mir auf dieser Basis gelingen, die Finanzierung zu realisieren? Oder würde mich die Bank höflich aber bestimmt vom Hof jagen?  Und was heisst das für mich im umgekehrten Fall - wenn mein Bankpartner dies freimütig zu einem seiner Ziele erhebt? Die Einschätzung möge der Leser selbst vornehmen ...

Jedes agile Team braucht einen Lead-Entwickler

Folgt man den Grundideen von Scrum, stellt sich das Entwicklungsteam als eine soziale, extrem leistungsfähige Struktur dar, in der es weder eine hierarchische noch eine laterale Führung gibt. Dies wird sogar als wesentlich betrachtet.

Führt man sich die Herkunft von Scrum vor Augen, so ist das auch nachvollziehbar. Jeff Sutherland, einer der Urväter von Scrum, stammt - wie er auch gerne in seinen Vorträgen betont - aus militärischer Schule. Die Teammitglieder in einem Scrum-Team werden, vergleichbar mit militärischen Eliteeinheiten, als erstklassig ausgebildete Spezialisten betrachtet, deren Kompetenzprofile so aufeinander abgestimmt sind, dass sie ideal miteinander harmonieren. Die Teammitglieder - ausschließlich aneinander gebunden durch die Vision dessen, was sie gemeinsam aufbauen sollen - stehen jeder für sich und wirken trotzdem konstruktiv und sich gegenseitig ergänzend auf das gemeinsame Ziel hin. Ohne Eitelkeiten, Grabenkämpfe, Frontenbildungen.
Aber lässt sich das in einem Unternehmen wirklich abbilden?

Die Antwort ist ganz eindeutig: Nein.

Wenn die Entwicklungsorganisation eine Größe von ein bis zwei dutzend Mitarbeiter nicht überschreitet und das Wachstum der Organisation bis zu dieser Grenze langsam und kontinuierlich war, ist es möglich, dass die Teammitglieder sich durch einen handverlesenen, zentralisierten Auswahlprozess noch auf einem relativ homogenen Kompetenzstand und einem vergleichbaren Verständnis von der Kultur des Unternehmens - insbesondere im Hinblick auf die Frage, wie man sich agile Softwareentwicklung vorstellt - bewegen. Aber es tritt zwangsläufig der kritische Punkt ein, an dem sich Heterogenität in die Mitarbeiterschaft einschleicht.

Setzt man nun Teams zusammen, muss man unterschiedlichste Charaktere einbinden - denn nicht jeder Softwareentwickler stellt sich Gesinnungstäter für die Vision des Produkts heraus. Es gibt, an sich wenig überraschend, punktuell wenig motivierte Mitarbeiter, Mitläufer, fleißige Arbeiter, mehr oder weniger fachlich gefestigte Kollegen, kreative, aber unstrukturierte Spezialisten. Die Liste lässt sich nahezu beliebig fortsetzen. Softwareentwickler zu sein setzt bestimmte Dispositionen voraus, führt aber nicht zu einer Normierung der charakterlichen Eigenschaften.

Die besonderen Dispositionen von Softwareentwicklern überdecken sich auch im allgemeinen Fall nicht vollständig mit den Anforderungen, die an sie in einem agilen Team gestellt werden.
Hier muss der Softwareentwickler fachlich breit aufgestellt sein (über die eigentlichen Softwareentwicklung hinaus z.B. im Hinblick auf automatisiertes Testen und Deployment), er muss kommunikativ sein, er muss Kompromissbereitschaft zeigen, Kritikfähigkeit besitzen, seine Ergebnisse darstellen, kundenzentriert denken (in Abgrenzung zu einer Technikzentrierung) und Eigenverantwortung übernehmen. Die Anforderungen sind extrem hoch und kaum durch die Mehrheit aller Mitarbeiter abzudecken.

Einen Fundus an Entwicklern, die diesem Idealbild entsprechen, darf ich also nicht erwarten. Wie kann ich dann aber ein erfolgreiches agiles Team bilden?

Wenn ich das Ideal mit der Realität in der Teambildung vergleiche, so ist es wie bei dem Computerspiel Tetris: Ich habe als herunterfallende Steine nur homogene, rechteckige Blöcke (meine perfekten Softwareentwickler) zur Verfügung. Dann ist es einfach meine Zielstruktur (das erfolgreiche Team) zu bilden. In der Realität sind es jedoch vielfältig geformte Elemente (die real existierenden Softwareentwickler), die zu meiner Zielstruktur kombiniert werden müssen. Und die Erfahrung zeigt - auch bei Tetris: Manche Elemente sind flexibler kombinierbar als andere und finden sich nahezu zwangsläufig als Teilelement in jeder Zielstruktur wieder.

Kehrt man von diesem Bild zurück in die Realität, gibt es eine Entsprechung zu dem Element, welches flexibler kombinierbar ist als die anderen und sich in nahezu jeder (erfolgreichen) Zielstruktur wiederfindet: dies ist der Lead-Entwickler. Was zeichnet ihn aus, wodurch gewinnt er den hohen Passgrad?

Der Lead-Entwickler ist in der Lage, aus der Diversität des Teams Kreativität erwachsen zu lassen. Er gibt ziellosen Diskussionen eine Richtung, er ist kommunikatives Vorbild, er verfügt über eine höhere, intrinsische Motivation. Er bildet sich permanent fort und hat so auch ein hohes fachliches Ansehen im Team. Junge Entwickler orientieren sich am Lead-Entwickler und profitieren von seinem Wissen. Finale Entscheidungen über Architektur und Vorgehen fallen in letzter Instanz ihm zu - nicht weil er deklariert, sondern weil er am Ende Verantwortung übernimmt. Gleichzeitig akzeptiert er das Spezialistentum der anderen Teammitglieder und bindet es erfolgreich zur Erreichung des gemeinsamen Ziels ein.

Aber warum ist er so wichtig für ein erfolgreiches Team? Dies erklärt sich durch Abgrenzung: fehlt ein solcher Charakter, verliert das Team an Dynamik. Diskussionen werden nicht abschließend geführt, Entscheidungen fälschlicherweise nach außen - als Impediment zum Scrum Master -delegiert. Die Fortschrittsgeschwindigkeit bleibt niedrig und es ist sichergestellt, dass technologisch und methodisch keine neuen Wege gesucht werden, die die Zielerreichung womöglich früher und effizienter ermöglichten. Und wenn dies doch der Fall sein sollte, besteht die Gefahr, dass der Treiber eher der „Coolness“-Faktor der neuen Technologie und weniger das Selbstvertrauen im Umgang damit ist.

Auch wenn sich in einem solchen Team eine Hackordnung ausbildet, bei der von außen der Eindruck entstehen könnte, dass so etwas wie ein Lead-Entwickler das Heft in die Hand genommen hat, so wird dieses Bild eher durch größere Extraversion einzelner hervorgerufen, als durch echte, laterale Führungskompetenz. Im Ergebnis reagieren die anderen Teammitglieder hierauf mit inneren Widerständen, was zu Spannungen innerhalb des Teams führt und damit die Fortschrittsgeschwindigkeit zusätzlich reduziert.

So gelingt es also, die Zusammensetzung eines leistungsstarken, agilen Team mit real existierenden Menschen: man achte auf die Zusammensetzung und füge immer einen Lead-Entwickler hinzu! Damit ist ein wichtiger Baustein für den Erfolg des Teams bereits gelegt.