In dieser Folge des Podcasts „DevOps – auf die Ohren und ins Hirn“ diskutieren die Gastgeber Alex Lichtenberger und Dierk Söllner mit Martin Thalmann, dem Leiter DevOps bei der Swisscom, über die umfassende DevOps-Transformation im Unternehmen. Thalmann gibt Einblicke in die anfänglichen Herausforderungen, die Implementierung agiler Praktiken, die Reorganisation nach dem Spotify-Modell und den Übergang zu einem agilen Mindset im gesamten Unternehmen. Er betont die Bedeutung von Agilität, Stabilität und kontinuierlicher Verbesserung, während er auf die Notwendigkeit hinweist, sowohl technologische als auch kulturelle Veränderungen anzugehen, um eine erfolgreiche Transformation zu gewährleisten.
Inhalt
- Einleitung und Vorstellung von Martin Thalmann
- DevOps-Transformation bei der Swisscom: Hintergründe und Ziele
- Agile Praktiken und die Implementierung im Unternehmen
- Herausforderungen während der DevOps-Transformation
- Implementierung des Spotify-Modells in der Organisationsstruktur
- Wichtigkeit von Stabilität und Qualität in agilen Teams
- Beziehungen zwischen Entwicklungs- und Betriebsteams („You build it, you run it“)
- Personal- und kulturelle Veränderungen innerhalb der Swisscom
- Zukunftsperspektiven und nächste Schritte in der DevOps-Transformation
Transkript (automatisiert, daher keine Gewähr 🙂 )
DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner und ich begrüße die Zuhörer und Zuhörerinnen auch im Namen von Alex Lichtenberger.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern, die in DevOps enthalten sind.
Wir liefern Vorschläge, Konzepte und Interviews mit Experten und Praktikern, damit unsere Hörer und Hörerinnen inhaltlich, persönlich durchblicken und ihr Unternehmen erfolgreicher machen können.
Gut, herzlich willkommen auch von meiner Seite.
Mein Name ist Alex Lichtenberger.
Und ich möchte ganz herzlich begrüssen Martin Thalmann, heute ein ganz spezieller Gast, auch mit einem sehr spannenden Thema.
Martin Thalmann, Leiter DevOps bei der Swisscom und auch Initiator oder Mitinitiator der DevOps Days in der Schweiz und des DevOps Meetups in Zürich.
Also willkommen Martin.
Besten Dank.
Ja, und ich würde sagen, bevor wir da jetzt ins Thema reingehen.
Also Thema DevOps Transformation bei der Swisscom.
Möchtest du dich kurz vorstellen, so als Person, aber vielleicht auch kurz die Swisscom.
Ich denke, die Schweizer Gäste, die kennen ja, kennen alle eigentlich die Swisscom als Telco-Anbieter, aber die Swisscom ist ja noch mehr.
Vielleicht kannst du ja kurz da vorstellen.
Bitte Martin.
Also mein Name ist Martin Thalmann.
Ich arbeite jetzt seit mehr als drei Jahren bei der Swisscom.
An der DevOps Transformation kann das in verschiedenen Rollen, darf ich das begleiten und mitgestalten.
Im Moment ist meine Rolle, dass ich als Product Owner für ein Team arbeite, von dem wir agiles Coaching und Trainings für die ganze Organisation zur Verfügung stellen.
Vom Hintergrund her habe ich eigentlich einen Entwickler-Background, habe also selbst mal programmiert und dann viele Jahre als Projektmanager gearbeitet.
Sowohl im Entwicklungsteil als auch im Betriebsteil.
Also ich denke, ich kenne von dieser Seite her sowohl das klassische Umfeld, den Betrieb, die Entwicklung, konnte ich schon sehr viel Erfahrung sammeln in dem Bereich.
Und im Moment arbeite ich bei der Swisscom.
Die Swisscom ist das führende Telekommunikationsunternehmen und eines der führenden IT-Unternehmen in der Schweiz.
Und was wir machen ist, wir bieten Privatkunden Breitbanddienste an.
Im Digital-TV, Mobilfunk und umfassende Services.
Und im B2B-Segment umfasst das Angebot Netz-, Cloud- und ICT-Dienstleistungen.
Gut, herzlichen Dank Martin.
Dann stellen wir jedem Gast immer die Frage, was verstehst du unter DevOps?
In dem Sinne auch an dich die Frage Martin, was verstehst du unter DevOps?
Kann man das überhaupt definieren?
Und wie?
Ja, das ist eine gute Frage.
Also wenn man es in einem Satz definieren soll, dann würde ich auch sagen,
DevOps ist eigentlich Agilität konsequent zu Ende gedacht.
Und wenn ich etwas mehr Zeit für die Antwort mir nehmen darf,
dann würde ich wahrscheinlich auf die Bezeichnung von John Willis zurückgreifen,
der ja diesen CALMS-Begriff definiert hat.
Wo er sagt, DevOps, da geht es um Culture, es geht um Automation, Lean, Measurement und Sharing.
Und ich habe das Gefühl, das trifft es eigentlich sehr gut,
weil es ist bedeutend mehr als nur eine Technologie,
aber genau gehört auch die Technologie mit dazu.
Also es ist eine ziemlich umfassende Sache,
damit man es schafft, Wert schneller zum Kunden zu bringen.
Ja Martin, vielen Dank.
Das ist ja schon mal interessant.
Interessante Definition, eine interessante Beschreibung.
Mit dem John Willis finde ich auch eine gute Idee.
Ich glaube, das kann man auch immer wieder anbringen.
Und da kann man sehr viel auch in der Erklärung, was ist DevOps,
kann man sehr viel reinpacken an der Stelle.
Jetzt hast du von der Swisscom gesprochen und von Transformation.
Transformation heißt ja auch immer Organisationsveränderung.
Warum habt ihr das denn gemacht?
Also was waren so die Treiber für euch dabei?
Ja, sagen Sie, es gibt.
Es gibt zwei Haupttreiber, die ich identifizieren kann.
Auf der einen Seite sind es klar die Anforderungen vom Markt.
Ich denke gerade die Telekommunikationsbranche ist eine Branche,
die in einem extrem schnellen Wandel ist.
Und vor allem wird auch die Konkurrenz immer globaler.
Also ich denke, die Swisscom sieht die Konkurrenz nicht nur
in den anderen Telekom-Anbietern im Schweizer Markt,
sondern es sind vor allem dann halt auch die globalen,
die mit Diensten wie Netflix, mit WhatsApp, mit Skype
eigentlich unser Kerngeschäft auch anbieten, angreifen.
Und damit wir da wettbewerbsfähig bleiben,
da klappt es eigentlich mit der bestehenden und mit der herkömmlichen Art,
wie wir Projekte machen, geht es eigentlich nicht mehr.
Und das ist wieder der zweite Grund.
Also wir haben, bevor wir Richtung DevOps umgeschwenkt sind,
haben wir auch mit der Klassik,
mit der klassischen Wasserfall-Projektabwicklung Projekte durchgeführt.
Und mit dieser klassischen Abwicklung hatten wir auch die klassischen Probleme.
Das heisst, wir hatten sehr, sehr lange Projektlaufzeiten.
Wir haben Fehler immer erst ganz am Schluss im End-to-End-Test gefunden.
Und das Verrückte ist ja, dass dort die Fehler am teuersten sind.
Also wir haben die meisten Fehler dort gefunden,
wo sie am meisten Kosten verursachen.
Es gab dann häufig die Situation,
dass der Kunde nicht ganz zufrieden war mit dem, was er erhalten hat,
also was von der Software geliefert wurde.
Und wir konnten auch schlichtweg schlecht auf Änderungen reagieren innerhalb des Projektes.
Und das waren eigentlich so die zwei Hauptgründe,
weshalb wir gesehen haben, auf die klassische Art,
da können wir nicht mehr weiter erfolgreich am Markt agieren.
Ja, also ich finde das sehr nachvollziehbar.
Und es ist ja auch wichtig, sich über das Warum im Klaren zu sein.
Man macht ja nicht DevOps wegen DevOps.
Und da gibt es auch einen Grund.
Und bei euch ganz klar auch eine Business-Motivation.
Das eine habe ich herausgehört, so Innovationsfähigkeit,
aber dann auch klar so Dinge wie Time-to-Market.
Und das führt uns eigentlich so zur nächsten Frage,
jetzt vor diesem Hintergrund.
Wie seid ihr dann das angegangen?
Weil ihr seid, ich glaube, auch schon da einige Zeit unterwegs.
Was war so der erste Schritt?
Den ihr dann oder die ersten Schritte, die ihr unternommen habt?
Ja, vielleicht muss man noch vorausschicken,
dass bevor wir überhaupt angefangen haben,
das wirklich als Programm oder als Initiative aufzuziehen,
wir haben ja nicht bei Null begonnen,
sondern wir hatten da bereits verschiedene Teams in der Organisation,
die in einem sehr, sehr lokalen Fokus auch schon mit Scrum oder mit Kanban experimentiert hatten.
Also es ist ja nicht eine,
es ist nicht eine komplett neue Erfindung,
sondern es basiert auf diesen bestehenden agilen Prinzipien.
Die gab es schon, darauf haben wir aufgebaut.
Und wir haben dann im 2014,
haben wir damit wirklich gestartet,
uns mit dem Thema DevOps auseinanderzusetzen.
Und dann haben wir gesagt, okay, das klingt spannend,
das klingt nach einem sehr vielversprechenden Ansatz
und haben dann mit verschiedenen Pilot-Teams,
haben wir versucht, erste Erfahrungen zu sammeln.
Also wir haben quer durch die Organisation
etwa sechs oder sieben Teams gesucht und identifiziert
und haben gesagt, okay, mit denen starten wir mal,
mit denen versuchen wir mal,
diese ersten Prinzipien von DevOps anzuwenden
und zu schauen, was geschieht.
Und das war super spannend.
Und ich würde sagen, von den sieben versuchten Piloten
waren sechs innerhalb von sehr kurzer Zeit erfolgreich,
richtig.
Und wir haben einen positiven Effekt nachweisen konnten,
auch wenn wir so die ganz klassischen Dinge
wie ein Continuous Delivery dort noch nicht eingebaut haben,
sondern vielleicht zuerst nur mal an der Zusammenarbeit gearbeitet haben.
Okay.
Na gut, da kann man ja noch mal ein bisschen drauf eingehen.
Du hast ja erzählt, dass ihr schon ein paar Teams hattet,
dass ihr schon die ersten Erfahrungen auch gesammelt hattet.
Und habt ihr dann irgendein DevOps-Modell genommen?
Also irgendwo out of the box irgendetwas gefunden?
Oder wie seid ihr dann quasi gestartet, um zu entscheiden
oder um zu sagen, jetzt machen wir,
versuchen wir auch nach DevOps-Prinzipien vorzugehen?
Ja, zu der Zeit, zu dem Zeitpunkt,
also es war ja doch schon einige Zeit her,
da gab es eigentlich noch relativ wenig Referenzmaterial.
Ja.
Also das Phoenix-Projekt, das Buch war draussen,
das haben wir natürlich alle gelesen
und uns gut mit der Person auch identifiziert.
Aber so, was DevOps ist,
das so ganz, ganz klar war es zu dem Zeitpunkt noch nicht.
Wir haben dann eigentlich parallel zu diesen Pilot-Teams,
haben wir dann gesehen, dass das funktioniert,
haben das dann auch mit mehr und mehr Teams gestartet.
Also wir haben einen ganzen Teil der Entwicklungsabteilung,
haben wir,
nach diesen Prinzipien aufgesetzt.
Und je mehr Gewicht, dass das bekommen haben,
dann ist so etwas Spannendes geschehen,
dass nämlich auf einmal alle Leute gesagt haben,
ja, wir sind auch agil.
Und die haben dann statt Projekt-Meetings,
haben sie Stand-Ups gemacht
und statt Wasserfallphasen waren das Sprints.
Und wenn man ein bisschen genauer draufgeschaut hat,
hat man dann aber gemerkt, ja, Moment mal,
das ist nicht agil,
sondern da ist einfach ein agiles Label draufgeklebt worden.
Und das war so der Moment,
wo wir gesagt haben, jetzt müssen wir eine für die Swisscom
gültige Definition von DevOps müssen wir finden.
Und was wir gemacht haben,
wir haben uns zu diesem Zeitpunkt,
haben wir uns dann an das Referenzmodell von IBM angelehnt,
haben das angeschaut.
Und die setzen so auf sechs verschiedene Capabilities,
die nötig sind.
Das ist Continuous Integration,
Continuous Testing,
Continuous Release und Deployment,
das Continuous Monitoring,
Continuous Customer Feedback und Optimization
und das Continuous Business Planning.
Und an diesem Modell hat uns eigentlich sehr gut gefallen,
dass es sehr ein umfassendes Modell ist.
Also, sagen wir mal, dass es halt all die verschiedenen Disziplinen,
auch die betrieblichen Disziplinen gut abdeckt,
dass es das Business involviert.
Und es ist nicht nur eine rein technische,
wir machen jetzt eine
Continuous Delivery Pipeline Geschichte war.
Und dieses Referenzmodell hat uns dann auch geholfen,
um gemeinsam uns daran auszurichten und zu sagen,
okay, das ist unser Verständnis.
In die Richtung wollen wir eigentlich gehen.
Ja, du entspannst, Martin.
Also ich höre heraus,
ihr habt ja schon früher,
ihr habt Erfahrung gemacht mit agilen Teams.
Ihr habt auch in der Initial
dann ein paar Piloten daraus gelernt,
euch an die agilen Prinzipien orientieren.
Und dann das Ganze, sagen wir,
bereichert dann auch mit diesem IBM-Kompetenzmodell
wie Continuous Delivery etc.
Und dann aus dem raus eigentlich wie gewachsen.
Und ich habe auch,
ich denke, da hat ja dann auch das,
so wenn man das Team als Basis nimmt,
das selbstorganisierte Team,
das sich dann end-to-end schlussendlich Verantwortung übernimmt.
Ihr habt euch ja dann, glaube ich,
auch stark am Spotify-Modell orientiert.
Ist das richtig?
Das ist richtig.
Wir haben dann gesagt,
wir wollen nach diesen agilen Prinzipien arbeiten
und haben dann überlegt,
und wie können wir das jetzt am besten
auch in der Organisation abbilden?
Und dort waren wir der Überzeugung,
oder sind wir immer noch der Überzeugung,
dass eine klassische Hierarchie sich nicht so gut
mit diesen agilen Ansätzen verträgt.
Und deshalb haben wir gesagt,
wir möchten dort wirklich einen Schritt weitergehen.
Wir möchten das auch in der Aufbauorganisation abbilden
und haben uns für diese Aufbauorganisation,
haben wir uns dann für das Spotify-Modell entschieden.
Das heisst eigentlich,
das agile Team,
das besteht bei uns zwischen sechs und vielleicht neun
hundert Prozent assignten Personen,
die fix in einem Team und genau einem Team arbeiten.
Und dieses Team zusammen, das, das,
das ist eine Squad dann.
Und mehrere Squads,
die thematisch am gleichen Thema arbeiten,
die bilden zusammen eine Tribe.
Und auf Stufe Tribe gibt es einen Tribe-Chief.
Und was von der Seite her noch ganz spannend ist,
ist, dass wir gesagt haben,
im SAP oder in der eigentlichen Hierarchie
rapportieren alle Leute an den Tribe-Chief.
Und das führt dazu,
dass der Tribe-Chief eine Führungsspanne
von 50 bis 125 Personen hat.
Und bei einer solchen Führungsspanne
ist es natürlich klar,
dass dieser klassische Führungsstil
mit regelmässigen Meetings mit den Mitarbeitenden
und Performancegesprächen und dergleichen,
das geht einfach gar nicht mehr,
weil man gar nicht mehr die Kapazität dazu hat.
Und deshalb hat uns eigentlich dieses Modell
auch dazu geholfen,
die Selbstorganisation zu fördern.
Weil wir sagen,
was immer das Team selber organisiert,
was man organisieren kann,
soll das Team auch selber organisieren.
Und nur ganz wenige Punkte,
wo es zum Beispiel auch gesetzliche Anforderungen gibt,
die werden nach wie vor von einem Tribe-Chief
oder von einem Agile-Coach,
der auch auf dieser Stufe agiert,
quasi übernommen.
Und um da einfach noch ein Gefühl zu bekommen,
von was für einem Mengengerüst sprechen wir da?
Also wie viele Squads oder wie viele Leute
sind da zurzeit in so Squads?
In so Squad-Konstrukten unterwegs?
Ja, das hat auch,
das ist auch gewachsen über die Zeit.
Also begonnen haben wir mit vielleicht etwa
100 bis 200 Leuten,
wo wir das so aufgesetzt haben.
Und über die Zeit haben wir das
mehr und mehr ausgeweitet.
Und diesen April,
also jetzt auf den 1. April,
haben wir entschieden,
dass wir die ganze Dev-Organisation,
also die ganze Entwicklung
und das ganze Application-Operation
haben wir jetzt auf diesen Namenssatz umgestellt.
Und das sind rund 1000 Personen,
die davon betroffen sind,
von dieser organisatorischen Veränderung.
Ich glaube, was da aber auch wichtig ist,
ist zu sagen, das ist die reine Aufbauorganisation.
Das ist eigentlich ein rein hierarchisches Konstrukt,
wenn man es so will.
Was ja, wenn wir aber von Agilität sprechen,
und dort ist ja dann auch die Frage,
wie kann man ein einzelnes agiles Team skalieren,
aber eine ganze Unternehmung.
Und für diese Skalierung
richten wir uns dann am Safe-Modell aus.
Und wenn man Safe anschaut,
dann hat ja Safe die Überzeugung,
dass wir immer uns an einem Value-Stream ausrichten sollen.
Also was erzeugt am Schluss Wert für den Kunden?
Und dieser Value-Stream ist aber Organisation,
oder eben dieses Silo übergreifend.
Also es ist dann nicht nur die Entwicklung,
die davon betroffen ist,
sondern es sind auch die Business-Units davon betroffen.
Und das sind auch die reine Infrastruktur,
die davon betroffen sind.
Und das gibt dann eigentlich mehr die Ablauforganisation,
die eigentlich viel stärker und wichtiger ist,
als die eigentliche Aufbauorganisation.
Ja, und so auch die,
am Schluss geht es ja um die Zusammenarbeit.
Genau.
Entlang des Value-Streams hat er dann am Schluss,
mit dem er den Wert dem Kunden liefert dann.
Genau, genau so.
Ja Martin, das klingt ja ganz interessant.
Ich wollte nochmal einhaken nach dem Thema,
oder bei dem Thema Agile Coach und Tribe Lead.
Wenn ich das richtig verstanden habe,
ist der Tribe Lead oder der Tribe Chief
wirklich mit einer enormen Verantwortung ausgestattet.
Hohe Führungsspanne, hohe Verantwortung.
Der Agile Coach ist ihm im Prinzip gleichgestellt.
Also hat er eine gleiche Verantwortung,
hat er ein gleiches Ansehen bei euch?
Ja genau, das ist genau so, wie du es sagst.
Wir haben den Tribe Chief,
der eigentlich mehr für die inhaltliche Verantwortung
der Tribe ist.
Der schaut, dass alles gut funktioniert,
dass der Fluss da ist,
dass sie die Software liefern,
schaut vielleicht auch für,
dass die Betriebstickets gelöst werden und so weiter.
Also er hat einen sehr starken inhaltlichen Fokus.
Und dann haben wir gesagt,
wenn man eine Agilitätsreise angeht
oder eine DevOps-Transformation angeht,
so eine Transformation braucht Zeit
und da braucht es auch Unterstützung dazu,
dass man das vorwärts bringen kann.
Und das ist dann die Rolle des Agile Coaches.
Wir haben uns sehr bewusst dafür entschieden,
dass der Tribe Chief und der Agile Coach
auf Augenhöhe zusammen das machen.
Das heisst, der Agile Coach ist für die Transformation
der ganzen Tribe zuständig
und bildet zusammen mit dem Tribe Chief ein Führungsduo.
Und die sind auch hierarchisch so,
ist das abgebildet,
weil beide rapportieren an den gleichen Vorgesetzten.
Also es ist wirklich ein Führungsduo auf Augenhöhe.
Und das heisst auch eben so,
die klassischen Management-Rollen,
die es dann immer weniger braucht,
und dafür dann die neuen Rollen,
Agile Coach, Tribe Chief.
Wenn ich mir das jetzt so klassisch vorstelle,
das hat ja sicher auch bedeutet,
dass es dann weniger,
also vor allem Mittelmanagement gebraucht hat.
Was waren da so die Herausforderungen?
Oder stimmt da meine Annahme,
die ich geäussert habe?
Ja, die Annahme ist absolut richtig.
Also diese agile Transformation
hat insbesondere auf das Mittelmanagement,
hatte das eine grosse Auswirkung.
Vor der Transformation hatten wir ungefähr 10%,
ich sage das mal in Anführungszeichen,
Management overhead.
Das heisst, von diesen 1000 Leuten,
die in dem Bereich arbeiten,
hatten wir 100 Leute,
die in irgendeiner Führungstätigkeit unterwegs waren.
Und das Ziel der Transformation war auch,
dass wir gesagt haben,
das reduzieren wir auf 5%.
Das heisst, jede zweite klassische Führungsrolle,
die wir bisher hatten,
die gibt es heute nicht mehr.
Das heisst, und wir haben uns bewusst dagegen entschieden,
dass wir gesagt haben,
wir machen so ein 1 zu 1 Mapping,
dass wir gesagt haben,
ein Team Leader wird nachher,
ich sage mal Scrum Master oder so,
sondern wir haben gesagt,
okay, wir setzen das neue Setup auf
und schauen dann,
dass wir die richtigen Leute dafür finden.
Und da gab es natürlich auch viele Leute,
die sich dann umorientieren mussten
oder ich sage im Sinne von,
dass sie jetzt eine komplett andere Aufgabe wahrnehmen.
Sei es als Agile Coach,
sei es als Tribe Chief
oder vielleicht auch eine viel technischere Rolle
wieder als DevOps-Ingenieur
oder als Scrum Master oder Product Owner.
Ja, also die einzige Konstante ist die Veränderung.
Und das ist halt für,
das Individuum oder man kann das als Chance anschauen
oder einige sehen das vielleicht dann als Gefahr.
Und ja.
Genau.
Also das ist so.
Und ich glaube,
das haben wir auch gesehen,
für die einen ist das eine extrem spannende Reise
und für die anderen war es wahrscheinlich nicht nur angenehm.
Das ist definitiv so.
Habt ihr noch ein paar andere Herausforderungen meistern müssen?
Also du hast vorhin davon gesprochen,
klassische Projekte, klassische Probleme.
Jetzt ist ja im agilen Umfeld auch nicht alles toll.
Also welche Probleme siehst du denn für euch,
für dich aus eurer Erfahrung aus den agilen Vorgehensweisen?
Also ich würde sagen,
das Schöne an dieser Vorgehensweise ist ja,
dass man eigentlich permanent wieder drauf schaut
und ein Learn und Adapt macht.
Und so sind wir auch in der Transformation vorgegangen.
Also wir haben viele Dinge,
haben wir einfach mal ausprobiert in einem kleinen Team,
haben geschaut, ob es funktioniert
und wenn es nicht funktioniert hat,
haben wir es angepasst.
Und so haben wir zum Beispiel auch dann irgendwann gesehen,
also die Frage ist ja immer,
wenn man autonome Teams hat.
Autonome Teams sind gut
und die sind auch extrem wichtig,
aber es geht nicht nur mit der Autonomie,
sondern es kommt,
irgendwann kommt dann die Frage auch nach dem Alignment auf.
Und das haben wir so ein bisschen gelernt.
Zuerst waren wir wahrscheinlich zu fest nur auf Autonomie
und haben dann gesagt,
okay, jetzt müssen wir etwas Alignment reinbringen
und haben dann Save als dieses Konstrukt mit reingebracht.
Und so denke ich schon,
das ist das Schöne,
dass man eigentlich permanent wieder sieht,
was hat funktioniert,
was müssen wir anpassen
und dass man dann diese Dinge auch anpassen kann.
Wenn ich jetzt die jetzige Situation anschaue,
dann sind wahrscheinlich
die grössten Herausforderungen,
sind so die Themen,
dass man,
diese Veränderung braucht Zeit.
Man hat so ein bisschen die Tendenz,
nach einer gewissen Zeit wieder in alte Muster zurückzufallen
und da braucht es sehr viel Ausdauer
und eine konstante und gleichbleibende Kommunikation
und eben auch Coaches,
die einen da unterstützen,
dass man in die Richtung geht.
Aber auch das Thema mit
dem Involvement von den Business-Abteilungen,
sind so,
da kommen ganz viele Themen hoch.
Wie stellen wir sicher,
dass Business sich auch auf diese Arbeitsweise anpassen kann
oder davon profitieren kann?
Das geht dann hin bis zu Shop-Mitarbeitenden
oder Leuten,
die im Call-Center arbeiten,
die davon betroffen sind,
wenn wir auf einmal,
zweimal pro Monat neue Releases
in die Produktion bringen,
statt wie bis anhin
nur dreimal im Jahr.
Also die Herausforderung gibt es immer,
aber was mir gefällt,
die Idee vom agilen Team,
dazu gehört dann auch Learn and Adapt,
das heisst dann eben auch
aus diesen Herausforderungen
denen begegnen
und dann daraus lernen.
Und dann, was ich herausgehört habe,
was ich spannend finde,
eben dann agil wirklich im doppelten Sinn,
also einerseits schon das agile Team,
aber die Transformation selber,
wie sie gesteuert wird danach
auf eine agile Art und Weise.
Das finde ich ganz, ganz wichtig,
weil gerade weil es ja eine Kulturänderung ist,
da ist der Vorbildcharakter immens wichtig.
Und wenn man jetzt eine agile Transformation
als ein klassisches Projekt aufsetzt,
dann bin ich der Überzeugung,
dass das nicht funktionieren kann,
sondern diese agilen Prinzipien,
die müssen auch in die Transformation mit einfließen.
Ja, in dem Kontext würde mich,
und ich denke auch die Zuhörer,
noch die Frage interessieren,
auch zur bimodalen IT, oder?
Weil es ist ja,
ich denke jede Enterprise IT
oder jede Firma macht jetzt Erfahrung mit,
oder hat schon seit längerer Zeit Erfahrung
mit agilen Teams,
vielleicht sogar Richtung DevOps,
aber viele machen ja dann den bimodalen Ansatz
und sagen ja,
in gewissen Bereichen,
da macht Agile Sinn,
vor allem dort,
wo halt viel Veränderungsdruck, Risiken
und da gibt es auch einen Bereich,
der wird einfach klassisch weitergefahren.
Wie steht da die Swisscom dazu?
Wir haben den Weg auch gemacht
und ich würde mal sagen im 2016
oder Mitte 2016 haben wir auch gesagt,
wir wollen den Weg gehen,
wir wollen Richtung bimodale IT gehen
und zu dem Zeitpunkt,
hatten wir noch den Eindruck,
dass wir mit dem agilen Teil relativ klein beginnen
und das über die Zeit aber immer stärker wächst
und am Schluss vielleicht so eine 70-30 Verteilung von Agile
und zu den Systems of Record sind.
In der Zwischenzeit sind wir aber der Überzeugung,
dass die bimodale IT eigentlich keinen Sinn macht,
wir diese Trennung zwischen Focus on Stability
und Focus on Agility,
der macht für uns eigentlich nicht so viel Sinn,
weil auch agile Systeme müssen stabil sein,
die müssen robust sein,
die müssen 100% Qualität liefern
und auf der anderen Seite
gibt es immer weniger Systeme,
wo man sagen kann,
die sind jetzt einfach da
und da muss man nichts mehr machen
und wir haben auch ein bisschen gemerkt,
dass es eine Zweiklassengesellschaft gibt
und dass es auch für die Kultur gar nicht gut ist,
dass man dann so sagt,
ja, ich bin im neuen und im agilen Teil
und alle anderen sind auf dem Abstellgleis
und diese Notation,
die haben wir irgendwie nicht rausgebracht
und deshalb haben wir auch gesagt,
nein, es gibt eigentlich nur einen Weg
und das ist der Weg der Agilität.
Wasser auf meine Mühlen,
ich bin ja auch ein Gegner sozusagen von bimodaler IT,
also insofern freut es mich,
dass ihr eure Erfahrungen auch gemacht habt
und nachdem ihr die Erfahrungen gemacht habt,
zu der Entscheidung gekommen seid,
zu der Einschätzung gekommen seid,
bimodaler IT macht keinen Sinn,
wenn man es wirklich richtig macht
und was ich auch interessant finde,
ist die Aussage,
dass natürlich auch agile Teams
auch Stabilität liefern müssen
und das auch können,
also das ist jetzt ja nichts Besonderes,
zumindestens aus meiner Sicht,
wenn ich agil entwickle und Betrieb mit dazu nehme,
also DevOps,
dass ich dann eben auch wirklich
schnell liefern kann,
schnelle Zyklen habe
und trotzdem Stabilität,
ich sage mal, ins Team natürlich reinbringen
und auch in die Applikation,
die ich bereitstelle, den Service.
Absolut, absolut, ja genau
und da hilft ja auch die ganze Automation,
also wenn ich die Tests automatisiert habe,
wenn ich die Deployments automatisiert habe,
wir haben es auch so aufgesetzt,
dass wir immer die Teams,
wir glauben dort an den Satz,
you build it, you run it,
also das heisst,
bei uns ist das Entwicklungsteam
immer auch für den Betrieb
ihrer Applikationen verantwortlich
und mit dieser Aufteilung
braucht man keinen Handover in dem Betrieb mehr
und mit dieser Aufteilung bedeutet das aber auch,
wenn ich etwas falsch
oder wenn ich einen Fehler in der Entwicklung mache,
dann sehe ich direkt die Auswirkungen im Betrieb
und kann daraus lernen
und kann es dann das nächste Mal wieder besser machen.
Ja, ich meine, es ist ja auch ein bisschen,
also einfache Psychologie,
oder wenn ich natürlich jetzt,
wenn ich, klar, ich kann agil arbeiten,
ich bin im Dev-Team,
aber wenn ich sage,
ja gut, betreiben muss es ja dann ein anderer
und das ist mir ja egal,
wenn es dann nicht so stabil ist,
aber wenn man,
wie du sagst,
you build it, you run it,
dass man dann wirklich als Team Verantwortung übernimmt,
dann überlegt man sich eben zweimal,
ob das, was man baut,
das auch bezüglich Stabilität
und man übernimmt dann wirklich die End-to-End-Verantwortung.
Das, ja.
Da geschehen dann auch ganz spannende Sachen,
wo man, wenn man die Teams dann,
oder als wir die Teams neu aufgebaut haben
und die Leute zusammengesetzt haben,
wo zum Teil Leute aus dem Betrieb
eigentlich vorher gar nicht mit den Leuten
aus der Entwicklung gesprochen haben
und wenn die dann zusammen angeschaut haben,
wie die die Deployments machen,
dann sehr schnell Optimierungspotenzial aufgekommen ist,
dass man gesagt hat,
hey, das kann ich doch schon im Code einbauen,
dann musst du es nicht mehr manuell machen,
dass man so eigentlich noch schon
durch das gemeinsame Verständnis
zu besseren Lösungen gekommen ist.
Ja.
Und hat da dann auch so ein T- oder P-Shaping,
hat das auch stark,
dass dann plötzlich Leute,
die sagen wir aus dem klassischen,
früher einfach nur klassische Betriebsaufgaben,
wie du sagst,
die haben fast selten mit wirklich Entwicklung gesprochen,
dass sie dann sich Richtung Entwicklung bewegt haben,
plötzlich solche Tase und umgekehrt auch Entwickler,
die dann zum Beispiel innerhalb des Sprints
dann gewisse Aufgaben übernommen,
die sonst der Betrieb gemacht hätte?
Das ist ganz klar das Ziel,
dass wir das erreichen müssen.
Genau in die Richtung möchten wir gehen.
Was man aber auch sagen muss ist,
das ist etwas, das wieder Zeit braucht.
Es ist einfach, die Teams zusammenzulegen.
Es ist einfach zu sagen, wir wollen das.
Wir machen zum Beispiel in der Rolle,
machen wir keine Unterscheidung mehr
zwischen Entwickler und Betrieb.
Wir sagen, beide sind DevOps-Ingenieurs.
Da gibt es keine Unterscheidung in der Rolle.
Aber was man schon merkt,
das kann man schnell machen.
Die Rollen anpassen geht einfach,
die Teams zusammenstellen,
das geht auch einfach.
Aber wirklich der Skills-Aufbau,
das ist etwas, das sehr viel Zeit braucht.
Und das versuchen wir dann auch zu unterstützen,
zum Beispiel durch so Communitys,
durch so Community of Practice,
wo wir die Leute zusammenbringen,
wo wir Ausbildungsinitiativen machen,
damit man über die Zeit
so einen T- oder P-Shape aufbauen kann.
Aber das geht nicht von heute auf morgen.
Das ist wirklich ein Invest.
Also Community of Practice,
wir haben jetzt viel über die Swisscom gesprochen.
Über Community of Practice sagen wir intern,
dann auch Skills weiterzuentwickeln.
Aber es ist ja auch,
DevOps ist ja auch stark eine Community,
die DevOps Days oder auch DevOps Meetups,
wo dann der Austausch
firmenübergreifend stattfindet.
Wie haben wir auch in der Einleitung gesagt,
du hast die DevOps Days Schweiz initiiert,
mitinitiiert.
Was war da der Grund auch dafür
oder auch die Motivation jetzt aus Swisscom Sicht?
Der Punkt ist,
eigentlich haben wir zuerst rein intern angefangen.
Wir haben gesagt,
wenn wir diese autonomen Teams haben
und denen auch die Freiheit geben wollen,
die Dinge so zu tun,
wie sie es tun wollen,
dann möchten wir trotzdem,
dass sie voneinander lernen.
Und deshalb haben wir gesagt,
okay, lass uns möglichst
ein niederschwelliges Angebot aufbauen,
wo wir den Leuten mehr oder weniger
nur eine Plattform geben,
sich gegenseitig auszutauschen.
Und das Resultat war wirklich beeindruckend.
Es hat so viel gute Kommunikation
und gegenseitige Befruchtung auch stattgefunden,
dass wir gesagt haben,
eigentlich ist es schade,
wenn wir das nur innerhalb von der Swisscom machen,
weil wir sind extrem überzeugt,
dass wenn wir das auch mit anderen Leuten
aus der Industrie teilen,
dass wir gegenseitig voneinander lernen können.
Und das war dann eigentlich die Motivation,
weshalb wir erst ein Meetup aufgebaut haben
mit Leuten, wo wir Kontakt dazu hatten,
auch von anderen Firmen.
Und aus diesem Meetup,
das hatte einen sehr starken Zulauf,
waren auch immer sehr, sehr spannende Begegnungen,
die wir dort haben.
Und dann haben wir gesagt,
okay, das müssen wir jetzt einfach weiterziehen
und haben letztes Jahr zum ersten Mal
die DevOps Days organisiert.
Und dieses Jahr, am 2. und 3. Mai,
finden sie zum zweiten Mal statt.
Und eigentlich genau um diesen Geist,
dieses gemeinsame Teilen und Voneinanderlernen,
um das zu fördern.
Ich war da letztes Jahr auch dabei.
Ich kann das sehr empfehlen.
Also ich werde auch dieses Jahr
wieder an die DevOps Days gehen.
Das ist schlussendlich auch ein super Austausch,
um gegenseitig zu lernen, voneinander.
Was auch noch,
was vielleicht die Zuhörerinnen und Zuhörer
interessieren würde,
so wiederum,
um auf die Swisscom zu schwenken.
Wir haben darüber gesprochen,
eben das Warum, die Motivation,
dann wie habt ihr gestartet,
den Ansatz, den ihr gewählt habt.
Wir haben gelernt,
das ist eigentlich eine Reise,
die nie aufhört.
Was sind so,
wenn man jetzt über die Zukunft spricht,
was sind jetzt so die nächsten Dinge,
die ihr im Rahmen der DevOps Transformation
angehen wollt?
Ja, das Thema,
es gibt eigentlich wie so drei Hauptthemen,
die wir angehen im Moment.
Das eine ist,
und das ist extrem schön,
hat mich sehr gefreut,
dass Agilität jetzt wirklich
bis in die Konzernleitung gekommen ist
und die Konzernleitung sich auch
ganz klar dazu committed hat,
gesagt hat,
wir wollen das auf die ganze Firma ausrollen.
Und das ist extrem spannend.
Es gibt natürlich auch wieder
ein paar spannende Herausforderungen,
also wie,
dass wir das Ganze angehen können.
Und dann ist ein Thema,
das Ganze,
die Thematik mit der Portfolio,
Steuerung,
also die ganze Finanzierung
war bisher sehr stark im Projektfokus.
Also wir haben eigentlich Projekte finanziert.
Und wenn man das agile Gedankengut weiterdenkt,
dann sollte man ja eher hingehen
und sagen,
wir finanzieren stehende Teams
oder ich sage mal Portfolio-Epics,
die aus solches dann finanziert werden.
Und das hat dann natürlich
auf diesen ganzen Portfolio-
und Finanzierungsaspekt,
das ist eine grosse Auswirkung.
Das ist so der zweite Teil,
wo wir dran sind.
Und der dritte Teil,
dort geht es dann sehr stark um
die ganzen Personalprozesse,
um HR-Themen,
wo man so mit den klassischen Ansätzen,
die stehen auch im Konflikt
mit dem agilen Gedankengut.
Also es geht um das Thema Anstellung
von neuen Mitarbeitenden.
Es geht um das Thema Beurteilung,
aber auch Entwicklung und Entlöhnung.
Und da möchten wir die Prozesse
unter die Lupe nehmen,
möchten schauen,
wie wir stärker das agile Gedankengut
auch in die Prozesse reinbringen.
Ja, sehr gut.
Ich habe nochmal einen anderen Punkt
und das ist das Thema Mindset, Kulturwandel.
Ich stelle bei vielen meiner Kunden fest,
dass das zumindest aus meiner Sicht
oftmals auch eine Art Generationenfrage ist.
Also ältere Mitarbeiter oder Mitarbeiterinnen
gehen mit dem Thema anders um als Jüngere.
Ich bin mir am überlegen,
ob ich dem zustimmen kann oder nicht.
Ich glaube, ich würde es nicht so pauschal sagen.
Ich habe vieles erlebt.
Ich habe schon ältere Mitarbeiterinnen
und Mitarbeiter erlebt,
die mit Freude und als Vorbild
eigentlich den agilen Weg gegangen sind.
Und ich habe das andere aber auch schon erlebt,
dass wir bei jüngeren Mitarbeitern
sehr grosse Schwierigkeiten haben.
Vielleicht ist es in der Tendenz
ein bisschen so, wie du es sagst, Dirk.
Aber ganz generell würde ich das nicht unterstützen.
Ich glaube, es kommt viel stärker
auf die Haltung des Menschen an
und auch auf die Neugierde und Bereitschaft,
etwas Neues anzugehen.
Und weniger zu sagen,
und wenigerhaft zu sagen.
Okay, ja.
Ich polarisiere manchmal etwas,
um so ein paar Aussagen rauszuhören.
Und insofern kann ich damit leben,
dass du mir vielleicht nicht ganz zustimmst.
Und letzten Endes liegt die Kunst darin,
die Leute zu unterstützen, zu coachen
und die Leute auch in die richtigen Teams zusammenzupacken.
Also vielleicht den eher zurückhaltenden
oder ablehnenden jungen Mitarbeiter
mit begeisterungsfähigen älteren Mitarbeiterinnen
zusammenzupacken,
dass man da genau einen schönen Mix im Team findet.
Genau.
Und ich glaube, es gibt ja auch da wieder Leute,
die nicht wollen.
Ich glaube, von denen werden wir uns
über kurz oder lang trennen müssen.
Also all die Leute, die sagen,
nein, das will ich nicht.
Ich kann nicht umgehen mit so viel Transparenz.
Ich möchte nicht so eng
mit anderen Leuten zusammenarbeiten.
Ich glaube, das muss man respektieren.
Dass die Leute das nicht wollen.
Dann sind wir aber wahrscheinlich
die falsche Firma für diese Personen.
Und all die Leute, die sagen,
ja, ich will,
aber ich habe vielleicht die Fähigkeiten dazu noch nicht.
Die kann man dann eben mit Ausbildungsmassnahmen,
mit Coachings dazu bringen,
dass die prima in einem solchen Setup funktionieren können.
Also können versus wollen auch.
Du hast ja die erste Gruppe,
die du angeschaut hast.
Also ich sage denen so die No-No’s.
Ich meine, ich bin selber wahrscheinlich
auch schon mal No-No gewesen.
Aber dann ist es auch schön,
dass wenn man selber einsieht,
dann ja eigentlich ist es nicht der richtige Ort für mich.
Ich werde woanders glücklicher.
Ich mache manchmal so die Unterscheidung,
es gibt die Skeptiker auch,
die haben zum Teil auch gute Gründe.
Aber dann gibt es ja auch,
die nenne ich so die Die-Hearts.
Also Die-Heart ist so,
wenn jemand die Frage stellt,
wo möchtest du in fünf Jahren sein?
Und dann kommt die Antwort,
ja, ich will genau dort sein,
wo ich jetzt bin.
Also die fühlen sich extrem wohl
in ihrer Komfortzone.
Sie sagen,
ja, habt ihr dieses Phänomen auch?
Dann Leute, die,
sie sind nicht aktiv dagegen,
aber sie fühlen sich einfach extrem wohl
in ihrer Komfortzone.
Ich finde es eine gute Aufteilung,
die du machst.
Und solche Leute gibt es sicher auch.
Das ist ganz klar.
Und dort ist die Kunst,
die dann trotzdem zu begeistern
und trotzdem zu überzeugen,
dass es der richtige Weg ist.
Und da habe ich auch schon
ganz viele schöne Beispiele von Leuten,
die zuvor nicht aktiv dagegen waren,
aber vielleicht auch nichts dafür gemacht haben,
die wir dann mit schönen Beispielen
begeistern konnten.
Und wenn du die mal transformiert hast,
das sind deine größten Supporte
dann auch für dich.
Spannend.
Ja, also,
ich weiß nicht,
wie es dir geht, Alex.
Ich bin durch mit meinen Fragen.
Ich denke,
wenn ich so zurückblicke,
haben wir wirklich wieder
viele Dinge angesprochen.
Ich finde,
es ist wieder ein sehr interessanter Podcast
wieder geworden.
Oder hast du noch Fragen?
Ja.
Ich habe keine Fragen mehr.
Nein, ich fand es auch,
ich fand das super spannend.
Jetzt auch anhand von,
in der Praxis war es schon ein Kunde,
der eigentlich auch schon,
also aus dem Swisscom,
die schon ein Weilchen unterwegs ist
auf dem Gebiet.
Und das ist natürlich besonders wertvoll,
denke ich,
für die Zuhörerinnen und Zuhörer.
Aber soweit keine Fragen mehr.
Martin, dann würde ich sagen,
dann einen herzlichen Dank,
dass du dir die Zeit genommen hast,
dass du so ausführlich berichtet hast
über das,
was ihr so macht bei der Swisscom
oder auch gemacht habt,
dass ihr über euren Weg.
Und ja,
vielleicht sieht man sich ja auch mal
in der Realität.
Also von mir einen herzlichen Dank
und auf Wiederhören.
Besten Dank auch.
Macht’s gut.
Tschüss miteinander.
Yes,
tschüss.
Okay.
tresing mit einem
von 은