Focus on Your
Business

Ich habe Marian zu Gast, der als Product Owner für die agile Transformation in einem Konzern für den IT-Betrieb tätig ist. Es ist eine sehr interessante Folge voll mit hörenswerten Erlebnissen und vor allem Tipps aus der Praxis am Ende der Folge. Wir erfahren, was Nike mit DevOps zu tun hat, wie Marian mit Ängsten, Fragen und Widerständen der Kollegen umgegangen ist, wie die beiden Rollen Service Manager und Product Owner zusammengeführt wurden, was Lipstick Agile ist und was das grundsätzliche Ziel und die Motivation bei seinem Projekt war/ist.

n dieser Podcast-Episode wird die Agile und DevOps Transformation in einem großen, operationslastigen Unternehmen ausführlich diskutiert. Der Gast Marian, ein Product Owner des Unternehmens, teilt seine Erfahrungen und Herausforderungen, von der Einführung von Agile und DevOps bis hin zur Anpassung der Unternehmenskultur und dem Aufbau eines neuen Verantwortungsbewusstseins bei den Mitarbeitern. Besonders wird auf die Bedeutung des Mindsets, die Rolle des Managements und die Anpassung an lokale Besonderheiten eingegangen. Der Wandel des Unternehmens hin zu einer agileren und effizienteren Arbeitsweise wird als ein fortlaufender Prozess beschrieben, der sowohl Herausforderungen als auch Chancen bietet.

Inhalt

• Marian stellt sich vor: Agile Transformation in einem Großkonzern
• Die Bedeutung von DevOps aus Ops-Sicht
• Herausforderungen beim Übergang zu Agile und DevOps
• Rolle des Managements und Kulturwandel im Unternehmen
• Die Implementierung von Agile und DevOps in internationalen Teams
• Diskussion über Trainings, Literatur und Knowledge Transfer
• Der kontinuierliche Prozess der Transformation und die Zukunft von Agile und DevOps im Unternehmen

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und
ins Hirn.
Mein Name ist Dirk Söllner.
Ich begleite Unternehmen auf dem Weg zu einer hochperformanten IT-Organisation.
Als Berater, Trainer und Coach mache ich Teams und Menschen erfolgreich, um die aktuellen
Herausforderungen bewältigen zu können.
Ich freue mich heute auf das Thema DevOps aus Ops-Sicht.
Allein zum Aussprechen schon mal ein schwieriges Thema, kann man sich gleich mal verhaspeln.
Zu Gast habe ich Luca Injani und Marian, der sich gleich selbst vorstellen wird.
Die regelmäßigen Hörer des Podcasts kennen Luca bereits aus der letzten Folge und aus
der April-Folge des letzten Jahres.
Warum ist Luca schon wieder dabei?
Hier gleich die Neuigkeit.
Luca und ich werden diesen Podcast zukünftig gemeinsam betreuen.
Details dazu erläutern wir euch am Ende dieser Folge.
Luca betreut die Organisation von Marian als Trainer und Coach und hat insofern auch heute
ein bisschen was zu erzählen.
Hallo Marian, magst du dich kurz selbst vorstellen?
Gerne, danke Dirk, danke Luca für die Einladung.
Meine aktuelle Rolle lautet Product Owner.
Für die agile Transformation in einem münchenbasierten Großkonzern.
In unserem Fachbereich werden vor allem Workplace-Services geliefert rund um den Arbeitsplatz und wir
sind besonders relevant in der heutigen Zeit von Covid, wo wir mit Hilfe unserer Services
ermöglichen, unseren Kollegen, Mitarbeiter, Kunden und Partner.
Zusammen zu kollaborieren aus verschiedenen Ecken der Welt.
Zu meiner Person.
Ich bin 31 Jahre alt, bin seit einem Jahr ungefähr in der Agile Journey, also in der
Agile Transformation und habe Luca auch ganz am Anfang kennengelernt und ich freue mich
auf den heutigen Austausch.
Ja, ich freue mich auch, weil es immer schön ist, wenn jemand aus der Praxis berichtet
an der Stelle.
Und.
Wir sind ja hier im DevOps-Podcast und da, die regelmäßigen Hörer werden es kennen,
bitte ich meine Teilnehmer immer um ihre persönliche Definition von DevOps.
Marian, wie würdest du DevOps definieren?
DevOps ist für mich die Art und Weise, Kollegen, Mitarbeiter und Kunden zu ermöglichen, dass
wir schneller etwas besser und.
In höherer Qualität, kleine, nichtsdestotrotz regelmäßige Funktionalitäten, Features an
die jeweiligen Gruppen zu liefern.
Finde ich interessant, wenn man da mal reinhört.
Du hast Kunden, glaube ich, mit drin in deiner Definition.
Das heißt, für dich gehört Kunde zu DevOps mit dazu?
Ja, ganz kurz und unprägnant.
Ja, wir glauben.
An die kontinuierliche Feedback-Loops mit den Kunden, mit unseren End-Usern.
Wir wollen nur Sachen liefern, die relevant für unsere Kunden sind und somit alles andere
als Waste zu betrachten und auf eine oder andere Weise beseitigen.
Klingt super interessant.
Thema ist ja DevOps aus Ops-Sicht.
Insofern bin ich gespannt, was wir noch an Waste.
Waste und Verschwendung in der Ops-Seite oder auf der Ops-Seite rausfinden an der Stelle.
Gerne.
Warum habt ihr euch auf diese Agile Journey, hast du es, glaube ich, genannt.
Warum habt ihr euch auf diese Agile Journey begeben?
Ja, wir kommen aus einem Bereich, der sich ständig ändert.
Nämlich, wie gesagt, die Services rund um den Arbeitsplatz.
Und lass uns wieder mit den Kunden, lass uns wieder mit den End-Nutzern loslegen.
Was erwarten die?
Sie erwarten Features, Funktionalitäten, Produkte, die aus dem privaten Bereich kommen.
Also wir haben da als Wettbewerber Top-Unternehmen wie Google, Amazon, Microsoft, Spotify.
Also verschiedene Erwartungshaltungen werden auf dem beruflichen Arbeitsplatz,
auf dem Arbeitsplatz übertragen.
Zudem noch ist für die sogenannten Digital Natives oder für Gen Z,
also die Kollegen, die Kunden nach meiner Generation, ich betrachte mich selber als ein Millennial.
Schon ganz schnell, ne?
Ja, ich bin etwas älter mittlerweile.
Und für die ist die Arbeitsplatzerfahrung einer der wichtigsten Entscheidungsfaktoren, wo sie arbeiten möchten.
Also allein.
Durch diese erhöhten Benutzererwartungen hat es sich verdient, sich zu überlegen,
wie schnell können wir darauf agieren?
Wie schnell können wir uns auf diese Art und Weise anpassen?
Und dadurch kommt noch die Perspektive, ja, Workplace als Enabler von agilen Methodologien.
Für TARM.
Für unsere, für unseren Konzern.
Also wenn wir selber nicht agil kennen und nicht agil arbeiten,
dann können wir die Collaboration, Communication-Werkzeuge gar nicht anbieten.
Also haben diese doppelte Rolle, einmal als Angebot, aber dann auch als Nachfrage.
Jetzt etwas konkreter zu nennen, warum Agile oder warum DevOps bei uns.
Wir hatten,
im Unternehmen bei uns, ein starkes Silo-Denken, ein starkes Modell, der die Zusammenarbeit etwas verhindert hat oder zumindest nicht promoviert hat.
Zudem, wenn ich noch Arbeitsweise sage, hatten wir kaum Fokus auf die Arbeitsweise, hatten kaum Fokus auf die Entwicklung von,
ähm,
ähm,
ähm,
ja,
wie wir zusammen kollaborieren,
wie wir zusammen agieren,
ähm,
wie wir diese,
diese Wände,
diese Silos brechen,
sondern das war immer,
immer sehr auf Ergebnisse fokussiert,
also immer auf die What Seite,
also immer auf was wir liefern,
aber etwas wenig oder zu wenig auf wie wir es liefern.
Und, ähm,
das alles haben wir dann gepackt in einer neuen Strategie.
Ähm,
die, äh,
unsere eigene Strategie,
also wir haben gesagt,
wir wollen jetzt die Owner unserer Strategie sein
und haben all diese Trends und all diese Schmerzpunkte zusammengefasst
und schön in PowerPoint-Folien dargestellt.
Und da hat aber immer noch so ein bisschen der Anstoß gefällt.
Also PowerPoint an sich ist ja nicht genug, um agil zu starten anscheinend,
zumindest nicht bei uns.
Und dann gab es einen Wechsel in der Fachbereichsleitung,
wo der neue Chef-Chef-Chef ganz gut Agile kannte.
Der hat es schon erfolgreich in einer großen Bank umgesetzt
und das war der konkrete Anstoß, wie wir uns auf die Agile-DevOps-Journey
angegangen sind.
Ja, ich…
Ich fand das gerade so spannend, wie ich das gehört habe,
dass irgendwie die, sagen wir mal, die Schwierigkeiten,
die mit der bestehenden Organisation sich ergeben haben,
schon irgendwie bekannt und bewusst waren,
aber trotzdem musste dann der Anstoß anscheinend von außen kommen.
Es musste ein neuer Chef her, der gesagt hat, pass mal auf,
ab jetzt machen wir DevOps.
Oder ich weiß nicht genau, wie er das gesagt hat.
Das war genau so.
Wenn der Stein ins Rollen kommt.
Ah, okay.
Ja.
Also finde ich spannend.
Wie ist das denn dann eigentlich aufgenommen worden?
Das war zwiespaltig.
Also einerseits war so die Denke oder ist es immer noch so die Denke im Unternehmen,
wenn der Chef sagt, dann machen wir einfach mit.
Und haben viele Kollegen, das war der initiale Moment,
das Momentum, wo die Kollegen einfach mitgemacht haben.
Und bald haben die aber gecheckt,
hm, das ist ja nicht die agile Art und Weise.
Wir reden hier viel über Servant Leadership
und das ist nicht die Art und Weise,
wie man denken sollte, wenn man agil oder DevOps einführt.
Und das war auch einer der Knackpunkte,
wo wir gemerkt haben,
ja, die Kollegen wollen selber die Initiative übernehmen
und den Ownership und selber überlegen,
was die DevOps-Theorie, was die DevOps-Prinzipien
in ihrem Alltag bedeuten.
Und wir haben weniger und weniger dann dieses Argument benutzt.
Der Chef hat es gesagt und mehr und mehr gecoacht
und mit den richtigen Fragen, mit den richtigen Workshops und Trainings
das Mindset promoviert.
Du hast es gerade schon gesagt, Trainings und Coaching.
Das ist auch mal die Frage, wie man sich dieser Thematik stellt,
wie man,
wie man DevOps einführt,
wobei auch da werden die regelmäßigen Hörer wissen,
ich mag den Begriff einführen nicht,
aber das können wir gleich nochmal klären.
Wie habt ihr euch denn vorbereitet?
Weil ihr habt ja, ich habe verstanden,
ihr habt PowerPoint-Folien gehabt,
ihr habt einen neuen Chef bekommen.
Wie habt ihr euch dann vorbereitet?
Ganz einfach.
Wir haben so nach dem Nike-Prinzip gesagt,
just do it.
Haben einige Teams als Team,
haben Vorläufer definiert, das waren drei bis fünf Teams,
wo die Produkte gepasst haben zu einer agilen DevOps-Entwicklung
und haben da erst mal gefragt, wer möchte Product Owner sein,
wer möchte Scrum Master sein.
Und für jeden dieser Squads haben dann auch einen sogenannten
Change Leader dazugenommen.
Also das war der Change Leader.
Also das war der Change Leader.
Also das war der Change Leader.
Also das war der Change Leader.
Also das war der Change Leader.
Also das war der Change Leader.
Also das war der Change Leader.
Also das war der Change Agent, der praktisch die Barrieren beseitigen sollte,
damit sich der Squad betreut fühlt, agil zu arbeiten.
Und dann haben wir gesagt, haben wir kaum was vorgegeben,
haben nicht mal das Tool zum Backlog vorgegeben
oder nicht mal die Meeting-Struktur.
Und haben nach einem Monat, also sprich nach zwei Sprints,
aha, wir haben doch die Sprint-Laufdauer bestimmt,
das waren zwei Wochen.
Also nach zwei Sprints haben wir gesehen,
haben fünf verschiedene Teams,
haben fünf verschiedene Versionen von den Backlogs.
Und das hat stark variiert.
Und wir haben verschiedene Art und Weisen.
Wir haben gesagt, okay, wir sollten das doch etwas standardisieren.
Und wir sollten doch ein zentrales Support der Kollegen anbieten.
Und da ist, wo wir angefangen haben,
Expertise von der Außenwelt zu holen,
sprich verschiedene Trainings.
Und Coaches interviewt und zufällig mit verschiedenen Unternehmen
Workshops gehalten.
Was bedeutet ja Agile und was bedeutet DevOps?
Und was ist für uns relevant?
Und was passt überhaupt zu unserem Umfeld?
Und was ist eher nicht anwendbar?
Das war ganz am Anfang.
Okay.
Du hast ja gerade ein paar Fachbegriffe auch nochmal genutzt oder eingeführt.
Du hast von Scrum-Mastern gesprochen,
du hast von Spotify-Modell gesprochen.
Okay.
Du hast auch gesagt,
ihr habt euch nicht oder habt den Teams nicht viel vorgegeben.
Sprintlänge zwei Wochen.
Allein das ist ja schon mal eine Vorgabe,
wenn man von Sprints spricht.
Aber also soll es keine Wertung sein.
Spotify kennt ja keine Scrum-Master.
Also vielleicht kannst du noch ein bisschen was dazu sagen,
wie sich die Teams entsprechend aufgestellt haben.
Weil man könnte ja auch sagen,
okay, sie brauchen keinen Scrum-Master.
Sie organisieren sich selber.
Ich brauche nur einen Product-Owner.
Und selbst das ist ja schon,
ein Fachbegriff aus einer Methodik.
Vielleicht kannst du dazu noch ein bisschen was sagen.
Ja.
Die Frage ist relativ einfach.
Wir haben von Anfang an das ausgewählt
und das übernommen, was uns passt,
was uns gefällt.
Und zwar auf verschiedenen Ebenen.
Also auf der Team-Ebene haben wir
wenig vorgegeben.
Sprich, die Rollen waren nicht obligatorisch.
Keiner wurde dazu gezwungen, das zu übernehmen.
Und auch außer Scrum konnte man auch Kanban machen,
sobald man sich an die agile Prinzipien hält,
also an das Agile Manifesto.
Gut, wenn ich jetzt überlege,
es ist auch eine gewisse Vorgabe,
aber gut, irgendwie muss man dann agil am Anfang erklären.
Und das ist auch eine gewisse Vorgabe.
Und das war erst mal auf der Team-Ebene.
Und dann kam die Transformationsebene.
Also wie wollen wir jetzt diese Squads,
diese agile Teams,
sagen wir erst mal Teams, auch ohne Squads,
wie wollen wir die weiterskalieren?
Und dann haben wir uns verschiedene Modelle angeschaut
und was passt jetzt uns bestens
und haben aus verschiedenen Bereichen
verschiedene Fachbegriffe übernommen,
was ja bei uns,
was Sinn gemacht hat.
Jetzt ein Beispiel vom Spotify-Modell,
natürlich Squad und Chapter.
Wir agieren nicht aber nach dem Spotify-Modell.
Das ist eher unsere eigene Art und Weise
und das ist, was wir uns auch bestreben haben,
zu sagen, wir haben unsere eigene Art und Weise.
Wir sind die Owner von unserer Arbeitsweise
und wir machen nur das, was Sinn macht.
Und konkret zum Product Owner,
das hat aus der Geschichte gut gepasst.
Davor hatten wir die sogenannten Service Manager.
Das ist ein, sobald ich weiß, ein Eitel-Konzept.
Und es war schon so etabliert,
dass man in der Organisation für einen Service
oder Produkt einen Service Manager hat.
Und diesen Bedarf hat weiterhin bestanden.
Deswegen haben wir auch nach einigen Workshops überlegt,
okay.
Die Product Owner-Rolle macht auf jeden Fall Sinn,
dass wir sie in dem zukünftigen Setup auch übernehmen.
Wenn ich das richtig verstehe,
habt ihr also den Product Owner quasi als wichtige Rolle erkannt,
übernommen und habt den Service Manager,
wie er früher da war,
ich sag mal umfunktioniert, umbenannt,
kann man das so sagen?
Wir haben auf jeden Fall die Aufgaben
und die Verantwortung umgeschiftet.
Von der alten in der neuen Rolle.
Wir haben aber auch von Anfang an klar gesagt,
dass Service Manager nicht gleich Product Owner ist,
sondern das beinhaltet auch das neue Setup von den Squads,
wo sowohl die Product Owner als auch die Team-Member empowert sind
und die Initiative haben und die end-to-end Verantwortung haben,
wie sie ihre Arbeitsweise,
wie sie ihre Arbeitsweise gestalten.
Wie lief das dann?
Was habt ihr denn dann für Erwartungen gehabt?
Ich meine, oder die gesamte Belegschaft,
was haben die sich denn vorgestellt,
wie das laufen würde?
Was war denn so das Gefühl,
mit dem man da reinging in die ganze Sache?
Es gab kein einziges Gefühl.
Das war so eine Mischung aus verschiedenen Gefühlen.
Die Kollegen und Partner,
und die Teilnehmer waren einerseits enthusiastisch,
die haben sich gefreut, dass sich endlich mal was ändert.
Und der Mehrwert von Agile und von DevOps
wurde bei bestimmten Kollegen schnell erkannt.
Und die haben sich schnell gefreut,
dass wir die langen Projekte und oder Programme ändern durften,
dass wir die klassischen Projektleitungen,
die wir im Bereich der Verhandlungsthemen und Gantt-Charts
durch andere Tools und Arbeitsmethoden ersetzen.
Gleichzeitig kam aber auch etwas an Angst,
etwas an Resistenz.
Wie ändert sich mein Arbeitsalltag?
Wie ändert sich die Arbeitsweise mit den Kollegen?
Was heißt jetzt mehr Verantwortung für mich,
im Positiven als auch im Negativen Sinne?
Wie ändert sich mehr Transparenz im Backlog?
Heißt das auch, dass mich jetzt einer trackt?
Ist das jetzt der Product Owner?
Wer darf jetzt in den Backlog überhaupt reinschauen?
Und in Bezug auf DevOps,
warum muss ich jetzt den anderen Bereich lernen,
sei es Dev, sei es Ops?
Warum muss ich mehr Verantwortung übernehmen
aus dem, wie gesagt, anderen Bereich?
Das war eher schon davor klar definiert.
Ist das alles irgendwie Wischiwaschi?
Ist das jetzt so oder wie soll ich mir das vorstellen?
Das waren all die Fragen, die meine Kollegen beschäftigt haben
bei der agilen Transformation.
Also, wenn man so will, weniger eigentlich Sorge
vor konkreten Dingen, sondern Sorge genau
vielleicht aus einem noch nicht so vollständigen Verständnis.
Man hat sich gefragt, was kommt denn jetzt nach?
Genau.
Ja, also viel rund um Denkweise,
rund um Verhalten, rund um die Unternehmenskultur.
Eher auf der Ebene als auch auf Arbeitsebene.
So, darf ich das, so diese Art?
Genau.
Jetzt hast du ein paar Sachen angesprochen,
die ich super interessant finde.
Also, es gab nicht ein Gefühl.
Es gab ein Gefühlsset quasi von positiven wie negativen Gefühlen.
Wenn ich jetzt mal überlege,
ich habe ja vorhin gesagt, ich mag den Begriff DevOps einführen nicht.
Und vielleicht kann ich jetzt genau sagen,
warum ich den Begriff nicht mag,
weil der für mich suggeriert, dass man irgendwann fertig ist.
Also, irgendwann hat man etwas eingeführt und dann ist man fertig.
Und das ist meiner Meinung nach eben eine falsche Einstellung.
Ich glaube, dass man quasi, wie ihr es ja auch gemacht habt,
erst mal anfangen muss und dann sich schrittweise nach und nach verändern
und damit auch verbessern muss.
Manchmal macht man auch vielleicht gefühlte Rückschritte,
wenn man feststellt, irgendwas passt nicht.
Das heißt, es ist eigentlich kein klassisches Projekt mit einem Ende,
mit einem Ende, definierten Ende, mit Abnahmekriterien,
sondern es ist eigentlich ein sich entwickelnder, permanenter Prozess.
Wenn du das auch so siehst, vielleicht die Frage dann nochmal dazu.
Wann habt ihr angefangen?
Also, wie lange seid ihr jetzt schon dabei?
Und wenn das überhaupt geht, wie lange wollt ihr noch einführen?
Wie lange soll das noch laufen?
Das ist eine sehr gute Frage,
weil wir uns auch schnell mit dieser Herausforderung getroffen haben.
Ja, ihr seid jetzt bloß das nächste Change- oder Transformation-Programm.
Ihr wollt wieder in sechs Monaten hier die Welt ändern
und dann seid ihr eher weg und dann müssen wir hier mit euren Vorgaben leben.
Wir sind jetzt seit einem Jahr in die Agile Transformation rein.
Wir haben Mitte Juli letzten Jahres angefangen.
Und ich kann nicht sagen, wann wir fertig sein würden.
Ich sehe keinen Endpunkt, wo wir sagen,
ja, ab jetzt sind wir so sehr zu 100 Prozent Agile oder DevOps,
dass wir jetzt das nicht mehr brauchen.
Vielmehr geht es um die Änderung zum Verhalten,
zum Mindset, dass wir sagen,
ja, wir haben die Ideen, die Methodologie, die Prinzipien verinnerlicht,
auch wenn wir die nicht auswendig kennen.
Die sind aber in unserem Arbeitsalltag sichtbar.
Und egal, was als Nächstes kommt,
also sei es DevOps 2.0 oder Agile, wie auch immer die nächste Stufe heißt,
wir sind dafür vorbereitet.
Durch unsere Tools, durch unsere Denkweise,
durch unsere Meetingstruktur sind wir auf jede Änderung vorbereitet.
Wir können in kürze Lebenszyklen, sorry, in kürze Lieferungszyklen liefern.
Wir können kürzere Zyklen uns verbessern.
Und wir sind jetzt viel mehr adaptiver, viel mehr dynamischer.
Das ist das Ziel.
Konkret, was das bedeutet, ist,
dass wir irgendwann mal auf diesem Transformation Team,
also sprich ein Team von Agile Coaches und Berater,
auf die interne Struktur umschiften sollen.
Und das ist schon vorgesehen, dass wir sagen,
ja, wir brauchen auf jeden Fall gewisse Fähigkeiten,
gewisse Capabilities intern.
Um ein Beispiel zu geben, was ein Scrum Master kann,
brauchen wir intern.
Und das wollen wir bei uns aufbauen.
Also das ist im Zielsetup so, dass wir sagen,
da sollen keine externen Berater diese Rolle betreuen.
Um vielleicht nochmal einzuhaken.
Ich hatte ja vorher gefragt, welche,
oder wir hatten vorher darüber gesprochen,
welche Sorgen gab es zu Anfang?
Gibt es die immer noch?
Und gibt es jetzt stattdessen irgendwie vielleicht neue Sorgen,
die jetzt aufgekommen sind im Laufe dieser fortschreitenden Transition?
Ja, das ist eine Reise, ein Journey.
Und einige der Probleme, die wir am Anfang entdeckt haben, sind jetzt weg.
Beispielsweise das Verständnis.
Warum machen wir das Ganze?
Und wie machen wir das Ganze?
Und was beinhaltet die eine oder andere Rolle?
Ich glaube, die Basics sind schon da.
Andererseits sind einige der initialen Sorgen verblieben.
Also was heißt das, wenn ich mit der Außenwelt agiere?
Sprich, die Außenwelt um mich herum ist immer noch nicht agil.
Diese Konfliktquelle, das bleibt leider bestehen.
Und da lernen wir immer noch, wie wir mit der Außen-non-agilen Welt
oder Non-Devops-Welt agieren.
Dazu sind neue Sorgen gekommen oder neue Herausforderungen,
aus denen wir gerade lernen.
Wie, jetzt um ein Beispiel zu nennen,
wie ich meine neue Rolle auswählen kann.
Agil gibt jetzt keine Hierarchien vor.
Und das tut DevOps auch nicht.
Was kommt jetzt nach Product Owner?
Oder was kommt nach DevOps Engineer?
Gibt es jetzt einen Senior DevOps Engineer oder einen Chief DevOps Engineer?
Und wenn nicht, was wird aus meiner Karriere?
Wie wird jetzt mein Performance-Bonus kalkuliert,
wenn ich jetzt keine Stufung nach oben bekomme?
Und wir lernen ständig.
Wir adaptieren auch unsere Vorgehensweise
in eher kurzfristige, regelmäßige Zyklen,
um diese Ängste zu beantworten.
Interessant.
Also nicht nur eure Arbeit wird agil, iterativ jetzt weiterentwickelt,
sondern auch der gesamte Rest der Organisationsstruktur.
Ich möchte gleich noch sagen,
weil ich das auch wiederum so spannend fand,
was du gesagt hast, dass ihr mit eurer neuen Art zu arbeiten
jetzt den Rest des Unternehmens irgendwie vor neue Herausforderungen stellt.
Kannst du das noch ein bisschen vielleicht an einem Beispiel konkretisieren?
Was ist denn da passiert?
Und wie hat denn das Rest vom Business darauf reagiert,
dass ihr jetzt auf einmal ganz neu seid?
Ja, gerne.
Und zwar viele Bereiche haben,
haben täglich Austausch mit uns.
Also wir haben mehrere Abhängigkeiten
und mehrere Partner, damit wir unseren Services liefern,
sowohl intern als auch extern von der Organisation,
von dem Konzern.
Und je nach Ansprechpartner hatten wir verschiedene Reaktionen.
Also einige Ansprechpartner,
haben gesagt, ist mir egal, wie ihr arbeitet,
sobald ihr besser liefert.
Andere waren richtig neugierig.
Ja, wie macht ihr dies und das?
Und wie steuert ihr hier besser?
Ja, aber wie kontrolliert ihr hier dieses eine Thema?
Natürlich kam dann wieder etwas an Angst und an Resistenz.
So nach dem Motto,
ihr dürft agil gehen,
sobald sich die Arbeitsweise für uns nicht ändert.
Sobald wir uns nicht anpassen müssen an eure Arbeitsweise,
dann könnt ihr machen, was ihr wollt.
Und da investieren wir viel Zeit und Energie
in die weitere Aufklärung auf verschiedenen Ebenen.
Also von ganz oben, von Bord-Ebene
zu dem mittleren Management,
also sprich Abteilungsleiter und Teamleiter,
ein bisschen zu verschiedenen Mitarbeitern,
also sprich Kollegen, die die Architektur verantworten
oder eben andere Bereiche vom Betrieb und von Ops,
damit das zusammenläuft und damit die Zusammenarbeit weiterläuft.
Und jetzt, wenn ich nach zwölf Monaten nach hinten schaue,
da waren die Ängste nicht begründet.
Da hat nichts Schlimmes passiert,
hat nichts gebrannt.
Im Gegenteil, da haben sich die Eskalationen verringert
und auch die anderen Bereiche haben gemerkt,
okay, also der Workplace-Bereich kann jetzt schneller agieren
und kann sich schneller anpassen.
Das war besonders in den Zeiten von Covid sichtbar,
wo wir enorme Anforderungen haben,
in kürzester Zeit so viele Tausende von Usern
auf unseren Services zu aktivieren.
Und dann kam auch danach berechtigterweise
die Dankbarkeit an uns und auch die Vorteile
von der DevOps-Arbeitsweise wurden mehr und mehr erkannt.
Das freut mich ganz besonders, dass jetzt auch von außen gesehen,
wie viel leistungsfähiger ihr auf einmal agieren könnt.
Also das finde ich ganz besonders toll.
Eine Sache, auf die bin ich auch sehr neugierig,
weil ich weiß, dass ihr auch Kollegen habt,
die nicht in Deutschland sitzen, sondern in anderen Ländern,
auch weit weg zum Teil.
Wie hat sich das auf die Zusammenarbeit mit denen ausgewirkt?
Einerseits rein organisatorisch, Distanzen, Zeitzonen und so fort,
aber andererseits vielleicht auch kulturell.
Ja.
Also wir haben erstmal gesagt, wir haben die cross-funktionale Teams,
die auch end-to-end Verantwortung haben für einen Service.
Und von Anfang an haben diese Teams
auch die internationalen Kollegen beinhaltet.
Und das heißt sowohl von Nearsharing, also Osteuropa,
Offshoring, wie im Beispiel typischerweise Indien.
Und wir haben die vom Anfang an mit involviert.
Und wie genau.
Wir haben uns immer bemüht, die gleichen Trainings anbieten zu können,
auch in anderen Standorten.
Auch das gleiche Set an Dienstleistungen als Agile Transformation Team anzubieten,
sprich Workshops, Coaching.
Und dann beispielsweise den Aufbau von Communities,
damit man sich mit involviert fühlt.
Und nichtsdestotrotz haben dann nach einer Weile bemerkt,
dass man dann doch etwas gezieltere Vorgehensweise bräuchte.
Und da hat, wie du schon erwähnt hast in der Frage,
die Kultur eine Rolle gespielt.
Und auch die davon resultierende verschiedene,
unterschiedliche Erwartungshaltung.
Und das waren wieder ganz menschliche Fragen wie,
ja was passiert mit meiner Karriere?
Wie gut ist die neue Rolle jetzt zum Beispiel von DevOps Engineer
auf dem externen Markt erkannt?
Also früher war ich Senior IT-Architekt offiziell.
Jetzt bin ich nur noch DevOps Engineer.
Und dann haben wir auch bemerkt,
wir sollen unsere Coaching und unsere Trainings auch etwas mehr customizen.
Etwas an Kultur und oder Alter und oder Hintergrund im Sinne von Erfahrung.
Und das hat uns da etwas weitergebracht.
Die Herausforderung aber bleibt weiterhin,
dass wir die Teams nicht in einem Standort blockiert haben,
sondern eben fast auf der gleichen Welt.
Ja gut, das sind natürlich dann auch wirklich Herausforderungen,
aber vielleicht kann man die auch positiv nutzen.
Ich würde nochmal auf das Thema eingehen, was du gerade gesagt hast.
Ihr habt die Trainings dann ein bisschen angepasst.
Also wahrscheinlich auf Kulturen, auf lokale Standorte,
vielleicht auch in der Sprache, das weiß ich nicht.
Das kann man auch nochmal gleich mal diskutieren.
Die Frage ist auch, habt ihr euch nur auf Trainings gestürzt
oder habt ihr auch Bücher gelesen?
Habt ihr auch Literatur gelesen?
Habt ihr euch da noch ein bisschen Erfahrungen und Informationen geholt?
Beides und auch etwas mehr als das, was wir denn haben.
Also wir haben ein Buch,
das uns wirklich stark motiviert.
Und das war nämlich das Phoenix Project.
Das Buch hat sehr gut unsere initiale Lage beschrieben.
Also eine klassische IT-Organisation
und alle sind mit vielen Themen überlastet.
Und das läuft etwas schräg.
Und viele, viele Kollegen haben sich zum Glück oder leider
mit einem Brand identifiziert.
Also das ist einer der Protagonisten,
der als Kopfmonopole und gleichzeitig als Engpass im Buch dargestellt wird.
Wir haben uns ständig informiert, was gerade auf dem Markt
und was gerade bei anderen Unternehmen passiert
und was wir daraus lernen können.
Das waren eher sogenannte Knowledge Transfers als konkrete Literatur,
weil einfach aus unserer Sicht der Bereich DevOps sehr agil ist
und bzw. sorry, nicht agil, sondern auch sehr neu, sehr dynamisch.
Und es dauert manchmal Jahre, bis ein Buch geschrieben ist
und wir wollten schon davor Erfahrungen von anderen
Experten sammeln.
Finde ich interessant.
Lass mich da mal ganz kurz einhaken,
weil das, was du sagtest, deute ich so Literatur eher nicht,
weil die eben noch nicht so aktuell war.
Sie hätte euch nicht geholfen.
Ihr habt viel höheren Zeitdruck gehabt.
Ihr habt euch dann bei anderen Unternehmen umgeschaut,
Knowledge Transfer betrieben.
Das ist richtig.
Das hört sich jetzt so einfach an.
Aber wenn ich auf meine Kunden schaue, dann höre ich häufig,
also ich empfehle denen das ja auch.
Und ich kann zwar Kontakte herstellen,
aber die sind in der Regel nicht ausreichend,
also von der Anzahl her.
Und da höre ich immer wieder, ja, wo kriegen wir jetzt Leute her,
die uns da was berichten?
Also gibt es da einen Trick oder wie habt ihr das geschafft,
dass ihr wirklich andere Unternehmen gefunden habt,
die bereit waren, euch Auskunft zu geben?
Und die müssen wir erstmal finden.
Ja, also zurück auf den ersten Teil der Frage.
Ich wollte Literatur nicht unterschätzen.
Ich denke, man bräuchte beide.
Und am Anfang haben wir uns auch viel eingelesen und eingearbeitet,
besonders ich, wo für mich die ganze Methodologie
und die ganze Arbeitsweise komplett neu war.
Sobald man dann dieses Grundverständnis bekommt
durch die Literatur, durch die Standardartikel,
die im Internet da sind, fragt man sich,
ja, wie lässt sich das jetzt in der Praxis umsetzen?
Und da hätte man zwei Möglichkeiten.
Man kann auch diese parallel betreiben,
entweder selber ausprobieren oder auch mal andere fragen,
wie es bei denen gelaufen ist.
Und wir haben gleich von Anfang an gesehen,
dass die Literatur nicht alle unsere Probleme lösen kann.
Jetzt an dem Beispiel von davor zu nennen,
diese Nicht-Kollokation,
diese Heterogenität der Standorten bei DevOps,
das war so eine Lücke, wo wir zumindest bisher
kein gutes Buch gefunden haben, keine gute Literatur.
Ich freue mich auf Empfehlungen übrigens,
vielleicht zum Ende des Podcasts.
Und dann jetzt auf den zweiten Teil deiner Frage.
Wie haben wir dieses Unternehmen gefunden?
Wir haben einfach gefragt.
Wir haben in unserem Netzwerk veröffentlicht, gepostet, gefragt,
unseren Partner, unsere Provider, unsere Vendoren.
Ja, wir haben vor, jetzt Agile und DevOps einzusetzen.
Oder sogar zu sein.
Wie sieht es aus, habt ihr das bisher gemacht?
Was könnt ihr mit uns teilen?
In welchem Format?
Was sind eure Empfehlungen?
Da ist sehr wichtig, dass man auf Feedback hört,
dass man offen ist zu Verbesserungsvorschlägen.
Also ich war von Anfang an sehr bewusst, dass ich das nicht gut kenne.
Und deswegen war ich immer sehr offen zu alles,
was ich an Input zu dem Thema bekommen habe.
Jetzt mal umgekehrt.
Wenn jetzt jemand zu dir kommt und sagt,
Marian, welche Tipps kannst du mir geben,
um in meiner Organisation anzufangen mit DevOps?
Was würdest du ihm sagen, was soll er auf keinen Fall machen?
Auf keinen Fall machen?
Das ist eine sehr gute Frage.
Es bringt mich zur Selbstreflexion in den letzten zwölf Monaten.
Ich würde sagen, auf keinen Fall Lipstick Agile machen.
Also nur DevOps als Buzzword zu machen.
Und das als Kulisse zu nutzen, um die Unternehmensprozesse
und die Wertschöpfungskette weiterhin so zu betreiben.
Und das beinhaltet, das klingt klischeehaft und klingt,
ja, ist doch logisch.
Man kann aber auf dieser Reise sehr schnell
in die alte Denkweise zurückrutschen.
Also wenn man beispielsweise Kollegen nominiert,
damit sie agil arbeiten, ohne dass sie das selber wollen,
das ist für mich nicht die agile Art und Weise.
Oder wenn man die alten Prozesse nur etwas ändert,
und vorne ein neues Wort davor hängt,
hat sich aber gar nichts geändert.
Das ist weiterhin das sogenannte Lipstick Agile.
Also ich würde sagen, entweder richtig,
auch wenn mit kleinen Schritten, oder lieber nicht.
Das ist die eine Sache, wo ich abrate.
Also ich habe was gelernt, Marian.
Den Begriff Lipstick Agile, den kannte ich noch nicht.
Also vielen Dank dafür.
Der kann ich mir sehr schön vorstellen.
Jetzt müssen vielleicht alle Frauen mal weghören,
aber so einen knallroten Lippenstift dann da zu nehmen,
um attraktiv zu wirken vielleicht, kann ich mir sehr schön vorstellen.
Also alles schön antünchen, übertünchen,
aber nicht wirklich in die Tiefe reingehen.
Ja, danke.
Das meinte ich. Freut mich.
Ja, aber es ist interessant, dass du das sagst,
weil das sagt sich viel leichter, als es dann tatsächlich ist.
Ich meine, selbst mit den besten Absichten.
Wenn man jetzt davon ausgeht, jemand möchte wirklich,
wirklich eigentlich in Richtung Agilität sich transformieren.
Aber ich kann mich zum Beispiel erinnern an die ersten Trainings,
die ich bei euch gehalten habe vor fast einem Jahr jetzt oder so was.
Wie schwer sich da viele Leute getan haben,
diese Konzepte, von denen sie da gelernt haben,
wirklich mit Leben zu füllen und zu sagen,
so wenden wir das an, so funktioniert das.
Man ist dann versehentlich immer wieder so ein bisschen zurückgefallen
in das bereits Bekannte.
Ich weiß nicht, ob ihr beide das auch so beobachtet habt,
aber mir fiel das so stark auf.
Und das hat sich jetzt aber über das vergangene Jahr
natürlich sehr stark gesteigert.
Mittlerweile haben die Leute wirklich einen Überblick gewonnen
und wissen jetzt, wie sie es verstehen sollen.
Ja, das kann ich auch bei uns sehen, intern.
Da kann ich nur zustimmen.
Agile und DevOps bedeutet,
dass man auch die Denkweise und das Verhalten ändert,
also das Mindset.
Und dadurch auch die Kultur.
Und das haben wir tatsächlich in dem letzten Jahr ein wenig bewegt.
Wir haben,
gewisse Initiativen, gewisse Ownership
auf die jeweiligen Kollegen geschifftet,
sei es DevOps-Engineers, sei es Product-Owner.
Und das ist eben dieser Kulturwandel.
Alles wird top-down entschieden,
alles wird vom Chef-Chef-Chef irgendwo vorgegeben
in einem Steering-Komitee zu.
Ich bin der Schmied,
ich mache meine eigene Arbeit, meine eigenen Arbeitspakete.
Und das ist besonders für das Management-Niveau etwas schwer.
Und da soll es auch anfangen.
Das ist auch eine unserer Lessons learned,
so früh wie möglich das Management mitzuinvolvieren
und das Richtige von Anfang an aufzusetzen.
Was bedeutet Agile für meine Rolle?
Was bedeutet das für mich als Agile-Leader?
Was mache ich richtig?
Wo soll ich mich verbessern?
Inwieweit passt das mit meinen Werten und Prinzipien zusammen?
Inwieweit passt das mit meiner Erfahrung zusammen?
Damit wir eben nicht in den Lipstick-Agile zurückrutschen.
Sehr interessant.
Ich habe auch noch eine andere Frage,
nämlich häufig wird DevOps, glaube ich,
immer noch so ein bisschen als eine Verlängerung von Agile betrachtet
und deswegen vielleicht versehentlich sehr stark
aus so einer entwicklungslastigen Brille.
Und nun seid ihr genau das Gegenteil als Organisation.
Ihr seid vollkommen betriebslastig.
Findest du denn, ist dein Gefühl,
dass in der DevOps-Bewegung, in der DevOps-Literatur
der Betrieb wirklich gut genug wegkommt?
Hast du genügend Informationen gefunden?
Hast du dich gut orientieren können mit dem,
was du gesehen hast an Literatur, an Trainings und so fort?
Ja, also erstmal auf den ersten Teil zu beantworten.
Tatsächlich kommen wir aus einem sehr Ops-lästigen Bereich.
Also ein großer Teil unserer Kollegen betreiben Ops
und noch dazu kommen einige externe Provider,
die für uns auch die Ops steuern.
Und ich glaube, DevOps ist immer noch sehr gut anwendbar,
auch wenn man aus der Ops-Welt kommt und nicht aus der Dev.
Die Prämissen von DevOps gelten weiterhin.
Und beispielsweise jetzt Automatisierung
oder den Continuous Flow, damit man dann regelmäßig liefert.
Jetzt kommt tatsächlich die Frage,
wie bringt man das den Ops-Kollegen bei?
Und da sind wir gerade auf dem Journey, also auf der Reise.
Wie motivieren wir die Ops-Engineers,
die Ops-Kollegen, damit sie sich mehr und mehr
für die Entwicklung interessieren?
Und das ist wiederum, sorry, wenn ich mich wiederhole,
das ist aber wiederum eine Frage vom Mindset,
von den intrinsischen Motivatoren, von der Kultur.
Und sobald man da die richtigen Motivatoren erwischt,
da sehen wir auch die ersten Promotoren,
die ersten Change Agents von DevOps unter unseren Ops-Kollegen.
Gut, das klingt super, Marian.
Also wir sind jetzt bei über 45 Minuten,
aber ich glaube, der Wert von dem, was du so erzählt hast,
der ist mehr wert als 45 Minuten an der Stelle.
Also ich sage mal von hier aus, aus meiner Sicht,
vielen, vielen Dank bisher.
Gibt es noch irgendetwas, was du aus deiner Sicht sagen wollen würdest,
was wir noch nicht angesprochen haben?
Ja, vielleicht ein paar Botschaften am Ende.
Es braucht Zeit und Energie, bis man agil wird.
Das lohnt sich aber, und das funktioniert.
Und was wir, oder vielleicht habe ich,
das zu wenig angesprochen.
Letztendlich macht das auch unsere Kollegen und unsere Teams glücklicher.
Und ich finde, glückliche Teams und glückliche Kollegen
heißt irgendwann auch glückliche Kunden.
Und das ist Ziel und Zweck von DevOps.
Und ja, mit den Worten möchte ich mich auch bei euch beiden bedanken.
Das war eine sehr interessante Session für mich,
die mich zu viel zu Selbstreflektionen
über die letzten zwölf Monate gebracht hat.
Perfekt, dann sage ich auch Danke und würde sagen,
das war auch ein toller Satz, Selbstreflektion.
Das ist ja, glaube ich, ein ganz wichtiger Punkt an der Stelle,
egal mit welcher Methode man arbeitet im Unternehmen.
Ich sage auch Dankeschön und würde sagen,
dann überlasse ich mal das Schlusswort dem Luca,
weil wir machen das ja ab dem nächsten Podcast
oder ab der nächsten Episode, ab der nächsten Folge,
zusammen.
Also ich sage auch vielen Dank, Marian,
für deine vielen tollen Aussagen,
für deine tollen Erlebnisberichte.
Vielen Dank.
Ja, genau.
Jetzt hast du mir fast nichts mehr übrig gelassen
für das Schlusswort,
weil du hast dich ja schon für alles bedankt, Dirk.
Aber ich kann mich dem wirklich nur anschließen.
Es war wahnsinnig spannend.
Es war sehr, sehr lehrreich.
Und es ist auch, glaube ich, was Besonderes,
wenn jemand mit so großer Offenheit über seine Erlebnisse spricht.
Und es ist ja nicht immer ein gemütlicher Weg,
sondern es ist bisweilen etwas steinig.
Insofern bin ich sicher,
dass unsere Zuhörer da sehr viel rausziehen können.
Ich weiß, dass es für mich auch sehr interessant war,
obwohl ich euch ja jetzt schon eine ganze Weile beobachten darf.
Insofern auch von meiner Seite vielen Dank.
Es hat viel Spaß gemacht.
Und es hat mich viel weitergebracht.
Dankeschön, Marian.
Ja, Luca, vielen Dank für deinen tollen Gast,
den du hier in den Podcast gebracht hast.
Ich habe dir zu Anfang gesagt,
wir machen das ab jetzt gemeinsam.
Ich freue mich, dass wir das gemeinsam machen.
Das bringt, glaube ich, ein bisschen mehr Qualität rein
oder noch mehr Qualität.
Das bringt ein paar andere Dinge.
Und die Frage ist, was denkst du denn, was du mitbringst?
Was möchtest du im Podcast verändern?
Oder was möchtest du mit einbringen?
Also, was ich auf jeden Fall natürlich mit einbringe,
ist ein anderes Netzwerk.
Ich kenne andere Leute als du, auch internationalere Leute.
Insofern, ich könnte mir durchaus vorstellen,
dass der Podcast jetzt etwas englischsprachiger wird,
obwohl ich glaube, dass es weiterhin
ein deutschsprachiger Podcast bleiben sollte.
Aber wenn wir halt einen spannenden Gast haben,
der kein Deutsch spricht, dann nehmen wir ihn natürlich trotzdem.
Ist ja klar.
Und das andere ist vielleicht,
dass ich eine etwas andere Sicht auf DevOps habe,
tiefer in der Technik-Ecke drinstecke
und trotzdem natürlich die Kultur und alles, was damit zusammenhängt,
die, sagen wir mal, die menschliche Seite von Technologie
für die überwältigend wichtigere halte,
aber trotzdem vielleicht in dieser Richtung
ein bisschen mehr Tiefe, ein bisschen mehr Kontext geben kann.
Sehr schön.
Ja, ich glaube, das sind auch die Gründe, weswegen ich auch gesagt habe,
das ist eine gute Idee, dass man eben mehr liefert.
Nicht mehr im Sinne von mehr Folgen, sondern mehr Qualität, mehr Sichtweisen.
Und ich denke, dass wir das ganz gut hinkriegen werden.
Wir werden sicherlich Folgen haben, die nur einer von uns betreut,
also wo nur einer die Fragen stellt
und die quasi nur unter der Leitung einer von uns beiden ist.
Ich denke aber auch, dass wir Folgen haben werden,
wo wir beide, so wie heute ja auch, wo wir beide Fragen stellen
und damit ja so aus einem Gast vielleicht noch mehr rauskitzeln.
Wie gesagt, mehr nicht im Sinne von quantitiv,
sondern qualitativ an der Stelle.
Also ich freue mich und bin mal gespannt, was wir in der Folge 39 machen.
Wir beide wissen es heute noch nicht,
aber wir haben eine Menge in der Zeit,
die noch sehr im Backlog stehen.
Und insofern würde ich sagen,
dann sage ich jetzt mal danke, lieber Luca,
dass du den Podcast bereichern wirst.
Ja, und ich danke dir auch vielmals, Dirk, dafür,
dass du mich eingeladen hast, hier mitzuwirken.
Nicht nur als Gast, sondern tatsächlich auch als Co-Moderator.
Und ich freue mich da wahnsinnig drauf.
Ja, danke dir auch.