In dieser Folge des Podcasts besprechen Alex Lichtenberger und Dierk Söllner ausführlich den „State of DevOps Report“. Sie thematisieren die Kernergebnisse des Berichts, darunter die Rolle von transformationaler Führung, die Auswirkungen von DevOps auf Organisationsgeschwindigkeit und -stabilität, die Bedeutung von Automatisierung und kontinuierlicher Auslieferung sowie die Herausforderungen der Implementierung von DevOps in Legacy-Systemen. Besonders hervorgehoben wird der Wert von Microservices und Modularisierung sowie der Übergang zu einem Lean Product Management-Ansatz.
Inhalt
- Einführung in den State of DevOps Report
- Schlüsselerkenntnisse des State of DevOps Reports
- Bedeutung von transformationaler Führung in DevOps
- Beziehung zwischen Geschwindigkeit und Stabilität in DevOps-Praktiken
- Rolle der Automatisierung in DevOps
- Herausforderungen bei der Implementierung von DevOps in Legacy-Systemen
- Bedeutung von Microservices und Modularisierung
- Lean Product Management und Agilität
- Zukünftige Entwicklungen und Trends in DevOps
Shownotes
- Puppet
- DORA (DevOps Research and Assessment)
- Scrum Guide Revision 2017
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 zu einer weiteren Folge von dem Podcast
DevOps – auf die Ohren und ins Hirn.
Ich begrüße Sie wieder als Hörer und hoffe, dass wir mit unserer neuen Technik
Alex und ich haben ein bisschen investiert in neue Technik
dass wir mit unserer neuen Technik noch besser die Qualität rüberbringen können
dass die Form stimmt und an dem Inhalt sind wir ja eh immer dran.
Wir haben heute das Thema State of DevOps
den Report, den wir so ein bisschen auseinandernehmen werden
den wir ein bisschen zusammenfassen werden
und insofern würde ich sagen, heute haben wir keinen Gast
Sie haben heute die Chance, Alex und mich mal wieder ganz alleine zu hören
und insofern Alex, gebe ich gleich mal rüber an dich.
Ja, danke Dirk. Herzlich willkommen auch von meiner Seite aus der schönen Schweiz
Es ist ja inzwischen schon der fünfte Podcast, den wir machen
und ja, ich glaube, vorstellen muss ich mich nicht mehr gross
also in dem Sinne, ich freue mich auf das heutige Thema und das Gespräch mit dir.
State of DevOps Report, habe ich eben gesagt, ist unser heutiges Thema
Ja.
Wir beide kennen den ganz gut
wir nutzen ihn auch in unseren Schulungen, in unseren Workshops
aber vielleicht gibt es den einen oder anderen Hörer, der diesen Report noch nicht kennt
oder nur mal so am Rande was davon gehört hat
insofern denke ich, Alex, erzähl doch mal ein bisschen was zum Report.
Ja, gerne. Also das State of DevOps Report ist inzwischen das vierte Mal, dass der erscheint
das ist eigentlich eine Studie, ein Reality Check
also werden Unternehmen gefragt, was macht…
was macht ihr effektiv im Bereich DevOps zu der Erhebungsmethode
kann ich dann gleich noch was sagen
also es ist eigentlich so sehr ähnlich
einige von euch kennen vielleicht den State of Agile Report
der ja dann im Bereich Agile schon seit vielen Jahren schaut
ja, was sind effektiv Praktiken, die die Unternehmen anwenden
was machen die genau
also wie gesagt, der Reality Check
und nun das gleiche im Bereich DevOps
ursprünglich wurde der DevOps Report, der wurde vom Puppet herausgegeben
Puppet ist ja ein bekannter Tool-Hersteller, auch im Bereich DevOps
die haben dann aber gesagt, weil das dann zu…
zu, sag ich mal, vom Hersteller kommt
und dann ist dann die Glaubwürdigkeit auch ein bisschen ein Problem
dann wurde eine neue Organisation gegründet, die DORA
das steht für DevOps Research and Assessment
also…
ein Institut, die diesen DevOps Report dann neu jährlich rausgibt
und vielleicht ganz kurz, eben wie wurde der Report gemacht
also da wurde wirklich darauf geachtet, dass halt sehr breit eine Umfrage stattfindet
also einerseits mal von der Demographie her
also es wurde…
also ich weiß, der Report ursprünglich aus den USA kommt
ist schon die Hälfte der befragten Unternehmen aus den USA
dann ein Drittel etwa…
Europa und 10% Asien und der Rest dann…
der Rest der Welt, also Südamerika, Australien etc.
was auch darauf geachtet wurde
also im Sinne, dass es nach der Repräsentative ist, die Resultate
die eigentlichen Branchen, also es wurden unterschiedlichste Branchen
Unternehmen aus unterschiedlichen Branchen befragt
also einerseits mal Technologie natürlich
etwa ein Drittel dann die Finanzindustrie
Retail, Telekommunikation, Bildung
also die ganze Breite ist abgedeckt
und was sie dann eben gemacht haben
sie haben nicht nur Unternehmen befragt
jetzt die wirklich…
sagen wir DevOps
gut, man kann nicht DevOps machen
aber man kann Continuous Delivery
also Firmen, die einerseits schon wirklich DevOps Praktiken anwenden
aber auch andere traditionell geprägte
um dann auch einen Vergleich zu machen
was ist dann der Effekt von DevOps
da wären wir dann…
da wären wir dann später auch noch drauf kommen
vielleicht für diejenigen, die auch den DevOps Report runterladen wollen
man kann das machen auf…
entweder auf der Webseite von Dirk
auf devops.de
kann man den aktuellsten Report runterladen
oder sonst auch bei meiner Seite
devops.ch
da könnt ihr dann effektiv reinschauen
ja, ich werde ihn bei mir eben genau bei den Shownotes
zu diesem Podcast bereitstellen
dass derjenige, der neben unserer Stimme auch noch ein bisschen was lesen will
auch die Chance hat, das mal im Detail nachzulesen
gut, ja Alex, danke für die…
für die Einführung dazu
ich habe ja gesagt, wir beide nutzen das in unseren Trainings
und in den Schulungen
ich finde es immer sehr, sehr interessant
und wir werden ja auch im Verlauf des Podcasts
noch ein paar wirklich interessante Ergebnisse rausfinden
oder darstellen
und das…
da bin ich schon mal gespannt drauf
gibt es…
zu Anfang gibt es ja so eine schöne Zusammenfassung
so eine Art Summary
was sind denn 2017 die wichtigsten Erkenntnisse gewesen
die Key Findings?
ja, also ich kann das ganz kurz zusammenfassen
wenn wir das eine oder andere noch vertieft anschauen
so sechs Key Findings
also das erste Key Finding war
Stichwort Transformational Leadership
damit ist gemeint, dass halt die Firmen, die erfolgreich DevOps machen
weg vom Tayloristischen traditionellen Management
Richtung DevOps Lean Leadership
also selbst organisierte Teams
und dann mit dem Leader, der dann halt mehr die Vision vorgibt
also eine andere Art von Führung
die auch zentral zu sein scheint für den Erfolg von DevOps
das andere ist auch wiederum die Feststellung
Firmen, die DevOps machen
die sind signifikant
also einerseits schneller
Time to Market
aber gleichzeitig auch die Stabilität
die…
die verbessert wurde
das dritte Key Finding
Automatisierung
also das…
das Automat…
die Firmen sagen, die…
die erfolgreich…
diese High Performing Organisations sagen
Automatisierung ist…
ist zentral für uns
das hat einen…
einen Unterschied gemacht
und dann der nächste
der ist…
ja sorgt dann für Diskussionen manchmal
Stichwort bimodale IT
dass man…
die Firmen kommen weg vom Gedanken, dass
es gibt ein Teil der IT, die macht DevOps
und der Rest nicht
dass man…
die Aussage ist
DevOps applies to all Organisations
dann ein weiteres Key Finding ist
ich würde mal sagen
DevOps is not enough
also es ist natürlich, wenn man unten dran Monolithen hat
architektural wird schwierig
dann DevOps umzusetzen
das heisst, was viele Firmen
Key Finding
man arbeitet an der Architektur
Stichwort SOA
Microservices
Modularisierung
und das letzte Finding war
ist noch das Thema
Lean Product Management
also die Art und Weise wie Produkte
dann weiterentwickelt werden
also dass die
sagen wir das Stichwort Agilität
oder Lean Product Management
auch eine zentrale Rolle spielt
weil viele sehen ja dann
DevOps sagen wir als eine
Erweiterung vom agilen und Lean Gedanken
und das wird da bestätigt
also das sind so zusammenfassend
die Key Findings
und ja vielleicht macht es jetzt Sinn
dass wir vielleicht ein Thema
gerade dann tiefer reingehen
weil das ein Thema
das ja in den vergangenen Reports immer
im Zentrum stand
nämlich
anknüpfen
auch zu den Zielen von
DevOps
DevOps schneller
besser
und hier jetzt der
DevOps Report
also wenn wir jetzt da
diejenigen die den
Report vor sich haben
müssen man auf Seite
muss ich jetzt selber schnell suchen
Seite 21
das wurde ja wiederum bestätigt
eben massiv
kürzere Durchlaufzeiten
und gleichzeitig auch die Stabilität
die erhöht wird
also in der Praxis
durch Umfragen bestätigt
und da könnte man vielleicht
ein bisschen
Dirk diskutieren
also wenn wir jetzt die
das anschauen
da steht zum Beispiel
46 mal häufiger werden
Deployments gemacht
440 mal schneller
Lead Time
96 mal kürzere
Störungsbehebungszeit
das ist sehr beeindruckend
da können wir vielleicht
ein bisschen diskutieren
Dirk auch das
ja das warum
also ich finde es auch interessant
weil das sind Zahlen
die natürlich wirklich
aus der Praxis kommen
die erhoben wurden
und wenn ich an meine
Schulungen denke
dann gibt es dann schon
den einen oder anderen
oder auch bei Vorträgen
den einen oder anderen
der sagt
das kann bei uns aber
nicht funktionieren
das kann bei anderen sein
Facebook schafft das
und Google schafft das
aber wir können
das nicht schaffen
und insofern finde ich
es interessant
und hoffe auch
dass die
Masse
die
Anzahl der Teilnehmer
weiterhin steigt
und dass die
Anzahl der Teilnehmer
weiterhin steigt
dass man einfach
auch da nochmal
Firmen mit reinbekommen
die jetzt eben nicht dabei sind
und für mich ist das
eine Bestätigung
dass das geht
dass das gehen kann
natürlich geht es nicht
von jetzt auf gleich
du hast es ja auch gesagt
so Microservices
ich habe
häufig noch
monolithische
Applikationen
die vielleicht
in einer großen
Datenbank arbeiten
oder wo ich
auch vielleicht SAP
im Einsatz habe
aber prinzipiell
wenn man daran arbeitet
das überschaubarer
zu machen
von den Teams her
dann denke ich
kann man dahin kommen
und es gibt
viele Firmen
die auch die ersten Schritte
dahin machen
das heißt
die haben dann
beispielsweise nicht
jeden Tag
hunderte von
Deployments
oder hunderte von
Produktivsetzung
von kleinen Änderungen
das was man ja auch
den großen
bekannten amerikanischen Firmen
dann nachsagt
die haben das nicht
aber
sie kommen dahin
dass sie eben
statt zweimal im Jahr
ein großes Release
ausrollen
dass sie schon
einmal im Monat
ein kleineres Release
ausrollen
die eben
diesem Weg folgen
aber natürlich
noch nicht so
ganz so schnell
wie das vielleicht
dann die Vorreiter da sind
und das hat ja dann
auch einen positiven
also ich glaube
das Beispiel
das du genannt hast
so ein häufiger Release
das hat einen
positiven Einfluss
auch auf die
Stabilität
im Sinne
also wenn man jetzt
im Report schaut
das Meantime to Recover
also die
Störungsbehebungszeit
ist im Schnitt
bei diesen
sagen wir
DevOps Firmen
96 mal kürzer
und deshalb
ich sage immer
wenn man jetzt
zwei Releases
im Jahr hat
dann
viel Spass
beim finden
einer Fehlerursache
weil es gibt ja
nach jedem Change
gibt es Störungen
und wenn man halt
dann eher kleine
Päckchen hat
dann ist
in der Regel
ist es dann
haben wir viel schneller
auch die Ursache
des Fehlers
gefunden
kann man schneller
einen Rollback
machen
oder gut
die Amerikaner
würden wahrscheinlich
eher fix forward
also das
heißt
39 mal kürzerer
Meantime to Recover
und für mich
auch für
schon
gekommen
aber
calex
mit
sowieso
mein
zu senken und wir werden hier 96 mal schneller. Wie gesagt, das ist ein enormer Wert, ein enorm hoher Wert, aber das zeigt, dass das geht, wenn man eben Dinge verändert und dann einfach startet. Also insofern, für mich ist das eben auch ein Argument zu sagen, auch der Betrieb, der ja vielleicht wirklich klassisch als der langsame Bereich dasteht, hast du ja gesagt, bimodal, sprechen wir nochmal drüber gleich,
dass auch der Betrieb eigentlich ein Interesse daran haben sollte, auch im Sinne von IT-Service-Management, von ITIL, zu sagen, hey, wir müssen uns um das Thema DevOps kümmern.
Genau, das sehe ich auch so. Es ist auch spannend, die Zahl, da wird auch eine Aussage gemacht, das Change-Fail-Rate, also im Schnitt jetzt die Firmen, die DevOps machen, dass die im Schnitt fünfmal weniger Fehler haben.
Und da ist auch eben, das Spannende ist immer die Diskussion, die ich mit den Leuten, also mit Kunden habe, aber auch in den Schulen, warum ist das dann so und bei DevOps ist ja, sagen wir, diese, hatten wir in früheren Podcasts darüber gesprochen, Shift-Left, also you build it, you own it und es wird sehr früh, es werden Tests, auch nicht-funktionale Tests werden und auch Antworten definiert und die Tests dazu automatisiert,
also einen starken Fokus auf ein starkes Test und ich denke, das ist so der Hauptgrund, wieso auch die, also nicht nur die Störungsbehebungszeit zurückgeht, sondern auch die effektive Fehlerrate zurückgeht, also im Kontext mit Test-Automatisierung.
Spannend, also das war jetzt so der Stabilität, wir haben ja alle mal gelernt, also dass wenn man schneller wird, geht die Stabilität runter und umgekehrt, wenn ich mehr Stabilität und mehr Change-Control,
dann geht es besser.
Ja, der Speed runter, aber hier wirklich das Faszinierende, beides geht ja, also DevOps will ja beides erhöhen und jetzt haben wir gesagt, ja, okay, Stabilität besser und dann eben dieses Lead-Time-for-Changes, also die effektiv, die Dauer, die, wie lange es geht, ein Change umzusetzen, sozusagen im Schnitt 440 Mal schneller, also es ist einfach jetzt mal aus der Umfrage raus und das ist natürlich auch wieder, ich würde sagen, das,
das magische Wort dahinter ist auch wieder Automatisierung, also vor allem auf Deployment-Seite, aber auch die ganze DevOps-Pipeline, also der, sagen wir im Idealfall der Entwickler-Check-In-Code und hintendran werden automatisiert die ganzen Tests ausgeführt, wenn man das richtig hinkriegt und quasi dann könnte jederzeit sagen, ja, jetzt meine Software ist in der Releasable-State und ich habe die Zahl, diese, auch wenn sie ein bisschen
Anfang war ich da skeptisch, habe gesagt, das kann ja nicht sein, also traue nie einer Statistik, die du nicht selber gefälscht hast, aber es ist schon, es lässt sich erklären.
Ja, ja, was ich interessant finde, du hast ja eben auf die Tabelle auf der Seite 21 referenziert, wenn man noch ein bisschen weiterblättert, es gibt da noch ein bisschen Unterteilungen, das heißt auf der Seite 23 gibt es die Unterteilung beim Change-Failure-Rate, also bei der Rate, wo Fehler mal nach einem Change
auftreten, 2017 im Durchschnitt fünfmal niedriger, wenn man es aber mal unterteilt in die einzelnen Organisationen, das macht ja der DevOps-Report, der unterteilt ja die Organisationen oder teilt sie ein in High-Performer, in Medium-Performer und in Low-Performer und wir alle wissen, was wir mit Low-Performer meinen, wenn wir über einen Menschen sprechen, also in diesem Fall hier haben wir den Low-Performer von der Organisation her und da ist das Interessante, die Change-Failure-Rate, die ist da im Prinzip
dreimal,
so hoch bei den Low Performern im Vergleich zu den High Performern.
Das heißt, diese fünffache, fünffach niedrigere Rate im Durchschnitt,
die wird nochmal ein bisschen genauer auseinandergerechnet,
indem einfach gesagt wird, dieser Wert wird quasi durch die Low Performer
nochmal nach unten gezogen.
Das heißt, die High Performer und die Medium Performer,
die sind zwischen 0 und 15 Prozent.
Also die haben relativ hohe Erfolgsquote bei Changes.
Ja, das wird ja sehr, und wir haben ja gerade einführend gesagt,
in der Erhebungsmethode wurden tausende von Unternehmen befragt,
aber eben in der ganzen Breite, also wirklich auch ganz traditionell
auf der anderen Seite die Unicorns.
Und da wurde dann so wie eigentlich ein Clustering gemacht
und dann diese Einteilung und die drei.
Das hilft auch noch fürs Verständnis.
Ja, also was ich interessant finde, ist für diesen Bereich die Aussage,
es geht, man kann Agilität, eine schnelle Lieferung,
verbinden mit Stabilität.
Wenn man das im Sinne eines DevOps-Konzeptes
und einer Philosophie macht, dann kann man das verbinden.
Das ist für mich eine zentrale Aussage und du hast es ja auch gesagt,
die kann man nicht vom Tisch wischen.
Man kann sie erklären und das versucht ja der DevOps-Report.
Ja, ich würde mal auf einen anderen Punkt gehen.
Du hast vorhin schon gesagt, Transformational Leadership
und das für die, die nachlesen wollen, finden wir auf den Seiten,
oder ab der Seite 12.
Das ist eben auch ein wichtiger Punkt,
dass man eben nicht nur die Uniformen,
nicht nur auf die technischen Dinge abzielt,
das war ja eben eher Technik oder geht ja stark in die Richtung Technik,
sondern auch in das Thema Führung.
Wie sieht eine Führung anders aus?
Und wenn man sich so, weiß nicht, bei Xingo, LinkedIn und sonst wo,
bei Twitter die ganzen Nachrichten anschaut,
dann wird einem ja als Führungskraft,
müsste einem ja Angst und Bange werden,
weil man alles falsch macht und weil man nicht modern ist.
Hier der Hintergrund ist Transformational Leadership.
Das ist eine Aussage, die getroffen wurde.
Wie hast du diese Aussage,
wie hast du diese Aussage interpretiert?
Was ist für dich Transformational Leadership?
Ja, also ich habe, als ich den Titel gesehen habe, gesagt,
hm, was könnte sich dahinter verstecken?
Aber als ich dann den Inhalt durchgelesen habe,
ich denke, man könnte hier auch genauso von Agile oder Lean Leadership sprechen.
Und ich denke, dass jetzt diese auch grundsätzliche Transformation,
die viele Unternehmen durchmachen,
als sich Richtung agile, selbstorganisierte Teams bewegen,
aber auch, also das eine ist ja, wie man sich als Team organisiert.
Aber es hat auch jetzt einen grossen Einfluss
auf auch das Selbstverständnis des Managements und der Führung.
Wie sehen wir unsere Rolle? Wie führen wir?
Und ich denke da, das ist auch der schwierigste Brocken,
weil wir kennen ja alle den Spruch
Culture eats strategy for breakfast.
Das heisst, die Leute, also man kann die schönsten Pläne haben,
aber wenn die Leute das nicht wollen,
auch das Management halte, nicht loskommen,
sagen wir, von der Art und Weise, wie sie die letzten 30 Jahre geführt haben,
dann scheitert das.
Es ist jetzt auch ein Kulturwandel, der stattfindet im Bereich Führung.
Und ich nehme da immer den Vergleich, also um das ein bisschen zuzuspitzen,
wenn man, ich übertreibe jetzt natürlich masslos,
aber es wird auch schon eigentlich im Report so gezeigt,
dass, wenn man das traditionelle Management,
tayloristische Management anschaut,
dann sieht man, der Manager, der Manager weiss, was gut ist für das Team.
He tells the team, das Team führt aus, wird über KPIs gesteuert.
Also die Welt der hohen vertikalen Gebäude, eben oben der Manager.
Und jetzt eben Transformational Leadership, sagen wir von der Idee her relativ alt,
aus dem Lean Leadership heraus, letztes Jahr, 160er Jahre,
das ist halt eher so die Welt der flachen Gebäude.
Da hat man einerseits das Team, das Team hat gemeinsames Verständnis, wie man arbeitet.
Das Team macht regelmässig Retrospektive, verbessert sich und macht auch Crosstraining.
Und was ist dann mit dem Manager?
Eben der Manager, man spricht nicht mehr vom Manager, sondern vom Leader.
Die Aufgabe des Leaders ist, sie sprechen dann auch eine Vision, eine Vision vorzugeben.
Was wollen wir?
Die Teams sind ja typischerweise um Produkte herum oder Services sorgen.
Was ist unsere Produktvision?
Und dann nicht den Leuten sagen, wie sie das erreichen sollen,
sondern welches Problem muss gelöst werden.
Und dann auch die richtigen Fragen stellen, den Teams helfen,
ihnen die Umgebung geben, dass sie sich weiterentwickeln können.
Und natürlich, ich meine, ich mache selber relativ viel Agile Coaching,
also auch Scrum Coaching, also helft den Unternehmen als Coach, sich Richtung Agile zu bewegen.
Und das ist dort genau der Move, den wir machen.
Also einerseits die Mitarbeiterebene, wie es versteht sich das Team selbst,
aber dann auch der Leader, wenn er zum Beispiel dann Scrum anschaut,
dann wird das in zwei geteilt, zum Beispiel Produktdonor,
der ist mehr für die Vision und die Anforderungen und der Scrum Master,
der schafft die richtige Umgebung.
Und spannend ist ja dann,
dass heute wird, dass er dann das nicht nur auf unten auf Team-Ebene,
sondern dass man das bis zu oberst oben skaliert.
Also man hat dann auch zu oberst auf C-Level,
wie die ihre, dass sie sich auch eher als Leader sehen
und eben nicht als Micromanager.
Das ist so, also auch aus dem Report, der Report sagt eigentlich ja,
dass die Unternehmen sehen diesen Teil als kritisch,
dieses Transformation Leadership als kritisch,
erfolgreich zu sein mit DevOps.
Ja, du hast es angesprochen.
Leadership ist ja ein Thema, was wir auch in dem agilen Umfeld haben.
Insofern, als ich das gelesen habe, fand ich zwei Dinge interessant.
Erstens, dass es ein Modell gibt,
nachdem man dieses Transformational Leadership quasi bewerten kann.
Auf dieses Modell beziehen sich ja die Autoren des State of DevOps Report
und das ist eben ein Aufsatz, der jetzt schon 13 Jahre alt ist,
an der Stelle, und der eben ein Modell beschreibt
mit fünf Charakteristika, wie Transformational Leader quasi auftreten,
wie sie denken, wie sie ticken und wie man eben genau das bewerten kann.
Und diese fünf Punkte finde ich sehr interessant.
Vielleicht ganz kurz, die Vision hast du eben angesprochen.
Charakteristisch für einen Transformational Leader ist eben,
dass er eine Vision hat, wo will die oder wo soll die Organisation
in fünf Jahren sein, als Beispiel.
Es geht um Inspiration.
Inspirierende Kommunikation, das hast du im Prinzip auch schon
ein bisschen angesprochen, eben keine Vorgabe,
sondern ein Transformational Leader kommuniziert in einer Art und Weise,
dass er damit die Leute inspiriert und motiviert.
Also er spricht die Leute eben an, eine inspirierende Kommunikation.
Das ist der zweite Punkt, der quasi in diesem Modell beleuchtet wird
oder der in diesem Modell betrachtet wird.
Dritter Punkt ist die intellektuelle Stimulation.
Das heißt, der Transformational Leader, der macht sich Gedanken über die Probleme
und erregt sich und auch seine Mitarbeiter quasi oder seine Teammitglieder an,
darüber auch nochmal nachzudenken.
Also er stimuliert letzten Endes auf einer intellektuellen Ebene an der Stelle.
Vierter Punkt, Supportive Leadership.
Das heißt also, ein Transformational Leader kümmert sich in einer Unternehmenspolitik,
unterstützenden Weise um die persönlichen Belange seiner Follower, seiner Teammitglieder.
Auch das geht so ein bisschen in Richtung Servant Leadership.
Ich komme gleich noch auf einen anderen Unterschied, auf einen wichtigen Unterschied
zwischen diesen beiden Konzepten, aber Supportive Leadership, der vierte Punkt.
Der fünfte Punkt, persönliche Wahrnehmung, sage ich mal.
Das heißt also, der Transformational Leader hat eine persönliche Wahrnehmung von dem Ganzen.
Also,
hier fünf Punkte, wie man einen Transformational Leader quasi charakterisieren kann.
Und ich habe eben schon gesagt, für mich ein zweiter Punkt, der noch wichtig ist,
als ich gelesen habe, Transformational Leader, habe ich gesagt, hey super,
wieder ein neuer Fachbegriff, wieder was Neues für Servant Leader.
Nein, es gibt einen Unterschied und das ist eben für all die, die Servant Leadership verstehen
und verinnerlicht haben, eben sehr schön beschrieben.
Auf der Seite 14 gibt es so eine kleine Box.
Es gibt einen Unterschied zwischen einem Servant Leader und einem Transformational Leader.
Und der Unterschied ist im Prinzip derjenige, dass der Servant Leader die Entwicklung,
die Performance seines Teams im Blick hat.
Also, er unterstützt die Entwicklung und die Performance seines Teams.
Also, fokussiert sich mehr auf das Team, wenn man das so will.
Hilft dem Team, indem er es eben führt.
Also, dienender Führer, er führt, indem er dem Team quasi dient.
Führt damit aber auch.
Der Transformational Leader, der versucht oder hat als Ziel,
dass sich die…
Follower, sein Team, sich mit der Organisation identifizieren
und eben versuchen, ihre Arbeit sinnvoll so zu gestalten,
dass die Organisation unterstützt wird.
Also, das ist schon, wie ich finde, eine andere Sichtweise.
Und insofern, das sind auch Themen, die man sicherlich nochmal,
ja, auch vielleicht in einem späteren Podcast mal genauer auseinandernehmen kann.
Da gehen wir ja wirklich in die Anforderungen an Führer.
Wobei, wenn wir Deutschen dieses Wort gebrauchen,
müssen wir ja mittlerweile immer noch vorsichtig sein.
Also, ein Leader…
Mal das englische Wort.
Also, ein Leader an der Stelle, der Transformational Leader,
ist ein bisschen anders unterwegs.
Und das, was eben der State-of-Dev-Ops-Report aussagt,
das ist ein Erfolgsfaktor.
Aber wie gesagt, es ist ein kleiner Unterschied,
aber ich finde auch einen wichtigen Unterschied zu einem Servant-Leader,
wie wir ihn aus der agilen Welt kennen.
Das fand ich jetzt so gut, dass du auch die Unterscheidung gemacht hast.
Es ist dann auch, auf welcher Ebene, also ist es mehr auf Team-Ebene
oder geht es darum, sagen wir mal,
dass…
Ja, ja, ja.
Es knüpft dann wieder an die Vision an.
Der Transformational Leader, der auch eine klare Vision vorgeben muss
und das dann in die Organisation reinbringen kann.
Und nicht einfach nur, sagen wir, der Servant-Leader,
der es dann mehr die Teams selber führt.
Haben wir noch andere Key-Findings, die wir ausführen können?
Also, der Report ist ja recht lang.
Aber ich habe mir…
Also, wir haben es ja auch im Vorfeld gedacht,
da müssen wir ein bisschen Fokus setzen,
dass dann der…
Das kann sich zwei Stunden lang werden.
Also, ein Thema, das vielleicht die Leute noch interessiert,
ist, weil…
Wir haben auch schon mal gesagt, man kann nicht DevOps machen.
Aber was man machen kann, sind die ganzen DevOps-Praktiken.
Das interessiert ja die Community immer sehr.
Also, da gibt es dann auch ein Kapitel dazu.
Das hat dann zwar das Kapitel, den Titel
Technische Practices.
Und da ist natürlich an erster Stelle
kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
das als Top-Trio.
Content ist jetzt halt mehr, er spricht von
Technologie, aber auch Prozessen.
Und vielleicht
ist es wert,
das könnte ich auch machen, aber
Continuous Delivery generell
ist ja, baut auf
Continuous, also die, die es vielleicht noch nicht
so kennen, baut ja auf
Continuous Integration auf.
Also bei Continuous Integration
die Praxis, dass man
als Entwickler, man arbeitet
an gemeinsamen Repositoren,
Cori,
und werden automatisierend
ein paar Basistests gemacht, das ist ja auch
ein bisschen alter Hut,
dann aber Continuous Delivery, so dieses
Mindset, dass
das, was, wenn ich
etwas mache, sagen wir als Ingenieur
oder Entwickler, ich will
Feedback bekommen, sofort
ist das, was ich
mache, richtig.
Also richtig, nicht nur jetzt im alten Sinn,
okay, mein Kollege
hat es reviewed, oder ich habe so ein
paar funktionale Tests gemacht,
sondern wirklich so weit, dass man
auch nicht-funktionale
Tests, also zum Beispiel
Security, Performance,
man baut das alles ein
und dass man
dann, eigentlich wird dann mit die Agilität
auch dann zu Ende getrieben,
ich bekomme sofort Feedback, ist es
wirklich dann oder nicht,
und wenn nicht, dann muss ich es eben korrigieren
und ich kriege dann nicht erst in drei Monaten
Feedback, wenn dann irgendwann
später ein Performance-Test
sagt, ist nicht gut. Also da ist jetzt
die Firmen fokussieren sehr stark
einerseits Infrastruktur,
Continuous Delivery,
da hängt natürlich der ganze unten dran,
man braucht
Cloud-Infrastruktur, also
dass man on-demand dann die nötigen
Testumgebungen bekommt, aber
dass auch man
investiert in Test-Driven
Development, früh schon
Tests, anfangen
als Test-Cases
definieren, automatisieren,
und
was da auch, steht glaube ich
auch drin, das kann man ja nicht von heute
auf morgen, sondern das ist auch wieder
ein Weg, das kann Jahre dauern,
wenn man aus dem Legacy kommt, sagt man
okay, jetzt automatisiere ich
mal den Teil, dann mal den Teil,
investiere ich in das,
und dann kommt man diesem Continuous
Delivery, dieser Vision
dann immer ein Stück näher.
Also es ist so, was ich rauslese
aus dem Report, dass es jetzt
extrem Fokus ist, auch bei den Firmen.
Ja, also ich
finde auch, und wir hatten ja gerade vor
ein paar Tagen das
Webinar von Jeff und
Ken Schwaber, von Jeff Sutherland,
Scrum Guide
Revision 2017, die Änderungen,
und da haben sie ja auch das Wort
DevOps auftauchen lassen,
das heißt also, der Scrum Guide
sieht auch, DevOps, da tut sich
was, und du hast eben so ein wunderschönes
Wort gesagt, dann, also wann
ist es fertig, wann ist es wirklich fertig,
und das ist eben das Schöne,
das ist der ganz feine Unterschied, der aber natürlich
viel nach sich zieht, wenn
ich rein nur auf Scrum mich
beziehe, dann bin ich fertig,
wenn die Definition of Done erfüllt ist,
und die ist aus Sicht von Scrum, wenn man
das Scrum ganz eng sieht,
dann, wenn der PO das abgenommen hat, dann muss
es noch nicht in Produktion sein,
und wenn ich dann sage, dann ist es
erst, also es ist erst dann fertig,
wenn es in Produktion ist,
und dort läuft, das ist nur ein kleiner
Schritt, aber ein
Riesenschritt, weil ich muss ja wirklich eine Menge
dabei tun, und das ist eigentlich auch
eine weitere Herausforderung, du hast ja gesagt,
wir reden über technische Praktiken,
Technical Practices, aber da hängt
natürlich auch Organisation und Mindset
wieder dahinter, ein Entwickler, der sagt,
habe ich entwickelt, PO
hat es abgenommen, bin zufrieden,
kann mich zurücklehnen, der muss sein
Mindset an der Stelle eben auch ändern, also
dann heißt, wenn es dann fertig
in der Produktion ist, und nicht auf einem
Entwicklungssystem oder auf einer
anderen Stage. Ja, also ich war gerade
in die, diesbezüglich war gerade
heute Morgen,
ein agiles Team, ich begleite
die, das hat sehr,
sagen wir, sehr Scrum-lastig, und
da habe ich mal gesagt, heute, ja, lass uns
mal ein bisschen über DevOps sprechen,
lass uns über die Definition of
Done sprechen, oder was
macht, würde es nicht Sinn machen, das jetzt mal ein bisschen
weiterzuentwickeln, also was ist
unser Verständnis über
Done, wollen wir uns mal Gedanken
machen, langfristig
gewisse Tests, Einbud
zu beziehen, also dass es dann auch
innerhalb vom Sprint ist,
effektiv erst dann,
wenn man auch weiss, ja,
es wird die Security-Tests
bestehen, es wird die
Performance-Tests bestehen,
und dann ist es eben spannend,
dass die aus den agilen Ecken,
die sagen, für sie ist eigentlich DevOps
doch nicht so neu, man hat zum Beispiel das
Wort Continuous Delivery, das ist ja schon
im agilen Manifest von
2001, taucht
das Wort ja schon auf, also
die Agilen haben ja schon immer gesagt, lass uns über das
Definition of Done, die
muss immer besser werden, immer näher zu,
aber das Problem ist, die Entwickler haben sich einfach nie
für den Betrieb interessiert,
und das ändert sich ja
jetzt, indem man dann, und da
reden wir dann nicht mehr über Technik, sondern
man beginnt
Betriebsleute in solche
Scrum-Teams zu integrieren,
dass sie eben auch ein Stake bekommen,
weil das sind die, dass man
dann diese operativen
Dinge auch bereits schon
in der Definition of Done
einwirkt, und da wir heute,
also da haben wir uns grundsätzlich
gesagt, ja,
lass uns Zeit investieren, das wird
ein langer Weg sein, aber dann immer
näher. Richtig, ja.
Langer Weg, weil ja auch die User-Stories,
die Anforderungen entsprechend kleiner
gepackt werden müssen, denn, wenn du hast
gesagt, Security-Test, viele andere
Tests, die kann ich nicht alle in einem
Zwei-Wochen-Sprint einbauen und die mal
eben dazu packen, das heißt, das ganze
Thema Testen und andere Anforderungen
drumherum, das muss ja auch
vorbereitet werden, dass das überhaupt
macht.
In einem entsprechenden
Sprint an der Stelle, also insofern
vollkommen richtig, da ist noch ein bisschen was
zu tun, aber auch meine
Sichtweise ist, oder meine
Erkenntnis ist, dass die Entwickler eigentlich
damit, ich sag mal so, kein Problem
haben. Wahrscheinlich sind das eher
bestehende Schranken,
bestehendes Simudenken, was
sie davon abgehalten hat,
quasi, oder wo sie abgehalten wurden,
sich auch um den Betrieb mit zu kümmern.
Da wurde einfach übergeben an den Betrieb
und du hast eben gesagt,
dass die Betriebsleute in die Teams
reingeholt werden. Das ist für mich
nochmal ein wichtiger Punkt, weil
ich würde jetzt nicht sagen, ich nehme
meine Betriebsmannschaft, teile die
fein auf, auf die einzelnen Scrum-Teams
und dann mache ich DevOps. Also das wäre ja
ein Missverständnis. Mein Verständnis
ist ja eigentlich eher, dass ich das
Wissen, das Betriebswissen in die
Teams packe. Ja, aber es hat mit
Verantwortung zu tun. Also meine, da gibt es
natürlich unterschiedliche Ansichten, aber
die meisten Kunden, mit denen ich zu tun
habe, die sagen wirklich, das hat der Gedanke
von Spotify. Man hat diese Teams
und die haben, you build it,
you own it. Weil solange
immer noch so ist, dass
jemand anders ist ja dann für den
Betrieb verantwortlich, dann haben
die nämlich gar nie ein Interesse, die
betrieblichen Dinge reinzunehmen. Also wir
versuchen, also nicht unbedingt
fest in die Teams, aber dass
die dann an,
wenn es um Planung geht, etc.,
zum Beispiel Sprintplanung, dass die
vertreten sind drin
und dass, also wir gehen dann so weit,
dass wir sagen, wir haben eine
und das Team hat dann auch betriebliche
Verantwortung. Es werden natürlich gewisse
Scherzdinge, die muss man immer separat
machen, also das ist klar.
Ja, also wir sind ja noch beim
DevOps Report, bei den Technical
Practices, was ich noch interessant finde
ist, du hast ja eben schon was zum
Continuous Delivery gesagt,
da ist auf der Seite 33
nochmal der Punkt
Fast Feedback on the Quality and the
Deployability. Genau.
Ein wichtiger Punkt, was ich da
schön auch am agilen Vorgehen
finde,
ist ja, und auch natürlich am
Lean Management ist, kontinuierliche
Verbesserung. Und kontinuierlich heißt für mich
immer in kleinen Schritten, in kleinen Häppchen,
ich sehe sofort, ob das funktioniert,
ob es nicht funktioniert, habe sofort ein
Erfolgserlebnis, habe sofort eben dieses
Feedback. Und dieses Fast Feedback,
was hier bei der Continuous Delivery
rüberkommt, finde ich eben auch sehr, sehr interessant,
dass eben die Entwickler, wie du es ja auch
gesagt hast, die kriegen schnell das
Feedback. Und egal,
ob das jetzt ein kleines oder ein größeres
Team ist, jeder im Team kriegt
dieses Feedback und kann daraufhin
sich seine Meinung bilden und kann eben
schauen, was muss man tun, um
mit dem Feedback quasi umzugehen
und mit dem Feedback zu arbeiten. Also
auch hier wieder,
es geht zwar um technische Praktiken,
die aber eben auch entsprechend
kulturelle, organisatorische
Veränderungen haben, Mindset-Veränderungen
und hier eben ein Fast Feedback,
also du kriegst ein schnelles Feedback als Entwickler,
ob das, was du gebaut
hast, auch wirklich funktioniert.
Und wie du es eben gesagt hast, nicht nur auf
Testumgebung, sondern
Security-Tests werden bestanden, andere
Tests werden bestanden, es funktioniert in der Produktiv-
Umgebung. Das finde ich eben auch das Schöne
und das Interessante.
Ja, wir haben ja, also wenn man schaut, Continuous Delivery
ist ja ein Punkt, was dann
als nächstes kommt, ist das ganze Thema
Architektur.
Also die
Aussage, dass auch dort jetzt
viel Veränderung
stattfindet. Wir haben ja kurz
über Modularisierung so angesprochen.
Gut, also ein weiterer
Punkt jetzt in dem Kapitel
Technical Practices,
zwar eben jetzt mit Klammer,
es geht ja nicht nur um Technik,
wie auch der Dirk schön gesagt hat,
es gibt Prozesse,
Kultur, du musst das auch unterstützen,
aber ein weiterer Punkt ist Architektur.
Und die Aussage
ist da,
dass die
Fähigkeit, also die, wenn man
sagen wir, man kann nicht
Continuous Delivery machen, man kann
nicht
in kleinen, selbstorganisierten Teams
und man kann auch nicht
inkrementell in kleinen Häppchen arbeiten,
wenn man unten dran immer noch Monolithen
hat.
Die ganze DevOps-Bewegung
kommt ja von diesen sogenannten Unicorns,
also wie Google, Netflix
und die hatten ja den Vorteil,
dass man die von Anfang an
die Architektur halt
DevOps-like gebaut
haben, nämlich
Modular,
in Microservices,
Clouds-Native
und wenn man das unten so,
die Architektur so ist,
dann hat man
es nach viel einfacher,
die anderen DevOps-Praktiken
umzusetzen.
Und ich hatte da auch,
wenn wir jetzt gut vom Report weg,
aber da fällt mir eine Anekdote ein,
oder eigentlich mehrere, ich habe sehr oft,
wenn ich beim Kunden
ein bisschen vorstelle,
DevOps und dann gerade bei den
Grossunternehmen, also bei uns zum Beispiel
die Banken, die machen schon sehr lange
IT in Deutschland, sagen,
das ist bei uns nicht möglich, weil
so Legacy und alles, wir können
die Architektur,
das ist
ein Rieseninvestment
und meine Antwort ist dann, also erstens,
die Frage ist nicht nur,
ist es möglich, sondern der Punkt ist
eben notwendig, wenn
sie jetzt, wenn sie
überleben wollen im kompetitiven
Umwelt, weil sie haben da eine Konkurrenz,
die machen das halt dann
einfach, das ist das eine
und das andere ist auch wieder Architektur,
das ist
das zu ändern, Richtung
Modularisierung,
das ist ein
extrem langer Weg,
also der kann sehr
lange gehen und das
Wichtigste ist einfach, dass man mal anfängt,
damit, man kann lange um den
Brei reden, aber das wollen wir auch hier wieder
in kleinen Schritten
dann die Architektur
graduell,
sie schreiben dann ja auch
auf Seite 36
loosely coupled
well encapsulated
architecture drives
IT performance.
Das braucht auch Zeit, aber es
ist wie, wenn die Architektur
nicht stimmt, in diesem
Sinne, dann gibt es
auch Schwierigkeiten, dann
continuous delivery und selbstorganisierte
Teams umzusetzen.
Also ich finde es interessant, deine
Anekdote an der Stelle, weil natürlich
kommt das Argument immer, das geht bei uns
nicht, weil wir eben
große Systeme haben, weil wir ein SAP
haben, was das nicht zulässt,
alles technisch gesehen erstmal
die richtigen Argumente, aber dann ist die Frage,
ja, können sich
Organisationen diese
Ausflüchte oder diese Erklärungen
noch erlauben oder ist nicht der
Wettbewerb so, der Druck von draußen so
stark, dass man einfach was tun muss
und das geht natürlich auch dann in Richtung
Disruption an der Stelle.
Also du hast
eben auch von den kleinen Schritten gesprochen,
wenn ich jetzt mal so ein bisschen weiterblättere,
Seite 43, da geht es dann, oder auch
Seite 42 geht es dann in Richtung
Lean Product Management und da
finde ich es eben auch interessant, dass
genau auch da so Erkenntnisse sind,
dass das ganze Thema
Lean Product
Management da mit
reinspielt, das heißt, ich
kriege bessere
IT-Performance hin, eine höhere IT-Performance,
wenn ich eben mit
kleinen Badges aber mitarbeite,
mit kleinen Teilchen, also die
und eben auch mit diesen kleinen Teilen
auch wiederum schnell Feedback bekomme und
das ist ja auch eben eine Erkenntnis
hier, die High Performer
sind High Performer oder
deswegen High Performer, weil sie es dann eben
schaffen, auch im Rahmen des
Deployments schnell das Feedback
zu bekommen und das Ganze
kriegt man eben nur hin und das quasi
gegenseitig die Beeinflussung,
man hat eine schlankere Produktion,
kriegt schnell da Feedback und das ist
wiederum dann die Voraussetzung, genau um
eben noch schlanker die Produktion zu
haben, also wirklich, dass
die IT-Performance quasi auch
eine Vorgabe ist und das
Thema Lean Product Management
treibt. Also auch hier wieder,
die Message mit
Small Badges, Short
Feedback Loops, ich denke, das zieht
sich so ein bisschen durch den Report
durch, über die verschiedenen
Themen,
auch im Thema Leadership,
im Thema dann
Continuous Deliveries, ja auch dann
Mittel zum Zweck, um dann
echtes Feedback
zu bekommen, schnell.
Und auch dann in den
Hard Fakten, die wir ganz am Anfang
besprochen haben, mit dem Schnelle
Bessere, das ist ja auch ein
Effekt von diesen
kleinen Badges, also in dem Sinn
dann kleine Päckchen,
kurze Release-Zyklen
und so dann schnelle Feedback-Loops zu bekommen.
Das zieht sich so ein bisschen durch, den ganzen
Report, fällt mir jetzt gerade
auf. Und mir fällt gerade ein, dass wir
vielleicht mal jemanden dazunehmen
sollten in so einem Podcast
zum Thema Microservices. Ich habe da
so ein paar Leute vor Augen, also
insofern habe ich mir ja gerade mal
notiert, dass wir auch mal das Thema
Microservices durch ein paar Experten hier uns
erläutern lassen sollen. Ja, genau, dass
man jetzt da mit ein bisschen Praxis
noch mehr, also Leute, jetzt die, also
wenn man die Report-Themen anschaut,
dann vielleicht den
einen oder anderen schnappt und der dann
auf Kundenseite was
dazu erzählen kann.
Ja, du hast vorhin noch mal
ein Stichwort genannt, was ich sehr, sehr interessant
finde, das Thema Bimodal, hat man ja gesagt,
Bimodal IT, wollen wir auch noch mal kurz
drüber sprechen und
da haben wir beide die gleiche Einschätzung.
Das hat unser kleines Vorgespräch
eben gezeigt. Wir sind da beide ein bisschen
skeptisch, ob das der richtige Ansatz ist
und wir beide haben auch vom Klaus Straub
das Interview oder den Bericht gesehen
von BMW,
der eben als IT-Verantwortlicher
sagt, Bimodal IT
ist für ihn kein Thema mehr oder ist
nicht mehr der richtige Ansatz
und insofern, Alex, warum denkst du,
ist das nicht der richtige Ansatz oder nicht
zeitgemäss? Ja, also ich bin auch ein bisschen
hin und her gerissen, aber ich hatte
ein interessantes Erlebnis
bei Kunden, die hatten die
Strategie eben Bimodal IT
und die haben gesagt,
Bimodal IT heisst ja
DevOps agil, ja,
für einen Teil der IT, aber den anderen
Teil lassen wir klassisch.
Und die haben auch das aus der Not
raus, mussten die die Strategie
haben, weil die haben gesagt, ja, wir haben
jetzt in bestimmten Produkte
Bereich, da wird
bald eine Konkurrenz kommen,
ernsthaft, ja, und wir müssen da
schnell,
wir müssen da Konkurrenz,
die wollten dann neue Leute,
neue Architektur, und da
die haben gesagt, mit der alten IT können
wir das gar nicht, also Bimodal IT,
da denkt man, ja, das macht Sinn
und ich weiss auch, dann haben sie
interviewt
ein paar Experten, das kam damals von
HR, oder, da ging es dann darum,
sie wollen so eine agile Story,
eben für den einen Teil der Bimodalen IT,
um die Leute zu begeistern,
für Agilität, für DevOps, und die haben mich
dann gefragt, ja, Alex, kannst du
das mal eben so, wie würdest du die Leute
für DevOps
begeistern?
Und dann habe ich dann, ja, mir überlegt,
und dann die Gegenfrage gestellt, ja, aber eigentlich
müsste, wieso erzählt ihr nur die Story
und nicht die andere für die andere,
das ist dann das alte Eis, ne,
dann plötzlich haben wir realisiert,
dass wie eine, entsteht
eine Zweiklassengesellschaft,
also der IT, oder, da gibt es die coolen,
agilen, die
jungen, die mit Potenzial,
und dann das alte Eisen, die alten,
die sind dann in der anderen
Legacy, die sind im anderen Teil, und da
ist ja klar, die meisten wollen bei den
coolen sein, aber es gibt dann wirklich so,
also auch emotional schlechte,
und die Firma hat sich dann tatsächlich
auch entfernt vom Bimodalen
Gedanken, die haben dann gesagt,
für uns ist die klassische
Welt langfristig keine Option
mehr, weil sie haben gesagt, und ich finde das auch,
oder man hat, weil DevOps ist,
das geht ums Schnelle, Besser, ich kann auch
in einem Legacy-Umfeld,
kann ich mir Gedanken
machen, wie, wie kann,
wo kann ich ein bisschen automatisieren,
wo kann ich Silos
abbauen, also ich glaube schon,
das ist ja die Aussage im Report auch,
DevOps ist eben
für überall,
also man kann es, es kann überall
nützen, nicht nur ein Teil der IT,
und ich,
ich unterstütze das, ich habe, inzwischen
bin ich mehr Fan, weil Bimodale IT
kommt ja von Gartner,
sie haben es inzwischen, kritisieren sie es ja selber,
sie haben da das neue Modell rausgebracht,
der Pace-Layered Approach,
den finde ich besser, das nimmt auch ein bisschen
die Emotion aus, sie haben einfach gesagt, ja,
das Multispeed-IT, sie haben gesagt,
ja, je nach Bedürfnis
vom Business, auch Änderungsdruck,
muss ich dann halt auch ein bisschen
die Methoden anders anwenden,
also sie sprechen von Systems of Difference,
Differentiation, das ist wirklich die,
diese IT in Business,
also die, die Produkte,
IT-Service, wo ich mich auch im Markt
differenziere, und dort ist das
wirklich die Welt von DevOps und Agile,
dort ist es ganz wichtig,
während andere ist es dann
nicht mehr so, sie sprechen
Systems of
Record,
zum Beispiel ein SAP,
oder ein, gut,
SAP kann auch unterschiedlich aussehen, aber
so die, ich meine nicht so eine Änderung, so, da, da, da, da, da, da, da, da, da, da,
dort ist das dann, ist das dann vielleicht doch nicht
so kritisch. Aber das,
das Modell finde ich dann eine Alternative
zur bimodalen IT,
das ist ja, bimodale IT, das Modell
ist halt ein bisschen schon
spaltet dann, die IT,
finde ich, das Negative.
Wie siehst du das, wie siehst du das?
Ich sehe es auch so, ich sehe es auch kritisch,
versuche ich auch in meinen
Vorträgen rüberzubringen, das eine ist das,
was du sagtest, und was der Klaus Straub hier auch
in seinem Interview gesagt hat,
Zwei-Klassen-Gesellschaft, da haben wir die,
die Leute, die sich alt vorkommen oder langweilig vorkommen, weil sie auf Stabilität achten.
Und wenn ich DevOps richtig verstehe und wenn ich auch die Aussagen aus dem State-of-DevOps-Report nehme,
dann sind das Punkte, die genau diesem Ansatz eben widersprechen.
Ich kann, das haben wir ja vorhin schon ausgeführt, ich kann schnell sein
und ich kann aber auch Stabilität sicherstellen durch mein Vorgehen.
Und insofern, das sind, also für mich sind die Kernaussagen aus dem State-of-DevOps-Report
widersprechend diesem Ansatz bimodaler IT.
Und ich komme ja auch immer mit meiner Metapher, mit der Geschichte vom Hase und dem Igel an der Stelle.
Die meisten werden das kennen, also der Hase, der sich eben über den Igel lustig macht,
über die kurzen Beinchen, dann machen sie ein Wettrennen und der Igel nimmt seine Frau mit dazu.
Und im Prinzip macht er das ganz geschickt.
Der Hase, wenn man die Metapher zu Ende liest, glaubt nach dem 73. Mal fällt der Hase nach dem Wettrennen tot um,
weil er eben wie ein Bekloppter.
Also hirnlos, aber schnell zum Ziel rennt und dort den antrifft, der einfach das Köpfchen eingesetzt hat.
Also für mich ist das eine schöne Metapher, benutze ich immer wieder, wo ich sage,
es ist aus meiner Sicht sinnvoll, das Richtige zu tun.
Und wenn ich das Richtige tue, dann bin ich damit im Prinzip auch schneller,
weil ich mir Nacharbeiten spare, weil ich mir extra Schleifen spare,
weil ich nur das tue, was wirklich benötigt wird.
Und dieses Richtige, das Richtige tun, das ist für mich eben auch Kern,
von DevOps und dann brauche ich keine Nacharbeiten und dann bin ich eben trotzdem schneller.
Das kommt quasi automatisch, wenn ich das Richtige tue, kommt automatisch die Schnelligkeit mit dazu.
Und du hast ja von deinen Kunden gesprochen.
Meine Erfahrung ist auch, in den Scrum Teams, wo ich auch Kontakt zu den Kunden habe,
also zu den Anforderern, die meisten sagen gar nicht, dass die Schnelligkeit für sie der Vorteil ist.
Die sagen, das ist zwar schön, aber die meisten sagen, jetzt habe ich endlich den Kontakt zu den Entwicklern
und ich kann direkt einwirken und ich kriege nicht irgendwann irgendwas vorgesetzt,
sondern ich habe die Chance, mitzuwirken und ich kriege deswegen bessere Software,
ich kriege bessere Ergebnisse und das ist das, was meine Erkenntnis ist aus den Scrum Teams,
die ich, wie gesagt, betreue, wo ich die Rückmeldung bekomme.
Die Kunden sind zufrieden oder zufrieden, weil sie eben das Richtige bekommen
und nicht unbedingt im ersten Schritt, weil sie es schneller bekommen.
Ja, übrigens fand ich eine super Metapher mit der Igel und Hase,
aber ich denke auch, dass dieses Aufgibseln,
auch das Missverständnis der DevOps, es geht auch um schneller, schneller,
aber ich denke, es geht wirklich primär darum, das Richtige zu tun,
weil ich kann ja lang, schneller, schneller und auch Kosten sparen.
Wenn ich zum Beispiel das falsche Geschäftsmodell habe, dann bringt mir das nichts.
Also ich denke auch eben, dass richtige Effektivität und weniger Effizienz.
Gut, natürlich braucht es am Schluss beides, wenn man als Unternehmen florieren will.
Ja, vollkommen richtig.
Also deswegen für mich ist natürlich, die Schnelligkeit kommt,
aber sie kommt quasi als Nebeneffekt.
Und du hast es ja selber gesagt, wenn ich schnell das Falsche mache,
da bin ich eine Zeit lang ganz schön schnell, aber irgendwann bin ich dann gar nicht mehr aktiv,
muss das passende Geschäftsmodell natürlich mit dazukommen.
Ja, hast du noch Punkte, hast du noch wichtige Themen aus dem State-of-Device-Report
oder kommen wir dem Ende näher?
Ja, also wenn man auf die Uhr schaut, ja, wir kommen dem Ende.
Es gäbe schon noch so das eine oder andere Topic,
aber ich denke, wir haben nicht so mal,
wir haben den Großteil abgedeckt und auch aus unserer Sicht jetzt die spannenderen Themen, oder?
Aber ich würde, also ich habe von meiner Seite eigentlich nichts mehr.
Und ich denke auch jetzt angesichts der Zeit sollten wir mal dann Schlusspunkt machen.
Ja, genau, zum Ende kommen, ja.
Was machen wir denn beim nächsten Mal?
Ja, das lassen wir uns mal überraschen.
Also wir haben ein paar Sachen im Köcher.
Wir müssen ja noch finalisieren, wer dann effektiv für ein Intro zur Verfügung stehen wird.
Also wir sind, wir sind agil unterwegs, richtig?
Ja, genau, agil kannst du sagen.
Sorry, ich spreche manchmal ein bisschen lang.
Wir sind agil, genau.
Wir sind agil.
Und heißt ja, wir haben einen Plan, aber den müssen wir eben vielleicht auch kurzfristig anpassen.
Also insofern, wir haben ein paar in der Pipeline.
Unser Product Backlog ist gepflegt, aber noch nicht ready, um es in den Sprint zu ziehen.
Gut, Alex, ja, also ich bedanke mich sozusagen bei dir für die Unterstützung an der Stelle
und würde sagen, das Schlusswort kannst du heute machen.
Mal wieder sprechen.
Ja, also danke auch von meiner Seite, Dirk.
Und ich hoffe, das wird auch für die Zuhörer, dass es für euch interessant ist.
Und ja, ich freue mich dann auf den nächsten Podcast.
Also in diesem Sinn bis zum nächsten Mal und vielen Dank.
Tschüss.
Tschüss.
Tschüss.