IT-Mitarbeitende im Spannungsfeld von Agilität, Cloud und DevOps

Inhalt

1. Einleitung
1.1. Ausgangslage
1.2. Fragestellung und Abgrenzung
1.3. Gliederung
1.4. Methodisches Vorgehen

2. Theoretische Abhandlung
2.1. Digitalisierung
2.1.1. Agilität in der IT-Organisation
2.1.2. Cloud als technologischer Treiber
2.1.3. DevOps in der IT-Organisation
2.1.4. Verknüpfung von Agilität, Cloud und DevOps
2.1.5. Good Practices
2.1.6. Spezifische Situation bei der Mobiliar
2.2. Bedürfnisse von Mitarbeitenden
2.2.1. Klassische Motivationstheorien und Neuroleadership
2.2.2. Das SCARF-Modell
2.3. Mögliche Spannungsfelder

3. Empirische Erhebung
3.1. Datenerhebung
3.2. Auswertung
3.3. Kriterien
3.4. Ergebnisse

4. Erkenntnisse und Handlungsempfehlungen

5. Fazit, Reflexion und Ausblick

6. Quellen
6.1. Literatur
6.2. Abbildungsverzeichnis
6.3. Interviews
6.4. Interne Dokumente

7. Anhang
7.1. Anhang mit zusätzlichen Abbildungen
7.2. Interview-Leitfaden
7.3. Interview-Protokolle
7.3.1. Interview mit Matthias Aerni
7.3.2. Interview mit Nicolas Bonfils
7.3.3. Interview mit Jasmin Fluri
7.3.4. Interview mit Gabriel Graf
7.3.5. Interview mit Anonym
7.3.6. Interview mit Hicham Khallouki
7.3.7. Interview mit Jeremy Singh
7.3.8. Interview mit Vasco Staffen
7.4. Kernaussagen der Interview-Protokolle

Abkürzungsverzeichnis

ART Agile Release Train

BFH Berner Fachhochschule

BfS Bundesamt für Statistik

CAPEX Capital expenditure

CEO Chief Executive Officer

CIO Chief Information Officer

CTO Chief Technology Officer

EHB Eidgenössische Hochschulinstitut für Berufsbildung

IT Informationstechnologie

NIST National Institute of Standards and Technology

NZZ Neue Zürcher Zeitung

OPEX Operational expenditure

PO Product Owner

PwC PricewaterhouseCoopers

RTE Release Train Engineer

SAFe Scaled Agile Framework

SECO Secrétariat d'État à l'économie

SM Scrum Master

ZHAW Zürcher Hochschule für Angewandte Wissenschaften

Management Summary

Die Digitalisierung stellt eine bedeutende technologische Veränderung dar. Unternehmen, die sich diesem Wandel aktiv stellen, sehen sich mit zahlreichen Parametern konfrontiert, die weitreichende Auswirkungen auf ihre Organisation haben. In vielen Organisationen laufen – meist parallel – digitale Transformationsinitiativen, welche bestehende Vorgehensweisen, Produktpaletten und Organisationsformen grundlegend verändern, um langfristig erfolgreich zu sein.

Die IT eines Unternehmens wird in diesem Prozess zu einem entscheidenden Faktor. Satya Nadella, CEO von Microsoft, drückt es so aus: "Jedes Unternehmen ist heute ein Softwareunternehmen. Während die IT früher die Geschäftsunterstützung oder bestenfalls ein Business Enabler war, wächst diese heute in die Rolle eines Business Driver hinein. Die damit verbundenen Anstrengungen betreffen die IT-Mitarbeiter eines Unternehmens in besonderem Maße, da sie in der Regel von einer meist mehrjährigen Implementierung von Agilität, Cloud und DevOps begleitet werden. Die vorliegende Arbeit schafft im ersten Teil des Theorieblocks einen kompakten Überblick über die wichtigsten Ausprägungen der digitalen Transformation.

Die IT-Mitarbeiter stehen bei technologischen und methodischen Innovationen an vorderster Front und sind damit sowohl als Konsumenten als auch als Produzenten betroffen. Die Erneuerungen erfolgen dabei zunehmend schneller, eine Entschleunigung ist derzeit nicht zu erwarten. Es stellt sich daher die Frage, wie sich die damit verbundenen vielfältigen Anforderungen auf die Arbeitskräfte auswirken werden. Hinter jeder Arbeitskraft stehen Menschen, so dass die Antworten auf die obige Frage am ehesten in der Psychologie zu finden sind. Motivationstheorien befassen sich zum Beispiel mit der Frage, warum und unter welchen Bedingungen Menschen bestimmte Tätigkeiten entwickeln und bestimmte Leistungen erbringen. Neben den klassischen Motivationstheorien (Maslow, ERG) haben in den letzten Jahren auch Theorien aus den Neurowissenschaften wie SCARF (Status, Certainty, Autonomy, Relatedness, Fairness) an Popularität gewonnen. Im Wesentlichen befassen sich all diese Theorien mit menschlichen Bedürfnissen.

Wenn diese Bedürfnisse mit den vielen Anforderungen der Digitalisierung in Konflikt geraten, können sogenannte Spannungsfelder entstehen. Diese Spannungsfelder schaden der Gesundheit der Mitarbeiter, z.B. durch eine Zunahme von Druck und Stress am Arbeitsplatz. Die Unternehmen sind deshalb gut beraten, auf diese Bereiche zu achten, denn der IT-Fachkräftemangel wird weiter zunehmen. Unternehmen, die diese Diskrepanz ernst nehmen, können sich von anderen Organisationen abgrenzen und sich so einen Wettbewerbsvorteil sichern.

Anhand des SCARF-Models werden die Spannungsfelder beschrieben, welche entstehen können, wenn die Digitalisierungsanforderungen im Widerspruch zu menschlichen Grundbedürfnissen stehen. Die aus der Literaturrecherche abgeleiteten Spannungsfelder sind: Arbeitsplatzsicherheit, viele Veränderungen, Aufstiegsmöglichkeiten und SAFe. Diese Themen wurden anhand einer empirischen Erhebung auf ihre Praxistauglichkeit geprüft. Dazu wurden insgesamt acht Experteninterviews mit IT-Mitarbeitenden aus den agilen Teams der Mobiliar durchgeführt. Dabei zeigte sich, dass die Arbeitsplatzsicherheit und die hohe Anzahl an Veränderungen bei den Befragten nicht als problematische Spannungen wahrgenommen werden. Hingegen belegen die Untersuchungen, dass durch flache Hierarchien im Bereich der Aufstiegsmöglichkeiten und bei der Implementierung von agilen Frameworks Handlungsbedarf besteht. Beide Punkte haben ihren Ursprung im Gebiet der Agilität. Es ist jedoch zu beachten, dass der Grundgedanke der Agilität nicht problematisch ist, da er ausnahmslos von allen Befragten unterstützt wurde. Es geht vielmehr um die gelebte Form von Agilität, die von den Befragten als verbesserungsbedürftig empfunden wird.

1. Einleitung

1.1. Ausgangslage

Digitalisierung der Versicherungsbranche

«Alle grossen schweizerischen Versicherungsgesellschaften setzen auf Digitalisierung», titelte die Handelszeitung Anfang des Jahres 2019 (Niklowitz, 2019). Laut einer Studie (EY, 2018) der Beratungsfirma EY könnten bis 2030 «[...] zwischen 30 % bis 70 % der derzeitigen Schweizer Anbieter aus dem Markt gedrängt, wenn sie ihre Geschäftsstrategien und -modelle nicht überdenken und innovativer werden.» Im selben Artikel wird darauf hingewiesen, dass sich die IT-Funktion «[...] grundlegend von einer peripheren Support-Funktion hin zu einer Kernkompetenz innerhalb der Unternehmen verändern» muss. Diese These hat branchenübergreifend Gültigkeit und ist bereits seit der Jahrtausendwende weltweit beobachtbar, wie das folgende Zitat aus dem Harvard Business Review (Gurbaxani, 2016) verdeutlicht: «[...] the current business environment requires all leaders to view their companies as software businesses — and think like software executives.»

Laut dieser Aussage ist eine Versicherung in Zukunft ein Technologieunternehmen mit einer entsprechenden Versicherungslizenz.

Welche digitalen Herausforderungen für die Versicherer dadurch entstehen, konkretisiert PwC in einer Publikation aus dem Jahr 2018 (Vgl. Abb. 1).

Abbildung 1: Fünf Thesen zum digitalen Versicherer der Zukunft

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an PwC, 2018, S. 4

Die von PwC aufgestellten Thesen sind immer noch aktuell und werden in Folge näher erläutert:

- Die agierende Kundschaft

Nach PwC (2018, S. 5-6) werden ab dem Jahr 2020 die Digital Natives zur wichtigsten Kundschaft der Versicherer gehören. Diese Generation sei eine komfortable Nutzung von Dienstleistungen und Produkten gewohnt und erwarte schnelle Prozesse und Reaktionen. Der Kontakt erfolge «rund um die Uhr und mehrkanalig (online, mobile, persönlich)» (S. 6). Die Rolle des beratenden Versicherungspersonals werde sich merklich ändern, weil die Kundschaft Versicherungen künftig aufgrund der sich selbst erarbeiteten Informationen abschliessen werden.

- Analysegetriebene Erkenntnisse

Gemäss PwC (2018, S. 7-8) verfügen Versicherungen über sehr grosse Datenmengen, welche jedoch ungenutzt sind. Der zukünftige Einsatz von Big-Data-Technologien, künstlicher Intelligenz, Cloud Computing oder Internet of Things werde neue Möglichkeiten zur Befriedigung von Kundenbedürfnissen schaffen.

- Ökosysteme

Laut PwC (2018, S. 10) geht es dabei darum, dass Versicherungen Allianzen mit Technologiepartnern ausserhalb der eigenen Branche eingehen, um damit gemeinsame digitale Netzwerke zu schaffen. Dadurch entstehen neue, integrierte und unternehmensübergreifende Dienstleistungen, welche die Kontaktpunkte und -frequenzen mit der Kundschaft verändern. Die Kundschaft soll in einem System alles finden, was sie für ihr jeweiliges Anliegen benötigt (Die Mobiliar, o. J.-b).

In Zusammenarbeit mit Insuretechs (Coopetition) entstehen im Idealfall neue Systeme (Maas, Wyss, & Steiner, 2018).

- Coopetition

PwC (2018, S. 12) empfiehlt den traditionellen Versicherungen, Partnerschaften mit Insuretechs einzugehen, anstatt diese zu bekämpfen. Dabei sollen zwei Welten vernetzt werden: Die «[…]Start-ups bringen agile Geschäftsmodelle und innovative Technologien», die Versicherungsunternehmen Erfahrung und finanzielle Ressourcen (Maas et al., 2018).

- 100 % Cloud

Dieser Aspekt bezeichnet die Weiterentwicklung bestehender Technologien und das Schaffen von Voraussetzungen zur Entstehung neuer disruptiver Technologien. Gemäss einer Analyse von Albisser & Rüttimann (2020) wurde die Cloud 2019 zum Must-have der Schweizer Finanz- und Versicherungsbranche.

Die vielfältigen Herausforderungen führen dazu, dass die Mitarbeitenden der Versicherungsbranche neue Kompetenzen benötigen (PwC, 2018). Zudem muss sich auch das Arbeitsumfeld ändern, ansonsten können die benötigten und neu gewonnen Mitarbeitenden nicht längerfristig gebunden werden. Des Weiteren muss auf das «empfindliche Gleichgewicht zwischen Unternehmen, Kultur und Mitarbeitern» (EY, 2018, S. 3) geachtet werden, da es ansonsten zu einer «Destabilisierung im Personalbereich» kommen könne. Ein Trend, der im Zusammenhang mit dem Wandel des Arbeitsumfeldes steht, ist laut HR Today (Wanzenried, 2018) das Diversity-Management. Mittels Diversity-Management strebt ein Unternehmen eine hohe Vielfalt der Mitarbeitenden (bezüglich Alter, Geschlecht, Nationalität etc.) an, um am Markt wettbewerbsfähiger agieren zu können. Die Digitalisierung beinhaltet demnach, nebst dem technologischen Wandel, auch eine Veränderung, welche direkt mit den Mitarbeitenden zu tun hat.

Agile Transformation

Die Neue Zürcher Zeitung beschreibt in einem Bericht (Müller, 2018), wie neue Wettbewerber im Zuge der Digitalisierung «quasi über Nacht» etablierte Unternehmungen angreifen. Kodak – resp. der Kodak-Effekt¹ (Finews, 2019) – ist ein bekanntes Beispiel für einen verpassten Wandel, welcher das Unternehmen als Konsequenz in die Insolvenz führte. Die NZZ (Roth, 2020) beschreibt ähnliche Szenarien auch für die hiesigen Finanzinstitute, da plötzlich neue Akteure, wie z. B. Revolut oder Grossunternehmen wie beispielsweise Apple und Amazon, mitmischen. Grosse und etablierte Unternehmen wie die UBS oder Credit Suisse müssen darauf schnell reagieren können, da «Anpassungsfähigkeit und Agilität» gefragt sind.

Die NZZ verweist auf eine Studie der Boston Consulting Group (BCG, 2017) laut der «eine agile Arbeitsweise der relativ bedeutendste Faktor, um den wirtschaftlichen Gesamterfolg eines Unternehmens zu steigern» ist.

Eine agile Arbeitsweise zeichnet sich durch flexible Planung und die Anwendung von agilen Methoden (wie z. B. Scrum) aus, welche ursprünglich aus dem Bereich der Softwareentwicklung stammen. Zudem erfordert agiles Arbeiten auch agile Führung, wie Beat Schori (Country Executive und Partner Schweiz bei Dr. Kraus & Partner) in einem Interview des Versicherungsmagazins betont (Leist, 2019).

Im Zusammenhang mit agiler Führung steht der Begriff «VUCA», welcher laut Handelszeitung (Clases, 2018) die «Herausforderungen für Organisationen in der digitalen Transformation» meint und «das unternehmerische Umfeld als volatil, unsicher, komplex und vieldeutig» skizziere. Bei der Agilität gehe es «[...] um die Beweglichkeit der Organisation selbst; damit also um die Beweglichkeit des Führungssystems eines Unternehmens sowie der Art und Weise, wie Kooperationen gegen innen und aussen gestaltet werden» (Clases, 2018).

Cloud als disruptive Technologie

Wie bereits erwähnt, ist die Cloud auch für Versicherungen strategisch wichtig. Die Cloud macht Unternehmen für das digitale Zeitalter fit. Der damit verbundene Wandel betrifft alle Ebenen eines Unternehmens: vom grundlegenden Geschäftsmodell des Unternehmens über die Herstellung und den Vertrieb des Produkts bis hin zur internen Zusammenarbeit der Mitarbeitenden (Frank, Schumacher, & Tamm, 2019, S. 6).

Die Cloud disruptiert die klassische Unternehmens-IT, indem sie Rechenleistung, Speicher, Netzwerk und faktisch alle weiteren IT-Komponenten für eine breite Nutzer-gruppe auf einfache Art und Weise verfügbar macht (Frank et al., 2019, S. 273-274). Diese Vereinfachung gelingt durch eine vollständige Automatisierung der Bestell- und Lieferprozesse. Sind in der klassischen IT noch manuelle Schritte und somit Menschen notwendig, erfolgen in der Cloud (Vgl. Abb. 2) alle kundenorientierten Prozesse automatisiert.

Abbildung 2: Cloud als Digitalisierung der IT

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Frank et al., 2019, S. 275

Dabei werden nicht nur Produkte und Prozesse digitalisiert, sondern auch ganze Organisationen, wodurch Services nicht mehr von Teams erarbeitet, sondern aus der Cloud bezogen werden. Mit der Cloud kann daher die IT eines Unternehmens digitalisiert werden.

Situation bei der Mobiliar

Die Mobiliar will ihre digitale Transformation beschleunigen und investiert seit 2019, zusätzlich zum bereits vorgesehen Projektportfolio, 250 Millionen Franken pro Jahr (Witschi, 2019). In einem Zeitungsinterview (Minetti, 2019) erklärt Markus Hongler (CEO der Mobiliar), warum diese Investitionen nötig sind: «Wir haben die Zahl der Informatiker innerhalb von neun Monaten von 450 auf 600 erhöht. Es geht in einem ersten Schritt um die Renovation unserer Kernapplikationen. Wir lösen zum Teil 20 Jahre alte Software durch unsere Neuentwicklungen ab. [...] Mit der neuen IT-Infrastruktur werden wir agiler sein. Wir sind dann in der Lage, Produkte schneller den Gegebenheiten am Markt anzupassen und noch besser auf Kundenbedürfnisse einzugehen.»

Für die Mobiliar (Mobiliar, 2019) geht es dabei hauptsächlich um die Beschleunigung der End-to-End-Digitalisierung: Ziel sind eine neue Produktgeneration sowie moderne digitale Kernprozesse und Kontaktpunkte für Kundschaft und Mitarbeitende.

1.2. Fragestellung und Abgrenzung

Mit der Digitalisierung gehen viele Veränderungen bezüglich der Anforderungen an die Mitarbeitenden der betroffenen Unternehmen einher. Die Masterarbeit soll aufzeigen, dass die IT-Mitarbeitenden in einem besonderen Mass von dauernden Veränderungen betroffen sind. Im Zentrum stehen dabei die Menschen und ihre Grundbedürfnisse.

Im Rahmen dieser Masterarbeit soll daher folgende Kernfrage geklärt werden:

Wo liegen bei IT-Mitarbeitenden allfällige Spannungsfelder zwischen den menschlichen Grundbedürfnissen und den Anforderungen der Digitalisierung?

Im Fokus stehen agile Teams der IT-Organisation der Mobiliar resp. deren Mitarbeitenden als Menschen. Aus diesem Grund ergeben sich in der Masterarbeit auch Schnittpunkte mit psychologischen Bereichen des Personalmanagements.²

Im Vordergrund stehen die Anforderungen der Digitalisierung, welche sich direkt auf die Mitarbeitenden auswirken. Technische und betriebswirtschaftliche Themen werden allenfalls eingeordnet – und wenn nötig für ein besseres Verständnis erklärt –, aber nicht vertieft behandelt.

1.3. Gliederung

Im ersten Kapitel wird der Einfluss der Digitalisierung auf die Versicherungsbranche inklusive der wichtigsten Ausprägungen aus Sicht einer internen IT-Organisation am Beispiel der Mobiliar erläutert. Daraus wird eine Kernfrage formuliert, welche im Rahmen dieser Masterthesis zu beantworten ist. Zudem wird das Forschungsdesign erklärt, welches aus Literaturrecherche und einer anschliessenden empirischen Erhebung besteht.

Im zweiten Kapitel erfolgt die theoretische Auseinandersetzung mit den drei prägendsten Strömungen der digitalen Transformation, die IT-Mitarbeitende betreffen; dabei handelt es sich um Agilität, Cloud und DevOps. Ferner wird erörtert, wie die Begriffe miteinander verknüpft sind. Ergänzend folgen zwei Beispiele aus der Praxis anhand von Unternehmungen, deren Digitalisierungsvorhaben schon weiter fortgeschritten sind als jene der Mitbewerber. In einem weiteren theoretischen Teil wird ein geeignetes Modell der menschlichen Grundbedürfnisse ermittelt, welches schliesslich den Digitalisierung-Anforderungen gegenübergestellt wird. Daraus werden schliesslich die möglichen Spannungsfelder abgeleitet.

Das dritte Kapitel beinhaltet die empirische Erhebung zur Situation der IT-Mitarbeitenden in den agilen Teams der Mobiliar. Es wird auf die Kernfrage der Studie eingegangen, die ausgewählte Datenerhebung wird dargestellt, die Erarbeitung des Interview-Leitfadens wird erklärt, die Methode zur Auswertung der Interviews wird erläutert und die Kriterien werden beurteilt. Anschliessend werden die Ergebnisse der geführten Interviews ausführlich dargelegt.

In Kapitel 4 werden die Erkenntnisse zusammengefasst, wodurch der Zustand der IT-Mitarbeitenden der Mobiliar aufgezeigt wird. Des Weiteren werden in diesem Kapitel auch Handlungsempfehlungen zur Operationalisierung in der Praxis gegeben.

In Kapitel 5 wird die Kernfrage der Masterarbeit beantwortet und ein Fazit gezogen, in dem auch Ausblicke auf weiterführenden Untersuchungsbedarf vorgenommen werden. Abschliessend erfolgt eine persönliche Reflexion des Autors zu Inhalt und Resultat der Thesis.

1.4. Methodisches Vorgehen

In diesem Kapitel wird die Methodik behandelt, welche dieser Arbeit zugrunde liegt und durch die die Forschungsfrage beantwortet wird.

In der Einleitung werden die drei wichtigsten Strömungen der Digitalisierungen für IT-Mitarbeitende benannt, nämlich Agilität, Cloud und DevOps (Vgl. Abb. 3). In der Arbeit werden die Auswirkungen der einzelnen Strömungen auf den Menschen aufgezeigt und den menschlichen Grundbedürfnissen gegenübergestellt. Diese Bedürfnisse werden mittels eines – im Rahmen dieser Arbeit zu definierenden – Modells abgebildet. Anhand der Gegenüberstellung sollen mögliche Spannungsfelder identifiziert und schliesslich mit Hilfe einer empirischen Erhebung analysiert werden. Für die bestätigten Spannungsfelder werden abschliessend Handlungsempfehlungen beschrieben.

Abbildung 3: Darstellung des methodischen Vorgehens

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung

2. Theoretische Abhandlung

2.1. Digitalisierung

2.1.1. Agilität in der IT-Organisation

Herkunft und Definition des Begriffes Agilität

Laut Prof. Dr. Stephan Fischer von der Hochschule Pforzheim (Fischer, 2016) ist Agilität «kein neues Thema, sondern existiere bereits seit fast 70 Jahren in unterschiedlichen Facetten und Ausprägungen».

Für diese Arbeit wird die Definition aus dem Gabler Wirtschaftslexikon (Bendel, 2019) herangezogen, wonach Agilität die «Gewandtheit, Wendigkeit oder Beweglichkeit von Organisationen und Personen bzw. in Strukturen und Prozessen» ist. «Man reagiert dabei flexibel auf unvorhergesehene Ereignisse und neue Anforderungen. Man ist, etwa in Bezug auf Veränderungen, nicht nur reaktiv, sondern auch proaktiv.» (Bendel, 2019)

Im Kontext dieser Arbeit sind die beiden wichtigen Ausprägungen die agile Softwareentwicklung und die agile Organisation.

Die agile Softwareentwicklung hat ihren Ursprung im sogenannten «Manifest für Agile Softwareentwicklung». Dieses wurde 2001 von 17 Forschern aus dem Bereich Softwareentwicklung als Antwort auf die damals vorherrschende Form der Projektabwicklung entworfen (Kim, Humble, Debois, & Willis, 2016, S. 4). In ihrem Manifest beschreiben die Autoren Werte (Vgl. Abb. 4) und Prinzipien der agilen Softwareentwicklung.

Abbildung 4: Manifest für agile Softwareentwicklung

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung anhand von Beck et al, 2001

Die Autoren betonen, dass sie die Werte auf der rechten Seite als wichtig erachten, die Werte auf der linken Seite jedoch stärker gewichten (Beck et al., 2001).

Dem Manifest und der damit verbundenen neuen Werteausrichtung wird eine starke Steigerung der Produktivität der Softwareentwicklung zugeschrieben (Kim et al., 2016, S. 5).

Im Zusammenhang mit agilen Organisationen spricht man oft auch von dem damit verbundenen Wandel, welche eine traditionelle Unternehmung auf dem Weg hin zu einer agilen Organisation durchlaufen muss (Feldges, 2018). Gemäss Silvester Schmidt (Schmidt, 2017) zeichnen sich agile Organisation durch folgende Merkmale:

«explorative Vorgehensweisen, Lernen, Selbststeuerung und Selbstorganisation» aus.

Gemäss Schmidt entstehe eine agile Organisation «nicht einfach dadurch, dass Projekte nach Scrum oder im Rahmen skalierter agiler Frameworks durchgeführt werden. Vielmehr müssen das Management, die Prozesse und die Strukturen auch außerhalb einer agilen Projektorganisation einen “agilen Mindset” besitzen.»

Neusten Forschungen der Universität St. Gallen (Schneider, 2019) zufolge tun sich viele Unternehmen schwer damit «agil» zu werden. Demnach sollen zwar bereits viele Organisationen mit agilen Methoden arbeiten, diese jedoch nicht in ihrer Kultur verankert haben. Die Autorenschaft stellte zudem fest, dass «[…] agile Strukturen und Methoden vorwiegend bereichsweise statt im ganzen Unternehmen eingeführt [werden]» (Schneider, 2019).

Methoden und Frameworks

Laut einer Studie der ZHAW (Majkovic, Gundrum, Benz, Dzsula, & Huber, 2019, S. 8) werden in den befragten Schweizer Unternehmungen am häufigsten folgende agile Methoden eingesetzt: Scrum, Kanban und Design Thinking.

Gemäss dem Scrum-Guide (Schwaber & Sutherland, 2017, S. 3) ist Scrum «ein Rahmenwerk zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte.» Laut den Autoren ist Scrum leichtgewichtig, einfach zu verstehen, aber schwierig zu meistern (Schwaber & Sutherland, 2017, S. 3).

Die Definition lautet im englischen Original: «Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.» (Schwaber & Sutherland, o. J.)

Das Scrum-Framework lässt sich anhand eines Bildes gut erklären, wie in Abbildung 5 zu sehen ist.

Abbildung 5: Das Scrum-Framework

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Scrum, o. J.

Im Zentrum der Abbildung steht das Scrum-Team, innerhalb dieses Teams gibt es drei unterschiedliche Rollen: einen Product Owner (PO), einen Scrum Master (SM) und die Rolle der Entwicklerinnen und Entwickler. Die Idee dahinter ist, dass das Scrum-Team teilautonom agieren und sich seine Arbeit selbst organisieren kann (Schwaber & Sutherland, 2017, S. 6).

Der PO repräsentiert die Kundschaft und ist fachlich für das Produkt resp. für die Wertemaximierung des Produktes verantwortlich, indem er die Anforderungen (an das Produkt) im Product Backlog entsprechend priorisiert (2017, S. 6).

Der SM hingegen stellt sicher, dass die Scrum-Zeremonien wie das Daily, die Retroperspektive, das Sprint Planning und die Sprint Review eingehalten werden (S. 8). Der SM ist ein Servant Leader für das ganze Team und entfernt auch allfällige Hindernisse, welche das Entwicklungsteam aufhalten (S. 8).

Am Ende eines Sprints (Zeitdauer der Entwicklung) wird vom Entwicklungsteam ein fertig entwickeltes Increment, das heisst lauffähige Software, erwartet (S. 7). Die Entwicklungsteams sind interdisziplinär und bestehen in der Regel aus mindestens drei bis maximal neun Mitgliedern (SM und PO werden nicht gezählt). (S. 7)

Scrum ist ein iterativer und empirischer Prozess, dabei soll «Wissen aus Erfahrung gewonnen» werden und es sollen «Entscheidungen auf Basis des Bekannten getroffen werden. […] Drei Säulen tragen jede empirische Prozesssteuerung. Transparenz, Überprüfung und Anpassung.» (S. 4).

Zusammenfassend lässt sich festhalten, dass das erfolgreiche Anwenden von Scrum ein Lernprozess ist, welcher Zeit und Geduld benötigt und neben den angesprochenen Rollen auch das Management betrifft (Pichler, 2013, S. 3).

Kanban bezeichnet «[…] ein System zur Steuerung von aufeinander aufbauenden Abläufen in einer Wertschöpfungskette» (Böhm, 2019, S. 31). Dabei wird in der Praxis meist vom sogenannten Workflow, also dem Arbeitsablauf, gesprochen. Das wichtigste Kanban-Element ist dabei die Visualisierung der Workflows (kanbanize, o. J.) anhand eines Kanban-Boards (Vgl. Abb. 6). Damit werden Arbeit, Durchlaufzeit (der Arbeit) und allfällige Warteschlangen sichtbar gemacht.

Abbildung 6: Beispiel eines Kanban-Boards

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Diehl, 2020

Das Kanban-Board ist eine Weiterführung der klassischen To-Do-Liste auf der Teamebene. Arbeitsschritte oder Aufgaben werden auf Kärtchen geschrieben und entsprechend ihres Bearbeitungsstatus geordnet. In der klassischen Variante (Vgl. Abb. 6) werden die Aufgaben in «To Do», «Doing» und «Done» eingeteilt (kanbanize, o. J.), diese Kategorien können aber individuell an das jeweilige Projekt angepasst und erweitert werden (Diehl, 2020).

Nach Böhm ist Kanban «KEIN [ sic ] System für die Optimierung eines Teams, sondern für die Optimierung des Gesamtsystems und des Durchflusses» (2019, S. 31)

Design Thinking ist eine iterative Methode zur Entwicklung neuer Ideen und zur Lösung komplexer Probleme (Fleischmann, Oppl, Schmidt, & Stary, 2018, S. 141). Dabei ist der sechsphasige Prozess Kern der Design-Thinking-Methode (Vgl. Abb. 7). Dieser Prozess wird i. d. R. mehrfach durchlaufen und nach Diehl (2019) sei dabei der Start und das Ende des Prozesses am wichtigsten. Der Start solle mit einem «Beginners Mind» und der Haltung des Nicht-Wissenden erfolgen. Am Ende jedes Durchlaufs erfolgt das Testen unter Einbezug der Kundschaft und mittels des zuvor entwickelten Prototypen. Damit soll das Feedback der Kundschaft aufgenommen und entsprechende Anpassungen vorgenommen werden. Der Prozess «[…] sei erst fertig, wenn eine Idee materialisiert und konkret implementiert ist» (Diehl, 2019).

Bei Design Thinking ist nicht die Vorgehensweise, sondern auch um das Mindset relevant (Fleischmann et al., 2018, S. 142). So soll die zu entwickelnde Lösung unter den Aspekten der Wirtschaftlichkeit, Machbarkeit und Erwünschtheit aus Kundensicht erarbeitet werden (S. 142–143).

Abbildung 7: Der sechs Phasen des Design-Thinking Prozess

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Diehl, 2019

Der Vergleich der drei Konzepte zeigt, dass Design Thinking eher punktuell – resp. am Anfang eines Produktlebenszyklus – zum Einsatz kommt und die Teams danach mittels Scrum und/oder Kanban weiterarbeiten.

Skalierung auf mehrere Teams

Gemäss Böhm (Böhm, 2019, S. 97) wird eine Skalierung³ notwendig, «wenn mehrere Teams an einem integrierten Produkt arbeiten». Skalierung kann laut Böhm eine Lösung sein, wenn «die Herausforderung [...] mit mehreren interagierenden agilen Teams gelöst werden» kann und die Organisation auch tatsächlich Nutzen aus diesem Ansatz zieht (2019, S. 98). Scrum ist bereits selbstskalierend und kann in einer Umgebung auf mehrere Teams angewendet werden (S. 99). Da der Bedarf nach einem Verfahren gross ist und nicht jede Organisation ein eigenes, ideales Modell entwickeln wollte, hat sich ein eigener Markt mit verschiedenen agilen Skalierungsmodellen entwickelt (S. 99). Einige der bekanntesten Frameworks sind: SAFe, LeSS, Spotify-Model, Scrum@Scale und Nexus (S. 97).

Aus aktuellen Studien (SwissQ, 2019, S. 19 & Kovynyov, 2019) geht hervor, dass in den meisten Schweizer Unternehmen das SAFe-Skalierungsmodell (Vgl. Abb. A-1 im Anhang) zur Anwendung kommt. SAFe «[…] wird zumeist von großen Unternehmen […] eingesetzt und hat ein großes Zertifizierungsprogramm für die einzelnen Rollen aufgebaut.» (Böhm, 2019, S. 100). Böhm weist darauf hin, dass bei der Transformation zu SAFe viele der bisherigen Stellen abgebildet werden können und der relativ geringe Änderungsbedarf somit ein möglicher Erfolgsfaktor ist (S. 100). Diese Aussage wird durch Abbildung 8 aus dem Whitepaper zur Version 5 von SAFe (Scaled Agile Inc., 2020, S. 1) illustriert. Auf der rechten Seite steht die klassische hierarchische Organisation, welche auf die kundenorientierte SAFe-Ebene gemappt wird.

Abbildung 8: Das duale operative System von SAFe

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Darstellung aus dem Whitepaper zur SAFe-Version 5.0 (Scaled Agile Inc., 2020)

SAFe wird in der Community⁴ kontrovers diskutiert (Dexter, 2020). Die wichtigsten Kritikpunkte sind, dass das Framework zu sehr auf Planung fokussiert, dass es bürokratisch und kompliziert ist, viele unnötige Prozesse beinhaltet und vor allem die Autonomie der Teams schwächt. Zudem kritisiert Dexter (2020) das «old-school mindset», welches die agilen Teams als reine «low level doers» Einheiten zur Ausführung von Ideen der «high level thinkers» behandle. Damit werde gegen ein grundsätzliches Element des agilen Denkens verstossen: «Ignored is the possibility that those closest to the work might be best equipped to make decisions about it» (Dexter, 2020).

Oftmals basiert die Kritik an den Skalierungsframeworks darauf, dass diese den Kern einer agilen Organisation durch zu viel Struktur unterminieren (Denning, 2019 & Thomas, 2015).

Auswirkungen auf die Mitarbeitenden

Forschungen zufolge arbeiten schon viele Unternehmen in der Schweiz mit agilen Methoden, aber die Agilität sei «noch nicht in den Köpfen der Mitarbeitenden oder in der Unternehmenskultur verankert» (Campana-Schott, 2019, S. 5). Nicht nur die Anwendung der Frameworks, sondern auch die kulturellen und organisatorischen Herausforderungen, sind zu bewältigen und haben grossen Einfluss auf die betroffenen Mitarbeitenden. Insbesondere folgende Themen sind von Relevanz:

- Fokussierung auf das Produkt

In einer agilen Organisation steht das Produktteam im Mittelpunkt (Böhm, 2019, S. 80). Das Team verfügt über alle Skills für Herstellung und Betrieb des Produktes und ist direkter Ansprechpartner für die jeweilige Kundschaft. Das angebotene Produkt ist langlebig und wird – im Gegensatz zum Projektgeschäft – über den ganzen Lebenszyklus vom zuständigen Team betreut.

- Agile Führung

Der reine Abbau von Hierarchiestufen bringt noch keine Verbesserung der Agilität (Campana-Schott, 2019, S. 22), denn wichtiger als das Aussehen des Organigramms ist, wie gearbeitet wird. Ein starrer Organisationsaufbau führt zu langsamen Top-down-Entscheidungswegen und damit zu Inflexibilität resp. Wettbewerbsnachteilen. Dennoch sind laut SwissQ-Studie aus dem Jahr 2019 (S. 34) bestehende Hierarchien nach wie vor die grössten Hemmnisse für Agilität.

Im Idealfall handelt es sich bei der agilen Führung um Führung auf Augenhöhe, in diesem Zusammenhang wird häufig der Begriff Servant Leadership (Campana-Schott, 2019, S. 18) genannt. Ein Servant Leader richtet seine Führung an den Interessen der Mitarbeitenden aus und gibt einen Rahmen vor, in dem sich die Geführten autonom und selbstorganisiert bewegen können. Die Führung ist eine der grössten Herausforderungen im agilen Kontext und muss grundsätzlich neu gedacht werden (Häusling, Rutz, Oimann, & Oebbeke, 2014).

Gemäss Häusling et al. (2014) muss die Führungskraft lernen, loszulassen und die Mitarbeitenden müssen lernen, mehr Eigenverantwortung zu übernehmen. Dieser Prozess kann jedoch dazu führen, dass sich die Führungskraft überflüssig und die Mitarbeiterinnen und Mitarbeiter überfordert fühlen.

Zu bedenken ist auch, dass durch die Abschaffung von Hierarchien auch traditionelle, vertikale Aufstiegsmöglichkeiten minimiert werden.

- Entscheidungen

Agile Teams, welche für ihre Produkte Verantwortung übernehmen, müssen auch über entsprechende Entscheidungskompetenzen verfügen (Böhm, 2019, S. 92). Verfügen sie nicht über diese Kompetenzen, ist die Autonomie eingeschränkt und es kommt zu Verzögerungen; diese Situation birgt Frustrationspotential für das Team. Ein Team, resp. die einzelnen Mitarbeitenden, soll zusammen – unter Anwendung der agilen Werte sowie mit Transparenz und Respekt – lernen, Entscheidungsprozesse zu durchlaufen und diese durch Feedback kontinuierlich zu verbessern (S. 96).

- Reifegrad

Gemäss Häusling et al. (2014) müssen Teams so entwickelt werden, dass sich diese selbst Ziele setzen und individuelle Leistungen offen besprechen können. Die oben angesprochene Feedback-Kultur weist in die gleiche Richtung und stellt ebenfalls neue Anforderungen an die Soft-Skills der Mitarbeitenden. Agile Teams benötigen daher Mitarbeitende mit einem hohen Reifegrad (Häusling et al., 2014).

Weitere Voraussetzungen sind Vertrauen, Transparenz und eine offene Fehlerkultur.

2.1.2. Cloud als technologischer Treiber

Definition

Gemäss der US-amerikanischen Standardisierungsstelle NIST (Mell & Grance, 2011, S. 2) gibt es fünf Eigenschaften, welche eine Cloud definieren:

1. «On-demand self-service»: Die Ressourcen können vom Verbraucher jederzeit und selbstständig konfiguriert werden.
2. «Broad network access»: Der Zugriff auf die Ressourcen (Services und Daten) erfolgt über das Internet.
3. «Resource pooling»: Mehrere Konsumierende mieten Dienste auf derselben Hardware, die vom Cloudanbieter nach Bedarf dynamisch zugewiesen werden.
4. «Rapid elasticity»: Kapazitäten können schnell und elastisch zur Verfügung gestellt werden, um sich an sich ändernde Anforderungen anzupassen.
5. «Measured service»: Im Gegensatz zu klassischen Servern werden die tatsächlich genutzten Ressourcen nachträglich abgerechnet.

Wenn diese Merkmale erfüllt und die Leistungen exklusiv für eine Organisation zur Verfügung gestellt werden, spricht man von einer Private Cloud. Sie kann von der Organisation selbst im eigenen Datacenter betrieben werden oder auch von einem Dritten in dessen Datacenter. Die Public Cloud ist hingegen via Internet für die Allgemeinheit erreichbar und wird aus den Datacentern des Cloud Anbieters betrieben. Werden mehrere eigenständige Cloud-Infrastrukturen gemeinsam genutzt, werden sie als Hybrid Cloud bezeichnet.

Erfolgt die Bereitstellung der Anwendung – im Gegensatz zu den Cloud-Modellen – aus dem eigenen Datacenter, wird von On-Premises-Services gesprochen (Vgl. Abb. 9).

Abbildung 9: On-Premises und Cloud-Servicemodelle

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Frank et al., 2019, S. 106

Der Unterschied zwischen den drei Cloud-Modellen besteht im Abstraktionsgrad der jeweiligen Services (Frank et al., 2019, S.105–106). Dieser wird umso höher, je mehr Ebenen des IT-Stacks automatisiert werden und in der Verantwortung des Cloudanbieters liegen.

Der einfachste Service ist Infrastructure-as-a-Service (IaaS), bei dem Rechenleistung zum Beispiel in Form eines virtuellen Servers zur Verfügung gestellt wird. Bei Platform-as-a-Service (PaaS) ist die Automatisierung bereits grösser, da umfangreiche Funktionalitäten wie beispielsweise Datenbanken bereitgestellt werden. Dank PaaS bzw. dem entsprechenden Abstraktionsgrad, entfällt für Konsumierende die Verwaltung der zugrunde liegenden Infrastruktur (aws, o.J.). Software-as-a-Service (SaaS) hingegen bietet «ein vollständiges Produkt, das von einem Serviceanbieter ausgeführt und verwaltet wird. In den meisten Fällen bezieht sich SaaS auf Endbenutzeranwendungen (wie z. B. webbasierte E-Mail-Programme» (aws, o.J.).

Nutzen für das Unternehmen

Aus ökonomischer Sicht bietet die Cloud neben den Kosteneinsparungen (Laube, 2018) auch neue, flexiblere Preismodelle sowie vor allem einen Paradigmenwechsel von Investitionsausgaben (CAPEX) zu reinen Betriebsausgaben (OPEX). Die gewonnene Rapid Elasticity der Cloud erlaubt Unternehmen neue Skalierungsmöglichkeiten. Ein Unternehmen wird mit Hilfe der Cloud agiler.

Interessant wird es für Unternehmen, wenn Prozessschritte automatisierbar (repetitiv) und digitalisierbar (mittels Algorithmus abbildbar) sind, denn diese lassen sich vollständig in der Cloud betreiben (Frank et al., 2019, S. 203). Die Cloud bietet Unternehmen neue Optionen, dadurch stellt sich die Frage, welche Arbeitsprozesse noch intern durchgeführt (Make) und welche ausgelagert (Buy) werden sollen (S. 199). «Die Digitalisierung weist dabei in eine klare Richtung: Immer mehr Prozesse werden durch Softwarelösungen automatisier- und digitalisierbar» (S.221–222).

Bedeutung und Folge für die IT-Organisation

Aktuelle Studien (Henkes & Rajmane, 2019 & Computerworld.ch, 2020) zeigen anhand steigender Investitionen, dass sich viele Schweizer Unternehmen in Richtung der Public Cloud bewegen. Gemäss Gartner (Moore, 2019) werden im Jahr 2025 weltweit rund 80 % der Unternehmen keine traditionellen Datacenter mehr betreiben.

Datacenter werden aktuell von vielen IT-Organisationen selbständig betrieben, das gängigste Referenzmodell für solche IT-Organisationen ist – wie in Abb. 10 dargestellt – Plan, Build und Run (Brühl & Dorschel, 2017, S. 107).

Abbildung 10: Plan, Build und Run

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Brühl & Dorschel, 2017, S. 108

In diesem Modell wird die IT in verschiedene Bereiche mit unterschiedlichen IT-Aufgaben eingeteilt. So ist ein IT-Betrieb vor allem für die reibungslose Stabilität der angebotenen Services zuständig, während die Entwicklung für die Weiterentwicklung sorgen muss (Kim et al., 2016, S. XXV). Der oben beschriebene Weg, die Cloud zu implementieren, betrifft verschiedene Bereiche in unterschiedlichem Ausmass.

Für klassische IT-Betriebsbereiche bedeutet dies eine grosse Herausforderung, da sie sich in folgenden Punkten weiterentwickeln müssen:

- Erweiterung des heutigen Plattform-Service-Angebotes mit Public-Cloud-Diensten inkl. Integration zwischen On-Premises, Public Cloud sowie End-to-End-Security
- Bereitstellung von attraktiven Plattform-Services aus der Public oder Private Cloud, einschliesslich kontinuierlicher Weiterentwicklung
- Plattform-Automatisierung und -Engineering – hier braucht es neue Skills in Richtung Software-Entwicklung
- Beratung und Zusammenarbeit mit Produkt-Teams mit Engineering-Leistungen – primär Automatisierung
- Vorwärtsstrategie in Richtung Public Cloud durch schrittweise Dekommissionierung der heutigen On-Premise-Infrastrukturen (Albisser, 2020)

Eine Cloud-Transformation fordert aber auch die IT-Architektur und -Entwicklung, denn diese müssen sicherstellen, dass die Applikationen auf cloud-native Software-Architekturen umgestellt werden (Frank et al., 2019, S. 225). Um die damit verbundenen Anforderungen zu erfüllen, müssen auch Prozesse der Software-Entwicklung modernisiert werden.

Bezüglich der Migration einer Applikation in die Cloud hat Gartner bereits im Jahr 2010 mit dem «5R-Modell» ein grundlegendes Konzept geliefert (SA Technologies, 2018).

Die Migrationsszenarien werden im Folgenden vereinfacht beschrieben:

- «Rehost» ist die Migration einer Applikation aus der klassischen IT zu IaaS.
- Bei «Refactor» wird die Applikation in Teilen und bei «Revise» umfassend neu geschrieben. In beiden Fällen läuft die migrierte Anwendung danach auf PaaS.
- Bei «Rebuild» wird die Applikation grundsätzlich neu aufgebaut. Dafür ist meist eine PaaS nötig.
- «Replace» ist der Ersatz einer Anwendung durch eine kommerzielle SaaS-Lösung.

Der Unterschied bzgl. des Aufwands der Szenarien ist gross, daher bedarf die Wahl einer geeigneten Migrationsstrategie für bestimmte Applikationen einer sorgsamen Analyse.

Konsequenzen für die Mitarbeitenden

«Bis 2030 fallen in der Schweiz eine Million Jobs weg» schrieb die NZZ am Sonntag im Oktober 2018 (Hug, 2018) und bezog sich dabei auf eine Studie der Beratungsfirma McKinsey (McKinsey, 2018). Die Autorenschaft weist auf eine fundamentale Umwälzung des Arbeitsmarkts durch die Automatisierung hin. Der Anreiz hierfür sei insbesondere in der Schweiz aufgrund der hohen Löhne gross. Deshalb wird davon ausgegangen, dass zwar viele Jobs verschwinden werden, aber auch viele neue Stellen im Technologiebereich entstehen werden.

Bezogen auf IT-Jobs beschreiben Frank et al. (2019, S. 182) folgende Ausgangssituation: Intuitiv spreche vieles dafür, gerade die Arbeitsplätze im klassischen IT-Betrieb zu reduzieren. Der aktuelle IT-Fachkräftemangel und auch der zukünftig steigende Bedarf im Technologiebereich sprechen jedoch dagegen. Statt IT-Mitarbeitende abzubauen, solle das Unternehmen diese an sich binden und auf die veränderten Anforderungen vorbereiten. Auch die Handelszeitung (Freres, 2016) empfiehlt in Anbetracht des Fachkräftemangels in der IT, dass sich z. B. Systemadministratorinnen und Systemadministratoren weiterentwickeln und neue Fähigkeiten entlang des cloudbasierten Software-Prozesses aneignen sollen. Mit dem Schritt in die Cloud nimmt die Relevanz von Software im Unternehmen zu, daher werden Mitarbeitende mit Programmierkompetenz (Schreiben und Verstehen von Code) stärker gefragt (Frank et al., 2019, S. 244). Gemäss einer Studie zur Kompetenzanforderung durch die Digitalisierung (EHB und Infras, 2017, S. 79), die vom Staatsekretariat für Wirtschaft SECO in Auftrag gegeben wurde, ergab eine Umfrage bei Fachleuten, dass es zwar genügend IT-Fachleute gibt, diese aber nicht über das aktuell am Markt gefragte Know-how verfügen. «Die Änderungen der Digitalisierung laufen sehr schnell ab und viele IT-Fachleute können mit diesem Tempo nicht mithalten» (S. 79). Zusätzlich zu IT-spezifischen Anforderungen nennt die Studie auch berufsübergreifende Kompetenzen, welche im Zuge der Digitalisierung an Bedeutung gewinnen werden:

- Analytische Kompetenzen

- Daten analysieren, beurteilen und interpretieren
- Analytisches und kritisches Denken

- Soft-Skills

- Flexibilität, Anpassungsfähigkeit bei Veränderungen
- Kreativität, Innovationsfähigkeit und Out-of-the-box-Denken
- Vernetztes und prozessorientiertes Denken
- Umgang mit Unsicherheiten

- Kundenorientierung und Kommunikation

- Individualisierte Kundenberatung und -betreuung
- Führungs- und Präsentationskompetenzen
- Umgang mit neuen Kommunikationstechnologien und sozialen Medien (S. 74–76)

In der Studie wird des Weiteren festgehalten, dass die grösste Veränderung der Kompetenzanforderung über alle Branchen hinweg betrachtet in der Informatik feststellbar ist (S. 81). Anpassungen der Kompetenzen erfolgen on-the-job oder über Aus- und Weiterbildung, es wird zudem darauf hingewiesen, dass das lebenslange Lernen zunehmend an Bedeutung gewinnen wird.

2.1.3. DevOps in der IT-Organisation

Herleitung und Definition

In Umfragen (SwissQ, 2019, S. 54 & VSHN, 2020, S. 35) zeigt sich, dass sich DevOps in Schweizer IT-Organisation zunehmend etabliert.

Der Begriff DevOps setzt sich zusammen aus Dev (für Development) der IT-Entwicklung und Ops (für Operations), was wiederum für den IT-Betrieb steht. Traditionell waren dies (und sind es vielerorts noch) siloartige Bereiche mit unterschiedlichen Zielen in IT-Organisationen. Während die Entwicklung der Software durch neue Fähigkeiten erweitert und erneuert werden sollte, wurde im Betrieb auf Stabilität, also möglichst wenig Änderungen, geachtet (Pracht, 2011). Abbildung 11 ist eine Visualisierung dieses Zielkonfliktes zwischen Entwicklung (Dev) und Betrieb (Ops).

Abbildung 11: Entwicklung versus Betrieb

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Kehrli, 2017, S. 37

Der DevOps-Roman «The Phoenix Project» der Autoren Kim, Behr, & Spafford aus dem Jahr 2013 zeigt, wie dieser Konflikt die Grundlage für das Versagen einer gesamten IT-Organisation sein kann. Der Begriff Wall of Confusion (Vgl. Abb. 11) bezieht sich gemäss Kawaguchi (2020) auf Phänomene, welche auftreten, wenn eine Gruppe eines ganzheitlichen Prozesses ihre Arbeit als abgeschlossen betrachtet, sobald sie diese an die nächste Gruppe weitergegeben hat. Kawaguchi beschreibt das wie folgt:

«The canonical example is when developers throw their code ‘over the wall’ to their ops colleagues and don’t pay attention to what must be done to actually get the software they’ve written into a deployable state. This often causes the ops team to struggle with getting the software actually deployed, and can lead to significant delays in releases and raised the risk of defects and other problems.» (Kawaguchi, 2020)

DevOps hilft dabei, den oben beschriebenen Konflikt zu lösen, indem die beiden Bereiche Entwicklung und Betrieb, besser aufeinander abgestimmt werden und gemeinsame Ziele entstehen. Lauf Frank et al. (2019, S. 176) ist «DevOps [...] die agile Bereitstellung von IT, welche die Wertschöpfung vom laufenden Geschäft bis zur funktionierenden Software ganzheitlich unterstützt.» Es gehe um die Zusammenführung der beiden Bereiche auf den Ebenen der Kultur, der Systeme, der Praktiken und der Werkzeuge. Gemeinsames Ziel sei «[…] die Orientierung der IT am Bedarf des Kunden, [...] der Qualität und der Geschwindigkeit.»

Ein zentraler Punkt ist dabei der Fokus auf die Software, Adam Jacob schrieb 2015 dazu auf Twitter: «Like it or not, DevOps is the word we will use to describe the operational side of the transition to enterprises being software led».

Die wichtigsten DevOps-Methoden im Überblick

Bevor auf die einzelnen DevOps-Methoden eingegangen wird, wird der Lifecycle der Software-Entwicklung (Vgl. Abb. 12) dargestellt. Dieser beginnt mit dem Schreiben des Codes, welcher zumeist in einer Programmiersprache (wie beispielsweise Java) geschrieben wird, die von den Zielsystemen nicht direkt verstanden wird. Beim Build-Step wird der Code maschinengerecht ausführbar, unter Integrate erfolgt danach die Zusammenführung (z. B. einer Funktion) zu einer Gesamtheit (z. B. mit der Anwendung). In jedem Step werden Tests durchgeführt und wenn diese erfolgreich durchlaufen wurden, kann die Anwendung veröffentlicht (released) werden und wird mittels des Deploy-Schritts auf den Zielsystemen ausgerollt. Danach ist die Software benutzbar und wird betrieben (Operate).

Abbildung 12: Lifecycle der Software-Entwicklung

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Frank et al. 2019, S.169

Mit verschiedenen DevOps-Praktiken soll dieser Prozess (der Arbeitsfluss von Entwicklung bis hin zum IT-Betrieb) beschleunigt werden. Eine zentrale Methode ist es dabei, den Prozess häufiger, jedoch mit kleineren Updates durchzuführen (Kim et al., 2013, S. 323). Dadurch werden die einzelnen Bereitstellungen weniger riskant, Fehler können schneller behoben werden und Neuerungen gelangen schneller zu den Endkunden. Um dieses Vorhaben zu ermöglichen, werden neue Ansätze benötigt:

- Continuous Integration (CI) ist eine Praktik, welche die Integration der verschiedenen Code-Linien von mehreren Entwicklern automatisiert und getestet sicherstellt.
- Continuous Deployment (CD) ist eine Weiterentwicklung der CI. Alle Codeänderungen werden dabei in einer Test- und ev. sogar in einer Produktionsumgebung automatisiert bereitgestellt (Frank et al. 2019, S. 174–175).
- Die Microservices-Architektur basiert darauf, dass komplexe Anwendungen aus vielen kleinen und voneinander unabhängigen Services bestehen (Frank et al. 2019, S. 163).
- Infrastructure-As-Code bezeichnet ein Verfahren, bei dem Infrastruktur (z. B. virtuelle Server) nach Prinzipien der Software-Entwicklung bereitgestellt werden – also beispielweise mit maschinenlesbaren Definitionsdateien anstelle der manuellen Konfiguration. Damit wird auch dieser Prozess automatisierbar. (Kehrli, 2017, S. 18–20)
- Der wichtigste Aspekt ist die Kultur der Zusammenarbeit und Kommunikation. Dabei muss das Management sicherstellen, dass die Ziele der beiden Disziplinen aligniert sind. Ebenso wichtig sind regelmässiger (täglicher) Austausch (Feedback) und die akzeptierte Verantwortung des gesamten Lifecycles. Werner Vogel (CTO von Amazon) verdeutlicht dies mit seiner Aussage «You build it, you run it.» (O’Hanlon, 2006, S. 16)

In Abbildung 13 wird ein Teil der erwähnten Praktiken anhand des Lifecycles der Software-Entwicklung dargestellt.

Abbildung 13: CI, CD und DevOps

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Frank et al. 2019, S.169

Nutzen für das Unternehmen

Laut Kim et al. führt der Einsatz von DevOps zu einigen Vorteilen für ein Unternehmen, nämlich zu:

- schnellerer Auslieferung von Features,
- erhöhter Kundenzufriedenheit,
- mehr Marktanteilen,
- besserer Mitarbeiterproduktivität und glücklicheren Kollegen (2013, S. 317).

Die Auswirkungen von DevOps werden bereits seit mehreren Jahren wissenschaftlich untersucht, so haben beim State-of-DevOps-Bericht (Forsgren, 2019) aus dem Jahr 2019 weltweit mehr als 31,000 Fachleute teilgenommen. Durch den Bericht sollen Status und Verhaltensweisen von Organisationen in allen Stadien der DevOps-Adaption besser verstanden werden. Dabei konnte über mehrere Jahre nachgewiesen werden, dass eine Optimierung der Stabilität möglich ist, ohne dabei die Geschwindigkeit zu reduzieren. Dadurch wurde empirisch bewiesen, dass der grundlegende Konflikt zwischen Dev und Ops gelöst werden kann (Kim et al., 2013, S. 319).

Dies ist wichtig für Unternehmen, weil Technologie resp. die Software-Wertschöpfungskette im Zentrum jedes digitalen Geschäftsmodells steht. Je besser die Organisation diese Wertschöpfungskette beherrscht, desto agiler kann sich das Unternehmen am Markt bewegen, wodurch digitale Wettbewerbsvorteile erzielt werden.

Kritik an DevOps (und an Agilität) entsteht häufig aufgrund einer zu wenig umfassenden Umsetzung in den betroffenen Unternehmen. Kris Buyteart ist Mitglied des Advisoryboards der globalen DevOpsDays-Initiative und erklärt diesen Umstand mit der schwierigen und aufwendigen Transformation (2018). Es sei für Unternehmen oder das jeweilige Management beispielsweise einfacher, ein Tool oder Berater einzukaufen, als einen aufwendigen Mindset-Wandel durchzuführen. Dadurch wird DevOps nur als leere Hülle oder «imposed habit» implementiert (Blomstrom, 2019).

Im State-of-DevOps-Bericht wird darauf hingewiesen, dass das Management den DevOps-Fortschritt der Organisation häufig überschätzt:

For nearly every DevOps practice, C-suite respondents were more likely to report that these practices were in frequent use. Because the C-suite relies on upwards communication – often filtered and sanitized by the time it reaches them –executives don’t see the bottlenecks and broken processes that are stalling progress. So they have an incomplete understanding of DevOps progress and impact. (Puppet & Splunk, 2018, S. 6)

Auswirkungen für die Mitarbeitenden

Aus den obigen Ausführungen wird deutlich, dass die Anwendung von DevOps vielfältige Änderungen bedeutet, welche organisatorische, methodische und kulturelle Aspekte betreffen. Diese Veränderung erfordert neue Kompetenzen der Mitarbeitenden und verlagert deren Tätigkeitsgebiete in Richtung der Software-Entwicklung. Um die neu entstehenden Berufsanforderungen zu erforschen, hat die Hochschule Osnabrück eine DevOps-Arbeitsmarktstudie (Bensberg, 2017) durchgeführt. Anhand der Analyse konnten acht typische Jobcluster identifiziert werden, welche «[…] sich eng an bereits etablierte IT-Kernberufe (z. B. Engineer, Developer, Administrator) anlehnen». Das mit deutlichem Abstand häufigste Berufsbild war dabei jenes des DevOps-Engineers, welcher sich vor allem mit den Tätigkeitsfelder Softwareverteilung (Deployment), Konfiguration, Monitoring, Continuous Integration und Administration befasst. Schwerpunkte waren zudem die Automatisierung (mittels der Programmiersprachen Python und Java), die Verteilung und die Konfiguration von Software im Cloud-Umfeld.

Personen, die im IT-Betrieb tätig sind, sind von diesem Fokus auf Software stärker betroffen. Für sie sind viele der oben genannten Themengebiete neu und erfordern daher ein Umdenken (König, 2019). Ein Investment in die Know-how-Erarbeitung scheint daher nötig (SwissQ, 2019 S. 53–54). Für Mitarbeitende aus dem Bereich der Entwicklung ist die Veränderung kleiner, sie müssen sich allerdings für die tendenziell immer komplexer werdenden Anwendungs-Stacks und die Produktion interessieren. Gute Soft-Skills sind bereichsübergreifend eine wichtige Voraussetzung für gute Kollaboration.

2.1.4. Verknüpfung von Agilität, Cloud und DevOps

Die Digitalisierung fordert von IT-Organisationen, dass diese in immer kürzeren Zyklen (Time-to-Market) qualitativ hochwertige Produkte- und Services hervorbringen. Um dies zu ermöglichen, muss die gesamte Unternehmung agiler werden, dafür ist – unter anderem – eine Verzahnung der IT- und Fachabteilungen mittels interdisziplinärer Scrum-Teams nötig. Die Flexibilität der Cloud bildet das Fundament der hochautomatisierten IT-Infrastruktur und fördert so die Agilität der Organisation. Auch der Einsatz von DevOps begünstigt die Agilität, indem agile Prozesse der Softwareentwicklung im IT-Betrieb implementiert werden.

Alle drei Aspekte stellen hohe Anforderungen an das Change-Management einer Organisation (Steinert & Kroeme, 2017a), das volle Potential kann jedoch nur im gelungenen Zusammenspiel (Vgl. Abb. 14) der drei Strömungen erreicht werden.

Abbildung 14: Agilität, DevOps und Cloud

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Steinert & Kroeme, 2017b

Bei der Gesamtbetrachtung der einzelnen Bereiche wird – neben vielen technischen Neuerungen – die wiederholte Betonung der Wichtigkeit des kulturellen Wandels deutlich. Auffallend ist ausserdem die hohe Zahl der gleichzeitig stattfindenden Veränderungen, welche die Digitalisierung durch die damit verbundenen Anforderungen an die IT-Mitarbeitenden mit sich bringt.

2.1.5. Good Practices

In diesem Kapitel werden – ergänzend zu den bisherigen Kapiteln – Beispiele aus der Praxis betrachtet. Im Gegensatz zu Best Practices sind Good Practices keine Lösungen oder gleich umsetzbare Vorlagen, sondern dienen als inspirierende Anschauungsbeispiele.

Bei der Auswahl der beiden Beispiele wurde darauf geachtet, dass die Unternehmen tatsächlich mit allen drei Aspekten Berührungspunkte hatten und diese Erfahrungen auch in der Literatur recherchierbar sind.

Beispiel «ING»

Die holländische Bank ING ist ein häufig zitiertes Beispiel für die gelungene Transformation eines klassischen Unternehmens in das digitale Zeitalter.

Der Druck auf traditionelle Geschäftsmodelle durch die Digitalisierung und der befürchtete Markteintritt von Tech-Giganten, wie zum Beispiel Amazon und Alibaba, war der Ursprung des Wandels (Loos, 2018). Ron van Kemenade, der CIO von ING, gab während einer Präsentation beim DevOps Entreprise Summit in London im Jahr 2016 Einblicke in das Unternehmen (IT Revolution, 2016). So betonte er die Think-forward-Strategie von ING, bei der es darum gehe, die Kundschaft dazu zu befähigen, im Leben und im Business immer einen Schritt voraus zu sein. Zudem erwähnte er das Kundenversprechen für klare und einfache Produkte, welche immer und überall verfügbar sind. Im Sinne einer agilen Unternehmenslinie sei das Bestreben auch, immer besser zu werden (IT Revolution, 2016, 5:37-7:07).

Die Entwicklung begann 2010, nachdem einige ING-Mitarbeitende eine Google-Konferenz besucht hatten und erkannten, wie wichtig eine Engineering-Kultur für die IT eines Unternehmen ist (McKinsey, 2017b). Im Anschluss an diesen Besuch wurde eine Initiative mit vorerst zwei Teams gegründet, welche nach agilen Prinzipien arbeiteten (IT Revolution, 2016, 12:10-14:30). In Abb. 14 werden die entscheidenden Schritte der Transformation dargestellt, welche als Beispiel für die kontinuierliche Weiterentwicklung des Unternehmens stehen.

Abbildung 15: ING Transformation Journey

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an IT Revolution, 2016, 15:22-22:40

Während dieses Änderungsprozesses ist ING vor vielen Herausforderungen gestanden, die wichtigsten waren folgende:

- Fähigkeiten der Belegschaft

Anpassungsfähigkeit und signifikant anderes Wissen und andere Kompetenzen sind gefragt. Was ist die richtige Balance zwischen Ausbildung, Anstellung und Outsourcing?

- Einbezug des Business

Das Business und die Art der Zusammenarbeit ändern sich. Wie kann man das Business mit an Bord nehmen?

- Technologische Anpassungen

Veraltete Technologie, welche nicht zu modernen Werkzeugen passt. Wo macht ein Investment überhaupt Sinn? (IT Revolution, 2016, 22:45-25:05)

Im Zusammenhang mit dem Begriff Einbezug des Business stehen BizDevOps und das Spotify model (Vgl. Abb. 15). Anhand dieses Modells hat ING die agile Organisation (Vgl. Abb. 16) – bestehend aus Squads, Tribes und Chapters – abgebildet (McKinsey, 2017b).

Abbildung 16: Das agile Organisationsmodell bei ING

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an McKinsey, 2017b

Squads haben, wie auch Scrum-Teams, einen Product Owner und bestehen aus etwa sieben Personen aus unterschiedlichen Bereichen (BizDevOps), welche selbstbestimmt und autonom End-to-End-Verantwortung übernehmen (ING, o.J.). Mehrere Squads werden wiederum in Tribes zusammengefasst, welche in ähnlichen Bereichen angesiedelt sind und ein gemeinsames Ziel verfolgen (ING, o.J.). Mittels Chapters werden Abstimmung und Austausch von Fachexperten über die Squad-Grenzen hinaus sichergestellt (ING, o.J.).

Der letzte Aspekt der vorgestellten Transformation Journey (Vgl. Abb. 15) war die Weiterentwicklung der Engineers mittels des Dreyfus-Modells. Mit dem Modell wird beobachtbares Verhalten beschrieben, es wurde von ING auf die eigenen Bedürfnisse abgestimmt (Llanos, 2020). Das Modell definiert fünf Stufen, nämlich «Novice, Advanced, Competent, Proficient,[ sic ] and Expert» und besteht aus den zwei Dimensionen «technical capabilities and competencies» (Llanos, 2020). Während die erste, technische Dimension für Engineers klar sei, werde die zweite Kompetenz-Dimension, die Soft Skills beinhaltet, in vielen IT-Unternehmen nicht geschätzt (Llanos, 2020). Bei ING werden diese Kompetenzen hingegen sehr stark gewichtet, da technisches Fachwissen nicht ausreicht, wenn es nicht auch zu einem Mehrwert führt (Llanos, 2020). Als Beispiel erwähnte Pedro Llanos, Chapter Lead bei ING, dass grossartige Ideen nur dann einen Mehrwert bringen, wenn jemand auch fähig sei, diese Idee in der Organisation umzusetzen (Llanos, 2020).

In einem McKinsey-Interview empfiehlt Ron van Kemenade, die Neu-Definition der Engineering-Profile möglichst früh zu beachten: «My recommendation to anybody embarking on a journey like this would be to start on the people side – make that the most important area of change early on.» (McKinsey, 2017a, S. 6).

Beispiel “Spotify”

Der schwedische Musikanbieter Spotify gilt seit einiger Zeit als Paradebeispiel einer agilen Organisation und erlangte durch sein Spotify model weltweit Beachtung. Ein Teil des Modells wurde bereits anhand der Organisationsstruktur mit autonomen Teams am Beispiel von ING (Vgl. Abb. 16) beschrieben.

Ein wichtiges Kultur-Prinzip bei Spotify ist die Balance von Alignement und Autonomie. Dabei haben die Leader eine wichtige Aufgabe, denn sie sprechen vor allem über das Was, also die zu lösenden Herausforderungen, und nicht über das Wie (Kniberg, 2014a, 03:06-04:04). Im fiktiven Beispiel von Kniberg geht es darum, einen Fluss zu überqueren (Was). Wenn nun dem Team befohlen wird, dafür eine Brücke zu bauen (Wie), dann besteht in der Organisation eine Command-and-Order-Kultur (Vgl. Abb. 17). In einer agilen Kultur kann das Team hingegen selbst entscheiden, wie es zur besten Lösung kommt. Geringes Alignement bei hoher Autonomie führt zu Chaos, da keine Richtung vorgegeben wird und die Mitarbeitenden machen, was sie wollen. Ohne Autonomie und Alignement geht es für Mitarbeitende hingegen nur darum, Befehle ohne Kontext auszuführen, wobei es sich nach Kniberg deshalb um Micro-Management handelt.

[...]

---

¹ Die Firma Kodak war vor der Digitalisierung Marktführer im Bereich der Fotografie und entwickelte bereits in den 1970er-Jahren die Technologie der digitalen Fotografie. Durch eine Fehleinschätzung des Marktes konzentrierte sich die Firma weiterhin auf die analoge Fotografie. Damit verpasste Kodak den Digital-Boom und verlor zudem ihre Marktführerschaft.

² Im Kontext dieser Arbeit steht der Begriff Spannungsfeld für Bereiche und Themen des Arbeitsalltages, in denen sich die Anforderungen des Unternehmens nicht oder nur bedingt mit menschlichen Grundbedürfnissen vereinbaren lassen.

³ Unter Skalierung wird das Anpassen an veränderte Massstäbe verstanden. In diesem Zusammenhang ist mit Skalierung, die Ausbreitung der Methodik auf mehrere Teams gemeint.

⁴ Der Ausdruck Community bezeichnet gemäss dem Gabler Wirtschaftslexikon (Esch, 2018) ein «[…] soziales Netzwerk von miteinander in Interaktion stehenden Individuen, […]». Es handelt sich dabei um eine lose Gemeinschaft, welche sich auf Konferenzen oder Meetups austauscht. Der Grossteil der Interaktion erfolgt jedoch digital.