Folge 15: Mythen der Selbstorganisation

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Selbstorganisierte Teams sind eines der wichtigsten Elemente von DevOps. Es existieren jedoch leider viele Annahmen und Mythen über Selbstorganisation, die oftmals völlig unreflektiert (oder bewußt?) übernommen werden. In dieser Folge diskutiere ich einige der Mythen (Missverständnisse!) mit Miguel May, einem sehr geschätzten Agile Coach-Kollegen.

In dieser Episode des Podcasts diskutieren die Gastgeber, Dirk Söllner und Miguel May, das Konzept der Selbstorganisation in DevOps-Teams und adressieren gängige Mythen und Missverständnisse. Sie erkunden verschiedene Aspekte wie die Rolle von Hierarchien, die Bedeutung von Führung in selbstorganisierten Teams und die Herausforderungen bei der Umsetzung von Selbstorganisation. Wichtige Erkenntnisse aus der Praxis werden hervorgehoben, die die Notwendigkeit eines Gleichgewichts zwischen Struktur und Autonomie betonen und die zentrale Rolle von Mentalität und Kultur für erfolgreiche Selbstorganisation unterstreichen.

Inhalt

  • Einführung in die Selbstorganisation: Vorstellung des Themas und des Gastes Miguel May.
  • DevOps aus Geschäftsperspektive: Diskussion von DevOps aus der Sicht des Geschäfts.
  • Mythen der Selbstorganisation: Analyse von Julia Kuhlens Liste der Selbstorganisationsmythen.
  • Rolle von Hierarchien: Entkräftung des Mythos, dass Hierarchien grundsätzlich negativ sind.
  • Herausforderungen in selbstorganisierenden Teams: Praktische Herausforderungen und Lösungen bei der Förderung von Selbstorganisation.
  • Einfluss von Führung: Die wesentliche Rolle von Führung und Entscheidungsfindung in selbstorganisierenden Teams.
  • Rahmenbedingungen vs. Mentalität: Die Bedeutung der Mentalität über strukturelle Rahmenbedingungen für eine erfolgreiche Selbstorganisation.
  • Persönliche Erfahrungen und Einsichten: Teilen von realen Erfahrungen und praktischen Einsichten.

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Dirk Söhn.
Hallo und herzlich willkommen zu einer neuen Folge vom DevOps-Podcast auf die Ohren und ins Hirn.
Ich habe heute zu Gast den Miguel May, der sich selber sicherlich gleich vorstellen wird.
Und Thema heute ist mit der großen Überschrift Selbstorganisation.
Da werde ich mit Miguel drüber reden. Und ich würde sagen, Miguel, stell dich doch mal ganz kurz vor.
Ja, Dirk, erstmal danke für die Einladung. Ich freue mich auf unser Gespräch.
Miguel May, ich bin agiler Coach. Ich bin seit 2011 als Freiberufler in dem Terra unterwegs.
Habe einen Background in Unternehmensberatung und Management und bin deshalb so ein bisschen Business-affiner
und fokussiere deshalb meine Arbeit als Coach auch auf die Business-Abteilungen
und arbeite deshalb besonders gerne und besonders häufig mit Product-Ownern,
Chef-Product-Ownern und den entsprechenden Stakeholdern zusammen.
Klingt ja schon mal ganz spannend, auch der Business-Hintergrund.
Ich hatte ja gesagt, DevOps-Podcast und was wir immer machen in unserem DevOps-Podcast ist,
dass wir die Teilnehmer bitten, DevOps zu beschreiben, also ihre Sicht von DevOps zu beschreiben,
vielleicht DevOps zu definieren. Wie sieht das bei dir aus?
Ja, mit Definition tue ich mich ein bisschen schwer, weil eben aus der Business-Sicht bin ich tatsächlich
ein bisschen weiter von den DevOps-Themen weg. Ich habe es natürlich trotzdem in Projekten kennengelernt
und finde es eine unheimlich faszinierende Kombination, weil klassischerweise sitzt ja,
also ich mache es mal deskriptiv, sitzt ja der Entwickler da, baut ein Stück Software,
irgendwann ist es fertig, schmeißt es dann irgendwo hinüber und dann muss es in Betrieb genommen werden
und dann beginnen erst die Probleme, weil der Kontext nicht passt und irgendwas nicht läuft
und welche Versionen nicht stimmen und es gibt einen riesen Tumult und es braucht eine Ewigkeit,
bis die Software aus der Entwicklung dann wirklich in den erfolgreichen Betrieb übergegangen ist.
Und immer wenn ich Teams hatte, wo ein sogenannter Opsler, ich weiß nicht, ob man das so nennen darf,
ich nenne die immer so, wenn ein Opsler mit dem Entwicklungsteam gleich drin sitzt
und schon bei der Entwicklung prüft, ob es denn in der Umgebung auch laufen würde
und ob die Umgebung dafür entsprechend konfiguriert ist und ob die ganzen Ports und Adressen
und all das Zeug eingestellt ist, das ist zwar immer ein bisschen mehr Aufwand während der Entwicklungsphase,
aber am Ende hast du halt einen sehr geschmeidigen Übergang direkt zum Kunden,
was ich natürlich aus Business-Sicht total gut finde, weil ich will ja,
von der Idee bis zum Impact auf den Kunden eine möglichst kurze Zeit haben
und für mich ist DevOps erstmal der Ansatz oder das Konzept, um das zu optimieren.
Das finde ich ganz klasse.
Wir hatten ja schon einige Folgen und was dabei rausgekommen ist,
ist immer, dass es eigentlich nicht die Definition von DevOps gibt.
Es gibt ein paar ganz knackige Begriffe, die finde ich immer ganz schön.
Das, was du erläutert hast, ist ja aus der Business-Sicht auch eine schöne Beschreibung,
ein schöner Vorteil, ein schöner Mehrwert.
Ein Konzept zu folgen.
Wir hatten das Thema Selbstorganisation, haben wir ja quasi mal oben drüber geschrieben.
Wir haben das noch nicht mit irgendwie konkretisiert
und wir beide haben eine schöne Webseite entdeckt,
wo Julia Kuhlen was ganz Schönes aufgeschrieben hat, formuliert hat,
zu dem Thema Selbstorganisation und nicht das vielleicht manchmal Anzutreffende,
das ist ganz wichtig und das muss man so machen und das hilft,
sondern dass sie eigentlich mal ein paar Missverständnisse aufgeführt hat
zu Selbstorganisationen.
Sie hat das Mythen genannt und die Webseite werde ich natürlich auch in den Shownotes verlinken.
Also insofern, wir beide nehmen eigentlich diese tolle Auflistung der Mythen,
der Missverständnisse zu Selbstorganisationen und wollen die mal ein bisschen bereden hier an der Stelle.
Gibt es irgendeinen Mythos von diesen 15, sie hat ja 15 Mythen aufgeschrieben.
Gibt es irgendetwas, was dir sofort ins Auge gesprungen ist, außer dass alle ganz interessant sind?
Also was ich gerade, während du das nochmal anmoderiert hast, mir gedacht habe,
was wir hier machen, ist ja eigentlich das perfekte Beispiel für Selbstorganisationen.
Wir haben uns gemeinsam die Seite von Julia Kuhlen rausgesucht, weil die uns gut gefallen hat,
als Aufhänger. Das ist jetzt quasi schon ein Rahmen, in dem wir uns bewegen.
Wir haben einen gewissen zeitlichen Horizont für unseren Gespräch,
wir haben technische Rahmenbedingungen, aber das ist schon ein Rahmen innerhalb derer,
innerhalb dessen heißt es glaube ich, wir uns jetzt organisieren.
Das heißt, ich finde am wichtigsten ist, dass Selbstorganisation nicht extra irgendwo hinzugefügt werden muss,
sondern sie ist per se einfach vorhanden.
Und es gibt immer irgendwelche Rahmenbedingungen, auch wenn sie noch so klein und harmlos erscheinen
oder uns gar nicht mehr auffallen, aber wir sind ständig in einer Herausforderung der Selbstorganisation.
Und ich glaube, der größte Mythos ist, dass es sozusagen ein extra Thema ist,
das man einführen muss oder jetzt mal damit anfangen sollte.
Ich glaube, der größte Mythos ist oder die größte Wahrheit, großes Wort, ist, sie ist einfach da.
Und man kann Selbstorganisationen steuern und verändern und vielleicht auch verbessern und verschlechtern,
aber erstmal existiert sie schlichtweg, sie ist einfach vorhanden um uns herum immer.
Super, lass uns gleich auf den ersten Mythos eingehen, weil der hängt da so ein bisschen mit zusammen.
Also der erste Mythos von Julia Kuhlen heißt Hierarchie ist schlecht und muss abgeschafft werden.
Ja, das hört man tatsächlich wahrscheinlich mit am häufigsten.
Ich weiß nicht, ob die Frau Kuhlen das in der Reihenfolge auch versucht hat aufzunotieren.
Aber eben Hierarchie ist für mich einfach erst mal nur ein Rahmen, in dem sich eine eigene Organisation dann ausprägen kann.
Ich suche immer noch die passende Metapher, sowas wie, das sind immer zwei Seiten derselben Medaille.
Die eine kann ohne das andere gar nicht existieren.
Es gäbe den Begriff Selbstorganisation ja überhaupt nicht, wenn es nicht die Gegenseite in Anführungszeichen dazu gäbe.
Und ob man die Gegenseite jetzt Fremdorganisation oder Kontrolle oder Hierarchie nennt,
da kann jeder sein eigenes Wort gerne sich wählen.
Ich finde erstmal gehört, wenn wir bei dem Begriff von ihr bleiben, Hierarchie und Selbstorganisation,
sind zwei Seiten derselben Medaille.
Deshalb, man kann sie gar nicht abschaffen, weil dann gäbe es keine Selbstorganisation mehr.
Die beiden Dinge bedingen sich.
Das war jetzt so ein bisschen vielleicht der philosophische, konzeptionelle Überbau dazu.
Ich persönlich finde immer, dass, also es gibt ein Beispiel, das mir immer im Hinterkopf geblieben ist.
Das ist die Tatsache, dass auf einem Klavier einfach nur 88 Tasten sind.
Und der Musiker muss auf diesen, wenn er Klavier spielt, wenn er Pianist ist,
er muss auf diesen 88 Tasten, wenn er Klavier spielt, wenn er Pianist ist,
er muss auf diesen 88 Tasten, wenn er Klavier spielt, wenn er Pianist ist,
88 Tasten spielen.
Es gibt nichts anderes.
Jetzt kann er dort aber eine wahre Meisterschaft erreichen.
Und wir wissen alle, dass es ganz verschiedene Arten von Meisterschaft auf dem Klavier gibt.
Und niemand als Pianist würde sich beschweren, dass es nur 88 Tasten gibt.
Aber im Prinzip ist das eine hierarchische Vorgabe,
auch wenn sie nicht organisatorisch eine Firmenhierarchie darstellt.
Aber hier ist eine Rahmenbedingung, die ist absolut unveränderbar.
Es gibt 88 Tasten, jetzt spiel drauf.
Und das ist, ja, es ist für die Leute überhaupt kein Problem.
Es ist eine spannende Herausforderung.
Es ist eine spannende Herausforderung.
Im organisatorischen Bereich, im Unternehmen, finde ich Hierarchie deshalb eigentlich praktisch,
weil sie dir sagt, wo dein Rahmen ist und sagt, wo ist das Ende deiner Selbstorganisation.
Eben, was sind deine 88 Tasten, auf denen du jetzt spielen kannst?
Und in diesem Rahmen kann ich mich jetzt aber bewegen.
Vielleicht nicht zu 100 Prozent frei,
aber erstmal gibt es Teams eine sehr hilfreiche Orientierung zu wissen.
Was ist die Vorgabe?
Was sind die Rahmenbedingungen?
Was ist eigentlich das Ziel?
Wie läuft das hier?
Und jetzt kann ich mich ausbreiten.
Und ich finde es befreiend, wenn ich überhaupt nichts als Rahmenbedingungen habe,
ist die Welt so groß, dass ich ja gar nicht weiß, wo ich anfangen und aufhören soll.
Welchen Teil soll ich jetzt organisieren und zu welchem Zweck?
Deshalb ist gar nicht euphemistisch gemeint.
Hierarchie hilft mir, weil es mir klare Rahmenbedingungen setzt.
MARKUS TRANTOW Ja.
Und was du eben schon angedeutet hast, ist ja auch das, was auch die Julia so schön beschreibt.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
MARKUS TRANTOW Ja.
hast. Es ist ja nicht so, dass ich
ohne Hierarchie auskomme oder
ohne Struktur. Das heißt, selbst
wenn ich jetzt keine organisatorische
Hierarchie habe, weil ich einen Chef
habe, weil ich Gruppenleiter habe oder andere
Dinge, weil ich Rollen definiert habe,
wo jeder in seiner Rolle genau das tun muss.
Also wenn das nicht da ist
oder da wäre, bildet sich ja
eine andere Hierarchie heraus. Und das
ist ja das, was ich auch immer in den
Teams erlebe, in den selbstorganisierten
Teams. Also erstens,
sie müssen es können. Das ist ja kein
Freibrief, sie müssen es ja können. Und
dann bilden sich dort auch Hierarchien
heraus. Die bilden sich aber dann eben heraus,
um das zu erreichen, was du eben
gesagt hast. Komplexität reduzieren,
einen Rahmen schaffen.
Ja, ich glaube, die Frau Kuhlen hatte auch in einem
anderen Punkt auf der Liste das
explizit erwähnt, dass sich eben dann informelle
Strukturen, das ist ja auch nur
ein anderes Wort für Hierarchie, herausgebildet
haben, die dann aber eher
vielleicht noch schwerer zu
durchschauen sind und auch gar nicht offiziell
ansprechbar sind. Also ich kann jetzt gar nicht sagen,
ich gehe zum Chef und rede mit
ihm darüber, dass ich hier in der Ecke
vielleicht mehr Freiraum möchte oder das selber
gestalten möchte, weil es gibt ja den
offiziellen Chef gar nicht. Es gibt halt einen
Meinungsführer, sozusagen der inoffizielle
Rudelführer, aber der kann dann
auch immer sagen, ja, weiß ich ja nicht, ich bin
ja nicht der Chef. Also das wird dann halt
eine sehr einseitige
Hierarchie. Die Leute, die inoffizielle
Rollen haben, üben diese Funktion
zwar aus, aber man kann sie offiziell
nicht wiederum ansprechen. Und das ist, finde ich,
eine sehr schwierige Gemengelage,
die, weiß nicht, ob das
jetzt in den Kontext passt, dann potenziell auch
eine gewisse Übergriffigkeit mit sich bringen kann,
weil man hat quasi als
inoffizieller Leader sich die Rechte genommen,
ohne die Pflichten auch zugewiesen zu
bekommen. Und dann ist die Gefahr da,
dass in solchen Strukturen auch Macht,
inoffizielle Macht vielleicht ein bisschen
weniger gut kontrolliert wird
und dementsprechend kritisch wird.
Nicht umsonst, wir hatten ja gerade hier
die Wahlen in Amerika,
gibt es ja da auch üblicherweise
immer Checks and Balance und dazu musst du halt wissen,
wer ist wer, damit die sich auch gegenseitig
ein bisschen im Auge behalten können.
Jawohl, und
zu Macht gehört ja auch
eine Verpflichtung, diese Macht dann auch,
sagen wir mal, zum Wohle von allen einzusetzen
an der Stelle. Und wenn die Macht oder
eine Steuerungsaufgabe
sichtbar ist,
zugewiesen ist, transparent ist,
dann kann ich
mich darauf einstellen, das, was du ja auch gerade
gesagt hast. Und wenn das informell ist,
dann ist es intransparent. Und allein
das widerspricht dann ja auch
schon gewissen agilen Grundprinzipien,
nämlich Dinge transparent zu machen.
Absolut. Also genau wie du sagst,
wenn man sich nur die Rechte rauspickt und die Macht
nutzt und nicht
dran denkt oder es ständig beachtet,
dass man eigentlich eine Verantwortung damit hat
und einen Beitrag für die Gruppe, für das Team,
für die Kollegen leisten muss,
dann macht man eben Cherrypicking und das, glaube ich,
ist gefährlich. Vollkommen richtig.
Und das ist dann manchmal, glaube ich, auch das, wo
dann auch vielleicht Schwierigkeiten entstehen,
wenn Teams wirklich dieses Cherrypicking
machen. Wenn sie also sagen, naja, wir
organisieren uns selbst, wir brauchen
keine Hierarchie mehr, wir brauchen keinen Chef mehr
und dass sie dann eben sich das Schöne rauspicken
und das dann eben falsch verstehen oder
missverstehen. Ich würde dann auf diesen nächsten
Punkt überleiten, das, was ich im Prinzip
eben schon so ein bisschen angedeutet habe.
Kann ich noch kurz was zu deinem
Punkt sagen? Entschuldigung, weil das ist echt,
ich habe da so ein kleines persönliches Anliegen oder es gibt
mehrere persönliche Erlebnisse,
die ich hatte, die genau das beinhalten,
was du beschrieben hast, dass sich die Teams
das wirklich einfach rausgepickt haben
und ich habe einfach Projekte
ein bis zwei Jahre kolossal
scheitern sehen, wo jetzt
wieder aus der Business-Perspektive kein Produkt
rauskam, kein Kunden-Impact und
halt irgendwie untere zweistellige
Millionenbeträge verbraten worden sind.
Was mir nur total wichtig ist an der Stelle,
es ist jetzt leicht, auf das Team zu schimpfen
und zu sagen, boah, die haben nichts geliefert,
die haben sich immer im Kreis gedreht,
die konnten sich nicht entscheiden, die wussten
nicht, wohin die Reise geht und genau
in meinem Satz, der letzten Satz, steckt ja
schon das Problem. Niemand hat ihnen genau gesagt,
wohin sie eigentlich gehen sollen.
Was die Rahmenbedingungen sind. Und ich habe auch mit
diesen Teams mich da natürlich unterhalten und die waren
unfassbar frustriert, weil sie
hatten natürlich eigentlich
sich gewünscht, sich frei entfalten zu können,
da ihnen aber niemand mehr sagte,
was denn die Richtung ist und was
eigentlich der Zweck des ganzen Spiels ist,
waren die völlig orientierungslos. Und ich glaube,
es ist ein großes Tabuthema,
dass die Teams selbst
sich hinstellen und sagen,
das ist jetzt zu viel Freiraum
oder Selbstorganisation ist super,
wir lieben das, aber wir haben jetzt nach drei Monaten
gemerkt, wir brauchen noch ein paar klare Ansagen.
Und da Selbstorganisation so ein
Hype-Begriff ist, darf man quasi
nur nach mehr Freiheit
und nach mehr Autonomie fragen,
aber es ist ganz schwer, das zu
durchbrechen und zu sagen, nee, gib mir hier
mal Guidance. Das höre ich leider ganz selten
und ich glaube, dass wir da die Teams
stärker ermutigen müssen
oder Rahmen schaffen müssen, wo
sowas ausgesprochen werden kann,
weil es wäre viel zu leicht zu sagen, dass das
Team selbst einfach
ja, fast falsch gemacht hat,
weil es die Rosinen rausgepickt hat.
Jemand hat den Rahmen gesetzt,
dass es die Rosinen rauspicken konnte und da
begann dann das Problem, was
sich vielleicht dann erst Monate später manifestiert.
Ja, dann sollten
wir vielleicht auch im Sinne einer positiven
Formulierung diesen Mythos nochmal abschließen.
Also, wir brauchen
auch bei selbstorganisierten Teams,
wir brauchen im Rahmen
von Selbstorganisation, brauchen
wir Hierarchie, wir werden
immer Hierarchie haben und
die Frage ist, wie kriegen
wir sie positiv gestaltet? Das heißt also,
wir brauchen die Hierarchie und wir können sie nicht
einfach per se abschaffen, weil sie sich
irgendwie dann doch wieder herausbildet.
Absolut. Jawohl.
Ja, ich wollte auf den nächsten Mythos übergehen.
Der ist im Prinzip ganz ähnlich
formuliert. Der sagt nämlich,
Chefs sind schlecht und müssen
abgeschafft werden.
Das ist glaube ich auch
aus meiner Sicht häufig
ein Problem, dass
Führungskräfte sagen,
Selbstorganisation ist ja toll, da braucht man mich nicht mehr.
Wie stehst du dazu?
Ja, wie du sagst, das ist natürlich relativ verwandt
zu dem ersten Punkt, weil
die Chefs oder die Führungskräfte
oder die Leader oder die Manager, wie man
eben auch nennen mag, sind ja die, die die
Hierarchie quasi repräsentieren
und zum Ausdruck bringen müssen, was die
Rahmenbedingungen sind. Und ich glaube,
das ist seit jeher, ich habe ja
da meine eigene Erfahrung als Führungskraft,
seit jeher
eine sehr schmerzhafte, herausfordernde
Situation, Leuten zu sagen,
dass es hier Grenzen gibt.
Wollen wir einfach nicht gerne machen.
Das gilt auch für Führungskräfte.
Das fällt den Allermeisten
genauso schwer oder noch schwerer
und dementsprechend vermeiden sie es die ganze
Zeit. Und ich glaube, es gibt
neben dem Begriff der
Selbstorganisation viele andere Hype-Themen,
die zum Beispiel
Management by Objectives, also
ich schreibe auf, was
für KPIs am Ende des Jahres erreicht werden
sollen und dann kann ich ja weggehen und muss
keine Führung mehr ausüben, weil
die Leute müssen ja nur noch auf die KPIs schauen,
was sie erreichen sollen und
mein Gott, habe ich ein Glück, ich muss jetzt nicht
mehr führen. Das ist
sehr plakativ, Feigheit
vor dem Feind. Also jetzt nicht Feind der Mitarbeiter,
sondern das schwierige Gespräch.
Und ich finde, es gibt an zu
vielen Stellen Versuche, Formate
zu entwickeln, Frameworks,
sowas auch
wie das Hype-Thema Selbstorganisation,
damit Führungskräfte
sich vor ihrer eigenen Führungsaufgabe drücken können.
Und wenn du dir die
Management-Literatur anschaust,
kann ich jetzt sagen mal grob persönlich die letzten
20, 30 Jahre überblicken ungefähr,
das kommt immer wieder.
Es ist völlig egal, in welcher Phase wir uns befinden.
Führung ist ein ganz schwieriges
Thema und es gibt wenig gute
Führungskräfte, weil wenig sich gerne
vor Leute stellen und offen sagen,
hier gibt es eine Grenze.
Ich bin selbst kein Elternteil, deshalb kann
ich es nur bedingt bewerten,
aber ich nehme das so wahr, dass das genau
das ist, was eine Elternrolle auch sehr
schwierig macht. Du musst liebevoll
Grenzen aufzeigen,
und es tut dir immer mehr weh,
das zu tun als dem Kind, aber ich glaube,
das ist genau die Herausforderung einer Führungskraft,
liebevoll Rahmenbedingungen
aufzuzeigen.
Und Chefs sind nicht in ihrer
Rolle schlecht, sondern viele
tun sich schwer, die Rolle einfach gut auszufüllen.
Ja, und da finde ich,
dann ist es egal,
ob diese Chefs in einem agilen oder in
einem hierarchischen oder
klassischen Umfeld tätig sind. Also
insofern, wenn ich diesen Punkt jetzt mal
positiv zu Ende formuliere
formuliere, wir brauchen
Chefs weiterhin. Wahrscheinlich ist nur
die Art und Weise, wie ein Chef agieren
sollte, vielleicht ein bisschen anders bei
selbstorganisierten Teams, und auch da
kommt es dann gar nicht auf irgendeine Methode
an oder auf eine Organisation an sich, sondern
auf das, was der Chef
im Sinne einer modernen Führungskraft
daraus macht. Also,
umformuliert, wir brauchen Führungskräfte,
die ihren Job ausüben,
und das ist, wie du auch erzählt hast,
ja nicht ganz einfach. Absolut,
da würde ich so unterschreiben.
So, und dann kommt man ja sofort
zu dem Punkt, okay, wir brauchen andere Führungskräfte,
die müssen das Team unterstützen,
sie müssen das Team
voranbringen, und dann kommen wir zu einem
Punkt, den ich sehr häufig
feststelle und
negativ feststelle, den hat die Julia
so in den Mythos 4 reingepackt.
Wir reden ja auch davon, dass wir
die, dass die Teams intrinsisch
motiviert sind, dass sie von sich aus
Bock haben zu arbeiten, und sie sagt,
ein Missverständnis ist,
die intrinsische Motivation
steigt, wenn alle gehört werden und sich
alle einbringen können.
Wird ja im Scrum Guide oder
mit Scrum an sich, wird das ja sehr stark
propagiert, wenn das jetzt die Julia
als ein Missverständnis aufzeigt.
Was sind so deine Erfahrungen
dazu? Also, ich denke,
dass der Satz erstmal,
dieser Mythos-Satz erstmal
gar nicht schlecht formuliert ist. Die intrinsische
Motivation steigt, wenn alle gehört
werden und sich einbringen können. Ich glaube, der stimmt.
Ich denke, sie hat es auch
dann im weiteren Text so aufgeklärt,
dass man aber da
eine Grenze setzen muss,
wie weit man sich einbringt
und wie weit Leute gehört
werden. In den vielen, vielen Meetings,
in denen ich mich mit Scrum
und Kanban-Teams bewege,
die jetzt überhaupt
nicht von sich behaupten würden, überbordende
Selbstorganisationen auszuüben,
gibt es schon eine Situation, dass
der eine nach fünf Minuten sagt, ey, jetzt haben wir genug
geredet, jetzt entscheide mal halt,
oder entscheide du, Scrum Master,
Product Owner, Projektleiter, wer auch immer, und dann geht es
halt weiter. Und der Nächste sagt, ey,
wir haben uns ja nicht mal warm geredet. Ich meine, wir
haben noch gar nicht mal einen Aspekt
betrachtet. Lass uns doch mal einen Extratermin machen
und zwei Stunden drüber reden.
Und das wäre ja beides noch
im normalen Selbstorganisationsrahmen
alles enthalten. Also
das alltägliche Problem ist ja
schon, wann wurde genug geredet,
wann wird entschieden? Und dann
ruft ja eigentlich jeder im Team
nach einer Entscheidung. Nach einer Entscheidung, die
sagt, okay, jetzt haben wir wirklich genug
oder nee, wir wollen noch. Und dann sind wir wieder bei der
Führungskraft und bei der
Hierarchie in Anführungszeichen
jemand, der beurteilen muss, wann ist
genug geredet worden.
Wenn das Team das selbst
tun soll, dann
ist halt die Gefahr, dass
auch da heute das viel
drüber reden eher als richtig gilt.
Das ist jetzt eine Hypothese.
Ich weiß nicht, ob das jetzt so allgemeingültig ist.
Das ist so mein Eindruck. Und dass dann
noch mehr zerlabert wird
oder verlabert wird und am Ende
dann trotzdem nichts entschieden wird oder was.
Entschieden wird es dann wieder ein Folgemeeting.
Also ich finde es wahnsinnig toll,
wenn das Team sich einbringen
kann. Das bereichert
das Team, bereichert die
Führungskraft. Ich würde jetzt auch mal einen
Product Owner als solchen bezeichnen.
Aber irgendwann muss man halt sagen, wann ist genug, weil
sonst kippt es halt einfach schnell um. Und das ist
wie mit den ganzen Themen
auf der Liste Selbstorganisation und
wahrscheinlich in allen Sachen, dass
das Maß macht das Gift, heißt es ja
so schön. Und hier muss einfach jemand das richtige
Maß finden. Und dann gibt es kein richtiges
und ein Falsch, sondern maßvoll
richtig. Ja, das finde ich so
schön, auch in ihrer Reihenfolge.
Sie hat noch ein anderes Missverständnis,
was da quasi
drüber steht. Mythos 3.
Die Agilität steigt, wenn alle mitreden.
Das ist ja genau das, was du auch sagtest.
Eigentlich ist es
per se erstmal schön, wenn alle mitreden
können, wenn sich alle einbringen können.
Die Dosis macht dann das Gift und dann ist
die Frage, was sind deine Erfahrungen,
wie man das in der Praxis
dann einfangen kann. Wie kann man
diesem Missverständnis, dieser Gefahr
entgegenwirken?
Dem Missverständnis jetzt
speziell, dass die Agilität steigt oder
dass einfach zu viel geredet wird? Was meinst
du genau? Dem Missverständnis, also
das Missverständnis 3 und 4,
die würde ich beide mal so zusammenpacken
unter dem Motto,
es sollten alle mitreden und das ist gut.
Und du hast ja gerade gesagt,
irgendwann kippt das Ganze. Also irgendwann ist es
nicht mehr gut. Dann ziehen sich Leute zurück.
Man kommt nicht auf den Punkt. Die einen
sagen, wir haben zu viel geredet. Die anderen sagen, wir haben
zu wenig geredet. Also wie kriegt man so ein
Idealmaß an, ich sage mal,
perfekter Kommunikation,
einem perfekten Austausch in einem solchen
Team hin? Dann sind wir eigentlich sofort wieder bei
der Frage nach den Führungskräften, weil jemand
muss das ja entscheiden. Dafür gibt es natürlich keine
Rechenformel, wie viele Minuten
jetzt in welchem Kontext genug sind. Du musst halt
einfach die Gruppe, das Team ein bisschen,
die Situation ein bisschen lesen
und erfassen, wo die sich befinden.
Du musst den Kontext kennen, in dem
dein Projekt sich befindet. Du musst
dich fragen, wo du in den nächsten drei,
Monaten hin willst. Du hast die längere Perspektive
und daraufhin eine Entscheidung treffen, was ja genau
dieses Management-Dilemma ist.
Und ich glaube, die Frage
nach, wann ist das richtig oder
wann wäre es noch ein bisschen früher, ein bisschen
später, ist nicht die allererste
Frage, die allererste. Jemand
muss sich einfach bewusst sein, dass er
diese Entscheidung zu fällen hat und es
dann einfach auch tun. Wir reden ja im Agilen ganz
oft über schnell etwas
machen, dann daraus zu lernen
und es wieder anzupassen. Und ich glaube,
und das ist sicherlich
kein Rezept, das sich so
schnell nachbacken lässt, trotzdem halte ich es für
wichtig, den Produkt-Owner
oder die Führungskräfte eben ermutigen,
das auszuüben und zu sagen, ich habe
den Eindruck, dass wir jetzt
darüber schon genug gesprochen haben. Wäre es für euch okay,
wenn wir das jetzt hier beenden
und ich dann eine Entscheidung fälle?
Also man kann ja erst schon mal fragen und ich glaube,
in vielen Teamsituationen würden dann
die meisten sagen, ja, ist es
wunderbar, entscheid jetzt. Ob es jetzt plus, minus
zehn Minuten spielt, spielt eigentlich gar keine Rolle.
Und man merkt dann schon, wenn das Team sagt, nee, Moment, Moment,
Moment, so geht das ja gar nicht. Das ist jetzt
wirklich, wirklich wichtig. Das mag dann
wiederum nicht jeden Einzelnen betreffen, aber wenn es
halt einen starken Widerstand gibt,
dann macht man doch mal eine halbe Stunde. Aber auch das, man kann
ja wieder fragen, sagt, okay, wäre es okay,
wenn wir nochmal eine Viertelstunde dranhängen
oder wollt ihr noch ein bisschen länger? Ja, wir wollen gerne
eine halbe Stunde. Alles klar, dann setze ich jetzt einen Timer
und wir reden nochmal eine halbe Stunde.
Du hast das ja vorhin auch erwähnt gehabt, Transparenz.
Ich glaube, einfach die
Dinge, die gerade sind, nämlich ich weiß
nicht, wie lange wir noch reden wollen, einfach
mal auszusprechen. Ich weiß nicht, wie lange wir noch reden wollen,
wie wäre es mit einer halben Stunde
oder wollen wir jetzt beenden? Und einfach
das, was im Raum steht,
zu transformieren
in eine Frage oder in eine Äußerung
und dann dem Team hinzuhalten und zu sagen,
ey, wie seht ihr das denn? Gibt meistens
so extrem hilfreiches Feedback,
dass ich als Führungskraft eben nicht
schlauer sein muss als das Team,
um zu wissen, was ist jetzt richtig, sondern
in allermeisten Fällen reicht es mir,
wenn ich Teamfeedback hole. Und manchmal,
aber wirklich nur manchmal,
muss ich eben auch sagen, okay, ihr wollt
jetzt noch zwei
Stunden reden, können wir nicht, wir müssen
heute das entscheiden, ich muss es da und da
und da hintragen heute, da kann ich nichts dran ändern,
das ist der Rahmen, in dem ich mich bewege,
noch zehn Minuten, dann werden
wir, dann werde ich entscheiden. Aber
ich glaube, mein
persönliches größtes Learning ist,
versuch nicht schlauer zu sein als deine Leute,
sondern bringen sie ein,
auch bei Führungsthemen, aber entscheiden
muss ich, habe ich keine Fragen, was sie jetzt für
richtig halten, weil, Entschuldige, dass ich
aushole, aber im Scrum ist ja dieses
implizite Wissen, das wir aus den Leuten
rausholen wollen, deshalb bringen
wir ja selbst Organisationen rein, ist ja unser
höchstes Gut. Die zehn Leute im
Team wissen zehnmal mehr als
eine einzelne Person, also ist doch unser Ziel,
das möglichst stark zu heben. Warum
nicht auch in solchen Fragen?
Ja, und das ist meine Erfahrung,
dann kommen wir wieder zu dem erstgenannten
Missverständnis oder Mythos.
Ich glaube, dass sich dann die
Führungsrolle, ich sag mal Führungsrolle,
dass es unterschiedliche Personen
gibt, die Führungsrolle dann übernehmen.
Du hast eben gesagt, es gibt
einen Product Owner, der vielleicht irgendein Ergebnis
weitertragen muss, dann gibt’s
sicherlich immer noch den Scrum
Master, der auf seine Art und Weise
eingreifen kann oder unterstützen
muss, der dann auch die Uhr stellt und andere Dinge
tut, aber was ich auch schon erlebt habe,
ist, dass in den Teams selber, also
Mitglieder dieser Teams sagen,
lass uns mal auf den Punkt kommen und das finde ich
dann schon genau das, was du auch
sagtest, transparent, das ist eine gewisse Reife,
als wenn ich da sitze und als
Teammitglied nicht zu übersehen
mein Gesicht verziehe und zeige,
dass jetzt zu weit geht, es wird zu lange reden
und dass ich aber dann daran nichts
ändere und dann auch da, wie gesagt,
Führungskraft oder Führungsrolle, denke ich,
kann auch aus dem Team herauskommen,
wenn ich einen Product Owner habe,
der vielleicht noch ein bisschen unsicher ist oder der
auch vielleicht mit
dem Thema Selbstorganisation noch nicht so
ganz zu Rande kommt, dass ich eben
aus dem Team auch jemanden habe, der eine
Führungsrolle übernimmt und für
eine Zielfindung oder
Zeiteinheit und dann auch sorgt.
Absolut, das ist ja auch extrem,
also
jeder Leader, jeder Führungskraft
ist ja dankbar, wenn er
nicht selbst alles tanzen muss,
wenn es Leute gibt, die ihn dabei sehr aktiv,
proaktiv, stark
unterstützen. Ich glaube, die eigentliche
Angst an jeden Führungskraft
ist nur, dass das letzte
Wort ihnen entrissen wird und
wenn es gibt
diese Konzentration dann, dass wenn
zwei, drei sehr starke Spieler in dem Team
sind, der Scrum Master
im organisatorischen Sinne und der Product Owner
im fachlichen Sinne das Gefühl hat,
oh verdammt, wenn ich nicht jetzt relativ
dominant, stark
auftrete, dann verliere
ich diese Option am Ende zu sagen,
okay, wir gehen jetzt links rum und
das sehen wir auch immer
in Teams, die, also das ist jetzt
auch eine sehr persönliche
Wahrnehmung an vielen Projektsituationen,
auch gerade kürzlich erst,
dann habe ich mit den starken
Alpha-Anwärtern
in den Teams mich
einzeln unterhalten, bin eine Stunde spazieren gegangen,
habe ihnen einfach mal das Bild gegeben, dass halt
entsteht, wenn du so eine starke
Team-Dynamik hast
und ich glaube,
egal wie oft ich solche Gespräche hatte,
jeder von denen wollte nur
das Beste für das Team, wollte das Beste
für das Produkt, wollte jeden nur unterstützen
und war sich vielleicht nicht ganz so klar,
wie schwierig es
für eine Führungskraft ist, sowas einzubremsen,
weil wir haben es ja vorhin schon kurz gehabt,
das ist ja eh schon nicht leicht, Führung
auszuüben und dann noch bei einem starken
Counterpart gelingt es dann meistens gar nicht mehr.
Und ich finde es immer total schön,
wenn an solchen Gesprächen die Leute
sich einfach einen ganz kleinen Tick zurücknehmen
oder ein bisschen stärker auch eben
die Pflichten der Stärke wahrnehmen
und sagen, oh, jetzt scheint
der Scrum Master in die Ecke getrieben
zu sein regelrecht, da muss ich halt
auch ein bisschen für eine Moderation
mitsorgen und kann nicht nur einfach sagen,
ja, aber ich chat gerne linksrum, fertig.
Und das sind so Momente, wo die Teams
wirklich anfangen, sich selber
stärker zu organisieren, weil jeder
seine Rechten- und Pflichtenanteile stärker
wahrnimmt und ausübt und
das sind immer die Dinge, wo mir dann ein bisschen
das Herz warm wird, wenn ich das beobachten darf.
Das ist ganz fantastisch, wenn nicht.
Ja, das finde ich auch schon,
wenn man dann
als derjenige, der das
ein bisschen unterstützen soll, sieht, dass das
funktioniert oder wenn man, wie du
dann auch sicherlich manchmal in deiner Rolle
als Product Owner dann auch sieht, hey,
ja, es funktioniert. Also ich kann
auch anders führen und
kriege dabei vielleicht ein noch, nicht nur
vielleicht, kriege dabei dann ein besseres Ergebnis raus.
Genau. Man müssen so alle
gemeinsam ein Stück wagen und dann werden wir
gute Erfahrungen machen damit.
Ja, nicht umsonst gibt es ja den Spruch
durch Fragen führen.
Das ist ja auch keine agile Erfindung an der Stelle.
Nee, der ist auch schon ein bisschen älter,
aber er ist immer noch gut.
Ja, ja, ja, okay.
Ich habe ein bisschen vorwärts gescrollt.
Mythos Nummer 9. Selbstorganisation
ist ein Selbstläufer, wenn sie mal
läuft. Das wäre doch wunderschön.
Also ich habe auch schon teilweise
Abteilungsleiter erlebt,
Gruppenleiter erlebt, also wirklich
klassische Manager,
die nach meinem persönlichen
Eindruck gesagt haben, super, lass
mein Team mal Scrum machen, lass die mal
agil sein, die sollen sich selbst organisieren.
Das schiebe ich an und dann habe ich endlich meine
Ruhe und das war nicht immer sehr erfolgreich
oder seltenst.
Ja, ich glaube, dass
auch da ein Stück weit ist
da was dran. Also andersrum,
so ein Team ist ja ein System
und aus der Systemtheorie
wissen wir ja beide, dass wenn
ein System keine
Veränderung erfährt, also nichts von drinnen,
von draußen sich verändert, kann
es schon, ist ja eben
ein theoretischer Zustand, kann es
schon stabil sein. Das heißt, dann wäre
es eigentlich ein Selbstläufer. Aber
in der Praxis ist das natürlich nicht so. Schon im
allerkleinsten Maßstab, der Kollege
Müller kommt dann halt am Montag
rein, hatte irgendwie am Wochenende
Schwierigkeiten, hat sich über seinen
Nachbarn geärgert und kommt mit einer schlechten
Laune rein, verhaut irgendetwas
und schon hat sich das System ein Stück weit verändert.
Natürlich jetzt in dem Fall erstmal im
Kleinen, aber es gibt
Staffingwechsel, es gibt neue Strategie,
es gibt neue Anforderungen, es gibt
organisatorische Wechsel. Das System ist ja
im ständigen Wandel
und das Schlimme
in Anführungszeichen ist, dass
du, wenn das
System einmal aus dem Zustand A
herausgebracht wurde, du kannst es nicht wieder
in den Zustand A zurückbringen, sondern
sobald du eine Veränderung erlebt hast, ist es
danach im Zustand A‘, wie das
in der Mathematik, wenn ich mich recht erinnere, noch heißt.
Das heißt, du hast dich in jedem Fall
weiterentwickelt. Das heißt, die nächste
Zwischenphase
der Selbstläufer-Situation
ist eine andere und das kann dann auch wieder
zwei, drei Wochen oder auch, ja, ich glaube
länger nicht, relativ
beaufsichtigungsfrei
gut funktionieren, bis
der nächste Impuls kommt und dann hast du auf einmal
ein Team, das ist dann bei A‘
und das heißt nicht, dass A‘ besser war als A‘,
es ist aber auf jeden Fall anders und
dieses ständige Beobachten,
was tut sich denn da draußen,
muss,
jetzt statt links rum, rechts rum gedreht
werden, um nachher das Gleiche vielleicht zu erreichen,
das hat eine dauerhafte Führungsaufgabe
und ja,
aus der Verantwortung kommt das
gemeinsam selbstorganisierte Team nicht raus
und auch nicht die Führungskraft. Also,
ich genieße trotzdem die Phasen, wenn mal zwei, drei
Wochen Ruhe in Anführungszeichen
ist und es einfach nur läuft, das genießt
man dann wirklich gerne,
aber es ist halt von kurzer Dauer.
Meine Hoffnung dabei ist immer, wenn es mal zwei, drei
Wochen läuft, dass dann das Team
einen höheren Level erreicht
auf den es oder den es halten möchte.
Das heißt, die Ansprüche an das vom vom Team an das Thema
Selbstorganisation, die steigen damit und wenn die Ansprüche steigen,
dann steigt aber auch die Verantwortung des Teams,
das auch die eigenen Aktivitäten darauf hin auszurichten.
Das heißt, ein Team wird reifer und reifer,
braucht immer nochmal Impuls von außen, braucht Unterstützung von außen,
aber wie meine Hoffnung ist und das erlebe ich dann schon auch nochmal häufiger in der Praxis,
dass die Teams dann quasi einfach immer so Level aufsteigen und immer reifer werden,
und sich besser selbst organisieren und dann mit solchen Ausreißern,
mit solchen Impulsen, die ein ein System stören, besser zurechtkommt,
weil sie wissen, dass sie dafür auch etwas tun müssen.
Völlig richtig, kann ich nur unterschreiben.
Es gibt dann immer wieder mal kleine Dips, wie bei so einem Börsenkurs.
Der bricht man wieder ein bisschen ein und dann wird es wieder deutlich besser.
Aber ich glaube, das ist total richtig.
Sowas ist langfristig ein stabiler Aufwärtstrend, wenn man dranbleibt.
Und das ist auch eine schöne Entwicklung, wenn man sich sowas zwei Jahre anschauen darf.
Ja, also formulieren wir diesen Mythos.
Neunmal positiv um, Selbstorganisation ist kein Selbstläufer.
Selbstorganisation braucht Unterstützung, braucht Führung.
Und wer in dem Blogbeitrag von der Julia reinschaut, die hat dazu ein Buch geschrieben.
Von Boris Kloga gibt es auch Bücher dazu.
Also das Thema Selbstorganisation braucht Führung.
Da gibt es mindestens zwei Bücher dazu, die das auch nochmal ein bisschen ausführen und erläutern.
Ja, ich glaube, man ist sich auch eigentlich darüber einig.
Abseits der Hype-Schlagzeilen, die irgendwo stehen, Leute, die sich damit profunder beschäftigt haben,
sind da, glaube ich, alle auf derselben Seite.
Ja, jetzt kommen wir zu einem Punkt, der mir persönlich sehr, sehr wichtig ist
oder der in diesem Mythos mit auftaucht.
Bin mal gespannt, welche Sicht du darauf hast.
Mythos Nummer elf.
Selbstorganisation kann man am Markt einkaufen.
Also ich vermute mal, dass du die gleiche Ansicht hast wie ich,
aber vielleicht machen wir uns auch bei dem einen oder anderen freiberuflichen Scrum Master jetzt unbeliebt.
Aber meine Meinung ist, dass ich als ein Unternehmen,
was in Richtung Agilität geht, ich brauche eigene Scrum Master.
Ich brauche die Leute, die aus meinen eigenen Reihen kommen.
Ich kann sicherlich für eine Einstiegsphase, für den Beginn mit externen Scrum Mastern arbeiten,
aber auf Dauer muss ich, wenn ich mein Unternehmen wirklich selbstorganisiert hinbekommen möchte,
muss ich dafür eigene Leute haben.
Wie siehst du das?
Wie sollte ich dir widersprechen?
Du machst das auch schon so lange.
Wir haben ganz ähnliche Erfahrungen gemacht.
Also dem kann ich natürlich nur zustimmen.
Trotzdem macht die Frau Kuhlen da einen ganz wichtigen Punkt.
Ich glaube, wenn, also meine Beobachtung ist, egal in welchem Setting du eine gewisse Zeit läufst,
dieses Setting tendiert dazu, sich selbst festzufressen in so einen Komfortzonenzustand,
den es irgendwann einfach erreicht hat.
Das System schwingt sich irgendwie ein und es ist dann wirklich schwer,
aus sich selbst heraus wieder Impulse zu finden.
Ich habe das oft gesehen und das gilt für mich exakt genauso.
Also erstens, ja, du hast völlig recht.
Jedes Unternehmen braucht gutes Scrum Master und gutes Scrum Master sind außerordentlich schwer zu bekommen,
weil es eine merkwürdige Qualifikationskombination ist, die es sonst selten gibt.
Du musst technisches Verständnis haben, du musst ein bisschen Menschenverständnis haben
oder vielleicht sogar ein bisschen mehr davon.
Du solltest ein Business Background haben, du solltest immer gut gelaunt sein,
motiviert sein, Leute antreiben können auch.
Also das ist echt ein verdammt schwieriger Job.
Und ich würde jedem, jeder, der einen guten Scrum Master gefunden hat, sagen,
bitte tu alles, um ihn zu behalten.
Das ist ein ganz rares, extrem wertvolles Wesen.
Aber selbst der allerbeste Scrum Master würde nach zwei Jahren sich ein bisschen einblüllen lassen
von dem gegebenen Zustand und dann braucht der vielleicht einen Coach.
Dann kommen so jemand wie du und ich mit rein und wir machen das mal für ein halbes Jahr vielleicht.
Natürlich nicht nur mit einem Scrum Master, sondern mit einer ganzen Gruppe von Leuten.
Aber auch wir werden nach einem halben Jahr,
wenn wir da öfters sind oder im Jahr, ein bisschen verbraucht und hätten auch keinen frischen Blick mehr.
Das heißt, du musst mindestens, also ich finde, du solltest dir Coaches besorgen.
Das heißt nicht, dass die den ganzen Tag da sind, aber immer wieder mal impulsartig für ein halbes Jahr,
aber auch nicht viel länger und dann mal wieder ohne und dann aber wieder einen nehmen.
Aber nicht den gleichen, auch wenn man mit dem zufrieden war.
Das geht doch natürlich genauso für mich.
Ich sage auch, hey wie, nach einem halben Jahr zurückkommen macht meistens nicht so wahnsinnig viel Sinn.
Das ist doch mal jemand anderen, der einfach frische Impulse setzt.
Und ich glaube, im täglichen Doing kann das die Firma selbst, aber wenn du wirklich in der Kurve,
die du beschrieben hast, wenn sich die Reife gerade erhöhen, dann denken die Teams irgendwann,
sie wären oben angekommen und es braucht einen externen Impuls, der sagt,
nee, da geht immer noch was, komm, lass uns rausfinden, was das ist.
Und ich glaube, deshalb ist das eine wunderbare Zusammenspiel von guten, stabilen Scrum Mastern
in den Firmen, angestellt dort und externen Impulsgebern, die aber auch selber durchwechseln müssen.
Ja.
Ja, perfekt.
Also auch da positive Formulierung, Selbstorganisation kann man nicht einkaufen.
So positiv ist das ja gar nicht formuliert.
Also Selbstorganisation muss man selbst herbeiführen.
Es ist eine wichtige Aufgabe des Unternehmens, das selber hinzubekommen.
Ja, auf jeden Fall.
Sonst bist du ja quasi abhängig.
Das ist ja bei jedem Coach eigentlich der erste Anspruch.
Ich will mich schnellstmöglich, wie sagt man, dass ich nicht mehr gebraucht werde.
Ich will mich schnellstmöglich wieder abschaffen.
Das muss auch unser Anspruch sein.
Das muss unser Anspruch als agile Coaches sein, möglichst schnell den Kunden dazu zu bringen,
das Ganze alleine zu können.
Und wenn er dann wieder Bedarf hat, dann kann der Nächste kommen.
Das finde ich immer so lustig, wenn ich in den Scrum Trainings habe ich bei der Erläuterung,
was ein Scrum Master, was einen guten Scrum Master ausmacht, ist eben, er sollte im Prinzip
daran arbeiten, sich selbst überflüssig zu machen.
Und dann gucken sie immer erst mal groß.
Aber wenn dieser Spruch kommt oder diese Aussage, dann sind wir schon ein bisschen tiefer eingedrungen.
Man versteht dann relativ schnell, was ich damit meine.
Ich habe ja auch den Weichmacher drin im Prinzip.
Also die Frage kann man wahrscheinlich mit Nein beantworten, ob er sich wirklich irgendwann überhaupt mal überflüssig machen könnte.
Das haben wir eigentlich auch schon diskutiert.
Ich brauche immer nochmal einen Impuls und so weiter.
Aber das Ziel sollte eben genau sein, sich selbst überflüssig zu machen.
Sprich auch als Coach die Teams und die Scrum Master so reif zu machen, dass sie viel Wegstrecke alleine zurücklegen können.
Da hätte ich jetzt eine Frage an dich kurz.
Wir kriegen ja beide oft die Fragen gestellt, wie viel Scrum Master brauche ich denn?
Einen Scrum Master pro Team oder einer für drei Teams oder so?
Und meine etwas gewagte Hypothese ist, in einer Reifephase, die noch sehr früh ist,
also wenn das Team ganz frisch ist mit der Methode und mit sich selbst, solltest du einen Scrum Master pro Team haben.
Aber genau wenn du diese größere Reife erreicht hast, kannst du, weil du dich ja quasi ein Stück weit selbst abgeschafft hast,
jetzt deutlich weniger tun, dann kannst du auch ein zweites Team übernehmen.
Und wenn wir jetzt mal davon absehen, dass es ja auch Rituale gibt,
die du dann irgendwann vielleicht auch das Team viel stärker selbst organisiert machen lässt,
kannst du auch irgendwann als Scrum Master, der dann nur noch Impulsgeber ist,
kannst du auch drei Teams begleiten, vielleicht sogar auch mehr.
Nur die Kunden verstehen dann das ganz falsch und denken, bei drei komplett neuen Teams könnte ein Scrum Master den Job machen.
Wie ist da deine Perspektive darauf?
Also was die Zahlen angeht, die du genannt hast,
würde ich sagen, mit dem Kunden oder in dem Kundenumfeld, in dem ich tätig bin, maximal zwei.
Weil für mich der Scrum Master dann ja auch noch die Aufgabe hat, Servant Leadership durchzusetzen.
Das heißt, im Unternehmen, also das Unternehmen auch zu entwickeln.
Ich komme immer mit einem Beispiel, ich zitiere mal einen anderen Scrum Master,
der hat dann gesagt, dass für ihn viele Scrum Master nur, bingo, jetzt fehlt mir das Wort, dass sie Meeting handeln.
Ja, ja.
Also sie sehen ihre einzige Aufgabe darin, die Meetings zu organisieren, genug Post-its zu kaufen und so weiter.
Wenn du so drauf bist, dann erfüllt sie auch nicht die Ideen und den Anspruch an, auch aus meiner Sicht,
und das ist auch im Scrum Guide so formuliert, die ein Scrum Master erfüllen sollte.
Also sprich, für mich hat ein Scrum Master mehr zu tun und dann würde ich sagen,
sollte er die Zeit, die er nicht im Team verbringen muss, damit verwenden und dazu verwenden, die Organisation weiterzuentwickeln.
Und deswegen würde ich die Grenze bei zwei ziehen.
Aber wie das immer so ist, ich könnte mir auch vorstellen, dass es eben reifere Organisationen gibt an sich,
wo es auch vielleicht mit dreien nötig wäre.
Aber eine Grundaussage würde ich unterschreiben, Anfangsphase, und die kann man auch nicht mit irgendwelchen Monatszahlen belegen.
Es gibt eine Anfangsphase, da hat der genug zu tun.
Und das ist ja das Interessante, dann sagt man ja, was macht der den ganzen Tag?
In den Meetings ist er drin, der muss sich aber nicht vorbereiten.
Und dann sage ich, ja, für mich ist ein ganz wichtiger Punkt, Impediment Backlog.
Also das, was er tut.
Das, was er tut, sollte er auch transparent machen.
Und wenn man das mal geschafft hat, dann merken die Leute, was der wirklich bewegen muss.
Und das kannst du auch nicht in Zeit messen.
Also dann hat er auch mal einen Job, dass er Störungen beseitigen muss, da wo er viel länger für braucht, wo er auch mal kreative Phasen braucht.
Also maximal zwei, wenn ich das auf eine Zahl reduzieren sollte, könnten auch mal drei sein.
Aber ansonsten würde ich dir prinzipiell zustimmen.
Aber dazu muss ich ein reifes Team haben.
Oder ich muss reife Teams haben.
Was du auch sagtest, das Missverständnis ist ja da, okay, einer kann drei, dann mache ich drei neue.
Das nicht.
Die Teams müssen reif sein und die Organisation muss auch drumherum reif sein.
Ja, Mensch, oh, das macht Spaß.
Lass uns noch einen Mythos nehmen.
Wer sind die Agile Mythbusters für Selbstorganisationen heute?
Chaka Chaka und wie auch immer.
Lass uns irgendwas zur Explosion bringen.
Das würde mir jetzt noch fehlen.
Irgendwie ein dickes Bam.
Ja, das ist so die Überraschung.
Am Podcast Ende.
Dann zünde ich eine Bombe hier und dann passt alles.
Ich bin gespannt.
Dann hoffentlich platze ich nicht vor Spannung.
Mythos 15.
Selbstorganisation ist vorwiegend eine Frage von Struktur und Arbeitsmodus und nicht von Kultur, Mindset und Führung.
Warum habe ich das nochmal rausgepickt?
Weil ich feststelle, dass in vielen Unternehmen in der Anfangsphase, wenn auch vielleicht noch eine gewisse Unsicherheit vorherrscht,
dann werden eben die Teams gebildet.
Und dann hat man ja die neue Struktur und dann läuft das schon und dann klappt das schon.
Und wie siehst du das?
Ja, witzigerweise habe ich gerade gestern, hatte eine Kollegin, vielleicht hört sie ja irgendwann mal zu, Irina.
Grüße nach München.
Hatte einen schönen Post zum Thema Safe-Modell geschrieben.
Und wir sprachen dort über Frameworks, welches sozusagen das bessere wäre.
Und sie pikste mich an und sagte, ey, was denkst du denn dazu?
Und meine Antwort war.
Es ist völlig egal, mit welchem Framework du arbeitest.
Jetzt ging es hier um Skalierungsframeworks wie Safe oder Less.
Sie sagt, du kannst mit allen Frameworks erfolgreich werden und du kannst mit allen Frameworks auch komplett scheitern.
Und ich glaube, die Frau Kuhlen hat das auch so aufgegriffen.
Du kannst auch mit einer tollen Produktidee komplett scheitern und mit einer schlechten trotzdem gewinnen.
Und du kannst mit einer guten Führungskraft Gutes erreichen oder auch nicht.
Also diese direkte Abhängigkeit von, wenn ich X habe, dann kommt Y.
Ist an sich schon ein schwieriges Format, das ich gar nicht kaufen möchte.
Und dann ist jetzt hier in der konkreten Frage.
Ja, wenn ich die richtige Struktur habe, dann werde ich auch automatisch ersetze das freie Wort mit, was immer du gerne haben möchtest.
Das funktioniert nicht genauso wenig.
Auch das, ich komme auf meinen Punkt von vorhin zurück, ist so, dass da bin ich immer ein bisschen kritisch in meiner Formulierung.
Da drückt sich die Organisation und die Führung um ihre eigentliche Aufgabe und denkt, wenn ich nur X tue.
Framework einführen, Strukturen aufsetzen, Scrum Master einstellen, whatever.
Dann läuft das, weil dieses Konstrukt liefert all das, das sich dann nicht mehr liefern braucht.
Und das kann nie funktionieren.
Und ich denke, die Coaches, die im Markt unterwegs sind, wissen, und das ist eine sehr unbeliebte Aussage,
dass die überwiegende Mehrheit der agilen Projekte sind, ja, ich sage immer gerne Zoll.
Ja, ich sage immer gerne Zombies dazu.
Du kannst dich auch Cargo-Kult-Fanatiker nennen.
Da stehen die Leute vorne an Bord und sie haben das Scrum Master und sie tun all das, was man so angeblich tut, weil das gehört irgendwie dazu.
Aber das Mindset hat sich halt keinen Millimeter bewegt.
Und ich persönlich finde es extrem frustrierend, wenn man das beobachtet, wenn die Menschen in den Teams ein Jahr lang neue Tools und Techniken üben und am Ende dastehen und sagen, ja, für uns hat sich nichts verändert.
Wir kommen nicht lieber zur Arbeit.
Unsere Produkte werden nicht schneller.
Die Software wird nicht besser.
Wir tanzen im Prinzip im selben Sprit nur einen anderen Tanz.
Tatscha hat vielleicht einen Roomba, aber es fühlt sich nicht anders an.
Also insofern kann ich Julia Kull nur dick unterstreichen, die auch gleich mit einem dreifachen großgeschriebenen Nein, Nein, Nein geantwortet hat.
Organisation und Mindset haben aus meiner Sicht quasi fast keine Korrelation.
Also du kannst mit der Einführung von Methoden überhaupt gar kein Mindset verändern.
Ich bin, glaube ich, relativ langweilig in meiner Einstellung und sage, Mindset entsteht in einer guten Zusammenarbeit zwischen Menschen.
Jemand muss ein Mindset haben, ihn beweisen, ihn immer wieder beweisen, ihn wiederholt zeigen, ihn einfordern, auch dafür offen sein, dass der natürlich mitgestaltet wird mit den Leuten, mit denen er da arbeitet.
Aber am Ende geht es Menschen mit Menschen finden einen Weg, miteinander zu arbeiten.
Dafür gibt es keine Gießform, in der sich das abbilden lässt.
Das muss einfach durch Tun erzeugt werden.
Das kann nicht durch Aufschreiben und Struktur erzeugt werden.
Aber da lasse ich mich gerne noch eines Besseren belehren, weil ich hätte auch gerne den magischen Knopf und dann führe ich das und das ein und dann haben sich die Menschen verändert.
Aber daran glaube ich nicht.
Wenn du das hättest, dann müsstest du das nur zweimal machen.
Dann wärst du ein steinreicher Mensch.
Wenn diese Zauberformel vorhanden ist und du die wissen würdest.
Ich glaube, es gibt viele Unternehmen, die würden dir die gerne abkaufen.
Ja, da würde ich die Methode wie Safe gründen und damit auch viel Geld verdienen.
Oder die Methode wie Scrum, die das auch gerne noch hier so gegen Ende des Casts eingestreut, vielleicht manchmal nicht hinreichend klar machen, wo die Begrenzungen der Methode liegen.
Das macht die Methode nicht schlechter.
Aber die Erwartungshaltung, wie viel eine Methode tun kann, wird vielleicht natürlich aus geschäftlich verständlichem Interesse.
Im Marketing ein bisschen zu kurz gehalten.
Und für die Leute, die gerne an sektenartige Konstrukte glauben, ist es dann genau die Einladung zu sagen, ja, oh, wenn ich mich diesem Kult anschließe, dann wird alles gut.
Das gelingt halt selten.
Ja, das stimmt wohl.
Und wir hatten ja über die Führungskräfte gesprochen.
Ich glaube, das Thema gilt genauso für Mitarbeiter.
Du hast ja eben von dem Mindset gesprochen.
Und auch da glaube ich, ist ein weiterer Grund.
Weswegen man nicht einfach so eine Methode nehmen kann oder überstülpen kann.
Ich hasse ja das Wort Einführen an der Stelle.
Ja, oder Rollout ist auch sehr schön.
Wir machen mal einen Scrum-Rollout.
Ja, perfekt.
Also insofern, das geht nicht.
Und das geht unter anderem auch deswegen nicht, weil auch Mitarbeiter dazu manchmal nicht kompatibel sind.
Das, was du ja vorhin auch schon ein bisschen mal angedeutet hast.
Also insofern, es ist eine Menge Arbeit und ich muss eine Menge Arbeit reinstecken.
Und die Frage ist, passt es überhaupt?
Das ist eine individuelle Aufgabe jeweils.
Ja, ich erinnere mich gerade noch daran, dass, wie hieß der Kollege noch?
Frederik, den habe ich auf der Agile-Bohse-Konferenz vor drei, vier Jahren in einem Vortrag gesehen.
Der wurde aus dem Publikum gefragt von jemandem, der offensichtlich an den schnelleren Weg glaubte.
Ja, wie lange wird das denn gehen mit dieser agilen Methode?
Der hat das super toll gemacht, fantastischer Vortrag.
Glückwunsch nochmal dafür.
Und der Herr war ganz begeistert und sagte, wie lange dauert das denn?
Und dann sagte er, ja, also Minimum, um überhaupt erste Spuren zu haben.
Und dann hat er sich kurz daran erinnert, dass er wusste, dass der Herr aus dem Konzern kam und sagte,
ah, Konzern, mindestens fünf Jahre.
Und da war der Herr im Publikum irgendwie ein bisschen frustriert.
Ich glaube, das ist das, was ich, ich will jetzt kein Schlusswort draus machen,
aber ich versuche den Leuten immer klarzumachen, der Weg ist spannend, der Weg lohnt sich,
aber es ist ein langer und mühsamer Weg.
Wenn ihr keine Lust auf den Weg habt, wenn euch die Reise an sich schon keine Freude macht,
wenn ihr da nicht durch wollt, dann lasst es vielleicht lieber sein oder ruft mich nicht an.
Weil eine Veränderung, eine Veränderung ist eine spannende Geschichte,
aber sie ist nicht for free zu bekommen und du musst da durch wollen.
Und das dann zu begleiten, das ist unheimlich schön, immer wieder anstrengend,
aber einfach unheimlich, wie sagt man, also rewarding, ja, vermittelt, gibt ganz viel zurück.
Da sind wir wieder bei dem Elternbild.
Kinder sind so anstrengend, aber es gibt so viel zurück.
Das ist bei einer guten, agilen Transition auch so.
Aber die meisten verstehen einfach nicht, dass das ein langer, anstrengender Weg ist.
Und dann hören sie mittendrin auf oder erklären zu früh den Sieg und meinen, das wäre es jetzt gewesen.
Lasst euch Zeit und seid darauf eingestellt, dass es ein langer, langer Weg ist.
Ja, perfekt. Du hast ja gesagt, das sollte kein Schlusswort sein.
Nee, Entschuldigung.
Das war schon richtig super.
Und du hast mir ein bisschen mein kleines Schlusswort weggenommen, aber das macht überhaupt nichts.
Es ist ja schön, wenn man Gäste dabei hat, die ja wirklich das Ganze gut voranbringen.
Meine Kurzformel dazu ist, Selbstorganisation braucht Zeit oder Agilität braucht Zeit.
Boah, super.
Das wäre mein Kurzwort, mein kurzes Schlusswort dazu.
Guck mal, unabgestimmt haben wir am Ende denselben Drang, das zu sagen.
Es braucht einfach Zeit, nehmt sie euch.
Ja, aber vielleicht, weiß ich nicht, das Wort Seelenverwandtschaft ist vielleicht ein bisschen zu hoch.
Uh.
Egal.
Ja, Miguel.
Ich danke dir.
Danke dir für die Zeit und für die vielen spannenden Aussagen.
Und ich würde sagen, von mir aus auf Wiedersehen.
Und dann sollte vielleicht der letzte Satz wirklich dir gehören.
Ja, ich glaube, den letzten Satz habe ich schon gesagt.
Ich finde, Leute sollten einfach Zeit nehmen für die Dinge, die sie da vorhaben.
Ein bisschen gesunden Menschenverstand einsetzen.
Nicht auf jeden modernen Hype aufspringen, sondern die Sachen prüfen.
Sich auch mal ein paar Tage Zeit nehmen, mal drüber schlafen, mal mit Leuten drüber sprechen, die eine andere Perspektive haben.
Man kann so viel Gutes erreichen.
Wenn man sich nicht von solchen Hypes verführen lassen lässt.
Und darauf hoffe ich immer, dass uns das immer mehr gelingt in der agilen Community.
Weniger Hype, mehr Realismus.
Ja, und damit wünsche ich nochmal Danke für die Einladung, Dirk.
Wer mich suchen sollte im Internet unter miguelmai.de.
Mein Gott.
Mai mit M-A-Y oder einfach im Google-Suchschlitz oder im Suchschlitz der Wahl M-A-Y Agile Coaching eingeben.
Da kann man mich auch finden.
Sonst nochmal besten Dank.
Ja, gerne.
Und die Webseite werde ich natürlich auch bei den Shownotes verlinken.
Und insofern eben auch nochmal vielen Dank.
Und ja, ich würde sagen, dann beenden wir das Ganze jetzt.
Vielen Dank.
Bis zum nächsten Mal.
Ciao.

Folge 14: DevOps im SAP-Umfeld: Geht das überhaupt?

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Viele Prinzipien und Ansätze in der DevOps Philosophie passen auf den ersten Blick nicht zum monolithischen SAP. Mit Daniele Di Croce und Franz Hiltscher von der REALTECH AG spreche ich über die Einsatzmöglichkeiten von DevOps im SAP-Umfeld.

In dieser Podcast-Episode werden die Anwendbarkeit und die Vorteile von DevOps-Praktiken im SAP-Umfeld erörtert. Die Gäste, Franz Hilscher und Daniele di Croce von REALTECH, diskutieren gemeinsam mit dem Moderator über die Herausforderungen und Möglichkeiten der Integration von DevOps in SAP-Systeme. Sie betonen die Bedeutung von kulturellen Veränderungen in Unternehmen, den Einsatz von Automatisierungstools und die Notwendigkeit, klein anzufangen und schrittweise vorzugehen. Trotz der Komplexität von SAP-Systemen und anfänglicher Zweifel, zeigen sie auf, wie agile Methoden und DevOps erfolgreich implementiert werden können, um schneller auf Marktanforderungen zu reagieren und die Qualität der IT-Services zu verbessern.

Inhalt

  • Einleitung und Vorstellung der Gäste
  • Grundlagen und Definition von DevOps
  • Anwendbarkeit von DevOps im SAP-Umfeld
  • Herausforderungen bei der Implementierung von DevOps in SAP
  • Bedeutung von kulturellen Veränderungen und Mitarbeitermotivation
  • Einsatz von Automatisierungstools in SAP
  • Praktische Beispiele und Erfahrungen aus der Realtek
  • Agile Methoden und deren Einfluss auf SAP
  • Organisatorische Veränderungen durch DevOps im Unternehmen
  • Wirtschaftliche Vorteile durch DevOps-Anwendung in SAP
  • Abschließende Empfehlungen und Ausblick

Transkript (automatisiert, daher keine Gewähr 🙂 )

Herzlich willkommen zu einer neuen Folge zum DevOps-Podcast auf die Ohren und ins Hirn.
Wir haben heute das Thema DevOps im SAP-Umfeld. Geht das überhaupt?
Und ich freue mich, dass ich dort zwei Gäste habe, die uns diese Frage beantworten können.
Ich begrüße den Franz Hilscher und den Daniele die Krotsche von der Realtek.
Und insofern würde ich sagen, auch da wieder schnell den Ball rüberspielen.
Daniele, Franz, könnt ihr euch und auch das Unternehmen mal kurz vorstellen?
Ja, gern. Ich bin der Daniele. Ich bin Mitbegründer der Firma Realtek.
Wir haben Realtek vor 25 Jahren gegründet als Beratungsunternehmen im SAP-Umfeld.
Und sind heute als Softwareanbieter im SAP-Umfeld tätig.
Und haben Tools zur Automatisierung vieler Abläufe im SAP-Rechenzentrum, die wir dem Markt anbieten.
Mein Name ist Franz Hilscher. Ich bin seit über zehn Jahren bei der Realtek.
Wenn man zu dem heutigen Thema, ich komme perspektivisch aus dem Ops-Bereich in SAP.
Also SAP-Basis, Betrieb, Systemarchitekturen und Systembereitstellung.
Sehr schön. Die Zuhörer unseres Podcasts kennen das.
Ich bitte dann die Teilnehmer auch immer oder die Gäste auch immer, sich nach der Vorstellung um eine Definition von DevOps zu bemühen.
Also insofern wäre die Frage, wie würdet ihr DevOps definieren oder beschreiben?
Gut, also ganz DevOps ist eine Sammlung von neuer Mindset, Methoden, praktischen und natürlich Software-Tools,
die den Unternehmen ermöglicht, seine Anwendungen und IT,
seine IT-Services schneller und einfacher zur Verfügung zu stellen oder bereitzustellen.
Ja, also agile Methoden sind ja im Entwicklungsumfeld, also im Dev-Bereich schon seit längerer Zeit etabliert.
DevOps ist einfach der Versuch, diese sich wirklich bewährten Methoden auf dem Bereich Betrieb auch mit zu erweitern.
Also Entwicklung und Betrieb gleichermaßen agil zu gestalten.
Franz, bei dir habe ich so ein bisschen rausgehört, auch den Punkt,
den ich ja für immer für sehr wichtig erachte, was du sagst, schneller bereitstellen,
also auch in Richtung des Kunden oder der Kunden, das heißt, den Kunden ein bisschen mehr mit einbeziehen.
Ist das richtig interpretiert?
Korrekt, ja. Es geht alles eigentlich immer weiter Richtung, also alle Services und Lösungen richten sich ja trendmäßig Richtung den Anwender,
also den Endkunden aus, also dieses kundenzentrische Agieren in allem, was wir eigentlich tun.
Ich glaube, das ist…
Mittlerweile allgegenwärtig.
Ja, wenn ich so zurückblicke, ihr habt ja beide auch ein bisschen, ein paar Jahre auf dem Buckel in der IT, aber ich mittlerweile auch.
Und ich meine, mit den Kunden haben wir immer im Fokus gehabt, haben wir jedenfalls gesagt,
aber mein Eindruck ist, dass wir durch DevOps, sprich auch die Pessosarbeit in der IT,
ja, das auch wirklich mit dem Kunden, weil doch mehr mit einer Sprache sprechen gegenüber dem Kunden.
Definitiv.
Also letztendlich ist dieser Fokus…
Der Fokus auf den Kunden, die geheime Zutat schlechthin für Erfolg.
Die Frage ist eben, in welchen Abständen man Kontakt hat zum Kunden.
DevOps ermöglicht das, in sehr kurzen Abständen letztendlich Feedback vom Kunden einzuholen,
um letztendlich auch kontinuierlich abchecken zu können, ob man genau das tut, also das dem Kunden liefert, den Wert, den der Kunde auch erwartet.
Ja, okay.
Der Titel vom Podcast lautet ja…
Im SAP-Umfeld, geht das überhaupt?
Und ich habe diesen etwas ketzerischen Titel mal gewählt, weil in meinen DevOps-Trainings dann auch schon mal SAP-Leute sitzen,
SAP-Minded-Leute sitzen oder auch Programmmanager, teilweise auch Kunden, die im ersten Moment sagen,
ja, die Ideen von DevOps sind gut, aber im SAP-Umfeld geht das nicht.
Das kann man ein bisschen auflösen in der Diskussion und es geht ja nicht nur um Automatisierung an sich,
aber so der erste Eindruck ist immer, das geht nicht.
Und insofern wäre jetzt…
Meine Frage an euch, wie kann man sich denn die DevOps-Ansätze im SAP-Umfeld zunutze machen?
Ja, geht nicht.
Das ist eine beliebte Haltung.
Gerade im SAP-Umfeld haben sich tatsächlich feste Muster etabliert über die letzten Jahre.
Aber nur weil etwas, ich sage mal, schwierig erscheint, darf man sich davor nicht drücken.
Letztendlich müssen die Kunden ihre Release-Zyklen verkürzen, also viel schneller Innovationen zum Markt bringen.
Ja, Time-to-Value.
Das muss kürzer werden.
Und diese Methoden kann man sich tatsächlich im SAP-Umfeld genauso zu eigen machen wie in anderen Bereichen.
Ja, das ist kein Hindernis.
Ja, man muss erstmal der Kopf umschalten, dass es möglich ist und nicht abzublocken.
Das ist, glaube ich, der erste Schritt.
Und die technischen Hürden kann man dann Schritt für Schritt nehmen.
Die sind nicht so groß, wie sie am ersten Blick erscheinen.
Das ist eine Kopfsache im ersten Schritt.
Ja, DevOps.
Das sagt ja, dass man mehr Wert legen muss auf Zusammenarbeit, auf Informationssharing.
Das ist natürlich im SAP-Umfeld genauso möglich wie in anderen Bereichen.
Wie läuft denn der typische Release-Zyklus ab?
Also häufig wird am Wochenende, so einmal im Quartal, ein neues Release eingespielt.
Dann stehen alle Gewehr bei Fuß, sind bereit, Anwendungsentwickler, Basisabteilung, Netzwerkabteilung
und wollen das Release einspielen und hoffen, dass alles gut geht.
Und so eine richtige High-Drama-Geschichte und meistens geht dann doch das eine oder andere schief.
Und dann steckt man die Köpfe zusammen und fängt an, Lösungen zu suchen.
Und hier ist eben der Ansatz von DevOps, warum tut man die Köpfe nicht schon vorher zusammenstecken,
mehr miteinander reden, mehr sich gegenseitig einbinden und versuchen,
bevor die Dinge schief gehen, letztendlich zusammenzuarbeiten und Qualität hereinzubringen.
Vor allen Dingen in einer Zusammenarbeit, die täglich stattfindet, die nicht einmal im Quartal stattfindet.
Damit es eben mehr Routine ist.
Wie wird es im SAP-Umfeld aussehen?
Denn dieses Vorurteil, das geht nicht, das muss ja irgendwo einen Grund haben, muss irgendwo herkommen.
Das SAP-System ist ja immer, sagen wir mal, der digitale Kern in den Unternehmen oder wird es gern bezeichnet
und hat auch diese Mantra, es muss stabil sein und es muss immer verfügbar sein.
Wenn es steht, steht das Unternehmen.
Das hat sich dermaßen, sage ich mal, in den fast Dekaden, 25 Jahre,
denke ich mal, in den Köpfen so eingebrannt und die ganzen Methoden und die Abläufe wurden daraufhin optimiert
und sind halt entsprechend auch unflexibel an der Stelle.
Und das jetzt aufzubrechen, das geht in kleinen Schritten.
Also wenn ich jetzt sage, ich möchte dieses ganze gewachsene Konstrukt und optimierten Betriebs- und Entwicklungsprozess im SAP-Umfeld
in Summe quasi umstellen, wird das…
Also ist das natürlich eine, erscheint diese als unlösbare Aufgabe.
Und ich denke mal, man muss hier wirklich in kleinen Schritten anfangen.
Entweder man macht einen einzelnen Prozessschritt oder man sucht sich ein eigenes System oder einen Bereich aus,
der ein bisschen autark agieren kann, um hier erste Erfolge zu feiern.
Und das dann im nächsten Schritt im SAP geht das natürlich per se über Automatisierungsmaßnahmen.
Das heißt, wenn ich das richtig interpretiere, geht es einmal um Kultur.
Also die Köpfe müssen sich öffnen.
Da ist eben auch eine gewisse Unflexibilität in den Köpfen über die Jahre hinweg gewachsen,
was natürlich auch erstmal nachvollziehbar ist, aber dann eben auch eine Unflexibilität in den Abläufen.
Und wenn man da rangeht, dann kommt man sicherlich auch an den Punkt, dass man es entsprechend technisch unterstützen muss.
Aber wenn ich das richtig verstehe, sagt ihr, erstmal muss ich in den Köpfen etwas verändern.
Das ist richtig.
Also der gesamte DevOps-Ansatz ist ja mehr eine Religion, als dass es eine Methodik ist oder dass es ein Tool ist.
Es betrifft dann am Ende natürlich Tools, es betrifft Leute, People und es betrifft Kultur.
Die Frage ist letztendlich, wo man anfängt.
Hier bewährt sich immer die Politik der kleinen Schritte.
Also der Mitarbeiter fragt sich natürlich am Ende auch immer, was ist denn für mich da drin?
Also wenn ich jetzt hier vieles ändern muss, alles über den Haufen werfen muss, was ich früher gemacht habe,
was habe ich davon?
Ja, und das ist eben eine Führungsaufgabe, dass nicht die Veränderung als Gefahr empfunden wird,
nicht als Bedrohung, sondern als Chance, letztendlich auch selbst zu profitieren.
Das heißt, Qualität zu erhöhen, manuelle Abläufe zu automatisieren, also Sachen, die langweilig sind,
am Ende über Software abzudecken und nicht manuell zu tun.
Ja, okay.
Na gut.
Insofern stößt das auf die Frage, was ist das, was wir tun?
Ja, okay. Na gut. Insofern stößt das auf die Frage, was ist das, was wir tun?
Und dafür ist dann hier vielleicht auch das Grundproblem, was ja auch von vielen gesehen wird,
flexible, schnelle Entwicklung, also agil, versus Stabilität, sprich stabiler Betrieb,
ja dann hier auch entsprechend aufeinander und hier dann vielleicht noch ein bisschen mehr.
Denn das, was ihr sagt, ist ja vollkommen richtig.
SAP ist ja in vielen Unternehmen der Kern.
Wenn SAP steht, dann steht das Unternehmen.
Das geht natürlich nicht für die eine oder andere Inhouse-Applikation oder für andere Themen.
Also insofern ist das natürlich schon der Grund, warum wir das machen.
Da ist natürlich schon der Anspruch da, dass SAP stabil sein muss und ich brauche sicherlich
auch nicht täglich neue Funktionen in der Finanzbuchhaltung ausliefern, wenn ich jetzt
mal so wirklich den einen Kern oder den einen Bereich von SAP rausnehme.
Also insofern, ja, der Kampf, der vermeintliche Widerspruch zwischen Agilität, also Schnelligkeit
und Stabilität, der ist dann im SAP-Umfeld genauso da.
Ist denn überhaupt möglich, dass wir in dem SAP-Umfeld ein Regelmechanismus haben, dass
wir das machen?
Das heißt, dass wir ein regelmäßiges, das heißt kurzfristiges Deployment in diesen
kurzen Zyklen bekommen, denn wir haben hier doch mittlerweile recht komplexe SAP-Landschaften.
Das ist durchaus möglich.
Wir haben auch viele Kunden in der Betreuung, die das auch schon machen.
Also wir deployen Änderungen täglich in die Produktion, entsprechend natürlich mit entsprechenden
Quality-Checks vorneweg und natürlich gesteuert und kontrolliert.
Aber es funktioniert und die Kunden, die den Mut haben, das zu tun, für die wird es, stellen
sich nach einer Zeit auch die Erfolge ein, weil wenn Sie sich mal vorstellen, so ein
typischer Zyklus im SAP ist so drei Monate bis sechs Monate ein Deployment in die Produktion
zu bringen.
Wenn sich jetzt die ganzen Entwicklungen über drei oder Änderungen über drei Monate aufsummieren
und die in Gänze in das System kommen und das ist das, was der Daniel ja auch meinte
mit der großen Fehlerquellen, also eine Vielzahl an Fehlerquellen, die ich habe und das ist
ein großes Drama an der Stelle und in der Regel, nach meiner Erfahrung, funktioniert
immer was nicht.
Und die Fehler dann zu identifizieren bei der Menge der Änderungen, die ich in On-Block
im System einspiele, ist weitaus komplex und auffällig.
Es ist aufwendiger, als wenn ich kontrolliert drei, vier Änderungen am Tag ins System einbringe
und weiß, was ich dann auch getan habe und kann mich dann auch schnell die Ursache identifizieren.
Letztendlich kennt ja jeder den Spruch never change a running system.
Das hat sich lange in der IT gehalten und am Ende kommt es ja wirklich auf die Anforderungen
an.
Also wenn ich, wie Dirk gesagt hat, in der Finanzbuchhaltung brauche ich nicht jeden
Tag neue Funktionen.
Das heißt, wenn die Anforderung gar nicht vorhanden ist, Geschwindigkeit aufzunehmen,
dann muss ich die Anforderung aufnehmen.
Dann spare ich mir natürlich den Aufwand gerne und sage, es reicht mir alle sechs Monate
hier was zu tun.
Wenn aber die Anforderung stärker vom Kunden her kommt, also Vertriebsseite, Marketingseite,
die Konkurrenz macht den Druck, weil sie einfach mit neuen Dingen auf den Markt kommen und
da kann man nicht hinterherhinken, dann verändert sich das Qualitätsverständnis.
Das heißt, von Vollständigkeit und Perfektion oder Gründlichkeit geht man halt zu einem
neuen Qualitätssystem.
Das heißt, das ist ein ganz besonderes Begriff, Schnelligkeit, Flexibilität und Feedback-orientierten
Entwicklungsprozess über.
Und hier setzt eben DevOps ein, das heißt, zu ermöglichen, den Anforderungen der heutigen
Zeit auch gerecht zu werden, sich Gedanken zu machen, wo muss ich ansetzen, damit ich
auch im SAP-Umfeld diese Anforderungen vom Markt erfüllen kann, schneller zu werden.
Ihr habt eben gesagt, tägliches Deployment, einige eurer Kunden im SAP-Umfeld machen wirklich
ein tägliches Deployment.
Nun gehört ja, denke ich, auch im SAP-Umfeld Testen jetzt als Beispiel mit dazu.
Was bedeutet das denn, abgesehen von den Erfolgen, die man erzielt, an Aufwand oder an Veränderungen,
wenn ich täglich deploye im SAP-Umfeld?
Also, sagen wir mal, vom Technischen her ist es mit den richtigen Tools gut umsetzbar.
Du sprichst jetzt natürlich einen guten Punkt an, das ist das Testen, das ist im Regel im
SAP-Fall, fällt das den Fachabteilungen zu.
Also der Buchhaltung oder der Logistikabteilung, die das eben anfordert.
Und da ist halt dieses, und da kommen halt auch wieder diese Silos extrem stark zum Tragen.
Die sind nämlich nicht nur Entwicklung und Administration im SAP-Umfeld, sondern es gibt
dann auch noch die Business-Seite, die Fachbereiche, die gerade im Testumfeld auch mit involviert
sind.
Die müssen natürlich dann in dieses DevOps-Modell investieren.
Ebenso mit eingebunden werden und stärker in der Zusammenarbeit und in den Feedback-Loop
mit integriert werden, damit das auch schnell funktioniert.
Also auch vorab schon in der Entwicklung mit drin, frühzeitig, eventuell schon im Entwicklungssystem
mit auf die Funktion gucken, intervenieren können, falls das nicht in die Richtung geht,
wie es sein muss.
Und nicht mehr diese starren Zyklen haben, auch in den Testphasen.
Also ich entwickle vier Wochen, dann teste ich vier Wochen, und wenn das dann wirklich
alles abgeschlossen ist, dann bereite ich noch zwei Wochen lang das Deployment in die Produktion
vor.
Das muss im Ablauf, im Prozess, in der Dokumentation natürlich in Summe alles beschleunigt werden.
Und natürlich die Königsdisziplin ist dann natürlich auch diese Tests weitestgehend
für einen Großteil der Funktionen zu automatisieren.
Ja, Franz.
Es ist ja so.
Ja.
Franz, es ist ja sicher nicht alles automatisierbar, aber zum Beispiel gibt es ja viele Objekte,
die im SAP-Umfeld transportiert werden müssen.
Man spricht ja bei SAP nicht von Deployment, sondern von Transporten.
Es gibt Objekte, die gar nicht kritisch sind.
Das heißt, die gewissen Approval-Schritte komplett eliminiert werden können, weil man
einfach sagt, wenn das in die Produktion übergeht, dann kann das nicht viel anrichten.
Ja, also man kann solche Checks in Software, sag ich mal, abbilden.
Sodass man sich da keine Gedanken machen muss, gewisse manuelle Schritte einzuhalten,
Workflows einzuhalten, sondern kann das automatisieren.
Da, wo die Automatisierung, ich sag mal, nicht möglich ist, da wird man natürlich mit den
Limitierungen des Systems leben müssen.
Aber man kann vieles beschleunigen, vieles vereinfachen und sich letztendlich auch Routine
antrainieren.
Ja.
Wenn man einmal alle drei Monate so eine Prozedur durchführt, eben Release einzuspielen, dann
ist es jedes Mal wieder ein neues Abenteuer.
Wenn man das täglich macht, dann ist es Routine.
Es verliert einfach den Schrecken, wenn man täglich etwas tut, wie soll ich sagen, also
dass es irgendwie schwierig wird.
Und wenn man täglich etwas tun muss, dann wird man sich auch angewöhnen, so ist der
Mensch halt, weil er faul ist, die Dinge in Skripte oder in Software zu automatisieren,
weil jeden Tag dieselben Handgriffe zu machen.
Ja.
Das kommt dann irgendwann doch ein bisschen merkwürdig vor.
Franz, du hast eben davon gesprochen, dass ja eigentlich auf der Business-Seite auch
die Silos da sind, die Spezialisierung auf ganz bestimmte Bereiche und dann sich die
Silos dort eventuell auch behindern.
Nun ist ja ein Teil von DevOps eventuell auch die Teams entsprechend oder die Organisation
anders zu gestalten, Teams anders zu gestalten und Teams quasi um Business-Funktionen oder
Business-Bereiche herum zu gestalten.
Stichwort Conway’s Law.
Habt ihr da auch schon Erfahrungen bei Kunden, dass sie eben auch ihre SAP-Mannschaft anders
aufgestellt haben, quasi noch mehr in Richtung Business organisiert haben?
Ich kenne viele Kunden, die das gerade machen.
Also die organisieren sich in der IT nicht mehr nach funktionalen Aufgaben, also Server,
Datenbank, wie es, sag ich mal, in den letzten Jahren üblich war, also schon viele oder
sind schon viele.
Oder sind dazu übergegangen.
Ja.
Die Kunden versuchen dann, sich in ihrer Organisation nach den Business-Funktionen auszurichten,
zumindest was die Kundenseite angeht, ja.
Ein paar wenige haben das wirklich auch in der kompletten Linienorganisation dann natürlich
auch mit übergreifenden Teams dahinter schon umgesetzt.
Also was du sagst, also die Richtung ist ganz klar zu erkennen bei den Kunden.
Jetzt haben wir eben schon ein bisschen was angesprochen, also organisatorische Veränderungen
eventuell.
Natürlich technische Veränderungen, Automatisierung.
Gibt es noch ein paar Rahmenbedingungen, die man aus eurer Sicht berücksichtigen müsste,
wenn man im SAP-Umfeld in Richtung DevOps geht?
Ja, also es ist, das Thema in Summe ist natürlich sehr komplex.
Ich würde empfehlen, sich ein kleines Team zu suchen, die auch begeistert sind, innerhalb
der SAP-Organisation oder IT-Organisation das anzugehen.
Und dann mit Keywords.
Ja.
Und dann auch in kleinen Projekten und kleinen Schritten quasi Erfolge feiern und darzulegen,
dass es möglich ist und sich dann Schritt für Schritt an die, ich sage mal, an die
großen Kernsysteme ranzuwagen.
Und man muss, man darf nicht quasi versuchen, die komplette IT-SAP-Organisation mit einem
Big Bang auf DevOps umzuschalten.
Das wird nicht funktionieren.
Und man muss seine Infrastruktur, also auch den ganzen, sage ich mal, den ganzen Application Stack da sukzessive in die Richtung bewegen. Aber Einstieg, sagen wir, start small, think big ist, glaube ich, da der beste Weg.
Ja. Und nicht sofort, wenn man, sagen wir, im ersten Schritt Prozessschritte jetzt nicht nach, sagen wir, nach DevOps, nach dem DevOps-Modell betreiben, umsetzen lässt, dann auch nicht. Dann lege ich den erstmal zur Seite und versuche, den nächsten Prozessschritt zu automatisieren, zu vereinfachen.
Also ich will das vielleicht so ergänzen. Ich meine, am Ende ist es ja so, dass, also ich sage mal, sich agil zu machen.
Ist zunächst mal ja mal ein Change-Prozess. Das heißt, ob das jetzt einhergeht mit Kulturwandel, mit Organisationsveränderungen, mit der Einführung neuer Tools, es sind Changes, es ist Veränderung.
Und der Mensch verändert sich in der Regel nicht so gern, es sei denn, dass er erkennt, dass das notwendig ist. Das heißt, die Frage ist, wo kommt die Anforderung her? Also wo kommt der Druck her, dieses Optimization for Speed im Unternehmen quasi,
Einzug halten zu lassen, statt, wie bisher immer ging es ja darum, Optimierung vor Kost. Es mussten die Sachen immer effizienter, günstiger werden. Und in Zukunft soll man ja eigentlich schneller anpassungsfähig sein auf die Anforderungen des Kunden.
Wenn das gegeben ist, dann wird der Wandel in Richtung einer DevOps-Organisation schon sehr schnell sich rumsprechen in Unternehmen, dass das Vorteile bringt, dass das zwingend ist, dass man sich dem nicht entziehen kann.
Und dann heißt es eben nur, wo fange ich an? Also People, Prozesse. Und da hat der Franz ja gerade gesagt, da bewährt sich die Politik der kleinen Schritte. Also nicht mit der Tür ins Haus fallen, sondern Projekte herausnehmen, wo man das vielleicht auch einfach umsetzen kann.
Das wird sich dann intern schon rumsprechen, dass man schneller zum Ziel gekommen ist mit weniger Problemen, mit weniger Qualitätsproblemen. Und letztendlich hat man sein Ziel in kürzerer Zeit mit besserer Qualität erholen.
Also diese internen Fürsprecher für die Methodik zu finden, das ist, glaube ich, ein guter Ansatz.
Ja, okay. Franz, du hast eben nochmal davon gesprochen und Daniela auch, ja, mit dem Vorschlag, mit kleineren Schritten zu starten, aber auch mit entsprechenden Teams.
Wie stark hindert denn dann das Thema ein komplexes, zusammenhängendes System, nämlich SAP, beim Aufbau von autonomen Teams?
Wenn ich an meine Schulung auch da wieder entsprechend zugehe?
Das ist ja ein wichtiger Punkt, den wir rüberbringen. Autonome Teams. Und autonome Teams heißt auch, dass sie ja auch von der Architektur her autonom sein müssen. Stichwort Microservices. Also insofern, die Frage wäre, wie stark hindert SAP den Aufbau von autonomen Teams, die ja auch architektonisch autonom sind?
Im jetzigen Release, also das SAP ERP, was noch sehr verbreitet ist, gibt es die Softwarearchitektur.
Natürlich ist der Aufbau von Microservices nur sehr, ja, nicht wirklich möglich, eins zu eins. Dazu kommt, dass sich halt aufgrund der steigenden Rechenleistung in den letzten Jahren auch sehr viel konsolidiert wurde von den Unternehmen.
Wieder Optimation for Cost. Natürlich versucht, so viele Funktionen wie möglich in ein zentrales System zu bringen, um Wartungsaufwände zu sparen.
Und so weiter und so fort. Ich glaube mal, natürlich perspektivisch und auch mit S4HANA muss da, was das SAP System Landscape Design angeht, da auch eine andere Richtung eingeschlagen werden, um das natürlich durchgängig zu schaffen.
Und es wird auch mehr und mehr Microservices aus der SAP Cloud mit integriert.
Und das, sage ich mal, Schritt für Schritt, sage ich mal, nicht von alleine löst, aber mehr und mehr entspannen wird.
Es gibt aber, sage ich mal, auch kleinere, sage ich mal, Zuhilfssysteme, die man autonom am Anfang schon betreiben kann.
Das sind jetzt natürlich nicht, sage ich mal, die Produktionssteuerungssysteme, aber zum Beispiel im HR-Umfeld, wenn man gerade sehr viel Richtung Employee Self-Services macht im SAP und da auch, gut, das ist jetzt, und den Mitarbeitern.
Da sehr viele Zusatz-Services bieten will, kann man das auch in einem kleineren Umfeld machen oder in einem GTS-System, was jetzt, sage ich mal, nicht so stark komplex ist.
Man muss, ich glaube, man muss diese Spielfelder identifizieren, finden und anfangen.
Ich glaube, wir müssen vielleicht auch ein paar Begriffe nochmal differenzieren, weil wir reden die ganze Zeit über SAP.
Die Frage ist nur, SAP ist eben nicht mehr wie vor 20, 25 Jahren.
Der Hersteller eines monolithischen, sage ich mal, Systems, damals R3, heute S4, HANA, welches alle diese integrierten Funktionen, die man im Unternehmen zur Steuerung von Unternehmensprozessen benötigt, integriert hat oder in einem Ort hat.
SAP ist heute ein sehr, sehr großes Unternehmen mit sehr, sehr vielfältigen Produkten, die es letztendlich anbietet.
Und deswegen müssen wir nochmal unterscheiden.
Also das Klassische, wie man SAP kennt, ist sehr geprägt von diesem Silo-Denken.
Ich habe eine Basisabteilung, die IT.
Ich habe eine Anwendungsentwicklung, die Prozesse kennt und entwickelt und es eigentlich mal dann auch zur Verfügung stellt den Benutzern.
Die SAP selbst versucht, diese Problematik ein Stück weit damit zu lösen, zu sagen, okay, geht mit dem System, mit dem Monolithen, mit dem Kern in die Cloud.
Dann braucht ihr schon überhaupt gar keine Basis mehr, weil das macht die SAP.
Und alle Änderungen macht ihr über die Cloud-Plattform.
Die SAP Cloud-Plattform ist ja von sich aus, wie sie geboren wurde, schon ein agiles System.
Agilität ist schon in den Genen.
Denn, sag ich mal, in dieser Denke der Open-Source-Welt auch, ist Agilität ja schon lange zu Hause.
Das Problem ist, wie kriegen wir das nach SAP?
Und mit dieser einfachen Lösung, also man tut einfach sein System, sein SAP, sein altes SAP-System in die Cloud und entwickelt dann alles auf der Cloud-Plattform an Ergänzungen und Erweiterungen.
Das ist die ideale Welt.
Die Wahrheit wird anders aussehen.
Die Wahrheit wird aussehen.
Das heißt, man hat Systeme, die man vielleicht nicht sofort in die Cloud geben kann oder will.
Und wie kann man in diesem Umfeld auch DevOps nutzen?
Und hier kommen wir als Giltig auch ein Stück weit mit Tools dem Kunden entgegen, mit Methodiken entgegen, sodass sie auch ihre klassischen Landschaften, ja, da, wo es geht, beschleunigen können.
Und dieses Köpfe zusammenstecken, dieses Einbetten von Entwicklung und Basisabteilung ineinander in diese agilen Teams, die sich eben formieren.
Und das ist ganz wichtig.
Also wir wollen auch den klassischen, sag ich mal, SAP-Kunden helfen, heute schon schneller zu werden.
Ja, du hast es eben schon angesprochen.
Das Ganze muss ja Vorteile bieten für die Unternehmen.
Also Time-to-Market reduzieren, die schönen Buzzwords, die wir so entsprechend auch kennen.
Letzten Endes ist ja die Frage, wo haben Unternehmen, die…
SAP automatisieren, die Change-Management automatisieren, wo haben die wirklich betriebswirtschaftliche Vorteile, die man auch wirklich rechnen kann, die man beweisen kann?
Also ich denke, das geht relativ schnell, die Sachen zu beweisen, denn wir sagen ja heute, dass Ressourcen knapp sind, also vor allen Dingen Fachkräfte sind knapp.
Das heißt, eigentlich muss jedes Unternehmen, jeder Kunde muss sehr interessiert daran sein, eben seine, sag ich mal, wertvollen Fachkräfte in Projekte,
zu stecken, die tatsächlich zukunftsorientiert sind, die Value schaffen und nicht manuelle Routineaufgaben zu erledigen.
Und wenn wir sehen, dass man gewisse Aufgaben, gerade im Change-Management-Bereich, sehr einfach automatisieren kann,
dann bringt das wirtschaftlich in sehr kurzer Zeit einfach Kostenvorteile.
Es wird weniger manuell gemacht.
Viele Dinge werden zur Routine, weil man sie auch häufiger macht.
Das heißt, weniger fehleranfällig.
Man muss sich ja nicht so lange mit gewissen Dingen beschäftigen.
Das verliert alles dann seinen Schrecken, auch so Releases einzuspielen.
Und am Ende merkt man, dass man tatsächlich also nicht nur schneller wird, das heißt, mehr Value zu seinen Kunden bekommt,
mehr Qualität zu seinen Kunden bekommt, sondern auch betriebswirtschaftlich relativ schnell eine Rechnung aufstellen kann, die zu Kosteneinsparungen führt.
Okay.
Also ich habe für mich jetzt mal mitgenommen, Fachkräftemangel als Stichwort.
Also wertvolle Ressourcen kann ich viel sinnvoller nutzen, wenn ich natürlich die sinnlosen oder einfachen manuellen Tätigkeiten automatisiere.
Und daran schließe ich eben den anderen Punkt an.
Weniger Fehler, mehr Qualität, indem ich einfach routine Tätigkeiten automatisiere.
Gibt es noch ein paar andere Punkte, die man da so nennen könnte?
Die Punkte, die wir jetzt ja haben, die kann man ziemlich genau beziffern nach den Betriebskennzahlen des jeweiligen Unternehmens.
Diese Schnelligkeit, glaube ich, oder der schnellere Umsetzung von Noten.
Neue Anforderungen, das kann man jetzt nicht in Zahlen fassen, aber ich glaube mal, der Markt fordert das einfach.
Ich kann mir als Unternehmen heute nicht mehr leisten oder fast nicht mehr leisten, der Zweite zu sein.
Also wenn ich mir heute Beispiel, ich habe Kunden wirklich, die vertreiben auch sehr viel über ein Online-Business und die sind im Wettbewerb.
Und die sagen, wenn jetzt ein gewerblicher Kunde was bestellt,
also in einem Großhandel und der Shop ist für den nicht zur Verfügung, dann geht er einen Shop weiter zum Wettbewerb und bestellt sich das Bauteil da.
Und wenn sich da was verändert, die Anforderung schneller umzusetzen, es wird mehr ein Wettbewerbsvorteil beziehungsweise Nachteil,
wenn ich mich nicht darauf einlasse, auch diese Geschwindigkeit aufzunehmen.
Die englische Sprache, die erlaubt ja in kurzen Worten darzustellen, was wir im Deutschen oft mit bezeichnen.
Und sehr lange Sätzen beantworten müssen.
Also ich sage oft, wenn ich sage über DevOps, was ist das eigentlich, dann sage ich, das hilft einfach, innovate faster.
Das ist eines der Stichworte, also wirklich Innovation schneller zum Endbenutzer zu bringen.
Und das dann eben auch mit einem sicheren Betrieb.
Denn die Innovation allein hilft ja nicht, wenn sie nicht stabil läuft.
Natürlich, definitiv.
Genau.
Und hier sagt man ja auch, also wenn man in kleinen Portionen Innovationen,
also zum Kunden bringt, also dass man, also fail fast und fix fast.
Das heißt, wenn man kleine Veränderungen zum Kunden bringt und merkt, das hat nicht zu dem Effekt geführt,
dann kann man sich auch schnell wieder zurückfahren oder korrigieren.
Dieses Feedback orientierte.
Wenn man drei Monate lang entwickelt hat, bringt ein Produkt oder eine Funktionalität zum Kunden,
der sagt, das ist es nicht, was ich eigentlich wollte, dann hat man schon drei Monate Zeit und Geld in den Sand gesetzt
und braucht.
Und das dauert auch wieder sehr lange, um das zu fixen.
Ja.
Kann ich nicht rechnen.
Das ist auch an vieler Seite an Kunden bestätigt worden.
Die Fachbereiche oder die, sage ich mal, über die die Business-Anforderungen an die IT gehen,
die akzeptieren die langen Release- oder Change-Zyklen im SAP auch nicht mehr.
Die Anforderungen müssen viel schneller umgesetzt werden und in höherer Komplexität
und mit mehr neueren Technologien im Zusammenspiel.
Gerade die Komplexität und dieses, wie heißt das, Vaku?
Daniel, hilf mir, Vuku?
Vuku-Konzept?
Vuka.
Vuka, Vuka.
Genau, danke.
Das lässt sich, glaube ich, jetzt mit den bewährten oder mit den bisher vorherrschenden Abläufen nicht mehr bewältigen.
Jetzt haben wir eben die Vorteile angesprochen, die auf der Hand liegen.
Also du hast ja auch gesagt, Franz, ein paar Sachen kann man rechnen und ein paar Sachen ergeben sich einfach und liegen auf der Hand.
Die kann man jetzt vielleicht nicht mit einem…
Mit besonderen Kennzahlen ausrechnen, aber die liegen auf der Hand.
Gibt es denn auch Hürden?
Also wenn es so einfach wäre und so sinnvoll, dann könnten wir es ja gleich machen.
Wo sind wirklich Hürden, technisch gesehen, organisatorisch gesehen?
Eine große Hürde natürlich ist ein großes zentrales SAP-System,
was sehr viele Prozesse integriert und auch über mehrere Systemlandschaften hinweg Satellitensysteme mit einbindet.
Hier das natürlich in ein…
In einem schnellen Testprozess ohne großen Implementierungsaufwand von Automatisierungslösungen zu kriegen.
Das ist natürlich eine Riesenhürde.
Ja, auch erstmal die Komplexität zu strukturieren und auch inhaltlich zu erfassen, damit ich Schritte definieren kann, diese zu automatisieren,
ist natürlich ein großer Schritt und viel Aufwand dahinter erstmal.
Ja, okay.
Und deshalb empfehlen wir immer, wirklich klein anfangen.
Ja, okay. Und deshalb empfehlen wir immer, wirklich klein anfangen.
Und erfolge haben, weil gerade wenn man sich sofort an diese Integrationstests und Regressionstests im SAP ranmacht,
dann ist der, sag ich mal, der Bissen auch zu groß für den ersten Schritt, um die Erfahrungen zu sammeln.
Ja, also letztendlich die Hürde oder die größte Hürde ist, glaube ich, auch wirklich das Mindset.
Also eine Innovationskultur und eine Change-Kultur überhaupt erstmal zu etablieren.
Das heißt, es muss schon auch von oben her gewollt sein.
Es reicht definitiv nicht, den Mitarbeitern ein Buch in die Hand zu drücken, Scrum Revolution oder wie auch immer, nach dem Motto, und jetzt werdet agil.
Sondern das ist tatsächlich in vielen kleinen, also so agile Stellhebel umzulegen, um eine intrinsische, sag ich mal, Motivation in den Mitarbeitern hervorzurufen,
dass sie mit einer neuen Arbeitsweise, mit mehr Collaboration, mehr Sharing und natürlich auch einem weitestgehenden Automatisierung von monotonen Abläufen
letztendlich ihre Arbeit machen können.
Und das ist ein Zusammenspiel, ja, und auch eine Gratwanderung zwischen Führung, Lernbereitschaft von Mitarbeitern, sich gegenseitig Informationen zuspielen und sich gegenseitig schulen und Wissen abholen.
Und letztendlich die ganze Arbeitsweise muss sich verändern.
Und ich glaube schon, dass das eine große Hürde in Unternehmen darstellt.
Und wie der Franz gesagt hat, das kann man nicht.
Das kann man nicht erreichen, indem man mit dem Big Bang reingeht ins Unternehmen und sagt, so, wir werden jetzt agil von heute auf morgen.
Das muss sich langsam etablieren, weil es von oben gerollt ist und weil man erste Anfangserfolge sieht, das sich rumspricht und der Kunde und die Abteilung und die Menschen dann merken,
dass man so letztendlich ja wettbewerbsfähig bleibt, die Kundenzufriedenheit erhöht und die internen Abläufe letztendlich auch profitieren.
Also es ist wirklich ein Prozess, der hier eingeleitet werden muss.
Und deswegen habe ich am Anfang gesagt, Religion.
Also man muss auch dran glauben.
Wenn ich mir das so überlege, das passt natürlich ganz klar, dass ich erst mit schnellen, mit kleinen Schritten machen muss, schnelle Erfolge.
Denn würde ja nicht gut zusammenpassen, wenn ich sage, liebes Business, wir wollen schneller werden und jetzt gehen wir erst mal zwei Jahre in Klausur.
Also ich muss ja diese Schnelle gleich von Anfang an zeigen und von Anfang an zeigen, dass ich auch das Thema Schnelligkeit verstanden habe und auch schnell das Feedback bekommen will.
Genau.
Und so, ich sage mal, genau das ist so der Mindset im SAP.
Man macht sehr, also man ist sehr genau, man muss sehr genau sein.
Ja, einfach weil die Verantwortung, das, sage ich mal, das Erfolg des Unternehmens ja auch auf der Plattform, was die Geschäftsprozesse angeht, ein bisschen lastet.
Aber wenn ich quasi auf diese heranke, mich quasi mit dem, mit meinem alten Verhaltens, mit meinem alten Verhalten an das Thema annähere, komme ich damit auch nicht weiter.
Aber was man, was man zusätzlich.
Was man zusätzlich machen sollte, Fehler zulassen, das ist ganz wichtig und gerade in so einem geschäftskritischen Umfeld muss man das Top-Management und halt auch das mittlere Management mit reinholen und ihnen klar machen, dass die müssen das aushalten, wenn man, wenn man sagt, man geht so einen Weg, man will das Unternehmen beschleunigen, agiler werden, dass diese Fehlerkultur und Fehler zulassen akzeptiert wird.
Und dann heißt es, also im schlimmsten Fall ist halt mal ein Fehler in der SAP-Produktion.
Das kann ich natürlich nicht dauerhaft machen, aber die werden natürlich auch passieren.
Und das Schlimmste ist dann, wenn man dann auf dem Weg dahin beim ersten Fehler das Management dann sofort einknickt und dann halt wieder eine Rolle rückwärts macht.
Das kann auch mal.
Wenn man sich vielleicht mal die Mühe macht, zu überlegen, was ist denn in fünf oder in zehn Jahren, ja.
Wenn man uns diese Vorstellung, die SAP ja selbst hat, mal tatsächlich zu eigen machen.
Alle unsere Systeme, die Kernsysteme sind bei SAP.
Wir nutzen nur noch Cloud-ERP, weil es eben diese notwendige Flexibilität, Pay-Per-Use und Anpassungsfähigkeit bietet.
Und auf der anderen Seite nutzen wir über die SAP-Cloud-Plattform eine Entwicklungsumgebung, mit denen wir ganz schnell neue Apps, neue Funktionen, neue Applikationen zur Verfügung machen können.
Spätestens dann ist ja das Ganze, dieser ganze agile Gedanke, dieser ganze DevOps-Gedanke im Prinzip fest vertratet in der IT, die wir nutzen.
Das heißt, da spätestens müssen alle quasi mit diesen Methoden und mit dieser Denkweise und Kultur eigentlich vertraut sein.
Also warum machen wir heute nicht den ersten Schritt und fangen mit den bestehenden Systemen an, diese Kultur zu etablieren, diese Automatisierungsmöglichkeiten zu nutzen und letztendlich die Leute, die Menschen vorzubereiten auf das, was in den nächsten fünf bis zehn Jahren kommen wird.
Ja, und da sieht man dann, dann ist ja Technologie oder technische Veränderungen sind dann der Treiber auch für organisatorische Veränderungen.
Ich habe einen Kunden, der selber auch gerade für sich, der auch in dem Betriebsumfeld ist, der in einem Konzernumfeld das Thema Microsoft eben betreut und der ist jetzt aufgefordert worden, MS-365 in der Cloud für den Konzern nutzbar zu machen, mit einem sehr ambitionierten Zeitplan.
Und der hat gesagt, das ganze Thema kriegen wir nur gestemmt, also nicht nur das Ausrollen, sondern auch den Betrieb nachher, wenn wir anders vorgehen.
Und der setzt eben auch entsprechende Teams auf. Das heißt, da ist eben genau durch den Lieferanten, durch die Technik, in diesem Fall der Microsoft, angetriggert worden, auch organisatorisch Dinge zu verändern an der Stelle.
Und das finde ich schon spannend. Ich bin ja als Betriebswirt eher derjenige, der sagt, naja, die Technik sollte das nicht treiben, aber wenn es in diesen Weg geht, habe ich damit auch kein Problem.
Ja, es ist auf jeden Fall ein Zusammenspiel. Also die Technik, also die technischen Möglichkeiten, die sind schon ein Problem.
Ein Motor, ein Antrieb. Und wie ich sagte, auch die Anforderungen. Das heißt, das, was der Kunde will. Wenn der Kunde immer schneller, beziehungsweise der Wettbewerb immer schneller quasi neue Ideen, neue Funktionen zur Verfügung stellt, dann kann ich dem nicht hinten dranbleiben.
Also wir müssen das vor diesem Hintergrund sehen. Also wir kennen das auch, wir nennen das immer diese Amazon-like User Experience. Das heißt, wenn ich heute gewohnt bin, eine gleichbleibende Qualität, jedes Mal, wenn ich einen Bestellprozess mache,
dann kann ich das tracken, dann kriege ich das am nächsten Tag. Das heißt, ich bin dran gewöhnt, dass eine gewisse Servicequalität und auch Schnelligkeit und ja, Flexibilität an der Stelle geliefert wird.
Und wenn ich dann in die Unternehmen reingucke, dann ist man weit entfernt von dieser User Experience. Da ist die Qualität eben nicht gleichbleibend, weil das kommt auf die Laune des Mitarbeiters an, dem man gerade eine Mail geschickt hat, ob er jetzt das erledigen könne.
Ja, und wenn man das natürlich in Services und auch in der Technik, dann ist das eine gewisse Qualität.
Und wenn man das auch in Software, also Automatisierung und einer anderen Art der Zusammenarbeit, ich sage ja, also mit Slack oder Teams einfach sich gegenseitig einbetten in die Aufgaben und informieren, dann ist das viel einfacher. Dann wird das, diese User Experience eben auch innerhalb der Unternehmen plötzlich zum Standard.
Ja, vielleicht dann noch ein Thema. Wir haben jetzt ja ziemlich viel beleuchtet. Wir haben auf das Thema Mindset abgehoben. Wir haben Automatisierung angesprochen. Wir haben Vorteile geklärt, Rahmenbedingungen.
Wenn ich jetzt als Unternehmen im SAP-Umfeld jetzt dann sagen würde, okay, jetzt möchte ich DevOps starten. Was sind da so eure Tipps oder was sind auch eure Erfahrungen? Wo haben Unternehmen Vorteile erzielt, die man an der Stelle auch weitergeben könnte?
Ja, wieder die kleinen Schritte. Man sucht sich einzelne, also in dem, ich sage mal, im Change Management Prozess Punkte aus, die man stellen, die man mit einfachen Mitteln automatisieren kann.
Man schaut sich auch nochmal die Bereich des Approvals an. Was der Daniele meinte, haben wir, ich sage mal, Change-Typen, die jetzt nicht von zwei oder drei Leuten approved werden müssen, sondern, ich sage mal, die, wo wir so eine Routine und Qualität schon haben, dass wir nur noch in, ich sage mal, bei bestimmten Exceptions ein Approval brauchen.
Aber wenn alles in einem gewissen Rahmen läuft, kann ich das durchautomatisieren, also bei unkritischen Projekten kleineren Anpassungen oder Anpassungen, die regelmäßig gemacht werden.
Ja, die haben ja auch, sind ja auch weniger fehleranfällig und ich dann sage, ich mache nur noch, sage ich mal, manuelle Checks oder tiefere Tests bei Objekten, wo ich weiß, oh, da haben wir jetzt seit zwölf Monaten keine Änderungen mehr vorgenommen, vielleicht die Dokumentation nicht vollständig, dass ich mich hier auf meine bewährten Abläufe verlasse und aber alles, was ich sehe, was regelmäßig wiederkehrend ist, anfange zu automatisieren und das geht auch im SAP.
Dafür gibt es die Tools.
Da ist die Erfahrung da, das lässt sich auch kundenspezifisch entsprechend anpassen.
Also, ich will das vielleicht nochmal so zusammenfassen.
Das hatten wir im Laufe des Gesprächs schon mal, da hast du dir gesagt, geht das überhaupt?
Ich habe letztlich einen Spruch gesehen auf einer Tür, da stand dann, alle sagen, das geht nicht.
Dann kam einer, der wusste das nicht und hat es einfach getan.
Und das kann ich den Unternehmen einfach sagen.
Das kann ich dem Unternehmen einfach nur nahelegen, es einfach auszuprobieren.
Diese Möglichkeiten, die heute schon mit Software, aber auch vielleicht mit einem agilen Coach in der Entwicklungsabteilung sowieso schon sehr stark sich bewährt haben, auch eben zu erweitern auf die Betriebsabteilungen, auf das gesamte Unternehmen und letztendlich in einem Prozess diese Kultur, diese Innovationskultur, diese Freiräume zu schaffen.
Um mehr Output am Ende, also Value für den Kunden auch zu generieren.
Es funktioniert, es funktioniert.
Man muss es einfach nur, man muss damit einfach nur starten.
Und dann noch genügend Rückgrat und Zeit mitbringen, weil es funktioniert sicherlich erstmal nur in kleinen Schritten.
Das heißt, auch die kleinen Schritte brauchen dann die Zeit und die Erfolge insgesamt brauchen eben auch ihre Zeit.
Man hat auch erstmal Rückschritte.
Ja, natürlich braucht man eine gewisse Beharrlichkeit, Geduld.
Wenn man Dinge anders macht, in der Retrospektive wird man dann feststellen können, also welche Fortschritte man am Ende gemacht hat oder dass man vielleicht auch nur noch überlebt als Unternehmen, weil man gelernt hat, schneller und agiler, also anpassungsfähiger zu werden.
Das ist leider, wir kennen ja auch die Namen der Unternehmen, die von ihrer Haltung her, sage ich mal, diese Geschwindigkeit, die, also auch die Innovationszyklen, die wir jetzt,
die wir jetzt in der IT kennen, nicht überlebt haben, also weil sie einfach zu lange an alten Dingen festgehalten haben.
Und das kann für die Zukunft schon der entscheidende Wettbewerbsvorteil sein.
Wir kommen langsam zum Ende.
Das ist so die Zeit, die wir auch immer so, nicht immer so vorgeplant haben für die Dauer von so einem Podcast.
Gibt es noch irgendetwas, was ihr in den letzten 45 Minuten nicht angesprochen habt, was noch wichtig ist, was euch noch auf dem Herzen liegt?
Ja, ich kann eben nur empfehlen, auch im SAP-Umfeld, ja, wagt den Schritt.
Es ist möglich, es ist kein, auch wenn es teilweise ein steiniger Weg ist, aber ja, nach vorne schauen, nicht zu sehr drauf verlassen und sagen,
wir haben das seit 20 Jahren so gemacht und deshalb können wir es nicht ändern.
Es funktioniert definitiv auch im SAP-Umfeld.
Es erweitert für die Leute, die aus der SAP-Welt kommen, wie für mich war es ein ganz anderer, ich sage jetzt nicht keine Offenbarung, aber mal einen ganz anderen Blick, ja.
Man hat doch sehr lange, gerade in den SAP-Organisationen, so ein bisschen im eigenen Saft geschmort, möchte ich sagen, ja.
Und die Welt hat sich da draußen rum gerade in was, was Schnelligkeit und Methoden angeht, doch deutlich verändert.
Ja.
Und da kann die SAP-Welt einiges lernen.
Und ich glaube,
es tut Ihnen gut, sich das zunutze zu machen, welche Möglichkeiten es sich, sage ich mal, so spezielle, so sage ich mal, in den letzten 15 Jahren außerhalb des SAP-Umfeldes sich ergeben haben, ja.
Ja, okay.
Also für mich ist immer überraschend oder erfreulich, wenn ich sehe, wie sich Microsoft verändert hat.
Also das, was man jetzt heute von Microsoft sieht oder merkt, das ist ja nicht mehr das, was man vor fünf oder vor zehn Jahren noch gewohnt war.
Und ich habe den schönen Artikel gelesen, Microsoft, das neue Apple.
Das ist natürlich vielleicht für Microsoft nicht das höchste Lob, aber aus meiner Sicht ist natürlich schon ein Zeichen, wenn wirklich Fachjournalisten mit einem klaren Blick auf die Inhalte auch wirklich das entsprechend darstellen.
Also insofern, vielleicht ist SAP ja in ein, zwei Jahren das neue Microsoft und das neue Apple.
Ja, das werden wir dann sehen.
Also ich denke schon, dass SAP hat auf jeden Fall das verstanden, dass das notwendig ist, dass sie Mittel und Tools und Software, also Lösungen,
dem Kunden an die Hand geben müssen, um eben in dieser neuen Welt auch bestehen können, in dieser volatilen Welt, die geprägt ist von Unsicherheit, von der Notwendigkeit, sich schnell adaptieren zu müssen.
Das Problem von SAP ist, dass sie halt doch sehr lange schon im Markt ist und diese etablierten Systemwelten, Denkweisen, Silos, die wir ja alle angesprochen haben im Podcast, nicht einfach so von heute auf morgen weg zu radieren sind.
Und in jedem Change-Prozess ist ja das Problem, dass jeder nur mitmacht, wenn er sich selbst sicher darin fühlt, also dass er sich nicht selber wegrationalisiert sozusagen.
Und das ist schon ein Dilemma, welches eben auch nur über die Führung oder eben über den Druck, der auch vom Markt herkommt, zu steuern ist.
Und wie gesagt, Microsoft hat es geschafft. Sie haben sich komplett verändert. Viele Kunden, egal in welchen Branchen, in welchen Tätigkeiten sie unterwegs sind,
müssen sich komplett verändern.
Ja, dem kann man sich nicht entziehen. Desto eher man das akzeptiert und nur noch die Frage stellt, wie verändere ich mich und nicht, nein, das brauche ich jetzt erstmal nicht, umso einfacher wird dieser ganze Wandel.
Ja, okay. Also, dann bedanke ich mich für eure Unterstützung an der Stelle, auch für das schnelle Einspringen, Daniele, für den erkannten Kollegen an der Stelle. Mir hat das viel Spaß gemacht. Es sind 50 Minuten jetzt vorbei.
Es kommt mir gar nicht so vor. Also, insofern vielen Dank für die, ich sage mal, spannende Unterhaltung, für die interessante Unterhaltung.
Ja, mir hat es auch viel Spaß gemacht. Vielen Dank, Dirk.
Ich schließe mich an. Danke, Dirk.
Danke.

Folge 13: Continuous Delivery

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Continuous Delivery spielt bei DevOps ein zentrale Rolle. Der Experte Eberhard Wolff erläutert den Begriff sowie die Verbindung zu Microservices, die Vorteile und technische Fragestellungen.

In dieser Folge des Podcasts „DevOps auf die Ohren und ins Hirn“ diskutiert Dierk Söllner mit dem Gast Eberhard Wolf, einem Experten für Microservices und Continuous Delivery, die Konzepte und Praktiken rund um Continuous Delivery und deren Unterscheidung von DevOps. Wolf erklärt die organisatorischen und technischen Aspekte von Continuous Delivery, Continuous Integration und Continuous Deployment, deren Bezug zum Agile Manifest und wie diese Konzepte die Softwareentwicklung und -auslieferung beeinflussen. Der Podcast geht auch auf die Herausforderungen und Potenziale von Microservices in Verbindung mit Continuous Delivery ein und diskutiert wichtige Studien und Literatur in diesem Bereich.

Inhalt

  • DevOps and Continuous Delivery: Unterschiede und Zusammenhänge
  • Continuous Delivery: Konzepte, Praktiken und deren Bedeutung
  • Continuous Integration vs. Continuous Deployment: Technische Details und Abgrenzungen
  • Microservices: Rolle und Bedeutung für Continuous Delivery
  • Herausforderungen und Potenziale: Bezug auf Microservices und größere Software-Projekte
  • Wichtige Studien und Literatur: Überblick und Empfehlungen
  • Testing in Continuous Delivery: Bedeutung von automatisierten und manuellen Tests

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Dirk Söll.
Hallo und herzlich willkommen zu einer neuen Podcast-Folge DevOps auf die Ohren und ins Hirn.
Wir haben heute das Thema Continuous Delivery und haben zu Gast den Eberhard Wolf.
Eberhard Wolf hatten wir schon im letzten Jahr zu Gast zum Thema Microservices und Eberhard Wolf ist Experte für das Thema Microservices, für das Thema Continuous Delivery.
Insofern freue ich mich, dass ich ihn hier zu Gast habe und wie immer beginnen wir mit der Vorstellung.
Eberhard, ich würde sagen, stell dich einfach mal ganz kurz vor und dann kommt ja bei uns im Podcast immer die Frage nach der Definition von DevOps.
Das heißt, wie verstehst du, wie würdest du DevOps beschreiben?
Eberhard, bitte sehr.
Ja, danke für die Einladung.
Mein Name ist Eberhard Wolf.
Ich arbeite für die Firma InnoQ.
InnoQ hat 120 Mitarbeiter über Deutschland und die Schweiz verteilt.
Wir machen im Wesentlichen Software-Projekte.
Ich bin ein bisschen eine Ausnahme.
Das heißt, ich laufe rum und mache vor allem Consulting, Training, bin auch auf ein paar Konferenzen und habe Bücher geschrieben.
Unter anderem ein Buch über Continuous Delivery.
Das ist mittlerweile in der zweiten Auflage.
Und mittlerweile zwei Bücher über Microservices.
Das Microservices-Buch, das ist mehr so Architektur.
Und zum anderen das Microservices-Praxis-Buch, das ist mehr so über Technologien.
Genau.
Die Definition von DevOps.
Also nach meinem Dafürhalten ist das erstmal etwas Organisatorisches.
Das heißt, es geht nicht unbedingt darum, Technologien zu machen oder so etwas wie Continuous Delivery ist für mich da auch ein getrenntes Thema.
Und was der Name hat schon sagt, ist, dass eben Dev.
Also Entwicklung und Ops, Operations, Betrieb zusammenwächst zu einem.
Und das bedeutet für mich in erster Linie eine stärkere Kollaboration.
Also das bedeutet nicht unbedingt, dass die jetzt im Organisationsdiagramm eine Einheit sind.
Aber die müssen halt eben zusammenarbeiten und halt gemeinsam versuchen, Ziele zu erreichen.
Und damit steht eben im Mittelpunkt auch der Abbau von Silos.
Was eben insbesondere bedeutet, dass ein DevOps-Ingenieur, den es ja neuerdings irgendwie gibt,
eigentlich ein Widerspruch in sich ist.
Also die Idee ist halt, dass man Dev-Ingenieurs hat und Ops-Ingenieurs, die enger zusammenarbeiten.
Das ist eigentlich das Ziel bei der ganzen Veranstaltung.
Sehr schön.
Ja, ich glaube, ich erinnere mich, das war beim Microservices auch, wie ich finde, eine sehr, sehr schöne Darstellung, als du das ähnlich dargestellt hast.
Habe ich das eben richtig verstanden?
Du hast gesagt, dass DevOps und Continuous Delivery im Prinzip zwei unterschiedliche Paar Schuhe sind.
Also DevOps siehst du eher kulturell und Continuous Delivery.
Dann eher technisch.
Das würde ich so nicht unbedingt sagen.
Also für mich, es sind einfach unterschiedliche Dinge.
So Continuous Delivery bedeutet, dass ich kontinuierlich Software ausliefere.
Das sagt ja der Name schon.
Das hat einen sehr starken Bezug zu dem Agile Manifest.
Also in dem Prinzipien des Agile Manifest steht eben auch drin, dass das Ziel der ganzen Veranstaltung ist,
kontinuierlich wertvolle Software auszuliefern.
Da steht also wirklich Continuous Delivery im englischen Original.
Und das impliziert ja jetzt nicht erstmal irgendeine Art von Organisation.
Das heißt, da steht irgendwie nicht, Betrieb und Entwicklung arbeiten zusammen.
Natürlich ergeben sich da Berührungspunkte.
Also es ist eben so, dass sinnvollerweise Betrieb und Entwicklung zusammenarbeiten müssen,
um kontinuierlich Software auszuliefern.
Das geht eigentlich nicht anders.
Aber das sind eben zwei unterschiedliche Sachen.
Es ist einmal die kontinuierliche Auslieferung von Software.
Und zum anderen ein Organisationsmodell.
Und ehrlich gesagt finde ich das immer ein bisschen schade, wenn die Sachen halt vermischt werden,
weil eben die sprachliche Präzision eigentlich schon, glaube ich, ein wichtiges Thema bei uns in der Branche sein sollte.
Das heißt, Continuous Delivery, sagst du, kommt aus dem Agilen oder bezieht sich auf die agilen Werte, auf das Agile Manifest.
Ich habe noch so zwei andere Begriffe, die man da vielleicht noch ein bisschen reinbringen könnte,
gerade weil du ja sagst, sprachliche Feinheit, Genauigkeit.
Continuous Integration und Continuous Deployment.
Wie kann man das mit dem Continuous Delivery zusammenbringen?
Genau, also Continuous Integration bedeutet, dass immer alle Änderungen in der Software möglichst kontinuierlich integriert werden.
Das heißt, wenn ich einen Commit mache, sollte das mit allen anderen Commits zusammen integriert werden, getestet werden und dann anschließend eben ein Software Stand entstehen.
Da gibt es eine andere Technik, die sich davon auswirkt.
Davon deutlich abhebt.
Das sind Feature Branches.
Feature Branches versuchen gerade das Gegenteil.
Feature Branches versuchen eben die Integration bestimmter Features aufzuheben bis zu einem bestimmten Zeitpunkt, an dem ich das dann eben alles integriere.
Das bedeutet nicht unbedingt, dass jetzt Feature Branches nicht funktionieren oder das Continuous Integration nicht funktioniert.
Das sind eben zwei alternative Verfahren, mit denen ich Software entwickeln kann.
Und beide funktionieren halt.
In bestimmten Projekten, sodass man da eben das eine oder das andere machen kann an der Stelle.
Continuous Integration ist historisch älter, also ist eine Reaktion darauf, dass eben in vielen Projekten Software entwickelt worden ist,
dann nach einiger Zeit die Änderungen aus den verschiedenen Quellen integriert worden sind und man dabei halt festgestellt hat,
naja, das dauert erstmal, bis man das zum Kompatieren bringt, das dauert erstmal, bis man die Tests alle zusammen zum Laufen bringt und so weiter und so weiter.
Und da war die Idee eben, das früher zu machen und eben eigentlich ständig.
Das ist genau die Idee von Continuous Integration.
Die Beziehung zu Continuous Delivery ist, dass man dann diese Continuous Integration Pipeline, die also die Softwarestände nimmt, auscheckt und durchkompatiert und testet.
Und zwar eben alle Änderungen, nicht etwa nur die von einem Branch.
Dass man das dann letztendlich logisch verlängert bis hin in Produktion.
Und dort.
Und dort hat man dann eben eine Continuous Delivery Pipeline, die die Änderungen nimmt und eben bis in Produktion durchschleust.
Das ist für mich der Unterschied.
Also Continuous Delivery ist eben sozusagen die Verlängerung von Continuous Integration.
Und bei Continuous Delivery würde ich auch argumentieren, dass ab einer bestimmten Geschwindigkeit man eigentlich nicht mehr wirklich mit Feature Branches arbeiten kann,
weil die Integrationsprozesse dafür zu lange dauern.
Also wenn ich halt versuche, öfter pro Tag zu deployen.
Dann ist die Zeit, die halt dabei draufgeht, ein Feature Branch zu integrieren, möglicherweise so lang, dass ich das nicht mehr ernsthaft tun kann.
Also ab einer bestimmten Geschwindigkeit muss ich wahrscheinlich eben echtes Continuous Integration machen, um Continuous Delivery zu machen.
Aber ich würde grundsätzlich nicht Probleme lösen, die ich nicht habe.
Von daher muss man eben schauen, wie das in der jeweiligen Umgebung funktioniert.
Der andere Begriff, den du eingebracht hast, ist Continuous Deployment.
Das ist tatsächlich nach dem, wie es definiert ist, etwas anders.
Das ist tatsächlich nach dem, wie es definiert ist, etwas anders.
Der Unterschied ist, dass ich bei Continuous Deployment tatsächlich jede Änderung in Produktion bringe.
Bei Continuous Delivery ist das nicht unbedingt so.
Da ist es eben so, dass ich kontinuierlich irgendwie neue Softwarestände in Produktion bringe.
Es ist nicht gesagt, dass ich jetzt jeden in Produktion bringen muss.
Ich würde halt denken, dass es so sein sollte, dass man im Prinzip jeden in Produktion bringen könnte.
Aber man kann sich natürlich dagegen entscheiden.
Bei Continuous Deployment bringt man tatsächlich jede Änderung in Produktion.
Das hat noch, glaube ich, ein paar weitere Konsequenzen.
Beispielsweise bedeutet es eben, dass die Software-Entwickler nochmal ganz anders mit ihren Änderungen umgehen müssen,
weil sie ja wissen, dass diese Änderung in Produktion geht.
Wenn also die Continuous Delivery Pipeline durchläuft, geht die Software eben in Produktion.
Und da muss man dann eben noch verantwortungsvoller mit der ganzen Geschichte umgehen,
als das der Fall wäre in einem anderen Continuous Delivery Szenario.
Sehr schön.
Ja, das heißt, wenn ich das so aus meiner Sicht interpretiere, ich bin ja kein Techniker,
ich bin ja eher der Betriebswirt, dann erfordert Continuous Deployment einen höheren Reifegrad
bei den Entwicklern und wahrscheinlich auch in der gesamten Organisation, richtig?
Ja, also du stellst jetzt in gewisser Weise einen Kausalitätszusammenhang her und sagst,
naja, wenn ich nicht reif bin, kann ich nicht Continuous Deployment machen.
Das hat natürlich was für sich.
Man kann es auch umgekehrt sagen.
Wenn ich Continuous Deployment mache, werde ich einen höheren Reifegrad erreichen,
weil ich eben dort ganz anders davorstehe und ganz anders inzentiviert bin.
Also das ist ja ein bisschen die Idee, die hinter Continuous Integration, Continuous Delivery und auch Continuous Deployment steht.
Da gibt es diesen englischen Satz von
Also wenn es halt weh tut, mache es häufiger und sorge dafür, dass die Probleme früher auffallen.
Und der Hintergrund ist dort, dass man nicht jetzt in einem Meer von Schmerzen enden soll,
sondern dass man dadurch, dass die Sachen früher gemacht werden und früher auffallen,
man früher Fehler eliminieren kann und halt zu einem besseren Reifegrad des Prozesses kommt.
Und an der Stelle, wo ich sage, dass jede Änderung eben in Produktion geht,
werde ich einen Prozess erzeugen müssen, der halt einen anderen Reifegrad hat.
Und dadurch kann das eben beschleunigt werden.
Natürlich ist es so, wenn man jetzt in der Produktion geht,
wenn man jetzt sagt, okay, wir haben überhaupt keine vernünftigen Tests,
wir machen Continuous Deployment, das ist vielleicht super optimal,
aber es wird eben dadurch eine starke Inzentivierung entstehen,
eben tatsächlich kontinuierlich zu deployen und auch automatisierte Tests zu haben,
die einen erlauben, das überhaupt zu tun.
Und dadurch wird daraus, glaube ich, ein Schuh.
Du hast es eben schon angesprochen, so Sinn und Unsinn, Vorteile von Continuous Delivery.
Also warum sollte man denn deiner Meinung nach Continuous Delivery machen,
und wo gibt es Schwierigkeiten, wo gibt es Probleme, die man dann beachten sollte?
Ja, also die Frage nach der Motivation von Continuous Delivery, finde ich, ist eine total spannende.
Eine Antwort, die halt auf der Hand liegt, ist, ich mache Continuous Delivery,
weil ich schneller Software in Produktion bringen will.
Und dadurch kann ich ein besseres Time-to-Market erreichen.
Und dadurch wird sozusagen an der Stelle alles gut.
Die Argumentation hat auch was für sich.
Und sie hat ein paar, nach meinem Empfinden, Schwierigkeiten,
weil wenn ich jetzt mehrmals pro Tag deploye,
ich weiß nicht, ob man halt tatsächlich mehrmals pro Tag neue Features ausliefern möchte.
Und die andere Geschichte ist, also ich weiß nicht, wie es anderen geht,
aber bei mir ist es so, dass ich fast jeden Morgen auf meinem Mobiltelefon neue Software installiere,
weil irgendwelche Apps geupdatet worden sind.
Und es ist eigentlich selten so, dass mir neue Features tatsächlich auffallen.
Und der dritte Punkt ist dann Time-to-Market.
Das ist eben so eine Geschichte, die Management, Product Owner und solche Leute halt interessiert
oder interessieren sollte.
In der Praxis tut sie das bedauerlicherweise oft nicht, weil zum Beispiel solche Sachen anstehen,
dass man sagt, naja, die Kunden wollen gar nicht so oft neue Software deployen
oder wir müssen sie halt schulen, was in gewisser Weise bizarr ist,
weil eigentlich lebt die Software durch die Features und dadurch sollte man einen Vorteil bekommen.
So.
Ja, so stellt sich die Frage, ob man da andere Vorteile noch außerdem irgendwie realisieren kann.
Und ich muss gestehen, ich habe eigentlich mit Continuous Delivery angefangen zu beschäftigen
und in der Folge auch mit Microservices, weil ich der Meinung war, dass diese Mechanismen die Mechanismen sind,
die uns versprechen, dass wir noch produktiver und noch besser werden bei der Softwareentwicklung ganz allgemein.
Und mittlerweile ist es so, dass man das auch tatsächlich nachweisen kann,
oder sehr gute Indizien dafür hat.
Es gibt diese State-of-DevOps-Studie und die behauptet jetzt,
naja, wenn ich kontinuierlich deploye, und zwar mehrmals pro Tag,
im Gegensatz zu einmal alle paar Wochen oder einmal pro Monat,
was ja auch schon relativ aggressiv ist,
wenn ich also mehrmals pro Tag deploye, dann kann ich deutliche Vorteile erreichen,
nicht nur in der Lead-Time, also bis zur Änderung,
produktiv ist, sondern auch in der Stabilität und der Zuverlässigkeit der Deployments,
in der Zeit, die ich benötige, bis ein System wieder funktioniert und ich kann sogar,
das haben dort die Statistiken ergeben, mehr Zeit aufwenden, um neue Features zu implementieren.
So, und das, also diese Studie basiert halt auf einer Umfrage, diese Umfrage hat,
ich weiß nicht, ich glaube, also hat ein paar tausend Teilnehmer gehabt,
so dass es da eine relativ umfängliche statistische Grundlage gibt,
das hat die Nicole Fersgreen im Wesentlichen gemacht, die hat einen Doktor,
hat das also wissenschaftlich begleitet, und die anderen beiden, die daran beteiligt waren,
waren Jess Humble und Jean Kim, die ja auch im DevOps-Bereich ganz bekannt sind,
Jess Humble hat eben das Continuous Delivery Buch geschrieben, das ursprüngliche, mitgeschrieben,
und dadurch können wir jetzt mittlerweile eigentlich sagen, naja, wir haben dort generell,
große Produktivitätsvorteile, wenn wir Software kontinuierlich ausliefern,
und zwar eben tatsächlich mehrmals pro Tag, und das finde ich ist halt ein relativ starkes Argument an der Stelle,
in diesen Bereich tatsächlich zu investieren, und auf der anderen Seite muss man halt sagen,
wenn man jemandem halt mal die Frage stellt, naja, was ist denn nun weniger risikobehaftet,
was wird weniger häufig schiefgehen, Quartalsrelease oder mehrere Releases pro Tag,
kommen diese Antworten sowieso, also intuitiv ist das offensichtlich klar,
dass man mit mehreren Releases pro Tag weniger Risiko fährt und insgesamt besser aufgestellt ist,
aber mittlerweile haben wir eben, wie gesagt, auch einen statistischen Datensatz, der das eben belegt,
und das ist für mich ein ziemlich starkes Indiz dafür, dass man das generell tun möchte,
also dass man halt an der Stelle einen relativ guten Hebel hat, um insgesamt produktiv zu sein,
produktiver, besser und sicherer zu werden, ganz abgesehen davon, dass man eben abends nach Hause gehen kann
und sagen kann, okay, ich habe halt ein paar mal Software deployed, und das ist, glaube ich, auch eine deutlich bessere,
also ist, glaube ich, eine deutlich bessere Herangehensweise, als wenn man sagt,
ja, nächstes Wochenende geht es wieder darum, Software in Produktion zu bringen,
ich kann das ganze Wochenende irgendwie abschreiben und habe irgendwie mega Stress,
also ich glaube, dass das eben auch an der Stelle einfach vorteilhaft ist.
Ja, Pampi hat ja gefragt, wo gibt es Probleme, wo gibt es mögliche Nachteile,
oder Herausforderungen gibt es nicht auch in dem Bereich, den ich mir so vorstellen kann,
SAP oder Oracle, also mit großen, althergebrachten, monolithischen Systemen,
geht das dort auch, das Continuous Delivery umzusetzen?
Das ist eine sehr, sehr gute Frage. Ich muss gestehen, du fragst ja konkret nach SAP,
im SAP-Umfeld bin ich mir unsicher. Es scheint so zu sein, dass es dort Möglichkeiten gibt,
zumindest habe ich das eben in einigen Projekten aus der Ferne gesehen,
tatsächlich auch relativ schnell und kontinuierlich Software in Produktion zu bringen,
aber wie gesagt, ich bin da halt kein Experte.
Ansonsten ist es so, dass du da eigentlich, glaube ich, nach meinem Empfinden,
wichtigen Punkt ansprichst, auch eine Geschichte, die ja durchaus im Kundenszenario passiert,
also ich habe dort irgendwie diese Software, diese Software wird im Moment so was wie sechs Wochen getestet,
sie wird irgendwie an einem Wochenende deployed und das ist ja etwas, was so ungewöhnlich gar nicht ist.
So, wenn man jetzt sagt, was eben in solchen Szenarien durchaus vorkommt,
man möchte mehrmals pro Tag deployen, dann ist die Frage, wie kommt man da hin?
So, und dann kann man halt irgendwie ausrechnen, ja, ich brauche halt irgendwie ein, zwei Größenordnungen,
also Faktor 100 oder sowas muss ich schneller werden bei Tests oder auch eben beim Deployment.
Da kann man sich überlegen, also am Wochenende sind 48 Stunden,
wenn ich mehrmals pro Tag deployen will, wie viel muss das Deployment schneller werden?
Und noch deutlich schlimmer, sechs Wochen Tests sind eben 30 Arbeitstage,
wenn ich mehrmals pro Tag deployen will, komme ich da tatsächlich eben auf so einen Faktor wie 100 oder so,
wenn ich das eben auf einen Dritteltag runterbekommen will.
So, und an der Stelle ist nach meinem Empfinden die Stellschraube, um die es geht, das System klein zu hacken
und zu sagen, wir haben kleine, unabhängig deploybare Einheiten und das sind eben genau,
das sind eben Microservices, weswegen es eben dort eine Architektur,
also weswegen ich mich eben auch mit der Architektur beschäftigt habe,
weil das eben etwas ist, was man eigentlich machen muss, ab einer bestimmten Größenordnung,
um Continuous Delivery zu erreichen.
Und umgekehrt, also Microservices sind halt ein Hype, sodass man eben durchaus fragen kann,
muss ich das eigentlich tun?
Mir fehlt in so einem Szenario, wie ich es gerade beschrieben habe, sechs Wochen Tests, ein Wochenende Deployment,
die Idee, wie ich sowas, wie ich mehrmals pro Tag deployen kann, ohne die Architektur zu ändern.
Also jenseits des Hypes sehe ich nicht, wie ich das hinbekommen soll, ohne Microservices einzusetzen.
Und der dritte Aspekt ist vielleicht, das impliziert eben auch, dass Microservices unabhängig deploybar sein müssen.
Also ich gewinne ja nichts, wenn ich sage, ja, ich habe da halt einzelne Dinger, die in Docker-Containern laufen
und dann habe ich eine große Continuous Delivery Pipeline, die eben alle diese Sachen zusammen deployt.
Dann habe ich mir eben an der Stelle den Vorteil genau verschenkt.
Und das kann relativ schnell der Fall sein.
Also wenn ich jetzt zum Beispiel sage, ja, ich möchte die ganzen Sachen Ende zu Ende testen,
dann komme ich eben sehr schnell darauf, dass ich diese sechs Wochen, die ich halt vielleicht bei einem Monolithen habe,
gar nicht so sehr beschneiden kann.
Und dann habe ich eben das nächste Problem.
Und aus dem Grund ist eben genau dieses getrennte Deployment und insbesondere eben auch die getrennte Testbarkeit,
die sich daraus ergibt, eine wichtige Eigenschaft von Microservices.
Und Microservices sind eben eine wichtige Eigenschaft,
eben eine wichtige Maßnahme, um vernünftig oft zu deployen.
Und eben diese Bereiche, wo die DevOps-Studie sagt, wo man eigentlich hin möchte,
also mehrmals pro Tag, sind nach meinem Empfinden nicht erreichbar,
wenn man nicht kleine Deployment-Einheiten hat, also eben Microservices oder sowas.
Ja, okay, das heißt eigentlich Microservices als wichtige oder fast zwingende Voraussetzung
oder notwendige Voraussetzung für Continuous Delivery.
Ab einer bestimmten Geschwindigkeit, die man aber eigentlich erreichen will, genau.
Sehr schön. Ja, du hast das Thema eben schon angesprochen.
Microservices und Continuous Delivery sind ja auch die Themen deiner beiden Bücher
und an sich auch deine Arbeitsthemen.
Wo würdest du diese noch Zusammenhänge sehen zwischen diesen beiden Begriffen
oder zwischen diesen beiden Ansätzen, außer dem, was du eben schon ausgeführt hast?
Ja, also was ich jetzt schon gesagt habe, ist, wenn ich Continuous Delivery umsetzen will,
muss ich eigentlich Microservices machen.
Das gilt auch ein bisschen umgekehrt.
Also es macht wenig Sinn, dass ich Microservices habe
und keine automatisierten Continuous Delivery Pipelines,
weil ich bei der großen Menge an Systemen, die ich mit Microservices habe,
ohne Automatisierung die Sachen nicht mehr vernünftig in Produktion bekommen kann.
Also das bedingt sich, glaube ich, gegenseitig.
Da gibt es dann halt auch irgendwie die Idee, dass man sagt,
ja, wenn du halt eine bestimmte Reifegrad in Continuous Delivery nicht erreicht hast,
dann solltest du nicht Microservices machen.
Da muss ich gestehen, das kaufe ich nicht.
Weil das bedeutet, dass ich eigentlich in so einer Art Deadlock ende.
Also ich sage dann halt, okay, ich kann nicht Microservices machen,
weil ich bin ja nicht Continuous Delivery reif
und ich kann nicht Continuous Delivery machen,
weil ich habe ja diesen blöden Deployment-Monolithen.
Meiner Ansicht nach ist es so, dass man mindestens den ersten Microservice, den man baut,
also ich würde anfangen, das ist das typische Szenario aus einem existierenden monolithischen System,
einen Microservice rausschneiden.
Und da ist jetzt irgendwie die Barriere nicht so super hoch,
weil also der Betrieb, den ich habe, wird dazu in der Lage sein, so ein System erstmal zu betreiben.
Also die können Systeme betreiben.
Die können das nicht in voller Schönheit.
Aber ich kriege halt sicherlich jetzt ein zusätzliches System erstmal in Produktion.
So, und dann würde ich eben parallel zwei Handlungsstränge aufmachen.
Zum einen eben den Handlungsstrang, der sagt,
wir bauen diesen Microservice.
Und zum anderen der Handlungsstrang, der irgendwie sagt,
wir bauen eine vernünftige Umgebung,
in der wir auch dann später eine Vielzahl von Microservices betreiben können.
Und das ist für mich halt auch wichtig,
weil ich sonst Gefahr laufe,
dass ich sehr viel Geld investiere in eine Infrastruktur,
die ich dann aber nicht vernünftig benutzen kann
oder nicht vernünftig ausnutzen kann oder so etwas.
Und deswegen würde ich eben genau an dieser Stelle versuchen,
diese beiden Aufgaben zu parallelisieren.
Und das sind eben auch,
und das sind eben auch Prozesse,
die sich gegenseitig befruchten.
Also ein Microservice eben,
für ein Microservice den Continuous Delivery Pipeline aufzubauen,
ist eben einfacher als die für einen Monolithen.
Also sollte ich eben diese beiden Sachen nach meinem Empfinden parallel angehen.
Ja, Hand in Hand bedingt sich dann wahrscheinlich auch.
Jawohl.
Du hast eben schon so ein, zwei Tools genannt.
Das wird auch ja immer gerne nachgefragt.
Mit welchen Tools arbeitet man dann?
Insofern gibt es,
Docker hast du genannt,
gibt es noch andere Tools, wo du sagst,
die sind einfach, die sind gerade State of the Art
und da sollte man einfach Bescheid wissen.
Und was haben die für Auswirkungen auf Continuous Delivery?
Ja, das hängt halt ein bisschen davon ab,
wie man Continuous Delivery interpretiert.
Und wenn wir jetzt bei meinem Beispiel bleiben,
von dem ich vorhin sprach,
also sechs Wochen Test, zwei Wochen irgendwie,
zwei Tage Deployen.
In der Continuous Delivery Diskussion wird häufig
das Thema Continuous Delivery mit einer Deployment Automatisierung gleichgesetzt.
Wenn ich jetzt in diesem Szenario
eine Deployment Automatisierung ansetze,
setze ich bei diesen zwei Tagen an.
Und das hat offensichtlich nicht so sonderlich viel Potenzial.
Und auch ansonsten würde ich eben sagen,
wenn ich mich hinstellen würde und sagen würde,
hey, hier ist ein Bugfix, der muss sofort raus.
Dann wird er auch relativ schnell in Produktion sein.
Also das wird nicht zwei Tage dauern.
Das wäre unwahrscheinlich.
Das heißt, die Frage ist, was ist eigentlich das Problem?
Und die Antwort ist meiner Ansicht nach,
ich habe nicht genügend Vertrauen in ein neues Stück Software.
Das ist genau das, was bei einem Bugfix gerade nicht der Fall ist.
Weil beim Bugfix weiß ich, da gibt es einen Fehler.
Und das neue Stück Software ist sehr präzise so zugeschnitten,
dass eben einfach nur dieser Fehler raus ist,
sodass ich Vertrauen habe, dass sich die Situation auf jeden Fall verbessert.
Und dann kriege ich das Zeug auch schneller in Produktion.
Das heißt, die Werkzeugfrage ist meiner Ansicht nach in erster Linie eine Frage nach Testing.
Also wie kriege ich das Zeug getestet?
Und dann gibt es noch eine andere Komponente, die glaube ich wichtig ist,
die halt auch an einigen Stellen übersehen wird.
Also wir könnten sagen, ich will eigentlich eine Continuous Delivery Pipeline aufbauen.
Ich brauche ein Werkzeug, um diese Continuous Delivery Pipeline zu automatisieren.
Und dann brauche ich eine Deployment Automatisierung und dann hat sich das,
dann ist das Zeug in Produktion und ich bin fertig.
So nochmal, das Problem ist nicht meiner Ansicht nach häufig das Deployment zu automatisieren,
sondern dafür zu sorgen, dass ich mehr Vertrauen in das Deployment habe.
So deswegen teste ich.
So und jetzt gibt es den Bereich von so Kapazitätstests.
Und bei Kapazitätstests geht es eben darum, zu schauen, ob die Software schnell genug ist.
Und dazu brauche ich eine vernünftige produktionsnahe Umgebung.
Dazu brauche ich vernünftige produktionsnahe Daten.
Dafür brauche ich vernünftige produktionsnahe Szenarien und so weiter.
Spätestens an der Stelle, wo ich sage, ich habe ein neues Feature, kann ich das alles vergessen.
Also wenn ich da irgendwie dem PO sage, hör mal zu lieber PO, sag mir doch mal, wie das in Produktion laufen wird.
Da kann der PO, wenn er ehrlich zu sich ist, nur sagen,
naja, ich hoffe, dass Leute das benutzen.
Und ich hoffe, dass das halt die folgende Anzahl an Leuten benutzen.
Und zwar folgendermaßen.
Aber er könnte genauso gut völlig andere Zahlen geben.
Und das bedeutet, und das gilt auch im Allgemeinen.
Also das Problem ist eben, ich weiß nicht genau, wie die Leute die Sachen benutzen.
Ich kann nur sehr schwer oder vielleicht gar nicht Produktionsdaten haben für Tests.
Und es ist auch sehr schwer oder fast oder unmöglich,
ein produktionsnahes System für das Testing zu bekommen.
Meistens ist es so, dass die Abteilungen genügend damit zu tun haben, überhaupt irgendeine Umgebung aufzubauen.
Also wenn man das alles subsummiert, muss man eben sagen,
naja, wenn ich mit einem Kapazitätstest in Produktion gehe,
der Kapazitätstest ist grün, dann ist es reichlich naiv anzunehmen,
dass ich halt in Produktion keine Performanceprobleme haben werde.
So und um das zu lösen, werde ich halt in Produktion Monitoring machen.
Und schauen müssen, ob ich irgendwo sehr lange Antwortzeiten habe oder sonst irgendetwas.
Das kann ich noch weiter kombinieren mit anderen Maßnahmen.
Ich kann Sachen erstmal blind mitlaufen lassen und schauen, wie es sich performancemäßig verhält.
Oder ich kann eben dort erstmal nur einige Knoten im Cluster mit einer neuen Version versorgen
und später dann alle und erstmal die neuen überprüfen und anschauen.
Das ist Canary Releasing.
Und das bedeutet im Allgemeinen,
ist ein wichtiger Teil von Continuous Delivery die Möglichkeit,
auch in Produktion genauer hinzugucken, Sachen zu monitoren
und dadurch das Risiko eines Deployments weiter zu verringern.
Das hört sich ein bisschen an wie Tests in Produktion,
aber mindestens an der Stelle, wo wir halt über Performance-Tests reden,
würde ich argumentieren, dass wir keine andere Möglichkeit haben.
Wenn wir uns hinstellen und sagen, wir haben Performance-Tests, die sind grün,
und dann können wir sicher sein, dass wir in Produktion keine Fehler haben.
Das ist naiv.
Also sollten wir eben auch in Produktion entsprechende Maßnahmen haben,
um dort zu überwachen, zu schauen, dass wir halt im Notfall eingreifen können.
Und das ist für mich eben auch ein Continuous Delivery-Anteil.
Eben Risikomanagement jenseits von Tests ist das für mich letztendlich.
Ja, okay.
Das klingt alles für mich, sag ich mal, plausibel an der Stelle.
Wahrscheinlich sehr schwierig.
Wahrscheinlich ist die Schwierigkeit, das dann in gewachsenen Strukturen umzusetzen.
Du hast eben das Thema auch angesprochen, Test.
Test ist, glaube ich, ein großer Anteil von Continuous Delivery, ein großer Treiber.
Für mich als Betriebswirt finde ich immer so zwei schöne Begrifflichkeiten da ganz herausstechend.
Du hast bestimmt sicherlich noch ein paar mehr, wenn ich mir das Test anschaue.
Also Test-Driven Development und Behavior-Driven Development.
Wie passen die in das Continuous Delivery-Umfeld hinein?
Ja, also Test-Driven Development bedeutet, dass ich erst den Test schreibe und dann die Implementierung.
Das kann man auf verschiedenen Ebenen machen.
Das kann man zum Beispiel für Unit-Tests machen.
Also ich schreibe halt, ich will irgendwie eine Klasse schreiben oder eine Methode.
Ich schreibe erstmal einen Test, der irgendwie sagt, wie diese Methode aussehen soll und wie sie reagieren soll.
Dann baue ich die Implementierung.
Und dann baue ich irgendwie den nächsten Test, der irgendwelche Sonderfälle umfasst oder sowas.
Und dann baue ich eben die Implementierung so um, dass sie halt die Sonderfälle umfasst.
Dieses Vorgehen ist nach meinem Empfinden etwas, was sozusagen aus dem Continuous Delivery-Bereich rausfällt,
weil das zu fein granular ist.
Das ist für mich etwas, was eben ein Entwickler vor seiner Maschine einfach tut
und hat mit einer Continuous Delivery Pipeline nicht so wahnsinnig viel zu tun.
Eine der Ideen von Behavior-Driven Development, das ist ja das, was du genannt hast,
ist, genau diesen Mechanismus, Test-Driven Development, auch auf grob granularer Resonanz,
grob granularere Sachen loszulassen.
Das heißt, die Vision ist, zusammen mit einem Experten, einem Fachexperten,
der irgendwie aus dem Fachbereich kommt oder im Product Owner oder sowas,
definiere ich einen Test, der sagt, wie dieses System sich verhalten soll im Sinne eines Akzeptanz-Tests.
Also, wenn der Test grün ist, wird das System eben abgenommen.
Und dafür nutzt Behavior-Driven Development solche Sachen,
dass ich halt Szenarien hinschreiben kann, tatsächlich in Englisch also oder in Deutsch nicht,
gegeben ein Kunde, da gibt es solche Teile, die eben voll definiert sind, also gegeben beispielsweise,
da würde ich also hinschreiben, gegeben ein Kunde mit einem Namen und einem bestimmten Kreditscoring.
Dann sage ich, was für ein Ereignis passieren muss, wenn der Kunde eine Bestellung über 1.000 Euro abgibt.
Und dann sage ich noch, was ich erwarte.
Dann erwarte ich, dass eben diese Bestellung abgelehnt wird.
Sowas in dem Dreh.
So, und das kann ich jetzt hinschreiben als eine fachliche Definition.
Und ich kann das dann eben so lange den Code ändern, bis das entsprechend umgesetzt ist.
Das ist nicht nur relevant, weil es eben die Qualität der Software erhöht,
sondern auch insbesondere deswegen,
weil ich dadurch,
den Kunden beim Akzeptieren der Software sozusagen eliminiere.
Also der Kunde, wenn er die Akzeptanztest versteht und akzeptiert,
dann brauche ich, bevor die Software in Produktion geht,
nur noch die Software eben durch den Akzeptanztest zu bekommen,
durch den automatisierten Akzeptanztest und dann kann ich es in Produktion geben.
Und das ist ein wesentlicher Schlüssel.
Also an der Stelle, wo ich sage, der Kunde will manuell noch durchtesten,
fehlt mir die Fantasie, wie das funktionieren soll,
mit mehrmals Deployment pro Tag.
Also das kann ich im Prinzip noch machen,
aber das ist dann nicht mehr sinnvoll.
Ich weiß nicht, was der da noch rausfinden will.
So, und das ist eben der Grund, weswegen genau dieser Bereich
eigentlich einer der wichtigen Bereiche von Continuous Delivery ist.
Und weswegen eben in meinem Buch auch ganz viel irgendwie über Testen drinsteht,
weswegen der Continuous Delivery Pipeline ganz viel über Testen schreibt oder eben sagt.
Und das ist eben dem geschuldet, dass genau dieser Bereich
Testing das höchste Optimierungspotenzial hat
und dass man da auch am meisten eigentlich ändern muss,
wenn man eben mehrmals pro Tag deployen möchte.
Ja, ich würde da gerne nochmal einhaken.
Für mich klingt dieses Behavior Driven Development so ein bisschen wie
die Idee, die es damals ja auch gab.
Ich modelliere mit ARIS, also mit einem Prozessmodellierungstool,
modelliere ich einen Prozess.
Und dann drücke ich auf den Knopf und dann kommt da eine SAP-Routine raus.
Und wenn ich das vergleiche, wie mein Verständnis wäre,
hier zu sagen, ist das überhaupt möglich?
Also was sind so auch deine praktischen Erfahrungen?
Lässt sich das umsetzen an der Stelle?
Hast du nun wirklich auch Projekte, wo das gemacht wird?
Also das wird umgesetzt, ja.
Und das ist eben auch etwas, was gemacht werden kann.
Aber, also du hast halt recht, das ist eben nicht einfach.
Und der Grund, warum ich eben darauf rumreite, ist gerade,
weil es eben nicht einfach ist und weil es aber eigentlich unabdingbar ist.
Und also das geht schief an vielen verschiedenen Stellen.
Also irgendwann, ich weiß nicht mehr, was für ein Szenario das war,
da war irgendwie die Aussage, wir haben einen Akzeptanztest,
aber der Kunde wird trotzdem irgendwie nochmal draufgucken.
Sondern da habe ich irgendwie gefragt, naja, wie sieht das aus?
Weiß der Kunde, was für Akzeptanztest das sind?
Hat er die schon mal gesehen?
Und dann stellte sich heraus, nein.
So, und das ist natürlich irgendwie tödlich.
Und das ist, glaube ich, eines der Missverständnisse,
das halt an vielen Stellen existiert.
Es geht eben nicht darum, dass jetzt der Entwickler
mit Hilfe von irgendeinem BDD-Tool die Tests schreibt, die er eh schreibt.
Sondern es geht darum, dass der Kunde Vertrauen entwickelt in die Tests,
sodass die automatisierten Tests ausreichend sind,
um Softwareproduktion zu bekommen.
Das ist auch ein bisschen ein Problem,
den ich mit der Diskussion an der Stelle manchmal habe.
Das ist eben keine Tool-Diskussion.
Es geht darum, dass der Kunde diesen Test vertraut.
So, das bedeutet an der Stelle,
das war auch zum Beispiel etwas, wo ich so für mich etwas gelernt habe,
man kann ja so ein Akzeptanztest jetzt auch mit einem UI-Test machen.
Dass ich eben sage, okay, ich habe ein automatisiertes Ding,
wo irgendwie rumgeklickt wird und am Ende sagt man halt,
ja, die Software funktioniert oder eben auch nicht.
UI-Tests sind nicht so toll, die dauern lange,
die sind auch fragil, wenn ich irgendwie Buttons umbenenne,
dann können die UI-Tests brechen,
obwohl die Funktionalität immer noch da ist und so weiter.
So, und in dem konkreten Szenario war es eben so,
dass ich gesagt habe, nee, lass uns doch keine UI-Tests machen,
sondern lass uns das irgendwie anders machen.
Also eben mit so einem Behavior-Driven Development Tool.
Und das hat sich nicht durchgesetzt, weil die Aussage dort war,
naja, die Kunden testen jetzt im Moment UI-basiert.
Wenn die Kunden testen jetzt im Moment UI-basiert,
wenn wir das ändern, wenn wir also dort
einen automatisierten UI-Test haben,
dann haben wir eine höhere Wahrscheinlichkeit dafür,
dass die Kunden das akzeptieren.
Und mittlerweile würde ich sagen, ja, genau,
das ist eigentlich der wesentliche Punkt.
So, und da gibt es viele andere Potenziale,
also an der Stelle, wo der Kunde so ein lustiges
Excel-Spreadsheet hat, wo irgendwie draufsteht,
wie er schrittweise die Software testen will,
kann man eben versuchen, dieses Excel-Spreadsheet zu nehmen
und automatisiert einzulesen, um dann eben einen entsprechenden Test
daraus abzuleiten oder den Test eben automatisiert durchzuführen.
Wenn da irgendwie steht, klick hier, klick hier, klick hier,
in diesem Excel, kann man das ja entsprechend ausführen.
Das ist ja kein großer Unterschied zu dem,
was Behavior-Driven Design da eh tut,
weil die eben dort dann entsprechend Textdateien haben.
So, und das ist eben der wesentliche Punkt an der Stelle.
Und ich kann nur nochmal wiederholen, das ist nicht trivial,
aber wie will ich sonst von diesen Textdateien,
wie will ich sonst von diesen sechs Wochen runterkommen,
auf wie viele Malts pro Tag?
Also wenn ich halt die Software dem Kunden in die Hand gebe,
wird das nicht funktionieren.
Also entweder schaffe ich das, die Akzeptanztests zu automatisieren,
oder ich werde mein Ziel nicht erreichen.
So einfach ist das nach meinem Empfinden.
Ja, und was ich bei dir raushöre, ist dann die Schwierigkeit ja auch,
dass letzten Endes das, was ich als Herausforderung für die,
ich sag mal aus psychologischer Sicht bei Test-Driven Development,
für die Entwickler, weil sie ja anders vorgehen müssen als früher.
Also früher sind sie ja häufig eher so als freischaffende Künstler unterwegs gewesen.
Sie müssen jetzt anders arbeiten und genauso müssen sich auch die Kunden anpassen.
Sie müssen das, was sie testen wollen, sauber und eindeutig beschreiben,
damit es dann eben automatisiert werden kann, oder?
Ja, genau. Wobei ich halt gestehen muss,
an der Stelle existiert für mich so ein bisschen so eine philosophische Frage.
Also wenn ich nicht sagen kann, was ich teste, wie teste ich es dann?
Also wenn ich nicht klar sagen kann, die Software soll sich folgendermaßen verhalten,
dann mag es ja sein, dass es irgendeinen unstrukturierten Test gibt,
der hat irgendwie einen Eindruck vermittelt, ob die Software vernünftig funktioniert.
Aber das ist ja nicht wirklich zuverlässig.
Also würde ich halt behaupten, dass an der Stelle, wo das nicht formalisiert aufschreibbar ist,
das sowieso wenig Sinn macht.
Vielleicht an der Stelle noch ein Hinweis, weil das finde ich halt auch ganz interessant.
Wir reden jetzt ein bisschen sehr stark, so wie es damals bei Extreme Programming war.
Extreme Programming hat damals gesagt, also das ist ja mittlerweile 20 Jahre her,
irgendwie im letzten Jahrhundert entstanden.
Und Extreme Programming hat damals gesagt, eine vernünftige Anforderung ist ein automatisierter Test.
Und das war eben eine sehr radikale Meinung.
Das läuft jetzt ein bisschen auch in diese Richtung.
Ich würde das nicht ganz so sehen.
Und das ist auch etwas, was tatsächlich sich in der Continuous Delivery Pipeline anders niedersteckt.
Ich kann manuelle Tests in der Continuous Delivery Pipeline haben.
Also es gibt explorative manuelle Tests.
Die dürfen nur nach meinem Empfinden kein Vetorecht haben, ob Software in Produktion geht.
Also will heißen, wenn ich mehrmals pro Tag deployen will, muss ich die Tests automatisieren.
Dafür darf es nicht so sein,
dass irgendein manueller Test sagt, ja, ich verbiete, dass dieses für Fan-Produktion geht.
So und jetzt ist die Frage, was machen dann überhaupt diese manuellen Tests?
Naja, es gibt bestimmte Sachen, die kann ich nicht so einfach automatisieren.
Also beispielsweise UX-Tests, wo ich irgendwie schaue, ob das Ding benutzerfreundlich ist.
Und das macht irgendwie auch nicht so sonderlich viel Sinn.
Und ich wüsste auch nicht, ob die nun unbedingt sozusagen betriebsverhindert sein sollten.
Vielleicht auch sowas wie Penetrationstests, obwohl man da eben diskutieren kann.
Unsicher, Software sollte vielleicht wirklich nicht in Produktion gehen.
Oder solche Sachen wie, naja, wir haben bei der Registrierung im Moment bekanntermaßen Performance-Probleme.
Guck da doch mal rein.
So und das ist offensichtlich in Produktion schon aufgefallen.
Also werde ich weiter Software in Produktion bringen, die dieses Problem hat.
Weil das verschlechtert eben die Produktion nicht.
Aber durch diese explorativen Tests kann ich eben einen Handlungsstrang lostreten.
Der dafür sorgt, dass das ausgemerzt wird.
Und dann vielleicht auch eben automatisierte Tests irgendwann ergibt.
So lange Rede, kurzer Sinn.
In diesem Continuous Delivery Bereich sind automatisierte Tests nicht das, was immer gemacht werden muss.
Grundsätzlich, so wie bei Extreme Programming.
Es gibt manuelle Tests, nur die sollten eben nach meinem Empfinden nicht produktionsverhindernd sein.
Sonst macht das eben keinen Sinn und ich kriege halt die hohe Geschwindigkeit nicht hin.
Ich würde auf das Thema Automation nochmal eingehen.
Du hast eben an vielen Stellen in deiner Ausführung immer wieder von Automation gesprochen.
Und wenn ich jetzt mal so eine naive Frage stelle, wäre denn Continuous Delivery ohne Tools überhaupt denkbar?
Sicher nicht.
Und also Test-Tools, diese Tools, die die Pipeline zusammenhalten und die halt durchführen, wie auch die Test-Tools, sind natürlich notwendig.
Ja.
Ja.
Das ist aber etwas, wo zumindest im Bereich Testing ja vorher schon es viele Tools gab.
Und die Innovation ist eben tatsächlich eher einmal in dem Bereich der Pipelines und zum anderen eben in dem Bereich von, wie kriege ich die Software nachher in Produktion.
Okay.
Das heißt letzten Endes einfach nur eine Art Veredelung.
Und vor allen Dingen die Unterstützung des gesamten Prozesses, des Pipeline-Prozesses.
Ja.
Letztendlich geht das halt in diese Richtung.
Und wir haben halt in dem Bereich, wir haben halt in diesem Bereich von, gerade die Pro mit Automatisierung, halt erhebliche Fortschritte.
Mittlerweile durch sowas wie Docker ist das sehr einfach geworden.
Und ich glaube auch, dass sich da so ein bisschen so ein Standard rausschält.
Umgebungen wie Kubernetes unterstützen auch.
Und unterstützen auch bestimmte Release-Taktiken.
Also ich habe gerade von Canary-Releasing gesprochen, wo man erstmal auf einem Knoten die neue Software deployt und dann später erst auf allen.
Das ist etwas, was Kubernetes beispielsweise direkt unterstützt.
Mit Kubernetes kann ich eben Docker-Container in einem Cluster laufen lassen und kann dann eben genau solche Deployment-Ticks wie Canary-Releasing direkt unterstützen.
Und von daher ist eben in diesem Bereich Deployment-Automatisierung, aber auch im Bereich von dem Management-Programm.
Aber auch im Bereich von dem Management, von den Pipelines, da ist sicherlich sehr viel Innovation zu sehen im Moment.
Ja, ich gucke ein bisschen auf die Uhr und die sagt mir, dass wir jetzt bei einer Zeit sind, die so angestrebt ist von der Planung her.
Ich finde auch, dass wir ziemlich viele gute Themen behandelt haben.
Gibt es aus deiner Sicht noch fachliche Dinge, die du anführen würdest zum Thema Continuous Delivery im Kontext DevOps?
Mir fällt jetzt so ad hoc nicht wirklich etwas ein.
Ich habe halt hingewiesen auf diese Studie.
Die kriegt man halt kostenlos.
Die, finde ich, ist eine ganz gute Argumentationshilfe und zeigt halt irgendwie auch, wo wir Optimierungspotenzial haben.
Ich glaube, das ist ein wichtiges Thema.
Ansonsten, also sich mit dem Thema Continuous Delivery auseinanderzusetzen und mit dem Thema Microservices macht halt sehr viel Sinn.
Neben den Büchern, also gerade im Microservices-Bereich ist halt neben den Büchern, die ich geschrieben habe, die man kaufen kann, gibt es auch ein paar kostenlose Bücher von mir.
Da kann man sich also auch, denke ich, suchen.
Da kann man sich auch, denke ich, sehr gut einarbeiten und mal schauen, was da voraus ist.
Ja, also die Hinweise auf deine Bücher werde ich in den Shownotes bringen.
Da hast du ja eine ganze Reihe von nützlichen und interessanten Websites dazu.
Das heißt, das kann man dann auch in den Shownotes sehen.
Den State of DevOps Report finde ich auch sehr interessant, wenn ich in meinen Schulungen diese Zahlen dort auflege.
Ich glaube, wir haben die Zahlen aus 2016 noch drin stehen.
Dann schlackern die alle mit den Ohren.
Natürlich sind das Zahlen.
Man erstmal überprüfen und hinterfragen muss.
Aber trotzdem sind es einfach Zahlen, die mal da sind und da stehen und die manche klassische IT ganz schön ins Schwitzen bringen.
Ja, genau.
Also, wenn man sich das tatsächlich anguckt, die haben ja so eine Segment-Analyse gemacht und haben irgendwie gesagt, wie stark unterscheiden sich eben die Elite-Performers von den Low-Performers.
Und die bekommen da tatsächlich Faktoren raus und zwar sehr hohe in Bezug auf Lead-Time und bessere Zuverlässigkeit, neue Releases und so weiter und so weiter.
Und auch in Bezug auf neue Arbeit.
Also, wie viel Zeit kann ich in neue Arbeit investieren?
Ich glaube, es ist 50 versus 30 Prozent oder sowas.
Ich würde das auch kritisch hinterfragen.
Klar, auf der anderen Seite ist es eben so.
Ich muss gestehen.
Intuitiv ist es eigentlich vielen Leuten, glaube ich, schon klar.
Also, wenn man jetzt einfach jemanden fragt und sagt, hey, Quartalsreleases, Mehrmalsportal-Releases, was wird häufiger schiefgehen?
Es ist absolut überraschend, wenn da jemand sagt, ja, Quartalsreleases werden weniger häufig schiefgehen.
Und das führt eigentlich ja zu der Frage, warum haben wir es nicht immer so gemacht?
Und ich glaube, dass eben der Kern dessen, warum wir es eben nicht immer so gemacht haben.
Oder warum das so entstanden ist.
Das Problem ist, dass das Deployment der verschiedenen Systeme koordiniert werden muss in vielen Architekturen.
Und das führt eben wieder genau zu dem Microservices-Ansatz, wo man an sich nach die wesentliche Aussage ist, nein, muss nicht koordiniert werden.
Und dadurch sprengen wir halt dieses Problem.
Wie übrigens auch, wie wir übrigens auch an der Stelle Voraussetzungen eliminieren, die SAFe hat, nicht?
Also das SCALE-Agile-Framework sagt,
wir müssen ein System haben.
Wir müssen ein Release-Train haben, in dem wir alle Projekte gemeinsam in Produktion bringen.
Deswegen müssen wir die Entwicklung der verschiedenen Projekte eng koordinieren.
Den müssen wir nicht.
Wenn wir halt irgendwie die Releases voneinander entkoppeln und dafür sorgen, dass eben diese Systeme getrennt deployed werden können, müssen wir auch nicht so ausführlich koordinieren.
Und deswegen ist eben genau dieser Ansatz so wichtig, glaube ich, an der Stelle.
Gut, dann würde ich mal sagen, Ewald, ich bedanke mich.
Ja, danke.
Ich finde es immer wieder schön, wenn Experten ihr Expertenwissen so erklären können, dass es auch ein Nicht-Experte versteht.
Und ich habe heute einiges mitgenommen, habe einiges verstanden.
Schön.
Insofern bedanke ich mich an der Stelle und ich hoffe, dass auch den Zuhörern das auch so geht.
Und also vielen Dank und bis demnächst, Ewald. Tschüss.
Ja, danke.
Vielen, vielen Dank.

Folge 12: Gespräch mit Rob England (The IT skeptic)

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Rob England ist als IT Skeptic weltweit bekannt und beschäftigt sich seit Jahren mit ITSM, Agile und DevOps. Wir sprechen über das schlimmste, was der IT passieren konnte: Projekt Management.

In dieser Folge des Podcasts „DevOps – auf die Ohren und ins Hirn“ sprechen die Gastgeber Alex Lichtenberger und Dirk Söllner mit Rob England, auch bekannt als der IT-Skeptiker, über die Probleme traditionellen Projektmanagements in der IT und die Vorteile des Übergangs zu DevOps und agilen Methoden. England argumentiert, dass traditionelles Projektmanagement oft ineffizient und ungeeignet für die IT ist, da es die Komplexität und Veränderlichkeit von Softwareentwicklungsprojekten nicht berücksichtigt. Er diskutiert, wie DevOps und Agile eine bessere Anpassungsfähigkeit, stärkere Teamdynamiken und kontinuierliche Verbesserung ermöglichen, und betont die Notwendigkeit einer kulturellen Veränderung in Unternehmen, um diese neuen Arbeitsweisen zu unterstützen.

Inhalt

  • Einführung und Vorstellung von Rob England
  • Kritik am traditionellen Projektmanagement in IT-Projekten
  • Vorteile von DevOps und agilen Methoden gegenüber traditionellem Projektmanagement
  • Diskussion über Dysfunktionen im Projektmanagement und ihre Auswirkungen auf IT-Teams
  • Die Rolle von Automatisierung und kontinuierlicher Verbesserung in DevOps
  • Notwendigkeit einer kulturellen Veränderung für erfolgreiche DevOps-Transformation
  • Betrachtung von DevOps als globale Bewegung und ihre unterschiedliche Anwendung weltweit
  • Abschlussdiskussion und Schlussfolgerungen zu DevOps und Projektmanagement

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 die Unternehmen erfolgreicher machen können.
Hallo und willkommen zu dem Podcast DevOps – auf die Ohren und ins Hirn.
Das heißt, DevOps durch die Ohren in den Gehirn zu bringen.
Mein Name ist Alex Lichtenberger und zusammen mit Dirk Söllner runne ich diesen Podcast.
Wie Sie hören können, ist das jetzt unser erster Podcast in Englisch.
Der Grund dafür ist, dass wir heute einen besonderen Gast haben, Rob England, auch bekannt als IT-Skeptiker.
Hallo Rob.
Hallo, freut mich, auf der Bühne zu sein.
Ja, danke.
Danke, dass Sie mitgekommen sind.
Es ist nicht nur speziell, dass es in Englisch ist, aber Rob ist auch auf der anderen Seite des Globes, also jetzt aus der europäischen Perspektive, in Neuseeland.
Das bedeutet also auch, dass die Zeit, die wir in dieser Session rekordieren, um 10 Uhr in der Nacht in Deutschland oder in der Schweiz ist.
Und Ihr Zeitpunkt ist jetzt 8 Uhr in Neuseeland.
8 Uhr, ja.
Unglaublich.
8 Uhr morgen, also ich kann Ihnen sagen, dass die Wetter morgen sehr schön ist.
Gut, ja.
Ich hoffe, dass es uns gelingt.
Also, wie es jetzt in Englisch ist, und ich denke, wir werden auch einige neue Redner haben, also ist es auch wert, kurz zu erklären, worum dieser Podcast geht.
Also unser Ziel ist es, interessante Interviews und Experten-Zweige über DevOps zu machen.
Und auch, weil es ein Podcast ist, also glaube ich, dass es auch sehr interessant ist, für Menschen, die eigentlich das Medium eines Podcasts lieben, also sei es im Zug, Bus, Auto oder auf der Fliege.
Heute geht es um das Thema Projektmanagement, das ist das schlimmste, was sich bei IT jemals passiert.
Eine sehr interessante These, denke ich.
Und bevor wir eigentlich in das Projektmanagement hineingehen.
Ein Thema und ein Thema von DevOps.
Vielleicht, Rob, können Sie sich kurz darüber vorstellen, was Sie als Person und was Sie professionell machen.
Ja, Rob.
Okay, also ich habe in Wellington, New Zealand, seit zwölf Jahren konsultiert.
Vor dem, als ich als Pre-Sales-Mann in Vendorland gearbeitet habe, habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Ich komme aus einem ITIL und Service-Management und operatio-Besitz-Besitz-Beifragung, obwohl,
wenn Sie, Entschuldigung, wenn Sie sich tief hinschauen, dann war ich früher ein Code-Developer.
Und, äh, in diesem Zeitpunkt habe ich über Service-Management und Regulierung und Strategie
gewechselt.
Und ich habe ebenfalls einen kleinen Blog eingebaut, den ich 12 Jahre zuvor hatte, als das
eine novelte Sache war.
Und es hat ein bisschen eine Nachfolge auf dem ganzen Weltraum gegeben, was Spaß war.
Und es hat ein bisschen eine Nachfolge auf dem ganzen Weltraum gemacht.
me into a bunch of people so that along the road of agile and then later devops the blog was um
taking a very skeptical view of these things and throwing a lot of rocks and some of the leading
thinkers in the devops space worked on me over a period of years and slowly broke down all my
objections and turned me into a bit of a fanboy a bit of an evangelist for devops so
i’ve been trying to talk to people in wellington about devops for quite a long time and in recent
years it has exploded and now i work a hundred percent in devops consulting it’s all i do
and i work now with my partner in life and work dr cherry vu and we call ourselves teal unicorn
which is a a a bit of a trendy
brand but we we like uh riding on the wave of of fed energy so teal unicorn uh actually quite
proud of that one i think it’s quite a good brand for a consulting organization and so that’s what
we do we consult here in wellington we design and build games we deliver games such as the phoenix
project game from gaming works we go to conferences we speak we spoke at the devops enterprise summit
and um just immerse in all things devops it’s wonderful hello rob so thanks and it’s nice to
have you here in our podcast so like we do to all our guests um what would you say how would you
define devops so devops is whatever you say it is man you know it has no formal definition so it’s
wonderful that you asked that question of everybody and uh
i take the big picture definition so you know some people would say it’s somebody in a server
room automating a linux server and some people would say it’s continuous integration and
continuous delivery and continuous testing and the flow from development to deployment
and particularly the automation of that but i take the even bigger view of the alms
service and the sharing and applying those principles to all the value streams in it
not just the require to deploy value stream but anywhere where we can move to new ways of working
which is my preferred phrase for describing it so for someone like me the term devops is actually
more baggage than help these days because it’s very technical and it focuses on dev and ops
and it doesn’t really embrace all the principles of new ways of working which have emerged in this
space yes okay so um like you like alex and like me we all came from it service management so what
do you think what uh what’s the correlation between id service management and devops several decades
ago
but um
uh i think that that itsm is just part of the thinking and um
you know i’m a big fan of gene kim’s approach to that itsm is an integral part of all of this but
itsm needs to move its thinking forward just like every other aspect of it needs to so
that whole crossover and impact on itsm is a particular area of interest and study for me and
that’s what we presented on last week it’s uh we went kind of tribal for a while and the
agile slash devops community in the itsm community kind of got it opposite ends of the paddock and
threw stones at each other and it hasn’t necessarily been a constructive relationship but
um you know we’re seeing lately i think around the world that the two groups are now really
starting to think together and get together and cross over ideas and
devops and agile are bringing bringing new thinking into idle um hence idle practitioner
or as i prefer to call it idol 3.5 and um and hence the work on idol 4 and hence
verism as a framework and hence um uh finally some influence from thinkers like richard cook and
sydney decker and some of the new ways of thinking about error
and resilience and and particularly thinking around complex systems so all these ideas
are spilling into the itsm space at last and uh so i think that’s the relationship is that
we there has been a tribalism but we’re coming together and we should i’ve always advocated that
we just need to bring itsm along on the journey yeah yeah let’s hope i mean that uh future
versions of uh itel and also verizon
will will bring in these ideas and coming back to your definition also of devops uh i actually
as dirk said we ask that question every interview guest and each time it’s a little bit different but
from my point of view i liked uh that you’re actually holistic well holistic whatever but
holistic view so uh looking at the different aspects uh which are needed and especially the
the people aspect so um
as the people aspect um
so now you know sorry in fact now i’m trying to expand
to train myself to say new ways of working and managing
big because one of the strongly emergent themes in recent years has been that for
an organization to change the leaders need to change right and so all the talk around
servant leadership and transformational leader and and realizing that often agile and devops when we say solutions but we’re definitely trying to sell it into the community as well trying to create solutions in terms ofWhat should weglif if there’s a right path how to give to this learning path etc
and transformational leader and and realizing that often
agile and devops
fail, because the management
think it’s something you do
to fix their people, and that they don’t
need to change the way they manage it all.
We really need to break
that. Yeah, which
nicely brings us to the
actual topic. So you
talked about management,
so also
now talking about managing
projects,
and one of your,
I mean, the reason how
we got to that topic is
also, I mean, some of our
listeners maybe know
the blogs of Rob England,
always with very interesting
titles.
I personally like also the one
that was titled, like,
How DevOps Messes With Your Head.
But recently you wrote a couple of
blogs, like,
I have to look that up, but it was
like
10 Agile
Principles That Screw Up
Conventional Project Management,
or the latest
one was the Oxymoron of Agile
Project Management,
or an older one, Project Management
was the worst thing that
ever happened to IT.
So I think they all go into the same
direction. So Rob, maybe you can
just as an intro, you can also
shortly explain. So we did now for
decades, projects,
so now
you say that’s the worst thing ever happened to
IT. Can you please explain?
So
the way I
see it, somewhere back
in the 80s and 90s
as
the cost of IT escalated
in lots of organizations, generally
for very good reasons, because IT was becoming
more and more mission critical and more and more complex
and so the costs were rising.
And organizations
governed IT like a black art.
They really didn’t understand how it works
in the same way that they understand how
finance works or
people management works. So
it was just a black art. They didn’t
understand it. So they went, oh my god, we need
to get some control over this.
Let’s black box it. Let’s
define the inputs and measure
the outputs. And so let’s put
a project and program management framework
over it so that we can see that we’re
getting what we thought we were getting with our money.
And IT
being typical IT,
took an
intensive engineering approach
to project management and adopted
civil
engineering style project management.
And imposed
these strict
waterfall constructs
on us. And
as a result
applied a paradigm
that is completely inappropriate
in a software world.
And the reason I say
it’s inappropriate is
because of our understanding now.
So at the time, you know,
we didn’t know everything that we know now.
But we understand now that
what we build are not simple systems, they’re
complex systems, that
you can define a bridge down to the
last rivet and
girder and then
build the bridge
because it’s near to a
simple system. Whereas
a software system
is nothing of the sort. It’s a complex system.
Which means that we have
no idea when we start the journey
what it is we’re actually going to build.
And yet
project management perpetuates this myth
of
define once, execute perfectly.
Design what you’re going to do
and then do it.
And have
defined inputs and expected
outputs.
Great. So let’s go a little bit more into detail.
And just a few days ago
I read your blog article
about dysfunctions of
project management. And I think it’s
a good point to use it
for a podcast to talk about
some of your mentioned
points over there. So
what do you think, how much
responsibility is within
DevOps?
Yes, I put those 20 dysfunctions
out yesterday and it seems to have stirred up
a bit of a hornet’s nest. So I’ll be looking forward
to putting this podcast link out as a response
to some of that.
There’s some really major
dysfunctions that project
management thinking drives in IT.
I’m a people person
so I’m with you.
Anything that affects people is,
one of my primary concerns.
And so, you know,
the basic model for project management
is we bring the
team to the work.
So we define a piece of work
and then we draw together people to create a team
to execute that piece of work.
And then when the work is completed, we disband the team.
Which is,
flies in the face of everything
we know about human behavior.
That any team has to go through
the old forming, storming, norming,
performing cycle. They need to
take time to coalesce as a group.
And they’re only just getting into the
performance. Once you get into the performing phase,
you can then start optimizing how you work.
So they get into a performing
phase and they start optimizing
how they work. And the next thing you know, the project’s
over and the team’s disbanded.
And they all sent off in different directions.
So it’s a highly
dysfunctional way of managing
people.
Whereas, you know,
product management thinking is that you have
a standing product team.
That is as stable for as long as possible.
And has the time to get into a performing
and then continuously optimizing mode.
And instead of bringing the team to the work,
we bring the work to the team.
Yeah.
Yeah, I fully agree.
And there are like now two aspects you looked at.
One is the problem with the phased approach.
And
I’m also, I’m most of the time working as an agile coach.
And I agree that, you know, in the beginning, if you don’t
know exactly what the requirements are, there’s a complex system.
You have to make the experience first.
And anyway, the team is in a storming phase that you cannot be
sure what your performance is.
So you rather go an agile approach.
And the other thing is also what I really like and what I see
as well is so less now talking about projects, what’s more about
products and what, what I would be interested because how do you see
with you saying, okay, that’s actually the traditional or waterfall project
management doesn’t make sense anymore, but don’t we still have situations
in IT where, where it still would make sense.
So where we, where we actually, when we know where we exactly want to go
and requirements are clear from the beginning, so isn’t it rather
like, let’s say a typical consultant answer, like it depends.
So which approach we choose, you know what I mean?
I, I, I don’t, I don’t feel that way.
I know a lot of people do, um, for two reasons.
One is I challenge the assertion that we know our requirements
in any software situation.
Um, so we are always building a complex system.
If nothing else, every system we build has people in it.
And as soon as you have people in a system, it’s by
definition complex, people are never simple linear and predictable.
So, um, and all our systems have people in them.
We have to stop pretending that we build things that have no people in them.
So, so I challenged the assertion that wherever in a situation where we’re
about to build a simple linear system and, and, and we have a clear understanding
of the requirements for that simple linear system, I just don’t
think we’re in that situation.
So I think that’s one challenge to it.
And then the other challenge is the whole bimodal thing, you know,
even if, even if there was a situation where project management
was a usable approach, um, I see no reason why we should have two
ways of working in an organization.
It’s equally amenable to doing it in an agile way.
So, you know, let, let’s adopt a single way of working for the organization
that works in all situations instead of adopting a new way of working for
the situations where the old way of working doesn’t work and then still
dust off the old way of working and drag it out occasionally when it does fit.
Mm-hmm then as a, as a, as a consequence, this would mean that, uh, so
you, you say bimodal is not really an option.
So what, what would be the consequence for the, for the companies that
there is only one model of working?
The consequence of only one model.
Uh, so to, to flip that, I think, you know, the consequences of bimodal are
toxic mm-hmm and, and it’s,
it’s possibly the worst idea that Gartner have ever had, but there’s a lot
of comp, but there’s a lot of competition for that title from Gartner.
It’s, it’s, I mean, I, I, I also play a little bit the devil’s advocate.
So, and Gartner by was also, they were the ones who came up with, with
the successor of the bimodal, which was the, uh, uh, paste layered
application, uh, or what, how was it called?
You’re right.
Multi, multi-speed IT, isn’t it?
Mm-hmm yeah.
And, and, um.
And I’m an advocate of multi-speed IT mm-hmm only in the sense that whatever
one way of working we come up with, it needs to embrace multiple cadences.
So, you know, the pace layering model and the application of multiple cadences,
I’m fine, I’m down with, but that we can still do all of those different
cadences with the same way of working is the point mm-hmm and, and, you know,
Gartner have softened their bimodal stance a bit by talking about convergence as
well, but, you know,
a, but I think we, we, we should aspire to converge as fast as possible because as long
as you maintain bimodalism, whether it’s product versus project or digital versus industrial,
you know, agile versus waterfall, uh, you, you’re immediately introducing tribalism
into the organization.
You’re immediately driving the idea that we have two teams, we’ve got the cool new funky
kids and we’ve got the boring old farts.
And, and.
Yeah.
und du fährst sofort eine große Schleimhaut in die Mitte deiner Organisation.
Es ist ein wirklich, wirklich toxischer Weg, um zu arbeiten.
Welche Organisation möchtest du gehören?
Also wenn du die Leute fragst, wollen natürlich die Leute Teil der coolen Leute sein.
Also ja, wir fahren auch enttrennte Positionen, sodass andere Leute sagen,
hell nein, ich bin, du weißt, das ist nur verrücktes Cowboy-Stuff.
Ich bleibe hier in der sensiblen, solid,
prüfen Welt von, weißt du, du fährst enttrennte Positionen beide Wege, tatsächlich.
Also ein guter Punkt.
Schau einfach von Neuseeland nach Europa, in die USA und überall in der Welt.
Was denkst du, sind DevOps überall in der Welt gleich?
Wie Idle sollte gleich sein oder Scrum sollte gleich sein,
weil da sind einige Frameworks geschrieben worden.
Also was denkst du, sind DevOps überall in der Welt gleich?
Ich denke,
Well, actually, DevOps is all over the world different.
So that’s a good answer.
So one of the things we need to learn is,
and this comes back to the whole product versus project thing.
We don’t know where it ends.
Anytime we do any work in the real world,
I think outside of really strictly defined technological spaces,
because technology can be really tightly locked down to be near a simple system.
But any other area of the world,
which is why Agile thinking is exploding out into business now.
We don’t know where it ends.
So whether it’s a project or whether it’s introducing DevOps ways of working
or introducing Agile, or any change at all to build something or change the way we work.
We don’t know where it ends.
So that means that DevOps looks different in every single organization around the world.
The only thing that’s common is the fact that DevOps is different, but every single organization around the world.
The only thing that’s common is the fact that DevOps is different in every single organization around the world.
is the principles they applied in order
to move forward on their journey.
But the result of applying
those principles to a complex system is
random. It’ll be different in every single
instance. So you can start
seeing patterns across large amounts of
data to see common patterns that
emerge from organizations
that take these approaches.
But there’s certainly no one pattern that
emerges and there’s no one answer.
Every organization’s
DevOps journey or any journey
is unique.
This is also what, from my
point of view, makes it
very interesting.
Maybe we can also ask the question
a little bit differently.
I think you would agree that
DevOps is also very much
a movement. So as you said
also in the beginning, there is no formal definition.
So it’s a movement. I think
you travel a lot in conferences
and speak. So how do
you see, so which regions
also in the world, so where is
DevOps very much pushed
or influenced? Do you see some
patterns here?
I’m not sure
I have a sufficiently global
view to answer that well.
You’ve got London,
isn’t it?
Yeah, so there’s passionate support
coming in the UK and
Europe and
of course there’s an epicenter
of energy in the US.
In New Zealand, well certainly
Wellington seems to be rocking
even by a global standard.
People are always surprised.
My clients include the New Zealand’s
largest government department
and New Zealand’s tax
collector.
And all the major banks are on
this. The National Airline is on this.
The telcos are on this.
So all the big core
horses in New Zealand are
either way advanced
or at least have one
blue glittery leg on the horse.
They’re all
very
they’re all starting the journey
or well down the journey.
And so
one of the banks has completely
transformed itself. One of the government departments
has completely changed the way it deploys software.
So certainly it’s hot here.
But I don’t
have a good picture around the rest of the world.
I think that’s an interesting question. I’m always
fascinated by China.
So here you have
what is now one of the largest
economies on earth.
And it’s almost completely
opaque to us. We have very little
visibility for what’s actually going on
in China in terms of ways of working.
So I know
some people
go and do training and have exchanges
and work with universities in China
and have a small visibility of this.
And there’s some academic
exchange. But every time I try and
research, I find it
really quite opaque.
And I think that’s a really interesting question
because
you know,
China is on the cusp in the next
couple of years of being one of the
five most powerful
countries on earth.
And
will eventually, of course, be the most powerful
country on earth. And yet we have
very little idea what’s going on there.
Yeah, great.
So have a look on your 20
point list regarding point number
nine. I think it’s a great point.
That leads to the point
do we have product teams
or do we have projects? And I think
it’s a good point
over there. So what’s
the experience with automation
within projects? I would
say so within
a project you are not
forced to
automate the things. And within
product teams who build
it and who run it, they are forced and they
are pushed to automate their
work. Absolutely.
So what happens
is that
my rule of thumb is it costs about
three times as much to automate a test
as it does to execute
that test manually.
So if
you’re a project manager, you’ve got the option
of either doing all the testing
once manually at the end
or investing in
automation and doing it many times throughout
the project. And for
many old school project
managers who don’t get what this is all
about, they go, you can’t be serious. Why
would I triple my testing costs?
So
they have
and in terms of automating
continuous delivery and any
other areas, they’re only going to do it once.
They’re going to build the thing,
they’re going to deploy it, they’re all going to run away.
So, you know, why
would they be interested in automating deployment?
They’re never going to have to do it again.
Yeah.
So all the incentives
are wrong for project managers
and for people on projects. They’re paid,
they’re incented, they’re measured on
how
they’re going to do it.
So, you know, I think that’s a good point.
Quickly and
accurately, they deploy once.
And maybe
one interesting point
would also be so
now, let’s say having also some
insight
and seeing all the problems
with the traditional
phased project management
and the wish
of the companies
also change towards
DevOps, standing teams, doing
agile, you build it, you own
it.
But now, let’s talk about
transformation. So people
which were used
to work
20 or 30 years
the traditional mode and now
you want to move
and you want, I understand that you work
as a consultant, you support
companies in that transformation.
And I think it’s also a
mindset change. So do you have some
tips for us? How can
we, from your experience,
what are the changes?
What are the challenges
and to actually that people
change towards the new way of
working?
Many, many, many
thoughts on this. But
some of the core ones are
I’m highly amused when I see
organizations that announce that they’re
going to move towards agile ways of
working and they’re going to do that in a
big bang project because
apparently they missed
the agile class, you know. So we
have to move towards
new ways of working in an agile way, which means
we should iterate, increment,
experiment, explore, find
our way. Because again, we don’t
know how it lands. And
I get some really interesting
conversations with traditional
organizational change management people
who want to know what the target operating
model is. And
I say, well, I have no idea. And
anybody who tells you
they know what your operating model is going to look like
in two years time, you should show them the door
because they have no idea either. Can I
ask a question between you? So I’m
hearing now that actually also the transformation
itself, you can do it in an agile way,
right? Absolutely.
It’s essential to
move forward
incrementally and experimentally
to find out what works at your organization
right now at this
point in time. And
so another language that I use is
talking about navigational
stars as aspirations
that we sail towards.
In the northern hemisphere, you
talk about the pole star or the north star.
Well, that doesn’t
work, of course, down
here in New Zealand. So I
talk about Matariki, which is a
Maori name for the
Pleiades constellation,
the Subaru constellation,
which is a constellation they navigated
with, which is highly
significant to them. But I use
that language of a navigational star
that
the navigational star is
that we do everything in product teams
and we don’t
have any
project organizational constructs
and da, da, da, da, da.
But that’s a star that we’re sailing towards.
It’s not something we’re going to just
leap to overnight. It’s
the direction we should be going in.
Yeah, consent.
So let’s switch to another point.
I like to talk about the
word or the phrase
bimodal IT.
The IT with two speeds.
Or different speeds. What do you think
about that in the context of
DevOps? I think again,
many, many thoughts, but one of the core ones
again is that we must
create white space.
So
around any attempts to
work in new ways. So even though
I’m really down on the
idea of bimodal,
ironically
bimodal is essential
as a temporary thing
while you’re experimenting
with new ways of working.
In order to experiment with a new way of working
you have to give it
isolation, white space.
You need to decouple it from the rest of your system
so that it can move in new ways.
Otherwise it’ll still be locked into the old
system.
It’s a common joke amongst consultants.
You probably see the same thing yourself
over and over again. You go into organizations
and they say, oh we tried
agile and it doesn’t work.
And the moment you
probe that, you discover that they told a team
to be agile, but left them locked into the rest
of the machine. So it was impossible for them to be agile.
And the other interesting
thing I noticed was
self-fulfilling prophecy.
So if people say,
if they are really skeptical
or no-no’s
and say, oh this will not work,
then it actually will not work.
So coming back to that
I understand, so yeah
it’s the key to success.
It’s a journey to experiments
step by step
and maybe Biomodel is the first step
to actually the next step.
But how do you deal with
because each organization
has such kind of people
so the really no-no’s
or
in a negative sense.
So I think
of this in terms of the normal distribution.
And
there are those early adopters
and pioneers at the other end of the normal
distribution who are on board straight away.
So I like to say
work with the people who want to be changed.
If people are resistant
then I used to bang away
but my strategy now is if people are resistant
I just go find and I go somewhere else.
So find
the people who want to be changed, work with the people
who have the vision, who are the early adopters
are the pioneers
and create some proof points.
Because as soon as you do something
within the organization or very close
to the organization that works
then you start moving down that balcony
you start moving into the early majority
the people who just need to see it.
And as soon as they see it they go
oh it does work and they start getting on board.
And then as soon as the early majority starts
coming on board then the late majority goes
oh look everybody is going over there
and they come along as well.
And the naysayers end up
standing on their own wondering where everybody went.
That sounds pretty
impressive also.
What if people just change by themselves
or they want it by themselves.
Your say actually creates
some early successes
and if people see that
they want to move to that as well.
So another analogy
we’ve used is that
I just kind of run around an organization
with a blowtorch trying to set the grass alight
and
every now and then
we hit somewhere that is nice and dry
and eager to hear new ideas
and a fire takes off.
Other places nothing happens.
Well okay, fine. Just move on.
Concentrate on the areas where you are getting
a reception and get something going.
Get those proof points and then
later on you do have to
start addressing the areas of resistance
but if you’re already getting momentum
and if you’ve already got data and evidence
and proof points from within the organization
then you start going up the pole
to management going look do you want this or don’t you.
We need to work together to address
these other areas.
Yeah true.
Sounds really really good.
Now we’re talking about
I think half an hour about
your blog article
that sounds like a manifesto
against project management
and regarding the
DevOps philosophy.
So I think we should
minimize
projects and should build up
product teams.
The teams who deliver,
who build it, who run it.
What do you think about that?
I think we’re all familiar with the momentum
of projects that
I was just talking to
someone the other day about this
in the context of a very large project
where if you’re within
or even if you’re outside the organization
as a consultant, if there’s a whole lot
of money being sunk on a big project
then if somebody says
if somebody is a naysayer, if they say
oh look this isn’t going to work because
you’re just seen as
somebody who is trying to create a
self-fulfilling prophecy. You’re seen as somebody
who’s not on board, who’s actually working
counter to this important project.
And so you get the whole emperor’s
new clothes thing where everybody’s just
all smiling and nodding and saying how
fantastic this project is because nobody
wants to be seen to be the one
who’s
not supportive.
And so projects
just get this horrendous momentum
of their own.
There’s the sunk cost fallacy.
There’s the way they’re divorced from
customers so often
so the customers don’t even realize how off the
rails it’s going. All these things
are many different
causes but the pattern is that
projects get a life of their own.
I heard a wonderful story recently
about a project that had been
not killed off but just shut down
sort of put on ice and
then the organization discovered months later
that they were still paying a whole bunch of
vendors and consultants in the context of that
project and so while they thought it was
on hold they’d actually burnt the rest of the budget
for the project.
Which I thought was fun.
So, no, exactly.
And whereas the whole
premise of Agile is that you’re constantly
re-evaluating your assumptions, you’re
constantly re-evaluating whether or not you should
even do this thing and one of the
four options every time you evaluate
an iteration is to completely
abandon the
it’s continue,
deploy,
pivot or abandon, right?
Yeah, so now
honestly, because looking
now at Agile, because Agile
Manifesto, it’s 2001
and also I think
Scrum or other frameworks
are even older. If I
talk to developers they also say
yeah, we do that
actually since
a while already. So why is
it that now talking about
horses, why it took so
long until
they start
adopting, so not
only Agile but now also including
operations, so DevOps?
Well, actually
I don’t think it took very long. I think it only
took a decade or two. Okay.
Depends
on what you define longer.
Yeah, yeah.
You know, if we look at the rates of
how fast society can
change and how fast
whole industries can change,
then, you know, a
decade is not a long time.
And even though
technology is changing at a blinding
pace, it drives this fallacy in
thinking that individual
humans and teams and
organizations and industries and
societies can change at
the same pace. And they can’t. Humans change
at a remarkably
slow pace. I make the joke that we
have to wait for some people to die to see
change. Looking
at the watch, right?
Yeah, no, it’s
for me it was
very interesting, but I have no questions.
No more questions so far.
Thanks,
Alex, for that hint.
We should go to
come to an end for this podcast.
So thank you, Rob.
Thank you, IT Skeptic, for
having you here in our podcast.
Really the first one
in English. I hope it’s not
going to be the last one. And I
think thank you for your remarkable
ideas. Thank you for your
blog posting and all the things
you mentioned to
help us to build a better
IT, to make IT faster
and reliable, more reliable.
So thank you to have you here.
Oh, thank you. It’s been fun.
I’m happy to have been part of it.
Thank you for the opportunity. Yeah, thanks
also from my side. It was really a pleasure talking
to you.
Thank you.

Folge 11: Adaption des Spotify Modells bei Objectivity

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Diese Folge berichtet über die Erfahrungen bei der Adaption des Spotify Modells beim englisch-polnischen Softwareunternehmen Objectivity. In dieser Folge von „DevOps – auf die Ohren und ins Hirn“ sprechen Alex Lichtenberger und Dirk Söllner mit Thomas Lechmann von Objectivity über die Adaptation des Spotify-Modells in ihrem Unternehmen. Thomas beschreibt die Herausforderungen und Erfolge dieser Transformation, einschließlich der Reorganisation in Squads, Tribes, Chapters und Gilden. Er betont, wie das Modell Autonomie, Vertrauen und einen Fokus auf persönliche Verantwortung fördert, und diskutiert die Balance zwischen Autonomie und Standardisierung sowie die Bedeutung kontinuierlicher Anpassung und Verbesserung im Rahmen des Modells.

Inhalt

  • Vorstellung von Thomas Lechmann und Objectivity
  • Einführung des Spotify-Modells bei Objectivity
  • Herausforderungen bei der Implementierung des Modells
  • Struktur von Squads, Tribes, Chapters und Gilden
  • Balance zwischen Autonomie und Verantwortlichkeit
  • Entwicklung von Best Practices und deren Anwendung
  • Anpassung und Skalierung des Spotify-Modells
  • Zukunftspläne und kontinuierliche Verbesserung bei Objectivity

Shownotes

Objectivity Unternehmenswebseite: Objectivity

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.
Willkommen auch von meiner Seite. Mein Name ist Alex Lichtenberger und ich möchte ganz herzlich,
begrüssen heute den Thomas Lechmann von Objectivity.
Das Thema heute ist die Adaption des Spotify-Modells bei Objectivity.
Spotify, das ist ja zurzeit in aller Munde.
Viele Firmen lassen sich durch dieses Organisationsmodell inspirieren und auch Objectivity.
So da denke ich, haben wir heute ganz spannend zu erfahren, wie das bei Objectivity umgesetzt wurde.
Ja, Thomas, dann würde ich sagen, stell dich doch mal ganz kurz vor.
Also kannst du dich auch gerne länger vorstellen und sicherlich ist es auch interessant, von der Firma Objectivity etwas zu hören.
Wir werden es gleich an deiner deutschen Sprache merken.
Du sprichst deutsch, aber du bist kein Deutscher.
Also insofern bin ich gespannt, was du auch über Objectivity zu erzählen hast.
Ja, ich habe schon ein paar Wörter vorbereitet.
Also ich kann lesen.
Aber werde ich etwas.
Was dazu auch sagen, wenn ich es so machen kann.
Also ich heiße Thomas und ich arbeite für Objectivity seit fünf Jahren.
Also es ist mein sechstes Jahr jetzt und ich begann als PMO, so Project Management Office, wo ich habe Project Manager geholfen, das Projekt zu verwalten.
Und weil ich sammelte die nächsten Erfahrungen in Objectivity oder bei Objectivity.
Habe ich entscheidet, dass ich etwas anderes machen wollte und das eigentlich war möglich und ich habe meine Rolle verändern.
Ich ging in die Richtung der Service Management und eigentlich arbeite ich immer noch daran, also bei Service Management und was ich mag am meisten in meiner Arbeit ist die
Unberechenbarkeit.
Und was ich meine, ist, dass eigentlich jeder Tag.
Ist ein großes oder kleines, aber stets und immer Fragezeichen.
Man weiß nicht, was passieren wird.
Und das ist die Sache, die ich am meisten mag an meiner Arbeit.
Objectivity, also Firma Objectivity, die Firma wurde in 1991 in Coventry, das ist Großbritannien, gegründet.
Und seit.
Falls.
27 Jahren unterstützen wir unsere Kunden mit Softwareentwicklung, Support und Software Integration und Project Management nach circa 16, 16 Jahren, also in 2007 Firma hat entscheidet, das Entwicklungszentrum in Breslau gegründet.
Und wo heutzutage der Großteil unserer Mitarbeiter.
Arbeitet ich auch von Zeit zu Zeit gehe ich zu oder nach Großbritannien oder zu nach der Kunde für die, die ich arbeite und speziell in den letzten fünf Jahren hat sich die Firma enorm weiterentwickelt und vergrößert und das hat viele Veränderungen mitgebracht.
Und wir haben in den letzten vier Jahren, vier oder fünf Jahren die Mitarbeiter hier vierfach und jetzt haben wir circa eigentlich über 650 Mitarbeiter und wenn ich startete in 2012, dann wäre ich 140 oder 135.
Also jetzt haben wir viel mehr Leute.
Bei Objektivität.
Das klingt ja schon mal spannend, also Wandel ist die einzige Konstante, bevor wir ins Thema Spotify bei Objektivität gehen, die Frage, die wir allen unseren Gästen stellen, auch dir, Thomas, was, was verstehst du unter DevOps, bitte?
Also, wenn ich an die Antwort gedacht habe, habe ich mich entscheiden, um etwas.
Eigentlich ein paar, ein paar Satzen zu stellen und für mich als meiner Praxis jeder Tag.
DevOps ist am meisten die Fähigkeit, je nach Bedarf unterschiedlich und unterschiedliche Ressourcen einzusetzen.
Also alles hängt von den Umständen und Bedürfnissen ab und das Bedürfnis des Kunden wird vollständig bestimmt und immer.
Und für mich.
Der Schlüssel ist, die Anforderungen gut zu verstehen.
Das ist der Schlüssel, die mein, die die wichtigste und das erwartete Ergebnis zu liefern, also liefern, Ergebnis, das ist die wichtigste, wie ich ja, wie ich gesagt habe, also das ist, was ich verstehe unter DevOps.
Okay.
Jetzt hast du ja eben gesagt, dass ihr bei euch.
Ähm, entschieden habt, auch Dinge zu verändern, ähm, dass ihr auch gewachsen seid in, in Breslau und der Titel ist ja Adaption des Mod, äh, Spotify Modells bei Objectivity, also insofern dann mal die Frage, ähm, warum habt ihr euch denn entschieden, etwas zu verändern, also was waren die Treiber bei euch, ähm, etwas zu verändern?
Also zuerst, was ich, äh, über das, über das Spotify Modell sagen kann, ist, dass das Modell ist skalierbar.
Und wir wollten etwas ändern, weil so große Veränderung, so große, äh, Erwachsung, äh, äh, wir brauchen oder wir brauchten etwas Besonderes, äh, und etwas Neues für uns.
Und das Spotify Modell ist, äh, popular in der Welt eigentlich und, äh, es klappt für beide kleine und, äh, also, äh, große Kunden.
Ähm, und für, für die wir arbeiten und das Spotify Modell auch ermöglicht den horizontalen Austausch von Wissen und Menschen, äh, und das ist, was ich benutze, was wir benutzen, jeder Tag eigentlich.
Und in Spotify, äh, in meiner Meinung das Grundproblem oder die Grundsache ist die Autonomie eines Teams.
Und das ist, was ich sehe in meiner, in meiner Arbeit.
Also wir haben Teamen, die für die verschiedene Kunde arbeiten und die Teamen sind sehr autonomisch und die, äh, eigentlich entscheiden, was zu machen und wenn zu machen, um das, äh, um das, äh, Produkt für eine Kunde zu liefern.
Und, äh, die Kultur auch ist bekannt für ein hohes Maß und an, äh, Ermächtigung und Vertrauen.
Das ist auch wichtig, Vertrauen und ein Fokus auf Persönlichkeit.
Und, äh, ist für ihren Sieg für Zweck bekannt.
Also die Teams, die wir haben, sind voll befugt, befugt, äh, und ihre Mission zu erfüllen und die, äh, Freiheit auch, auch zu haben, äh, unbehängig zu handeln.
Und, äh, was ich meine, ist das das Beste und auch die, äh, schwierigste an der Arbeit für, äh.
Oder wenn wir arbeiten mit Spotify Modell, ist die Autonomie, also etwas, was ich, äh, gesagt, was ich schon gesagt habe, also Teamen, äh, die, die entscheiden, was zu machen und wenn zu machen.
Und es ist auch wichtig, äh, Spotifys Modell, äh, ist nicht, äh, in einer Organisation zu kopieren, also etwas, was wir schon gesagt haben, sondern die entsprechenden, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh.
Anpassung in, äh, Betracht zu ziehen, also vielleicht nicht Spotify bei Objectivity, aber das Modell, also am besten aus Spotify Modell für Objectivity, äh, und das Modell, äh, führt auch, äh, eine Aufleitung in Gruppen ein, äh, abhängig von den Kompetenzen oder der gemeinsamen Arbeit für ein Ziel oder und einen Kunden.
Ja, jetzt bist du ja schon ein bisschen in die Details eingegangen, ähm, wann habt ihr denn begonnen, euch an diesem Spotify Modell auszurichten, denn, ähm, mich würde nochmal ein bisschen interessieren, warum ihr euch verändern musstet, also, äh, sind euch Kunden abgesprungen, waren Kunden unzufrieden, äh, oder habt ihr euer Wachstum nicht mit dem, mit den alten, ähm, Abläufen, mit den alten, ähm, ähm, ja, mit der alten, mit der alten Aufbauorganisation hinbekommen, also warum musstet ihr euch verändern?
Weil das Modell, die wir, äh, früher haben, war nicht, äh, gut, äh, also die, eine Minute, also die Leute, die hier arbeiten, die hatten, äh, eigene Gewohnheiten und weil, äh, wir haben sich entwickelt und vergrößert als Firma, die waren nie, äh,
nie mehr, ähm, aktuell, vielleicht kann ich so sagen, aktuell, also wir, wir haben entscheidet, dass wir etwas anderes, äh, äh, versuchen müssen.
War das dann auch ein Effekt, du hast ganz zu Anfang erwähnt, war ein starkes Wachstum und das ja klassische, oder wenn man ja noch ganz klein ist als Firma, kann auch sehr gut zusammenarbeiten, man kann gemeinsam als, als Team auf den Kunden fokussiert und war es dann, dass ihr auch aufgrund,
äh, des Wachstums dann vielleicht eine gewisse, äh, Siloisierung stattgefunden hat und das, so wie auch jetzt, äh, Dirk gesagt hat, dass da ein bisschen der Kunde aus den Augen gegangen ist, äh, kann man, kann man das so beschreiben?
Und noch besser zu verstehen wirklich die Treiber, äh, das, das Warum, warum musstet ihr was ändern, äh?
Also das, das war, das war auch etwas, äh, was, äh, kommt Interessantes von, mit, mit, mit, äh, Spotify Modell.
Also, äh, was du gesagt hast, also Treiben, Gilden, Squads, äh, das ist, das ist alles, was macht, äh, ein Team und dann das, äh, auch, äh, macht das Team zu, äh, autonomisch zu sein eigentlich.
Okay, okay, gut. Gut, also da, äh, was mir da sehr gut gefällt, du hast das, äh, erwähnt auch, äh, ihr habt, äh, viele Firmen, die sehen, es gibt ja diese berühmten,
äh, Spotify Videos auf YouTube, äh, die heissen, äh, Spotify Engineering Culture und dann kopieren die Firmen das einfach eins zu eins, aber das habt ihr ja nicht gemacht, ihr habt das, äh, adaptiert auf eure Bedürfnisse, auch habe ich verstanden, aus dem Bedürfnis zu, äh, skalieren, oder, dass ihr ein bisschen Manko achtet, wenn das traditionelle, agile Modell, das ihr auf das Team auskriegt, aber was ist, wenn man das, äh, man muss ja auch zwischen Teams abstimmen und dann, du hast erwähnt danach,
äh, auch, äh, die Begriffe Squads und Tribe, glaube ich auch, das ist ja auch etwas, das so ein bisschen von Spotify kommt, was, was habt ihr da genau gemacht, wie habt ihr euch da organisiert oder euch inspirieren lassen von Spotify?
Ja, also Spotify gibt dir ein Framework und das ist, was ich, was wir benutzen haben und wir haben das mit den besten Software-Praktiken kombiniert und, äh, Treiben und Gildien,
äh,
das haben wir auch, äh, gebracht und Squads, also, äh, Treiben, die, die, die, die wir, äh, haben und das, das, das sind die größten Teams auf, äh, Leuten, die verschiedene Kompetitionen haben und dann arbeiten, also, das ist ein großer Team, das, das, das arbeitet für ein, für eine Kunde, das ist, was wir Tribe nennen und dann haben wir auch, äh, Gildien, Gildien, die sind die, äh, Teams, die, äh,
wo Leute mit, äh, selben Kompetitionen sind und dann Squad, das ist eigentlich ein Team, äh, mit verschiedenen Leuten, die, äh, die liefert für einen Kunden, das kannst du, das, das können wir so nennen.
Ja, fangen wir vielleicht dort, oder, weil der Squad, auch wenn man sich das Video anschaut, der Squad ist eigentlich so die, die Grundeinheit, eben das selbstorganisierte Team, you build it, you own it, wie, wie habt ihr da, was ist bei euch?
squad wo hängt ihr das auf was ist die verantwortung wie sind die zusammengesetzt
also was gott macht macht ist die
eigentlich denn den service oder das produkt würde ich jetzt bei der service und produkt
weil wir auch support team haben und das in support kaufst du auch squad haben und dann
squad kein kann ein produkt machen oder auch ein service das ist was das ist wie ich es bei
objektivität aussieht als ihr damals begonnen habt mit spotify also mit dem modell das für
euch zu adaptieren wie viele mitarbeiter warte den zu den damen damaligen zeit es war in 2000
und
14 also es war ca 200 ok 2014 mit 200 mitarbeiter wenn ich das jetzt mal
ich muss ein von antworten ja thomas du hast es gesagt jeden tag neue überraschungen und das
war eben kunden anruft das heißt wir fangen mal wieder an den kunden in den mittelpunkt
zu stellen und müssen und podcast aufnahme dann da fortsetzen wo wir eben aufgehört hatten meine
frage war zu und mitarbeiter habt ihr zu der zeit damals gehabt als euch entschieden habt
für spotify für die adaption des modells habt ihr das ganze dann quasi in einem
großen rundum schlag eingeführt oder oder adaptiert oder habt ihr einzelne teams nach
und nach aufgebaut also wir haben das mit einem big bang gemacht es waren es war ein riesiges
risiko aber stets so haben wir das so haben wir entscheiden und so haben wir das gemacht und es
es war eigentlich gut und von meiner meinung es war auch in sehr interessant in das teil
zu nehmen und das war in 2014 wenn wir das modell adaptieren starten
das insofern spannend auch dass ihr könnt euch vielleicht noch erinnern werden der letzte podcast
war damit martin thalmann von swiss kommt die haben auch sich am spotify modell angelehnt die
haben die ersten evolution
bei euch habe ich verstanden so big bang am schluss muss es natürlich auch passend für
euch hat das offensichtlich so gepasst was waren dann also dann also big bang habt ihr
wirklich im neuen setup wohl gesagt okay das sind die produkte services sind die teams die
squats sie dahinter seht ihr habt die schon die chapters et cetera habt ihr das alles zum
vornherein
das dauert das dauert eigentlich ein paar wochen monaten und man kann man kann man weiß dass die
einführung einer so großen veränderung weil das war eine große veränderung steht vor einem
widerstand aber wie ich gesagt habe das war ein big ein großer challenge aber es war
auch sehr interessant und ich glaube dass wir dass wir das gut gemacht haben und es weil was steht
dafür ist dass immer mehr und mehr leute nach objektivität kommen und auch bei kunden ok also
kunden und mitarbeiter auch oder ja genau
also mitarbeiter das dass ich was was ich leute gesagt habe und kunden auch ja okay aber das ist
glaube ich für mich also wenn ich in den schulungen bin immer auch ein argument den den teilnehmern
klarzumachen es geht nicht nur darum die kunden zufrieden zu stellen mit einer neuen organisation
mit einer neuen art zu arbeiten sondern auch die attraktivität als arbeitgeber zu heben an der
stelle und sofern finde ich es gut wenn ihr da auch die praktischen ergebnisse damit habt also
wirklich wenn ihr sagen könnt für
wir sind als arbeitgeber attraktiver geworden weil wir anders arbeiten als vielleicht vor weiß ich nicht
zehn oder 15 jahren der fall war du hast gesagt ist auch eine große herausforderung ist eine große
veränderung was war denn so aus deiner sicht im rückblick was man die größten hemmnisse also wo
kamen die größten widerstände und wie seid ihr damit umgegangen also von meiner perspektive und
wie ich es
wie ich es
wie ich es
sehe und wo sich also die die größte war also ich habe ein beispiel eigentlich also jetzt arbeiten
wir in tribes und und chapters und das war hier nicht bevor und das war eine größe veränderung
auch und die was fast was der schlüssel hier ist ist dass die die mitarbeiter und die leute dass das
dass wir objektiv arbeiten die werden hier von drei master oder chapter leaders unter unterstützt
und für mich ist es eigentlich sehr interessant weil ich kann weil wenn ich wenn ich wenn ich
brauche ein kompetition die ich nicht habe oder ich brauche jemand das hat das das hat etwas
eigentlich ist etwas neues dann kann ich versuchen mit der gilt oder mit mit anderen treiben zu
solche kompetenzen zu suchen und dann bin ich jemanden gefunden hat dann kann ich versuchen
diese kompetenzen zu versuchen bei bei oder für die kunde die ich arbeite für und als ich
verstehe weil die frage von von dirk war ebenso herausforderungen challenge aber ich verstehe
auch dass eigentlich die ganze organisation war dem ganzen sehr positiv eingestellt ist
es richtig dass damals sagt ja machen wir wir wollen die veränderung richtig von meiner also
ja ich glaube dass das wichtig ist dass ich das ist meine meinung was mich da noch interessieren
würde wird das ja erwähnt da gab es neue rollen die ihre eingeführt hat so squat stripe tief und
ich hatte auch letzten die erfahrung das was im workshop in der abteilung das war mit dem
management haben wir auch solche strukturen definiert neue rollen agile coach und plötzlich
so was passiert jetzt eigentlich mit uns braucht es uns überhaupt noch also das vielleicht auch
weil ihr hattet ja früher auch gab es vielleicht die klassischen chefs was ist damit den passiert
kam da nicht auch widerstand oder habe die das als chance gesehen die sind aber stets mit stets
mit uns aber die rollen nehmen sich anders jetzt ja und die die klassische struktur ist nie hier
es gibt ein struktur weil es wurde nicht klappen ohne ein struktur also es gibt leaders die
mitarbeiter unterstützen man nennt die nicht chefs vielleicht ja aber die sind stets mit uns
und und jeden tag die also es gibt wieder welche die die die mitarbeiter unterstützen und damit
sie ihren tag das beste aus ihren fähigkeiten rausholen sorry dass ich zwischenfrage sind
das weil die leute jetzt bezug zum spotify ist das sind dass die chapters dann chapter
leads oder chapter leads oder guild masters auch weil in in chapter oder in guilds haben
sie haben wir eigentlich leuten die dieselbe kompetition haben also
es ist chapter leaders oder guild masters das ist die rolle für die leute die weit so das spotify
modell nicht so können wir haben die eine grundidee senkt dies quatsch es sind nicht autonome teams
die verantwortliche produkte übernehmen damit in jedem team haben ein ähnlicher rollen habe
jetzt zum beispiel produkt auch
Und ja, die Idee ist ja dann vom Spotify-Modell, okay, jetzt machen wir halt, nehmen wir alle Produkt-Owner zusammen, die können dann gemeinsam ihre Kompetenz weiterentwickeln.
Und das ist dann der Chapter. Und wenn es mehr informal ist, ist es dann die Gilde.
Die Gilde, die haben typischerweise dann so informelle Mailing-Listen an Conferences etc.
Habt ihr das auch so umgesetzt oder wie habt ihr euch das umgesetzt?
Sehr ähnlich eigentlich. Also wir haben auch verschiedene Rollen, die in einem Squad sind.
Wir haben Developers, wir haben Testers, wir haben Business-Analysts, wir haben Scrum-Masters auch.
Und die sind alle verschiedene Rollen, die in einem Squad sind.
Und dann hast du die, oder eigentlich haben wir ein Team, das sich verschiedene Leute vorstellt.
Und dann…
Die alle haben seine Gilden oder seine Chapters, wo sie verschiedene Kompetenzen verwählen, ich meine, Exchange.
Also die können mit den Leuten, die dieselbe Kompetenz haben, in Kontakt gehen.
Ja, das ist ja ganz, ganz wichtig, dass man trotz der Autonomie…
Ja, das ist ja ganz, ganz wichtig, dass man trotz der Autonomie in den Teams den Austausch fördert, sei es informell, sei es auch, wenn auch vielleicht gemeinsam, ja, sagen wir, Dinge beschlossen werden müssen, die dann für alle zugehörigen Squads dann auch gelten.
Ja.
Wir hatten ja beim letzten Mal, Alex hat es schon angesprochen, den Martin Thalmann, und da war auch ein wichtiger Punkt für die Swisscom, wie sie ihr Alignment hinbekommen haben.
Und das ist ja manchmal auch ein Problem, wenn man zu sehr…
Wenn man zu sehr in Richtung Autonomie geht, dass so ein gewisses Alignment fehlt, das heißt die Ausrichtung auf das Unternehmen und so weiter.
Also wie schafft ihr das, dass ihr trotz Autonomie auch schon mit zentralen Vorgaben arbeitet, dass die Teams trotzdem, ich sag mal, ein Alignment hinbekommen?
Ja, also es ist nicht einfach eigentlich, den Spagat zu finden zwischen der Autonomie und der Verantwortlichkeit.
Also wir geben so viel Macht und Verantwortung wie möglich zu unseren Menschen, unseren Mitarbeitern, aber es ist doch auch wichtig, die Verantwortung, wie ich gesagt habe, nicht zu vergessen.
Also du hast etwas zu machen, du hast Tasks und du musst wissen, dass du die…
Liefern musst.
Also es gibt Termine, also es ist Autonomie, aber es gibt auch Termine und die Verantwortlichkeit.
Und das ist hier die Rolle der Gildie, Best Practices zu entwickeln und auch diese Best Practices zu zeigen.
Also wenn jemand Neues ist oder wenn jemand Fragen hat oder wenn jemand Probleme hat, dann…
Kannst du oder können wir mit der Gildie in Kontakt zu gehen und dann die Best Practices zu erwarten.
Und die Gildie hilft in solchen, mit solchen Problemen.
Also der Squad kann quasi dann…
Da gab es ja nochmal ein Telefon, aber ich denke, jetzt können wir weitermachen.
Ich möchte noch kurz nachdenken.
Nachhacken, weil wir haben jetzt darüber gesprochen, so Alignment versus Autonomie.
Und wenn man das Spotify anschaut, wie das Handhaben, die haben dann schon eine sehr, ich würde sagen, nicht einseitige, aber sehr, sehr spezielle Ansicht.
Zum Beispiel, wenn es um Standardisierung geht, sagen sie, es dürfen keine Standards vorgegeben werden, sondern das ist in der Autonomie des Teams.
Und dann ist so der Path of Least Resistance, sagen sie.
Ja, quasi das.
Das, was sich dann durchsetzt, also wenn ein zum Beispiel Tool sehr erfolgreich ist im Team, die anderen Teams sehen das, dann adaptieren das automatisch und das wird dann wie ein de facto Standard.
Also wie geht ihr mit dem um, wenn es jetzt um das Thema Standardisierung Tools, aber auch Prozesse geht?
Habt ihr da auch so diesen Weg eingeschlagen oder wie macht ihr das?
Auf einer Seite muss man sagen, dass die, dass die Standards und Prozesse hier sein müssen.
Weil ich bin der Meinung, dass ohne Prozesse und ohne Standarde kann man eigentlich nichts erreichen oder ist es wirklich schwer.
Und an der anderen Seite haben sie oder haben wir Teams, die Autonomie haben.
Also wie kann man diesen Teams Standards geben?
Dann haben sie doch keine Autonomie, kann man sagen.
Aber die, die, die, die, die größte, die größte Challenge oder die größte.
Schwierigkeit ist die, ist die, den goldenen Mittel zu finden.
Also von meiner Meinung, die Autonomie muss sein, aber es müssen doch auch Sondern Standarde oder Prozesse sein, weil oder die oder oder oder diese Prozesse.
So, da hatten wir schon wieder mal den Kunden am Rohr, am Telefon.
Insofern die nächste Frage schließt sich da vielleicht gerade an.
Thomas, du hast vorhin gesagt, ihr habt euch für Spotify entschieden für das Modell, weil es sich sehr schön skalieren lässt.
Wenn ich mir jetzt vergleichbare Unternehmen von der Größe angucke, so 600 bis 650 Entwickler, hast du ja gesagt, seid ihr.
Da sind häufig Unternehmen dabei, die mit Skalierungs Frameworks arbeiten, Save oder was es da alles noch so gibt.
Meine Frage wäre also, skaliert ihr quasi mit diesen vielen Entwicklern wirklich nur aus Spotify heraus oder nutzt ihr noch andere?
Methoden, andere Frameworks, um so viele Personen wirklich unter einen Hut zu bekommen?
Also wir haben das Spotify Modell adaptiert für uns, aber das bedeutet nicht, dass wir, dass wir vielleicht begrenzt ist.
Das ist nicht das beste Wort, aber das ist, was das ist, was ich meine.
Also wenn wir entscheiden, dass das Modell ändern muss, dann werden wir das noch einmal adaptieren.
Oder wenn wir entscheiden, dass.
Wir etwas Neues, anderes und besser für uns sehen, dann vielleicht können wir auch etwas anderes zu adaptieren, entscheiden zu adaptieren.
Also von meiner Perspektive, von meiner Meinung, es.
Es funktioniert gut, aber was die Zukunft bringt, dann wissen wir jetzt nicht.
Dann werden wir sehen und wir sind.
Flexi, also wenn wir etwas ändern muss, dann werden wir das ändern.
Das, das klingt doch sehr vernünftig, würde ich sagen.
Wenn ich, wenn ich jetzt zurückblicke, wir haben ja am Anfang ein bisschen über die Treiber gesprochen.
Oder warum wolltet ihr eine Veränderung?
Und, und dann habt ihr gesehen, ja, Spotify, das bietet eigentlich eine gute, gute Inspiration.
Und die habt es nicht einfach kopiert.
ihr habt für euch adaptiert ihr habt ihr nach wie du jetzt gesagt der vernünftige ansatz ja
halt regelmäßig schauen passt das noch wenn nicht müssen wir anpassen wir haben noch ein
bisschen darüber gesprochen er hat diese konstrukte wie squat und frei wir hat das
adaptiert ihr habt dann chapter und gilden strukturen drüber gelegt und es funktioniert
grundsätzlich gut meine frage wäre so und ich denke das wird vermutlich jetzt ein bisschen
kürzer podcast ja ausblick was wie geht es dann so so weiter und ein bisschen hast du die frage
auch schon beantwortet also für mich das ist etwas das ich schon erfahren hat also in die
vergangenheit habe ich eine
andere rolle als jetzt also für die zukunft die ausblick für mich das bedeutet dass die
leute die bei objectivity arbeiten die können entscheiden ob sie ob sie etwas anderes machen
wollen oder ob sie für die für die für dieselben kunden arbeiten wollen für mich das ist die
möglichkeit um etwas zu ändern wenn man solche brauche hat
also es für mich das bedeutet dass wenn du etwas ändern wolltest dann kannst du das bei
objectivity machen du musst nicht eine andere firma zu suchen weil objectivity so flexi ist
und es gibt ein chance etwas zu ändern wenn du willst also für die zukunft wir haben das modell
jetzt spotify modell und für mich es funktioniert gut und ich hatte eine option etwas zu ändern wenn
ich wenn ich wollte das machen und das ist für mich das ist der grund das ist der schlüssel dass
wenn man sich entscheidet dass er oder sie etwas machen wollte dann kannst du das entscheiden kannst
du das machen
gut ja ich glaube dann sind wir am ende dieses podcast ich bin gespannt wie der nachher wenn
wir das zusammengeschnitten haben klingt das war sicherlich mal ein sehr interessanter podcast von
der aufnahme her und ich hoffe dass war da auch für die zuhörer genug an informationen
rübergebracht haben also ich sage an dieser stelle mal auf wiederhören und vielen dank thomas dass
du für uns hier ja als als redner zur verfügung gestellt
gestanden hast als gesprächspartner von mir auf wiedersehen
ja sehr gerne euch beide zu zu sprechen danke auch von meiner seite

Folge 10: Digitale Transformation bei der SwissCom

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

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 은

Folge 9: DevOps Missverständnisse

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode von „DevOps auf die Ohren und ins Hirn“ diskutieren Alex Lichtenberger und Dierk Söllner sechs häufige Missverständnisse über DevOps. Sie erklären, dass DevOps weder ein neues Framework ist noch die agile Produktentwicklung ersetzt, sondern diese ergänzt und sich gut in das IT-Service-Management einfügt. Die Rolle des IT-Betriebs wird durch DevOps verändert, aber nicht überflüssig gemacht, und obwohl Automation ein wesentlicher Bestandteil von DevOps ist, geht es dabei um mehr als nur „Everything as Code“. Zudem klären sie, dass Entwickler keinen direkten Zugriff auf Produktionsumgebungen haben, sondern der Prozess hochautomatisiert und kontrolliert abläuft.

Inhalt

  • DevOps als Philosophie, nicht als Framework
  • Verhältnis von DevOps zur agilen Produktentwicklung
  • Kompatibilität von DevOps mit IT-Service-Management
  • Die Rolle von Operations in DevOps und das Konzept von NoOps und NewOps
  • Bedeutung der Automation in DevOps und darüber hinausgehende Aspekte
  • Missverständnis über Entwickler mit direktem Zugriff auf die Produktion
  • Verschiedene DevOps-Praktiken und -Prinzipien

Shownotes

  1. DevOps Days: devopsdays.org
  2. ITIL (IT Infrastructure Library) für IT-Service-Management: ITIL
  3. Scrum als agiles Framework: Scrum Guide
  4. Scaled Agile Framework (SAFe): Scaled Agile Framework

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 Alex Lichtenberger.
Ich begrüsse die Zuhörer und Abonnenten auch im Namen von Dirk Söllner.
Der sich dann gleich vorstellen wird.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir sprechen alle DevOps-Interessierten an, die mit dem Medium Podcast etwas anfangen können
und gerne etwas dazu hören, sei es beim Autofahren, im Zug oder abends im Hotel oder zu Hause.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern.
Die in DevOps enthalten sind.
Mit diesem Podcast sollen die Hörer und Hörerinnen das vielleicht etwas schwammige Thema DevOps besser verstehen und auch erklären können.
Wir liefern Vorschläge, Konzepte und Interviews mit Experten und Praktikern,
damit sie persönlich durchblicken und ihr Unternehmen erfolgreicher machen können.
Heute machen wir wieder mal einen Podcast zu zweit, ohne externen Gast.
Das heisst dieses Mal nur Dirk und ich.
Nun zum Thema vom heutigen Podcast, das ist inzwischen der neunte Podcast, DevOps-Missverständnisse.
DevOps ist ja schon seit fünf bis sechs Jahren geprägt, dass ja kein Framework ist, kodifiziert.
Jeder versteht ja auch ein bisschen was anderes darunter und entsprechend gibt es ja sehr viele Missverständnisse.
Als Beispiel.
DevOps ersetzt die agile Produktentwicklung oder DevOps macht den IT-Betrieb überflüssig.
NoOps oder DevOps ist ein neues Framework.
Das sind so Punkte, die der Dirk und ich, wir haben uns das mal aufgelistet, auch aus unserer Praxis, aus Beratung und Schulung, was wir so aufschnappen.
Ja, und wir wollen diese Missverständnisse mal durchgehen und auch vielleicht einen oder anderen missverständlich.
Ja, bevor wir da jetzt mit mal one-by-one durchgehen, vielleicht noch kurz Dirk, willst du auch noch was kurz sagen?
Ja, Alex, vielen Dank für die Einleitung. Ich will kurz was sagen, vielleicht auch ein bisschen länger nachher zu den fachlichen Themen.
Ja, Dirk Sönder ist mein Name. Ich stelle mich jetzt auch ruhig auch nochmal vor, weil wir ja doch mehr Zuhörer bekommen und auch Zuhörer bekommen, die uns, die mich und dich, Alex, auch noch gar nicht so aus der Praxis kennen.
Also insofern.
Dirk Sönder. Ich betreibe verschiedene Webseiten. Eine unter anderem die Webseite devops.de, also mit zwei Dees, wo auch dieser Podcast dann verfügbar ist.
Mittlerweile haben wir ihn ja auch bei iTunes platzieren können. Also auch die hohen Weihen der bekannten Podcast-Portale haben wir ja dann geschafft.
Und insofern kriegen wir auch Rückmeldungen und ich wollte die Chance heute mal nutzen, mich auch bei den verschiedenen Rückmeldungen zu bedanken.
Bei den Hinweisen, wo Leute aufhören.
Wo wir etwas verbessert haben, wo wir also schon Dinge verändert haben und mit den kleinen oder auch größeren Tipps, sodass wir den Podcast immer mehr auch an die Wünsche und Anforderungen der Zuhörer anpassen können.
Also insofern einen vielen Dank oder einen herzlichen Dank an die Zuhörer und an die Abonnenten.
Gut, vielen Dank, Dirk. Dann legen wir mal los, deine unsere wunderbaren Liste.
Da haben wir als erstes, sehe ich, DevOps ist ein neues Framework. Dirk, was meinst du?
Ja, ist ja wirklich ein interessantes Missverständnis aus meiner Sicht.
Ich könnte mir vorstellen, dass das von dem einen oder anderen Hersteller oder Anbieter von Schulungen unter diesem Stichwort quasi verkauft wird.
Aber für mich ist das eben kein neues Framework.
Das macht es für mich auch so interessant, diese Sichtweise, dass es eben kein neues Framework ist, weil ich glaube, dass wir schon genug Frameworks haben.
Die muss ich jetzt nicht alle aufzählen. Wir wollen auch die Namen nicht alle nennen.
Also ich glaube, dass wir genug Frameworks haben. Wir haben genug Wissen.
Wir haben genug Wissen aufgeschrieben. Wir haben genug Wissen in der Praxis.
Wir müssten jetzt nur einfach mal drangehen, das in der Praxis umzusetzen, das, was an Wissen da ist, was an beschriebenen Frameworks da ist.
Und deswegen glaube ich, dass es eben kein neues Framework ist.
Ich sehe es jedenfalls nicht als ein Framework. Ich sehe es als etwas, was so Best Practice ist, dass die Unternehmen ihr eigenes Best Practice ermitteln.
Die Welt wird immer komplexer. Das heißt, aus meiner Sicht könnte auch überhaupt, wenn wir ein Framework hätten,
ein Framework allein kann meiner Meinung nach die Komplexität, die wir haben und die ja stetig zunimmt, gar nicht mehr abdecken.
Das heißt, wenn ich sage, es ist für mich kein neues Framework, heißt es für mich, ich kombiniere verschiedene Dinge.
Ich glaube, das haben wir auch immer schon mal wieder dargestellt. Das zeigt sich auch bei unseren Gästen.
Wir haben ein bisschen IT-Service-Management drin, repräsentiert durch ITIL.
Wir haben ein bisschen Agilität drin, durch Scrum unter anderem repräsentiert.
Und wir haben Lean-Management drin mit Kaizen.
Das heißt, die verschiedenen Frameworks und Ansätze, die es gibt, die kombinieren wir einfach nur.
Und vielleicht noch der letzte Punkt aus meiner Sicht jetzt für diesen ersten Einstieg in dieses Missverständnis.
Ich denke auch, dass DevOps etwas ist, was man in der Praxis umsetzen muss, was man erfahren und erlernen muss.
Es hilft nicht, irgendeinen Best-Practice-Ansatz zu haben und den sozusagen nur zu kopieren.
Ich glaube, das ist zum Beispiel etwas, wo…
Wo ITIL auch Schwierigkeiten hervorgerufen hat, wenn ein Unternehmen nur auf die Idee kommt, das zu kopieren.
Es spricht nichts dagegen, von Best-Practice-Ansätzen zu lernen, genauso wie ich von anderen Unternehmen lernen kann.
Also lernen ja als Best-Practice, aber eben das Wichtigste ist, man darf nicht kopieren, meiner Meinung nach.
Und deswegen halte ich es eben nicht für ein Framework, sondern einfach eine Philosophie.
Ja, also da sehe ich eigentlich genau gleich wie du.
Und das ist ja auch eben das Problem.
Mit dem Wort Framework oder auch Best-Practices.
Ich würde DevOps auch eher als Bewegung ansehen und als Emerging-Practices.
Sehr stark wird das ja geprägt durch die verschiedenen DevOps-Events, sei es die DevOps-Days, DevOps-Meetups, die ja inzwischen auf der ganzen Welt stattfinden.
Und wo halt wirklich, wie du sagst, auch aus der Praxis heraus neue Ideen…
Das sind eher so Emerging-Practices.
Ja, die kommen, die dann die Philosophie von DevOps unterstützen.
Und schlussendlich bewährt sich auch das, was Erfolg hat.
Und dann eben das Schöne, wie dann die verschiedenen Dinge dann zusammengebracht werden.
Elemente aus Agile, Lean und Service-Management und anderen.
Und in zwei Jahren schaut dann DevOps wahrscheinlich wieder anders aus, wie es heute ausschaut.
Das macht für mich persönlich jetzt auch den Reiz aus.
Ja, wahrscheinlich ist auch die Frage…
Ob man es überhaupt jemals mit einem Snapshot beschreiben kann.
Wenn es immer in Bewegung ist, dann ändert es sich ja auch.
Und ich glaube auch, das zeigen so meine Diskussionen, dass jedes Unternehmen das ein bisschen anders für sich sieht.
Ich habe in meinen Schulungen, da legen wir ja Wert auf der einen Seite auf Kultur, aber auch auf Automation.
Also zwei grundsätzlich unterschiedliche Bereiche.
Und dann gibt es Schulungsteilnehmer, die beschweren sich, dass wir viel zu viel über Kultur sprechen.
Das Ganze wäre ja…
Da gibt es sehr viel Automation.
Und dann gibt es welche, die genau das Gegenteil sagen.
Die also sagen, hey, ihr habt super toll die Kultur drin.
Hebt hervor, was Kultur bedeutet.
Automation, das kann ja im Prinzip jeder.
Da rede ich über irgendwelche Tools.
Also auch die Sichtweise der Teilnehmer, der Schulungsteilnehmer in diesem Falle, ist total unterschiedlich.
Und das finde ich eben schön, wenn man damit umzugehen weiß.
Ich weiß natürlich auch, dass es schwierig ist, im Unternehmen eine Richtung vorzugeben,
wenn man quasi kein klares Ziel hat.
Ich glaube, es wäre ein schlechter Rat, das Ziel quasi, das fehlende Ziel zu ersetzen,
indem man einfach blind eben ein Framework kopiert, was auf ganz vielen Seiten beschrieben ist.
Man muss einfach probieren, man muss immer wieder anpassen.
Und wie gesagt, die aktuelle Zeit ist heute so komplex.
Die Herausforderungen sind so unterschiedlich, dass ich eben auch im Unternehmen mich immer wieder anpassen muss.
Ja, dann wollen wir uns mal den nächsten auf der Liste anschauen.
Was denkst du?
Können wir machen.
Ich bin bereit.
Aber du bist ja dran, ne?
Ja, genau, ich bin dran.
Dann schaue ich mal da.
DevOps ersetzt agile Produktentwicklung.
Ja, auch ein weit verbreitetes Missverständnis.
Ja, das Problem ist wahrscheinlich mit dem Wort ersetzt.
Ich würde eher sagen, DevOps erweitert oder ergänzt die agile Produktentwicklung.
Weil agile Produktentwicklung ursprünglich natürlich aus dem Dev, aus dem Development raus,
inzwischen auch nicht schon in die Jahre gekommen, kann man sagen.
Agiles Manifest 2001, Scrum, Kanban, eigentlich noch älter.
Und wenn man so die Entwicklung anschaut, also die 90er Jahre, da hat man ja typischerweise noch wasserfallmässig Projekte abgewickelt.
So Projekte sind dann gut und gerne zwei, drei Jahre.
Und dann sind eben die Entwickler, die haben dann zuerst den Move gemacht, haben gesagt, ja, wir müssen da, wenn jetzt mal die Konkurrenz das gleiche in einem halben Jahr macht, da haben sie angefangen auf agil umzustellen.
Aber eben agil selber, beispielsweise auch in der Umsetzung dann mit Scrum, ist ja nicht ausreichend, wenn das ganze System ja nicht erlaubt,
dass man beispielsweise alle zwei.
Wochen oder häufiger effektiv mit dem Produkt und mit dem Service live gehen kann.
Und aus dem raus hat sich ja dann ganz natürlich hat sich eigentlich DevOps entwickelt.
DevOps als natürliche Weiterentwicklung von agil, dass man zum Beispiel sagt, ja, man versucht zu mehr zu automatisieren, auch so die Qualität zu steigen, indem man beispielsweise Tests automatisiert,
indem.
Man früher auch Operations im im Zyklus reinholt dann und das hat schlussendlich hat das die ganze agile Entwicklung bereichert, indem dann halt auch die Qualität gestiegen ist.
Also auch wenn man, denke ich, mit Leuten aus der agilen Welt, die schon seit seit langer Zeit im agilen Umfeld arbeiten, die sagen, ich hab’s wahrscheinlich auch letztes Mal eine Daten Startup gegründet, schon vor x Jahren über DevOps.
Ja.
Ja.
Ja.
Ja.
Und da hat er gesagt, ja, okay, DevOps sagt ihr dem.
Ja, wir machen das schon seit 15 Jahren.
Das ist jetzt natürlich so die die Sicht der agilen.
Na und jetzt gibt natürlich aus Operations Sicht auch oder, dass sich die dann ich denke sich dann Richtung Agilität entwickeln können und was auch noch dazu.
Ich denke auch klassische Phasen, wenn man jetzt Phasen mäßig, Wasserfall mässig vor geht.
Kann man ja auch von automatisieren,
und von dem kulturellen Change von DevOps profitieren.
Was deshalb ersetzen, denke ich, ist das falsche Wort.
Es ist eher, würde ich sagen, es bereichert, ergänzt die agile Produktentwicklung.
Ja, da würde ich dir zustimmen.
Dieses Wort ersetzen ist wahrscheinlich das, was so am meisten stört
oder was einem sofort ins Auge springt.
Ich würde es auch sehen.
Es ist eine Art Fortsetzung, es ist eine Erweiterung,
dass ich die agilen Teams eben erweitere, dass ich die agile Arbeit erweitere.
Und natürlich ist viel Agilität in DevOps drin, aber eben nicht alles.
Und das finde ich eben auch wichtig, immer wieder zu betonen.
Sonst könnte man ja sagen, okay, ich nehme irgendein agiles Produktentwicklungsteam,
packe da so ein, zwei Betriebsleute mit dazu und dann habe ich ja schon DevOps.
Das wäre ja eben auch etwas zu kurz gesprungen.
Also insofern ist für mich eben auch wichtig, nochmal zu sagen,
dass wir da auch schon viel IT-Service-Management drin haben.
Das hören vielleicht die agilen Entwickler nicht so gerne.
Und wir haben auch wirklich viel Lieblingsarbeit.
Lean drin, Lean-Management.
Und auch da, denke ich, sind viele wichtige Aspekte,
die einfach das Ganze ergänzen an der Stelle.
Also insofern habe ich immer wieder gesagt,
agil, Lean und IT-Service-Management.
Und vor allen Dingen, es ersetzt eben dann nicht die Produktentwicklung,
sondern es bereichert das.
Ja, der Gene Kim hat ja mal schön gesagt,
es braucht Entwickler, die so denken können wie Operation-Leute
und Operation-Leute, die so denken können wie Entwickler.
Es bereichert dann auf beide Seiten.
Ja, und wenn man jetzt mal überlegt, die agile Produktentwicklung,
also wenn wir das mit Scrum mal gleichsetzen,
ist schon interessant, wie ich finde, in dem aktuellen Scrum-Guide 2017,
da wird schon mehr auf DevOps und auf Automation und andere Themen hingewiesen.
Das heißt also, da haben Jeff und Ken schon so ein bisschen mehr den Blick
auch auf das, was aktuell sich quasi am Markt tut,
mit Ansätzen, eben nicht mit Frameworks, aber mit Ansätzen.
Genau.
Und insofern,
denke ich, gibt es auch ganz wichtige Dinge, die aus der Agilität kommen,
die aus dem Scrum kommen.
Wenn wir einfach mal schauen, bei Scrum haben wir ja potenziell auslieferbare Produktinkremente.
Ein richtig schön sperriger Begriff, der auch nicht immer einfach zu erklären ist.
Aber aus Sicht von DevOps ist es für mich ganz einfach.
Das, was die Scrum-Teams liefern, das liefern sie jetzt eben nicht in irgendeine Testumgebung,
sondern sie liefern es in die Produktivumgebung.
Also, ich sage mal, verbal gesehen nur ein kleiner Schritt,
aber inhaltlich ist es natürlich dann viel.
Ich bin mit dabei, um quasi bis in die Produktivumgebung zu liefern als Team an der Stelle.
Also, das ist, was du auch sagtest, es ist die Fortsetzung.
Wir erweitern die Aufgaben der agiligen Teams einfach, um auch ein bisschen Produktivsetzung.
Software is always in a releasable state.
Das ist eine der Definitionen von continuous delivery.
Und wenn man sich das mal so auf die Zunge zergehen lässt,
was heißt in a releasable state, kann man sogar so interpretieren und sagen,
ja, es ist sogar betragen.
Also, ich arbeite so, auch wenn ich zum Beispiel agil arbeite,
dass ich jederzeit live gehen könnte.
Und zwar auch so, dass es dann im Sinne jetzt von Service Management
halt nicht funktionale Anforderungen wie Security, Performance etc. das erfüllt.
Ja, ich habe in meinen Schulungsunterlagen so einen Satz drin stehen,
dass wir eben, was du sagtest mit dem continuous delivery,
dass wir quasi die Release-Setzung oder den Release,
den Release-Plan, die Produktivsetzung,
dass wir das damit eben in die Hände des Business legen.
Das Business könnte das Release live gehen lassen,
wenn wir das eben erfüllen, was du eben gesagt hast.
Und die gucken immer etwas ungläubig,
was manche können sie sich noch nicht vorstellen,
aber das ist ja genau das Ziel, wo wir hinwollen.
Das stimmt, ja.
Was ich dann häufig mache, auch wenn jetzt Teams,
sagen wir, die mit agil arbeiten, zum Beispiel nach Scrum,
dass wir zusammen antworten,
mit der Definition of Done arbeiten.
Wir machen das jeweils im Rahmen von Retrospektiven
und überlegen uns, was heisst jetzt Done für uns?
Oder Done hat früher vielleicht mal geheissen,
ja, okay, wir haben Acceptance-Kriterien, sind erfüllt,
da haben wir das weiterentwickelt, okay, Peer-Review,
da haben wir gesagt, okay, jetzt tun wir mal,
Done heisst beispielsweise, wir haben auch Performance-Tests durchgeführt,
also die, logischerweise muss man die dann automatisieren,
oder wir haben gesagt, ja, gewisse Security-Anforderungen,
die immer wieder kommen, die werden auch Teil von Done,
und das ist so eine Reise, und irgendwann kann man dann
vielleicht wirklich sagen, ja, unser Done, also jederzeit auch,
wir könnten jederzeit live gehen, oder so ist es eigentlich,
aus dieser Sicht ist es schon eine natürliche Weiterentwicklung
von Agilität, aber wie gesagt, klassische Projekte, denke ich,
die können auch davon profitieren.
Ja.
Zum nächsten, oder?
Drittes Missverständnis, was wir hier für uns so aufgeführt
und aufbereitet haben, DevOps passt nicht zu IT-Service-Management.
Das ist natürlich unsere Hauptdomäne oder unsere historische Domäne,
deine und meine, und auch das, finde ich, ist eben ein Missverständnis.
Das heißt, DevOps-Praktiken, meiner Ansicht nach,
können natürlich kompatibel zu IT-Service-Management gestaltet werden,
weil wir natürlich viele Ziele, die wir mit IT-Service-Management,
verfolgen, mit DevOps auch verfolgen und durch DevOps-Praktiken unterstützen.
Allein schon das Thema Automation, wie viel Aufwand und Ärger
wir uns im IT-Service-Management ersparen können,
wenn wir Dinge automatisieren, finde ich das schon einen ganz wichtigen Punkt.
Also insofern passt DevOps aus dieser Sicht heraus schon mal sehr gut
zu IT-Service-Management.
Und wenn ich mir dann so ein, zwei Teile mal rauspicke vom IT-Service-Management,
dann das ganze Thema.
Also CMDB, CMS, Configuration Management, das sind natürlich alles Dinge,
die Pflege dieser Datenbank, das war immer schon ein Automatisierungsgebiet,
wo man eigentlich nur wirklich sinnvoll arbeiten konnte,
wenn man das automatisieren konnte.
Und dadurch, dass ich jetzt die Entwicklung mit Eime ziehe quasi,
da habe ich ja noch bessere Daten, noch genauere Daten.
Und wenn ich den ganzen Fahrrad Continuous Delivery automatisiere,
dann habe ich auch automatisch eine,
die bessere CMDB.
Also auch da, finde ich, ist es wirklich ein sehr gutes Beispiel dafür,
dass DevOps eben IT-Service-Management sehr gut ergänzen kann, unterstützen kann.
Ja, und da können dann eben auch die Entwickler,
die können, vor allem die können was lernen.
Weil historisch, du hast ja DevOps Wall of Confusion,
jetzt sagen wir, okay, die Operations-Leute müssen lernen,
agiler zu werden, zusammenzuarbeiten mit den Entwicklern.
Aber auf der anderen Seite ist es auch ein Bereich,
in dem die Entwickler sich ja historisch nie für IT-SM interessiert haben.
Aber ich denke schon, also ein Kandidat ist zum Beispiel auch das Problem-Management.
Problem-Management, denke ich, eine der Practices aus dem IT-Service-Management,
die dann hilft, ganz im Sinne jetzt auch vom Second Way, vom Gene-Came-Feedback,
von rechts nach links, wiederkehrende Störungen,
da auch dann…
Proaktiv, oder das an der Wurzel zu fassen
und Probleme zu beheben und Störungen zu verhindern.
Configuration-Management sehe ich auch so.
Andere, denke ich, Gebiete, zum Beispiel das Event-Management,
zum Beispiel das ganze Continuous-Monitoring,
wo, sagen wir, auch wenn man jetzt ITIL als Framework anschaut,
da hat es super Tipps drin, die helfen,
wie man ein Continuous-Management,
Continuous-Monitoring aufbauen kann,
ohne dass man jetzt das Rad neu erfinden muss.
Ja, richtig.
Also, was du auch sagtest beim Thema Störungen,
beim Incident-Management, sehe ich ganz genauso.
Ich habe im DevOps ja das Ziel, schnell Störungen zu erkennen
und auch schnell reagieren zu können.
Und da wird jeder ITIL-Freak sagen,
genau das ist das, was wir auch wollen an der Stelle.
Also, insofern gibt es da wirklich große Übereinstimmungen
und man kann sich gut ergänzen.
Und wenn ich ergänzen nochmal…
Ich finde aber auch im Umkehrschluss,
dass IT-Service-Management auch sehr schön
das Thema Agilität unterstützen kann.
Denn wir haben dort, wie du auch sagtest,
tolle Tipps, tolle Practices zum Thema,
wie gehe ich mit Kunden um?
Was sind Services?
Wie beschreibe ich Services?
Service-Level-Management?
Wie vereinbare ich Services?
Das sind alles Dinge, die man quasi im DevOps
sehr schön aus IT-Service-Management übernehmen kann
und weiterentwickeln kann.
Weil das sind alles Sachen, die in den Bereichen,
z.B. Lean-Management und Agile, eben nicht auftauchen.
Also auch da denke ich, kann IT-Service-Management
auch etwas dazu beitragen, um das ganze Thema rund zu machen.
Also, ich finde auch definitiv, ITSM hilft.
Aber es gibt auch dann viele Aspekte,
wo es bei jedem Framework manchmal hilft, manchmal nicht.
Ich denke, die große Inspiration für DevOps
kommt schon vor allem aus dem Lean,
dann aus dem Agilen und natürlich auch ein bisschen
aus dem IT-Service-Management.
Aber ich würde es genau in der Reihenfolge formulieren.
Aber das ist jetzt so meine persönliche Meinung.
Ja, klar.
Also insofern, aber wir haben ja zu Anfang schon gesagt,
es ist kein neues Framework
und jedes Unternehmen muss die eigenen Erfahrungen machen.
Und je nachdem, wie die Erfahrungen im Unternehmen sind,
also ob es groß ist, ob es klein ist,
ob es viele Provider hat, ob es viel selbst macht,
es gibt sehr viele unterschiedliche Rahmenbedingungen,
und die haben einen Einfluss darauf,
wie gestalte ich denn meine DevOps-Organisation,
wenn ich überhaupt in so eine Richtung gehen möchte an der Stelle.
Ja, also insofern, ich glaube auch schon,
dass man aber auch, da haben wir vielleicht
ein bisschen unterschiedliche Einschätzungen.
Ich glaube schon, dass auch so Themen wie Governance
und das ganze Thema Management, also quasi als Überbau,
dass das auch Dinge sind, die wir aus dem IT-Service-Management
sehr gut übernehmen können, quasi als Rahmen,
in dem die DevOps-Teams dann,
sauber und gut strukturiert arbeiten können.
Das ganze Thema Portfolio, Service, Katalog.
Natürlich kann ich mich hinstellen
und kann die Teams das bestimmen lassen,
bin ich auch mit dabei,
aber die bestehenden Strukturen im Unternehmen,
die sind ja da, und da, denke ich,
hilft es schon noch, solche etablierten Prozesse zu haben
und die auch zu nutzen.
Aber man muss sie sicherlich anpassen
und DevOps-Teams da so reinbringen,
also reinmerchen.
In dem Kontext auch, du hast das Portfolio-Management,
erwähnt, also das Scaled-Agile-Framework.
Ich weiss nicht, wie es in Deutschland ist,
aber in der Schweiz ist es,
also ich glaube jetzt bei grossen Unternehmen,
Enterprise-ITs, wo eigentlich dann auch die Governance
sehr stark geprägt wird durch solche Frameworks.
Also Portfolio, Programm und dann auf Projekt- oder Team-Ebene
ist dann halt Scrum oder Kanban
und dann halt ergänzt durch DevOps-Mechanismen.
Ja, richtig.
Aber auch da wieder, was wir zu Anfang hatten,
eigentlich ist es ja ein Luxus-Problem.
Ich kann mir als Unternehmen überlegen, was nehme ich?
Nehme ich jetzt Governance aus Safe,
nehme ich Governance aus Covid beispielsweise,
haben wir ja nicht nur ITIL.
Also ich kann mich eigentlich bedienen,
das ist natürlich aufwendig
und das ist auch mit viel Arbeit verbunden.
Man muss Gehirnschmalz investieren.
Aber wir waren ja bei dem Missverständnis,
DevOps passt nicht zu IT-Service-Management
und das passt nicht so.
Also das passt sehr gut,
und kann sich sehr gut gegenseitig befruchten.
Ja, da sind wir uns einig, denke ich.
Sehr schön.
Mhm.
DevOps macht den IT-Betrieb überflüssig,
respektive NoOps.
NoOps, da habt ihr vielleicht schon den Begriff schon mal gehört.
Das ist ein ursprünglicher Begriff,
der wurde geprägt vom CEO von Netflix.
Der Name fällt mir jetzt gerade nicht mehr ein.
Aber er hat eigentlich gesagt,
ja, für ihn DevOps,
also er heisst es auch,
er braucht keine Operation mehr.
Das ist so der Begriff auch vom Full-Stack-Developer.
Der hat alles selber im Griff.
Shift, Left,
der kümmert sich auch um die ganzen nicht-funktionalen Dinge.
Und Operation ist eh alles,
das dann Infrastructure as Code,
das kommt alles aus der Cloud raus.
Und ja,
gut, da muss man erstens mal dazu sagen,
heute, wie Netflix funktioniert,
das ist definitiv nicht mehr so.
Auch die haben Operation.
Und Operation ist ja,
man darf das jetzt, denke ich,
weniger als Funktion anschauen,
sondern es gibt, sagen wir,
gewisse traditionelle Aufgaben, oder?
Die müssen auch, sagen wir,
im DevOps-Team oder im DevOps-Konstrukt
wahrgenommen werden.
Ich denke, was sich schon ändert,
ist die Rolle von Operation.
Also Operation,
und das ist übrigens auch interessant,
eine der ursprünglichen Ideen von IT-Service-Management,
Operation muss viel früher im Zyklus,
im Lebenszyklus von Produkten und Servicen
berücksichtigt werden.
Also Shift, Left.
Das kann dann schon de facto bedeuten,
dass halt klassische Operation-Abteilungen schrumpfen.
Also nicht mehr so die Denke,
ja, etwas wird entwickelt,
wird übergeben an jemand anderen,
über Prozesse etc.,
sondern halt die Aufgaben,
die müssen weiterhin wahrgenommen werden.
Aber früher Shift, Left.
Und dann ist auch, ich denke,
im Verständnis von DevOps ist,
oder das sehe ich zumindest oft in der Praxis,
ist Operation,
also im DevOps ist sehr stark auch der Enabling,
sagen wir, Infrastructure Layer.
Also die ganze Infrastruktur zur Verfügung stellen.
Cloud, also das kann dann auch eine private Cloud sein,
oder dann halt Public Cloud,
da braucht es auch die Governance dann dazu.
Und mit Infrastructure as Codes,
den ganzen darunter liegenden Layer,
damit dann die Teams,
you build it, you own it,
da effektiv auch beispielsweise Continuous Delivery machen können.
Ohne diesen Layer ist das nicht möglich.
Also es findet dann,
ich denke in der Zukunft ist es nicht mehr die Aufgabe von Operation,
Code in die Produktion zu nehmen,
das zu betreiben,
sondern das den anderen einfacher zu machen,
damit sie das selber machen können.
Und auch andere,
also wenn jetzt von No Ops,
finde ich deshalb auch einen schlechten Begriff,
weil es wird weiterhin,
es wird Störungen geben,
es wird weiterhin klassische,
Monitoring-Aufgaben.
Die Frage ist einfach, wo wird das dann wahrgenommen?
Es ist dann, denke ich,
nicht mehr ein separates Department,
weil das etwas, was ja DevOps definitiv nicht will,
sondern ich glaube Operation muss sich einfach,
ja, muss sich ein bisschen neu orientieren.
Und ich habe es glaube ich schon mal gebracht,
da ist dann eben nicht No Ops,
sondern New Ops eher.
Aber die müssen dann auch entsprechend offen sein,
sich zu wandeln,
statt wie anhin oft halt dann zu mauern,
zu sagen ja,
immer nein zu sagen und sagen nein,
das kommt jetzt nicht in die Produktion,
sondern auch sich da zu öffnen.
Und wenn das nicht der Fall ist,
dann wird dann eben aus,
dann wirklich No Ops draus,
weil dann,
das sehe ich auch oft,
Entwicklungsabteilungen,
die dann das Zepter selber in die Hand nehmen
und,
und sich dann die Dinge auf dem Markt selber beschaffen,
beispielsweise via Public Cloud etc.
Also deshalb,
DevOps macht,
denke ich,
nein,
macht den IT-Betrieb nicht überflüssig,
aber der IT,
die Rolle des IT-Betriebs wird sich wandeln
oder wandelt sich bereits.
Ja,
ich glaube auch,
dass sie sich schon aktuell schon stark wandelt.
Da ist ja auch ein gewisser Druck da durch,
durch Cloud-Anbieter,
du hast es ja eben schon gesagt.
Das heißt,
eine gewisse Notwendigkeit ist da.
Das, was du eben sagtest mit dem Mauern,
nein, das kommt nicht in die Produktion.
Das kann natürlich sein,
dass man gemauert hat aus Prinzip,
aber es kann ja auch sein,
dass man die Gründe gehabt hat,
warum es nicht in die Produktion geht.
Und das finde ich eben einen weiteren Punkt.
Du hast ja gesagt,
sie müssen sich wandeln und das,
oder die Arbeit muss sich wandeln.
Und das finde ich eben dann nur als Vorteil für Ops,
dass die Erfahrung und die Verantwortung,
das Verantwortungsbewusstsein,
das, was wir einfach viel früher in den Lifecycle einbeziehen
und dass wir das jetzt auch wirklich umsetzen.
Du hast ja gesagt,
das auch schon gefordert.
Ja,
es ist ja auch nichts Besonderes zu sagen,
hey,
viel früher einsteigen.
Aber ich glaube,
dass wir jetzt an dem Punkt sind,
wo wir in den IT-Organisationen feststellen,
die Notwendigkeit ist da
und die Sinnhaftigkeit wird auch so gesehen.
Also insofern,
New Ops,
ja,
New Ops heißt,
sie bringen ihre Erfahrung mit ein,
sie bringen ihre Verantwortung,
ihr Governance-Thema,
ihr Governance-Thema mit ein
und sorgen dafür,
dass wir viel früher diese Dinge beachten
und damit auch mehr Qualität produzieren.
Und,
was ich ja auch nochmal ganz interessant finde,
es gibt ja ganz viele ungeliebte manuelle Tätigkeiten im Operations.
Das sichert zwar Arbeitsplätze,
aber ist nicht unbedingt sinnstiftend an der Stelle.
Also insofern,
auch da wieder das Thema Automation,
dadurch,
dass wir eben quasi über DevOps,
auch ganz stark über Automation reden
und es auch umsetzen,
ändert sich ja auch das Thema Ops.
Sprich,
wir kriegen eben,
wir haben den Entfall von vielen manuellen ungeliebten Tätigkeiten,
einfach weil wir Dinge automatisieren
und dazu muss aber auch Ops die Erfahrung mit einbringen
und muss auch die Anforderungen an die Automatisierung quasi formulieren
und mit in den Teams entsprechend eben formulieren.
Ja,
also da finde ich auch,
ja,
aber das produziert dann auch sehr viele Ängste.
Sagen wir,
Leute,
die halt im Vergangenheit
sehr viele repetitive Aufgaben gemacht haben
und da ist jetzt ein gewisses Automatisierungspotenzial,
da,
dass sich dann die Leute halt die Frage stellen,
ja was,
was,
was passiert mit mir in der Zukunft?
Jetzt kann man das natürlich als Gefahr sehen,
einerseits,
aber auch als Chance.
Also primär würde ich jetzt,
für mich würde ich sagen,
ja auch,
dass der Job spannender wird.
Aber die,
das Problem ist natürlich dann mit den Skills.
Das sieht man auch schön,
zum Beispiel im Testing.
Früher sehr viel,
sagen wir Testausführende,
während heute,
klar die,
weil ja viel Automatisierung,
auch Testautomatisierung,
das heisst,
es braucht wenige Testausführende,
aber Leute,
die dann die Skills haben,
zum Beispiel Tests zu automatisieren
oder in die Richtung.
Und dann ist dann immer die Frage,
ja,
die Leute wollen vielleicht,
aber sie können nicht von den Skills her.
Das ist dann schon,
schon auch problematisch.
Auf der anderen Seite ist ja,
Industrialisierung ist etwas,
das vermutlich schon seit 200 Jahren stattfindet,
aber die Jobs sind ja nicht weniger geworden,
es sind immer mehr geworden.
Und ich glaube,
in der IT ist auch,
obwohl jetzt immer mehr automatisiert wird
oder Komoditisierung durch Cloud,
die Jobs werden mehr,
aber es ist halt mehr,
es wird anspruchsvoller,
denke ich.
Und da ist auch die Frage,
können sich Operationsleute,
die,
sagen wir,
sich in automatisierten Bereichen bewegt haben,
also die jetzt automatisieren,
können sich da weiterentwickeln?
Und wenn nicht,
dann ist es halt für die schon schwieriger.
Ja, das glaube ich auch.
Aber da stelle ich fest,
zumindest bei uns in Deutschland,
dass wir ja schon verantwortungsvolle Firmen haben,
verantwortungsvolle IT-Organisationen,
die sich ihrer Verantwortung eben bewusst sind
und auch dafür sorgen,
dass die Mitarbeiter diesen Weg mitgehen,
wenn sie sich eben öffnen.
Das hast du ja auch schon zu Anfang gesagt.
Sie müssen sich öffnen
und sie müssen das als Chance sehen.
Wer dort mauert,
der hat vielleicht früher die Produktivsitzung gemauert
und jetzt mauert er sich dann seine eigene Sackgasse.
Ja, ich finde,
da gibt es so ein schönes Dreieck.
Dürfen,
wollen und können.
Das eine ist ja,
wir dürfen,
klar,
die Firma sagt doch,
also ihr dürft,
wir wollen das sogar,
dass ihr euch in die Richtung entwickelt.
Und dann ist schon die Frage damit,
aber will er das überhaupt?
Und vielleicht,
ja, okay, will er es,
aber da gibt es auch die Fälle,
wo man aus dem Testausführen,
dann kannst du nicht von morgen auf heute
einen Testautomatisierer machen.
Das sind komplett andere Skills.
Da kann dann eben schon noch der Hund begraben sein.
Weil da finde ich einfach dann auch wichtig,
deswegen haben wir auch diese Missverständnisse,
die wir mal rausgepickt haben,
dass man den Betriebsleuten klar macht,
dass man das Wissen schon noch hat,
was man noch braucht.
Natürlich verändert sich die Arbeit,
aber das Wissen,
die Erfahrung,
die die gesammelt haben,
das sind Schätze,
die kann ich einem Entwickler,
kann ich ihm das gar nicht erklären.
Also die Erfahrung,
die der Betrieb mitbringt,
die braucht man auch bei Übergangsphasen in die Cloud,
wenn man wirklich die Cloud,
also wenn man eine externe Cloud hat
oder wenn man eine eigene,
eine private Cloud aufbaut im Unternehmen.
Das Wissen brauche ich ja auch an der Stelle.
Also insofern,
da sind wir uns eben auch einig,
der DevOps,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
da sind wir uns eben auch einig,
der DevOps macht den IT-Betrieb nicht überflüssig,
sondern verändert die Arbeit
und wir können nur hoffen,
dass sich die Leute mitgenommen fühlen,
dass sie mitgenommen werden
und dass sie sich einbringen können.
Ja,
ist eine Chance schlussendlich.
Ja,
ja Mensch,
das fünfte,
das fünfte Missverständnis,
einen können wir noch
oder zwei.
DevOps ist eigentlich nur Everything as Code.
Das heißt,
wir reden eigentlich bei DevOps nur über Automation.
Also auch das,
das ist ein Missverständnis.
Denn,
das denke ich,
haben wir schon durch die vorherigen Missverständnisse
ein bisschen klar gemacht,
wir reden eben nicht nur über Automation.
Natürlich haben wir bei DevOps oder mit DevOps
einen ganz hohen Automationsanteil,
aber das ist eben nicht alles,
weil wenn ich jetzt beispielsweise über die Prozesse
nicht nachdenke,
dann automatisiere ich ja nur Teilschritte
eines gesamten Prozesses.
Das heißt,
ich brauche einen Gesamtüberblick über alle Prozesse,
über den gesamten Ablauf,
über die gesamte Wertschöpfungskette,
das heißt,
Automation,
sehr schön,
aber ich muss eben die gesamte Wertschöpfungskette im Blick haben,
muss diese drei Wege,
muss den Rückfluss einfach über die gesamte Kette sehen.
Also insofern,
ja,
Automation,
aber es reicht eben nicht,
nur einen Teil zu betrachten.
Ja,
ich denke,
also DevOps ist sicher nicht möglich ohne Automation.
Ja,
da hatten wir auch früher schon mal drüber gesprochen.
People,
Prozesse,
Technologies,
schlussendlich ein Aspekt dann.
Und wir brauchen ja auch Kultur.
Also das ganze Thema,
was wir aus der Agilität kennen mit Experimenten,
mit Fehlerkultur,
mit Dingen mal ausprobieren und so weiter.
Also die vielen Dinge,
die wir aus der Agilität kennen,
die muss ich in eine DevOps-Kultur einbringen,
genauso wie ich auch die Betriebsaspekte in diese Kultur einbringen muss.
Also ich glaube wirklich einen großen Mehrwert
oder das Sahnehäubchen ist zum Beispiel einfach,
eine gemeinsame Kultur zu schaffen,
eine Kultur,
wo sich alle wiederfinden,
wo es dann eben auch wirklich Spaß macht
oder vielleicht wieder Spaß macht,
für die IT zu arbeiten.
Du hast ja immer so schöne Zitate vorhin gebracht
und ich habe da auch ein schönes Zitat gefunden
von dem Christopher Little,
der hat eben gesagt,
bei DevOps geht es nicht um Automatisierung,
genauso wie es in der Astronomie nicht um Teleskope geht.
Also ich brauche das zwar,
aber es gibt ein bisschen mehr an der Stelle.
Also insofern,
ja,
Missverständnis ausgeräumt hoffentlich an der Stelle.
DevOps ist,
DevOps ist mehr als Automation.
Das muss ich jetzt gleich noch toppen,
nochmal mit einem Zitat.
A fool with a tool is still a fool.
Ja stimmt, richtig.
Von wem kommt das eigentlich?
Von Herrn Kupf unbekannt.
Keine Ahnung,
ich glaube das ist so ein bisschen allgemein gut,
aber da gibt es sicher einen,
der das zuerst gesagt hat.
Man muss mal gucken,
wo man den findet.
Also insofern,
Everything as Code,
ja auf jeden Fall,
aber es ist eben nicht alles.
Wollen wir noch einen?
Also Zeit haben wir glaube ich noch.
Der ist ja so von der Reserve list.
Ja, mach mal.
Knapp 40 Minuten.
Ja, der tönt im ersten Moment ein bisschen blöd,
aber ich bin halt ab und zu stoßig auf diese Aussage.
Entwickler haben direkten Zugriff auf die Produktion.
Nein, natürlich nicht.
Aber zuerst einmal,
woher kommt dieses Missverständnis?
Also einerseits,
ist halt wenn man hört,
wie Continuous Delivery, Continuous Deployment,
z.B. Amazon,
die machen 5000 Deployments am Tag.
De facto,
wenn Entwickler Code eingecheckt und das hat alle Tests durchlaufen,
das geht in die Produktion.
Das ist dort so,
bei anderen Firmen auch.
Und dadurch kann ja dann das Missverständnis,
jetzt hat der Entwickler direkt Zugriff auf die Produktion.
Aber wenn man jetzt,
gut, das ist halt ein bisschen jetzt technisch auch,
aber wenn man sich Continuous Delivery anschaut,
die DevOps Pipeline ist ja weiterhin so und muss auch so sein,
auch aus Governance Gründen.
Der Entwickler entwickelt auf einer Entwicklungsumgebung
und was ja weiterhin stattfindet,
ist dann der Transport und die ganze Change Control,
einfach in einem hochautomatisierten Grad.
Das heisst,
wenn das wird dann direkt überführt in eine Testumgebung,
es werden automatisierte Tests durchgeführt,
also alle,
die das V-Modell kennen,
das fängt dann beim Unit Test System Test etc.
Dann aber auch,
was ja früher vergessen gegangen ist,
nicht funktionale Tests wie Performance, Security, Continuity etc.
Und dann,
wenn das alles erfolgt,
dann wird das in eine zum Beispiel Produktionsumgebung überführt.
Vielleicht auch nur für ein paar wenige User,
je nachdem welche Teststrategie das man fährt.
Man kann ja dann sagen,
ja,
dann lässt es mal als Piloten laufen
und dann,
wenn kein negatives Feedback,
wird es dann ausgeweitet auf den Rest.
Aber in dem Sinn ist ja auch ganz im Sinne von DevOps,
dass es wird,
dass es kein direkter Zugriff auf die Produktion,
dass uns das weiterhin separiert,
Change Control,
aber halt einfach im,
wenn wir jetzt technisch oder prozessmässig gesprochen,
einen hohen Grad an Automatisierung.
So, also das ist jetzt so meine Sicht.
Ich weiss nicht wie du Dirk,
bist du auch schon über diese Aussage gestossen,
Entwickler haben direkten Zugriff auf die Produktion.
Das kommt manchmal bei,
wenn wir über das Thema Governance sprechen,
dann kommt das manchmal,
aber so wie du es im Prinzip gesagt hast,
kommt dann immer auch als Erklärung
und ich glaube,
dass die meisten das dann auch an der Stelle auch verstehen.
Ja, genau.
Ja Mensch,
dann haben wir heute sechs Missverständnisse
und ich glaube,
wir sollten die nochmal aufzählen
und zwar eben,
dass wir sie so formulieren,
damit keiner rausgeht aus dem Podcast
und sich quasi das Missverständnis merkt.
Also ich fange mal an mit meinem ersten Missverständnis
und formuliere das mal positiv.
DevOps ist kein neues Framework.
DevOps ist eine Philosophie,
aber kein neues Framework.
Dann versuche ich das im genau gleichen Stil für den nächsten,
nämlich DevOps ergänzt und ersetzt nicht
die agile Produktentwicklung.
Jawohl, dann mache ich weiter mit dem dritten.
DevOps passt zu IT-Service-Management.
DevOps kann gut von IT-Service-Management ausgehen.
Man muss IT-Service-Management lernen und umgekehrt.
Also DevOps passt sehr wohl zu IT-Service-Management.
Dann DevOps macht IT-Betrieb überflüssig aka NoOps.
Nein, die Aufgaben von Operation wird es weiterhin brauchen.
Ist halt einfach das Bild von Operation,
das klassische Operation,
das sich wandeln muss Richtung NewOps.
Jawohl, da bin ich wieder dran.
DevOps ist mehr als Automation.
DevOps ist nicht nur Everything as Code.
DevOps ist mehr als Automation.
Und DevOps besteht zwar zu einem hohen Teil aus Automation,
aber es gibt noch viele andere wichtige Dinge.
Insofern, DevOps ist mehr als Automation.
Dann Entwickler haben direkten Zugriff auf die Produktion.
Nein, natürlich nicht.
Das ist Blödsinn.
Ja.
Jetzt hast du mich aber geschockt.
Ja.
Jawohl, sehr schön.
Ja, dann haben wir doch wieder eine Podcast-Folge hier gemeinsam über den Weg gebracht.
Das ist jetzt die letzte Einstellige.
Also insofern, mir macht es Spaß.
Ich finde es schön.
Es ist ein schöner Austausch.
Und man sieht ja auch und hört an den Feedbacks,
dass es bei den Kunden auch ankommt,
dass es Leute gerne hören.
Gut, dann sind wir jetzt durch, Alex.
Ich habe ja gesagt, mir hat das Spaß gemacht.
Mir macht es immer wieder Spaß.
Beim nächsten Mal.
Beim nächsten Mal haben wir dann wieder einen Gast
oder vielleicht sogar auch mehrere Gäste hier im Podcast.
Wir haben ein Unternehmen.
Und das Unternehmen wird uns ein bisschen was aus der eigenen Praxis berichten.
Insofern verraten wir den Namen mal noch nicht.
Es ist aber ein ganz interessantes Unternehmen.
Der eine oder andere wird es vielleicht kennen.
Aber ja, seien Sie gespannt.
Seid ihr gespannt auf den nächsten Podcast.
Ich verabschiede mich.
Auf Wiederhören, auf Wiedersehen, wo auch immer.
Dir war Dirk Söhner.
Ja, vielen Dank auch von meiner Seite.
Es hat mir auch wieder riesig Spass gemacht.
Und ja, ich freue mich auf den nächsten Podcast.
Dann hört man sich wieder in einem Monat.
Bis dann, auf Wiederhören.
Tschüss.
Tschüss.
Tschüss.
Tschüss.
Tschüss.

Folge 8: Das Phoenix Project und DevOps Handbuch

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Podcast-Episode diskutieren Dierk Söllner und der Gast Thomas Demmich, der Übersetzer des „Phoenix-Projekts“ und des „DevOps-Handbuchs“, detailliert über DevOps. Sie erörtern verschiedene Aspekte wie die Übertragung von Produktionsprinzipien auf die IT, die Herausforderungen bei der Implementierung von DevOps in Unternehmen, und die Bedeutung einer Fehlerkultur. Sie reflektieren auch über die Charaktere und Ereignisse im „Phoenix-Projekt“ und wie diese die Realitäten in IT-Organisationen widerspiegeln, während sie gleichzeitig praktische Ansätze aus dem „DevOps-Handbuch“ hervorheben.

Inhalt

  • Einführung und Vorstellung von Thomas Demmich
  • Definition und Bedeutung von DevOps
  • Diskussion über das „Phoenix-Projekt“ und Charakteranalyse
  • Einblicke in das „DevOps-Handbuch“
  • Automatisierung und Herausforderungen in DevOps
  • Bedeutung von Fehlerkultur und technischen Schulden
  • Anwendung von DevOps-Prinzipien in realen IT-Umgebungen
  • Abschließende Gedanken und Aha-Effekte

Shownotes

  1. „Das Phoenix-Projekt“ BuchLink
  2. „Das DevOps-Handbuch“ BuchLink
  3. Gene Kim (Autor)Link
  4. O’Reilly Verlag (Thomas Demmich arbeitet als Übersetzer für sie) – Link

Transkript (automatisiert, daher keine Gewähr 🙂 )

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 Abonnenten auch im Namen von Alex Lichtenberger.
Der ist leider heute Abend krank, den hat die Grippe ins Bett geworfen, also insofern haben wir heute eine Premiere für diesen Podcast.
Die Premiere ist nur einer der beiden Gastgeber am Mikrofon, aber ich denke, das kriegen wir hin.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir sprechen alle DevOps-Interessierten an, die mit dem Medium podcasten.
Und gerne etwas dazu hören, sei es beim Autofahren, in der U-Bahn, S-Bahn oder abends im Hotel oder auch vielleicht zu Hause.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern, die in DevOps enthalten sind.
Und für diese Folge haben wir was ganz Besonderes.
Wir haben Gene Kim. Na gut, wir haben natürlich nicht Gene Kim selber.
Wir haben die deutsche Stimme von Gene Kim, Thomas Demick, der die Bücher von Gene Kim,
übersetzt hat, das DevOps-Handbuch und das Phoenix-Project.
Also haben wir heute ein Fachgespräch mit der deutschen Stimme von Gene Kim.
Mit diesem Podcast wollen wir eben die Hörer und Hörerinnen etwas näher und etwas besser an das etwas schwammige Thema DevOps heranführen.
Wir wollen Dinge verstehen und erklären und wir liefern Vorschläge, Konzepte, Interviews mit Experten und mit Praktikern,
damit wir Sie, liebe Zuhörer, liebe Zuhörerinnen, persönlich,
weiterbringen, damit Sie persönlich durchblicken können und Ihr Unternehmen und Ihr Team erfolgreicher machen können.
Heute haben wir das Thema, wie ich eben schon gesagt habe,
The Phoenix Project und begrüßen dazu Thomas Demick, den deutschen Übersetzer.
Und in diesem Podcast werden Sie etwas über die Inhalte vom Phoenix Project hören,
einen Roman über DevOps.
Wir werden Ihnen ein bisschen die einzelnen Charaktere näherbringen, etwas über Sarah und über Eric erzählen, etwas über Patty und Wes.
Wir werden auch ein bisschen was über die anderen Charaktere sprechen.
Wir werden über das DevOps Handbuch sprechen.
Wir werden zum Beispiel darstellen, was das bedeutet, sichtbar machen von Arbeit, was es bedeutet, über technische Schulden zu sprechen.
Wir werden versuchen, den Aha-Effekt so ein bisschen rauszuarbeiten, den die Autoren für sich damals hatten, um dann das Buch zu schreiben.
Wir werden ein paar andere Dinge ansprechen, die in dem Buch beschrieben sind.
Wir sprechen über die vier Arten von Arbeit.
Wir sprechen über die drei Wege, über das Drei-Wege-Modell.
Also insofern werden wir hoffentlich eine schöne Podcast-Folge produzieren,
die die Leichtigkeit des Romans ein wenig übernimmt und ein wenig auf diesen Podcast überträgt.
Lieber Thomas, vielen Dank für die Unterstützung und deine Begleitung heute.
Herzlich willkommen zu unserem Podcast hier, DevOps auf die Ohren und ins Hören.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
immer zu Anfang eine kurze Vorstellung unseres Gastes und dann die Frage,
wie würdest du DevOps definieren?
Also insofern würde ich sagen, lass uns loslegen, lieber Thomas.
Starten wir mit der Vorstellung und mit deiner Einstiegsdefinition von DevOps.
Ja, hallo. Also ich bin Thomas Demmich.
Ich bin eigentlich Entwickler, nebenberuflich auch Übersetzer,
vor allem für O’Reilly und den D-Punkt-Verlag mittlerweile.
Arbeite sonst hauptberuflich in einem großen deutschen Softwareunternehmen,
habe in, ich glaube, vorletztes Jahr ist das jetzt schon das Phoenix-Projekt übersetzt
und auch dann danach das DevOps-Handbuch.
Fand das sehr spannend und sehr interessant und freue mich darüber jetzt mal zu reden.
Du hast es ja schon gesagt, DevOps-Handbuch, Phoenix-Projekt.
Geht es um das Thema DevOps? Wie würdest du DevOps definieren?
Kann man das überhaupt definieren? Würdest du das beschreiben?
Ich würde das definieren als engere Zusammenarbeit zwischen der Entwicklung
und dem darauffolgenden Operations-Unternehmen.
Wobei versucht wird, eben möglichst viel zu automatisieren
und möglichst viele Zeitfresser und Hindernisse aus dem Weg zu räumen, nach und nach.
Ja, sehr schön. Das ist auch schon mal ein interessanter Punkt.
Zeitfresser, ich denke, ich weiß, woher du diesen Begriff hast
und die Hindernisse aus dem Weg räumen, das sind ja schon Dinge,
die aus dem Buch auch so hervorgehen.
Aber vielleicht mal so zu Beginn noch eine ganz andere Frage.
Gar nicht so fachlich.
Wie wird man Übersetzer und wie muss ich mir als jemand,
der die übersetzten Bücher liest, wie muss ich mir das vorstellen?
Was macht ein Übersetzer oder wie arbeitet der?
Ich bin das geworden, weil mein Vater es schon war.
Der hat das gemacht damals, musste dann damals noch zu Windows 2000-Zeiten
gleich so vier Bände auf einmal übersetzen bzw. betreuen
und hat mich damals gefragt, ob ich das nicht auch mal machen will.
Dann habe ich damals einen von den Bänden übersetzt
und der damalige Lektor war halt angetan davon
und hat mich, als bei der damals gerade den Verlag gewechselt hat, mitgenommen.
Und dann habe ich, ich glaube, erst für Hansa übersetzt und für METP.
Und das ist dann irgendwann, ist das eingeschlafen
und dann habe ich mich mal bei O’Reilly beworben sozusagen,
habe da einfach mal angefragt, habe eine Probeübersetzung gemacht
und seitdem bin ich seit vielen Jahren irgendwie schon da.
Insofern, du hast ja ein Privileg, glaube ich, du bist ja etwas ganz Besonderes.
Ich denke, du bist einer der wenigen auf der Welt,
der quasi das Original und die deutsche Übersetzung gelesen hat.
Also insofern bist du da schon was Besonderes.
Nicht nur die deutsche Stimme von Gene Kim,
sondern auch jemand, der, wie gesagt, beide Bücher gelesen hat.
Gut, das heißt, die Arbeit als Übersetzer,
wie stark nimmt dich das ein oder wie stark beschäftigt ist es in deiner Freizeit?
Es sind im Prinzip dann die Abende, die ich damit verbringe.
Also nicht den ganzen Abend, aber immer schon so,
zwei, drei Stunden, aber eben nicht jeden Abend.
Also ich gucke, dass ich dann, wenn es geht,
das terminlich so absprechen kann mit dem Verlag,
dass ich quasi dann auch eine Fünf-Tage-Woche habe,
sodass ich dann immer ein, zwei Abende die Woche nichts tun muss
und auch kein schlechtes Gewissen haben muss, wenn ich mal nichts tue.
Okay, ja. Aber es ist schon anstrengend sozusagen oder schon auch durchgetaktet?
Ja, es ist schon anstrengend auf Dauer dann.
Also es macht immer Spaß, wenn ich was Neues anfange
und wenn ich dann auch wieder gleich wieder,
wenn ich dann auch wieder was Neues anfange,
immer wieder was am Stück kriege, ist das auch schön natürlich.
Aber wenn dann mal Pause ist, ist das auch nicht schlecht.
Aber nach so zwei, drei Monaten Pause, das kommt ja auch mal vor,
freue ich mich dann auch wieder, wenn ich dann mal wieder was machen kann,
weil ich es einfach auch spannend finde, weil es immer wieder mal was Neues ist.
Die Themen ja auch immer wieder variieren.
Das ist im Vergleich zu dem, was ich in meiner,
sagen wir mal, in meiner Brotarbeit tue,
ist das halt quasi ein Spielbein für mich.
Ja, ja, das ist doch interessant.
Ich finde es auch schön, wenn man ein bisschen noch was quasi
nah am Fachlichen dran hat.
Weil ich gehe immer schon davon aus,
dass du auch das eine oder andere von deinen Übersetzungen
auch mitnehmen kannst fachlich.
Also du kriegst ja quasi das Lesen bezahlt.
Ja, also ich denke, ich habe in vielen Bereichen,
habe ich mal was erfahren.
Ich bin nirgendwo so richtig tief drin.
Also es ist jetzt, es gibt immer,
auch in meinem Umfeld auf der Arbeit,
immer genug Leute, die irgendwas auf jeden Fall deutlich besser können.
Aber ich habe von allem schon mal gehört.
Und das finden viele irgendwie finden,
das muss ich auch zugeben,
viele sind spannend, wenn die davon hören,
was ich halt nebenbei noch mache.
Und die freuen sich auch immer wieder mal,
wenn ich dann ein fertiges Buch mitbringe,
die dann da drin auch lesen können.
Ja, okay.
Wenn wir jetzt mal auf das Phoenix Project gehen.
Also ich finde, das ist ja ein wahnsinnig tolles Buch.
Wie ging dir das, als du das zum ersten Mal so bekommen hast
und dann gelesen hast?
Es wird ja als Roman beworben oder dargestellt.
Würdest du es auch als Roman bezeichnen?
Oder ist das für dich auch eher ein,
ein Fachbuch?
Also wie war so dein erster Eindruck,
als du das Buch bekommen hast?
Es ist schon ein Roman,
finde ich auf jeden Fall.
Ein Roman mit einer, mit einem,
ja, wie soll ich sagen,
nicht mit dem erhobenen Zeigefinger,
aber mit einem, der versucht halt,
eine Message rüberzubringen.
Der versucht ja, Informationen zu vermitteln,
die Leute dazu zu bringen, zu sagen,
Mensch, das kenne ich doch bei mir genauso.
Vielleicht sollte ich das mal irgendwie auch angehen.
Aber es ist, im Endeffekt ist es eine Geschichte,
eine schöne Geschichte, die erzählt wird,
in der sich, glaube ich, wirklich viele IT-Leute,
viele IT-Leute wiederfinden.
Ganz viele, glaube ich.
Und beim Übersetzen,
also habe ich dann auch schon gemerkt,
es gibt immer wieder Stellen, wo ich dann auch kurz gezögert habe,
weil es, weil mir dann irgendwie
was komisch vorkam.
Aber letztendlich
wird damit alles erzählt oder vieles
erzählt, was jetzt dann nachher auch im Handbuch quasi
etwas trockener aus, aus fachlicher
Sicht dann nochmal ausführlicher beschrieben wird.
Ja, okay.
Gut, dann würde ich sagen, es ist ein Roman, weil er einfach
eine Geschichte erzählt, könnte die
Geschichte, könnte dieser Roman
in der Wirklichkeit so stattgefunden haben
oder ist das auch zu viel Fiktion
für dich mit dabei? Also die, sagen wir mal so,
der Zeitrahmen,
den finde ich etwas herausfordernd.
Den kann ich mir so nicht vorstellen in der Realität,
aber es ist halt ein Roman. Es ist eine
Erzählung. Ja, okay.
Und die
ziehen letztendlich,
also zumindest auf der IT-Seite ziehen mehr oder weniger
alle mit.
Die Bösen sind ja dann quasi auf der
Business-Seite eher.
Ja, okay.
Ich glaube gerne, dass viele das gerne
mitmachen, aber ich vermute eher, dass auch immer
mehr eher dann welche dabei sind,
die das irgendwie doof finden oder
nicht richtig finden oder das irgendwie aus
Prinzip nicht mitmachen wollen.
Und das geht da ein bisschen unter, aber
es soll ja halt auch,
es soll halt die Geschichte erzählt werden und da finde ich
das in Ordnung. Ja, okay.
Du hast ja vorhin schon auch so ein paar
Details ausgesprochen,
Zeitfresser und so weiter. Eben hatte ich ja
noch danach gefragt, wie du das so empfunden hast.
Wenn du jetzt,
wenn dich jemand fragen würde, der
von IT vielleicht nicht so viel Ahnung
hat, ein guter Freund, ein guter Bekannter,
würdest du ihm dieses Buch
empfehlen, quasi eben,
weil es ja ein Roman ist und
sagt, Mensch, wenn du mal wissen
willst, wie das in manchen Firmen abgeht, liest du
mal dieses Buch durch? Ich glaube schon,
also im Vergleich zu irgendeinem Fachbuch auf jeden
Fall, aber auch da
ist es, glaube ich, so, man profitiert eher davon,
wenn man schon mal das alles irgendwie mitgemacht hat,
zumindest am Rande.
Ich kann mir vorstellen, dass das auch für die
Businessleute durchaus von Interesse ist, weil die dann
nämlich mal sehen, warum dann irgendwas nicht so läuft,
wie sie es sich vorstellen.
Dieses Klassische,
das ist doch aber eigentlich ganz einfach, ja,
aber aus historischen Gründen ist das eben doch
nicht so einfach.
Aber ich denke, so für jemanden, der so
von ganz, gar nichts
mit bisher zu tun hatte, ist das Problem,
dass er
auch da vieles nicht verstehen wird, warum
das denn jetzt so kompliziert ist.
Wie es in der Realität halt
dann auch ist.
Ja, okay.
Also ich habe mit
vielen Kollegen gesprochen,
Beraterkollegen an der Stelle und
die haben eigentlich immer so
ähnlich so beschrieben,
ihr Lesegefühl. Sie haben
dabei geweint und gelacht, also
gelacht unter dem Motto, das habe ich alle
schon genau so erlebt und als Berater
weiß man ja, dass diese Dinge in
vielen Firmen passieren. Die Firmen
sagen ja immer, das ist nur bei uns so schlimm und dann,
ich sage dann immer, nee, das ist überall so schlimm,
in unterschiedlichen Ausprägungen.
Also die haben geweint und gelacht und gelacht,
wie gesagt, weil sie es erlebt haben und
geweint, weil sie einfach sagen, hey, es könnte
ja, wenn man den Roman mal
richtig umsetzen könnte, könnte ja so
einfach sein, das alles sozusagen in Griff zu
kriegen an der Stelle.
Ja, also ich gehe auch davon aus, dass
das eigentlich letztendlich
in so gut wie allen Firmen so ist,
mehr oder weniger. Ich bin halt
nur nicht immer ganz sicher, ob dieses, also
ich glaube, man profitiert auf jeden Fall, wenn man
versucht, DevOps umzusetzen
bei sich, soweit es eben geht.
Aber ich denke, es gibt auch immer
wieder Szenarien, Situationen,
in denen das dann schwierig wird, das
komplett umzusetzen. Also ich bin
halt im UI-Umfeld unterwegs
bei uns. Da sehe ich
zumindest, wie knifflig
das ist, sagen wir mal,
Code, also Tests zu automatisieren,
die dann mit Browsern zu tun haben,
zum Beispiel, weil das
nicht so einfach ist.
Okay, ja. Ja klar,
also wenn es einfach wäre, könnte es ja
jeder, okay, hast du vielleicht
ein paar Beispiele, weil Browser ist ja
ein schönes Beispiel dafür. Also,
wenn man irgendwie so eine Control-
Bibliothek hat,
dann, also zumindest bei uns im Umfeld
ist das so, da werden dann die Tests automatisiert
und dafür werden dann automatisch
Screenshots erstellt und dann verglichen mit der
letzten Version. Und wenn jetzt
zum Beispiel der Browser sich entscheidet,
eine neue Rendering-Engine zu nehmen und das um
zwei Pixel zu verschieben, dann ist erstmal alles rot,
alle Tests.
Okay.
Erstmal alle und dann muss man ja sehen, ist das jetzt nur rot,
weil es sich um den Pixel verschoben hat oder hat
sich doch irgendwas geändert, sowas zum Beispiel.
Ja. Also das sind halt
so Dinge, da kommt man
glaube ich eher an seine Grenzen.
Oder, wo ich
vorher beteiligt war, da ging es um
so eine Integrationsumgebung,
in der Code
aus, also oder halt im Prinzip
Services aus verschiedenen Umgebungen
integriert wurden.
Und da haben wir sehr viele
Mocs geschrieben und
da hatte ich dann teilweise das Gefühl, dass
mit 90% der Zeit dafür draufging,
die Umgebung zu simulieren,
damit, um zu gucken, ob der
eigene Code funktioniert. Das hat jetzt nicht
explizit was mit DevOps zu tun, das ist mir schon klar,
das ist ja eher dann das,
überhaupt das Automatisieren und ich weiß auch, dass es
trotzdem sinnvoll ist, aber ich fürchte, da
kommt man irgendwo an eine Grenze,
wo es dann letztendlich doch zu teuer
wird und man vielleicht dann
doch einfach sagen muss, okay, wir laufen,
wir nehmen in Kauf, dass wir ab und zu mal
irgendwas kaputt machen und dann müssen wir es halt dann
reparieren. Ja,
das ist richtig und das ist dann natürlich auch
das Schöne an einem Roman, da muss man sich um
diese Banalitäten nicht kümmern.
Da schreibt man einfach die Geschichte weiter.
Ja, aber immerhin im Roman
kommen ja auch Szenen vor, in denen dann
sie haben schon versucht und trotzdem ist es noch
mal alles drunter und drüber gegangen.
Ja, das stimmt und das sind auch die
Realitäten wieder an der Stelle.
Also was ich
in diesem Roman so schön finde, sind die
verschiedenen Personen.
Ich habe auch wieder
von vielen gehört, die im Unternehmen
sind, die haben gesagt, wenn ich
jetzt meinen Kollegen sowieso sehe
auf dem Flur, dann weiß ich,
hey, das ist Brent oder das ist
der oder das ist der. Also die haben
eigentlich die ganzen Protagonisten
in dem Buch, finden sie wieder
in ihrem eigenen Unternehmen. Geht
dir das auch so? Ja.
Also ich
sehe das ja nun eher,
man könnte vielleicht sagen, sie sind ein wenig
teilweise zu schablonenhaft, aber sie sollen
ja halt auch einfach den Leuten
Wiedererkennungswert bieten und das
tun sie damit natürlich schon. Ich denke, niemand ist
exakt so wie in dem Buch.
Der Brent, der irgendwie an allem
mitwirbelt und
von allen gebraucht wird. Also
ich denke, so ein Brent kennt
tatsächlich jeder in der Art und Weise
vielleicht nicht so extrem. Es ist vielleicht ein bisschen
überzeichnet. Eine Sarah, die
von Business-Seite aus immer
versucht, irgendwie zu
intrigieren.
Stimmt auch.
Aber das soll natürlich
helfen, dass man die Leute wieder
erkennt. Und vielleicht freut man sich dann auch,
dass die Leute in der eigenen Firma nicht ganz so
extrem sind wie in dem Buch.
Ja, gut. Also klar, eine Freude
dann, eine ganz kleine Freude natürlich.
Und wenn man dann auf dem Flur
im Unternehmen daran vorbeigeht,
ey, guck mal, da kommt wieder die Sarah.
Kann man doch mit der Geheimsprache sprechen.
Ja, okay. Also Brent und Sarah hast du angesprochen.
Was ist
als Charakter noch für dich so hängen geblieben?
Wer ist noch so schön darstellbar?
Wer lebt in dem Buch?
Die Patty, die
irgendwie Operations sozusagen
durchzieht, aber dann auch immer
vernünftig ist und immer organisiert ist.
Solche Leute gibt es, glaube ich, auch in vielen
Unternehmen. Ich glaube, wenn es sowas nicht gäbe, dann würden
die Unternehmen ganz schön untergehen.
Und den Wes, der halt tatsächlich
auch schräg ist und sagt, was er
denkt, aber eigentlich dann doch sehr
hilfreich und häufig auch gute Ideen hat.
Also die gibt es eigentlich, sind die alle
offensichtlich.
Der CEO, der Steve, der ist
für mich zu weit weg, als dass ich das jetzt ernsthaft
vergleichen könnte.
Der Eric, der ist ja so
eine Art irgendwie
Jedi-Vater.
Das ist, glaube ich, jetzt wirklich
so eine Figur,
die, glaube ich, jetzt in der Realität dann doch eher selten
hervorkommt. Aber ich finde,
sie passt gut dazu, um so die Geschichte ein bisschen
oder um die Geschichte voranzutreiben
und
der Hauptfigur Bill
dann einfach die richtigen Stichworte zu geben.
Ja, und wahrscheinlich
auch, du hast auch gesagt, die Geschichte vorantreiben,
und immer an den richtigen Stellen
die richtigen Erläuterungen geben.
Und wenn ich mir das anschaue,
also ich habe mir das Buch,
als ich es mir durchgelesen habe, habe ich gleich angefangen,
als die immer in der Fabrik sind
und einfach diese
Geschichten erklärt werden
über die verschiedenen Arten der Arbeit
und so weiter. Da habe ich mir gleich so
Post-its dran gemacht, so kleine
Zettelchen, wo ich weiß, ich kann diese
Geschichtsteile in der Fabrik
quasi nochmal, immer mal wieder nachlesen,
weil ich das einfach schön erklärt finde,
an der Stelle.
Es passt halt auch gut, dass das gerade eine Firma ist, die tatsächlich
richtige Fabrikhallen
hat.
Das haben ja viele IT, also
Firmen im IT-Umfeld dann ja doch
eher nicht mehr, aber
natürlich ist das
da sehr geschickt und es gibt es natürlich
ja natürlich auch, also dass die IT-Abteilungen
in echten produzierenden Firmen
dann Probleme haben.
Ja, das ist richtig, das ist ja wohl
richtig, jawohl. Was ich so
schön finde, sind die vier Arten der
Arbeit. Hast du da für dich auch
Parallelen entdeckt? Kannst du das nachvollziehen?
Ja.
Ja, in meinem Umfeld ist es so, dass
wir quasi nur IT-Projekte haben,
aber ich
sehe das bei unseren Kunden durchaus,
dass das ja dann nochmal mehr oder
weniger getrennt ist und dass
IT Sachen machen muss, wo Business
sagt, wofür brauchen wir das, aber es ist halt notwendig.
Also ich sehe das im Prinzip
so auch, gerade die ungeplante Arbeit
dann im Rahmen von Änderungen gerne
vor allem. Ja.
Über die man halt erst stolpert, wenn
ja, wenn sie dann vor einem
steht und es nicht weitergeht.
Ja, dann wird das ja in dem Buch sehr schön
dann weiterentwickelt, wie man mit dieser
ungeplanten Arbeit umgehen sollte,
dass man die eliminieren sollte,
Engpass-Theorie und so weiter.
Jetzt hast du natürlich
nicht den direkten Bezug zu
DevOps. Wäre das denn, oder ist das
für dich nachvollziehbar aus dem Buch, wo das
im Buch so erklärt wird, auch wenn
es ein Roman ist?
Ja, also
ich finde das auch gut.
In meinem Umfeld
wird jetzt gerade damit begonnen
im Prinzip, das möglichst tatsächlich
zu automatisieren, zu gucken, wo bleibt es denn
hängen.
Dieses Continuous Integration,
Continuous Deployment
wird versucht anzustreben
im Rahmen des historisch machbaren
oder aus historischen Gründen
eingeschränkten.
Und da sehe ich auch, dass tatsächlich es
anscheinend wirklich gut ist, wenn eben
der Bild plötzlich nicht mehr vier Stunden,
sondern nur noch eine dauert,
um eben mal schneller zu testen,
ob das, was man da eingecheckt hat, in Ordnung ist.
Da sind wir halt noch nicht bei
irgendwie,
und bevor ich eingecheckt habe,
ist auf jeden Fall alles einmal durchgelaufen.
Aber ich sehe das auch so.
Und auch die ungeplante Arbeit,
dass es gut ist, die zu
reduzieren durch
vor allem automatisieren und vereinfachen.
Das denke ich auch.
Ja, nun wird ja in Ihrem Buch
immer die Parallele
bezogen quasi, dass die IT
ja eigentlich genauso arbeiten könnte,
genauso arbeiten sollte und organisiert
werden sollte, wie ein
Produktionsunternehmen. Und dann
kenne ich den einen oder anderen ITler, der sagt,
nein, nein, nein, nein, das ist bei uns alles ganz anders
und wir sind ja Wissensarbeiter.
Wie stehst du zu dieser
Übertragbarkeit?
Ich denke, es gibt ja nicht schwarz und weiß.
Ich denke, man kann sich
viele Anregungen
vom Band holen,
aber eben
nicht alles tatsächlich, weil es dann doch
also ich kann mir eher vorstellen, dass es
es ist ja noch mehr Kreativität dabei
als beim reinen Herstellen nachher.
Und es passieren, glaube ich, auch eher
ungeplante Dinge als beim Herstellen.
Was hoffentlich dann nach
einer Einschwingphase dann so läuft,
wie man es sich vorstellt.
Wo man dann noch optimieren kann.
Aber ich habe das Gefühl, im
IT-Umfeld sind
eher immer wieder mal etwas andere Dinge.
Es gibt immer wieder mal was Neues.
Aber
dieses
das kann ja gar nichts, ist überhaupt nicht so wie
im herstellenden Bereich. Das finde ich
eben nun auch nicht. Also ich denke schon, dass man da vieles
also zumindest, dass man sich inspirieren
lassen kann davon, ja.
Also im DevOps-Handbuch wird da noch mehr
drauf eingegangen, auf diese Enden-Cord und sowas.
Das ist vielleicht gar nicht so schlecht.
Ich denke nur, das Verhältnis
zur
Produktionsstraße ist dann doch
ein bisschen anders, was Änderungen angeht.
Also die Häufigkeit von Änderungen.
Ja, okay. Du hast das
zweite Buch angesprochen, das DevOps-Handbuch.
Du hast ja auch gesagt,
da gibt es dann nochmal so ein bisschen Erläuterungen
dazu. Das heißt, jemand,
der diese Aha-Effekte hatte
aus dem Phoenix-Project, das, was die ja auch
als, was die Autoren ja auch wollen,
der kann diese Aha-Effekte auch im DevOps-Handbuch
quasi nochmal vertiefen.
Ja, ich denke, das
Phoenix-Project, das ist
quasi zum, ja, damit die Leute sagen,
Mensch, das ist ja tatsächlich so wie bei uns.
Aber wenn man sich dann ernsthaft damit
befassen will, dann muss man eigentlich das
DevOps-Handbuch dazu lesen. Das ist dann
das, was tatsächlich die Grundlage bietet.
War eine von den, oder eins von den
beiden Büchern einfacher zu übersetzen, oder
nimmt sich das nichts?
Unterschiedlich einfach. Also das
DevOps-Handbuch ist ja nun wirklich
eher ein Fachbuch und
ich will jetzt schon mal sagen, Fachbücher
lassen sich im Allgemeinen, wenn man
das Thema halbwegs beherrscht,
leichter übersetzen. Während der,
das Phoenix-Project halt als Roman,
da ist es, dann geht es mal flapsiger zu, dann
werden lustige Sachen gesagt.
Das ist, ich finde es anspruchsvoller.
Also ich finde, bewundere auch jeden
ernsthaften Literaturübersetzer, weil das
dann nochmal ein ganz anderes Niveau ist, meiner Meinung nach.
Ja. Und das
Phoenix-Project ist jetzt keine hohe Literatur,
aber es ist, ich fand es einfach
in der Hinsicht anspruchsvoller.
Ja, wir haben jetzt eben so ein paar über die Charaktere
des Phoenix-Project gesprochen. Wir haben
über die
vier Arten von Arbeit gesprochen.
Und dann ist natürlich noch,
ich finde, ein ganz wichtiger Punkt, das sind, so ist
dieses Drei-Wege-Modell von dem,
Kim, kannst du da mal was zu erläutern?
Ja, im Prinzip
gibt es einmal den,
muss man sehen, dass man seine Arbeit
quasi in den Flow kriegt, dass die
also eben läuft, durch
Automatisierung, dass nicht die Sachen
dauernd in irgendwelchen Queues hängen und darauf warten,
dass der Nächste sich darum kümmert.
Ich glaube, das ist auch ein zentraler Punkt von diesem
ersten Weg, dass es einfach
gar nicht das Problem ist, irgendeine
Aufgabe mal schnell zu erledigen, sondern dass
das Problem ist, wenn die Aufgabe von vier Leuten
nacheinander erledigt werden muss, dass dann
die immer viel zu lange in irgendwelchen Warteschlangen
rumhängt.
Der zweite Teil ist dieses,
dass man kontinuierlich Feedback
braucht, um eben den Prozess
wiederum zu verbessern, um
zu erfahren, der, der nach mir
damit zu tun hat, kämpft immer wieder und dann
wäre es vielleicht besser, wenn wir da was anpassen könnten.
Und das dritte ist immer
kontinuierliches Lernen, Experimentieren,
wenn man irgendwelche Sachen
erforscht, dass man dabei möglichst wissenschaftlich
vorgeht und nicht nur nach Bauchgefühl.
Das sind im Prinzip diese
drei Wege, denen man nach und nach
folgen soll. Also erstmal den Flow einrichten,
Flaschenhälse erkennen, Batchgrößen
reduzieren, dann Feedback
regelmäßig einholen und das
auch berücksichtigen und
dann gucken, dass alles, was man
auch im Kleinen herausbekommen hat, dass
das für alle hilft und alle davon
profitieren können und lernen können.
Ja, okay. Wenn du jetzt diese
drei Wege so mal vergleichst
oder die mal so betrachtest,
denkst du, dass man die quasi sozusagen nacheinander
durchschreiten kann oder
wie kann ein Unternehmen
quasi mit diesen drei Wegen arbeiten?
Kannst du dir da was vorstellen?
Also ich würde mal sagen, die bauen
aufeinander auf. Also
ohne einen vernünftigen Flow
braucht man mit dem, also
helfen die nächsten beiden Schritte dann gar nicht mehr
so sehr, weil dieses
Feedback einholen ist
natürlich immer sinnvoll, aber
wenn man dadurch seinen Flow
verbessern kann und den gesamten
diesen Ablauf dann
fehlerfreier oder schneller machen kann, für
alle, dann hilft
das erst dann richtig.
Und das Lernen und Experimentieren
ist natürlich auch immer sinnvoll, aber auch da
denke ich, dass das
auch vom Flow und von dem Feedback dann
auch, also dass es
dann am besten funktioniert, wenn man das
als Grundlage hat schon.
Ja, okay.
Du hast eben so ein schönes Wort gesagt, Lernen und
Experimentieren. Nun sind
ja nicht alle Unternehmen so erfreut
drüber, dass man eine
Fehlerkultur einrichten muss, dass man
experimentiert und so weiter.
Was hast du aus dem Buch da
so ein paar Dinge rausgezogen, wo
du für dich abgerechnet hast? Das
macht eigentlich Sinn, mit so einer Kultur zu
arbeiten? Ja, ich
also ich habe das nach
dem Buch, sehe ich das noch eher, dass das sinnvoll
ist. Wir haben das auch schon bei uns
im Umfeld schon mal vorher versucht und
ich würde sagen, man kann
das, wenn man die Möglichkeit hat, auch im
Kleinen durchaus versuchen, im eigenen Team,
wenn einem das von außen auch
ermöglicht wird, aber
wenn die so insgesamt in der Firma
das nicht, sagen wir mal, honoriert
oder unterstützt wird, dann ist das natürlich
schwierig. Dann kann man das für sich vielleicht
einfach zum eigenen Vorteil nutzen oder zum
Vorteil des eigenen Teams dann was machen, aber
ich glaube, das bringt nur dann was, wenn man,
wenn das tatsächlich akzeptiert wird, auch von
außen, auch nach außen hin, also nach außen
heißt außerhalb des Teams oder außerhalb einer Abteilung
oder so. Ja. Denn das
bringt nicht so viel, wenn man irgendwie zwar selbst
dann so vorgeht und
sagt, es tut uns leid, wir
haben jetzt gesagt, wir können nur das und das machen,
das andere wird zu viel und dann gesagt wird, ist ja schön,
aber wir brauchen es trotzdem. Und man es dann
doch machen muss, notgedrungen.
Es muss schon sein, dass so weit
wie möglich das umgesetzt werden kann
und man nicht nur mit seinen eigenen zehn Leuten
oder so das versucht umzusetzen,
weil dann klappt es meistens
auf Dauer doch nicht, weil man ja mit den anderen doch
interagieren muss. Ja, ich
empfehle in meinen DevOps-Trainings
immer das Buch als Lektüre
und eigentlich würde ich mich so hinstellen
und sagen, das sollte eigentlich eine Standardlektüre
für IT-Manager
sein.
Nein. Siehst du das auch so,
abgesehen davon, dass du vielleicht als Übersetzer ein bisschen
voreingenommen bist?
Ja, würde ich auch sagen. Also natürlich
bin ich auch voreingenommen, aber
würde das auch tatsächlich jedem ans Herz
legen und durchaus auch
auch Managern ans Herz legen,
die mit IT zu tun haben, eben im
Business-Umfeld. Ja.
Vielleicht auch, um damit ein bisschen mehr
Verständnis zu wecken. Und
denkst du, dass man dann,
wenn man in den Situationen ist, die du
eben gerade beschrieben hast, dass es
eben nicht ausreicht, wenn ein Team alleine
sich so aufstellt,
wenn es quasi zum Business oder so
eben genau die Schwierigkeiten hat, dass man
dann sagt, hier, lest euch mal das Buch
durch und dann reden wir weiter. Also glaubst du,
dass man mit dem Buch auch Überzeugungsarbeit
leisten kann, konkret?
Ich glaube schon. Ich weiß, ich glaube
auch, da hängt es dann wieder von der Firmenkultur
ab, inwieweit nachher
nicht gesagt wird, ja, da habt ihr schon recht,
aber es hilft uns nicht, weil wir brauchen
es trotzdem. Und ich glaube, es mag
bestimmt Firmen geben,
die dann sagen, stimmt, habt ihr recht, lasst uns das mal
probieren. Aber ich fürchte, es gibt auch welche,
die dann sagen, das ist doch alles
Quatsch, wir brauchen das jetzt einfach und seht zu,
wie ihr fertig werdet. Ja, gut.
Gibt es noch andere Punkte, die du dir
so aus diesem Buch herausgezogen
hast, die du von dir aus noch so ein bisschen
darstellen würdest? Also ich
fand interessant, wie sie halt
beim Deployen immer am Anfang
sehr gehadert haben und nachher immer
noch gekämpft haben, aber es dann besser wurde.
Das sehe ich
bei mir im Umfeld auch tatsächlich so und
das fand ich durchaus
interessant, wie das da ablief.
Also ich meine, bei uns ist es nun nicht mehr so,
dass irgendwie dann sich morgens die Pizzaschachteln
stapeln, aber
es wurde doch früher
mehr gekämpft. Mittlerweile wird es halt besser,
weil mehr automatisiert ist, weil
tatsächlich in kleineren Einheiten
deployed wird.
Und uns hilft natürlich noch ein bisschen das in dem Umfeld, wo ich
tätig bin. Was wir machen,
wird erstmal von anderen genutzt
und das, was die machen, wird dann wiederum
von anderen genutzt und das erst geht an den Kunden,
letztendlich, wirklich ernsthaft.
Da haben wir natürlich immer noch einen gewissen
Puffer.
Wobei natürlich das Ziel ja wäre, dass
wenn ich da, ich, klar, ich kenne euer
Umfeld nicht, aber letztendlich wäre ja das
Ziel, dass ihr das, was du machst,
in einem Team passiert, was direkt mit
dem Kunden interagiert.
Das stimmt, aber dafür
sind wir zu groß, würde ich
vermuten, um das direkt zu machen.
Es gibt bei uns auch Gruppen, die
näher, also die
letztendlich, sagen wir mal, auch UI-Entwicklung
machen und trotzdem nah am
Kunden sind, aber
ist halt, ich glaube,
ab einer gewissen Größe, auch ab einer gewissen,
sagen wir mal, Entwicklungsgröße,
wird es dann tatsächlich schwieriger, weil
zumindest ich sehe dann durchaus, dass es auch
von Vorteil ist, wenn man
mehr Schichten hat, in denen das
vorgegeben ist, in denen, wenn man sagt,
die Buttons müssen ein bisschen anders werden,
dass dann auch alle Buttons anders werden und man
nicht die halben Entwicklermannschaft anschreiben
muss, dass sie jetzt alle bitte was anpassen sollen.
Also,
da,
ich glaube, irgendwann wird es dann schwierig,
einen guten Weg
zu finden zwischen, es muss alles
exakt vorgegeben
sein, wie etwas umzusetzen ist
und
es wäre schön, wenn das
halt nah am Kunden ist. Da muss man irgendwie
einen Zwischenweg finden, der, glaube ich,
nicht immer geht.
Ja, ich glaube auch, dass es gar nicht
den Zwischenweg gibt oder den
goldenen Mittelweg. Das muss ein Unternehmen
für sich herausarbeiten.
Muss man auch einfach mal ein bisschen organisatorisch
probieren und dann glaube ich auch, dass es
auch immer wieder so Pendelbewegungen gibt.
Das heißt, man probiert das mal aus.
Man hat ein paar Erkenntnisse, man hat Erfolge,
man hat auch Restriktionen, die man
dann eben bemerkt und dann muss man eben
gegensteuern oder weiterentwickeln
und denke mal,
das ganze Thema agile Entwicklung
und das ist ja die Basis von DevOps,
zumindest im Development-Bereich,
ist ja, glaube ich,
auch das Thema, wie skaliere ich das?
Wie gehe ich jetzt mit mehr als neun oder
zehn oder elf Entwicklern um?
Das, glaube ich, ist ja auch die große Herausforderung
für viele andere Unternehmen, wenn ich noch
nicht mal den Betrieb mit dazu nehme.
Also rein nur, wie skaliere ich agile
Entwicklungsteams, wenn ich wirklich ein paar mehr
Leute dabei habe?
Ja, also ich habe schon das Gefühl, dass es sinnvoll ist,
dass die möglichst autark agieren können.
Aber wenn man halt in einem
Umfeld tätig ist, in dem man
noch viel mehr beachten muss
oder in dem noch viel mehr Leute mitspielen,
dann wird es halt schwierig.
Oder wenn es darum geht, zum Beispiel
eine Barrierefreiheit sicherzustellen,
dann ist es natürlich
gut, wenn die dann trotzdem auf alles
achten und nicht sagen, ach, das machen wir nächstes Mal, weil
das können wir jetzt gerade nicht.
Ja, okay. Wenn ich mal ein bisschen auf das
schaue, was du in deiner
Brotarbeit genannt
tust, wenn du an deine Kollegen
denkst oder auch an dich,
würdest du das Buch oder hättest du das Buch gelesen
oder gekauft
oder glaubst du, dass das halt ein Buch ist, was
für einen Entwickler vielleicht gar nicht mal
so interessant ist?
Ich glaube,
interessant ist es. In meinem
speziellen Umfeld sehe ich
jetzt nur eher, dass
das jetzt
auch tatsächlich, was da drin steht, mehr oder
weniger, sagen wir mal, verfolgt wird. Also
jetzt weniger das wirkliche DevOps,
aber so ein Continuous Delivery,
dass das angestrebt
wird und anscheinend auch gut ist.
Ja, okay, gut.
Hast du noch andere Punkte, die so für dich,
die du rausgezogen hast, die du auch vielleicht mit deinen
Kollegen besprochen hast, die du in deiner Arbeit
eingebracht hast?
Also ich habe mich neulich mit unserem Architekten
unterhalten, gerade da über das,
über den Podcast auch und
über das DevOps und da
kamen wir halt auch drauf, dass
das halt gewisse Grenzen
gibt, was ich vorhin schon sagte mit UI-Tests.
Ist alles möglich, aber wird
dann halt irgendwann ganz schön teuer.
Wo ich mich dann frage,
ist das dann einfach so teuer, wenn man es
ordentlich machen will oder muss man in Kauf nehmen,
dass man dann irgendwo dann unsauber wird?
Das geht jetzt in dem Buch natürlich ein bisschen
unter, weil da geht es um dieses schwierige,
schwierige Aspekte weniger.
Ja, ja.
Das sind ja eher Sachen, die sich leichter machen
lassen. Ich könnte mir auch vorstellen,
dass das dann, dann gibt es vielleicht schon
einen Business Case, der irgendetwas durchrechnet,
aber der geht ja immer nur von irgendwelchen Annahmen
aus. Das heißt, vielleicht wird es
dann so sein, dass ein Team sich so entscheidet,
also wenn sie autonom entscheiden
können und ein anderes Team oder
ein anderer Bereich wird anders entscheiden.
Also das würde ich jetzt mal so tippen,
weil ich glaube nicht, dass es genau die Wahrheit
gibt, die man auch im Vorfeld
genau berechnen kann.
Ja, natürlich. Also
ich denke, das Autonome, das finde ich
gut. Das scheint auch bei uns
so mehr oder weniger zu funktionieren
oder das zumindest
hingenommen wird, wenn dann die
Product Owner
aus einzelnen Bereichen sagen, das ist
gut, das machen wir. Das hört sich zwar auch gut an,
aber das können wir einfach im Moment nicht machen. Und dann
wird das auch akzeptiert. Das mag
dann aber eher an der Kultur liegen der Firma
und weniger daran,
wie gut man dadurch vorankommt, weiß ich natürlich nicht.
Ja, wir haben ja schon einiges
rausgezogen aus dem
Phoenix Project. Gibt es noch andere
Punkte, die du hast, Thomas? Vielleicht auch aus
dem DevOps-Handbuch? Also aus
dem Phoenix Project finde ich
eigentlich gut und ich glaube auch
hilfreich in der täglichen Arbeit ist, dass
versucht wird, Aufgaben sichtbar
zu machen. Dass man sich wundert,
warum irgendwas denn dann zwei Wochen dauert, wo das
doch nur eine kleine Änderung ist
und dass man das mal zeigt,
aus wie vielen Schritten das besteht, wie viele Leute
beteiligt sind, damit dann auch
vielleicht eben die Stakeholder
aus dem Business sehen, oh, okay, ja,
das ist jetzt doch nicht so einfach, wie ich dachte.
Das
ist, glaube ich, was, was
helfen kann. Zumindest kann man
sich dann besser fühlen, wenn man das mal gemacht hat und
die anderen sagen, ist mir egal, ich will es trotzdem,
dann kann man zumindest, ist man sich sicher,
dass man sich nicht da vertut und sich
nicht wundert, warum das alles so lange dauert.
Und
die technischen Schulden, dass
man die tatsächlich angehen sollte, das ist, glaube
ich, eher aus dem DevOps-Handbuch,
dass man, wenn man mal schnell was
macht, das ist in Ordnung, aber
das kommt irgendwann wieder meistens
und dann tut es richtig weh.
Das sehe ich auch tatsächlich bei mir im Umfeld.
Ja.
Man baut Sachen ein, die irgendwie
in dem Moment gerade geholfen haben,
aber sich im Nachhinein
nur ganz schlecht wieder rausnehmen lassen und dann
alle ärgern. Und die
muss man regelmäßig, glaube ich, angehen, um die
abzuarbeiten. Ja,
was ich so an dem Begriff der technischen
Schulden auch so schön finde, ist,
dass man damit,
wenn das Business
darauf eingeht, dass man denen damit das
erklären kann. Also ganz
klar, Business, wenn du das haben willst,
lieber Stakeholder, das können wir machen,
aber wir bauen eben Schulden auf damit.
Das ist genauso, als wenn du dir jetzt ein Haus
kaufen würdest. Du kannst dir Geld
von der Bank leihen, dann musst du einfach
Zinsen bezahlen. Du hast Schulden, die du
abstottern musst. Und wenn du kein Geld
verdienst, dann wird das Haus auch gepfändet
und so weiter. Also dieser Vergleich
zwischen technischen Schulden und der
Realität finde ich sehr, sehr schön,
Idee. Und ja, das sehe ich
wie du. Das wird sehr schön beschrieben,
sehr schön plastisch beschrieben.
Ja, und was ich auch einen tollen
Schritt fand, da weiß ich
nicht, wie realistisch das machbar ist, ist,
dass die mal eine Zeit lang sagen, wir machen gar nichts
Neues. Wir bauen jetzt mal zwei Wochen lang oder so,
wie lange das war, alles ab. Oder versuchen
zwei Wochen lang nur Sachen zu erledigen, die
wir schon immer mal machen wollten oder immer mal
machen mussten eigentlich, um
damit eben dann ordentlich Schulden abzuarbeiten.
Irgendwann geht es wahrscheinlich, kommt man nicht
drum rum, dann wieder neue Sachen zu machen. Aber
ich denke, das ist
was, was ich zumindest sehr
charmant finde und sehr hilfreich.
Also
ich habe das einmal erlebt bei
einem Scrum-Team, die
wirklich einen Sprint von zwei Wochen, also
das war wirklich eine sehr überschaubare
Größe, dass sie in einem
Sprint von zwei Wochen sich mal nur
um die Problems gekümmert haben.
Also nur darum mal gekümmert haben,
Bugs zu beseitigen,
die sie immer wieder mit Workarounds gefixt
haben und wo sie gesagt haben, wenn wir da mal
Zeit hätten, dann könnten wir das mal
richtig beseitigen. Und die Zeit hat
man ihnen in der Entwicklungsphase
nicht gegeben. Aber als dann so ein gewisses
Grundgerüst da war, da haben sie wirklich
dann mal in einem Sprint von
zwei Wochen wirklich nur
Storys bearbeitet, die eben diese klassischen
ITIL-Problems beseitigt
haben oder nur daran gearbeitet.
Und das Schöne fand ich jetzt auch
im Vergleich dazu,
das ist im Buch ja auch so beschrieben,
dass das quasi auch aus dem Team herausgekommen
ist. Das Entwicklungsteam hat keine
Ahnung von ITIL gehabt. Die haben sich nicht um
IT-Service-Management gekümmert.
Die haben aber einfach für sich
gesagt, wir haben jetzt hier wieder einen Bug,
den haben wir beseitigt, Quick und Dirty,
weil wir ihn schnell beseitigen müssen.
Lieber PO, das sollten
wir mal in Ruhe angehen und eben
genau diese Schulden beseitigen.
Also ein Beispiel habe ich so
für diese zwei Wochen.
Ob das Team so ganz glücklich war, sich zwei Wochen
nur darum zu kümmern, das weiß ich jetzt gar nicht
mehr, weil man ja eigentlich
versucht, das immer so ein bisschen zu mischen an der Stelle.
Ja, das ist natürlich
auch eine Variante, dass man tatsächlich, wenn man das
kann, so und so viel Prozent
der Kapazität
der eigenen dafür dann
pro Sprint beiseite zu legen
und dann das immer wieder was, also
quasi kontinuierlich was zu machen.
Das ist, denke ich, die andere Variante. Aber ich könnte
mir vorstellen, dass man so, und wenn man es nur einmal
im Jahr macht, irgendwann in der Zeit,
wo dann gerade mehr oder weniger
es etwas ruhiger ist,
dass man dann einfach Sachen mal abarbeitet.
Ich glaube, das tut einem auch gut. Natürlich ist das
spannend, da neue Sachen zu machen, aber
ich glaube, man fühlt sich danach richtig gut, wenn
man dann mal Sachen ordentlich gemacht hat
wieder. Ja, also ich habe
schon einen oder anderen Entwickler getroffen,
der gesagt hat, technische Schulden
sind mir suspekt. Also der fand
diesen Begriff gar nicht gut an der Stelle, aber ich glaube,
das sind ganz wenige Entwickler, die so denken.
Ja, ich glaube aber, also der
Begriff ist, da kann man bestimmt auch darüber diskutieren,
aber ich glaube, was dahinter steckt, das dürfte
fast alle stören. Ja, okay.
Ja, klar, natürlich. Also dieses,
mach mal schnell,
das stimmt schon so.
Ja, und was
auch noch ein Aspekt von dem Buch ist, ist dieses
Change Management, was
manchmal dann vielleicht ein bisschen eskaliert,
aber was
in einem gewissen Rahmen, glaube ich, tatsächlich
notwendig ist, um eben
zu vermeiden, dass der eine eine Änderung
macht, die dann alles andere
kaputt macht, aber
ihm ist das gar nicht bewusst vorher.
Ich glaube, das kann man nicht ganz
vermeiden, weil sonst landet man
nachher in einem wirklich bürokratischen Monster.
Aber so in einem gewissen Rahmen
ist das, denke ich, sehr hilfreich und kann
viele Situationen entschärfen.
Ja, ich glaube, dass du mit dieser Aussage,
die ja von einem Entwickler
kommt, vielen
Leuten aus dem IT-Service-Management
und IT-Umfeld aus der Seele gesprochen hast,
weil die natürlich
sich jetzt auch fragen, ja, das ist ja wunderschön,
alles agil, alle schöne bunte Zettel,
alles visuell, aber wir brauchen auch
ein paar Prozesse und das glaube ich auch, das ist einer
der Prozesse, der unheimlich wichtig
ist und den man nicht einfach abschaffen
kann. Also selbst wenn man die Verantwortung
in Teams gibt, ein paar Sachen
muss man schon noch über Prozesse
regeln und ja, das ist, denke ich, einer
der Kernprozesse, die man
trotzdem geregelt kriegen muss, auch
wenn man die Teams eben autonom
aufstellt und eine andere
Art der Arbeit propagiert.
Ja, ich glaube, das ist auch so ein bisschen, also das
jetzt im Phoenix-Projekt kommt das, glaube ich, mehr oder weniger
kaum vor, so ein Scrum of Scrums oder
wie das manchmal genannt wird.
Das ist ja auch nicht Thema des Buches, aber
auf jeden Fall muss, glaube ich, jede
Firma oder jede Organisation
irgendwie für sich einen Weg finden,
diese möglichst
autonom agierenden Sachen trotzdem
zu organisieren.
Das ist richtig, das stimmt, ja.
Und klar, man muss natürlich die Dinge auch
zusammenbringen und das ist eben im Kleinen
wie im Großen zu tun. Also insofern,
ja, die Frage ist, wie man es
organisiert, aber du hast auch recht, im
Buch war es nicht das Thema und unser Thema
ist ja das Buch. Also insofern,
ich glaube, wir haben ziemlich viel,
ähm, angesprochen aus dem Buch und
ich hoffe auch, dass wir, ähm,
dem einen oder anderen, der das Buch noch nicht gelesen
hat, so ein bisschen das in den Mund fässrig
gemacht haben. Was mich eben
bei diesem Buch begeistert hat,
war, dass ich diesen Aha-Effekt
hatte. Den Aha-Effekt, den die vier Autoren
sehr schön zu Anfang in ihrem Vorwort
beschreiben, dass die alle irgendwann
so einen Aha-Effekt hatten und gesagt haben,
hey, wir müssen das anders
machen. Und, ähm, ich hatte
quasi nach dem Lesen des Buches meinen
Aha-Effekt. Ähm,
wie sieht das bei dir aus? Hast du auch deinen Aha-Effekt
bei der Übersetzung gehabt oder
hast du den vielleicht schon vorher gehabt?
Ich,
wir haben vorher schon zum Teil agil
gearbeitet. Da hatte ich schon viel
Aha. Ähm, und
beim Automatisieren von Tests
und all solchen Sachen, das ist
also beim Buch selbst jetzt gar nicht so
sehr, da hatte ich eher Wiedererkennungseffekte,
dass ich gedacht habe, hey, das kennst du doch von irgendwo her.
Und wenn es vor zehn Jahren ist oder so, also ich habe
auch schon in kleinen Firmen vorher gearbeitet, da
ist das dann nochmal anders Aha gewesen.
Und ich habe, ich habe jetzt im Nachhinein
diesen Aha-Effekt, wo ich in meinem Umfeld sehe, wie
Dinge aus, die in dem Buch vorkommen,
auch in
meinem Umfeld versucht werden, umzusetzen.
Und
das finde ich dann, da denke ich,
ach, guck mal an, das kenne ich doch irgendwo her.
Ja, okay. Also bei mir ist das jetzt so ein bisschen
verzögert, weil ich selbst
weniger
damit zu tun hatte bisher, sagen wir so.
Aber ich kannte halt von
früher vieles und ich sehe jetzt in meinem Umfeld,
dass durchaus da Aktivitäten,
Ablaufen, die dem aus dem
Buch oder aus dem DevOps-Handbuch auch
durchaus entsprechen. Ja,
okay. Ja, das ist doch schön. Also insofern ist
das schon ja schon ein bisschen Bezug zur Praxis
oder vielleicht nicht nur ein bisschen, sondern ein bisschen mehr auch.
Gut, das heißt also,
einwandfreie
Kaufempfehlung für das Buch,
wie gesagt, auch wenn du,
wenn du, für beide ja eigentlich,
für beide, also das denke ich, müssen wir mal
festhalten. Wir haben zwar das Phoenix Project
als Aufhänger genommen, aber ich glaube, es ist
auch rausgekommen, dass das Phoenix Project,
diese Aha-Effekte produziert,
die die Sache einfach ein bisschen plastischer
und lesbarer näherbringt
und wer wirklich tiefer einsteigen will
und Praxis haben will, der braucht natürlich
das DevOps-Handbuch. Ja, das
auf jeden Fall. Also ich würde das
Phoenix-Handbuch tatsächlich jedem ans Herz
legen, eigentlich, der mal länger im IT-Bereich
gearbeitet hat oder mit
IT zu tun hat. Das DevOps-Handbuch
ist, glaube ich, also
wenn man sich ernsthaft damit danach dann damit
befassen will, dann ist das DevOps-Handbuch auch
unvermeidlich, unverzichtbar.
Aber dann wirklich, weil wenn man
damit was, wenn man sich da richtig mit,
wenn man da richtig einsteigen will.
Ja. Gut.
Thomas, dann danke ich
dir für diese schöne dreiviertel
Stunde. Ich fand das sehr, sehr kurzweilig.
Ich glaube, das haben wir sehr gut hinbekommen.
Und würde sagen,
viel Spaß und Erfolg mit
den weiteren Büchern. Ich hoffe, da kommt noch
ein bisschen was vom Gene Kim
für das Thema DevOps. Und
dann bis zum nächsten Mal.
Ja, vielen Dank für die Einladung. Ich habe mich auch
sehr gefreut.
Vielen Dank.

Folge 7: DevOps bei der SwissRe

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

DevOps in der Praxis: Wie wird DevOps bei einem der größten Rückversicherer der Welt umgesetzt? Wir haben Tobias Weinmann zu Gast im Podcast.

Inhalt

  • Vorstellung von Tobias Weinmann und seiner Rolle bei Swiss Re
  • Definition und Bedeutung von DevOps-Transformation
  • Die „Three Ways“ im DevOps-Kontext: Flow, Feedback, und kontinuierliches Lernen
  • Einsatz und Herausforderungen von Cloud-Technologien bei Swiss Re
  • Der Ansatz von Swiss Re zur DevOps-Transformation, inklusive Bottom-Up und Top-Down Strategien
  • Konkrete Beispiele für DevOps-Initiativen: Value Stream Mapping, Lean Change Management, Minimal Viable Processes
  • Diskussion über die Rolle von Technologie und Kultur in der DevOps-Transformation
  • Der Umgang mit Legacy-Systemen und neuen Applikationen im Kontext von DevOps
  • Die Rolle der Cloud im DevOps-Ansatz von Swiss Re
  • DevOps als Balance zwischen IT-Service-Management, Lean-Management und agilem Vorgehen
  • Gesamtbild der DevOps-Reise bei Swiss Re

Shownotes

  1. DevOps-Transformation bei Swiss Re
  2. „The Phoenix Project“ Buch (https://itrevolution.com/book/the-phoenix-project/)
  3. „DevOps Handbook“ Buch (https://itrevolution.com/book/the-devops-handbook/)
  4. Swiss Re Unternehmen (https://www.swissre.com/)
  5. Definition und Prinzipien von DevOps
  6. Agile Methoden und Scrum
  7. Cloud-Technologien in der Versicherungsbranche
  8. IT-Service-Management
  9. Lean-Management
  10. Minimal Viable Architecture und Prozesse
  11. Datenbankmanagement und Automatisierung
  12. Continuous Integration und Continuous Deployment (CI/CD)
  13. Value Stream Mapping
  14. Lean Change Management

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
Hallo und herzlich willkommen zum DevOps-Podcast auf die Ohren und ins Hirn.
Ich begrüße Sie. Mein Name ist Dirk Söllner.
Wir haben hier heute zu Gast den Tobias, der von der Swiss Re sich gleich vorstellen wird,
wenn ich sage, wir ist das Alex Lichtenberger, mit dem ich gemeinsam diesen Podcast erstelle.
Also insofern würde ich sagen, Tobias, stell dich doch einfach mal bitte kurz vor.
Ja, hallo. Mein Name ist Tobias Weinmann.
Wie Dirk schon gesagt hat, ich arbeite für einen der größten Rückversicherer weltweit bei der Swiss Re.
Und ich habe dort die ehrenvolle Aufgabe, mich Vollzeit dem Thema DevOps zu widmen,
was ich seit ein bisschen mehr als einem Jahr jetzt mache und befinde mich dort auf einer sehr spannenden Reise.
Oder wir als Unternehmen befinden uns dort auf einer sehr spannenden Reise.
Ein bisschen zu meinem Hintergrund.
Ich bin schon sehr lange bei der Swiss Re, habe einige Sachen gesehen.
Ich habe in der Entwicklung, Softwareentwicklung angefangen und hatte dann,
von diversen Verantwortlichkeiten auch im betrieblichen Umfeld,
war unter anderem verantwortlich für die ganzen Entwicklungsplattformen, Versionskontrollsysteme, CICD-Systeme und so weiter.
Und ja, bin jetzt, wie gesagt, dort gelandet, DevOps Transformation Lead in einer vergleichsweise großen IT-Organisation.
Und vielen Dank, Tobias. Herzlich willkommen auch von meiner Seite.
Mein Name ist Alex Lichtenberger.
Vorstellen muss ich mich, glaube ich, nicht mehr.
Heute haben wir ja das Thema DevOps Transformation bei der Swiss Re.
Das heisst, ein Praxisbeispiel aus der Unternehmenswelt.
Und ja, bevor wir da reingehen, wir haben ja immer zu diesem Running Gag oder die Standardfrage an unsere Gäste,
dieses Mal auch an dich, Tobias.
Was verstehst du unter DevOps Transformation?
Unter DevOps, kann man das überhaupt definieren, oder wie würdest du das definieren?
Ich versuche es mal mit nur zwei Worten.
Nachhaltige Geschwindigkeit.
Also nicht Geschwindigkeit oder Schnelligkeit um jeden Preis, sondern,
und auch nicht sicher und stabil, egal wie lange es dauert, sondern eben beides zusammen.
Also für mich ist DevOps eigentlich ein Optimieren für die Geschwindigkeit.
Oftmals für mich ist es ein Optimieren für die Geschwindigkeit.
Oftmals für mich ist es ein Optimieren für die Geschwindigkeit.
Oftmals für mich ist es ein Optimieren für die Geschwindigkeit.
Oft Janeiro.
Wird es auch mit der Idee assoziiert, Optimierungen für Kosten?
Wird es auch mit der Idee assoziiert, Optimierungen für Kosten?
Sehe ich aber nicht so.
Ich sehe wirklich Optimierungen für der Geschwindigkeit.
Aber halt nicht um den Preis von Qualität, Sicherheit und Compliance.
Und wenn ich noch ein bisschen weiter ausholen darf.
Also ich sehe, also den Startpunkt, wie muss auch so in der Lektüre viel sieht wirklich auf diesem Cor.
Country Konflikt.
Also wenn man mal die Top-Prioritäten aus IT-Executive-Sicht anschaut,
es ist natürlich Rapid Change, also wir wollen eigentlich schnelle Veränderung,
aber gleichzeitig wollen wir Stabilität, Zuverlässigkeit, Sicherheit und so weiter.
Also so die funktionalen und nicht-funktionalen Aspekte.
Und jetzt ist es aber typischerweise so, dass halt die Leute, also Teile der Organisation,
sich eher in diese Richtung Rapid Change orientieren
und andere Teile in der Organisation Richtung Stabilität, Zuverlässigkeit und Sicherheit.
Und wenn halt nicht da alle wirklich an einem Strang ziehen,
findet man sich möglicherweise dann halt in so einer Abwärtsspirale,
die ja auch oft beschrieben wird in einem DevOps-Kontext.
Also man macht dann tatsächlich die schnelle Veränderung,
aber die Systeme werden eben nicht stabiler und zuverlässiger und sicherer,
sondern das Gegenteil ist der Fall.
Und dann werden oft die Kontrollen hochgefahren
und im Endeffekt wird man eigentlich langsamer und nicht schneller,
wenn man nicht die Sachen wirklich konsequent gemeinsam adressiert.
Und wenn man auf die Three Ways schaut, für all die,
die das Phoenix Project oder das DevOps Handbook gelesen haben,
das sind für mich auch sehr zentrale Themen.
Also der erste Weg.
Die Principles of Flow oder auch anders gesagt,
die systemische Sicht, Systems Thinking.
Da geht es natürlich um Sachen wie Limit, Work in Progress oder Release Cadence.
Aber für mich ist da wirklich ein zentrales Thema,
auch mit Silos zu brechen und wirklich zu schauen,
dass sich halt alle an einem schnellen Fluss orientieren.
Also dass man wirklich auch sagt,
Sicherheit oder Compliance sind wichtige Themen,
aber nicht zu jedem Preis.
Also nicht Hauptsache sicher, egal wie lang es geht,
sondern der Fluss muss wirklich gewährleistet sein.
Und der zweite Weg, Principles of Feedback.
Da geht es ja darum, dass man möglichst schnell eigentlich Feedback gibt,
bei allem, was man tut, dass möglichst früh die Rückmeldung passiert.
Also Negativbeispiel.
Man merkt erst, dass ein Produktionssystem nicht mehr funktioniert,
wenn der User halt anruft und sagt, da tut was nicht.
Also das möglichst früh bekommendes Feedback.
Und darunter liegt für mich eigentlich die Idee,
dass man ein möglichst sicheres Environment schafft.
Also ein Environment, wo man schnell Änderungen machen kann,
ohne Angst zu haben, dass irgendwas zerbricht
und nachher nicht mehr funktioniert.
Und der dritte Weg, Third Way,
Continued Learning and Experimentation,
ist für mich wahrscheinlich der zentralste Punkt,
bei DevOps, weil ich glaube, dass wir uns in einem Environment bewegen,
das zunehmend komplex wird, wo wir uns immer schneller bewegen
und wo es eine gewisse Unsicherheit gibt.
Was meine ich damit?
Cloud ist ein Riesenthema bei uns, bei der Swiss Re,
aber auch, würde ich sagen, überall in der Industrie.
Und Cloud bietet viele Möglichkeiten, aber es macht gleichzeitig die Systeme
auch komplexer, weil sie halt verteilter werden.
Wenn wir uns Microservices-Architekturen zum Beispiel anschauen,
da gibt es viele Möglichkeiten, aber es gibt auch viele neue Herausforderungen.
Und die Unsicherheit, die ich erwähnt habe,
die bezieht sich sowohl auf das technologische Umfeld
als auch auf das Business-Umfeld.
Dort muss man auch eben flexibler sein.
Man muss sich möglichst schnell den neuen Gegebenheiten anschauen.
Man muss sich ganz schnell anpassen können.
Jetzt habe ich ein bisschen weit ausgeholt.
Um noch einfach zu sagen, wie wir DevOps interpretieren,
da ist ganz wichtig, dass wir es halt als ganzheitliches Konzept sehen.
Also wir versuchen uns immer entlang den Dimensionen
Culture, People, Process und Technology zu bewegen.
Da gibt es auch ein paar interessante Sichtweisen.
Oftmals ist es halt so, dass man es ein bisschen zu einseitig betrachtet.
Dass man sich zu sehr auf die Technologie konzentriert
oder vielleicht zu sehr nur auf den kulturellen Aspekt.
Man sollte wirklich versuchen,
es ist unsere oder meine Meinung,
halt wirklich entlang all dieser vier Dimensionen zu gehen.
Danke, das fand ich eine sehr spannende Beschreibung.
Also was ich herausgehört habe,
also Ziel nachhaltiger Geschwindigkeit,
dann die Umsetzung über die Three Ways
und dann eben, dass ihr auch,
weil viele sehen ja DevOps nur als Tool-Angelegenheit,
dass du eigentlich sagst,
schlussendlich müssen alle Bereiche stimmen,
People, Process, Technology.
Und was jetzt auch,
ein bisschen hast du es schon angetönt,
das Warum, du hast es ein bisschen erwähnt,
Cloud ist wichtig bei euch
und dass sich die Änderung,
also immer mehr Änderungswünsche.
Und die Frage wäre jetzt,
wenn wir so den Link noch mehr zur Swiss Re machen,
was waren dann für euch schlussendlich
die Treiber, oder dass eine IT der Swiss Re gesagt hat,
okay, wir möchten jetzt uns Richtung DevOps bewegen.
Tobias.
Also ein Treiber ist sicherlich die Agilität,
also sich möglichst schnell verändernden Voraussetzungen
anpassen zu können.
Und in dem Zuge halt auch neue Ideen auszuprobieren,
möglichst schnell,
und die dann auch möglichst schnell wieder verwerfen,
so sie sich dann als falsch,
oder als nicht richtiger Pfad rausstellen.
Und dann haben wir,
also wir sind wie gesagt im Rückversicherungsgeschäft tätig.
Wir haben nicht jetzt,
wir haben zwar auch Consumer Exposure,
aber das ist nicht so wesentlich.
Wir arbeiten eigentlich mehr im B2B Umfeld.
Aber unsere Kunden,
also zum Beispiel Erstversicherer,
oder größere Unternehmen,
die sind natürlich viel stärker,
oder sind auch sehr stark,
oder noch stärker als wir,
in dieser digitalen Transformation.
Dort ist der Druck viel größer,
und die Veränderung findet statt.
Und wir müssen da mitgehen.
Also wir wollen eigentlich dann stetig dort am Ball bleiben.
Und gleichzeitig eben auch neue Ideen direkt an den Markt bringen.
Also vielleicht auch dann direkt wirklich im B2C Business
noch mehr Fuß fassen.
Das ist bei uns im Moment noch eher kleiner.
Und was halt bei uns intern,
um den Weg gehen zu können,
organisieren wir uns auch neu innerhalb der IT
und auch über die IT hinaus.
Also das IT wächst eigentlich näher ans Business ran.
Wir gehen weg von Shared-Funktionen.
Also wir hatten eine sehr dicke Shared-Infrastruktur-Organisation,
die jetzt eigentlich,
wo wir uns immer mehr zu einem föderierten Ansatz entwickeln,
weil ich die, wir sagen den Business-Domain ITs,
also die IT-Organisationen,
die den entsprechenden Business-Domains zugeordnet sind,
wo die wirklich End-to-End-Verantwortung
für den Betrieb von den IT-Lösungen übernehmen.
Und um das zu ermöglichen,
müssen wir eigentlich DevOps-Prinzipien umsetzen im Unternehmen.
Okay, du hast eben davon gesprochen,
Transformation Lead,
auf dem Weg digitaler Transformation.
Habt ihr ein Ziel?
Wie weit seid ihr?
Seid ihr schon fertig?
Kannst du da mal ein bisschen was zu sagen?
Also fertig sind wir sicher noch nicht.
Und ich persönlich bin halt auch immer,
ich sage, die Leute,
die schon mutmaßlich ein ziemlich komplettes Bild von dem Ganzen haben,
die challenge ich eigentlich immer.
Weil ich sage, wir können das noch gar nicht so genau sagen,
wie das denn in einem Zeithorizont von ein bis zwei, drei Jahren aussieht.
Oder?
Weil das alles in Bewegung ist
und wir auch noch sehr viel lernen müssen, oder?
Also wir können, die Zeit ist einfach nicht die,
dass wir jetzt sagen können, es ist alles schon klar.
Wir müssen nur das und das und das machen
und dann sind wir genau dort, wo wir hinwollen.
Also von dem her, um deine Frage zu beantworten,
wir sind mittendrin und wir wissen,
dass es noch eine geraume Zeit so weitergehen wird
und dass auch eben diese hohe Geschwindigkeit an Veränderungen,
die wird mehr zum Alltag.
Also wir werden uns mehr in diesen Schnellwechselmodus gewöhnen,
als dass wir dann irgendwann sagen, jetzt sind wir fertig mit dem,
wann kommt die nächste große Transformation?
Wie reagiert denn das Business da drauf?
Weil ich häufig, wenn ich in Scrum-Trainings bin
und auch in den Projekten drin bin,
man ja der IT vorwirft, dass sie nicht liefert,
dass sie keinen Ziegel hat
und letzten Endes ist ja das genau,
was ich bei dir raushöre,
aktuell der Fall.
Zumindestens könnte man euch vorwerfen,
ihr wisst gar nicht, wann ihr fertig seid.
Insofern wieder mal planlos.
Naja, das kommt dann auch drauf an,
auf was man das jetzt anwendet, diese Aussage.
Also digitale Transformation, glaube ich,
sind wir uns einig, das geht ja durch das ganze Unternehmen.
Das ist ja nicht nur ein IT-Thema.
Und ich gebe dir schon recht,
also es ist nicht so jetzt unbedingt,
dass das Business jetzt sagt,
jetzt lass uns hier das zusammen machen
und jetzt wissen wir schon genau, wo es hingeht,
sondern ich habe da oft das Beispiel mit dem,
wenn es darum geht, jetzt gerade wieder in einem DevOps-Kontext zu sagen,
hey, lass uns doch mal die Release-Cadence erhöhen.
Lass uns doch mal nicht Quarterly-Releases machen,
sondern jeden Monat oder alle zwei Wochen
oder wenn es geht, noch öfters.
Und oft ist halt eine Reaktion auf der Business-Seite dann,
ja, eigentlich wollen wir eher weniger Releases,
weil Release bedeutet für uns eigentlich Aufwand.
Also wir müssen dann irgendwie,
werden dann zum User-Acceptance-Test eingeladen,
müssen vielleicht noch eine Ausbildung machen
und dann, wenn es übers Wochenende,
dann braucht es ein ganzes Wochenende,
um das Deployment zu machen
und am Montagmorgen gibt es dann wieder Probleme.
Also Bottom-Line-Release wird assoziiert mit Arbeit, Aufwand und Problemen.
Und da, das ist auch ein Teil meiner Aufwand,
meine Aufgabe halt auch zu erklären,
dass mittelfristig eigentlich eine höhere Release-Cadence bedeutet,
dass die Releases kleiner werden, weniger spürbar,
weniger Risiko mit sich bringen
und dann eben sich nicht so anfühlen,
wie sich jetzt so ein Quarterly-Release anfühlt,
wo man dann das Gefühl hat,
hey, ich möchte es eigentlich eher weniger als mehr machen,
sondern dass es sich eher so anfühlt,
es wäre dann ein Zielbild,
wie ich eigentlich Releases auf einem Mobile-Device wahrnehme, oder?
Ich nehme da immer mich als Beispiel.
Am Anfang auch gesagt,
ja, hm, das verschiebe ich mal lieber,
bevor ich da irgendwie das Knöpfchen drücke
auf meinem Mobile-Device,
um das Upgrade machen,
aber mittlerweile ist das ja was,
wo man quasi automatisch macht
und wirklich im laufenden Betrieb,
weil man weiß,
die Applikation verändert sich nicht fundamental
von einem Release zum anderen.
Also jetzt nur eine Anekdote,
ein Beispiel,
aber das ist eben auch das,
wo zustimmen,
ja, das Business und die IT
muss da noch mehr zusammenwachsen,
aber das ist eben auch ein Teil,
ein Bereich, wo DevOps helfen kann.
Aber zeigt auch,
dass ein Teil deiner Arbeit ist ja auch,
dann mit den Leuten sprechen,
mit den Stakeholdern sprechen
und aufzeigen, was DevOps bedeutet
und das bei ihnen zu bekommen.
Genau.
Ja, und wenn wir jetzt
über die DevOps-Transformation
bei der Swiss Re sprechen,
also wie,
also du hast erklärt, schön,
die Treiber auch.
Warum ist das überhaupt ein Thema
bei einer Swiss Re?
Bei euch ist es natürlich anders
wie jetzt bei anderen Unternehmen,
weil es ist ein Business-to-Business-Umfeld
und ihr habt aber auch,
sagen wir, die interne IT-Perspektive,
sagen wir mal,
ein bisschen weg von,
sagen wir, dem Shared Service,
sondern mehr im federalistischen Ansatz.
Und jetzt von der Transformation her,
wie seid ihr da vorgegangen?
Oder wie,
deine Aufgabe ist ja,
die Transformation vorwärts zu treiben
innerhalb der IT.
Wie geht ihr das an?
Also angefangen haben wir eigentlich,
und es hat immer noch den Charakter
eher mit einem Bottom-up-Ansatz,
also dass wir wirklich an der Basis anfangen,
auch anhand von kleinen Beispielen
und das dann wirklich Bottom-up
in die Organisation versuchen reinzutragen.
Und jetzt, als ich angefangen habe
vor einem Jahr,
da hat eigentlich,
hat man, sage ich mal,
auf Executive-Ebene noch nicht so prominent
über DevOps geredet.
Das wird auch heute noch nicht so jetzt
ganz riesengroß geschrieben im Sinne von,
wir haben jetzt eine riesen DevOps-Strategie,
obgleich jeder Einzelne im Executive-Team
natürlich weiß, was DevOps ist
und das auch unterstützt und weiterbringen möchte.
Ich sage da oft,
wir haben so eine Art Sandwich-Situation eigentlich.
Also wir bringen das von unten nach oben
anhand von wirklich konkreten Beispielen.
Und es hat aber auch den Executive-Bein und Support.
Also ihr bringt, sagen wir,
von unten nach oben mit konkreten Beispielen,
aber gleichzeitig auch so mit Top-Down
oder das Management-Commitment zu bekommen.
Wenn wir jetzt so von unten nach oben,
also da, was habt ihr da konkret?
Gibt es da ein paar Beispiele,
was ihr so gemacht habt?
Ja, also da kann ich gerne ein paar Beispiele bringen.
Also wir haben ganz am Anfang haben wir,
und das machen wir auch bis jetzt noch,
wir haben mit Value-Stream-Mappings angefangen,
wo wir wirklich Leute aus der Infrastruktur,
Shared-Infrastruktur, aus dem Bereich IT-Audit,
Governance-Compliance und natürlich
aus der Applikationsseite zusammengebracht haben
und dann wirklich mal den Technology-Value-Stream
also Change-Inception, also von der Idee bis hin zu Change
wirklich verfügbar in Produktion,
den ganzen Ablauf angeschaut und analysiert haben
und daraus dann abgeleitet wirklich kleinere Verbesserungsansätze.
Das kann oftmals sein,
dass einzelne Schritte einfach weggestrichen werden,
weil man sieht, wenn man dann auf das Ganze mal schaut,
ja, die braucht es eigentlich gar nicht.
Oder halt auch Verbesserungen im Sinne von Automatisierung,
im Sinne von Automation oder APIs zu den Infrastruktur-Plattformen,
dass man wirklich dann die Automation in einem Pipeline,
CICD-Pipeline-Kontext umsetzen kann.
Typischerweise und so auch bei uns ist das halt oft
so eine zusammengestöpselte Toolchain aus verschiedenen Systemen,
wo dann oftmals halt auch Portale oder User-Interfaces involviert sind,
wo es halt schwierig ist,
so einen ganzen End-to-End-Ablauf wirklich zu automatisieren.
Also wir haben das gemacht mit verschiedenen Business Domain ITs
und das Schöne war, dass sich dann wie ein gemeinsamer Backlog entwickelt hat,
wo wir uns halt, wo wir jetzt uns durcharbeiten sukzessive.
Was wir auch gemacht haben, ist dann, wir haben das Flash Builds genannt,
weil wir so ein bisschen, sag ich mal, an vielen Orten,
auch speziell ein bisschen in der Infrastruktur,
dort plant man traditionell ein bisschen in größeren Zyklen, oder?
Weil dort halt auch viele Investments gemacht werden,
wenn man neue Hardware kaufen muss,
obgleich wir auch unsere Datacenters runterfahren.
Aber dass wir wirklich ein bisschen mit dieser langen oder, ja,
Monate- bis Halbjahresplanung brechen konnten,
haben wir dann Flash Builds gemacht.
Also wirklich so, was können wir erreichen innerhalb von einer Woche,
um wirklich ein bisschen auch aus dieser, ja, dadurch, dass wir,
ich habe dem Analysis Paralysis gesagt, oder?
Weil wir dadurch, dass halt oftmals die Investments so groß sind
in technische Lösungen, in Enterprise-technische Lösungen,
dass man sich dann wirklich ewig lang hin und her überlegt
und mit allem, mit jedem redet und schaut,
was könnte denn jetzt die beste Lösung sein,
weil man natürlich nicht ein großes Investment machen möchte,
ohne sich ganz sicher zu sein.
Mit dem zu brechen und mal was wirklich Kleines anzufangen.
Und wir haben das dann Minimal Viable Architecture genannt.
Also wir haben da in dem Fall jetzt wirklich mit einem ganz einfachen
Cloud-Native-Muster angefangen.
Wir haben eigentlich ein Open-Source-API-Gateway genommen,
haben dann mit eine Microservices-Architektur implementiert,
auf Basis von Docker.
Und das war es eigentlich, wo wir dann wirklich die Leute drum herum
konzentriert haben und so einen gemeinsamen Arbeits-Context
geschaffen haben.
Und auf Basis von dem, was dabei rausgekommen ist,
haben wir dann wirklich weitergearbeitet.
Also mittlerweile sind die Technologie-Bausteine,
die da entstanden sind, in einem höheren Reifegrad.
Also wir arbeiten uns da jetzt sukzessive vor.
Und ein anderes Beispiel, mehr so aus der Prozess-Ecke,
läuft bei mir so unter dem Überbegriff Lean-Change-Management.
Ist ja sehr interessant für Leute mit einem IT-Service-Management-Programm,
die Service-Management-Background.
Also dort haben wir halt den Prozess für Change-Release-Deployment
angeschaut.
Der ist bei uns im Wesentlichen über ServiceNow implementiert.
Und haben dann festgestellt, wenig überraschend, dass das halt
mit so einer hohen Release-Cadence, mit CI-CD und so weiter,
nicht kompatibel ist.
Und haben dann uns auch zusammengesetzt mit den Haupt-Stakeholders,
also mit den Applikationsleuten, mit Leuten von IT-Audit
und mit den Prozess-Ownern von den jeweiligen Prozessen
und haben dann einen Minimal Viable Process definiert.
Und das war eigentlich ganz interessant, weil was wir da gesehen haben ist,
und ich habe das Delegation of Concern genannt,
das ist nicht zu verwechseln mit dem schönen Software-Design-Pattern,
Segregation of Concern, sondern was ich gesehen habe,
ist so, es gibt einen Prozess-Owner für den Change-Release-Deployment-Prozess.
Der redet mit den Leuten auf der Applikationsseite.
Die deponieren ihre Requirements.
Und er redet aber gleichermaßen auch mit den Leuten auf der Governance,
auf der IT-Audit-Seite.
Also es ist wie so eine Art Proxy.
Aber gleichzeitig, jetzt komme ich zu dem Punkt Delegation of Concerns,
die Leute auf der Governance-Compliance-Seite schmeißen so ihre Requirements,
da zum Process-Owner und auf der Applikationsseite genauso.
Und er steht dann so in der Mitte und muss da irgendwie eine Lösung finden.
Und der Schlüssel bei uns, was dann auch zu diesem Minimal Viable Process geführt hat,
war auch ein Value-Stream-Mapping, wo wir wirklich alle Leute an einen Tisch gebracht haben.
Und dadurch, dass eben auch die Leute auf der Applikationsseite direkt mit den Leuten
auf der IT-Audit-Seite geredet haben, hat sich wie ein neuer Solution-Space,
wo sich zusätzliche Optionen ergeben, die man sonst vielleicht gar nicht so einfach gesehen hätte.
Und ganz konkret, was wir gemacht haben dort ist,
wir haben zum Beispiel das eigentliche Change-Management angeschaut
und sind dann zu einem Schluss gekommen, dass nur weil es nicht in ServiceNow stattfindet,
heißt es nicht, dass es nicht stattfindet.
Es findet einfach in anderen Tools statt, bei uns mehrheitlich in Jira zum Beispiel.
Und wir haben uns dann darauf geeinigt, dass wenn der Product-Backlog und das Sprint-Planning,
also wenn wirklich vernünftig mit Jira gearbeitet wird, dass das ein implizites Change-Management ist
und das dann nicht mehr noch in einem separaten Tool nachgeführt werden muss.
Und das ist aber jetzt wohlgemerkt auch nur der Anfang, aber wir haben jetzt wirklich
eigentlich einen wesentlichen Schritt dahin gemacht, dass wir den Prozess wirklich entschlacken.
Und den Prozess mehr um die Continuous-Deployment-Pipeline oder Delivery-Pipeline orchestrieren und nicht umgekehrt.
Das waren ja ein paar schöne Beispiele, insbesondere dieses Minimal-Viable-Process-Architecture.
Finde ich ja eine ganz gute Übertragung dieser Prinzipien.
Und als du das eben so erzählt hast, habe ich mir gedacht, da ist mir die Frage hochgepoppt, wie würdest du das sehen?
Also ich sage immer, DevOps ist im Prinzip eine vernünftige Mischung zwischen IT-Service-Management, Lean-Management und agilem Vorgehen.
Wenn du das auch so siehst, meinst du, dass man da auch aus deiner Erfahrung heraus quasi so gewisse Prozentsätze verteilen kann?
Also im ersten Moment klang es bei dir sehr stark nach Lean, dann kam aber schon wieder auch Scrum mit dazu.
Also die Frage ist, kann man das irgendwie aufteilen und wie siehst du, wie sich DevOps aus klassischen, bisher bekannten Disziplinen zusammenfasst?
Also da, ich würde sicher da nicht mit irgendwelchen Prozentzahlen, würde ich mich sicher nicht festlegen.
Also da spielt alles ein bisschen mit rein und ich sage halt immer, das Wichtigste ist eigentlich der gesunde Menschenverstand.
Also man darf sich da nicht zu sehr auf die eine oder andere Weisheit oder Methodologie verlassen.
Ich glaube, man muss es immer individuell anschauen und dann entscheiden.
Das höre ich gerne.
Gesunder Menschenverstand hilft.
Das war jetzt schon ein bisschen eine sehr schweizerische Antwort.
Aber das mit dem gesunden Menschenverstand ist international, das muss man schon sagen.
Und du bist ja schon ein Weilchen in der Schweiz.
Genau, ja.
Und du hast jetzt schön, also es sind so drei Bereiche, so Value Stream, dann das mit dem Flash Build und dann Lean Change Management.
Aber immer was die drei Bereiche gemeinsam haben.
Also am Anfang gesagt, so statt Analysis, Paralysis, also statt zu Tode argumentieren, auch mal, einfach mal klein anfangen.
Aus dem, also so auch das Bein der Leute bekommen, aus dem raus wachsen, verbessern.
Und das ist ja auch so ein typischer Ansatz aus dem Lean.
Also man macht einen Value Stream, mal End-to-End verstehen von der, du hast auch schön gesagt, von der Inception bis zum Rollout.
Man hat auch schön den Three Ways.
Man hat ja, die Leute haben ein gemeinsames Verständnis, wie arbeiten wir zusammen.
Aus dem verbessert man dann Schritt für Schritt.
Und das ist ja so stark, auch im Moment ist es noch ein Bottom-Up Ansatz.
Ist aber auch etwas, wenn wir zum Beispiel schauen in der Vergangenheit bei vielen Firmen, wie agile Transformationen stattgefunden haben.
Da haben ja einfach mal Teams angefangen mit Scrum zu arbeiten.
Das war recht erfolgreich.
Und die anderen Teams haben das dann automatisch adaptiert.
Aber irgendwo muss ja dann immer der Punkt kommen, wo dann auch das Management sagt, ja okay, da wollen wir jetzt.
Das ist auch, sagen wir, Teil unserer Strategie, dass wir den Weg gehen wollen.
Und wo steht ihr in Bezug auf das, also das jetzt, sagen wir, das Management bei Ihnen, dass es auch jetzt von oben bewusst gesteuert wird?
Oder ist das etwas, das ihr jetzt dieses Jahr angehen wollt?
Jetzt, wir haben vereinzelt Business Domain ITs, die wirklich das auch in ihrer Strategie manifestiert haben.
Also explizit auch eines von den Top-Level-Punkten und andere, wo das mehr so implizit ist.
Also wo dann schon DevOps auftaucht als Element der IT-Strategie, aber nicht ganz so explizit.
Und das hängt auch ein bisschen damit zusammen, dass die,
die Strategien, wir haben natürlich eine Gruppen-IT-Strategie, aber die Business Domains an sich sind unterschiedlich
und entsprechend sind auch teilweise die IT-Teile unterschiedlich ausgerichtet und haben da unterschiedliche Schwerpunkte drauf.
Und um den anderen Teil der Frage zu beantworten, also wir sind schon noch jetzt an einem Punkt, wo wir halt mit Referenz-Applikationen,
wir sagen dem auch DevOps Co-Owner,
also das sind wirklich so DevOps Advocates in den Business Domain ITs, mit denen ich eng zusammenarbeite,
die für gewisse Applikationen oder Portfolios zuständig sind, wo wir wirklich so die Referenz nicht unbedingt,
ja doch Implementation kann man schon sagen, jeweils machen.
Und auf Basis von dem wollen wir es dann eigentlich später auch ausdehnen und erweitern.
Und vielleicht ist es auch noch, also wir haben die Applikationen, mit denen wir zusammenarbeiten,
sind tendenziell halt eher in diesem, werden neu gebaut oder sind also keine Bestands-Applikationen oder Legacy-Applikationen
und das ist dann noch ein Feld, wo es für uns sehr spannend wird oder wenn wir wirklich dann mal mehr traditionelle Applikationen anpacken
und uns die noch weiter modernisieren im Sinne von DevOps-Prinzipien.
Habe ich das richtig verstanden, dass ihr im Prinzip diese DevOps-Ansätze wirklich nur bei neuen Applikationen anwendet?
Das heißt, ihr habt es noch nicht übertragen auf Bestands-Applikationen und insofern auch noch nicht unbedingt auf eine großartige Organisationsveränderung?
Ja, also sagen wir mal, die Referenz-Implementationen sind jetzt eher mit neueren Applikationen.
Das hängt aber auch damit zusammen, dass halt viele ältere Applikationen sind halt im Run-Modus.
Also da werden nicht massiv neue Features implementiert, sondern die werden halt am Laufen gehalten, sage ich mal.
Und dort will man halt noch nicht jetzt so die großen Investments machen.
Aber man muss auch sagen, also die Applikationen, wo wir jetzt wirklich entlang von DevOps-Prinzipien arbeiten,
das sind nicht nur Cutting-Edge-Applikationen aus Technologiesicht.
Also wir haben eine, die ist schon eine Microservices-Architektur, wo auf unserer Private Cloud läuft,
wo aber WebSphere, also so Sachen sind da mit dabei.
Das ist noch die modernste in Anführungszeichen.
Aber wir haben auch welche, wo wirklich Batch-Verarbeitung, ETL, Data Warehouse, auch Enterprise-Datenbank-Lösungen.
Sind zwar neue Applikationen, aber nicht jetzt auf irgendeinem Cutting-Edge-Public-Cloud-Technologie-Stack.
Und solche haben wir dann aber wiederum auch, oder? Also welche, die wirklich schon auf einem hochmodernen Tech-Stack sind.
Aber wie gesagt, eher Applikationen, die noch im Build-Modus sind, nicht Applikationen, die im Run-Modus sind.
Weil dort halt die Schwelle zu investieren, ist halt dort höher, oder?
Du hast ja auch erwähnt, Cloud ist bei euch ein Thema. Ihr habt, glaube ich, auch eine Cloud-Initiative am Laufen.
Wie siehst du da den Kontext jetzt Cloud und DevOps, respektive bei euch konkret jetzt?
Ja, also das eine, also es spielt wie ineinander und gehört zusammen.
Es gibt ja wie so zwei Ansätze, die wir da, oder zwei Sichtweisen.
Also man kann ja einerseits sagen, DevOps entfaltet die Wirkung und erst richtig, wenn man Cloud als Betriebsmittel hat.
Also wenn man die Cloud-Möglichkeiten ausschöpfen kann.
Zum Beispiel Immutable Infrastructure und so weiter, Infrastructure as Code.
Das kommt erst so richtig zum Tragen, wenn man Cloud-Mittel nutzen kann.
Oder man sieht es umgekehrt.
Also man kann wirklich Cloud nur nutzen, wenn man DevOps-Prinzipien und Methoden anwendet.
Wir sehen es mehr so, wir haben eine sehr starke Cloud-Ausrichtung in unserer IT-Strategie.
Also das wird da sehr groß geschrieben.
Entsprechend wird DevOps mehr so als Mittel und Ansatz gesehen, um wirklich diese Cloud-Strategie zu implementieren.
Also einer der Gründe, um Cloud zu machen, ist eigentlich auch,
DevOps und dann Cloud als Enabler für DevOps. Richtig?
Genau.
Und wenn ich jetzt die Sicht, also viele Software-Entwickler, für die ist ja so ihre Vision, also sie wollen,
wenn sie Code einchecken, also sie können eh virtuell ganz schnell, sie bekommen eine Umgebung und da werden automatisiert Tests ausgeführt.
Alles eigentlich darunterliegen ist alles Infrastructure as Code.
Und für die ist eigentlich dann ein bisschen eine Blackbox.
Oder ob das dann aus dem eigenen Datacenter kommt oder ob das so diese Tendenz von Know-Obs.
Der Software-Entwickler würde am liebsten dann alles aus der Public Cloud beziehen, Azure, Amazon.
Aber das ist ja bei euch, also ich sage das ja nicht, wenn wir noch die Branche besser verstehen.
Also Rückversicherung ist ja auch sehr stark reguliert. Also welchen Weg geht ihr da?
Mehr Public Cloud oder ist das dann Private Cloud?
Ja, im Moment, also ein Großteil der Applikationen wird sich jetzt erstmal in eine Private Cloud bewegen.
Eben aus den erwähnten Gründen. Aber die Strategie sieht eigentlich vor, wo immer möglich, gehen wir eigentlich in die Public Cloud.
Wo das nicht möglich ist, in die Private Cloud.
Und von dem Last Resort, dass irgendwas ordentlich passiert,
was On-Premise bleibt, redet man eigentlich gar nicht, oder?
Also eigentlich ist Public Cloud first und dann als zweite Möglichkeit halt Private Cloud.
Und wie es sich jetzt manifestiert, ist halt wirklich so, dass ein Großteil jetzt in die Private Cloud geht.
Eben wegen den erwähnten Regulatorien, die halt sehr stark sind im Financial Services Sektor und speziell im Versicherungssektor.
Alex hat eben nochmal ein Stichwort eingebracht, Know-Obs.
Und so wie du es auch ausgeführt hast, Alex, klang es für mich so ein bisschen,
als ob die Entwickler sich eigentlich gar nicht um Obstthemen kümmern wollen. Nicht unbedingt.
Gab es denn bei euch Erfahrungen, oder wie sind eure Erfahrungen, wenn die Entwickler, die eben neue Features bauen wollen, auf IT-Betrieb treffen?
Also wenn sie auch den Betrieb sicherstellen müssen. Was sind da so eure Erfahrungen mit den Entwicklern?
Aus dem, was ich jetzt erfahren habe aus vielen Gesprächen, ist eigentlich, dass ein Applikationsentwickler
möchte eigentlich Applikationsentwicklung machen, oder?
Also die sind im Regelfall schon eher an den funktionalen Aspekten von der Applikation entwickelt.
Also ich persönlich sehe wieder ein bisschen ein neues Profil.
Das ist jemand, also so ein Ops-Engineer, wo er sich eher an der Applikation orientiert,
wo er sich aber auf die nicht-funktionalen Aspekte konzentriert.
Die verschiedenen Entwicklertypen arbeiten dann zusammen in einem Team.
Das ist so das, wo ich so ein bisschen vermute, wo die Reise hingeht.
Aber es ist noch ein bisschen schwierig zu sagen.
Um die Frage zu beantworten, wie Applikationsentwickler reagieren.
Also das kommt dann, nachdem so wir dürfen jetzt alles und machen alles selber,
kommt irgendwann oft ein Punkt, wo so ein bisschen auch nicht Ernüchterung,
aber wo die Leute dann sehen, was das denn alles bedeutet.
Also diese, ich glaube, diese No-Ops-Idee.
Irgendwann kommt dann da die Ernüchterung, oder?
Wo man dann sagt, okay, aber ganz das alles wollen wir dann doch auch nicht machen, oder?
Und ich rede von dem klassischen Applikationsentwickler.
Ich glaube an Teams, an Applikationsteams, wo es halt Entwickler gibt.
Alles sind Entwickler, aber halt welche, die sich auf die funktionalen Aspekte konzentrieren
und andere auf die nicht-funktionalen.
Das bedeutet Monitoring, Automation, CI-CD-Pipeline und so weiter.
Okay, das heißt, die Entwickler,
von denen du gesprochen hast, die lernen dann durch DevOps,
dass Ops doch nicht ganz so einfach ist und ja,
manchmal auch ein bisschen langweilig wahrscheinlich,
aber trotzdem schon eine Herausforderung und wollen es dann wahrscheinlich doch eher auch abgeben
oder einfach im Team auch vielleicht so ein bisschen hin und her schieben.
Ja, so könnte man das zusammenfassen, ja.
Und es ist halt, es ist alles auch noch ein Lernprozess, oder?
Weil das verändert sich halt doch sehr stark.
Also das muss sich alles setzen und man muss gute Setups am Ende vom Tag finden, oder?
Wie man das nachher betreiben kann.
Ja, ist schlussendlich, also DevOps-Transformation ist ja eine Reise.
Das ist ja, auch wenn man so liest oder hört, was andere im Bereich Enterprise IT,
DevOps-Transformation machen, ist ja nicht so, dass man von Anfang an Ziel bildet, sondern es ist eine Reise.
Und jetzt auch anknüpfen, was wir vorher diskutiert haben halt,
dass sich auch Operation ein bisschen neu finden muss, neu definieren und eben sicher nicht No Ops,
weil das ist sicher nicht die richtige Lösung, sondern eher würde ich sagen so New Ops,
was auch immer das konkret heisst, ja.
Und was ich jetzt vielleicht noch spannend finden will, wir haben ja darüber gesprochen,
was habt ihr da konkret gemacht, eben so Value Stream Mapping, Flash Build,
dann das Lean Change Management, wenn wir vielleicht ein bisschen tiefer gehen.
Also ich persönlich bin Fan noch von diesem Value Stream Mapping,
weil es ist auch etwas, wo man relativ schnell dann auch Verbesserungen erzielen kann,
dann einen gewissen Drive reinbringen kann, weil die Leute sehen das und wollen dann weitermachen.
Kannst du, Tobias, vielleicht ein Beispiel von so einem Value, also du musst es ja nicht beim Namen nennen,
aber in welchem Bereich habt ihr denn das Value Stream Mapping gemacht, welche Art von Applikation?
Also was ist dann konkret so aus solchen Value Stream Workshops,
was ist da dann herausgekommen an konkreten Verbesserungen?
Also eins ist sicherlich das gewesen mit dem Lean Change Release Deployment Management.
Das war ein Finding, das wir dann konkret halt jetzt in diesem Minimal Viable Process Beispiel umgesetzt haben.
Dann haben wir auf der Datenbankseite angefangen,
und dort wirklich das auch mehr aus einer, also wir haben einen gewissen Automationsgrad,
was das Ausführen von Datenbankskripten oder das Verwalten von Datenbanken anbelangt, haben wir schon,
aber eben nicht in einem End-to-End Automationskontext oder in einem Pipeline-Kontext.
Und das war eigentlich in so gut wie allen Value Stream Mappings, die wir gemacht haben, ein großes Thema.
Dort haben wir jetzt wirklich auch schon konkret erste Schritte gemacht,
wo Applikationen dann wirklich aus der Pipeline kommen,
aus der Pipeline raus im Prinzip ihre Datenbank Changes deployen können.
Und dann gibt es eben, ein anderes Beispiel wäre noch Monitoring,
dass man wirklich das Monitoring, das Produktionsmonitoring eben auch aus der Pipeline quasi abschalten kann,
dann Veränderungen vornehmen kann automatisiert und zum Schluss das Monitoring wieder anstellen.
Und ja, ab dergleichen gibt es noch mehrere kleine Beispiele, würde ich sagen.
Aber das ist auf der Prozessseite mit dem Change Management und auf der Datenbank
Seite, das sind wohl die grösseren Blöcke bisher, würde ich sagen.
Ja, aber das sind doch konkrete Verbesserungen.
Und ihr seid ja, habe ich verstanden, auch so vorgegangen, dass ihr mich halt dann als Team zusammengesetzt habt,
vielleicht Leute, die vorher noch nicht so miteinander gesprochen haben, also verschiedene Departments.
Man hat gefragt ja, der End-to-End Stream, wer ist da involviert?
Und zuerst mal ein Bild bekommen, wie läuft es jetzt und dann aus dem heraus Verbesserungen identifiziert.
Wie habt ihr das gemacht?
Also das Interessante war für mich, ich habe auch fast bei allen Value Stream Mappings eigentlich gesehen,
dass jeder, also dass zum Beispiel Leute, die in einem grösseren Applikationsteam zusammenarbeiten,
auch jeweils untereinander was voneinander gelernt haben.
Also eigentlich nicht mal nur Leute, die jetzt da normalerweise nichts miteinander zu tun haben,
sondern alle haben irgendwie was gesehen oder Einsichten bekommen in das,
was der andere macht.
Und was mir so hängen geblieben ist, ist das Beispiel mit dem, das war eine Batch-orientierte Applikation,
wo die Testzyklen sehr, sehr teuer sind.
Also konkret ein voller Testzyklus hat, glaube ich, acht Stunden oder so gebraucht.
Also zeitmäßig sehr teuer und entsprechend konnte der nicht so oft durchlaufen.
Wir haben dann herausgefunden, dass eben pro Release dreimal dieser Testzyklus durchlaufen wird
und dass in dem ersten Testlauf hunderte von Fehlern entdeckt werden.
Und dann werden die Fehler behoben, dann hat man vielleicht noch 50% oder 30% von den Fehlern im zweiten Testlauf
und im dritten läuft dann alles durch.
Und dann haben wir wirklich in einer Gruppe eigentlich geschaut, ja, was machen wir denn damit?
Und haben dann gesehen, eigentlich wäre es doch gut,
wenn man wirklich möglichst viel von dem Testing nach links verschieben kann,
dass das nicht alles nur an diesen teuren Testläufen hängt, oder?
Weil man hat gesehen, das war halt für sie die einzige Möglichkeit, das zu testen, aus ihrer Sicht,
und das war sehr teuer, also hat man alles dort reingesteckt.
Und die Schlussfolgerung war eigentlich, dass wir dann wirklich versucht,
möglichst viele Tests schon vor diesen teuren Testzyklen zu machen,
dass dann der erste teure Testzyklus halt zum Beispiel nur noch,
50% der Fehler finden muss, dass man vielleicht am Ende vom Tag mit zwei teuren Testzyklen statt mit drei laufen kann.
Und natürlich ist das dann in der Theorie sehr einleuchtend und naheliegend
und in der Umsetzung halt etwas schwieriger, aber schon allein die Einsicht hätte man glaube ich nicht gehabt,
ohne dieses Value Stream Mapping, wo dann wirklich alle, die in diesem Value Stream mitarbeiten,
das an einem Tisch sitzen und das anschauen.
Das klingt doch gut. Das finde ich auch einen sehr schönen Lerneffekt,
auch aus dem Phoenix Project Buch, aus dem Roman, dass man wirklich den Value Stream,
den Wertstrom sich anschaut und daraufhin eben entwickelt.
Und damit ja letzten Endes auch über die Silo-Grenzen hinaus das Ganze mal betrachtet.
Ja, jetzt gucke ich mal auf die Uhr, Alex. Sonst ist das immer dein Job, auf die Uhr zu gucken.
Jetzt gucke ich mal auf die Uhr. Ich habe keine Fragen.
Das war ein super tolles Gespräch und wenn du keine Fragen hast, Alex, dann können wir ja auch langsam beenden.
Also ich habe auch keine Fragen mehr. Ich fand das super spannend.
Das sind auch die wertvollsten Beiträge, die wirklich aus der Praxis kommen.
Also was machen die Unternehmen effektiv, wenn es um DevOps geht?
Also von dem her vielen Dank von meiner Seite, vor allem von Tobias.
Sehr gern.
Dann auch von mir vielen Dank. Ich habe mitgenommen eine sehr tolle Definition von DevOps.
Nachhaltige Geschwindigkeit oder Geschwindigkeitssteigerung. Finde ich sehr, sehr interessant.
Werde ich bestimmt übernehmen in Vorträgen oder in Schulungen oder in Erläuterungen.
Und was ich interessant fand, war die Erkenntnis, dass das viele kleinere Verbesserungen sind.
Also das ist ein Weg, den man gehen muss, wo man viele kleinere Verbesserungen hat,
wo man viele Schritte hat, wo man Erfahrungen hat und dass das kein so riesen Programm ist, was man aufsetzt.
Das fand ich sehr, sehr interessant. Und davon von mir auch herzlichen Dank an dich, Tobias.
Sehr gern. Danke euch.
Und dann noch ein Ausblick auf den nächsten Podcast. Dirk, willst du das machen?
Respektive haben wir da noch mehrere Optionen im Moment, oder?
Ja, das hast du geschickt gemacht. Das muss ich wieder sagen.
Wir wollen kein neues Thema haben. Also wir haben die Option, jawoll.
Und wie es immer so ist, so am Jahresanfang, jetzt wo wir heute diesen Podcast aufnehmen, das startet so langsam.
Also insofern, der nächste Podcast kommt bestimmt wieder zur Mitte des Monats, wieder dann Mitte Februar.
Aber das Thema ist noch nicht ganz klar.
Ja, das stimmt.

Folge 6: DevOps und Microservices

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode diskutieren die Gastgeber Alex Lichtenberger und Dirk Söllner zusammen mit dem Experten Eberhard Wolff ausführlich über die Rolle und Bedeutung von Microservices in der DevOps-Welt. Sie erörtern, wie Microservices die IT-Infrastruktur modernisieren und die Effizienz in der Softwareentwicklung steigern, indem sie eine stärkere Modularisierung und Entkopplung ermöglichen. Es wird besprochen, wie Unternehmen schrittweise von monolithischen Systemen zu einer Microservices-Architektur übergehen können, wobei Herausforderungen wie Betriebskomplexität und Teamdynamik angesprochen werden. Die Episode schließt mit einer Diskussion über organisatorische Veränderungen und die Rolle von DevOps in diesem Kontext.

Inhalt

  • Einführung und Vorstellung von Eberhard Wolff
  • Definition und Bedeutung von Microservices
  • Verbindung zwischen DevOps und Microservices
  • Herausforderungen und Vorteile von Microservices
  • Praktische Beispiele und Anwendungsfälle von Microservices
  • Schrittweise Migration von monolithischen zu Microservices-Strukturen
  • Organisatorische Veränderungen und Kultur im Kontext von DevOps und Microservices

Shownotes

  1. Microservices: Definition und Prinzipien – https://martinfowler.com/articles/microservices.html
  2. Independent Systems Architecture Prinzipien – https://innoq.com/en/isap/
  3. Eberhard Wolff’s Buch über Microservices – (URL je nach spezifischem Buchtitel)
  4. Eberhard Wolff’s Buch über Continuous Delivery – (URL je nach spezifischem Buchtitel)
  5. Docker und Kubernetes als Infrastrukturthemen –
  6. Domain-Driven Design – https://dddcommunity.org/

Transkript (automatisiert, daher keine Gewähr 🙂 )