key2success

Digitale Kultur

Unsichtbarer Erfolgsfaktor

ca. 16 Min. Zeitbedarf

Neben den offensichtlichen Unterschieden, die sich in der Struktur (s. Digital Organization) oder dem Einsatz von Technologie niederschlagen, gehören auch einige weniger sichtbare Eigenschaften, die sich bei erfolgreichen Digitalunternehmen finden. Dieser Abschnitt fokussiert die nicht auf den ersten Blick erkennbaren Unterschiede – die kulturellen Aspekte, die nachhaltig nur durch das Senior-Management geprägt werden können.

Gründer- vs. Corporate-Mentalität

Ein Unternehmer riskiert etwas. Er organisiert die Dinge, damit etwas erfolgreich wird. Deshalb ist er mit Herzblut bei der Sache. Erfolg bedeutet überdurchschnittlichen Lohn, Misserfolg im Idealfall ein paar verlorene Jahre, im Regelfall eine belastete Zukunft. Eine Kerneigenschaft erfolgreicher Unternehmer ist es, sich selbst und das Erreichte zu reflektieren, in Frage zu stellen und stets weiter zu optimieren. Er gestaltet Ereignisse, beobachtet, wägt ab und korrigiert den Kurs, damit er sein Ziel erreicht. Dieser Regelkreis ist in Start-ups durch die unbedingte Nähe des Gründers zur operativen Basis sehr direkt. Aufgrund dieser Nähe kann ein Gründer erfolgreich sein Unternehmen schnell auf Veränderungen einstellen und gleichzeitig dieses den neuen Bedingungen anpassen. Eine unbedingte Fähigkeit, wenn man sich auf unbekanntem Terrain bewegt. Beim Militär sind die Einheiten für Sondereinsätze auch kleine, hochspezialisierte Teams und nicht ganze Armeen.

Eine Kerneigenschaft erfolgreicher Unternehmer ist es, sich selbst und das Erreichte zu reflektieren, in Frage zu stellen und stets weiter zu optimieren.

Mit dem Wachstum eines jeden Unternehmens wächst auch der Abstand der treibenden Kraft, dem Unternehmer, zu der operativen Basis. Zwischenschichten werden erforderlich, um die Komplexität zu beherrschen. Die zusätzlichen Ebenen erweitern den Regelkreis. Der Regler wirkt nicht mehr direkt auf die Regelstrecke, sondern erreicht nur noch die Zwischenregler. Inwieweit Informationen in dieser Gestaltung ungefiltert von unten nach oben und umgekehrt fließen und ob der Regler noch die Komplexität hinreichend durchsteigt, um überhaupt sinnvoll regeln zu können, sind typische Gestaltungsherausforderungen jeder wachsenden Organisation.

Im Normalfall erzeugt der Unternehmer funktionale Subsysteme, die er mit weniger Aufmerksamkeit bedenken muss, da er sie durch Rahmenvorgaben an weniger involvierte Führungskräfte zur Steuerung abgeben kann. Das spiegelt sich in der Vergütung dieser Führungskräfte wider: sie erhalten einen Lohn, ihr Wohl und Wehe ist nicht mehr direkt an den Unternehmenserfolg gebunden. Zielsetzung der ersten und zweiten Generation von Managern ist es sogar oft, das Geschaffene zu bewahren und zu stabilisieren, anstelle es weiter in Frage zu stellen oder es im Sinne der Anti-Fragilität (2) konstruktiv zu zerstören und zu erneuern.

Je größer das Unternehmen wird, desto weniger erfolgsabhängige Vergütung (Motivation) findet sich in den unteren Führungsebenen. Teilweise haben die Einzelnen wenig Einfluss auf den Gesamterfolg und wollen daher gar nicht unbedingt so abhängig vom Gesamterfolg partizipieren. Meist ist aber auch gar nicht die Möglichkeit vorgesehen. Daher setzen sich in diesen Strukturen andere Gesetzmäßigkeiten durch: Wie lässt sich die eigene Position verbessern? Wie lässt sich der eigene Einfluss erweitern? Welche Kandidaten gibt es noch, die auf dem Weg zu mehr Einfluss von Bedeutung sind? Persönliche Motive können die betrieblichen übersteuern. Und hier beginnt der Culture-Clash, den Unternehmer-Persönlichkeiten nicht lange mitgehen. Typische Ausprägungen dieser Systematik schlagen sich in folgenden, gründerfeindlichen Verhaltensnormen nieder:

  • Career over customer

    Bei dieser Einstellung stehen die eigenen Ambitionen im Mittelpunkt des Handelns, nicht die Bedürfnisse der Kunden. Ob es dabei um Bequemlichkeit oder den nächsten Karriereschritt geht, hängt von der individuellen Ausprägung ab. Auf Gründer wirken sie gleichermaßen abschreckend.
  • Not invented here

    Dem Not-invented here- Verhalten liegt zugrunde, dass weder einem Gleichgestellten ein Erfolg gegönnt – er steht ja dann in besserem Licht – noch eine Innovation von außen aufgenommenwird. Zum einen wäre das Gewohnte zu ändern, zum anderen könnte die Frage aufkommen, warum das nicht sowieso schon so gemacht wurde.
  • Cover my ass
    Fehler sind keine Option. Hier wird schöngeredet und es werden hundert Gründe bemüht, weshalb etwas nicht so funktioniert, wie geplant. Zudem wird keine Entscheidung getroffen. Alles wird nachgefragt und mehrfach abgesichert und mit allen diskutiert.

Diese Symptome sind glücklicherweise nicht die Regel! Für Unternehmen, in denen sich Anzeichen dieser Ausprägungen finden, ist der Weg zum Innovationstreiber noch ein Stückchen weiter als in Unternehmen, die diese Hemmschwellen schon überwunden haben. In solchen Fällen bietet es sich an, erst einmal die Arbeitskultur zu reparieren, bevor zusätzliche Komplexität durch innovative Ansätze erfolgreiche gemeistert werden kann. Tatsächlich ist es in so kaputten Arbeitskulturen keine Seltenheit, dass neue Ansätze nicht nur blockiert, sondern sogar aktiv sabotiert werden, um Erfolge einzelner zu verhindern.

Ich empfehle, neue Vorhaben stets als Speedboats neben dem großen Tanker zu starten!

Diese Phänomene sollten dringend beachtet werden, wenn neue Modelle erdacht und gestartet oder Akquisitionen von Startups eingegliedert werden. Wir empfehlen immer, neue Vorhaben als Speedboats neben dem Tanker zu starten., da sie von der oben beschriebenen Agilität profitieren können. Das sollte für alle Bereiche gelten: Beschaffung, Staffing etc.

Neben diesen Führungsaspekten gibt es noch eine Reihe weiterer kultureller Elemente, die ein innovatives Unternehmen auszeichnen.

Beschränken von Verlusten - Fail Fast

Ein ganz zentraler Bestandteil erfolgreicher Kulturen ist das Prinzip „Fail Fast“. Dahinter steht das möglichst frühzeitige Erkennen von Fehlern. Grundgedanke dabei ist es, dass kritische Elemente möglichst vorgezogen werden, um frühzeitig die Ummöglichkeit oder Limitierungen eines Lösungskonzeptes zu erkennen und somit unnötige Investitionen zu vermeiden.

Dabei ist es egal, ob dieses Prinzip im Bereich der Softwareentwicklung, auf das gesamte Geschäftsmodell oder eine bestimmte Form der Kundengewinnung Anwendung findet. Der Fokus liegt bei der Gestaltung aller Maßnahmen und Investitionen darauf, die kritischen Aspekte – ob aus Sicht der technologischen Machbarkeit oder der Kundengewinnung – als erstes anzugehen.

Das entspricht nicht der (vielleicht) deutschen Vorliebe, zunächst ein paar Jahre im stillen Kämmerlein zu tüfteln, um dann mit der eierlegenden Wollmilchsau ins Licht zu treten. Vor allem, frühzeitig das Kunden-Feedback zu suchen, wird weder von Seiten der Anbieter noch von Seiten der Kunden in Deutschland praktiziert bzw. akzeptiert. Dennoch wird es das Modell der Zukunft sein, experimentell Geschäftserfolg zu generieren. Fast alle großen Errungenschaften haben sich auf diesem Weg entwickelt.

Der Fokus sollte auf der Bewältigung erfolgskritischer Aspekte liegen – sei es in der Technologie oder der Kundengewinnung!

Das Sicherheitsdenken deutscher Manager ist wirklich erstaunlich. Es gestaltet sich immer wieder äußerst schwierig, Partner zu finden, die Bereitschaft und Interesse haben, sich inhaltlich mit Dingen auseinanderzusetzen, die sich nicht sofort positiv auf den eigenen Revenue niederschlagen.

Dennoch gibt es hier und da Licht im Dunkel, mit wachsendem Druck auf dem Thema Digitalisierung bieten viele Unternehmen bereits Anlaufstellen, um solche Partnerschaften anzugehen. Leider verfügen diese auch nur bedingt über Möglichkeiten, sich in den operativen Einheiten durchzusetzen.

Fehler zulassen

Wer ein „Fail fast“ ermöglichen will, der muss auch dafür sorgen, dass „Fail“ eine valide, akzeptierte Option ist. Sprich: Beweist ein Manager, dass sein Vorhaben nicht zum Erfolg führen wird, bzw. zeigt die Indikationen auf, dass ein weiteres Investment nicht erfolgreich wäre, darf dies nicht als Schwäche oder Unvermögen ausgelegt werden. Dabei soll dies nicht als Entlastung für unkreatives Management verstanden werden. (“…’s geht halt net.”) Es soll jedoch ermutigen, gemeinsam Rahmenparameter für den Suchkorridor zu definieren, innerhalb derer ein wirtschaftlicher Erfolg erkennbar werden sollte. Das können einzelne technische oder vertriebliche Meilensteine sein.

Es liegt auf der Hand, dass alle lieber einen erfolgreichen Start des Vorhabens erleben wollen. Dennoch ist es auch elementar für einen wirtschaftlichen Erfolg, weniger erfolgreiche Vorhaben rechtzeitig zu beenden, anstelle sie auf Biegen und Brechen zu einem schön gerechneten Erfolg zu zwingen. Damit mag dann augenscheinlich die „Ehre“ der Führungskraft gerettet sein, jedoch wird es mittelfristig zu einer finanziellen Belastung

Fehlerkultur und Belohnungssystem entscheiden darüber, ob Fehlinvestitionen rechtzeitig kommuniziert werden

Beispiel Fehlerkultur

Beispielhaft hierfür ist m.E eine Kundensituation, der ich bei einem größeren, börsennotierten Unternehmen begegnet bin:

Ausgehend von der Überlegung, dass die Auslastung (=Umsatz) der Hardware (=Fixkosten) eines Cloud-Providers den EBIT des Providers direkt bestimmt, war es das Ziel des Vorhabens, Überkapazitäten von Cloud-Providern auf einer Art Marktplatz zu handeln. Aus Kundensicht sozusagen ein Multi-Cloud-Zugang mit wechselnden Providern zu günstigen Kosten. Gleichzeitig hätten die Provider den Vorteil, ungenutzte Kapazitäten noch zu Geld machen zu können, was den den Deckungsbeitrag verbessert.

Nun waren seinerzeit Docker und Kubernetes noch nicht so weit verbreitet wie heute und die Image-Formate der Hypervisoren nicht standardisiert. Somit war ein Umzug zwischen den Providern kein triviales Unterfangen, was wiederum die Handelsfähigkeit hemmte. Daher war es die Überlegung, eine Cloud Management-Infrastruktur bereitzustellen, welche über die Cloud-Provider hinweg zum Einsatz kommt, sodass ein Umzug inklusive der Meta-Informationen vergleichsweise einfach möglich wurde.

Ersten Gespräche mit den großen Cloud-Anbieter ergaben jedoch, dass zu dem Zeitpunkt der Cloud-Markt noch einige Jahre als Wachstumsgeschäft angesehen wurde. Man investierte mit dem Ziel, die Kapazitäten irgendwann in den kommenden Monaten bzw. Jahren auszulasten. Da waren Kapazitätsüberschüsse schlicht irrelevant, ja sogar Teil des Planes. Hinzu kam, dass das Thema Cloud-Security im Fokus aller Betrachter lag. In einem solchen Szenario die Sicherheit durch Öffnung eines Cloud-Segments für Management-Software von Dritten zu öffnen, erschien ohnehin als unrealistisch, da die Compliance-Prozesse des Anbieters durchbrochen würden.

Trotz dieser erheblichen Warnhinweise wurde das Projekt vorangetrieben. Man fokussierte sich auf die kleinere Anbieter, für welche die Bereitstellung expliziter Kapazitäten und die damit verbundene Anpassungen der Compliance-Regel keine so große Hürde darstellte. Sie betrachteten den Marktplatz als zusätzlichen Vertriebskanal und sahen daher keine Herausforderung darin, Kapazitäten explizit für den Marktplatz bereitzustellen.

Dieser strategische Schwenk reduzierte die möglichen Transaktionsvolumina und stellte den Marktplatz in Konkurrenz zu den großen Cloud-Anbietern, denen er eingangs helfen sollte. Zudem wurde durch die technologische Voraussetzung, Kapazitäten explizit für den Marktplatz bereitzustellen, die eigentliche Idee des Handels mit Überkapazitäten konterkariert. Das wiederum beeinflusste die Preisstruktur negativ.

Auch ein Abbruch kann eine interessante und wertvolle Erkenntnis sein, die es zu honorieren gilt

Es ist herausfordernd, den richtigen Zeitpunkt des Ausstiegs zu finden. Verfügt eine Organisation über eine offene Fehlerkultur, ist ein unbewusstes Ausweichen auf weichere, leichtgängigere, jedoch nicht zielführende Alternativen keine attraktive Option. Unternehmen, in denen bekannt ist, dass der Bote einer so tiefgreifenden Erkenntnis nicht geköpft wird, können immense Investitionen sparen. Grundsätzlich ist es daher hilfreich, das Belohnungssystem des betroffenen Projektleiters oder Geschäftsführers von vornherein auch die Option des Scheiterns einzuplanen. Beispielsweise lassen sich einige zentrale Voraussetzungen in den Zielen nennen, bei deren Wegfall eine Neuausrichtung der Initiative vorzuschlagen ist. Intelligente Mitarbeiter, werden diese Option beachten und wahrnehmen.

Agile Culture begreifen

Wird diese Fehlerkultur nun auch im Alltag des Managements gelebt, ist der Boden für die typischen Begleiter der „Digitalisierung“ bereitet: Agile Software-Entwicklung sowie Continuous Integration und Deployment. Beide Philosophien kommen auch mit Prozessen daher. Dennoch handelt es sich nicht nur um Vorgehensweisen, sondern auch Denkmuster.

Beispielsweise erfordert richtig agiles Vorgehen in der Software-Entwicklung Mut, Vertrauen, Disziplin und Kompetenz. Alle Prozessbeteiligten werden herausgefordert. Der Product Owner muss sich den Restriktionen der Umsetzung stellen. Einfach nur bunte Bildchen malen geht nicht mehr, da er die Fragen der Entwickler, woher denn diese oder jene Information herkommen soll, die er angezeigt haben will, auch zu beantworten hat. Die Entwickler müssen mit offenem Visier eine Schätzung abgeben, oder erklären, was ihnen für eine verlässliche Schätzung fehlt, und sich zu dieser Einschätzung auch bekennen. Abweichungen fallen sofort auf und es gibt einen Mechanismus zur Ursachenforschung und -bekämpfung (Retrospektive).

Gute Entwickler nehmen diese Herausforderung gerne an. Ein entsprechend offenes Umfeld gibt ihnen den Gestaltungsraum, den sie aufgrund ihrer Ausbildung und Kompetenzen auch benötigen, um sich sicher zu fühlen und ihre Kreativität einzubringen.

Ist Ihre Organsiation bereit für die digitale Transforation? Lesen Sie mehr über unser digitales Reifegradmodell

Die Erfahrung zeigt jedoch, dass diese Kultur des Vertrauens all zu oft durch traditionelles Management-Verhalten konterkariert wird. Weder verfügen die Product-Owner über ausreichend Budget und Entscheidungsvollmacht, noch akzeptieren die lenkenden Organe die selbstorganisierenden Teams hinreichend.
Oft will dennoch ein CEO-Office von einem IT-Verantwortlichen Liefertermine für die Bereitstellung bestimmter Dienste wissen. Eigentlich wäre diese Frage an den Product Owner zu richten. Stattdessen wird dem IT-Leiter die Zusage für einen Liefertermin abgerungen, da es ja auch seine Leute sind, die liefern sollen. Ursache ist die traditionelle Verankerung der Entwickler unter dem IT-Leiter. Den Leistungsumfang bestimmt jedoch ein Dritter (der PO). Die Zeitplanung kommt aus dem Team. Wie kann also eine verlässliche Aussage durch den IT-Leiter entstehen? Solche Planungsansätze und Zusagen erzeugen erhebliche Konflikte und fördern den Vertrauensverlust.

In einer agil orientierten Kultur würde die Verantwortung für den Umsatz und die Produkte – und damit für den Fortschritt der Produktentwicklung – bei dem Product-Owner liegen. Er könnte anhand des ihm aufgrund seiner Umsatzerwartung zur Verfügung stehenden Budgets überlegen, wieviele Teams er mit seiner Lösung beauftragen will. Und er hätte Verzögerungen in seinem Business Plan zu regulieren.

Das CEO-Office bräuchte sich nicht mehr um Liefertermine zu kümmern, sondern müsste nur den Umsatz, bzw. den Deckungsbeitrag des durch den PO vertretenen Produktes überwachen. Auch kann es eigentlich jedem im Unternehmen erlauben, einen Business Plan aufzustellen und wie ein Venture Capitalist, die Budgets der einzelnen POs genehmigen oder ablehnen. Die Kreativität und Motivation, die sich durch einen solchen Ansatz entfalten lässt, würde jede bestehende Struktur herausfordern und gleichzeitig gesund „erneuern“.

KVP ist nicht gleich Performance-Vergleich

Ein weiteres oft missverstandenes Konstrukt im agilen Kontext sind die Qualitätsmesszahlen (Story Points). Story Points werden von den Teams vergeben, um die Mächtigkeit einer vom PO angefertigten User Story zu beschreiben. Zur Bewertung haben sich allgemeinhin die Fibonacci-Zahlen eingebürgert, denkbar wäre jedoch auch jede andere Skala.

Teams schätzen vorgelegte User Stories und bewerten sie somit. In einem Zeitfenster (Sprint) arbeiten sie eine zugesicherte Menge an Stories ab. Sind die Teams in ihrer Struktur über längere Zeit konstant, lassen sich geschätzten Stories zur Roadmap-Charakterisierung heranziehen, da sich das Kontingent an Story Points pro Sprint im Regelfall angleichen wird. Das ist jedoch nicht zwingend, da sich die Zusammensetzungen ändern, die Güte der Anforderungsbeschreibungen oder das erforderliche Skillset mit jeder Story vollkommen variieren können.

Story Points sind keine vergleichbaren Leistungsmesszahlen sonder Team-individuelle Steuergrößen

Obwohl wir agile Software-Entwicklung nun seit mehr als 15 Jahren kennen, finden sich immer wieder Betriebsräte oder Manager, die aus diese Zahlen mehr machen wollen, als die individuelle Plangröße eines Teams. Unerfahrene Manager neigen dazu, die umgesetzten Story Points zwischen Teams zu vergleichen, Betriebsräte wollen Leistungsvergleiche verhindern.

Beide Sichtweisen sind ein erheblicher Irrtum! Da es kein Team-übergreifendes Verständnis für die anzunehmenden Werte gibt. Während Team A eine Story mit 5 bewertet, mag ein anderes Team die gleich Story mit 13 ansetzen. Das ist keine Qualitätsaussage, sondern eine Team-spezifische Einschätzung. Der Missbrauch der Zahlen für andere Zwecke als dem der Team-internen Steuerung unterminiert das Vertrauen und schadet somit dem Ansatz

No Estimates

Ebenfalls taucht auch immer wieder die Idee auf, auf Schätzungen komplett zu verzichten. Dieser Ansatz mag verlockend klingen und es gibt auch sinnvolle Anwendungsbereiche. Beispielsweise im Bereich technischer Schulden gibt es Dinge, die man nicht abschätzen kann, die jedoch erledigt werden müssen. Aus meiner Sicht wäre hier jedoch die Kommunikation der zugrundeliegenden Unsicherheit das probate Mittel, da das Schätzen an sich, die bewusste Auseinanderstezung mit der Anforderung und das Commitment des Teams auf einen Lieferzeitpunkt eine wertvolle Übung darstellen.

Respekt und Offenheit

Letztendlich inkorporiert das agile Vorgehen ein sehr mächtiges Instrument: die Retrospektive. Die Güte dieses dem Kontinuierlichen Verbesserungsprozess entlehnten Instrumentes hängt vor allem an der Art und Weise des Umgangs miteinander. Sind die Team-Mitglieder in der Lage respektvollen Umgang miteinander zu pflegen, entsteht das Vertrauen, einander zu kritisieren und dieser Kritik auch zuzuhören, bzw. sie anzunehmen. Der Boden für Verbesserungen ist bereitet. Im Idealfall entsteht daraus eine sich stets optimierende Kultur.

Werden jedoch die Informationen aus der Retrospektive missbraucht, landen im Vertrauen geäußerte Einschätzungen oder Kritik außerhalb des Teams oder verfügen die Team-Mitglieder nicht über den erforderlichen Umgangston miteinander, um vorsichtig geäußerte aber konkrete Verbesserungen bei den Team-Mitgliedern einzufordern, bzw. die Offenheit, solche Anregungen anzunehmen, dann kann sich die Konstruktion nicht etablieren.

Immer wieder erleben wir es, dass Vorgesetzte einen „friss oder stirb“-Tonfall an den Tag legen. Diese zunächst in breiter Front Anfang dieses Jahrtausends hippe, jedoch stets respektlose und menschenverachtende Kommunikationsform mag dem Benutzer ein Gefühl der Stärke vermitteln. Sie ist jedoch tödlich für ein respektvolles Klima.

Die Form des Umgangs miteinander wird durch das Management geprägt und entscheidet über den Erfolg der agilen Methoden.

Dieses wiederum ist der Nährboden für die sich selbstverstärkende Produktivitätssteigerung der agilen Methoden. Führungskräfte sollten daher alles daransetzen, respektvolle Kommunikation zu fördern, um das volle Potential der agilen Methoden auch wirklich zu erschließen. Denn auch im Kontext der Digitalen Transformation gibt der Chef den Ton an. Und agile Kulltur ist nicht nur in den Teams gefordert.

Was ist eigentlich "agile"?

Agile ist ein Modebegriff für die Gesamtheit von Methoden, die darauf ausgerichtet sind, den traditionell steifen Prozess der Software-Gestaltung (für die jüngeren Leser: Anforderung, Grob-Spezifikation, Fein-Spezifikation, Implementierung, Test, Abnahme, Inbetriebnahme) zu flexibilisieren. Ausgehend von den massiven Verfehlungen in den achtziger und neunziger Jahren, in denen jahrelange Entwicklungen in völlig unbrauchbaren Systemen endeten, hat man über Rapid-Prototyping, Rapid-Development, etc. Wege gesucht, das Kundenfeedback frühzeitig einzuholen, um insbesondere Verhaltensaspekte „Wie nutzt der Anwender die Software?”, “Wie kann er die Funktionalität sinnvoll einsetzen?“ aus Benutzersicht frühzeitig in die Systemgestaltung einfließen zu lassen.

Diese Bemühungen und unterschiedlichen Ansätze teilen große Funktionsblöcke in kleinere Häppchen und beteiligen den zukünftigen Benutzer bereits an Teilergebnissen. Somit erlauben sie ein frühzeitiges Erkennen von Fehlentwicklungen oder Optimierungspotenzialen. Das wiederum reduziert die „sunk costs“, also den Anteil Entwicklung, der in unbrauchbare Konzepte fließt. Dabei sind diese Prinzipien nicht auf Software beschränkt, mit Hilfe von bspw. 3D-Printing lassen sie sich auch in der modernen Fertigung anwenden.

Während frühe Ansätze wie das Rapid Protyping(1) die Vorteile vor allem in dem Austausch zwischen Entwickler und Benutzer sahen, wurde ihnen lange vorgeworfen, diesen Dialog unstrukturiert zu führen und Neuerungen bzw. neue Komplexität einzubauen, die nicht gewünscht wurden. Diese Kritik hat der SCRUM-Prozess exzellent aufgenommen, er definiert alle Rollen und deren Zusammenspiel im Kontext der Softwareentwicklung. Dabei werden mehrere ineinander verbundene Prinzipal-Agenten-Beziehungen geschaffen, die gleichzeitig die Prinzipien der Kontinuierlichen Verbesserung inkorporieren. Richtig angewendet, entsteht im SCRUM ein sich stetig optimierendes System, in dem alle Beteiligten innerhalb kurzer Zyklen zu Teilergebnissen geleitet werden. Findet der Prozess in einer hinreichend offenen und stabilen (Personalkontinuität) Umgebung statt, führt er typischerweise innerhalb von 8-12 Wochen zu erheblichen Produktivitätssteigerungen. Vorurteile und Informationshoheiten werden abgebaut, Vertrauen- und Team-Spirit aufgebaut.

Geschwindigkeit durch Automation

Ein weiteres, kulturelles Element sind die mit der DevOps-Philosophie verbundenen Folgen. Plan, Build, Run-Ansätze, wie sie u.a. in ITIL-orientierten Organisationen gepflegt werden, propagieren eine strikte Trennung von Entwicklung und Betrieb. Wohldefiniert, expliziert und nachvollziehbar für die Prüfung von außen, entwickelt für das Outsourcing von IT-Leistungen öffentlicher Auftraggeber hat sich ITIL den Weg in die meisten Unternehmen gebahnt. Damit einher geht entsteht ein hohes Maß an operativer Stabilität. Diese wird jedoch auf Kosten von Zeit und Flexibilität eingekauft.

Die DevOps-Philosophie ändert das Paradigma. Hier liegt die Verantwortung für die Lösung bei demjenigen, der sie entwickelt hat. Er hat sicherstellen, dass der von ihm zur Verfügung gestellte Service läuft. Und wenn der Service das mal nicht tut, ist er derjenige, der die Funktionalität wieder herzustellen hat. Die Annahme ist, dass die Verantwortung zu qualitativer Software und somit weniger Fehlerfällen führt. Das zentrale Konzept zur Erreichung dieses Zieles ist CI/CD.

Der Ansatz ist in Bereichen sinnvoll, die einer schnellen oder hochfrequenten Adaptions–notwendigkeit unterliegen. Dies sind in der Regel die am Markt differenzierenden Leistungen. Ein eingekauftes ERP-System ist in der Regel eher statisch und benötigt diese Reaktionsfähigkeit nicht so dringend. Das soll jedoch nicht heißen, dass diese Gestaltung sich dafür nicht eignet. Eine kundenbindende SaaS-Lösung wäre jedoch eher ein Kandidat, da mehr Anteil der Entwicklung in der eigenen Hand liegt.

Eine CI/CD-Automation stellt für sich selbst ein aufwändiges Gebiet dar. Diese Aufgabe ohne weitere Vorbereitung in jedes Scrum-Team zu kippen, wäre ein Fehler und würde die Arbeitsproduktivität für eine geraume Zeit erheblich reduzieren. Tendenziell sollte die Bereitstellung geeigneter CI/CD-Lösungen eine zentrale Service-Leistung darstellen, welche analog eines externen zu erbringenden Dienstes bewirtschaftet oder gar direkt zugekauft wird.

Was ist CI/CD?

Continuous Integration and Delivery (CI/CD) bezeichnet die Automation wesentlicher Teile des Software-Entwicklungsprozesses.

Nachdem Software-Code geschrieben und gebaut ist, muss er einer Reihe von Tests unterzogen werden. Das beginnt bei funktionalen Tests der einzelnen Funktion, geht über formale Prüfungen zu Strukturen und Sicherheit oder qualitative Fragen über die Compliance-Aspekte verwendeter Komponenten bis zu den Integrationstests (Zusammenspiel mit anderen Anwendungsteilen) sowie Last- und Performance-Tests. Alles dies zusammen kann recht aufwändig werden. Die Idee, diese Aufgaben zu automatisieren, bietet einen erheblichen Qualitätsvorteil (bspw. Regressionstests). Dieser Teil wird als Continuous Integration bezeichnet.

Neben dem automatisierten Bauen und Testen lässt sich die erfolgreich getestete Software auch gleich an den jeweiligen Einsatzort transportieren. Dies kann je nach Sicherheitsbedürfnis einweiteres Testsystem oder gar das finale Produktivsystem sein. Das automatische Ausbringen bezeichnet man als Continuous Delivery. Dieser Schritt kann wiederum durch unterschiedliche rechtliche Vorgaben reguliert sein.

Letzteres findet sich noch etwas seltner. Oft sitzt noch eine manuelle Freigabe zwischen CD-Ende und tatsächlichem Produktionseinsatz. Viele große Software-Anbieter aber vor allem SaaS-Anbieter leben diese Prozesse bereits seit längerem. Wer beispielsweise die Jira-Cloud-Lösung nutzt, kann sich sowohl von den Vor- als auch die Nachteilen dieses Konzeptes überzeugen.

Mit Hilfe eines CI/CD-Ansatzes lässt sich eine sehr hohe Adaptionsgeschwindigkeit bei gleichzeitig reduzierter Fehleranfälligkeit erreichen, da sich Änderungen theoretisch direkt nach der Implementierung auf einem gesicherten Pfad ausbringen lassen.

Elementar aus kultureller Perspektive ist jedoch die Neugestaltung der Verantwortung. Es ist ein erheblicher Unterschied, ob jemand Montag bis Freitag von 0800 bis vielleicht 1900 Uhr Software entwickelt oder ob er sich am Samstag um 2300 Uhr bereithalten muss, um einen Ausfall zu beheben. Das erfordert sowohl eine andere Bindung an das Unternehmen als auch andere Vergütungsmodelle und damit auch Arbeitsverträge.

Die Entscheidung für einen DevOps-Ansatz hat weitreichende Folgen bis hin zur Neugestaltung der Arbeitsverträge und Entscheidungsgewalt und sollte daher wohl überlegt erfolgen

Gleichzeitig sollte sich das Management vorab klar werden, welche Entscheidungsgewalt es in diesem Kontext delegieren möchte. Hier ein kleines Beispiel im Kontext von Infrastrukturentscheidungen:

Angenommen das Management hat ein Outsourcing-Partner gewählt. Dieser bietet zwar einen Managed Database Service, welcher jedoch nicht die Wiederherstellungszeiten der Datenbank bieten kann, die der zu entwickelnde Service benötigt. Darf der Entwickler nun zu einem anderen Anbieter wechseln? Oder muss der Auftraggeber (PO) die schlechteren Wiederherstellungszeiten akzeptieren?

Kultur als Erfolgsfator begreifen

Neben den aufgezeigten Aspekten gibt es noch eine Vielzahl weiterer, unternehmensindividueller Aspekte die den Erfolg bestimmen. Beispielsweise ist es uns aufgefallen, dass sich insbesondere Unternehmen aus dem Maschinenbau mit der anfänglichen Unvollkommenheit von Software-Lösungen schwertun. Die Vorstellung, eine Maschine nur zum Teil zu entwickeln und sukzessive während des Einsatzes am Kunden reifen zu lassen, widerspricht allem, was ein Maschinenbauer in seiner Ausbildung und seinem Arbeitsleben gelernt und erfahren hat!

Dieser Konflikt zwischen Erfahrungswissen und Vorgehen führt automatisch zunächst zur Ablehnung der Vorgehensweise. Oft erlaubt erst die positive Erfahrung, dass es anders auch funktionieren kann, eine Akzeptanz. Das ist nicht negativ zu sehen! Es ist eben eine andere Erfahrung, die auch ihre Berechtigung hat. Es schlicht wirtschaftlich unmöglich, tausenden Systemen im Feld einen neuen Stecker oder nachträglich einen zusätzlichen Arm einzubauen. Im Zuge eines Software-Updates ist es dagegen möglich, eine zusätzlich oder überarbeitete Funktion auszuliefern. Diese kulturellen Unterschiede gilt es zu identifizieren und zu adressieren.

EACG hat hierzu ein Kultur-Assessment entwickelt. Durch eine Reihe von Interviews und Workshops helfen wir Ihnen, den kulturellen Zustand Ihres Unternehmens zu identifizieren und Optimierungspotential zu erkennen. In der Folge lassen sich dadurch geeignete Maßnahmen für die Transformation der Kultur identifizieren.

Sind Sie sich klar über die kulturellen Unterschiede zwischen einer digitalen Organisation und ihrem Unternehmen?

Literaturverzeichnis

(1)