Wie passen das Framework zur Skalierung agiler Organisationen SAFe und DevOps zusammen? Ich habe den DevOps Trainer und SAFe Programm Consultant Falko Werner zu Gast im Podcast. Wir sprechen darüber, wie sich DevOps im SAFe wiederfindet, welche Rollen SAFe kennt und wie agil SAFe wirklich ist.

In dieser Episode diskutieren die Gastgeber und der Experte Falko Werner über die Grundlagen und Anwendungen von DevOps und SAFE. Werner definiert DevOps als eine Bewegung zur Optimierung der Lieferung von Kundennutzen und beschreibt SAFE als ein Framework zur Skalierung von Agilität in großen Organisationen. Die Diskussion beinhaltet Details zu verschiedenen Rollen innerhalb des SAFE-Frameworks, die Integration von DevOps-Prinzipien in SAFE, und die Bedeutung von Agilität auf Unternehmensebene. Darüber hinaus werden die Herausforderungen und Vorteile der Anwendung dieser Frameworks in großen Unternehmen sowie die kontinuierliche Entwicklung und Anpassung von SAFE anhand von Marktfeedbacks erörtert.

Inhalt

• Einleitung und Vorstellung von Falko Werner
• Definition und Erklärung von DevOps
• Vorstellung des SAFE-Frameworks
• Integration von DevOps-Prinzipien in SAFE
• Rollen und Struktur im SAFE-Framework
• Agile Methoden und deren Anwendung in großen Unternehmen
• Diskussion über die Entwicklung und Anpassung von SAFE
• Bedeutung von Training und Zertifizierungen im Kontext von SAFE und DevOps
• Diskussion über die Bedeutung und den Nutzen von Frameworks
• Agile Prinzipien und ihre Umsetzung in SAFE
• Abschluss und Ausblick auf zukünftige Themen

Shownotes

Webseite von Falko Werner
Webseite des SAFe Frameworks

Transkript (automatisiert erstellt, daher keine Gewähr 🙂 )

Hallo und herzlich willkommen zum Podcast DevOps auf die Ohren und ins Hirn.
Wir haben heute zu Gast Falko Werner und haben zum Thema Safe und DevOps.
Wie weit reicht die Continuous Delivery Pipeline?
Ja, die, die den Podcast regelmäßig hören, wissen, dass ich eigentlich gar nicht großartig Vorgeplänkel mache,
dass ich gar nicht großartig im Vorfeld etwas sage, sondern gerne zu meinem Gast überlenke.
Also insofern, Falco, ich würde sagen, stell dich einfach mal vor.
Ja, hallo an alle Zuhörer. Ich bin Falco Werner.
Ich bin Scrum Master in verschiedenen Projekten, bin als Trainer im Umfeld von Scrum,
und DevOps und auch Safe neuerdings ziemlich aktiv und freue mich, hier eingeladen zu sein, Dirk.
Sehr schön. Ja, eingeladen als Experte für das Thema Safe.
Safe werden wir gleich noch uns ein bisschen anhören.
Und im Titel haben wir auch drinstehen Safe und DevOps.
Und auch da wieder die Zuhörer, die den Podcast regelmäßig hören, wissen,
die erste Frage an meine Gäste ist immer,
wie definierst du DevOps? Falco, wie würdest du DevOps beschreiben oder definieren?
Ja, das ist natürlich eine interessante Frage, weil so richtig definieren tue ich mich wirklich schwer.
An sich könnte man sagen, DevOps ist Agilität auf Enterprise-Niveau oder Agile 2.0,
wenn wir in der Nomenklatur bleiben.
An sich ist es eine Bewegung zur Optimierung der Lieferung von Kundennutzen.
Letztendlich vom Kunden gedacht, über den gesamten Prozess wieder bis zum Kunden,
zurück von der Anforderung bis zur Lösung.
Und da spielt letztendlich die Business-Seite, Fachbereiche, Architektur, Entwicklung,
Qualitätsmanagement, Security, Privacy, Operations, der Betrieb und letztendlich Kundenservice
alle mit rein, sodass man sagen kann, es ist eine lange Schleife.
Ansonsten so die klassischen Definitionen in Richtung Culture, Agile, Lean, Measuring,
und Sharing mit dem Akronym CALMS ist eine Richtung.
Und ja, wer eine Definition will, kann natürlich gerne auch in der Wikipedia nach SAFE und DevOps schauen.
Da finde ich letztendlich relativ gut beschrieben, so ein Stück DevOps, eine Engineering Culture,
also eine Kultur und Praktiken, die darauf hinarbeiten, sowohl Softwareentwicklung als auch Betrieb zusammenzubringen.
Das ist quasi der erste Schritt.
Und wenn man es im Ganzen betrachtet, halt den gesamten Prozess mit allen Beteiligten so einfach,
so hoch automatisiert zu bekommen, dass man den Kundennutzen möglichst schnell zu der Anforderung entsprechend liefern kann.
Finde ich immer wieder interessant bei diesen Fragen, wie lang dann doch die Ausführungen sind,
also wie viel dann doch rüberkommt und wie viele Erklärungen man dazu braucht.
Also mir geht es ja auch so, es gibt ja nicht einen Satz, wo ich sage,
jetzt DevOps könnte man bringen, aber das ist dann immer ein ziemlich allgemeingültiger,
hochtrabender und dann auch gleichzeitig nichtssagender Satz.
Also insofern hast du ja ein paar Auswahlpunkte gebracht und ich denke,
das Thema Kundennutzen und Wertstrom oder gesamte Lieferkette,
ja, finde ich einfach sehr, sehr interessant, würde ich auch zustimmen.
Gut, jetzt haben wir ja im Thema oder im Titel stehen SAFE und DevOps
und kommen wir dann quasi zu der zweiten Frage.
Was ist denn SAFE?
Also warum haben wir in diesem Podcast SAFE und DevOps als Themen oder als Frameworks aufgeführt?
Was ist SAFE?
Na gut, fangen wir letztendlich mal an.
Also SAFE ist ein Framework für skalierte Agilität, Scaled Agile Framework
und ein E letztendlich im Rahmen des Akronyms, damit es sich sicher anfühlt.
Also für das Management ausreichend viele Artefakte, Erfahrungen, Best Practices,
die dann zusammengeführt worden sind zu einem großen Framework.
Das hat letztendlich Dean Leffingwell im Umfeld von Nokia entwickelt.
Es gab an sich die Frage, wie bekommt man die Gedanken, Erfahrungen, die positiven Ergebnisse,
die man mit agilen Frameworks wie Scrum auf Team-Ebene hat, auf ein Enterprise-Niveau gehoben.
Deswegen auch bei der Antwort auf die Frage, wie definiere ich DevOps, Agilität auf Enterprise-Niveau.
Das heißt, in einem Umfeld, wo es nicht nur ein Team, nicht nur fünf oder zehn Teams gibt,
sondern wo letztendlich Organisationen in Größenordnung von tausenden Leuten
an verschiedenen Projekten, Solutions, Produkten und Services arbeiten,
wie bekommt man die letztendlich so zusammengestellt, zusammenorganisiert,
dass sie die gleichen Effekte, die man auf Team-Ebene mit Scrum erreichen kann,
in solch einer Umgebung auf die Welt loslegen.
Da gibt es letztendlich das Framework, gibt es eine Seite auch im Internet,
die sehr viel Hintergrundinformationen dazu gibt, scaledagile.com.
Und da gibt es dann halt verschiedene Beschreibungen für Rollen, für Zusammenarbeitskonstrukte
wie einen agilen Release Train, den man wieder zusammenfasst zu verschiedenen agilen Solution Trains,
die dann halt in einem Portfolio.
Also in einem Lean-Portfolio gemeinsam an den Kundenlösungen arbeiten.
Okay. Jetzt hast du eben gesagt, im Umfeld von Nokia ist das entwickelt worden.
Jetzt könnte man, wenn man ja böse wäre, sagen, das kann es ja nichts gewesen sein,
weil Nokia gibt es ja nicht mehr in der Form.
Das ist ein naheliegender Gedanke, aber grundsätzlich ist auch da viel gelernt worden.
Und das Gelernte dann halt übertragen, angepasst, erweitert.
Und SAFE ist ein Framework, was sehr viel auch Interaktion mit den Anwendern betreibt,
sehr viel Feedback auch aufnimmt und regelmäßig Veränderungen vornimmt.
Und die Dinge, die aus dem Nokia-Umfeld gelernt worden sind,
die Dinge, die aus vielen anderen Konzernumfeldern gelernt worden sind,
sind natürlich dann auch in das Framework eingeflossen.
Jetzt kann man das natürlich negativ sagen.
Okay, SAFE und Nokia und lass das sein.
Andererseits ist es halt ein sehr weit verbreitetes.
Es ist ein Framework am Markt mit ca. 30% Marktanteil an agilen Skalierungsframeworks.
Ist das größte von denen.
Es gibt halt verschiedene andere, aber ich glaube, da kommen wir später noch drauf zu sprechen.
Und ist jetzt in der Version 4.6 aktuell quasi als Framework nutzbar.
Im Laufe des Jahres wird man die nächste Versionsstufe angehen.
Version 5.0, eine Komplettüberarbeitung.
Und auch da werden wieder viele neue Dinge,
die aus den ganzen Unternehmen, die das anwenden, wieder zurückgetragen werden, eingearbeitet.
Und aus dem Grund sehe ich es als relevant.
Einerseits, weil es am Markt relevant ist.
Und andererseits, weil halt viel Gelerntes auch quasi in das Framework eingeflossen ist.
Jetzt hast du gesagt, das ist Skalierung oder Skalieren von Scrum.
Wenn ich das so richtig weiß, dann ist gerade in der Version 4.6
sehr viel mehr auch in Richtung Lean und Kann-Man passiert.
Genau.
Also wie viel Scrum steckt drin, wie viel Kann-Man steckt drin
und wie viele andere Dinge stecken da drin aus dem agilen Umfeld?
Ja, letztendlich alles Gute steckt da drin, kann man jetzt so sagen.
Ist vielleicht ein bisschen flach und einfach geantwortet.
Generell ist es so, dass auf der Team-Ebene für gewöhnlich den Teams freie Hand gelassen wird,
in welchem agilen Framework sie sich am wohlsten fühlen,
was mit ihren Arbeitsweisen am besten übereinstimmt.
Aber…
Aber üblicherweise geht man davon aus, dass man Scrum auf der Team-Ebene einsetzt.
Wenn das nicht der Fall ist, dann halt auch gerne Extreme Programming, XP oder ein Kann-Man.
Wobei Scrum ist ja auch nur eine Form von Kann-Man.
Insofern gibt es da viele Freiheiten.
Und wie man dann diese Teams mit anderen Teams zusammenbringt,
da setzt letztendlich erst das SAVE-Framework an,
wie man die Skalierung auf die Beine stellt.
Jawohl.
Das heißt, SAVE lässt den…
Die Teams freie Hand, weitgehend freie Hand.
Klar, es muss ja wahrscheinlich ein paar Vorgaben geben,
aber an sich lässt es ihnen freie Hand.
Und die Teams entscheiden dann selber, wie sie arbeiten.
Aber die Prinzipien, die Ideen von Agilität, die werden eben auf Enterprise-Niveau angehoben.
Genau.
Okay, ja, jetzt haben wir die beiden Titelgeber, die beiden Namensgeber für den Titel erklärt.
Du hast DevOps definiert, du hast SAVE im Groben zumindest mal erklärt.
Wie hängen denn die beiden zusammen?
Die müssen ja zusammenhängen, sonst hätten wir ja diesen Titel ja nicht gewählt.
Ja, können wir gerne so sehen.
Letztendlich ist SAVE als Skalierungs-Framework offen für viele Einflüsse.
Und ein Einfluss kommt aus dem DevOps-Umfeld.
Und letztendlich ist eines von den Zielen im SAVE-Umfeld,
Produkte auf den Markt zu bringen, sie releasefähig zu bekommen.
Und man geht davon aus, dass man üblicherweise das nicht auf dem Team-Level schafft,
also in einer Größenordnung von sieben Team-Mitgliedern,
plus minus zwei Produkte auf Enterprise-Niveau auf die Straße zu bringen,
dass man da mehrere zusammenarbeiten lässt und dann auf der Ebene drüber sagt,
da liegen die Produkte.
Und die Produkte sollen halt releasefähig sein,
sie sollen schnell anpassbar und erweiterbar sein.
Und da nutzt man letztendlich die Einflüsse, die man aus den Erfahrungen von DevOps hat,
sowohl das Zusammenbringen von Team-Mitgliedern,
mit einem größeren Fokus auf Entwicklung,
andere Team-Mitglieder mit größerem Fokus auf Betrieb,
vielleicht auch einige aus dem Bereich Security oder Datenschutz oder ähnliches,
Architekten und Fachbereiche,
und bringt diese in einem Art von Release-Train,
Agile Release-Train oder Solution-Train entsprechend zusammen, um dann Produkte zu bringen.
Das heißt, in diesem SAVE-Framework gibt es ein großes Big Picture,
also ein großes Diagramm, wo man versucht, alle Ebenen so ein Stück darzustellen.
Und da platziert man DevOps als eine Kernfähigkeit auf der Produktebene
an der Grenze zwischen der Team-Ebene und dem Portfolio.
Du hast eben gesagt, dass SAVE sehr stark davon lebt,
dass es auch die Erfahrungen aus dem Markt zurückbekommt und einarbeitet.
Das heißt, auch das wäre jetzt ein Beispiel dafür,
dass die DevOps-Erfahrungen aus dem Markt dann sich in SAVE-Train quasi wiederfinden,
also entsprechend eingearbeitet werden.
Ist das richtig?
So kann man das sehen.
Letztendlich gibt es dann auch so ein Stück Umdeutung oder Erfahrungen,
die man halt in Projekten gemacht hat, die man versucht, in das Framework einzubringen.
So ähnlich, wie ich es vorhin am Rande der Definition von DevOps gesagt habe,
dass man so ein Akronym CAMS, Culture, Agile Lean, Measuring und Sharing hat,
sagt SAVE, wir haben so viel Sharing, wir brauchen das nicht speziell in diesem Akronym für uns.
Wir nehmen letztendlich so ein Element Recovery,
machen statt CAMS, CALMER.
Es gibt letztendlich auch Schulungen, die das SAVE-Framework mitbringt
oder die man im Rahmen des SAVE-Frameworks betreiben, erweitern und nutzen kann.
Da gibt es zum Beispiel auch eine Zwei-Tages-Workshop zum Value-Stream-Analyse,
Value-Stream-Mapping, einen Health-Check, einen DevOps-bezogenen Health-Check
auf so einen Agile-Release-Train, also eine Zusammenfassung von mehreren Teams,
wie diese zusammenarbeiten, wie man gemeinsam releasen kann.
Das sind letztendlich alles Dinge, die dort mit reinfließen, die auch so einen Austausch ermöglichen.
Du hast jetzt ja eben verschiedene Angebote angesprochen.
Wie muss ich mir das vorstellen?
Also wenn ich jetzt mal auf die Frameworks schaue, die ich so kenne,
in der alten Version, das waren 2000 Seiten, das waren fünf Bücher.
Ich kenne Scrum, das sind 17 Seiten Scrum Guide, quasi von der Quelle her.
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich das machen?
Wie muss ich mir vorstellen, wie ist SAFE beschrieben?
Wie komme ich als Kunde an das SAFE-Wissen?
Der erste Ansatz ist, auf der einen Webseite, wenn wir jetzt auf Zahlen gehen,
scaledagile.com, sich diese Beschreibung des Frameworks näher anzuschauen.
Da gibt es letztendlich sehr viel auch Informationen dazu, die man sich durchlesen kann,
die man versuchen kann, auf sein Unternehmen zu übertragen.
Man kann den nächsten Schritt gehen und sagen, man lässt sich,
entweder öffentlich oder halt auch in Firmen, entsprechend schulen.
Da gibt es Trainer am Markt, die das anbieten.
Man kann da mit verschiedenen Trainingsorganisationen zusammenarbeiten.
Man kann selbst zum Trainer werden, indem man eine Schulung zu dem Framework
als SAFE-Programm-Consultant zum Beispiel macht, um befähigt zu werden,
um die verschiedenen Bereiche, wie zum Beispiel,
den gerade erwähnten Zwei-Tages-DevOps-Schulungs-Workshop,
den Architektur-Training, ein Team-Training, SAFE for Teams gibt es zum Beispiel,
die letztendlich alle in verschiedenen Unternehmen mit anbieten
und dann auch als offene Trainings alternativ am Markt anzubieten,
um das SAFE-Wissen dann auch zu verteilen und zu verbreiten.
Das sind so die Ansätze, die relevant sind.
Es gibt natürlich auch…
Bücher von den SAFE-Erfindern, sage ich jetzt mal,
oder SAFE-Wissenszusammenträgern, sind verschiedene Ansätze,
die man da wählen kann am Markt.
Aber das heißt im Prinzip, es gibt Trainings, es ist ein umfangreiches Schulungsangebot.
Ich kann mich auf der Webseite informieren.
Das ist das, wie ich an die originäre Literatur von SAFE komme.
Natürlich gibt es Bücher und andere Themen,
aber originär quasi Schulungen und das, was auf der Webseite steht.
So habe ich es.
Das habe ich bis jetzt verstanden.
Wir haben ja das Thema, so wie du es jetzt dargestellt hast,
oder ist ja aus meiner Sicht DevOps quasi ein Teil von SAFE.
Wenn ich mir das so bildlich vorstelle, da gibt es irgendwo DevOps-Teams,
oder da steht DevOps ja quasi etwas über der Team-Ebene.
Gibt es denn irgendetwas oder irgendjemanden,
der in SAFE dann quasi für DevOps zuständig ist?
Gibt es irgendeine DevOps-Rolle, eine spezielle oder mehrere DevOps-Rollen?
Wie vorhin in der Definition gesagt, ist ja DevOps keine…
Also ich habe es zumindest nie als Rolle verstanden.
Es gibt auch Organisationen, Trainings, die DevOps als Rolle verstehen,
dann aber mehr mit dem Fokus rein Automatisierung.
Bei SAFE ist es nicht so.
SAFE ist letztendlich als Framework bezogen auf DevOps mit dem Blick unterwegs,
zu sagen, das ist die Optimierung des gesamten Lieferprozesses
und bezieht halt nicht nur die initiale Stufe Entwicklung und Betrieb,
zusammenzubringen, sondern halt alle an dem Lieferprozess Beteiligten
zusammenzubringen mit einem.
Gibt es denn in SAFE auch bestimmte Rollen, also DevOps-Rollen,
wo ich wirklich konkret einer Person oder einer Rolle Aufgaben zuschreibe
in diesem SAFE-Framework?
Weil mein Verständnis ist ja immer noch, dass ich DevOps als einen Teil darin habe
und meistens gibt es ja in solchen Frameworks immer irgendwelche Rollen
und irgendwelche Verantwortlichkeiten.
DevOps hat viele Rollen.
Viele haben letztendlich einen Einfluss oder einen Bezug zu DevOps.
An sich ist der DevOps-Gedanke in allen Teams beheimatet.
Das heißt, die Teams sollten fähig sein, ihre Artefakte zu liefern,
ihre Artefakte automatisiert zu liefern, automatisiert testen zu lassen.
Um das zu unterstützen, sind die Architekten,
also in dem Fall auf der ersten Ebene über dem Team,
ist der Systemarchitekt, darüber dann Solution- oder Enterprise-Architects,
die letztendlich das Ganze mit unterstützen.
Gegebenenfalls auch in der Zusammenarbeit
auf einer eher operativen, wissensaustauschbezogenen Ebene.
Da werden in SAFE oft Communities of Practice eingesetzt,
um so einen Austausch zu ermöglichen.
Und auch so ein Release-Train-Engineer ist letztendlich mit in der Verantwortung,
mit den Teams zusammen dorthin zu arbeiten.
Das ist ein guter Fluss.
Durch alle beteiligten Teams, alle Beteiligten gibt
noch ein SAFE-Programm-Consultant ist letztendlich dort in dem Bereich mit aktiv.
Das heißt, ich habe Systemarchitekten, ich habe Solution-Architekten
und diesen Release-Train-Engineer, die quasi als Rolle über den Teams stehen
oder mit den Teams gemeinsam etwas zu tun haben,
aber die dann auch das Thema DevOps und das Thema Skalierung
verantworten und unterstützen.
Ja, mehr unterstützen, verantworten.
Schon auf der Team-Ebene.
Okay, also die Verantwortung bleibt bei den Teams, sie unterstützen entsprechend.
Jetzt haben wir ja schon über das Thema DevOps gesprochen
und du hast ja auch in deiner Definition oder in den verschiedenen Definitionen auch angeführt,
dass es sehr umfangreich sein kann.
Mein Verständnis von DevOps ist ja, dass ich da ein bisschen Scrum habe,
ein bisschen Kanban, ein bisschen ITIL, vielleicht auch ein bisschen COVID mit reinpacke.
Also das finde ich das Smarte an DevOps, also an meinem Verständnisverhältnis.
Von DevOps, dass ich einfach die verschiedenen Frameworks, die es dort gibt,
bestmöglich für mich zusammenbaue.
Wie ist das in SAFe?
In SAFe ist es so, dass man DevOps als Element sieht,
das für eine Enterprise-Agilität hilft, einen durchgängigen Fluss zu generieren,
einen durchgängigen Fluss von der Anforderung bis zur Lösung für den Kunden.
Und SAFe ist da letztendlich im Bereich,
eine zweite Skalierung im Framework, das ähnlich verwendet werden kann wie LESS.
Ja, die klassischen großen Skalierungsframeworks, weniger verbreiteter Markt,
sind dann auf Scrum.org basierend Nexus oder ursprünglich aus dem IBM-Umfeld stammend,
aber mittlerweile als Eigenständeorganisation am Markt tätig.
Disciplined Agile, Disciplined Agile Delivery als Kern.
Mit auch einem relativ umfangreichen Framework.
Und auch im SAFe-Umfeld bedient man sich halt verschiedenen anderen Themen,
zum Beispiel DevOps.
Unterstützend würde aus der Architektur zum Beispiel so ein Framework wie TOGAF,
im Compliance-Umfeld COBIT, bei den Prozessen FITSM,
so dein Steckenpferd oder auch ITIL.
Und ansonsten im Technologie-Umfeld natürlich von den Herstellern verschiedene,
Frameworks, Prozesse, Schulungen, Ausbildungen im AWS-Umfeld bei Azure oder von der Google Cloud
oder allgemeiner, so ein bisschen herstellerunabhängig mit Cloud Council,
die letztendlich auch mit anbieterunabhängigen Technologieschulungen am Markt sind.
Wenn man das alles zusammenfasst, hat man natürlich ein Riesenportfolio.
Da kann man sich auch ein Stück drin verlieren, aber es ist auf jeden Fall viel Wissen vorhanden.
Die Frage wäre natürlich dann in die Richtung, wie bekommt man,
da einen Überblick oder wie schafft man es, in diesem Wust genau das zu finden, was man braucht.
Das wäre jetzt auch meine nächste Frage gewesen.
Wenn wir erstmal auf SAFE gucken, schafft SAFE schon das Zusammenführen
dieser verschiedenen Ansätze und Frameworks?
Also hat SAFE das überhaupt als Ziel für sich formuliert?
Also soweit es mir bekannt ist, ist das Ziel von SAFE, sich auf die Skalierung zu fokussieren,
Unternehmen soweit zu befähigen.
Und zu unterstützen, dass sie eine Chance haben, in einem Umfeld,
das halt viele Teams, vielleicht viele Teams von Teams,
kundenfokussiert, lösungsorientiert arbeiten zu lassen.
Das heißt, an sich ist dann SAFE nur eins von vielen Frameworks auf der Skalierungsebene.
Und die anderen Bereiche, die ich gerade erwähnt habe, haben halt auch eine Einwirkung darauf.
Aber SAFE führt jetzt nicht alle Themen zusammen.
Zusammen, auch wenn es sich aus vielen Bereichen wie DevOps, wie Scrum, wie Compliance bedient.
Okay, das heißt also, wenn ich da einen Überblick bekommen will,
gibt es in dem DevOps-Umfeld einen Ansatz, um das zusammenzubringen.
Weil da habe ich auch gesagt, das ist ja für mich der gleiche Ansatz.
Also wo habe ich eine Chance, überhaupt einen Überblick zu bekommen?
Wie arbeiten die einzelnen Systeme zusammen, die einzelnen Frameworks?
Wo hängen sie zusammen? Wo überschneiden sie sich?
Also gibt es da noch einen Ansatz dazu?
Also einen interessanten Ansatz, den die DevOps Agile Skills Association gerade entwickelt
oder versucht auch zu platzieren, ist basierend auf dem DASA-Kompetenzmodell
verschiedene Schulungen von verschiedensten Anbietern, Framework-Anbietern,
Technologie-Anbietern, Schulungs-Anbietern, Prozess-Anbietern in ein Modell zu bringen,
zu bekommen, nennt sich dann DevOps Skills Map.
Das ist ein Trademark.
Und da werden gerade, ja, zumindest schon eine Zeit lang am Markt
verfügbare mit Zertifizierung hinterlegte Schulungen gegenübergestellt.
Und anhand dieses Kompetenz-Frameworks mit vier Soft- und acht Hard-Skills,
die für DevOps relevant sind, entsprechend bewertet auf einer Skala von 1 bis 5,
wie weit diese jeweilige Schulung aus dem einen oder anderen Framework
entsprechend des Kompetenz-Frameworks der DASA Wissen liefern.
Das heißt also, da gibt es ein paar Links, die packe ich dann in die Shownotes,
dass man da nochmal nachlesen kann und das ein bisschen verfolgen kann.
Und du hast es, glaube ich, gesagt, bei dieser Initiative der DASA bist du auch mit dabei,
also dass du dort mit zusammenträgst.
Genau. Also ich habe mich jetzt ein Stück auf die Save,
auf Rollen und Save-Trainings sowie auf die Scrum.org-Trainings und Zertifizierungen,
die es dort gibt, gestürzt.
Es gibt dann verschiedene andere Unternehmen und Beteiligte,
die sich dann auf zum Beispiel Technologien oder andere Prozesse,
zum Beispiel ITIL oder andere Skalierungs-Frameworks wie LESS oder Nexus dann
und ihren Schulungen, die es dort gibt, entsprechend fokussieren.
Um dann mal einen großen Überblick über den Schulungsmarkt,
der in irgendeiner Form Relevanz oder Bezug zu DevOps hat, zu bekommen.
Also ich finde es sehr interessant und deswegen unterstütze ich auch diese Initiative.
Insofern ist da da ein bisschen Leben drin und dann kann ja der Link in den Shownotes
sich quasi auch entwickeln oder das, was hinter dem Link dann entsprechend steckt.
Genau. Das ist jetzt die ersten, glaube ich, zehn Schulungen auf der DevOps-Seite,
auf der DevOps-Webseite entsprechend veröffentlicht werden sollen.
Ich weiß nicht genau, wann das der Fall sein wird.
Wir arbeiten gerade in der Größenordnung von 100 bis 200 Schulungen.
Also da kommt noch eine ganze Menge nach.
Ich kenne das. Ich habe das im anderen Umfeld auch mal getan,
dass wir auch versucht haben, so etwas zusammenzubringen, zu vergleichen,
eine Übersicht zu erstellen.
Das ist schon eine Menge Arbeit, weil man ja nicht einfach nur irgendwelche Überschriften nehmen kann.
Also da muss man ja schon ein bisschen genauer reinschauen.
Also ja, viel Spaß weiterhin.
Ich bin gespannt, was dabei dann auch rauskommt.
Jetzt hast du ja wirklich viele Frameworks aufgezählt.
Ihr bringt die zusammen. Ihr macht einen Überblick dazu.
Jetzt könnte man ja, wenn man nur böse wäre, sagen, es gibt viel zu viele Frameworks.
Oder wie ich es sage, es gibt genug Frameworks. Wir müssen sie nur anwenden.
Also vielleicht können wir nochmal ein bisschen über das Thema,
den Nutzen von Frameworks sprechen.
Aus deiner Sicht, aus meiner Sicht.
Was bringen denn?
Was bringen diese Frameworks überhaupt?
Aus meiner Sicht entwickeln sich Frameworks aus guten Erfahrungen, die man gemacht hat.
Wenn man sie in verschiedenen Bereichen anwendet, werden sie reifer.
Man kann letztendlich aus den Themen, die so ein Framework mitbringt,
für sich selbst etwas lernen.
Man kann Ideen bekommen, die vielleicht andere schon in die Tat umgesetzt haben,
die ihnen was gebracht haben.
Man kann sich da letztendlich von bedienen.
Sie bringen oft Ressourcen.
Also Erfahrungen, Dokumente, Best Practices, Erfahrungsberichte von anderen Unternehmen,
die es eingesetzt haben, und eine Form von Verständnis mit.
Sie bieten dann darüber hinaus eine Plattform zum Erfahrungsaustausch.
Also bei vielen Frameworks, die weitläufig im Einsatz sind, auf Team-Ebene Scrum,
auf Enterprise-Ebene, DevOps oder Save oder Less, haben letztendlich auch Communities,
die dort da sind, um voneinander zu lernen, miteinander zu lernen.
Es gibt zum Teil weltweite Konferenzen oder regionale Konferenzen zum Austausch.
Und dieses Miteinander und Voneinanderlernen, das sind Dinge, die man vielleicht ohne die Frameworks
so in der Form auf klassischen Konferenzen vielleicht so gar nicht erleben würde
oder gar nicht mitbekommen würde.
Das sind für mich letztendlich die Dinge, die so ein Framework im Großen mitbringen.
Eine Plattform, auf der ich auch ganz gern unterwegs bin, ist die von Michael Cohn eingerichtete
Agile Mentors Community.
Das ist ein amerikanisches Projekt, um Scrum Master zum Beispiel zusammenzubringen
mit Product Ownern und Erfahrungen auszutauschen zu verschiedenen Themen.
Da gibt es zum Beispiel auch einen Buchclub, wo einmal im Monat ein Buch gemeinsam gelesen
und vorgestellt wird.
Dann gibt es oft eine Videokonferenz am Ende des Monats.
Mit dem Autor, man kann den Autor mal persönlich kennenlernen, man kann auch mal eine Frage
zu dem Buch stellen.
Das sind alles Themen, die im Rahmen von so Frameworks entstehen und sich entwickeln
und wirklich interessant sind.
Da, wo Menschen zusammenarbeiten, teamübergreifend, unternehmensübergreifend, macht halt auch
so eine Motivation aus, bringt auch Spaß, bringt Drive-In auch in Unternehmen von außen rein,
dass man an sich…
Erstmal mit dem Framework selbst, vielleicht gar nicht erreicht hätte, aber mit dem Austausch,
mit den Erfahrungen, mit dem Miteinander, seine gelernten Themen mit anderen Unternehmen,
unternehmensübergreifend zu verbreiten, ist natürlich fast, wenn man sich jetzt mal an
Gene Kims drei Wege erinnert, fast sowas wie ein vierter Weg, nachdem man halt so das
ersten Weg Flow im Unternehmen, zweiten Weg Feedback schleifen, aufbauen, dritten Weg
Unternehmensintern.
Ja, unternehmensintern voneinander zu lernen, zum Beispiel übergreifend über Teams oder
übergreifend über Abteilungen oder Bereiche, jetzt als vierten Schritt quasi das Ganze
über die Unternehmensgrenze hinaus zu treiben und unternehmensübergreifend zu lernen.
Das ist für mich so ein nächster Effekt, den man letztendlich mit Frameworks wie Safe
oder Less oder Scrum oder DevOps halt wirklich in die Welt bringt.
Die man erleben kann.
Ja, du hast es ja gesagt, das könnte man ja auch machen, wenn man das ohne solche Frameworks
macht.
Meine Erfahrung ist aber dann, es hilft immer, wenn man jemanden dabei hat, der das Ganze
organisiert, der das antreibt, der quasi schon ein Eigeninteresse daran hat, dass das stattfindet
und von daher auch ein bisschen startet und mit unterstützt an der Stelle.
Ja, das hat man halt mit den Frameworks.
Eine klare Zeit man da als Unternehmen so ein Stück auch für, für die Zertifizierung,
für die Trainings.
Und Ähnliches.
Aber man kommt auch eine ganze Menge zurück.
Okay, Falko, jetzt haben wir ein bisschen über die Frameworks gesprochen, über Vorteile,
über Safe und über DevOps, was in Safe drin steckt.
Jetzt kommt noch ein Punkt, den ich immer mal wieder höre und dann gibt es Leute, die
sagen, dieses A in dem Scaled Agile Framework, dieses Agile, das ist falsch da.
Also das ist gar nicht agil.
Was denkst du denn darüber?
Wie agil ist denn Safe?
Ja, Safe ist letztendlich ein relativ detailliertes Framework, das ziemlich viele Vorgaben macht.
Zum Beispiel, wie man ein Portfolio aufbaut, wie man Teams in agilen Release Trains, wie
Safe das nennt, zusammenfasst, wie man diese agilen Release Trains in Solution Trains zusammenfasst.
Es hat ein relativ enges Framework, was Zeiten angeht.
Sowas wie teamübergreifende,
Iterationen, eine Kadenz mit, auch vorgeschlagen, zwei Wochen im besten Fall, vielleicht auch
drei Wochen, sodass man in diesem Rhythmus gemeinsam getaktet arbeitet, ist halt sehr
preskriptiv.
Ist aber ein guter Ansatz, um überhaupt in das agile Leben, Denken und Planen reinzukommen.
Es gibt im Safe-Umfeld ein Programmingrement Planung.
Das ist eine Big Room Plan.
Planning-Veranstaltung, eine üblicherweise Zwei-Tages-Veranstaltung, wo ein ganz agiler
Release Train, also irgendwo so in der Größenordnung 50 bis 120, 130 Teammitglieder in einem großen
Raum, vielleicht auch mit Räumen drumherum, um mal ein bisschen Ruhe zu haben und Themen
an der Seite zu diskutieren, aber in einem großen Raum zusammenkommen, an zwei, zweieinhalb
Tagen, wo sie dann einen Zeitraum von vier,
fünf, sechs Sprints gemeinsam planen.
Und das ist natürlich ein Zeitraum, den man dann entsprechend überdenken muss, wo dann
die Reaktion, was das Agile ja ausmacht, auf den Markt reagieren können, eingeschränkt
ist.
Und je nachdem, wie viel Details man dort schon plant, umso weniger Zeit und Fähigkeit
auf Veränderungen am Markt zu reagieren, hat man natürlich.
Das heißt, man plant auch bis zu einem Vierteljahr.
Das ist jetzt nicht so weit weg von einem Wasserfall, auch wenn da Projekte eher so
in drei Jahre geplant werden und dann Releases so halbjährlich laufen.
Und SAFE hat im Gegenzug gesagt, man sollte halt schon innerhalb so einem Programm-Inkrement,
also so einem Vierteljahr, nicht nur einmal releasen, sondern halt mehrfach.
Aber vielleicht kann die Organisation das zu dem Zeitpunkt noch nicht und man lernt es
und geht in die Richtung.
Deswegen ist das Agile in SAFE eher…
Ja, das Ziel als der Startpunkt.
Und SAFE an sich mag auch nicht der Endpunkt von so einer agilen Transition sein, sondern
kann halt auch als Zwischenschritt verstanden werden und sagen, okay, wir bedienen uns dem
Framework, wir versuchen, in das Laufen zu kommen, wir versuchen, eine Organisation
von mehreren hundert oder mehreren tausend Mitarbeitern zu bewegen.
Das sind ja oft Tanker, die man letztendlich versuchen muss, in irgendeiner Form einen
zum Halten, zum Drehen, zum Wenden, zum Agieren zu bekommen.
Und das ist natürlich ein guter Anfang, mit SAFE zu starten.
Ja, okay.
Wenn ich noch mal meine Sicht auf Agile auch nehme, ich glaube, dass manche Leute Agile
eben genau als interpretieren, ich kann machen, was ich will.
Das manche ist auch gar nicht ironisch oder irgendwie despektierlich.
Also Agile wird ja…
Ich kann es an vielen Stellen, wie ich es auch immer erlebe, als eine etwas so, ja, ich
mache mal so, ich gucke mal, ich schaue mal, interpretiert.
Und wenn ich Scrum nehme als das agile Framework, was die meisten wahrscheinlich kennen, würde
ich auch sagen, da gibt es genug Regeln.
Also Scrum an sich hat ja auch schon sehr viele Regeln und ist ja auch das Ziel von
Scrum, durch Regeln, durch Sätzen von Leitplanken, die natürlich ein bisschen breiter sind,
aber trotzdem mit Leitplanken.
Also das Ziel ist schon, flexibel zu sein, anpassungsfähig zu sein, aber das kriege ich
ja eben nicht hin, indem ich einfach sage, macht, was ihr wollt, sondern indem ich mit
Regeln arbeite und immer da, wo Menschen zusammenarbeiten, wo Menschen voneinander
etwas erwarten, brauche ich Regeln, um eben aufzuschreiben, was kannst du von mir erwarten,
was bin ich denn bereit oder fähig zu liefern.
Also das Thema, was ist agil, darüber gehört wahrscheinlich auch stundenlang in so einem
Podcast reden und wenn ich dich richtig verstanden habe, würdest du auch sagen, dass
dieses A zu Recht in dem Safe drinsteht, in der Abkürzung drinsteht und dass man das
eben, dass agil eben nicht heißt, ich habe keine Regeln, ich habe keine Planung an der
Stelle.
Also ich stimme dir zu, dass agil nicht heißt, man hat keine Planung und keine Regeln.
Man will letztendlich reaktionsfähig sein auf Veränderungen am Markt, man will letztendlich
auch in einem großen…
In einem großen Unternehmen, in einem Konzern auf dem Markt noch reagieren können und man
versucht das letztendlich mit einem Satz von Regeln und aufbauend auf bestehenden Best
Practices und insofern ist das A von Agile in der Abkürzung von Safe, Scaled Agile Framework
halt schon da, aber man braucht natürlich auch da die Menschen, die das Ganze umsetzen.
Man muss letztendlich ein gemeinsames Verständnis für das Produkt, für die Ziele, für den
Markt auch auf hunderte oder tausende Mitarbeiter entsprechend bekommen und da hilft letztendlich
so ein Framework, die Zusammenarbeit zu organisieren, eine gemeinsame Sprache auch zu haben, ein
gemeinsames Miteinander, das sich in vielen anderen Bereichen halt als mit guten Erfahrungen
gut übertragbar bereits gezeigt hat.
Und es sagt ja auch keiner, dass selbst wenn man in so einem Programm-Inkrement in Safe
über ein Vierteljahr plant, dass man so eine Planung dann entgegen dem agilen Manifest halt
von Anfang bis Ende 1 zu 1 umsetzen muss, sondern dass man auch da sagt, plan vielleicht
zu Anfang dieses Programm-Inkrements keine 100% Kapazitätsauslastung ein, lasse dir
Zeit, um auch Veränderungen zu ermöglichen, um eine Planung auch anzupassen, nimm dir die
jeden Sprint, jedes Inkrement sagt Safe und überlege dir, ob der Plan, den du für dieses
Inkrement oder für den restlichen Teil des Programm-Inkrements gemacht hast, ob der noch
aktuell ist, ob der relevant ist und auch das hat man im klassischen Projektmanagement,
da macht man halt auch nicht den Plan am Anfang des Projekts und am Ende nach einem definierten
Zeitraum von zwei Jahren hat man genau das geliefert, was man geplant hat, auch da ist
es ja die schönen Gantt-Diagramme, die man so gezeigt hat.
Ein guter Projektmanager aktualisiert die jeden Tag, jede Woche, zumindest sehr häufig
und genau so geht man letztendlich auch in dem Umfeld Safe und sagt, mache dir einen
Plan, überlege, wo du hinkommen willst, aber lasse dir auch die Möglichkeit, darauf zu
reagieren.
Eine Erfahrung, die wir gemacht haben, wir planen jetzt zum Beispiel bei den meisten
unserer Teams halt eher in der Größenordnung 70% unserer Kapazität im Rahmen des Safe-Programm-Inkrements
ein.
Und die restlichen 30% nehmen wir uns halt Zeit, um auf Veränderungen zu reagieren,
um auf Dinge, die wir während des Programm-Inkrements gelernt haben, halt dann auch umzusetzen
in Veränderungen im Plan und das macht das letztendlich möglich.
Ein weiterer Aspekt, den Safe mitbringt, so ein Programm-Inkrement besteht nicht nur
aus inhaltlichen Umsetzungen, also fachlichen Anforderungen, die umgesetzt werden, also
Features, sondern halt auch am Ende dieses Programm-Inkrements.
Das ist ein Programm-Inkrement mit einem Innovations- und Planungssprint.
In diesem Sprint ist vorgesehen, dass man sich Zeit nimmt für Themen wie Hackathons, für
Themen wie Erfahrungsaustausch, Schulungen, Trainings, in dem man aber auch sich Zeit
nimmt, die Dinge, die vielleicht nicht ganz nach Plan gelaufen sind, fertig zu bekommen
und andererseits natürlich auch für das nächste Programm-Inkrement zu planen.
Und so einen zwei Wochen Zeitraum, den man letztendlich hat, den man sich regelmäßig
auch nimmt.
Den bringen wenig andere Frameworks mit.
Ja, das stimmt.
Das würde ich auch so sehen.
Und wenn ich mal überlege, es ist ja auch so, das ist für mich ja auch ein wichtiger
Punkt, agil kann ja nicht das Ziel sein.
Also ich bin agil und arbeite toll nach agilen Prinzipien.
Das Ganze muss ja dem Kunden einen Wert bringen an der Stelle.
Also insofern würde ich auch mal sagen, unseren Kunden, unserem Business ist es egal, wie
wir arbeiten.
Hauptsache, wir liefern vernünftige Dinge.
Und insofern kann ich damit leben, wenn der eine oder andere sagt, das A in safe ist falsch.
Ich denke, du hast ganz gut dargestellt, dass es eben dann doch seinen Sinn hat und seine
Berechtigung.
Und selbst wenn, Hauptsache, es funktioniert und es kommt was Vernünftiges bei raus.
Genau.
Also das A kann falsch sein, ist letztendlich eine Sichtweise von Personen und mit denen
kann man sich gerne austauschen und man kann auch voneinander lernen.
Und die Gedanken, die dahinterstehen, sind vielleicht nicht allen bekannt.
Die Gedanken sind vielleicht auch in safe so vielleicht nicht von Anfang an enthalten
oder gedacht gewesen und haben sich halt ein Stück mehr entwickelt.
Und so wird sich auch safe in Zukunft weiterentwickeln.
So wird sich DevOps weiterentwickeln und viele andere Frameworks, die eingesetzt werden, auch.
Das Einzige, was sich selten weiterentwickelt, sind Frameworks, die nicht eingesetzt werden.
Das stimmt.
Die werden dann vielleicht irgendwo weiterentwickelt im stillen Kämmerlein, aber sicherlich nicht
für die breite Maßnahme.
Und das hast du ja auch gesagt, das ist ja ein Vorteil von Frameworks.
Dass man einfach breit zugänglich das Wissen hat an der Stelle.
Gut.
Hattest du noch irgendwas, was du ansprechen würdest, was wir noch nicht diskutiert haben?
Also für mich ist das eine runde Sache aktuell.
Ja, okay.
Gut.
Dann würde ich sagen, herzlichen Dank.
Für mich ist ja immer der Punkt, ich lerne ja bei diesen Podcast-Aufnahmen auch immer
irgendetwas oder nicht nur irgendetwas, sondern etwas.
Und ich denke, wir haben auch ein paar Themen besprochen.
Ich würde sagen, vielen Dank, dass du dir die Zeit genommen hast, darüber ein bisschen
was zu erzählen, was du auch tust mit der DASA an der Stelle.
Und ja, bis demnächst.
Vielen Dank an alle Zuhörer.
Vielen Dank, Dirk, dass du mich eingeladen hast.
Ich höre gerne deinem Podcast zu.
Ich habe bis jetzt alle Folgen gehört.
Sehr viele interessante Themen dabei.
Ich habe auch jedes Mal was gelernt.
Und ich hoffe, es geht so weiter.
Ach, du bist das, der also schon gehört hat.
Okay.
Das weiß ich ja endlich.
Okay.
Nein, Spaß beiseite.
Das ist, ich glaube, ich nähere mich jetzt auch der 25.
Folge und bin mal gespannt, wie das so mit den einzelnen Themen weitergeht.
Ich habe da ein paar interessante Dinge in der Pipeline, die jetzt aufsetzen.
Spotify-Modell werde ich demnächst noch mal ein bisschen intensiver diskutieren.
Ich habe auch jemanden aus dem Lean-Bereich.
Also, wie du auch sagtest, es bringt ja immer den Zuhörern immer ein bisschen was.
Ich lerne auch was dabei.
Also, insofern.
Ja, vielen Dank an der Stelle noch mal.
Und dann bis demnächst.
Bis zum nächsten Mal.

https://podcasters.spotify.com/pod/dashboard/episode/e29ihr7

Das Testen von Software im DevOps Kontext ist das Thema dieser Folge. Ich habe Luca Ingianni zu Gast, Er ist Ingenieur und neben seiner Tätigkeit als Trainer sehr vielseitig in der Praxis aktiv. Wir sprechen über das Testen im DevOps allgemein und die notwendigen Änderungen in Organisation, Selbstverständnis und Umfeld. Daneben klären wir, ob es in Zukunft überhaupt noch Tester geben wird, wie man in der Produktionsumgebung testen kann (oder nicht?) und was Testen in der Zukunft in Zeiten von DevOps ausmacht.

Inhalt

• Einführung in DevOps und Agile Entwicklung
• Die Evolution des Testens in DevOps
• Die Rolle der DASA in der DevOps-Ausbildung und -Zertifizierung
• Hintergrund und Expertise von Luca Ingianni
• DevOps definiert durch Luca Ingianni
• Das Konzept von ‚links und rechts‘ in DevOps
• Qualitätssicherung und kundenorientierte Entwicklung
• Der Übergang von manuellem zu automatisiertem Testen
• Die Bedeutung der Überwachung nach der Bereitstellung
• Die sich wandelnde Rolle von Testern in einer DevOps-Umgebung
• Testgetriebene Entwicklung und ihre Implikationen
• Die Bedeutung von Soft Skills und Kommunikation beim Testen
• Die Auswirkungen von DevOps auf traditionelle Testrollen
• Kosten-Nutzen-Analyse effektiven Testens in DevOps
• Abschließende Gedanken zu Qualitätssicherung und DevOps

Shownotes

Webseite von Luca Ingianni

LinkedIn-Profil

Transkript (automatisiert erstellt, daher keine Gewähr 🙂 )

Hallo und herzlich willkommen zum DevOps-Podcast auf die Ohren und ins Hirn.
Ich habe heute zu Gast Luca Ingianni und wir reden über das Thema Testen im agilen Umfeld,
im DevOps-Umfeld. Freut mich sehr, dass ich jetzt wieder jemanden habe, der so ein bisschen
mehr auf der Technik-Ebene vielleicht unterwegs ist. Das wird sich zeigen. Beim letzten Mal hatten
wir ja Martin Andenmatten dabei zum Thema ITIL 4 und DevOps. Das waren also eher so Übersichten,
was Frameworks und Ansätze angeht. Also heute wird es ein bisschen technischer und Luca Ingianni ist
mit mir gemeinsam im DevOps-Trainer-Team unterwegs. Das heißt, wir sind ja beide als DevOps-Trainer
unterwegs und Luca bietet darüber hinaus auch noch andere Dinge an. Ich denke, das kann er jetzt
am besten selber erzählen. Luca, stell dich doch mal ganz kurz vor. Ja, gerne. Also vielen Dank,
Dirk, für die Einladung. Ich bin tatsächlich mit dem Dirk gemeinsam viel als DevOps-Trainer
unterwegs, aber das ist nicht das Einzige, was ich mache. Ich mache auch Beratung. Ich sage immer,
ich verdiene mein Geld auch manchmal mit ehrlicher Arbeit. Ich mache auch Engineering.
Wichtig ist, Teams dabei zu helfen, ihre Arbeit besser zu machen. Auf technischer Ebene, auf kultureller
Ebene. Ich bin derjenige, der dabei helfen kann, dass die Umsetzung sauber gelingt. Ehrliche Arbeit,
gutes Stichwort. Wenn wir auf die ehrliche Arbeit nachher nochmal eingehen. Wir haben es schon gesagt,
wir sind beide als Trainer in einem Team unterwegs und beziehen uns dabei auf das, was die DASA
bereitstellt an Trainingsunternehmen.
Trainingsunterlagen oder an Syllabus. Kannst du vielleicht da nochmal ein bisschen was zu sagen
zu DASA und wie du bei der DASA arbeitest gerade?
Ja, also die DASA ist die DevOps Agile Skills Association. Das ist eine Gruppierung von Leuten,
die versuchen, DevOps vielleicht zu definieren, die auch versuchen, das über eine Zertifizierung
so ein bisschen zu systematisieren, welche Bereiche es da gibt, welche Fähigkeiten vielleicht jemand
haben könnte.
Und mit denen zusammen, also zum einen bediene ich mich natürlich ihrer Zertifizierungen, auch im Rahmen der
Kurse, die ich gebe. Und zum anderen mache ich gerade in deren Auftrag einen neuen Lehrplan für einen
neuen Kurs, einen neuen Kurs im DevOps-Umfeld über das Thema Spezifikation und Verifikation. Zusammen mit
noch einem dritten aus unserem Trainerteam, dem Falko Werner.
Jetzt haben wir über die DASA gesprochen, über DevOps gesprochen und in meinem Podcast kommt es zu einem
Thema, in dem es sich um die Frage an jeden neuen Teilnehmer handelt. Wie würdest du DevOps definieren?
Naja, du weißt ja, wie es ist. Wenn du zwei Leute fragst, kriegst du fünf Antworten. Nicht mal interessanterweise die deutsche und die englische Wikipedia sind sich einer Meinung, was DevOps wirklich bedeutet.
Aber für mich persönlich bedeutet DevOps eigentlich das konsequente Zu-Ende-Denken von agiler Entwicklung.
Agil, sagen wir mal, in seinem ursprünglichen Ansatz hat sich rein auf die Softwareentwicklung gelegt.
Und das ist aber vielleicht ein bisschen zu kurz gesprungen. Man muss einfach noch weiter nach links schauen und muss weiter nach rechts schauen.
Man muss den Kunden im Fokus haben, man muss aber auch den Betrieb im Fokus haben.
Nur wenn diese gesamte Kette vernünftig greift, dann wird man in der Lage sein, ein wirklich gutes Produkt im Sinne des Kunden rauszubringen.
Das ist für mich DevOps. Agil, konsequent zu Ende gedacht.
Und konsequent zu Ende gedacht, finde ich interessant, nach links und nach rechts, also den Kunden mit dazunehmen.
Den Betrieb mit dazunehmen. Und schlussendlich kommt ja nach dem Betrieb dann auch wieder der Kunde, der ja das auch dann, das Produkt erhält, was wir nicht nur entwickeln, sondern auch betreiben.
Genau, der Kunde ist links und rechts.
Richtig, ja. Am Anfang und am Ende.
Genau.
Jawohl. Gut, okay. Du hast ja eben gesagt, ihr schreibt dieses White Paper für die DASA und das werde ich in den Shownotes auch verlinken, den Hinweis oder die Quelle an der Stelle.
Also insofern, wir werden uns jetzt bei dem Podcast ein bisschen auf dieses White Paper, auf das beziehen, was du dort geschrieben hast mit Falco zusammen.
Vielleicht mal so eine grundsätzliche Einschätzung. Was findet man denn in diesem White Paper?
In dem White Paper oder in diesem Lehrplan, den wir daran angelehnt aufbauen, geht es um genau die Sachen, die links und rechts von der Entwicklung stattfinden.
Das heißt, es geht einerseits um Spezifikation.
Ja, die Wünsche des Kunden entdecken, sprichwörtlich, aufnehmen, systematisieren, dann den Entwicklern zur Verfügung stellen und dann machen die halt ihr Ding und dann hinterher aber auch wieder nachzuprüfen,
habe ich das, was der Kunde gewünscht hat, korrekt umgesetzt? Wünscht der Kunde überhaupt das immer noch oder hat er mittlerweile selber auch dazugelernt?
Das heißt, das ist eben auch ein Bestandteil davon.
Weiter nach links und weiter nach rechts zu schauen, als in Anführungszeichen nur die Entwicklung.
Okay. Insofern ist ja so, wenn ich das so, auch meine Sicht auf das Thema Testen nehme, geht es ja bei Testen eigentlich hauptsächlich um Qualitätssicherung, oder?
Ja, das kann man so sehen. Dann stellt sich natürlich die spannende Frage, was ist denn eigentlich Qualität?
Ja, dann erklär mal.
Ja, ich würde den Spieß gerne umdrehen. Was verstehst du?
Ui, das ist natürlich eine gute Frage. Das ist auch eine gemeine Frage, weil ich wollte von dir die Antwort hören.
Was verstehe ich unter Qualität? Ich muss erst mal nachdenken, wenn ich mir das so durch den Kopf gehen lasse.
Also wichtig ist, glaube ich, erst mal, dass nur der Kunde die Qualität bestimmen kann oder den Anspruch bestimmen kann.
Das heißt, ob ein Produkt oder Dienstleistung qualitätsmäßig gut ist, kann nur der Kunde entscheiden, würde ich jetzt so ad hoc mal sagen.
Und dann gibt es eben Dinge, die ich unterscheiden würde. Qualität im Sinne von, die Anforderungen sind erfüllt.
Also das, was ich damit tun will, funktioniert, kann ich damit machen.
Und technische Qualität, also das, was wir auch mit nicht-funktionalen Anforderungen kennen, sprich Antwortzeitverhalten, Stabilität und so weiter.
Also das wären so meine ersten Antworten in dem Umfeld.
Ja, genau. Also eigentlich ganz stumpf kann man sagen, nützt es mir was?
Dann habe ich ausgerechnet Qualität.
Also stabil ist oder nicht, ist ja wurscht. Hauptsache, vielleicht ist das ja gar nicht schlimm, dass die abstürzt.
Vielleicht stört mich das gar nicht oder vielleicht ist das total blöd.
Insofern, Absturzfreiheit jetzt als Beispiel genommen, ist jetzt nicht zwingend ein Zeichen für schlechte Qualität oder gute Qualität.
Es kommt wirklich darauf an, das, was der Kunde wünscht, kann er das bekommen von dieser Software.
Okay. Wobei ich muss sagen, mit dem Abstürzen, da hätte ich schon einen anderen Anspruch an die Qualität.
Also eine Software, die ich habe, die ich nutze.
Auf die muss ich mich auch verlassen können.
Das gilt bei vielen anderen Produkten auch.
Ich muss sicher gehen, dass das Auto weiterfährt und so weiter.
Also da habe ich vielleicht auch noch eine andere Einschätzung.
Ja, aber da hast du genau den Kern gesagt.
Du musst dich auf sie verlassen können.
Und wenn zu Zuverlässigkeit Absturzfreiheit eigentlich gar nicht gehört, in dem speziellen Fall,
dann ist das ja voll okay, wenn es die ab und zu mal zusammenhaut.
Das mag natürlich in vielen Fällen nicht so sein, das ist schon klar.
Aber zum Beispiel…
Zum Beispiel, das ist ein Ansatz, der häufig in der Telekommunikation verwendet wird.
Die haben da häufig den Ansatz, let it crash.
Wenn die Software Schwierigkeiten macht, dann lass sie in Gottes Namen umfallen.
Mir egal, weil diese Software steuert ein Gespräch von einer Million.
Dann geht halt ein Gespräch den Bach runter, das ist zwar sehr traurig,
dann soll der andere halt nochmal anrufen.
Ärgerlich ist es, wenn ich gerade bei einer Buchung bin, nicht bei dem Kontieren.
Da würde ich sagen, lass es mal runterfallen.
Das ist ja nur eine von tausenden von Buchungen, weiß ich nicht.
Ja, trotzdem…
Machen die das so und machen die das schon seit Jahrzehnten so
und ich unterstelle mal, du bist mit der Qualität des Telefonsystems durchaus zufrieden.
Also Telefonsystem ja, aber Buchung eben nicht.
Also ich bin dabei, eine Rechnung zu schreiben und dann stürzt eben das System mal ab,
dann schreibe ich die Rechnung neu.
Da wäre ich ein bisschen not amused.
Ja, aber angenommen, das Ding würde zum Beispiel deine Rechnung speichern
und du könntest einfach dann sofort an derselben Stelle wieder weitermachen
und du hättest eigentlich nur so mal kurz so ein paar Sekunden flackern.
Das, ja.
Ja, das soll es, ne?
Also jedenfalls Kern ist eben wirklich der,
das, was der Kunde sich davon wünscht, zum Beispiel störungsfreie Rechnungen schreiben,
das muss erfüllt sein.
Wie es erfüllt ist, das steht auf einem völlig anderen Blatt.
Insofern, das ist, glaube ich, der Kern bei Qualitätssicherung,
dass man sich wirklich erst mal vor Augen führen muss, worin besteht denn Qualität?
Und deswegen fand ich das so toll, dass du vorhin so ein bisschen rumgestammelt hast.
Das macht man sich nämlich häufig gar nicht so richtig bewusst.
Was brauche ich denn eigentlich?
Was erwarte ich denn eigentlich von meinem Produkt?
Und genau das muss ich dann auch nachweisen.
Und das ist ja dann die spannende zweite Frage.
Wie gut muss es denn sein?
Ja gut, wie gut muss Software sein?
Das, was ich zu Anfang ja schon sagte, das ist etwas, was der Kunde formuliert,
wo ich als IT-Team, als Team, die das, also die Qualitätsanforderungen aufnehme
und beschreibe und dann auch eben entsprechend umsetze.
Aber das Wichtige ist doch, wie gut muss es denn wirklich sein?
Wie gut muss Software denn sein?
Es ist ja ganz klar, zum Beispiel,
es gibt verschiedene Qualitätsansprüche zwischen einem Tamagotchi und einem Herzschrittmacher.
An das eine würde ich wahrscheinlich höhere Ansprüche stellen als an das andere.
Wobei, ob jetzt der Qualitätsanspruch an einem Tamagotchi niedriger sein muss,
das hängt glaube ich davon ab, ob man vierjährige Kinder hat oder nicht.
Sehr schön, ja.
Wir haben es über das Testen jetzt gesprochen.
Gibt es noch irgendwas anderes Wichtiges, was für dich in dem Kontext Testen denn von Bedeutung ist?
Ja, es gibt etwas, was ich für ganz zentral halte
und was wiederum sich viele Menschen interessiert.
Und was viele Leute nicht so ganz bewusst machen.
Nämlich, es ist ja so ein bisschen dumm beim Testen.
Man würde ja ganz gerne nachweisen, dass eine Software fehlerfrei ist.
Das Blöde ist bloß, durch Tests kannst du Fehlerfreiheit nicht feststellen.
Du kannst nur Fehler feststellen.
Das bedeutet, die einzige Möglichkeit, die dir das Testen bietet, ist, Vertrauen aufzubauen.
Und ich finde, es ist ganz wichtig, sich das bewusst zu machen.
Insbesondere auch, wenn man im DevOps-Kontext darüber nachdenkt.
Im Kontext einer erhöhten Geschwindigkeit, Automatisierung und so weiter.
Alles, was ich tue mit Testen oder anderen Formen von Qualitätssicherung,
ist ausreichendes Vertrauen in mein Produkt herzustellen.
Mehr kann ich nicht schaffen, als dass ich sagen kann,
ja, ich glaube, das können wir auf unsere Kunden loslassen.
Wir haben es gründlich geprüft.
Wir finden nichts mehr.
Wir wissen mit unserer Erfahrung, irgendwo wird schon noch ein Hund drin sein.
Aber wenn, dann ist das hoffentlich nichts Schlimmes mehr.
Weil, so genau wir auch schauen, wir finden es nicht.
Okay, das muss jetzt passen.
Darum, das ist ganz zentral.
Testen kann nichts anderes tun, oder Qualitätssicherung kann nichts anderes tun,
als Vertrauen aufzubauen.
Okay, ja, na gut.
Also, was ich interessant finde, war die Aussage,
dass ich ja mit dem Testen nur Fehler finde.
Aber Fehlerfreiheit ja nicht quasi nachweisen kann oder erzeugen kann.
Genau.
Okay, jetzt haben wir das Thema DevOps als Überschrift für den Podcast
und auch für uns.
Und für unsere gemeinsame Arbeit.
Testen gibt es ja jetzt nicht erst, seit es DevOps gibt.
Also, Testen gab es ja schon zu meiner Zeit, als ich angefangen habe mit IT.
Also, es ist schon ein paar Tage her.
Gibt es irgendetwas, was sich in dem Thema Testen verändert hat durch DevOps
oder auch vielleicht einfach nur durch die Jahre,
durch die Jahre, in denen wir mit Test arbeiten?
Ja, sicherlich.
Also, man begann ja damit, dass man einfach manuell getestet hat
und vielleicht auch nur stichwörtlich.
Und mittlerweile ist das Pendel sehr weit in die Richtung geschwungen,
dass man sehr viel automatisieren möchte,
was natürlich gut zu DevOps passt,
das ja auch sehr stark den Fokus auf Automatisierung setzt.
Nicht zuletzt, weil man sich davon verspricht,
eine höhere Geschwindigkeit zu erreichen.
Aber die Frage ist natürlich,
tut man sich damit wirklich einen Gefallen
oder produziert man Produkte, die zwar schnell rauskommen,
aber die vielleicht gar nicht so stabil sind,
weil man gar nicht mehr die Zeit hatte, so gründlich zu untersuchen.
Das ist eine Frage, die ich sehr häufig höre in meinen Trainings,
dass die Leute dann etwas skeptisch werden und sagen,
ja, jetzt mal so bei aller Liebe,
wenn ich bis hin zu Continuous Deployment gehe und sage,
sobald jemand seinen Code fertig geschrieben hat,
dann knistert es mal kurz in der Maschine
und fünf Minuten später ist das Ding live.
Sag mal, bist du noch ganz bei Trost, Luca?
Insofern, wie kann man sicherstellen,
dass dieses Vertrauen, von dem wir vorher sprachen,
weiterhin bestehen bleibt und auch gerechtfertigt ist?
Und was würdest du in dem Umfeld empfehlen
oder was antwortest du auf diese skeptischen Fragen?
Naja, die Antwort ist die,
man macht die Dinge jetzt halt anders als vorher.
Also das ist jetzt nicht mehr wie zu Opis Zeiten.
Aber trotzdem wird man natürlich den Fokus
vielleicht sogar noch mehr auf Qualität legen,
als man es früher getan hat.
Man verschiebt nur den Zeitpunkt, an dem man verifiziert
und dann wird man nicht mehr so weit.
Die Methoden, mit denen man verifiziert, woanders hin.
Der eine Punkt ist, ich verlege sehr viel nach vorne
in Richtung der Spezifikation.
Also ich sage, ich schreibe jetzt nicht
mein 500-seitiges Anforderungsdokument,
knall das den Entwicklern auf den Tisch
und höre zwei Jahre nichts mehr von denen,
sondern ich spreche sehr häufig mit denen.
Ich stelle sicher, dass das, was ich mir überlegt habe,
wirklich Hand und Fuß hat.
Ich reagiere auf neue Erkenntnisse.
Das hat jetzt also nichts mit Testen zu tun,
sondern ich stelle schon im Voraus sicher,
dass das, was ich baue, überhaupt das ist,
was ich bauen sollte und so, wie ich es bauen sollte.
Das Zweite ist, natürlich, ich automatisiere sehr stark.
Ich habe eine aufwendige Testsuite.
Aber jeder, der sich ein bisschen intensiver
mit Testen beschäftigt hat, weiß,
es gibt gewisse Dinge, die sind einfach,
die findet eine Maschine nicht.
Ein Mensch findet die eine Maschine,
wird die nicht sinnvoll finden.
Was mache ich jetzt mit denen?
Da ist die Antwort.
Das schiebt man weiter nach hinten.
Das schiebt man nicht nach hinten.
Das schiebt man nämlich sogar
bis hinter die Auslieferung im Zweifelsfalle.
Indem man sagt, ich finde solche Arten von Defekten
nicht mehr im Test vor der Auslieferung,
sondern ich überwache während und nach der Auslieferung
mein Produkt sehr akribisch, sehr engmaschig.
Und sobald ich merke,
irgendwas ist da nicht ganz so, wie ich mir das vorstelle,
dann reagiere ich an dieser Stelle.
Das ist das, was wir früher Bananensoftware genannt haben?
Ah, danke schön.
Reif beim Kunden.
Ja, danke schön.
Das ist das Argument, das an der Stelle kommt.
Ja.
Das stimmt in einem Sinne schon,
aber im anderen natürlich nicht,
weil wenn ich dann in der Lage bin,
mir diese Geschwindigkeit zunutze zu machen,
um auf der Stelle zu reagieren,
auf der Stelle erkannte Probleme abzustellen,
bevor es der Kunde überhaupt richtig geschnallt hat,
dann habe ich ihm ja nichts Böses getan.
Okay.
Das bedeutet eben, wenn ich gutes Monitoring habe,
wenn meine ganze Organisation
technisch, kulturell, personell
so aufgestellt ist,
dass ich in der Lage bin,
mit dem Kunden in einem Dialog zu sein,
ob er es merkt oder nicht,
das kann ja auch einfach nur in einer passiven Beobachtung bestehen,
und unmittelbar zu reagieren,
wenn da irgendwas nicht ganz so läuft,
wie man es sich vorgestellt hatte,
dann habe ich ja trotzdem noch eine ausreichend hohe Qualität,
dann habe ich weiterhin das Vertrauen in mein Produkt,
so wie ich es ausliefere.
Vertrauen in dem Falle nicht,
weil ich mich vielleicht schon vorher vergewissert habe,
dass das fehlerfrei ist.
Na gut, kann ich eh nicht.
Sondern, dass ich weiß,
wenn irgendwas schiefläuft,
dann kann ich eingreifen und schnell eingreifen
und so gut eingreifen,
dass die Wünsche des Kunden weiterhin erfüllt bleiben.
Wenn ich das jetzt für mich nochmal mit meinen Worten formuliere,
dann sehe ich das ja,
also ich habe ja auch dann die Leute vor Augen jetzt gerade,
die in den Schulungen sitzen,
die eher so aus der klassischen,
alles genau beschreiben,
alles genau durchtesten,
jeden Fehler finden wir vorher, keine Frage.
Was du jetzt sagst,
geht ja eben dann genau auch quasi konsequent in die andere Richtung.
Natürlich einen hohen Qualitätsanspruch,
aber wir können eben vielleicht nicht vorher alle Fehler finden.
Was heißt vielleicht?
Du sagst ja, man kann vorher nicht alle Fehler finden,
dann lieber möglichst genau,
also Aufgaben nach links verschieben,
also shift left nach vorne,
respektive dann auch hintendran eben verbessern.
Sprich, dass das Testen sich eigentlich nicht nur auf das Testen
vor der Auslieferung bezieht,
sondern eigentlich auch Monitoring mit reinfällt,
um in der Live-Umgebung,
eben auch quasi zu testen in einem moderneren Sinne.
Genau, das ist der Kern der Sache,
dass man Testen nicht mehr als eine punktuelle Aktivität hat
während des Entwicklungsprozesses,
sondern genauso wie die gesamte Perspektive von DevOps
sich weiter nach links und nach rechts verschiebt,
muss auch Testen oder Qualitätssicherung
sich weiter nach links und weiter nach rechts verschieben.
Ich muss sicherstellen,
dass zu Anfang meine Anforderungen noch sauberer sind als bisher
und dass zweitens auch,
nachdem ich der Automatisierung
der Test beispielsweise gemacht habe,
nach hinten raus,
ich immer noch ein viel schärferes Augenmerk
auf die Qualitätssicherung mache nicht.
Das Ding wird irgendwie jetzt über den Zaun geschmissen,
ausgeliefert, nicht mehr unser Problem.
Interessant, also ich habe mich ja mit dem Testen
noch nicht so detailliert beschäftigt,
was du jetzt ja mir doch schon sehr gut erklärst an der Stelle.
Wenn ich mir das jetzt so vor Augen führe,
dann hätte ich jetzt gesagt,
es gibt ein paar Rollen,
die auch sagen, das machen wir so nicht.
Das verstößt gegen meine aktuelle Berufsethik
oder im schlimmsten Falle,
es gibt meinen Job gar nicht mehr oder mein Job ist anders.
Also wie reagieren denn Tester zum Beispiel auf solche Konzepte,
auf solche Aussagen?
Ja, das ist ganz unterschiedlich.
Also es gibt ohnehin eine gewisse Erwartung,
dass automatisches Testen Tester überflüssig machen würde,
was natürlich überhaupt nicht stimmt.
Irgendjemand muss ja diese automatischen Tests
nicht nur ursprünglich mal erstellen,
sondern vor allen Dingen auch weiter pflegen.
Die machen ja auch weiterhin Mühe.
Die müssen gewartet werden.
Die Testergebnisse müssen analysiert werden.
Es muss Leute geben,
die diese Testergebnisse überhaupt verstehen können.
Aber die andere Frage ist,
gibt es eigentlich den Tester noch,
wie man ihn kennt?
Also einen Typ, der irgendwo sitzt
und der dann versucht, Löcher in die Software zu hauen.
Ich stelle mir das gerade vor.
Löcher in die Software hauen.
Das ist eine schöne Umschreibung für einen Tester.
Ja, ich habe ja auch viel mit Embedded Software gearbeitet.
Da muss man manchmal auch wirklich physisch
irgendwo was kaputt machen.
Okay.
Ja, also was passiert denn mit den Testern?
Ja, der Tester, der testet,
den gibt es dann wirklich nicht mehr.
Der wäre ja ein Fremdkörper
in einer schnellen DevOps-Organisation.
Jetzt habe ich irgendwie rasend schnell
mein Produkt entwickelt
und habe eine wahnsinns Deployment-Pipeline
und solche Sachen.
Aber nee, jetzt braucht erstmal die Testabteilung noch drei Wochen,
um das Ding auf Herz und Nieren zu testen.
Das ist ja ein bisschen widersprüchlich.
Sondern Tests sind dann eben Dinge,
die automatisch schnell laufen während der Entwicklung
oder die sich durch Monitoring nach der Entwicklung
in der Produktion wiederfinden.
Und die Aufgabe des Test-Experten,
so nenne ich ihn mal,
ist es dann sicherzustellen, dass das sauber läuft.
Das heißt, er hat eine beratende Funktion.
Er muss den Leuten, die links und rechts von ihm sitzen,
dabei helfen, Qualitätsansprüche umzusetzen.
Er hat Architekturverantwortung.
Er muss mitreden und sagen,
passt mal auf, wie wollen wir diese Funktion,
die ihr euch vorstellt, denn eigentlich mal testen?
Wie können wir das überhaupt technisch gewährleisten?
Er muss allen beteiligten Softwareentwicklern,
Spezifikateuren, vielleicht sogar dem Kunden,
dabei helfen, zu verstehen,
wie Qualität überhaupt aussieht für das bestehende Produkt,
welches Vertrauensniveau notwendig ist,
wie wir dieses Vertrauensniveau herstellen können.
Das heißt, er hat eine viel stärker konzeptionelle,
beratende, sprechende Funktion.
Okay. Das heißt, in dem Umfeld würde er dann auch
bei dem Thema Test-Driven Development mithelfen.
Also er würde helfen, die Entwicklung entsprechend so auszurichten.
Ja, genau.
Und Test-Driven Development impliziert natürlich auch,
dass es automatisiert ist, ist die Frage,
wer schreibt denn diese Tests? Schreibt die der Tester?
Schreibt die der Softwareentwickler? Schreibt die noch wer anders?
Keine Ahnung. Was ja auch eine spannende Frage ist,
denn das ist genau der Punkt.
Die Aufgabe des Testers ist es im Einzelfall jetzt vielleicht
gar nicht mehr, Tests zu verfassen,
sondern die richtigen Fragen zu stellen, zu sagen,
wie wirst du das hier testen?
Und hast du schon ausreichend getestet,
der vielleicht einem Entwickler dabei hilft,
die Testautomatisierung gut zu nutzen?
Okay. Oder Menschen quasi, die in diesem Umfeld wichtig sind.
Ich habe ja eben jetzt nur von dem Tester gesprochen.
Du hast gesagt, das ist für dich der Testexperte.
Gibt es noch andere Rollen, die sich in dem Testumfeld
ja eben verändern werden?
Ja, klar. Nenne mich alle.
Okay.
Der Tester ist jetzt eben nicht mehr derjenige,
der quasi als einziger den Hut auf hat,
sich um Qualität kümmern zu müssen,
sondern das ist eine Verantwortung,
die jetzt in viel stärkerem Maße alle trifft,
die irgendwie an der Produktentstehung beteiligt sind.
Der Kunde, in dem er wirklich mitteilen muss,
was braucht er denn für eine Qualität?
Wie definiert sich für ihn Qualität?
Ein Product Owner, ein Spezifikateur, was weiß ich,
der dafür sorgen muss, dass die Anforderungen Qualität bereits im Blick haben.
Der Softwareentwickler, der automatische Tests schreiben muss,
der in eine Konversation tritt mit den Testexperten, mit den Kunden.
Ein Infrastrukturingenieur, der das Monitoring zur Verfügung stellen muss,
der eine automatische Testinfrastruktur einerseits nutzt,
andererseits vielleicht betreibt.
Weil, das ist ja übrigens auch ein spannendes Thema.
Ich kann ja in einer Everything-as-Code-Umgebung
plötzlich auch meine Infrastruktur testgetrieben entwickeln.
Das heißt, auch der Gegenstand der Tests könnte sich jetzt ändern.
Es ist nicht mehr nur allein das Produkt,
sondern es kann auch wirklich die Basis, die Infrastruktur sein,
das Netzwerk, sagen wir mal, in dem das alles läuft.
Also, sehr, sehr interessante Frage.
Vielen Dank für die Gedanken oder Ausführungen.
Ich habe jetzt gerade vor Augen,
ich war gerade vor zwei Tagen beim Training, Scrum-Training,
und da hingen noch alte Unterlagen von einem anderen Kurs,
der wohl vorher stattgefunden hatte,
der genau um das Thema Anforderungsspezifikation geht.
Und da habe ich mich jetzt gerade so ein bisschen daran erinnert,
denn mein Ansatz bei den Scrum-Trainings ist ja zu erklären auch,
wie ich denn Anforderungen beschreibe und dass ich eben Wert lege auf die Anforderungen,
Quatsch, auf die Akzeptanzkriterien.
Das heißt, dass letzten Endes, bevor der Entwickler loslegt,
er eigentlich wissen muss, auf was entwickelt er denn hin.
Also, dass der Kunde eben nicht sagt, die Software muss schnell sein
oder diese Funktion muss mir das und das ermöglichen,
sondern dass man wirklich klar ausarbeitet vorher, was heißt denn das?
Also, die Anforderungen besser zu beschreiben,
insbesondere auf das, was eben der Entwickler produzieren soll.
Und wenn du jetzt sagst, das Testen hat damit einen ganz großen Vorteil,
hat damit einen ganz, ganz anderen Stellenwert, eben von Anfang bis Ende.
Also, den Tester gibt es nicht mehr oder nicht mehr in der Form, wie wir ihn jetzt kennen,
weil er einfach jetzt quasi alle Testen im Blut haben müssen.
Genau. Insbesondere, wenn man so Techniken macht wie Behavior-Driven Development, BDD
oder auch genannt Specification by Example,
da gibt es in der Literatur gerne genannt die sogenannten Three Amigos.
Das sind dann die drei Freunde des Business, der Entwicklung und die Tester,
die sich wirklich zusammensetzen müssen und gemeinsam eine Specifikation entwickeln müssen,
die natürlich nicht nur funktionale Wünsche enthält, sondern auch Abnahmekriterien,
auch nicht funktionale Anforderungen, auch konkrete Beispiele, anhand derer man nachweisen kann,
ja, wir haben das gesteckte Ziel tatsächlich erreicht.
Gibt es noch Punkte von dir, die du jetzt in diesem Umfeld Tester, also Rollen und Menschen anführen würdest,
die wir noch ergänzen sollten?
Nein, ich glaube, das war es. Das Wichtige ist wirklich der Tester,
den gibt es nicht mehr. Es gibt jemanden, der ein Testexperte ist oder ein Qualitätsexperte ist,
der dem ganzen Team dabei helfen muss, Qualität sicherzustellen und dabei die gesamte Kette im Blick hat.
Also so wie du das jetzt darstellst, passt das für mich auch in das gesamte Bild.
Wir versuchen ja mit dem Thema DevOps hochperformante IT-Organisationen zu schaffen
und letzten Endes weg von den Silos und genau das ist ja der Punkt.
Das heißt, dass die Qualitätssicherung letzten Endes durchgängig ist.
Von Anfang bis Ende und dass ich eben jetzt nicht einen Experten habe, der alle Testszenarien kennt und so,
sondern dass ich einfach den Anspruch habe, nicht nur Qualität zu produzieren, sondern auch Qualität zu sichern
und das eben durch Testen, ich sag mal Testen in Anführungsstrichen, weil sich ja Testen dann auch verändert,
dass ich das umsetze und sicherstelle, eben durch den gesamten Prozess der Erstellung bis hin zur Auslieferung.
Genau und Geschwindigkeit, wir sprechen ja auch immer darüber,
DevOps solle nachhaltige Geschwindigkeit herstellen.
Geschwindigkeit ist ja auch kein Selbstzweck, denn ein Produkt, das nicht ausgeliefert werden kann,
weil wir es nicht fertig kriegen, weil jetzt wir noch, keine Ahnung, zum Beispiel aufwändige manuelle Qualitätssicherung machen müssen,
das ist quasi per Definition die schlechteste Qualität, die wir haben können, das Produkt ist gar nicht da.
Ja stimmt, da stimme ich dir zu, was das Thema Qualität angeht.
Genau.
Ja okay, gut, ich habe eben gesagt, bis zur Produktion,
bis zu dem Betrieb, wie sieht es denn aus mit dem Thema Testen in der Produktion, in der Live-Umgebung,
weil du hast ja gesagt, da monitore ich, also mache da im Prinzip auch Qualitätssicherung.
Ja genau und das muss ja auch die Konsequenz daraus sein, dass ich sage, ganz bewusst überspringe ich gewisse,
sagen wir mal traditionelle Teile der Qualitätssicherung, dass ich mir eine Analysephase mache,
die sehr lange dauert, nachdem das Produkt fertiggestellt wurde, sondern sobald ein Produkt oder Produktabschnitt fertig wurde,
ist der potenziell deploybar.
Wird vielleicht im Rahmen von Continuous Deployment sogar schon auf der Stelle deployed,
dann muss ich natürlich sicherstellen, dass ich trotzdem auf Überraschungen reagieren kann.
Und das kann ich nur machen durch ein wirklich ausführliches Monitoring und vor allen Dingen das, was dann auf das Monitoring folgt.
Monitoring alleine hilft mir noch gar nichts, sondern das Feedback muss dann auch wirklich seinen Weg wieder zurückfinden
zu den jeweiligen Entwicklern, schnell, präzise und auch die Entwickler müssen in der Lage sein, darauf zu reagieren,
wenn die jetzt merken, aha, ich habe da was entwickelt.
Ich habe die Produktion geschafft und jetzt erfüllt es aus irgendeinem Grund nicht meine Vorstellungen.
Das muss ja gar nicht heißen, es funktioniert nicht, es stürzt ab oder sowas, sondern es kann ja auch einfach nur sein,
die Benutzer finden es jetzt irgendwie doch nicht so toll.
Dann muss ich in der Lage sein, darauf schnell zu reagieren und gleich eine verbesserte Iteration nachzuschieben.
Dann, wenn mir das gelingt, dann habe ich wirklich die Macht von DevOps realisiert,
ganz unmittelbar, ganz schnell und auch trotzdem solide auf neue Erkenntnisse reagieren zu können.
Und das ist dann das, was wahrscheinlich Gene Kim mit seinem dritten Weg dann beschreibt.
Ja, genau.
Schnell Feedback sicherstellen und wir reden dann ja hier nicht nur über Feedback im Sinne von oder also regelmäßiges Feedback.
Wir reden nicht davon, dieses Feedback quasi in irgendwelchen Gesprächen zu haben, täglich sich irgendwo zusammenzustellen,
sondern dann vielleicht sogar noch kurzfristiger zu reagieren und das dann gar nicht mehr mit irgendwelchen Abstimmungsrunden,
sondern die Entwickler kriegen das quasi direkt auf den Rechner gespielt.
Sie müssen was tun, weil sie eben erkennen, da laufen Dinge nicht so wie geplant.
Na klar. So, angenommen, ich deploye jetzt eine neue Funktion von meiner Software,
dann muss ich da schon entsprechendes Monitoring installiert haben, sodass ich sehen kann, wird diese Funktion überhaupt genutzt?
Jetzt angenommen, ich habe eine gewisse Benutzerbasis und ich erwarte, dass jeden Tag 100 Leute diese Funktion in Anspruch nehmen werden.
Und jetzt stelle ich aber fest, das sind gar nicht so viele, das sind irgendwie bloß drei oder vier.
Diese Information, die kann ich ja automatisch sammeln. Keine Ahnung, wenn das eine Website ist, kann ich ja sehen, wie oft wird diese Seite abgerufen.
Und dann versetzt mich das in die Lage, sofort die Frage zu stellen, was ist denn da passiert?
Funktioniert diese Funktion nicht? Ist sie an den Wünschen der Kunden vorbei entwickelt oder wird sie einfach nur nicht gefunden?
Vielleicht ist das Problem ja total stumpf und die haben das doch gar nicht entdeckt, dass die da ist. Aber diese Mechanismen muss ich haben.
Und das würde dann ja auch auf den Kritikpunkt, sage ich mal, auch kommen.
Wir haben ja in unseren Trainings ja nicht nur Web-Entwickler und App-Entwickler, die wirklich schnell Dinge rausbringen wollen.
Wir haben ja auch an vielen Stellen Entwickler.
Und Mitglieder aus Teams, die eine, ich sag mal, eher stabile Software haben, die gar nicht auf diese Schnelligkeit an sich auch aus ist.
Und die fragen natürlich immer, was ist denn, wenn ich jetzt, ich muss ja nicht in der Buchhaltung jeden Tag eine neue Funktion bringen.
Oder nicht jeden Tag eine neue Funktion im wahren Wirtschaftssystem. Ich muss ja andere und neue schulen.
Das geht ja auch in die Richtung, quasi dieses Monitoring auch auf die Nutzung der bereitgestellten Funktionalitäten auszudehnen.
Abgesehen davon, das kann ja auch ein Qualitätskriterium sein, dass ich sage,
hey, die Software soll zumindest nach außen hin sich stabil verhalten.
Natürlich will ich nicht jeden Tag meine Benutzer umschulen. Die werden mir was husten.
Aber das Mächtige ist, dass ich in der Lage bin, so schnell zu reagieren, wenn ich es denn muss.
Wenn ich jetzt plötzlich feststelle, ich habe in meiner Buchhaltung irgendwie einen Fehler drin.
Da kann ich doch nicht bis zum nächsten Auslieferungsfenster in drei Monaten warten.
Sondern wenn ich dann technologisch, personell, kulturell in der Lage bin, auf der Stelle zu reagieren und diesen Fehler zu beheben,
dann bin ich doch in einer wahnsinnig starken Position.
Wirklich hohes Vertrauen in mein Produkt.
Das bedeutet, selbst wenn ich nur alle drei Monate neue Features rausbringe, die für meinen Kunden eine Veränderung sichtbar machen,
allein der Umstand, dass ich auf erkannte Fehler blitzartig reagieren kann, das ist für mich die große Stärke und das, was DevOps wirklich ausmacht.
Richtig. Ja, eben hoch performant. Also nicht nur schnell entwickeln und auch schnell reagieren und schnell,
also nicht nur schnell entwickeln, schnell ausliefern, aber eben auch schnell sicherstellen, bei Fehlern schnell zu reagieren.
Ja, genau. Also das ist auch eine Frage, die ich häufig entdecke.
Wenn ich in Kursen habe so, ja, aber ich will doch gar nicht so schnell. Ja, musst du ja auch nicht. Aber du kannst.
Und eben, das ist ja der Unterschied, wenn ich sage, ich will nicht, dann richte ich meine Organisation nicht darauf aus.
Wenn ich aber sage, ich möchte im Fall der Fälle schnell reagieren, dann habe ich ja die, also kann das erstmal mein Business,
denke ich, sehr viel besser verkaufen und schaffe damit quasi eine immanente Qualität in meiner Organisation und kann dann im Fall der Fälle eben entsprechend schnell reagieren.
Genau.
Jetzt sind wir wieder bei dem Punkt Vertrauen, weil ich ein höheres Vertrauen gewährleisten kann in mein Produkt.
Ja, richtig.
Selbst wenn die Organisation jetzt irgendwie Mist gemacht hat, die IT-Organisation, dann kann sie auf der Stelle diese Scharte wieder auswetzen.
Ja, richtig. Ja, so schließt sich der Kreis. Aber wir sind ja noch nicht am Ende. Wir haben ja noch ein paar Themen, die wir besprechen können.
Und was ich noch interessant finde, ist, dass du gesagt hast, dass nach wie vor auch Testen noch menschliche Arbeit ist.
Wenn man das Thema Automation sozusagen vielleicht falsch zu Ende denkt, dann würde das ja heißen, ich muss alle Tests automatisieren.
Dann hätte ich keine Menschen mehr. Du hast ja gesagt, ich brauche natürlich auf der einen Seite immer Menschen, die die Testautomation betreuen und betreiben.
Gibt es noch andere Fälle, wo wir sozusagen auch weiterhin menschliches Know-how brauchen im Testumfeld?
Wie gesagt, zum einen brauchen wir immer Leute, die die tatsächlichen Tests erzeugen, warten, umsetzen und so weiter.
Also für die eigentliche Testaktivität. Aber mehr als das, ein Testexperte oder ein Qualitätsexperte, der muss, wie gesagt, auch beratend zur Verfügung stehen.
Der spielt auf einmal in die Architektur mit hinein. Und er muss auch in die gesamte Organisation der Produktentwicklung mit hinein sprechen.
Denn der ist derjenige, der ein zentrales Interesse oder ein zentrales Verständnis hat von all diesen Rückkopplungsprozessen, die da stattfinden müssen.
Ganz kurzzyklische im Sinne von automatischen Unit-Tests oder sowas.
Die müssen mir im besten Fall bereits Sekunden, nachdem ich das fertiggestellt habe, eine Rückmeldung liefern.
Bis hin zu langzyklischeren Maßnahmen, die dann zum Beispiel mir Monitoring-Daten aus der Produktion zurückspielen.
Und das bedeutet, dass das nicht nur eine technische Arbeit ist, sondern es ist auch sehr stark eine Kommunikationsarbeit unter Menschen.
Und es ist sogar auch etwas Kulturelles. Es muss ja die gesamte Organisation sich überhaupt menschlich dazu in der Lage sehen,
mit so radikalem, so schnellem, so detailliertem Feedback umzugehen.
Ja, das ist richtig. Das ist vielleicht auch eine schöne Überleitung zu dem anderen Punkt, zu einer anderen Quelle.
Ich werde in den Shownotes auch nochmal einen Link posten. Es gibt, wie ich finde, eine ganz schöne Übersicht,
wo sieben Tipps dargestellt sind zum Thema Testen im DevOps-Umfeld oder sieben Hinweise.
Und einer dieser Hinweise ist nämlich genau, dass die Bedeutung der Soft-Skills zunimmt, auch für Tester oder in diesem Testumfeld.
Das ist ja genau das, was du auch sagst.
Ja, genau so ist es. Also zum Ersten brauchen Tester, glaube ich, schon immer gute Soft-Skills, weil jemandem mitteilen zu müssen,
dass seine Arbeit in irgendeiner Weise nicht gut genug war oder sowas, das ist halt nicht schön.
Dafür braucht man ein gewisses Feingefühl, kann man nicht dem anderen irgendwie feixen ins Gesicht sagen, was er da schon wieder für ein Mist verbockt hat.
Also kann man schon, aber das wird halt nicht gut gehen.
Aber es geht eben auch wirklich darum, Verständnis für all die Kommunikationsprozesse zu entwickeln, die da innerhalb eines Teams ablaufen und ablaufen müssen.
Bei diesen sieben Tipps, Soft-Skills, denke ich, das haben wir jetzt auch durchgängig behandelt.
Der erste Tipp ist auch Veränderung der Sichtweise, der Rolle des Testers, da haben wir auch, denke ich, ausführlich darüber gesprochen.
Der dritte Punkt ist, dass dort steht, dass Tester quasi, also wenn es die überhaupt noch gibt, logischerweise, aber in der Form, wie wir es jetzt in der modernen Form sehen,
dass Tester auch einfache Kenntnisse haben sollten über Entwicklung, also über Codieren. Wie stehst du dazu?
Ja, auf jeden Fall. Ich meine, ohnehin fordert DevOps ja, genauso wie das Agile auch, sogenannte T-Shaped Team Members,
also die sind dann T-förmig, nicht im körperlichen Sinne, aber im Sinne ihres Fähigkeitsprofils.
Sie haben eine tiefgehende Fähigkeit in einer bestimmten Sache und aber auch ein breites Verständnis links und rechts von dem, was sie so machen.
Und auf Tester trifft das in zweierlei Hinsicht zu, nämlich einerseits im Sinne von Testautomatisierung, die natürlich Programmierung darstellt.
Ein Testexperte muss verstehen, wie man automatische Tests schreibt, wie man sie klug schreibt, wie man sie richtig schreibt.
Da gibt es ja auch eine Menge Sachen, die man unklug angehen könnte.
Und zum anderen muss er aber auch Verständnis für Softwareentwickler und Softwareentwicklungsprozesse haben, weil er unmittelbar in sie eingreift mit diesem ganzen Feedback, das er bietet.
Auch eine vernünftige Forderung oder eine sinnvolle Forderung. Vielleicht so noch den letzten Punkt, den ich da rausgreifen würde, weil von diesen sieben Tipps haben wir eigentlich ziemlich viele schon im Vorbeiflug.
Behandelt und besprochen. Ein Punkt, den ich noch sehr interessant finde, ist, dass dort der Tipp gegeben wird, letzten Endes das Thema Berichtswesen oder Reporting nicht so sehr auf das Thema Testergebnisse auszurichten.
Das ist ja auch das, was du sagst, das ist falsch und das ist falsch und das ist falsch, sondern mehr auf das Thema, welchen Nutzen stifte ich denn mit meinen Tests, welchen Wert schaffe ich bei meinem Kunden, wenn ich Qualitätssicherung betreibe?
Ja, das stimmt. Das ist natürlich nicht allein.
Auf automatische Tests beschränkt, sondern das selbst in einem ganz klassischen manuellen Testumfeld stünde uns das auch gut zu Gesicht, darzustellen, nicht nur welche Fehler haben wir gefunden, sondern welchen Wert haben unsere ganzen Qualitätssicherungsmaßnahmen überhaupt erschaffen für die Organisation als Ganze?
Gerade in solchen Dingen wie Vertrauen, Verfügbarkeit und so weiter. Wahrscheinlich hat jeder schon mal diese Diagramme gesehen, wo da drin steht, ein Fehler, den ich während der Planung finde, der kostet einen Euro und ein Fehler, den ich während der Entwicklung finde, der kostet zehn Euro und ein Fehler, den ich erst in der Produktion finde, der kostet tausend Euro.
Wenn ich immer mehr von diesen Erkenntnissen immer weiter nach links schieben kann, dann kann ich auch ganz konkret auf Euro und Cent sagen, pass mal auf, liebe Organisation, unser ganzer Testaufwand, der hat dir wirklich eine Menge Asche gespart.
Ich war vergangene Woche auf einer Qualitätssicherungskonferenz, da hat jemand einen Vortrag darüber gehalten und hat uns das auch wirklich mal vorgerechnet und hat gesagt, pass mal auf, angenommen, wir testen gar nicht, dann in seinem Beispiel hat das irgendwie 800.000 Euro oder sowas gekostet an Kosten für Fehlerbehebung.
Mit dem Hut in der Hand beim Kunden auftauchen, was weiß ich was. Und dann hat er so systematisch angefangen, ja, wir könnten manuelle Tests einführen, wir könnten automatische Tests einführen, wir könnten Monitoring einführen und er war in der Lage, uns da einen Return on Investment vorzurechnen für im Extremfall, ich glaube, 700, 800 Prozent.
Also ich glaube, man darf nicht unterschätzen, wie zentral gute Qualitätssicherung ist für Softwareentwicklung im Allgemeinen und ganz besonders, wenn man, so wie DevOps das tut, auf Geschwindigkeit abzieht.
Weil dann kann man es sich einfach nicht leisten. Wenn ich aus vollem Lauf auf die Fresse fliege, dann tut es halt richtig weh.
Ich stelle mir das gerade vor. Ja klar, okay, natürlich. Wenn ich schnell bin, dann tut es wirklich weh. Das ist auch ein schönes Bild.
Ja, weil dann ist auch das Vertrauen weg. Dann ist dieser ganze schöne DevOps-Prozess, hat dann das Vertrauen verloren innerhalb der Firma, hat das Vertrauen verloren außerhalb der Firma.
Qualität muss man absolut ernst nehmen.
Man muss ein First-Class-Citizen sein, der die gesamte Softwareentwicklungskette von Anfang bis Ende, aber wenn man das hinkriegt, dann ist man halt wirklich rasend schnell.
Das war irgendwie ein ganz tolles Schlusswort. Ich stoppe jetzt mit all meinen Fragen, weil das war wirklich ein schönes Schlusswort. Wir sind ja auch schon bei der Zeit soweit fortgeschritten, das war eine vernünftige Länge.
Luca, ich danke dir. Das war wirklich für mich, also auch für mich nochmal, waren so ein paar Gedankengänge dabei, die neu waren für mich, die mich auch weitergebracht haben.
Und ich hoffe und denke, dass es auch dann den Hörern des Podcasts so geht. Also vielen Dank für deine lustigen und vor allen Dingen auch sinnvollen und gut begründeten Einschätzung zum Thema Testen im DevOps-Umfeld.
Ja, nochmal vielen Dank für die Anleitung, Dirk. Ich hoffe, euch Hörern hat es auch Spaß gemacht und euch auch ein paar neue Denkanstöße gegeben. Das ist einfach ein Thema, das mir wahnsinnig wichtig ist und ich freue mich immer, wenn ich Leuten dabei weiterhelfen kann.
Besser zu verstehen und klüger anzugehen.

https://podcasters.spotify.com/pod/dashboard/episode/e29ihqs

Das führende ITSM-Framework ITIL® ist in einer neuen Version verfügbar und fokussiert nun stark auf Agilität. In diesem Podcast habe ich Martin Andenmatten zu Gast, der als ausgewiesener Experte für IT Service Management gilt und viele gute Veröffentlichungen für die Coomunity liefert. Wir sprechen unter anderem über die Neuerungen in ITIL4®, über die Beziehung von DevOps und ITIL® und wie diese beiden Ansätze IT-Organisationen in Zukunft gemeinsam unterstützen können.

In dieser Podcast-Episode diskutieren die Teilnehmer die Entwicklung und Integration von DevOps und ITIL 4, zwei zentrale Frameworks in der IT-Serviceverwaltung. Martin Andenmatten, ein Experte auf diesem Gebiet, beleuchtet die historische Trennung zwischen DevOps und ITIL und erklärt, wie ITIL 4 mit neuen Konzepten wie Service Value Chain und Guiding Principles reagiert hat. Der Fokus liegt auf der Verschmelzung agiler Prinzipien in ITIL und der Förderung einer effektiveren Zusammenarbeit zwischen Entwicklung, Betrieb und Geschäftsprozessen. Die Episode endet mit einem optimistischen Ausblick auf die zukünftige Koexistenz und Synergie von DevOps und ITIL 4.

Inhalt

• Einleitung und Vorstellung der Gäste
  • Martin Andenmatten, Managing Director von Glenfis
• DevOps und ITIL: Historische Perspektiven und Trennung
  • Diskussion der ursprünglichen Konflikte zwischen DevOps und ITIL
• ITIL 4 und seine neuen Konzepte
  • Erklärung des Übergangs zu ITIL 4
  • Vorstellung der Service Value Chain und Guiding Principles
• Integration agiler Prinzipien in ITIL 4
  • Wie ITIL 4 agile Methoden aufnimmt
• Die Rolle von DevOps in der heutigen IT-Landschaft
  • Diskussion über die anhaltende Relevanz und Entwicklung von DevOps
• Synergie und Koexistenz von DevOps und ITIL 4
  • Diskussion über die zukünftige Zusammenarbeit von DevOps und ITIL
• Schlussfolgerungen und Ausblick
  • Abschließende Gedanken zur zukünftigen Richtung von ITIL und DevOps

Shownotes

Blog von Martin Andenmatten

Webseite der Glenfis AG

Hybride IT-Organisationen mit ITIL4 und DevOps

ITIL und DevOps im Zusammenspiel

Transkript (automatisiert erstellt, daher keine Gewähr 🙂 )

Herzlich willkommen zum Podcast DevOps auf die Ohren und ins Hirn.
Wir haben heute das Thema DevOps und ITIL, wieder Freunde.
Und zu diesem, denke ich, ziemlich interessanten Thema freue ich mich, einen sehr kompetenten Gesprächspartner an Bord zu haben, Martin Andenmatten.
Martin Andenmatten ist Managing Director der Firma Glenfis aus der Schweiz.
Und ich glaube, bevor ich jetzt Martin weiter vorstelle, denn da ist sehr viel zu erzählen, ist ein sehr kompetenter Gesprächspartner, würde ich sagen, Martin, stell du dich doch mal vor.
Ja, vielen Dank, Dirk, dass du mir hier die Gelegenheit gibst.
Ja, ich bin ja schon eine Weile unterwegs mit verschiedensten Themen im Bereich Organisationsentwicklung.
Wie du gesagt hast, bin ich Geschäftsführer der Firma Glenfis.
Das ist ein Unternehmen, das ich vor 20 Jahren gegründet habe.
Ja, tatsächlich vor 20 Jahren.
Das ist auch so der Anfang gewesen, als das Thema ITIL großgekommen ist.
Und ja, ich habe hier ein Unternehmen mit 15 Mitarbeitern.
Wir haben spannende Beispiele.
Wir haben spannende Projekte.
Wir arbeiten mit Menschen und wir teilen die Erfahrungen und sind trotz all diesen 20 Jahren immer wieder überrascht, was wir für tolle neue Herausforderungen anpacken können.
Ja, und heute ist ja ein spannendes Thema auf dem Tablett und da bin ich gerne bereit, da mal meine Einschätzung zu geben.
Ja, was ich so interessant finde, ist, dass du eben natürlich die ITIL-Kennzüge hast oder das ITIL-Know-how aus.
Ja, 20 Jahre an der Stelle, aber dass du ja auch in vielen anderen Themen unterwegs bist.
Also du bist in dem Thema Agilität unterwegs.
Du kennst dich auch sehr gut aus dem Thema COVID.
Also wie kann ich IT mit Governance verbinden?
Also ich glaube, dass du da, wenn du da sagst, du bist eine Weile unterwegs.
Diese Weile ist ja schon relativ lang, was du ja selber gesagt hast.
Und dadurch bringst du auch natürlich sehr viel Kompetenz, sehr viel Erfahrung mit.
Und ja, da freue ich mich auf unser Thema.
DevOption ITIL, wieder Freunde.
Die Hörer meines Podcasts werden ja wissen, ich stelle immer den Gästen die Frage, was ist DevOps für dich?
Kannst du DevOps definieren?
Kannst du DevOps beschreiben?
Also Martin, wie würdest du denn DevOps definieren oder beschreiben?
Ja, das ist immer die spannende Frage.
Ich höre ja deine Podcasts immer wieder gerne und es ist auch spannend, wie da auch immer unterschiedliche Definitionen herauskommen.
Für mich ist es klar, es ist eine Bewegung.
Es ist vor allem eben auch eine kulturelle Bewegung, die auf eine bessere Zusammenarbeit ausgerichtet ist.
Insbesondere eben auch angestoßen aus der Softwareentwicklung.
Dort ist die ganze agile Mindset, denke ich, schon eine Weile länger präsent gewesen.
Und man hat damit eigentlich mal diese Bastion Operation, diese Mauer da durchbrochen.
Und ich sehe vor allem eben darin diese Bewegung.
Dieser Mindset der agilen Zusammenarbeit, der besseren Zusammenarbeit im Vordergrund.
Ich sehe weniger im Fokus jetzt die Technologie, dieses Automatisieren, das natürlich auch irgendwo ein Bestandteil ist.
Aber die große Bewegung, die man dann ausgelöst hat, eben, dass man da endlich mal über den Graben schaut,
das ist für mich eigentlich die große Errungenschaft von DevOps.
Okay, das finde ich interessant, weil ich hatte über das Thema Bewegung, über den Begriff Bewegung, noch nie drüber nachgedacht.
Der tauchte noch nie so in meiner Sichtweise auf.
Aber natürlich, es ist eine Bewegung.
Es ist eine Bewegung von Leuten, die einfach sagen, wir möchten zusammenarbeiten oder wir sollten zusammenarbeiten.
Und wir heißt dann eben die verschiedenen Bereiche, Dev und Ops oder auch vielleicht noch ein paar mehr Bereiche.
Ja, ich glaube eben, es ist ja auch ein bisschen eine Befreiung gewesen.
Ich denke, Operation hat sich da ein bisschen eingelegt.
Die Mauern hochgezogen und irgendwie ist man angestanden, mit dem Druck hier noch mehr Tempo hineinzubekommen, Veränderungen anzustoßen.
Und mit dieser Bewegung, sage ich jetzt trotzdem nochmal, DevOps hat man eigentlich da einen Stein ins Rollen gebracht, hat die Türen geöffnet.
Und das hat auch eine gewisse Befreiung vielleicht gebracht in Organisationen.
Ja, das finde ich, das klingt gut.
Das ist ja auch für mich interessant.
Wenn ich jetzt auf den Titel vom Podcast gehe, Dev, Ops und ITIL wieder Freunde?
Fragezeichen.
Das suggeriert ja, dass sie mal nicht Freunde waren oder überhaupt noch nie Freunde waren.
Würdest du das auch so sehen?
Ja, eben. Ich personifiziere jetzt so Methoden und Frameworks nicht wirklich.
Das ist letztendlich projiziert man vielleicht gewisse,
Verhaltensweisen oder sucht dann irgendwo Feindbilder oder Gründe, wieso gewisse Sachen nicht laufen.
Aber es stimmt natürlich schon ein bisschen, dass das ganze ITIL Framework, so wie es auch in vielen Organisationen eben umgesetzt worden ist,
eben als der Grund für diese eher starren, eher bürokratischen Prozesse angeschaut worden sind und damit eigentlich auch die Ursache,
wieso das insbesondere natürlich Operation vielleicht sich da nicht so bewegt hat.
Und was man natürlich dann hauptsächlich als Begründungen gehört hat, wieso das jetzt endlich Dev Ops da zum Zuge kommt,
war dann, weil alles, was man vorher gehabt hat und da ist natürlich ITIL als, sage ich mal, zentrales Framework,
das praktisch in jeden Organisationen vorhanden gewesen ist, ist dann die,
ja, ideale Zielscheibe wahrscheinlich gewesen, für dort alles mal abzuladen, was nicht gut läuft.
Und was man ja so gehört hat, ITIL ist ein Loch, das ist viel zu prozesslastig,
dass mit diesen vielen Prozessen, die da sind, das kann ja unmöglich funktionieren,
sind viel zu theoretisch und natürlich jetzt mit diesen Phasen, die ja da das Lifecycle dargestellt hat,
mit Strategie, Design, Transition, Operation, das ist das Tönt nach Wasserfall
und das ist überhaupt nicht mehr geeignet für diese eher eben auf agilen Methoden ausgerichteten Arbeitsweisen.
Und daher hat ITIL, und das muss man ja auch sagen, ITIL hat dort auch keine entsprechende Antwort gehabt bis jetzt
und hat das einfach so mal schlucken müssen.
Und ich meine, ich habe ja am Anfang auch gesagt,
ich kenne das Framework schon seit dem Anfang an, seit der Version 1
und es war ja nie die Absicht von diesem Best-Practice-Framework,
irgendwie eine Bürokratie aufzubauen oder starre Verhaltensweisen in Organisationen zu etablieren.
Man hat eigentlich ein Framework bereitgestellt mit der Idee,
schau,
das sind so diese Best-Practices als Guidelines, adoptiert die und passt die an für eure Organisationen.
Und was die Organisationen gemacht haben, die haben das dann zwar übernommen,
aber haben es nicht angepasst an die Organisation und praktisch dann eins zu eins diese Themen da versucht umzusetzen.
Das war sicher ein großes Problem.
Auf der anderen Seite, das muss ITIL aus heutiger Sicht sicher auch sagen,
die Prozesse, die sind dann so detailliert.
Die sind dann so beschrieben worden, dass man sich überhaupt nicht mehr Gedanken gemacht hat,
dass das Ganze eben irgendwie zusammen funktionieren muss.
Man hat dann eben wirklich aus diesen Funktions-Silos, die man vielleicht gekommen ist,
hat man dann Prozess-Silos aufgebaut und jeder hat sich hinter die Prozesse versteckt.
Das ist sicher das, was ITIL, ich denke, nicht in der ursprünglichen Idee gehabt hat,
aber was natürlich draus geworden ist.
Ja, na gut, ich meine, es ist ja so, wenn ich mir das anschaue,
ITIL oder ITIL sind ja erstmal nur Bücher.
Also insofern, man kann ja den Büchern nicht vorwerfen,
dass sie das Ziel hatten, etwas zu bürokratisieren.
Es sind immer noch die Menschen, die irgendetwas daraus gemacht haben an der Stelle.
Und was ich auch immer sehe, ist,
ich war ja eine Zeit lang auch ziemlich kritisch gegenüber ITIL,
muss aber jetzt sagen, man muss auch mal ein bisschen Abstand gewinnen
und man darf nicht außer Acht lassen.
Es gab mal Zeiten oder Phasen, ITIL ist ja schon ein bisschen älter,
wo es absolut Sinn gemacht hat, mit dieser Art Denkweise
ein bisschen mehr Professionalität und Standardisierung
in die Unternehmen reinzubringen.
Ja, ich denke, das hat ja gefehlt.
Man hat irgendwie zu wenig Struktur gehabt,
insbesondere wo man das ganze Thema immer wieder projiziert,
ist der IT-Operation-Bereich.
ITIL hat ja von der Idee her natürlich auch vielen grösseren Scope,
aber dort insbesondere im Betrieb,
dort hat man eigentlich nicht wirklich gesehen,
was man da wirklich an Mehrwert leistet,
ausser dass man schaut, dass die Infrastruktur schön warm läuft
und dass die Systeme immer hochgefahren sind.
Und dass da ein Mehrwert fürs Unternehmen daraus entsteht,
nur damit man schaut,
die Lampen leuchten, das ist zum Teil in vielen Organisationen
auch heute noch nicht wirklich sichtbar.
Und mit ITIL hat man zumindest den Tätigkeiten
und diesen Aufgaben einen Namen gegeben.
Man konnte es auch strukturieren und man konnte den Leuten,
die dort auch wirklich einen tollen Job machen wollten
und auch gemacht haben, konnte man auch eine Perspektive geben,
wie sie sich entdecken.
Ich denke, das ist sicher auch ein großes Vermächtnis,
dass man ITIL und den Leuten, die dahinter stecken,
immer noch stecken, zugutehalten muss.
Ja, klar.
Jetzt hast du eben schon angedeutet,
dass sich bei ITIL ein bisschen was verändert hat.
Wir reden ja heute auch über die Version ITIL 4,
wobei ich gehört habe, das soll nicht Version 4 heißen,
sondern nur ITIL 4.
Also egal, wie das heißt, es gibt eine neue Version,
eine Veränderung bei ITIL.
Und das geht auch in Richtung Agilität.
Kannst du da mal vielleicht ganz kurz oder auch ein bisschen länger
was zu erklären?
Ja, vielleicht das mit dem Klären mit dem V4.
Es ist in der Tat so, das V kommt nicht in Erscheinung.
Man sagt ITIL 4.
Die 4 hat verschiedene Bedeutungen.
Einerseits ist es klar, die neue Version.
Auf der anderen Seite soll es auch die vierte Revolution
oder die in der Art, die wir jetzt haben,
von der Digitalisierung, wo wir jetzt gerade drinstecken,
dass das auch ein Basisrahmenwerk ist.
Und ja, es hat sich ja einiges aufgestaut.
Wir haben es ja gesehen.
Der ITIL hat keine Antworten gehabt auf die neuen Herausforderungen,
auf die neuen Arbeitsweisen und insbesondere auch auf die Agilität hin
hat sich dort einiges aufgestaut, dass man jetzt den angepackt hat.
Und ja, es ist natürlich,
sehr viel hat sich da geändert.
Also, was man vielleicht von ITIL V3 oder der Edition 2011 her kennt,
das war ja schon, wo man das dazu mal eingeführt hat,
auch ein großer Schritt.
Man hat ja diesen Service Lifecycle ins Leben geworfen,
weil man ja dann auch wirklich den Service in den ganzen Lebensphasen
da kennen und steuern und auch entwickeln wollte.
Dieser Lifecycle ist in der Form eigentlich nicht mehr vorhanden.
Man hat jetzt eigentlich angedockt an die anderen Frameworks,
insbesondere auch aus dem Lean Umfeld hat man diesen Value Chain oder
dieses Service Value System hochgezogen, weil ja, man hat,
ich sage das immer gerne so, man hat von der Version 3 mit dem Fokus
auf den Service teilweise ein bisschen,
die Schwierigkeiten gehabt, den Mehrwert für das Business hervorzuheben.
Und in der neuen Version ITIL 4 ist der Fokus jetzt nicht mehr der Service alleine,
sondern insbesondere der Fokus liegt auf dem Mehrwert,
auf dem Value für das Business.
Und die Leute, die sollen immer wieder vor Augen haben,
was ist letztendlich der Mehrwert?
Wieso machen wir überhaupt gewisse Dinge?
Und dieses Ausrichten auf diesen Value,
äh,
hat dann eigentlich den Rahmen gegeben für dieses Service Value System.
Und insbesondere spannend hier drin ist,
dass man ähnlich wie vielleicht in diesem agilen Manifest,
hat man auch hier jetzt sogenannte Guiding Principles definiert,
so Leitprinzipien, nach denen man eigentlich die grundsätzliche Denkhaltung
ausrichten sollte oder auch die Wertvorstellungen ausrichten sollte.
Und weiß nicht, vielleicht kennt man noch den ITIL Practitioner.
Das war ja so ein Zwischending,
der mal auch mit sehr viel Aufwand erstellt wurde,
aber im Markt nicht wirklich großen Anklang gefunden hat.
Aber dort drin waren wirklich sehr, sehr gute Ansätze schon enthalten,
wie man eben auch auf die heutigen Anforderungen rausgeht.
Und diese Guiding Principles, das sind eigentlich Kern,
Prinzipien, die man da auch aus diesem Practitioner jetzt herausgenommen hat
und hier eigentlich zur Grundlage gelegt hat.
Lass mich mal ganz kurz einhaken.
Ich habe ja gesagt, es wird auch vielleicht ein bisschen mehr,
was du zu erzählen hast, weil es ja eine relativ große Veränderung ist.
Was ich aber nochmal nachfragen wollte, was für mich der Eindruck ist,
es gibt ja ITIL jetzt nicht mehr in den vier Bänden mit einem kompletten Werk
und darauf entwickle ich, und das ist einmal durchdekliniert,
darauf setze ich die Schulungen auf, sondern man hat quasi jetzt pro Schulungszyklus
oder pro Schulungsinhalt entwickelt man Bücher.
Also man geht, wenn man so will, auch agil vor.
In kleineren Schritten entwickelt man das große Ganze.
Ist das ein richtiger Eindruck?
Ja, das ist eigentlich ein richtiger Eindruck.
Ich bin auch ein bisschen skeptisch gewesen oder kritisch,
dass man jetzt die Detaillierung eigentlich anhand von der Ausbildung ausrichtet
und nicht umgekehrt.
Aber die Idee ist schon, dass mit diesem Foundation,
das ist ja das erste Buch, das da ist,
also es wird dann über das ganze Jahr werden,
da mindestens noch vier oder fünf Bücher kommen,
hat man jetzt eigentlich die Grundlage gebaut
oder eigentlich auch die Übersicht geschaffen,
um das ganze System mal von einer Vogelperspektive anzuschauen.
Ich denke, das ist ein großer Vorteil gegenüber vielleicht den anderen Büchern,
die da nach diesen Lifecycle-Phasen orientiert sind.
Man hat eigentlich immer nur eine bestimmte Optik eingenommen
und es war dann sehr viel Sekundärliteratur auf dem Markt,
die mehr oder weniger gut geschrieben sind,
die dann das ganze Bild eigentlich gebaut haben.
Und hier mit dem Foundation hat man jetzt so eine Grundlage erarbeitet
und man sieht schon relativ gut, wie das Ganze letztendlich dann auch aufgebaut ist.
Also insbesondere dieses Value System mit diesem Value Stream,
das Konzept, das kommt hier sehr gut herüber.
Also für mich würde es auch heißen, wenn ich mir das vorstelle,
wenn ich jetzt in ITIL einsteigen möchte,
dann hätte ich ja früher eigentlich, wenn ich keine Schulung besuchen will,
mir diese fünf Bücher durchlesen müssen,
weil es ja gut, es gab zwar ein paar Originalzusammenfassungen,
aber es gab eben quasi von der Originärliteratur nur diese fünf Bücher
und das kann ich jetzt anders machen.
Jetzt lese ich mir dieses Buch Foundation durch
und habe dann einen Überblick, was hinter ITIL 4 steckt
und kann dann tiefer einsteigen in die weiteren Bücher, die noch kommen werden.
Ja, so in der Art.
Aber es ist vielleicht auch noch ein ganz anderer Ansatz, den man hier fährt,
was genau in den neuen Büchern, in den noch zu erwartenden Büchern drinsteckt.
Das ist schwierig jetzt hier schon abzuzeichnen,
aber man hat den Vorwurf, dass die Bücher zu umfangreich gewesen sind,
dass die Beschreibungen so detailliert gewesen sind,
also diese praktisch vorschreibende Darstellung, wie man Prozesse dann zu bauen hat,
von dem ist man grundsätzlich weggekommen.
Man hat diesen Vorwurf dann auch ernst genommen
und hat jetzt die Prozesse gar nicht mehr als Prozesse beschrieben,
sondern man hat alle bekannten Prozesse und Funktionen, die in ITIL 3 dagewesen sind,
die hat man jetzt eigentlich als Prozesse beschrieben.
die hat man jetzt eigentlich als Prozesse beschrieben,
die hat man jetzt eigentlich als Praktiken dargestellt.
Und Praktiken sind ein bisschen allgemeiner gehalten hinsichtlich,
was jetzt Prozessinhalte sind,
sondern es ist dann auch vor allem eben auch noch der Link
zu den anderen Ressourcen, die notwendig sind, sind da abgebildet.
Man hat eben dann als Organisation, die sowas dann eben adaptieren will,
viel mehr Spielraum.
Es ist gar nicht so viel Material vorhanden, um zu definieren,
wie was gebaut ist, Priorisierung heisst einfach,
Heißt einfach, es muss priorisiert werden, aber wie man das jetzt macht, das ist dann der Organisation überlassen.
Daher ist dann meine Empfehlung, es gibt dann immer noch Leute, die dann plötzlich anstehen und nicht genau wissen, wie man sowas machen könnte,
dass man jetzt die alten Bücher, die V3-Bücher nicht gleich wegschmeißt.
Vielleicht kann es dann helfen, dass man zwischendurch wieder mal zurückgreift auf das V3-Buch und geht dort mal reinschauen und sich eine Vorstellung holt.
Wie das dann nun konkret aussehen könnte.
Aber das Aktuelle, das ist wirklich sehr schlank gehalten.
Man hat eine ganz einfachere Übersicht, wie so Dinge zusammenhängen.
Okay, das heißt, wenn ich jetzt kurz zusammenfasse von den Änderungen von ITIL 4.
Die erste große Änderung ist, es gibt keine Service-Lebenszyklen mehr oder Lebenszyklusphasen.
Es gibt dafür jetzt eine Value Chain, eine Service-Value Chain.
Wir haben ähnlich wie beim ITIL 4.
In einem agilen Manifest, in einer agilen Umgebung haben wir eben Guiding Principles.
Also etwas so eine Art, wie der Name schon sagt, leitende Prinzipien.
Und wir haben, wenn man so will, keine Prozesse mehr, keine Funktionen, sondern nur noch Praktiken, die beschrieben werden.
Richtig?
Das ist richtig, was aus dem Inhalt vom ITIL her kommt.
Das heißt ja nicht, dass es dann keine Prozesse mehr braucht.
Die Prozesse, die muss man natürlich dann in Organisationen bei der Umsetzung schon bauen.
Aber die Idee ist jetzt wirklich, dass man nicht jetzt einfach silomäßig die Prozesse oder eben die Praktiken umsetzt als wieder eigenständige Entitäten,
sondern man baut jetzt, und da ist vielleicht auch ein bisschen diese Anlehnung an die DevOps-Gedanke,
man baut jetzt eben Value Streams, die sich dann eben zusammensetzen aus den verschiedenen Praktiken, die man dann braucht.
Also es ist nicht die Idee, dass man jetzt einen Value Streams,
einen Value Stream hat aus einer Praktik heraus, sondern ein Value Stream besteht dann vielleicht aus verschiedensten Praktiken,
die dann angezogen werden, wenn sie entsprechend dann auch zum Zuge kommen.
Und das gibt eine grössere Flexibilität, es gibt auch mehr Modularität und vor allem hilft es eben den Organisationen,
hier auch ein bisschen zurückzugreifen an Inhalten, was man dann allenfalls berücksichtigen sollte.
Das ist vielleicht sicher einer der grossen Vorteile.
Ja, okay. Was gibt es noch an grossartigen oder nennenswerten Veränderungen?
Ja, eben, es ist natürlich sehr viel im Detail drin.
Also wichtig eben sind schon diese Guiding-Prinzips, also diesen Fokus auf den Mehrwert zu legen,
dort anfangen, wo man auch heute steht, iterativ vorwärts gehen, Feedback geben, Sichtbarkeit erhöhen,
all diese Themen, die lehnen sich stark eigentlich auch an diesem agilen Mindset an.
Ja, was gibt es?
Was gibt es sonst noch? Also ein Thema ist eben auch diese ganze Wertschöpfungsthematik.
Man hat, das ist immer einer der grossen Vorwürfe, die man an die IT-Organisationen hat.
Die IT hat immer das Gefühl, sie wisse dann, was jetzt der Service und was der Mehrwert für das Business darstellt.
Aber letztlich kann man den Mehrwert nicht ohne das Business bestimmen.
Und so ist ein Grundkonzept vom neuen ITIL 4 dieses Value Co-Creation.
Also man kann den Mehrwert nicht ohne das Business bestimmen.
Also man kann den Mehrwert nicht ohne das Business bestimmen.
Man erarbeitet den Mehrwert eben gemeinsam zusammen mit den Stakeholdern,
mit dem Business, mit den irgendwelchen, weiß nicht, auch Partnern, mit Legal.
Also es ist nie eigentlich ein Ergebnis, das man aus der IT-Organisation herausgibt
und so, hier hast du jetzt und hoffentlich kriegst du Value,
sondern es ist eigentlich, der Mehrwert wird eigentlich geshared.
Also es ist eine…
Eine Co-Ownership of the Value.
Und das heißt, man hat viel mehr Skin, letztlich viel mehr Haut eigentlich auch auf der Business-Seite drin,
um sicherzustellen, dass es tatsächlich das ist, was das Business braucht.
Wenn ich das richtig verstehe, das Business wird quasi mit in die Verantwortung genommen,
in Mitwirkungspflicht, den Business zu beschreiben und zu bestimmen.
Auf jeden Fall.
Also beschreiben, ich denke, wichtig ist, dass man wirklich,
dass man wirklich genau herausspürt, wie das Business diesen Service braucht.
Und das ist auch noch der zweite Grundgedanke, den man jetzt hier damit eingebaut hat,
neben dem Co-Creation, ist auch dieses ganze Service-Relationship,
dass die Unternehmen, also die IT-Organisation, sei das interne oder externe,
erhöht letztendlich die Capabilities vom Kunden, der natürlich diesen Service aufnimmt.
Also mit dem…
Mit dem kann der Kunde sein Business dann wiederum optimaler gestalten.
Und letztendlich wird er natürlich dann vom Business aus gesehen den Service, den er seinen Kunden gibt,
auch wiederum ihm gegenüber helfen, dem Endkunden seinen Service, seine Capabilities zu erhöhen.
Also es ist eigentlich so eine Art, eine Kettenreaktion, dass man dann eigentlich damit erreicht,
wenn die Mehrwerte…
optimal austariert sind, dass eben auch die Endkunden und vielleicht auch die Kunden der Endkunden
entsprechend dann auch einen Mehrwert haben.
Dieses über den Tellerrand schauen, nicht nur, was gefällt jetzt meinem Kunden,
sondern auch verstehen, wie das Produkt oder der Service, den man gegenüber dem Endkunden liefert,
wie das dann dem Endkunden auch wirklich was verbessert.
Ja, okay. Wenn ich mir diese Veränderungen mal anschaue, dann stellt sich mir,
die Frage, ist denn ITIL 4 überhaupt noch ITIL?
Also hat sich da nicht ITIL so komplett verändert, dass man von einem neuen ITIL sprechen kann?
Man kann sicher von einem neuen ITIL sprechen, das kann man auf jeden Fall.
Also wenn man das natürlich so liest, hat man komplett neue Konzepte, neue Ideen dabei.
Aber der Grundgedanke vom Service Management, der ist nach wie vor da.
Man will natürlich…
Services so produzieren oder so bereitstellen, dass es dem Kunden einen maximalen Mehrwert gibt.
Das war schon immer die Ursprungsidee.
Und die Methodiken, wie man das erreicht mit den Veränderungen, die…
Und das ist ja nicht der Anspruch, den ITIL hat, den auch eigentlich kein Framework hat,
für sich zu definieren, alles zu wissen oder alles zu definieren, wie man gute Services baut,
sondern dass man das auch einfließen lässt, wie jetzt gerade die ganzen agilen Bewegungen,
dass man das eben nutzt, diese Gedanken dann auch weiterzuentwickeln.
Und von daher ist es bestimmt neu, aber es hat natürlich sehr viel Wiedererkennungswert.
Eben schon allein von den Praktiken, die im ersten Moment vielleicht genau gleich heissen,
wie sie früher mit den Prozessen geheissen haben.
Aber das sind Sachen, die immer wieder auf die bestehende oder auf die alte ITIL-Version zurückblicken.
Jetzt hast du ja ganz viel berichtet davon, was sich an ITIL verändert hat oder mit ITIL 4 verändert hat.
Was hat sich denn nicht verändert, außer dass die Prozesse und Funktionen jetzt quasi nur anders heißen?
Also wo ist sich ITIL quasi treu geblieben und wo können auch die, die sich mit dem alten ITIL auskannten oder auskennen
und die es auch gut finden, die es genutzt haben, wo finden die sich denn am ehesten wieder?
Also wo hat ITIL auch wichtige Dinge beibehalten?
Also eben, was ja sicher…
Wenn man mal bleibt, ist der Name. Das ist mal das Einfachste.
Das ITIL ist sicher noch das Gleiche.
Ich denke auch, wie es auch alles jetzt so beschrieben ist.
Ich denke, dieses Streben nach eben besserer Zusammenarbeit mit dem Business,
diese Einstellung, die es da braucht, diese Serviceorientierung,
diese Fokussierung eben auch auf das Wesentliche, das ist gleich, ist eigentlich immer noch…
Genau gleich da.
Es hat natürlich sehr viele neue Definitionen dabei.
Die Definition von, was ist ein Service, was ist Value, hat man leicht adaptiert,
aber das ist auch noch ziemlich ähnlich, wie es früher gestanden hat.
So, jetzt haben wir ja den Titel DevOption ITIL wieder Freunde.
Und wir hatten ja zu Anfang gesagt, dass es schon so ist,
dass sich durch ITIL in einer vielleicht auch falschen Anwendung Bürokratie herausgebracht,
gebaut hat, Silo-Denken herausgebaut hat.
Das hat dazu geführt, dass sich Firmen und Unternehmen zu anderen Konzepten hingewendet haben,
eben unter anderem DevOps, aber auch nicht alleine.
Wie würdest du das einschätzen?
Würde man heutzutage, wenn man quasi bei Null anfängt, wenn man einsteigt,
würde man dann sagen, okay, ITIL 4 reicht als Framework aus oder auch als Einstieg aus,
um sich den aktuellen Problemen zu widmen?
Also braucht man dann DevOps überhaupt noch, diese Bewegung, von der du vorhin gesprochen hast?
Ja, ich glaube, DevOps ist sicher ein mustergültiger Value-Stream,
den man jetzt eigentlich im Vorfeld, eben jetzt schon ein paar Jahre,
bevor es die neue Version da ist, eigentlich aktiv auch gelebt hat
und auch gesehen hat, was das für Effekte hat.
Eben, man hat natürlich im Zusammenhang mit DevOps sehr viele Mythen hochgezogen,
dass jetzt DevOps ist dann gleich NoOps, das heißt, man braucht eigentlich gar keine Operation mehr,
weil alles automatisiert ist, es läuft alles und in der Entwicklung wird dann auch alles wieder gefixt
und gelöst, damit es läuft.
Das ist wirklich ein Mythos.
Es gibt sehr viele Aktivitäten, die in welcher Konstellation auch immer,
ob das jetzt eine DevOps-Konstellation ist oder noch eine klassische,
die werden nach wie vor auch in Zukunft gebraucht werden.
Ich glaube sehr daran, dass diese DevOps-Bewegung wirklich was verändert hat,
dass diese Graben zwischen Entwicklung und Betrieb da zu einem großen Teil zugeschüttet hat werden können.
Aber wegen dem werden diese Aktivitäten und diese Praktiken, die man dann auch braucht,
rundherum um diesen, sage ich mal, Entwicklung, Test, Release, Deployment-Stream,
werden nach wie vor gebraucht.
Das wird notwendig sein.
Und man kann das im Prinzip eigentlich in diesem gleichen Mindset,
kann man so Value-Streams dann auch ausweiten auf andere Themen.
Und da kann E-Till, kann dazu ein guter Fundus sein.
Ich denke, dass sich das dort wirklich ergänzt.
Weil eine große Errungenschaft, die DevOps wirklich hat,
ist diesen Graben zwischen Entwicklung und Operation zuzukippen.
Es gibt aber noch andere Gräben, auch noch in der Organisation.
Und der größte ist ja immer noch zwischen Business und IT.
Den hinzubekommen.
Ja, okay.
Aber ich habe dich so verstanden.
Also erst mal den Graben zwischen Business und IT.
Da ist E-Till, denke ich, oder deiner Aussage nach,
das würde ich unterschreiben, in der neuen Version,
ein guter Einstieg oder bietet gute Hinweise.
Gerade auch mit der Idee Co-Creation oder Value Co-Creation.
Richtig?
Ja, das war ja immer schon die Absicht.
Ich bin auch nicht naiv zu glauben, dass jetzt dann alle Probleme in Zukunft gelöst sind.
Diese Absicht.
Solche Sachen in den Griff zu bekommen und besseres Verständnis zu bekommen,
das wird auch mit der Version 4 noch die eine oder andere Hürde nehmen.
Genau gleich, wie ich überzeugt bin und jetzt mittlerweile auch in verschiedenen Orten feststelle,
dass mit dem Grundgedanken von DevOps alleine diese Zusammenarbeit auch nicht überall
wirklich so harmoniert, wie man sich das eben gerne vorstellt.
Also die Probleme liegen nicht in der…
Denn Frameworks, die liegen nach wie vor eigentlich in der Kultur,
insbesondere auch im Leadership, im Vorleben, in den Verhaltensweisen, in der Organisation.
Und daran müsste man eigentlich arbeiten.
Und dann sind die Frameworks dann Unterstützungshilfen.
Also das Framework alleine wird es nicht schaffen.
Das bin ich überzeugt.
Wenn ich jetzt mal aus meiner DevOps-Sicht heraus die Idee hätte zu sagen,
okay, jetzt gibt es eine neue ITIL-Version, die scheint agiler zu sein,
oder ist agiler, hat auch das als Überschrift für sich ja auch gewählt.
Könnte man also im Prinzip ITIL 4 nutzen, um auch den Betrieb einfach mal in die Richtung zu bringen
und sagen so, Mensch, ITIL 4 ist jetzt agil, ganz plattformuliert, jetzt müsst ihr es auch werden.
Also bietet der ITIL 4 eine gute Möglichkeit, auch agile Gedanken,
agiles Gedankengut in den Betrieb reinzubringen, quasi über den Umweg-Framework?
Ja, also das Wichtigste…
Das Wichtigste ist wirklich, sage ich mal, diese Leitprinzipien.
Diese sieben Leitprinzipien, die gehören groß geplottet, ausgedruckt in jedes Betriebsbüro rein,
in jede Entscheidungsfindung herangezogen, bei jedem Design mit überlegt,
wenn es darum geht, was zu bauen.
Also es ist diese Grundhaltung, die muss man irgendwie den Leuten vermitteln können.
Okay.
Und mit dem Lesen vom Buch alleine ist es ja wahrscheinlich nicht getan.
Die Ausbildung wird hoffentlich in Zukunft mehr darauf Wert legen, solche Werte in den Fokus zu bringen,
also dass man die Leute natürlich schult, aber die Schulung alleine macht die kulturelle Veränderung nicht statt.
Letztlich muss es ein klarer Wille sein von jeder Organisation, von einer IT-Organisation,
wie positionieren wir uns in der Organisation, welche Werte vertreten wir?
Und dann gibt es nicht Werte für die Entwicklung oder Werte für den Betrieb,
sondern es sind allgemeine Werte, die hoffentlich abgestimmt sind mit den Werten des Gesamtunternehmens.
Und hier, das neue ITIL hat hier konkrete Inhalte jetzt mal so formuliert,
die kann man übernehmen und die kann man auch an die eigene Wortwahl dann noch anpassen.
Aber von daher ist sicher dort mal der Samen gesät,
dass es so etwas geschehen kann.
Also ich finde das interessant, ich musste eben ein bisschen schmunzeln.
Erst du sagtest, die Guiding Principles ausdrucken und an die Wand hängen,
dann könnte man sie wahrscheinlich neben das Agile Manifest hängen,
was ja auch an vielen Wänden hängt in den Büros.
Und wenn da noch Platz ist, kann man die so nebeneinander hinhängen
und dann wird man feststellen, dass das eben allein nicht ausreicht.
Das hast du ja auch gesagt.
Das heißt, auch bei agilen Teams, wo ich unterwegs bin, da hängt es auch an der Wand.
Vielleicht nicht mal das Agile Manifest.
Aber doch zumindestens auch mal so gewisse Prinzipien von Scrum,
die Scrum-Werte zum Beispiel.
Und trotzdem wird es noch nicht gelebt.
Und das reicht ja auch nicht, die Schulung zu besuchen.
Es reicht auch nicht, das Poster aufzuhängen.
Aber es ist ja vielleicht mal ein erster Schritt, auch zu sagen,
so, das sind jetzt unsere Leitlinien, weil das ist das,
was ich versuche in meinen Scrum-Schulungen immer rüberzubringen.
Ich lege Wert drauf, das Agile Manifest zu erklären,
die agilen Prinzipien zu erklären, die Scrum-Werte zu erklären,
weil das natürlich auch…
Das ist das, was ich mache.
Die Unklarheit nachher über Prozesse oder Aktivitäten immer hilft.
Also man kann immer wieder gucken,
aha, wir haben jetzt die und die Frage, linksrum oder rechtsrum,
dann lass uns doch mal das Agile Manifest anschauen
oder die agilen Prinzipien.
Was würden wir denn mit seiner übergeordneten Sicht
auf diese Frage antworten?
Okay, da gehen wir eben mal den Weg linksrum.
Also diese Guiding Principles, glaube ich, ist dann auch was Neues.
Gab es so etwas vorher noch nie in ITIL?
Eben.
Diese Guiding Principles,
die sind ja vor allem eben jetzt ein bisschen abgeleitet
und ein bisschen gestrafft worden aus dem ITIL Practitioner.
Das ist ja das Buch, das so zwischen, sage ich mal,
ITIL 4 und ITIL 3 herausgekommen ist.
Und dort haben sehr viele, sehr viele Bekannte
und auch hochgeschätzte Autoren haben dort wirklich jetzt auch versucht,
all diese Sachen, die man eben vermisst hat
oder die zu wenig klar zum Ausdruck gekommen sind,
hier dort zu vereinen.
Und in der Form,
in der Form gab es das.
Es ist zwar immer sehr viel im Prosa-Text beschrieben gewesen,
aber so richtig herausgelistet, was kulturelle Werte sind,
wie wichtig eben diese Einstellung, dieses Verhalten,
diese Zusammenarbeit ist.
Und das mit Grundsätzen untermauert,
das hat es vorher nicht gegeben.
Und ich denke da auch, was man mit dem Practitioner,
das war ja auch ein bisschen abgekupfert,
vielleicht aus diesem agilen Manifest,
ja, dass man so gemeinsam,
dass man so gemeinsame Werte irgendwie mal auflistet.
Und das hat jetzt hier auch Niederschlag gefunden.
Und ich finde das gut.
Das hilft letztendlich eben auch so ein bisschen Orientierungshilfe.
Weil diese Leiblinien, Leibprinzipien,
die sollten unabhängig sein,
ob wie jetzt die Organisationsstruktur aufgestellt ist,
was für neue Ziele, wie die Strategie sich ändert.
Sondern die sollten wirklich eine Grundhaltung zum Ausdruck bringen.
Ja, und vor allen Dingen, wenn man das wirklich schafft,
dass man die eben nicht nur an die Wand hängt,
sondern dass man sie auch,
auch diskutiert, erarbeitet
und für sich daraus konkrete Dinge ableitet,
also für das eigene Team, für das eigene Unternehmen,
dann wird es ja auch greifbar.
Weil sonst ist es ja genauso wie Unternehmensvisionen,
die eben in einem Elfenbeinturm
von der Strategieabteilung entwickelt werden,
die kriegst du auch nicht transportiert an die Mitarbeiter,
weil sie einfach da überhaupt gar keinen Bezug zu haben an der Stelle.
Und man muss sie auch immer wieder zurate ziehen
und das eigene Tun ein bisschen hinterfragen.
Bringt das jetzt noch einen Mehrwert?
Ist es transparent?
Ist es transparent für alle?
Und dass man wirklich diesen Fokus nicht aus dem Auge verliert.
Das ist sicher.
Wir waren ja noch bei der Diskussion
DevOps und ITIL wieder Freunde.
Und wenn ich das mal so ein bisschen zusammenfasse,
die letzten 35 Minuten so,
dann waren es zwar keine Freunde,
weil ITIL keine Antworten hatte auf das,
was DevOps adressiert hat,
wo DevOps ja auch ein bisschen Pionierarbeit geleistet hat.
Aber du würdest heute sagen,
ITIL hat quasi diese Lücke geschlossen
und jetzt können beide in friedlicher Koexistenz,
helfen, Dinge zu verbessern.
Also sprich, man sollte schon schauen,
dass man das, was die DevOps-Bewegung
deiner Ansicht nach bewegt hat
und welche Wege sie beschritten hat,
dass man das einfach jetzt mit ITIL gemeinsam weiter voranbringt.
Ja, auf jeden Fall.
Also ich glaube, die Grundlage dazu ist jetzt eigentlich geschaffen.
Und ich würde auch sagen,
das wäre jetzt komplett falsch,
dass man sagt, okay, jetzt hat DevOps diese Lücke geschlossen,
und jetzt gehen wir wieder zurück zu ITIL.
Ich denke, diese Bewegung, die muss man aufrechterhalten.
Und es ist nicht die Frage,
ob jetzt DevOps oder ITIL oder Scrum oder sonst was.
Letztlich muss der Spirit,
der muss in der Organisation rüberkommen.
Und die Frameworks und die Methoden,
die existieren für sich ja nicht alleine.
Und ich glaube jetzt,
es sind viele Leute,
die vielleicht dem ITIL den Rücken gekehrt haben
und das irgendwie als abgeschlossen betrachtet haben.
Die müssen vielleicht ein bisschen über den eigenen Schatten springen
und vielleicht doch mal schauen,
ob es dort vielleicht Antworten gibt,
die sie mit der Methode DevOps alleine nicht lösen können.
Und umgekehrt muss auch jetzt diese
vielleicht noch eingeschorene ITIL-Gemeinde
auch nicht das Gefühl haben,
wir brauchen jetzt kein DevOps mehr,
wir können das Ganze wieder stoppen,
weil wir jetzt wieder eine Antwort haben.
Für die ganze agile Fragestellungen,
die wir haben aus dem Markt oder aus der Organisation.
Ich denke gerade die DevOps-Bewegung hat eben gezeigt,
dass es machbar ist.
Und es ist ein sehr guter Case,
der mit diesem Value Stream jetzt eigentlich dort gebaut wurde.
Jetzt muss man eben auch den Mut haben,
weitere Value Streams nach dem gleichen Muster so zu bauen,
dass es eben auch die Zusammenarbeit
der beteiligten Organisationen,
die sich da auch noch weiter vereinfachen,
die sich da auch noch weiter vereinfachen,
die sich da auch noch weiter vereinfachen,
und nicht diese Silo-Mentalität weiterhin fördert.
Ich weiß auf jeden Fall für mich,
dass ich das, was du eben gesagt hast,
vollkommen unterschreiben würde.
Ich habe in meinen DevOps-Schulungen
eigentlich keine Antwort geben können.
Also zumindest nicht auf der Basis der Unterlagen,
die ich verwende.
Und das sind ja hoch angesehene Unterlagen,
wo wir wirklich konkret auf die Frage eine Antwort geben konnten,
wie organisiere ich jetzt den Betrieb in DevOps.
Das war eine relativ allgemeingültige,
bequeme,
bequeme Bilder und Übersichten.
Aber konkret die Frage,
wie lasse ich jetzt Inzidenz laufen?
Also wie kriege ich denn selbst organisierte Teams,
die quasi nicht nur Entwicklung,
auch Betrieb machen sollen,
wie kriege ich das hin,
dass die eben in einem Inzidenz-Prozess mitspielen?
Weil die Erwartung kann ja nicht sein,
dass alle Teams jetzt 24-7 erreichbar sind.
Also ich brauche ja schon noch ein paar Dinge,
die genau in ITIL ja beschrieben sind.
Und da habe ich keine Antworten in den Unterlagen gehabt.
Natürlich habe ich praktische Erfahrungen
ausprobiert oder getan.
Aber wie gesagt,
DevOps hat auf solche Fragen keine Antworten gehabt
und die gab es immer im IT Service Management,
gab es immer im ITIL.
Und das ist für mich schon ein wichtiger Punkt.
Also es hat jetzt in dem Buch,
dem ITIL Foundation,
so anschauliche und auch Beispiele im Appendix,
wie so Value Streams jetzt eben aussehen könnte.
Aus beispielsweise für so einen
Incident Resolution Stream.
Und das Gute eben daran ist,
dass es eben nicht ein Prozess alleine ist,
sondern da gibt es jetzt eben Praktiken
aus dem Service Desk Umfeld.
Es gibt Praktiken aus dem Configuration Management,
aus dem IT Asset, aus dem Continual Improvement.
Also man kann so anschaulich dann auch,
wie es da beschrieben ist,
so einen Value Stream dann bauen.
Das sind natürlich auch wieder Beispiele
und dürfen nicht so eins zu eins übernommen werden.
Aber einfach nur zur Illustration,
dass dieses Konzept,
das man eigentlich mit DevOps da gebaut hat,
dass man das jetzt mit den verschiedenen Praktiken,
die sind ja übrigens jetzt von den 26 Prozessen
auf 34 Praktiken angewachsen,
dass man die eben so verwenden kann.
Aber es hat eben auch jetzt Themen drin wie
Architektur Management,
es hat Themen drin wie Business Analyse,
es hat Themen drin wie,
wie Service Design inklusive Design Thinking,
wie User Experience, wie Customer Experience.
Das sind so Themen,
die jetzt viel, viel mehr eigentlich auch
in die Welt der Entwickler hineingreifen.
Und von daher ist es eine Quelle mehr,
die man nutzen kann,
ohne dass man jetzt für sich alleine den Weg suchen muss.
Und es hilft ungemein,
den eigenen Kopf anzuschalten,
selber nachzudenken
und diese Beispiele aus dem Appendix zu nehmen
und sie eben sich selber weiterzuentwickeln.
Am besten Business, Entwicklung und Betrieb zusammen.
Richtig?
Genau.
Genau.
Genau.
Also dort,
ja eben auf der Seite vom Business,
das habe ich ja gesagt mit diesen Co-Creation,
da ist einiges jetzt neu drin.
Dort könnte man auch in Zukunft noch mehr machen.
Also ich sage das jetzt gerade bewusst,
weil ich weiß,
ich bin jetzt ja auch vor allem
mit dem Business Relationship Management Institute
in Zusammenarbeit,
wo man wirklich diese strategische Partnerschaft
noch viel, viel präziser
und noch viel, viel direkter einfordern muss
oder auch sicher arbeiten muss.
Und das ist dann sicher auch noch eine Entwicklungsmöglichkeit,
die ITIL vielleicht mal in der Version 5 noch hinkriegt.
Na ja,
das ist doch gut.
Ob wir die noch erleben?
Fragezeichen.
Aber gut.
Ja,
in unserem Berufsleben.
Wir werden sie vielleicht nochmal erleben.
Also alle sieben Jahre kommen neue Versionen.
Also das heißt,
Ja,
okay.
Wenn du jetzt dann mit 26 noch dabei bist,
dann,
ja,
dann wirst du vielleicht die Fünf erleben.
Also ich will in 2026,
könnte ich mir schon vorstellen,
noch zu arbeiten.
Ich weiß nicht,
wie das bei dir ist.
Ja,
ich,
ja,
ich,
ja,
ja,
ja,
ja,
ja.
Ja,
ich glaube,
da,
wenn man mal mit diesem Virus investiert wird,
dann kann man sich nie lösen.
Ja,
das wird man über alle Phasen,
die noch kommen,
da mittragen.
Ja,
und ich werde mich sicher auch immer wieder ein bisschen äußern zu den Themen.
Das ist doch gut.
Also dann vereinbaren wir jetzt schon einen Termin,
Podcast in 2026 im Sommer.
Du sitzt auf irgendeiner Alm und ich sitze irgendwie,
weiß ich nicht,
am Flüsschen und dann reden wir über ITIL 5.
Sehr gerne.
Gut.
Ja,
Also ich fand, das war eben schon mal
eine gute Überleitung zu einem
Schlusswort. Hast du
noch irgendwas, was du zu dem Thema
DevOps und ITIL wieder Freunde
noch sagen wolltest?
Ja, nein. Ich denke jetzt,
die Hände ausstrecken,
sie einander geben
und dann
anfangen, sich wieder zu umarmen. Das ist
vielleicht das
Schlusswort, das ich sage. Ich denke,
die Grundlagen sind dazu da. Jetzt müssen
es die Menschen nur noch tun.
Jawohl, das ist doch perfekt.
Das heißt, wir nehmen den Schlusssatz
DevOps und ITIL wieder Freunde
Ausrufezeichen und
reicht euch die Hände, vertragt
euch und dann würde ich
sagen, ich bedanke mich, Martin, für den
tollen Podcast, für die
wirklich tollen Aussagen und auch für das
friedvolle Ergebnis.
Vielen Dank dir.
Vielen Dank.

https://podcasters.spotify.com/pod/dashboard/episode/e29ihst

Digitalisierung wird die Arbeitswelt verändern bzw. tut sie das schon heute. Mein Beraterkollege André Claassen hat mich zu diesem Thema in sein Podcast eingeladen. WIr sprechen u.a. über die Frage „Wie überlebe ich in der Digitalisierung oder besser gesagt, wie werde ich und mein Team in der Digitalisierung erfolgreich?“

In dieser Podcast-Episode interviewt André Klaasen den IT-Experten und Business Coach Dierk Söllner, um zu erörtern, wie sich die Rolle und Arbeitsweise in der IT-Branche im Zuge der Digitalisierung verändert. Sie besprechen die Notwendigkeit für IT-Spezialisten, sich neuen Methoden und Technologien gegenüber zu öffnen, die Bedeutung von Kundenorientierung und einer Beratermentalität, sowie die Anpassung an agile Arbeitsweisen. Darüber hinaus wird betont, wie wichtig es für IT-Mitarbeiter ist, aus der Komfortzone herauszutreten und sich kontinuierlich weiterzuentwickeln, um in der sich schnell verändernden digitalen Landschaft erfolgreich zu sein.

Inhalte

• Die Veränderung der IT-Branche durch Digitalisierung
• Bedeutung von IT-Service Management und agiler Organisationsentwicklung
• Dirk Söllners Weg zum Solopreneur
• Coaching-Ansatz in der IT-Branche
• Herausforderungen und Lösungsansätze für IT-Abteilungen in der digitalen Transformation
• Die Rolle von Cloud-Technologie und deren Einfluss auf IT-Kompetenzen
• Bedeutung von Kundenorientierung und Beratermentalität in der IT
• Entwicklung von Teams und Einzelpersonen in der IT
• Wichtigkeit von Offenheit und Anpassungsfähigkeit
• Verbindung von technischen und soft skills

Transkript

Hallo, ich freue mich sehr, dass du dabei bist.

Keine Angst, du bist nicht im falschen Podcast. Ich habe in diesem Podcast auf der anderen Seite gesessen und bin als Gast von André Klaasen interviewt worden. Insofern freue ich mich jetzt hier diese Folge wiedergeben zu können. Ich stelle mir schon seit längerem die Frage, wie sich die Digitalisierung auf die Arbeit in der IT auswirkt.

Während zu Beginn die Technikkompetenz und Affinität eine unbedingte Rolle spielte, war die Arbeit in den letzten Jahren stark durch das IT-Service- Management geprägt. Aber reicht Prozess und Technikwissen aus für die Umbrüche, die jetzt vor uns liegen oder die auch gerade passieren? Um dieser Frage nachzugehen, habe ich mit dem IT-Experten und Business Coach Dirk Söllner gesprochen. Ich habe Dirk gefragt, wie überlebe ich in der Digitalisierung oder noch besser, wie werde ich und mein Team in der Digitalisierung wirklich erfolgreich? Lass dich von einem spannenden Gespräch überraschen und jetzt geht es los.

Hallo Dirk, stelle dich doch kurz einmal vor. Wer bist du? Was machst du? Und was treibt dich eigentlich an? Herzlichen Dank lieber André für die Einladung und für mich auch mal interessant auf der anderen Seite bei so einem Podcast zu sitzen. Mein Name ist Dirk Söllner. Ich bin Berater, Trainer und Coach für IT-Service Management und agile Organisationsentwicklung. Ich habe im letzten Jahr mich ein bisschen mehr mit dem Thema Unternehmertum beschäftigt und bezeichne mich letztendlich seit, weiß ich nicht, seit dem letzten Jahr, seit Mitte 2018 als Solopreneur. Also ich würde mich jetzt nicht mehr als Freiberufler beschreiben, sondern als Solopreneur. Und meine Tätigkeit kann man eigentlich umschreiben. Ich tue das zumindest so mit dem mit dem Slogan. Ich mache Teams und Menschen erfolgreich. Das heißt, mein Fokus liegt auf dem Thema Coaching. Ich habe ja schon gesagt, Agiles Coaching, Agile Organisationsentwicklung. Aber für mich ist das noch ein Schritt weiter. Ich habe mich im letzten Jahr auch weiter gebildet zum Business Coach. Das heißt, ich versuche mehr und mehr wegzukommen von der Berater-Schiene, von jemandem, der genau weiß, wie es geht und das dem anderen nur noch mal kurz erklären muss und dann funktioniert das. Weil meine Erfahrungen sind eben, dass es eben dann genau nicht funktioniert, weil es doch sehr viel mehr Zeit braucht, um nachhaltig Dinge zu verändern. Insofern bin ich eben verstärkt mit einem Coaching-Ansatz unterwegs. Das heißt, also selbst in Fachaufgaben, wo ich fachlich als Experte gerufen werde, versuche ich mittels eines Coaching-Ansatzes Unternehmen zu verändern, Teams zu verändern und Menschen zu helfen, einfach ihren Job besser zu machen. Oder auch vielleicht einen neuen Job überhaupt mal zu verstehen.

Das finde ich wirklich interessant, dass du sagst, ich komme eigentlich aus der klassischen Beratung. Ich habe jahrelang, also so so so so so wirkt das auf mich meine Fachkompetenzen sozusagen auf dem Punkt weitergegeben.

Aber echte Nachhaltigkeit, echte Wirksamkeit braucht einen anderen Ansatz. So so so habe ich das gerade verstanden. Das heißt, der Coaching-Ansatz geht eine Stufe weiter und sagt nicht hier sind die und die Lösungen oder die Patentrezepte, sondern die Lösung müssen wir eigentlich erst mal arbeiten. Die liegt gar nicht so offensichtlich auf den Tisch.

Ja, beziehungsweise, ja, beziehungsweise es gibt immer, denke ich finde, gibt es in der heutigen Zeit immer nur sehr, sehr individuelle Lösungen. Das heißt, natürlich kann ich mir überlegen, in einem Unternehmen anders zu arbeiten, indem ich irgendeinen Framework nehme, auch als Basis. Meine Erfahrung ist eben genau, dass dieses Framework dann von den Leuten vielleicht erst mal auch abgelehnt wird, weil es irgendein Framework ist, weil man auch denkt, na ja, habe ich bisher nicht gut gearbeitet.

Das heißt also, ich sage mal, die Mischung, meine Mischung, mein Angebot an meine Kunden ist eben nicht nur Coach zu sein. Gibt ja auch genug Coaches, die quasi fachlich wenig oder gar keine Ahnung haben, die dafür sehr gut im Coaching sind. Er sieht wirklich nur Coaching betreiben als Punkt oder eben die andere Seite quasi der Medaille Experten, die sich in irgendwelchen Prozessen und jahrelang in irgendwelchen Frameworks, Scrum, beispielsweise auskennen. Und ich bin letztens eines dazwischen. Ich habe schon das Fachwissen über verschiedenste Frameworks im IT-Umfeld, aber ich komme eben mit einem Coaching-Ansatz und an vielen Stellen bin ich mittlerweile bei meinen Kunden auch nicht nur eben als Berater da, sondern die sagen eben ganz klar, bitte Coaches meine Leute. Das heißt also, die meine Coaches wissen zwar, dass ich das Fachwissen habe und ich lasse das manchmal auch als Tipp rein spielen. Aber ansonsten ist es vom Vorgehen eben eher Coaching, das heißt, die Leute zu befähigen, selber die Lösung in sich zu finden. Also dafür brauche ich nicht immer einen Framework, da brauche ich einfach nur manchmal oder häufig einen gesunden Menschenverstand und das versuche ich mit meiner, mit einem Coaching Ansatz rauszuarbeiten.

Und einen Außenblick und natürlich die Fähigkeit auch die richtigen Fragen zu stellen.

Ja, richtig.

Ich starte direkt mal in das Thema ein. Wir hatten uns ja kurz vor dem Podcast unterhalten und du kommst ja oder du hast dich ja jahrelang, du hast es schon eingangs erwähnt in der IT bewegt und die IT steht. Das ist so ein bisschen unsere These vor einer Veränderung. Wir haben überlegt, wie dramatisch ist es, fallen IT-Abteilungen weg, wird IT künftig ganz anders aussehen, auch in dem Kontext der Digitalisierung. Und der Titel dieses Podcasts heißt ja auch, so überlebst du die Digitalisierung. Ist das wirklich so schlimm, Dirk, dass man alles über den Hausen werfen muss, um zu überleben?

Also ich sage mal ja und nein.

Warum ja und nein? Natürlich glaube ich, dass man auch in der heutigen Zeit manche Dinge ein bisschen mehr auf den Punkt bringen muss. Manche würden auch vielleicht sagen, ein bisschen übertreiben muss, um Gehör zu finden. Also insofern würde ich mal sagen, ist es vielleicht nicht ganz so schlimm, wie das manchmal dargestellt wird. Auf der anderen Seite glaube ich schon, dass die IT wirklich vor sehr, sehr großen Herausforderungen steht. Und ich erlebe das ja in meiner Tätigkeit, dass man eben schon sieht, wie auf der einen Seite Mitarbeiter absolut verunsichert sind. Wie geht es mit mir und meinem Unternehmen weiter und dass auch Führungskräfte, wo man eben auch sieht, die Führungskräfte verunsichert sind.

Die zeigen das vielleicht nicht so, aber die ganzen Dinge, die sich verändern, die sind wirklich massiv und die betreffen die IT massiv. Und manchmal kriege ich auch so ein paar Einblicke in Details und es gibt auch den einen oder anderen Kunden, wo man auch sieht, dass sich die Zahlen, also die betriebswirtschaftlichen Auswirkungen dann auch verändern. Also kurzum, ich glaube schon, da bin ich sicher, dass die IT vor großen Herausforderungen steht. Das war vor ein paar Jahren auch so. Also das wird vielleicht gar nicht anders. So ist auch vielleicht die Wirtschaft. Aber das Thema Digitalisierung beispielsweise und Disruption, das ist schon sehr, sehr präsent. Und das ist eigentlich schon eine Bedrohung und wir sprechen ja auch einzelne Personen an. Ich glaube, dass es auch eine Bedrohung ist für diejenigen, die diese Veränderung nicht mitgehen, weil sie es nicht wollen oder weil sie es einfach auch nicht können.

Versuchen wir das mal konkret zu machen, wenn wir jetzt mal auf eine IT-Abteilung schauen. Was sind aus deiner Sicht Veränderungen in Arbeitsweisen, in Kompetenzen, die jetzt anstehen, auch in Folge der Digitalisierung oder einfach auch durch Veränderungen, durch Technik und allgemeine Trends? Ja, also das kann man da auch ein bisschen aufteilen, verzehnt in das Thema Technik, also Fachlichkeit und dann eben Arbeitsweise. Wenn ich auf die Fachlichkeit mal schaue, dann glaube ich, dass das ganze Thema Cloud eine andere Art, beispielsweise auch infrastruktur bereitzustellen, dass das eben die Fachlichkeit verändert und dass damit viele Positionen, ich sage mal ein IT-Administrator oder andere Dinge, dass solche Aufgaben eben nicht mehr im Unternehmen stattfinden müssen, zwangsläufig, sondern dass sie eben nach außen gegeben werden. Natürlich lebt die IT auch schon seit Jahren davon, Dinge nach draußen zu geben. Aber hier reden wir darüber, dass auch wirklich Jobs oder Aufgaben gefädert sind, die gefühlt quasi immer im Haus sein mussten. Ich musste meinen Rechenzentrum im Keller stehen haben und dann muss sich auch Leute haben, die das bedienen. Das ist eben nicht mehr der Fall. Also, Fachlichkeit, glaube ich, verändert sich gerade einiges und diese fachliche Veränderung führt sicherlich auch dazu, dass auch Arbeitsweisen sich verändern müssen. Und da verstehe ich, dass sich auch mehr und mehr, dass sich nicht nur die IT verändert oder verändern muss, sondern auch dass das Business sich anders organisiert. Was meine ich damit? Also konkret für Leute, die in der IT sind, wie gesagt, fachlich müssen sich, verändern sich Dinge relativ stark. Und was die Arbeitsweise eingeht, ist einfach, ich sage mal so, wir gehen vielleicht, wenn man es auf den Punkt bringt, wir gehen weg von einem Spezialisten tun. Wir haben in der Vergangenheit immer Spezialisten gebraucht und diese Spezialisten, die Brands aus dem Phoenix Project beispielsweise, die waren hoch angesehen, weil sie das Spezialwissen hatten, dann hat man auf die gewartet. Man war zwar als Business nicht zufrieden damit, aber man musste warten. Die Kollegen mussten darauf warten. Und diese Spezialisten, denke ich, die werden sozusagen aussterben. Diese Spezialisten, wir brauchen das Spezialwissen noch, arbeiten diese Spezialisten, müssen anders arbeiten. Sie müssen sich in Teams einbringen und sie müssen auch, meiner Meinung nach, kundenorientierte arbeiten. Das heißt, die freischaffende Künstler, wie ich das manchmal bezeichne, Architekten, also IT-Architekten, Leute, die Konzepte sehr schön ausarbeiten. Auch die müssen, denke ich, ihre Arbeitsweise verändern, weil das Thema Konzeption lange Zeit und dann wird ein bisschen aufgebaut. All das verändert sich ja, weil die Kunden diese Lösungen schneller haben wollen und in kleineren Schritten. Also kurzum die Arbeitsweise, die das Selbstverständnis in IT

muss sich oder wird sich auch bei vielen Leuten ändern müssen, weil sie ansonsten einfach ein Problem haben, weil die Firma sie nicht mehr beschäftigen kann, meiner Meinung nach.

Das sind diese beiden Spannungsbögen, also Fachlichkeit und Arbeitsweisen, die sich eineinander bedingen.

Und jetzt wird es ja spannend, wie kann so eine Veränderung denn gelingen? Also angenommen, ich arbeite als Atmen oder als IT-Architekt weiter wie bisher auch. Ich merke aber irgendwie verändert sich was. Wie kann die Veränderung gestaltet werden, dass das also nicht in einem Big Bang, in einem Chaos oder in einer sehr unzufriedenen Situation endet?

Auch da würde ich sagen, wieder so eine zweigeteilte Antwort oder eine zweiteilige Antwort. Ich denke, auf der einen Seite müssen die Mitarbeiter, diese Spezialisten, von denen, wie ich jetzt gerade spreche, sich öffnen. Ihnen muss bewusst werden, dass sie so nicht weiterarbeiten können, dass Dinge sich verändern müssen, dass man einfach aus der Komfortzone rauskommt. Wie alle, die wir an uns arbeiten, die wir uns verändern wollen, wissen, dass es schwierig ist, eine Komfortzone zu verlassen. Also der Punkt ist eben ganz klar,

dass Bewusstsein bei den Mitarbeitern muss da sein. Und dann und das halte ich fast noch für den wichtigeren Punkt Führungskräfte, das Management. Das heißt, die Außenwelt muss einfach verstehen, dass die Leute, die sich einer Veränderung vielleicht gefühlt oder auch nicht nur gefühlt, sondern auch aktiv widersetzen, dass sie das nicht tun, um jemanden zu ärgern. Sprich, die Aufgabe von Führungskräften ist aus meiner Sicht der Punkt ganz klar, dass es eine neue Herausforderung für das Management, für die Führungskräfte, die diese Mitarbeiter befähigen müssen, diesen Weg mitzugehen. Und dazu gehört mindestens erst mal das Verständnis darum, dass das eben erst mal so ist, dass das eine menschliche Reaktion ist auf Veränderung, also erst mal mit Mitwiderstand oder Ablindung zu reagieren. Und gerade gestern war ich auch wieder in einem größeren Workshop, wo auch zwei Leute dabei waren, die waren jetzt nun mal älter. Also das mag ein Zufall sein, das ist aber nicht immer aufs, oder es ist jetzt nicht immer all das abhängig, aber da waren zwei Ältere Mitarbeiter, die ganz offen nichts dagegen. Sie haben gesagt, haben aber immer wieder Argumente gefunden haben, warum eine neue Arbeitsweise vielleicht doch gerade nicht so passt. Und ich finde das gut, wenn Sie das sagen, weil es muss nicht alles gut sein, was neu ist. Also, die brauchen schon Leute, die kritisch sind, die Dinge hinterfragen oder auch infrage stellen. Aber die Frage ist eben, mit welcher Intention und

passiert das und mit welcher Konsequenz? Also irgendwann müssen diese Leute, denke ich, sich überlegen, ob sie dann eben noch an der richtigen Stelle sind, wenn sie sich wirklich auf Dauer und permanent einer Veränderung widersetzen. Und um das abzuschließen, das ist Aufgabe von Führungskräften, eine neue Aufgabe von Führungskräften, vielleicht auch da wirklich Verständnis zu haben und die Leute mitzunehmen und auf den neuen Weg zu führen.

Und das sind ja Dinge, die man in der Führung, ich war ja lange Zeit auch Führungskraft zwar kennt, aber wo man sozusagen nicht immer Kompetenzen hat, weil man oft in der in der funktionalen fachlichen Führung steht. Dort gibt es das Tagesgeschäft, das bearbeitet werden muss. Aber eine Veränderung von einer Arbeitsweise A hin zu einer Arbeitskultur, vielleicht auch B, ist ja nochmal etwas, was auch für Führungskräfte ungewohnt ist. Und kommst du da ins Spiel? Also ja, stelle ich.

Geschlechtene Fragen. Ja, leidschung. Wir bringen mal hin. Also ich komme dann anders herum. Ich fange mal einen Schritt weiter vorne an, bevor ich die Frage bin, ob ich ins Spiel komme oder wie ich ins Spiel komme. Das, was du sagst, vollkommen richtig, die Führungskräfte müssten dazu aber auch erst mal verstehen und wissen, ob sie denn bereit sind für diese Veränderung. Das heißt, das, was wir beide jetzt sehen, eine Außensicht als ehemalige Führungskräfte. Das ist ja eine Einschätzung, die bei einer Führungskraft, die noch im Hamsterrad ist, die noch in der in der gesamten Umgebung ist, da vielleicht noch gar nicht vorhanden ist. Das heißt, insofern, wenn Führungskräfte da sind, die das verstanden haben, dass sie sich verändern müssen und dass das die neue Herausforderung ist, dann bin ich quasi automatisch im Spiel. Ich oder anders, also gibt ja auch andere Coaches. Und wo ich häufiger aktuell von meiner Einschätzung ja noch ins Spiel komme, ist, dass ich den Führungskräften, die das noch nicht verstanden haben, das irgendwie näher bringe. Also ist vielleicht nicht unterjubel, aber dass sie eben durch meine Arbeit sehen und merken, hey, das, was da an Schwierigkeiten ist, ich könnte mal überlegen, ob ich auch was dazu beitragen kann. An mir, an meiner Arbeit, an meiner Fähigkeit zu selbst Reflektion. Und das ist das, was mir an meiner Arbeit eben so Spaß macht. Du hast ja vorhin auch gefragt, was treibt mich an? Mich treibt es an, andere Menschen erfolgreich zu machen. Das hatte ich auch eingangs gesagt. Und wenn dann die Führungskräfte, wenn ich sehe, dass sie wirklich sich selbst reflektieren, beispielsweise, dann treibt mich das an, dann befriedigt mich das. Das ist das, wo ich dann, ja, ich sage mal, abends nach Hause, gehen sie auch, hey, das war wieder ein Schritt vorwärts. Mehr Verständnis auch zwischen Führungskräften und Mitarbeitern geschaffen zu haben, auch die Kunden. Wir haben ja über die Kunden noch gar nicht gesprochen. Auch die Kunden müssen ja etwas tun. Und häufig bin ich dann in Gesprächen oder in Arbeiten, in Arbeitsauftrag unterwegs, wo auch der Kunde mit dabei ist. Das heißt auch der Kunde. Also das Business, sage ich mal jetzt, das Business, wenn ich jetzt an Unternehmen bin, der, richtig, der interne Kunde, dann auch der muss sich verändern. Und auch das sehe ich. Und interessanterweise bin ich, gerade bin ich auf 2018 zurückgeguckt, von den Arbeitsinhalten eher quasi von der IT bezahlt worden. Das ist mal ganz einfach, ausdrückt, bin aber mehr bei den Kunden, bei den internen Kunden der IT aktiv gewesen, die einzubinden, ihnen bewusst zu machen, was es denn bedeutet, wenn jetzt die IT auf einmal agil arbeitet. Und das funktioniert ja nur, wenn der Kunde mitarbeitet. Geschaut auf die Dinge, die du machst. Die IT ändert Arbeitsweisen, geht schon in Richtung Agilität. Was aber einfacher ist, als einfach sich nur stumpf, nach einem Framework zu richten.

Ich muss ja, das heißt also die Fähigkeit der Selbstreflexion,

muss in irgendeiner Weise oder aufgebaut werden, also bei den Führungskräften, aber die Kunden müssen auch mit spielen. Das tue die nicht automatisch. Und da kommst du ins Spiel. Und unter anderem. Und dann kommt dann der fachliche Part wieder eher ins Spiel. Ich weiß, ich habe letztes Jahr in drei Projekten quasi in einer Anfangsphase hat die IT-Abteilung für sich gesagt, wir wollen anders arbeiten. Und wir haben Workshops gemacht, wo ich sowohl der betroffenen IT-Mannschaft, also dem Projektteam, dem Produktteam, als auch den betroffenen, beteiligten Kundenvertretern diese Dinge klargestellt habe, was heißt eben, was heißt kommen, was heißt kann man, was bedeutet das, welche Veränderungen treten da auf, damit sowohl die Kunden als auch die Mitarbeiter quasi entscheiden konnten, wie wollen wir arbeiten und dann sich auch entsprechend kommitten, also sich entsprechend verpflichten. Und das ist eben wichtig. Das heißt, das IT-Management hatte quasi den Auftrag an mich gegeben, weil die Aufgabe war, inhaltlich Dinge vorzustellen, die Leute insofern nicht abzuholen, das Wort abzuholen ist auch, finde ich manchmal ein bisschen überheblich, aber einfach dafür zu sorgen, dass die Leute verstehen, was das bedeutet und dass sie sagen, okay, so wollen wir arbeiten. Und nicht einfach sagen, lieber Kunde, wir arbeiten jetzt hier mit dem Scrum-Team, wir laden dich zum paar Termin an, dann gucken wir mal. Also, sondern wirklich in der Phase davor, die Beteiligten zu informieren, sie zu befähigen, eine Entscheidung zu treffen, wollen wir so arbeiten und sie auch noch bewusst zu machen, was das für sie konkret bedeutet. Unter anderem auch für den Kunden.

Kommen die Kunden gut damit zurecht mit dieser anderen Arbeitsweise? Ich frage das mal so ein bisschen provokant. Klassischen Zusammenarbeit hat man ja die IT mit irgendwas beauftragt und die dann in Ruhe gelassen und hatte auch selbst Zeit für andere Dinge. Agile Arbeitsweisen erfordern ja mehr Mitwirkungsleistungen. Wie sind da deine Erfahrungen? Also, gerade mit der Kundenseite, sich auf diese Prozesse einzulassen. Ja, meine Erfahrungen sind auch da wieder zweigeteilt. Ich gebe dir heute im anderen zwei geteilte Antworten hier. Ich mag das. Ja, es ist immer sowohl als auch, es gibt solche und solche. Das ist dann dein Berater, das kommt darauf an. Also, es gibt natürlich auch Erfahrungen, wo ich feststelle, dass der Kunde oder die Kunden, dass die Vertreter das nicht machen wollen. Oder sie ist auch nicht, es ist vielleicht erst wollen, also schon die Absicht haben, aber ihnen nicht bewusst ist, was das wirklich bedeutet. In den Fällen bin ich dann selten damit dabei, weil der Kunde sich dann eben eher zurückzieht und ich ja auch aus der IT heraus mich bei dem Kunden hier auf den Schoß setzen kann. Also, die gibt es und ich kann es keine Zahlen nennen oder keine validen statistischen Zahlen nennen, aber die gibt es. Was ich aber interessant finde, ist, dass es für mich zumindest aus meiner Sicht es genug Kunden gibt, die das verstehen und die es eigentlich auch wollen.

Ich sage dann immer, ihr könnt ja der IT, die sagen, macht das, wir erklären euch das ganz kurz, wie man es eben klassisch macht, dann darfst du aber nachher auch nicht dich beschweren, wenn was rauskommt, was du nicht bekommst. Und mit so einer Einsicht, sag ich mal, und das ist ja nichts Besonderes, das haben die Kunden ja auch erlebt, dass sie eben einfach sagen, okay, wir sehen, wir müssen oder wir wollen auch mehr mitarbeiten. Das heißt, sie haben ja auch Vorteile davon. Sie können ja viel intensiver oder viel direkter auch steuern. Die Kunden, die das verstehen, und das sind die, die ich eben häufiger kennenlerne, die sehen eben darin große Vorteile. Und wenn ich jetzt an einen speziellen Fall gerade denke,

wenn ich über eine konzerngebundene IT-Tochter nachdenke, die mit ihrer Mutter im Konzern, wie immer auch Schwierigkeiten hat, das Team, die beiden Teams, die ich da letztens ja betreut habe, wo es was auch jetzt noch weiter geht,

sind die Projekte, die intern bei den Kunden hochgelobt wurden. Auch da gab es Schwierigkeiten, aber insgesamt ist es der IT-Tochter fast schon peinlich, dass da bei den Kunden immer mit diesen Projekten geworben wird, weil die so toll laufen.

Das freut mich dann auch immer natürlich.

Also es ist spannend, weil gerade IT-Töchter haben es ja wirklich nicht einfach, zumindest in der Vergangenheit, nämlich in der klassischen Auftragnehmer-Auftraggeberbeziehung. Und wenn du sagst, wir kommen einfach durch diese stärkere Zusammenarbeit in eine ganz andere Zufriedenheit rein, dann ist das ja eigentlich genau einer der Punkte, die wichtig sind für die Veränderung. Also das finde ich schon sehr schön, eine schöne Geschichte. Ja, und für mich ist das auch nochmal interessant, weil ich ja vorhin auch gesagt habe, ich versuche mich von Frameworks oder von solchen Methoden in so ein bisschen abzuheben, die können ja nur funktionieren, wenn es Sinn ergibt. Und ich glaube, wir beide wissen auch, dass es genug tolle Projekte gibt, wo Unternehmen super toll auf Agil uns kaum umgestellt haben, wenn man mal genauer nachschaut, ist das eben nicht so. Also was ich versuche, in meiner Arbeit eben mit einer Argumentation zu kommen, die Vorteile dieser Arbeitsweise zu erläutern. Und da ist es eben so, die Kunden sehen die Vorteile und die sagen da manchmal auch, also ist mir doch egal, wie ihr das nennt. Ihr könnt das Scrum oder Kanne mal nennen, ist mir eigentlich egal Hauptsache, es wird besser und es wird dann eben entsprechend besser. Und da sind dann auch keine Methoden für die Schisten, sondern die sagen ganz klar, wie ist die Methode egal, wie ihr arbeitet, Hauptsache es wird besser. Und dann kommen wir auf den Punkt zurück,

dann ist einfach eine andere Art der Zusammenarbeit da, das was du ja auch sagtest, und das hängt nicht von Methoden ab.

Triffst du eigentlich in deinem Beratungskontext auf Methoden für die Schisten? Also ich hatte früher öfters mit denen innen zu tun. Und das war nicht immer ganz einfach, aber bei mir jetzt eher zugegebenermaßen stark im Softwarebereich. Ist das bei, oder sind die Kunden eher offen, weil ich finde, diese Einstellung Hauptsache es hilft, Hauptsache ich komme zu einer Verbesserung, die finde ich eigentlich total wichtig. Also die treffe ich immer dann an, oder die treffe ich an, weil natürlich, wenn ich als Coach unterstütze, man ruft mich ja nicht als Coach, wenn alles glatt läuft. Das heißt, meine Aufgabe ist ja, häufig Menschenbereiche zusammenzubringen. Und ich hatte ja eingangs auch gesagt, ich bin in dem Bereich IT Service Management und agile Organisationsentwicklung tätig. Wenn ich das mal zusammenführe, dann kommt das schöne Wort DevOps raus und da habe ich natürlich auf beiden Seiten. Also ganz klar, ich habe auf beiden Seiten Methodenfetischisten und wenn die dann aufeinander treffen, dann ist es ja noch schlimmer, wenn sie quasi sich über die Methode auch nochmal, wenn sie nicht miteinander reden. Also insofern ich treffe sowohl Methodenfetischisten auf der ITIL, auf der IT Service Management Seite an, wie auch auf der Agilenseite mit Scrum. Und da denke ich es dann auch dann mein Vorteil, dass ich eben beide Seiten verstehe, weil ich beide Seiten kenne. Ich kann auf beiden Seiten fachlich mitreden. Muss das aber nicht? Oder versuche das eben nicht, sondern versuche das, wie gesagt, über diesen Coaching-Ansatz hinzubekommen?

Ich glaube, auch die einzige Chance, diese Dinge aufzulösen. Denn es ist jetzt einfach zu sagen, die Methode A ist besser als Methode B, führt jetzt zu keinen Punkt. Und man kann auch nicht sagen, ITIL ist per se schlecht und Scrum ist per se gut. Es hängt so viel vom Kontext ab. Das ist so meine Erfahrung, wo bewegen wir uns gerade und was sind die Elemente, die helfen, diese herauszuarbeiten.

Ich würde gerne nochmal auf einen Punkt kurz zurückgehen.

Wir haben uns ja oft aufgeteilt in A und B. Und zu Beginn sagt es, Veränderungen wirkt ja auf Mitarbeiter und Führungskräfte. Wir hatten bei den Führungskräften gemeinsam festgestellt, eine ganz wichtige Erkenntnis ist Selbstreflexion, um in Erfinderung erfolgreich zu sein. Und bei den Mitarbeitern sagst du, die müssen sich auch öffnen. Wir haben ja über die hochspezialisierten Mitarbeiter gesprochen. Die müssen raus aus der Komfortzone. Ich frage jetzt mal, wie erlebst du das? Kannst du so etwas auch begleiten? Was sind deine Erfahrungen damit? Ich erlebe das natürlich. Ich erlebe diese Spezialisten oder auch die Methodenphytischisten in Trainings. Wenn sie in Trainings aus einer Betriebsäcke herauskommen, Def Ops ablehnen oder Spamme ablehnen. In Trainings geht das noch. Da ist mein Anspruch gar nicht mal die Leute aus dem Training oder mit dem Training so zu beeinflussen, dass ich darauf gewartet habe. Mein Ansatz im Training, das sage ich auch häufig, ihr müsst es nicht gut finden, was ich euch hier erzähle, aber hört erst mal zu. Wenn ihr es verstanden habt, dann könnt ihr euch ein Bild machen. Aber wenn einer Scrum-Schulung nach 2-3 Stunden schon sagt, das wird so nicht funktionieren, der könnte eigentlich aus der Schulung und rausgehen. Weil er sich ja so blockiert. Also wie gesagt, als Trainer ist mein Anspruch,

in Diskussionen immer mal meine Sicht darzulegen, aber ich sehe mich da nicht als Messias.

Um auf deine Frage einzugehen, wo erlebe ich die natürlich viel intensiver? Das ist eher genau, wenn es darum geht, Teams erfolgreicher zu machen oder überhaupt erst mal zusammenzubringen, dann erlebe ich die. Und da ist es natürlich schon wichtig, diese Leute zu verstehen. Und da ist dann manchmal, es kommt immer häufiger vor, meine Aufgabe auch, sie in, sage ich mal, auch in Einzelgesprächen einfach die Beweggründe zu verstehen. Und sie versuchen in Einzelgesprächen dahin zu bringen, dass sie das, ob erst mal, verstehen. Und natürlich kann man als Coach niemanden coachen, der nicht gecoached werden will. Also wer das wirklich rundherum ablehnt, das geht nicht. Und solche Sachen würde ich auch dann wahrscheinlich gar nicht annehmen oder würde solche Gespräche auch frühzeitig abbrechen, weil ich das Geld da entsprechend nicht verbraten möchte. Aber was natürlich schon geht, ist, dass man versuchen kann, eben mit Coaching-Techniken diese Ablehnung zumindest mal in ein positives Ziel zu verwandeln. Das heißt, die Ablehnung ist ja etwas, damit kann man ja alles kaputt machen. Wie will man jemand bewegen, wenn er das ablehnt. Aber die Frage ist eben immer, und das versuche ich dann eben mit entsprechenden Coaching-Techniken zu machen, diese Ablehnung mindestens in was Positives zu verwandeln, eine positive Zielrichtung rauszubekommen und dann doch noch ins Gespräch zu kommen. Also wie gesagt, das kommt häufiger vor. Man muss auch dann ja sehen, das ist ja für die Firma dann ein relativ teures Spielchen ist, einzelne Mitarbeiter quasi Coaching zu lassen. Aber wie gesagt, ich sehe eben, dass der Anspruch für den Firmen da ist, Teams aufzubauen. Und wenn ich in einem Team eine nur habe, der alle runterzieht, dann hat der quasi fast eine potenzierende Wirkung. Ein gutes Team kann durch eine Person schon runtergezogen werden. Und wir haben ja in Deutschland doch eine ziemlich, das haben wir Wohlfühlkultur, es gibt ja andere Kulturen, die würden diese eine Person direkt aus dem Team entfernen. Wir versuchen die noch zusammenzubringen. Und dann komme ich da eben auch ins Spiel.

Ja, da sind wir tatsächlich anders. Und ich will das gerne nicht bewerten, weil Wohlfühlkultur heißt auch Sicherheit. Und Sicherheit heißt auch potenzielle Zufriedenheit und Teamfähigkeit. Also auf der anderen Seite ist es genau so, wenn also jemand wirklich Partur nicht will, dann wird das Team auch nicht funktionieren. Und das ist halt das Spannungsfeld, in dem man arbeitet. Ich dachte aber auch an andere Dinge, wenn ich jetzt mal so auf meine Erfahrung schaue,

raus aus der Komfortzone heißt tatsächlich auch, rein in Gespräche, rein in den Austausch, rein wieder in das Lernen gehen. Ich erlebe Barcams als sehr hilfreich, also jetzt sage ich spreche ich mal für mich, um sozusagen auch ganz andere Impulse, ganz andere Erkenntnisse zu bekommen. Und ich denke, dieses Einlassen auf Neues, das ist etwas, was wichtiger wird in den nächsten Jahren, weil einfach das Wissen sich verändert und weil auch die Form der Zusammenarbeit sich so stark verändern. Wir sind ja mittendrin, das ist ja noch gar kein Ende, wo wir uns gerade befinden. Und wir wissen eigentlich gar nicht, wie Arbeit in fünf oder zehn Jahren aussieht. Und das waren so die Punkte, die mir gerade jetzt auch ein Stück weit durch den Kopf gehen. Also das eine ist das Coaching, das arbeiten mit den Menschen. Und das andere ist auch, ich sage mal, wie sich die Arbeitswelt insgesamt verändert und Spezialisten.

Das wäre so ein Stück weit meine These. Die brauchen auch Impulse für die persönliche Weiterentwicklung. Oder persönliche Weiterentwicklung könnte selbst ein Stichwort sein, was wichtiger wird. Also vollkommen richtig. Wir hatten ja auch vorhin schon über die Einschätzung gesprochen, dass meine Erwartung eigentlich ist, dass man eben offener wird, dass diese Spezialisten sich öffnen müssen. Das hat sie eben auch nochmal ja auch gesagt. Und ich denke, wenn man das richtig angeht, dann kriegt man das auch hin. Auch da gehe ich von einem positiven Menschenbild aus. Ich sage eben nicht, die machen das um jemanden zu ärgern, oder weil sie, weiß ich nicht, enttäuscht sind vom Leben oder sonst wie. Sondern die sind einfach so groß geworden, sie sind so erzogen worden vielleicht auch. Und so wenn es sind das auch vielleicht Entwicklungen, die sind 30, 40, 50 Jahre alt. Da muss man einfach Verständnis für haben, meiner Meinung nach. Und gucken, wo kann man ansetzen, dass man diese Spezialisten mit ihrem Wissen weiterhin einbindet. Denn es heißt ja nicht, dass wir das Wissen nicht mehr brauchen. Also manche Ortsgabe, ich gibt es auch noch dieses Missverständnis, dass man eben gesagt, wir haben jetzt ein cross-funktionales autonomes Team, wir brauchen keine Spezialisten mehr. Das ist ja eben genau nicht so. Also das ist ja ein Missverständnis. Und insofern, cross-funktional heißt ja ein Team, das aus verschiedenen Fachkompetenzen und letztendlich auch Spezialisten zusammengestellt wird. Richtig, ich habe Molych gerade ein schönes Beispiel dazu gelesen. Also insofern, das, was ich jetzt erzähle, kommt nicht vor mir. Das war bei Twitter, dass jemand, jemand, das gesagt hat, das vergleicht eher mit Fußballmannschaften. Ich brauche natürlich in Fußballmannschaften, ich brauche ein Torwart, das ist ganz banal. Ich brauche Spezialisten für, vielleicht für Verteidigung, für Spielaufbau, für Sturm. Ich brauche Kopfvollspezialisten, brauche ich. Aber wenn die alleine spielen würden, dann würden sie nicht gewinnen. Das heißt also, die Erwartung ist schon, dass ich diese Spezialisten habe. Damit ich aber nicht abhängig davon bin, muss ich eben einfach in den Köpfen der Spieler, der Fußballspieler, den Punkt haben, ich muss auch mal in eine andere Position spielen können. Dann darf man von mir keine Höchstleistung erwarten. Also jemand, der vielleicht kein Kopfvollspezialist ist, aber jetzt in einem Spiel diese Position übernimmt, dann muss man eben damit zufrieden, wenn er vielleicht, ich sag mal, vielleicht nur ein Tor erzielt oder einfach den Gegner bindet. Also kurzum, ich brauche diese Spezialisten, aber ich muss eben dahin kommen, allen Leuten klarzumachen, welche Vorteile es hat, im Team diese Spezialisten einzubinden. Dann gibt es hier nun auch genug Möglichkeiten, sie entsprechend einzubinden.

Ich kenne das aus dem, vielleicht eher aus dem amerikanischen, unter dem Begriff T-Shirt Spezialisierung. Das heißt, ich habe einen Sockel, wo ich sozusagen besonders gut bin, beispielsweise beim Fußball, der Stürmer oder der Mittelfeldspieler. Ich habe aber wie beim T-Shirt, Seitenkompetenzen und kann sozusagen auch andere Rollen übernehmen oder zumindest verstehen.

Und ich glaube, das ist, das Fußballbild gefällt mir auch sehr gut. Fußball funktioniert nicht mit Totalspezialisten. Da wird da kein Spiel draus, aber auch nicht mit Totalgeneralisten. Wenn jeder alles macht, dann wird es halt auch nicht funktionieren. Ich kann das noch fußbarmäßig ergänzen. Es gibt vom Ottmar-Hitzfeld so ein schönes Zitat. Es spielt nicht immer die besten Elf, sondern die beste Elf.

Also ein Buchstabe macht da schon einen riesen Unterschied. So, wenn ich Team-Entwicklungs-Workshops mache, dann ist das auch so der Einstieg, um den Leuten klarzumachen, wohin wir wollen an der Stelle.

Schönes Zitat.

Dirk, was kann ich denn in der IT anders machen? Also wenn ich jetzt mich in die Lage eines IT-Mitarbeiters versetze und sage, ja, ich möchte eigentlich in der Zukunft diesen Job weitermachen, auch unter anderem Vorzeichen. Was wären denn für mich gute Tipps oder drei gute Tipps, um weiter erfolgreich zu sein, schlichtweg in meinem Job? Die Frage ist ja, ob ich nicht vielleicht jetzt weniger Spaß habe und mit einer anderen Arbeitsweise mehr Spaß habe.

Ich mache das ja nicht, oder ein wichtiger Punkt für mich in der Argumentation dabei ist ja auch immer, dass natürlich das Unternehmen Vorteile von haben muss und die Kunden, aber auch die Mitarbeiter. Also mich treibt auch an, dass ich einfach möchte, dass die Leute wieder mit mehr Spaß oder überhaupt Spaß zur Arbeit gehen. Also insofern, das war ich so als mögliches Ziel, als mögliche Motivation, einfach zu sagen, ich habe dann vielleicht mehr Spaß bei der Arbeit, weil ich anders arbeite.

Jetzt zu diesen drei Tipps vielleicht nochmal. Ein Punkt, den hatten wir schon ein paar Mal jetzt aufgeführt, ist die Themen Offenheit. Also, sichten den neuen Themen zu öffnen und eben sie nicht per se abzulehnen. Das muss nicht heißen, dass ich naiv alles Neue toll finde, aber eben einfach ran zu gehen, offen ran zu gehen, ich habe gesagt, Offenheit, sich diese neuen Methoden anzuhören und zu überlegen, wo könnten denn Vorteile sein? Ich weiß nicht, ob das eine deutsche Angewohnheit ist, eben erst das Negative zu sehen. Natürlich verändere ich oder natürlich verändern neue Methoden, neue Arbeitsweisen, auch meine Arbeitsweise an sich und die Komfortzone haben wir besprochen, aber es gibt ja auch Vorteile. Also, ein Tipp wäre ganz klar, Offenheit, offen an die neuen Dinge ran zu gehen und diese Offenheit dann auch sicherlich zu überlegen, wo kann ich denn meine Kompetenzen, die ich habe, die auch häufig weiter gebraucht werden, wo kann ich die einbringen, wie kann ich die einbringen und wo kann ich dann eben oder wo muss ich auch noch Dinge verändern, wo muss ich vielleicht noch Schulungen besuchen oder Unterstützung mir einholen, aber wie gesagt, offen an die neuen Themen ran zu gehen.

Zweiter Punkt, wie ich finde, ist, wäre mein Tipp, zu sagen Kundenorientierung. Und ist das ein Begriff, den weiß ich in die Chemmer schon seit 20, 30 Jahren, dass wir sagen IT, Kundenorientierung. Und das Interessante ist, dass diese, das Thema Kundenorientierung, glaube ich auch heute immer noch eine Schwierigkeit ist in der IT, wahrscheinlich, wenn wir das nie in den Griff kriegen, weil wir ja schon mit Spezialisten und mit Technikern reden und Techniker sind eben vielleicht nicht immer per se so Kundenorientiert, wie wir das gerne hätten. Ich bin ja kein Techniker, ich bin ja Betriebswirt, insofern bin ich vielleicht Kundenorientierter, so durch meine Art heraus schon. Aber was meine ich mit Kundenorientierung? Letzten Endes bezahlt der Kunde mein Gehalt, bezahlt der Kunde meinen Auftrag und ich kann Recht haben als Techniker, aber wenn der Kunde damit nicht zufrieden ist, hilft mir das nicht viel.

Das heißt, das soll ja nicht heißen, dass ich alles das mache, was der Kunde will. Da kommt damit am besten ein bisschen Kritik oder auch Selbstverständnis oder Kritik-Wähigkeit rein. Aber schlussendlich ist es das, was ich tue, auch in der IT, muss dem Kunden gefallen und es muss für den Kunden einen Mehrwert bringen. Und dann wäre eben mein Tipp für IT-Ler,

einfach sich vielleicht versuchen mal gedanklich von der anderen technischen Sache zu lösen von der technischen Argumentation her und das Ganze aus Sicht des Kunden zu sehen und dann auch vielleicht Dinge einem Kunden zu erläutern. Und der Motto, wir können das so machen, bedeutet das und das und hat die und die Konsequenzen und das eben mit dem Versuch, das einem Kunden, also einem Nicht-Techniker zu erklären.

Und das geht für mich in den dritten Punkt rein, den ich mir da so überlegt habe, ist so, dass es eine Berater, Beratermentalität.

Nun sind ja auch Berater nicht immer beliebt von ihrer Art her, aber in diesem Fall meine ich Beratermentalität. Das heißt, dass ich als IT-Ler, als Experte dem Kunden schon klar mache,

du hast diese Möglichkeit oder wir haben diese Möglichkeit, wir haben diese Möglichkeit, diese beiden, das sind die Vor- und Nachteile, das sind die Konsequenzen da draus und dann den Kunden entscheiden zu lassen, was er dort möchte. Also dem Kunden Wahlmöglichkeiten aufnehmen. Und nicht quasi der Versuch, die einzige oder die eine Möglichkeit, nur als einzige Möglichkeit, als einzige Umsetzungsmöglichkeit rüberzubringen. Also zusammengefasst, Offenheit haben wir komplett drüber gesprochen heute,

Kundenneuentierung, Beratermentalität, einfach weil die IT heutzutage einen so hohen Stellenwert hat in den Geschäftsprozessen. Auch das ist ja nichts Neues, aber es wird ja immer schlimmer oder immer, man wird ja immer abhängig von der IT, das eben genau ich als Experte, als technische Experte, das aus einer Kundensicht sehe, verstehe und dem Kunden auch entsprechend näher bringe und erkläre.

Ich male mal ein Bild, vielleicht ist das auch ein bisschen zu weit abgehoben, vielleicht sogar zu, mir fällt kein besseres Wort, ein Romantisch oder Rosal gefärbt. Ich sage mal, in der klassischen IT-Welt, ich habe ja auch in der IT-Welt gearbeitet,

da kommt ja auch der Begriff Kunde her, da ist das Verhältnis zwischen Kunde und IT tatsächlich so ein Auftraggeber, Auftragnehmerverhältnis gewesen, IT hat das ja ganz detailliert gezeichnet, wie dort die Prozesse sind.

Und das war ein Bild, das sehr stark über Abgrenzungen gearbeitet hat, das sind die Dinge, dafür bin ich zuständig, das sind die Dinge, das muss der Kunde machen. Und wenn einer in dieser Zusammenarbeit nicht so ganz 100% dk arbeitet hat, also der Kunde hat dich genau technisch spezifiziert oder was auch immer, dann gab es Probleme und man hat sich über Rollenzuständigkeiten und Zusammenarbeit ausgetauscht.

Ich glaube, in der zukünftigen Welt ist ja das Thema Zusammenarbeit wichtiger. Natürlich gibt es den Kunden, natürlich gibt es den IT-Spezialist, aber am Ende des Tages gibt es ein Projekt, an dem man zusammenarbeiten muss.

Und da sehe ich, und das passt glaube ich gut zu dem Thema Beratermentalität und Kundenorientierung, dazu gehört auch Wertschätzung, das wäre so mein Bild.

Ich schätze den Kunden und seine Probleme wert und auch ein Kunde muss vielleicht ein Stück weit in eine andere Zusammenarbeit kommen.

Wie siehst du das, dass sich das ein Stück weit, also weg von dieser Auftragnehmer, Auftraggeberbeziehung, ein Stück weit künftig auch in einer Form von Zusammenarbeit entwickeln könnte? Also ich sehe das jetzt schon, dass diese bessere oder die andere Zusammenarbeit angewendet wird, dass sie funktioniert und das, was du sagst mit der Wertschätzung, finde ich unheimlich wichtig. Die würde ich aber eher auf die Kundenseite legen. Also ich, wenn ich das jetzt wirklich ganz mal knallhart formulieren würde, würde ich sagen, die Kunden müssen die Arbeit der IT wertschätzen, also mit einem höheren Wert einschätzen. Und du hast eben gesagt, IT hat ja den Kundenbegriff in der IT eingeführt oder auch für die IT geschaffen.

Wenn wir zurückgehen, lange bevor es IT gab, gab es schon Kunden. Und in der heutigen Zeit versuche ich immer auch, den IT-Land Beispiele zu bringen aus einer Nicht-IT-Welt. Und auch da wiederum, da geht es gar nicht um Methoden. Natürlich kann ich als Kunde immer auch sagen, ich habe Recht. Also man trifft sich auch vielleicht vor Gericht und kriegt auch Recht und kriegt auch Geld, wie da aber so viel Ärgerheit dabei ist. Das heißt, diese Wertschätzung, vollkommen richtige Wertschätzung, die ich als Kunde meiner Meinung nach meinem Dienstleister entgegenbringen sollte, führt dazu, dass der vielleicht nicht nur Dienstleister ist, weil dann leistet er ja irgendwelche Dienste, sondern dass man wirklich auf einer partnerschaftlichen Ebene zusammenarbeitet, weil beide Seiten eigentlich ja Stress vermeiden sollten. Und wie kann ich Stress am besten vermeiden, indem ich offen bin, indem ich mit meinem Gegenüber wertschätzend gegenüber trete. Und dann auch vielleicht mal das eine oder andere Tour, was ich laut Vertrag gar nicht tun müsste, nur damit ich den Kunden oder auch den Auftageber auf Dinge hinweise, die ich abstellen kann, wenn ich in rechtzeitig eben vor etwas war. Also insofern Wertschätzung, finde ich, ein ganz wichtigen Begriff. Und Wertschätzung würde ich sozusagen mit Blick auf die heutige Welt eher einem Kunden zuschreiben, dass er die Arbeit des Dienstleisters, des IT-Partners wertschätzen sollte. Ich finde das ein spannendes Thema, das ist vielleicht ein Thema für zukünftige Podcast, denn da kann man ja noch deutlich weiterspinnen. Das heißt, du sagst ja, auf der Kundenseite ist das ein Thema. Und die spannende Frage, die müssen wir aber jetzt nicht behandeln, ist, wie komme ich in eine andere Wertschätzung als IT-Dienstleister rein? Da muss ich mich, glaube ich, tatsächlich ein Stück weit von der reinen technischen Expertenkompetenz lösen hin zu einer anderen Qualität. Das sind wir vielleicht wieder bei der Beratermentalität.

Ja, sehr schön. Dirk, ich danke dir sehr für das Gespräch. Ich glaube, wir sind jetzt am Schluss angekommen und haben eigentlich auch genau die drei Punkte herausgearbeitet, die für IT-Mitarbeiter wichtig sind in der Digitalisierung. Ich danke dir sehr für das Gespräch.

Ich bedanke mich auch. Und wenn ich jetzt auf die Uhr gucke, ich fand das recht kurzweilig. Also ich hätte jetzt nicht gesagt, dass wir hier schon 45 Minuten reden, also insofern auch ein Dank an dich, dass ich da mit dir durch dich, durch dieses Thema so durchgeführt wurde und dass wir hier, denke ich, den ganz guten Podcast produziert haben.

Webseite von André Claassen

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

Inhalt laden

Mit Sandra Parsick spreche ich über den Toolseinsatz im Rahmen von modernen Techniken aus Continuous Integration (CI) und Continuous Delivery (CD). Insbesondere unterstützt Continuous Delivery wichtige Architekturziele wie Stabilität und Reaktionsfähigkeit. WIr setzen unser interessantes Gespräch aus dem ersten Teil fort.

In dieser Folge der „DevOps Toolparade“ diskutieren Dierk Söllner und Sandra Parsick über eine Vielzahl von Tools im Bereich der DevOps, angefangen bei Versionskontrollsystemen, über Continuous Build und Test-Automatisierung, bis hin zu Themen wie Transparency Inspection und Continuous Controlling. Sie gehen auf die Bedeutung der einzelnen Tools für den Entwicklungsprozess ein, diskutieren deren Einsatzmöglichkeiten und Vorteile und betrachten auch die Herausforderungen, die mit der Implementierung einhergehen. Besonders hervorgehoben werden Tools wie Git, Maven, Gradle, sowie Testing-Tools wie jUnit und Selenium.

Inhalt

• Versionskontrollsysteme
  • Bedeutung von Git und anderen Systemen
• Continuous Build
  • Tools wie Maven und Gradle
• Test-Automatisierung
  • Einsatz von jUnit, Selenium
• Transparency Inspection
  • Bedeutung und Anwendungsbereiche
• Datenbanken in DevOps
  • Anpassung und Automatisierung
• Konfigurationsmanagement
  • Tools wie Ansible, Puppet
• Automatisierung und Verteilung
  • Einsatz von Docker und Kubernetes
• Continuous Controlling und Observation
  • Überwachung und Monitoring in der Produktion

Shownotes

Die Basis unseres Gesprächs, der Architektur-Spicker

Webseite von Sandra Parsick

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 der Fortsetzung DevOps Toolparade. Wir hatten ja beim letzten Mal mit Sandra Pasik gesprochen über das Thema,
welche Tools gibt es im DevOps-Umfeld. Ja, und da wir so nett geplaudert hatten und so viel zu erzählen hatten, sind wir mit der Zeit insofern nicht hingekommen,
als dass wir gefühlt wirklich erstmal mittendrin stehen geblieben sind. Und wir hatten uns da ganz kurzfristig verabredet, eine zweite Folge zu machen,
einen zweiten Termin zu machen. Insofern, hier kommt jetzt der zweite Teil, die DevOps-Toolparade. Und ich würde sagen, Sandra, die Vorstellung können wir uns dann ersparen.
Und auch die Definition von DevOps. Mein Vorschlag ist, dass wir einfach ganz kurz nochmal einsteigen in den groben Überblick der DevOps-Perlenkette,
die du ja in einem Dokument sehr schön beschrieben hast, was wir ja eben auch, wie gesagt, bei den Shownotes verlinken werden.
Und dass wir dann einfach einsteigen in die einzelnen Schritte. Also insofern wäre es schön, wenn du nochmal ganz kurz einen Überblick gibst und dann vielleicht gleich einsteigst in das Thema Versionskontrollsystem.
Ja, erstmal hallo. Schön, dass wir uns wieder zusammengefunden haben. Ja, die Perlenkette besteht eigentlich aus acht Perlen.
Da sind als erste Perle zu nennen die Versionskontrollsysteme. Dann als zweites geht es dann um Continuous Build, also um Build-Automatisierung im Allgemeinen.
Dann gehen wir Richtung Test-Automatisierung. Also wie kriege ich meine Tests halt toolgestützt automatisiert.
Dann geht es Richtung Continuous Build.
Dann geht es Richtung Transparency Inspection, was jetzt im AT2-Speaker jetzt nicht genau eingegangen wird, weil dazu gab es für mich einen eigenen Speaker.
Dann geht es Richtung, eher so ein bisschen Oldschool, halt 2-3 Datenbanken. Wie kriege ich das DevOps-mäßig oder Continuous Build-Automatisiert?
Dann eher mehr OPS-lastig als Dev-lastig ist dann halt Konfrontationsmanagement.
Da geht es dann darum, wie ich das automatisiert zur Infrastruktur bereitstellen kann.
Dann geht es Richtung Automatisierung.
Dann geht es Richtung Verteilung. Also wie kriege ich stressfrei meine Software-Artifakte auf der Infrastruktur installiert.
Und dann zum Schluss Continuous Controlling, Observation. Das geht halt darum, wie kriege ich in der Produktion ein Monitoring hin und wie kriege ich die Produktion überwacht, ob ich mit meiner Software meine Produktziele oder Qualitätsziele damit auch erreiche.
Ja, und dann sind wir beim letzten Mal eingestiegen in die Versionskontrollsysteme.
Da geht es halt darum, dass ich halt meinen Code visionieren möchte.
Ja, und dann sind wir beim letzten Mal eingestiegen in die Versionskontrollsysteme. Da geht es halt darum, dass ich halt meinen Code visionieren möchte.
Janine Youtube
Potenzial
Und dann haben wir glaube ich schon ein bisschen darüber geredet, warum ich das tun sollte.
Janine Youtube
Potenzial
Da gibt es halt mehrere Möglichkeiten was zu tun, der geile heiße Scheiß, obwohl das schon ein paar Jahre alt ist.
었습니다
Und da gibt es halt mehrere Möglichkeiten was zu tun, der geile heiße Scheiß, obwohl das schon ein paar Jahre alt ist.
Janine Youtube
Potenzial
Es ist halt parenthis, also eher so eine verteilte Bildungsverwaltung und daraus resultieren sich dann ganz neue Möglichkeiten wie ich die Entwickler miteinander halt Arbeit lassen kann.
Es ist halt parenthis, also eher so eine verteilte Bildungsverwaltung und daraus resultieren sich dann ganz neue Möglichkeiten wie ich die Entwickler miteinander halt Arbeit lassen kann.
Und daraus resultieren sich dann ganz neue Möglichkeiten, wie ich die Entwickler miteinander halt arbeiten lassen kann. Da werden ja solche Sachen gerne genannt wie Feature-Branch-Unterstützte-Entwicklung oder die Teams sollen mit Pool-Requests halt arbeiten.
Und ja, das sind halt so Möglichkeiten, die damals mit Subversion oder mit dem zentralen Versicherungsverwaltungssystem eher schwer zu realisieren waren. Das heißt, das Tool gibt halt in dem Sinne ganz neue Möglichkeiten auf, wie man die Zusammenarbeit zwischen den Entwicklern halt vorantreiben kann.
Vorantreiben im Sinne von zentraler Verwaltung und verteilter Verwaltung, richtig?
Genau, genau. Also der Vorteil war, also was ich persönlich als Vorteil sehe, den Wechsel von den zentralen Versicherungssystemen.
Also Versicherungsverwaltung, ich habe halt bei der zentralen Versicherungsverwaltung habe ich immer nur einen Aufschnitt auf meiner Platte.
Das heißt, wenn ich zum Beispiel die Historie sehen möchte, was da für Änderungen gelaufen sind, dann muss ich immer mich mit dem Server halt verbinden.
Das ist jetzt bei mir immer meistens ein Problem, weil ich jetzt als Berater unterwegs bin, das heißt, ich arbeite gerne auch aus dem Zug heraus.
Naja, und ich will jetzt kein Bahn-Bashing machen oder deutsche Infrastruktur-Bashing machen, aber manchmal kommen wir halt da keine Internetverbindung an.
Ja, okay.
Naja, dann ist es halt ein bisschen blöd, wenn man jetzt vielleicht eine andere Vision braucht vom Code, dass man da keinen Zugriff hat.
Und das habe ich mit Git halt nicht oder mit anderen verteilten Versicherungsverwaltungen, weil ich mir immer an die komplette Kopie des Repositories auf meiner Platte halt ziehe.
Das heißt, wenn ich mal auch im Tunnel bin, im Zug, also die Historie habe ich immer bei mir auf der Platte.
Das ist so einer der Vorteile, was ich halt so sehe.
Aber ich habe mir auch sagen lassen, das ist ein Berater-Problem.
Das muss ich unbedingt jetzt auf allen Entwickler zu treffen.
Von daher, ja, aber gut, vielleicht kann man es als ein Berater-Problem halt ansehen.
Ja, okay.
Wobei, Berater-Problem oder eben überhaupt das Problem von, auch vielleicht bei einer eher schwachen Infrastruktur, wenn man vielleicht in Teilen der Welt arbeitet, die auch in einem Büro nicht gut angebunden sind.
Ich glaube, das ist wahrscheinlich in der IT-Welt wahrscheinlich eher selten, aber könnte ja theoretisch auch sein, wenn man mal absieht von deinem persönlich.
Ich glaube, das ist wahrscheinlich ein Berater-Problem mit der deutschen Infrastruktur, dass man so ein bisschen globaler sieht.
Also insofern die Frage fällt an der Stelle, wenn man Teams hat, die vielleicht an einem Ort zusammenarbeiten, also wirklich räumlich beieinander oder nah beieinander sind, gibt es da Unterschiede?
Also aus der technischen Sicht zwischen der zentralen und der verteilten Versionsverwaltung?
Ja, also es gibt das schon, denn wenn ich halt bei der zentralen Versionsverwaltung, also bei der, oder fangen wir anders an,
bei der zentralen Versionsverwaltung habe ich den Vorteil, ich habe so einen, ich sage mal, für Laien gesprochen, so einen Zwei-Phasen-Commit.
Das heißt, ich visioniere meine Änderungen, die ich mache, halt erstmal bei mir lokal und davon bekommen erstmal meine Kollegen halt nicht mit.
Aber ich habe für mich persönlich dann nochmal so einen Sicherheits-Snap von wegen, okay, wenn ich jetzt experimentieren möchte oder was ausprobieren möchte,
ich kann immer wieder auf einen funktionierenden Stand zurückgehen.
Und wenn ich dann sicher bin, dass die anderen von meiner Änderung was mitbekommen sollen, dann, das nennt sich das bei Gips,
dann pushe ich meine Änderungen.
Dann habe ich die Änderungen halt in das Remote-Repository, wo alle halt drauf zugegriffen haben.
Wenn ich das jetzt mit Subversion machen möchte, das geht erstmal mit Hausmitteln von Subversion nicht,
denn da ist ein Commit jedes Mal, ich pushe das wirklich ins Repository, wo alle anderen halt, ins Remote-Repository, wo alle anderen halt die Änderungen gleich mitbekommen.
Das heißt, da habe ich den Nachteil, also kann man auch vielleicht sagen, okay, das ist vielleicht wieder so ein persönlicher Entwickler-Ding,
wie man halt arbeitet, aber ich habe da nicht die Möglichkeit, dass ich fein Granulare halt,
arbeiten kann, dass ich halt kleinere Schritte machen kann in meiner Historie, sondern ich habe da immer so solche Big Bang-Commits.
Und da ist leider, würde man sagen, okay, wo ist das Problem?
Das Problem ist halt, wenn ich Fehler suche und mache.
Das ist halt einfacher, kleine Änderungsunterschiede zu analysieren, als wenn ich halt große Änderungsschritte mir analysieren muss.
Und das wäre zum Beispiel jetzt auch so ein Vorteil, wo ich sage, okay, so ein verteiltes Versionsverwaltungssystem,
könnte man auch einsetzen, auch wenn man halt vielleicht lokal zusammensitzt mit den Entwicklern vor Ort.
Ja, gut. Wobei natürlich dann letzten Endes es ja immer in der Entscheidung des Teams liegt, wie sie arbeiten.
Genau.
Und insofern, würdest du sagen, dass eine der beiden Versionen oder der eine der Arten, mit Versionsverwaltung zu arbeiten,
einen höheren Reifegrad des Teams erfordert oder ist das eigentlich egal?
Also ich habe die Erfahrung gemacht, das ist eigentlich egal.
Also das ist eigentlich…
Also wenn ein neues Versionsgetreu-System irgendwo eingesetzt wird, dann empfehle ich halt immer das verteilte Versionsverwaltung,
weil ich kann die Konzepte einer zentralen Versionsverwaltung auch mit einem verteilten Versionsverwaltungssystem halt simulieren.
Ich habe aber zusätzlich halt die Möglichkeit, zukünftig, wenn ich meinen Workflow halt ändern möchte,
dass ich dann mehr Spielraum an der Stelle habe.
Und dann ist halt auch diese, dass ich halt diese Persönlichkeiten, wie jemand arbeitet, halt unterstützen kann,
wo ich sagen kann, okay, wenn du Feingranen…
Wenn du Feingranen oder arbeiten möchtest, dann kannst du es damit tun.
Wenn jemand aber große Komiz machen möchte, warum auch immer,
also das kann man sich sogar streiten, ob da irgendwelche Vorteile gibt,
der hätte das mit einem verteilten Versionsverwaltungssystem auch noch die Möglichkeit.
Also ich sehe, also gerade bei neuen Projekten, also wenn es die überhaupt gibt,
sehe ich da keine große Vorteile, so ein zentrales Versionsverwaltungssystem halt einzuführen.
Ja, okay.
Wenn ich jetzt mal so kurz zusammenfasse, der Punkt 1 war ja Versionskontrollen.
Versionskontrollsystem.
Insofern ist es natürlich wichtig, überhaupt erstmal ein solches Versionskontrollsystem einzuführen.
Ja, natürlich.
Das war dann die wichtigste oder die Basisentscheidung.
Also ich bin dann ein bisschen radikal und sage,
also wenn jemand ein Softwareentwicklungsprojekt starten möchte ohne Versionskontrollsystem,
dann soll er es direkt lassen.
Ja, okay.
Also ich bin auch, ich habe das auch beim letzten Mal auch schon gesagt,
ich habe das selbst bei kleinen Teams erlebt.
Nun bin ich ja kein Entwickler.
Aber selbst bei ganz, ganz kleinen Teams,
sofern ich bei den Entwicklern einen gewissen Reifegrad, einen gewissen Anspruch festgestellt habe,
haben selbst die mit zwei, drei Entwicklern genauso gearbeitet.
Also Versionskontrollsystem und haben für sich, für ihre Arbeit einfach den Vorteil gesehen,
das, was du ja auch alles entsprechend schon dargestellt hast.
Also ich glaube, das hängt dann wirklich von dem Reifegrad, von dem Anspruch der Entwickler ab.
Ja, also ich meine, wenn ich Privatheitswachen mache,
also ich gucke die Milchhäuser wieder.
Das ist ja auch sehr, sehr praktikal, weil ich halt wahrscheinlich Techie bin.
Aber wenn ich zum Beispiel halt einen Artikel schreibe, ich mache das halt nicht in Word,
sondern halt in so, also wir leiden gesprochen, in so einer Textdatei.
Und dann bin ich die Sachen auch in einen lokalen Git-Ribs-Tutorials am Ablegen.
Das, wenn ich halt mal zu einem zusätzlichen Stand zurückspringen möchte,
dass ich dann, wie ich das von meinem Source Code halt gewohnt bin,
dass ich da auch in meinen Artikeln halt nochmal in Visionen zurückspringen kann.
Mhm, ja.
Also das ist halt…
Mhm, ja.
Also das kann man jetzt sagen, okay, sie macht das, weil sie halt Entwicklerin ist
und das bestehende Tooling halt benutzen möchte.
Aber das wäre halt auch an der Stelle eine Möglichkeit, das zu tun.
Also, oder wenn man alleine an einem Softwareprojekt arbeitet.
Mhm.
Also das ist das Erste, was ich halt mache, auch wenn das kein Remote-Ribs-Tutorial ist
oder auf GitHub ist, aber ich habe zumindest immer ein lokales Ribs-Tutorial,
wo ich dann eine Visionierung auf dem Laptop mache.
Ja, okay.
Also für diesen Punkt Versionskontrollsystem, denke ich, sind ein paar Punkte wichtig,
wichtig ist, dass die Entwickler eben entsprechend den Code häufig einchecken,
regelmäßig einchecken und regelmäßig heißt nicht einmal im Jahr,
sondern in einem sehr viel kürzeren Zeitraum,
dass sich die Entwickler oder die Teams für ein entsprechendes Tooling
und für einen entsprechenden Workflow entscheiden und eben ihre Arbeitsweise daran anpassen.
Denn je nachdem, ob ich nun verteilt oder zentral arbeite,
muss ich ja auch als Entwickler meine Arbeitsweise darauf abstimmen.
Und ich denke, der dritte Punkt ist,
der dritte Punkt, den du auch in deinem Spicker so beschrieben hast,
ist, dass das Team für den Quelltext gemeinsam verantwortlich ist,
also das Thema, was du hast es genannt, Collective Ownership.
Das, denke ich, sind so die drei wichtigen Punkte für dieses Thema.
Doch, ja. Und genau.
Und das ist halt Basis, wenn wir jetzt zum zweiten Punkt rüberkommen,
dann ist es halt eine Basis, um halt zum Beispiel den Bildlauf zu automatisieren.
Also mit Bildlauf ist halt gemeint, okay, jetzt habe ich meinen Softcode,
aber der Softcode alleine macht noch keine lauffähige,
halt, Software, sondern die muss halt erstmal übersetzt werden,
dass so eine Maschine überhaupt versteht, was sie da tun soll.
Und das möchte ich halt nicht manuell machen,
sondern dann habe ich halt auch Skripte, die das entsprechend automatisiert tun.
Das heißt, dann gehe ich halt einen Schritt weiter und sage, okay,
dann kann ich ja das Bild weiterführen und sagen, okay,
ich kann ja in meinem Visionskontrollsystem ja drauf räuchen.
Hat sich da was geändert an dem Stand des, des Hostcodes?
Und wenn ja, dann habe ich irgendetwas, das hat ja meistens so eine continuous integration,
CI-Maschine oder CI-Server genommen und der dann sagt,
aha, da hat sich was geändert, dann kompiliere ich das alles mal durch,
also übersetze das alles mal in lauffähige Software und gucke,
ob da irgendwelche Kompilierungsfehler, also Sonntagsfehler zum Beispiel, vorhanden sind.
Und somit habe ich ein schnelles Feedback auch Richtung Entwicklung
und vor allem, wenn ich, wenn da mehrere Entwickler haben,
miteinander arbeiten und zu gucken, wenn ich die Sachen zusammenführe,
ob das Ganze überhaupt noch baubar oder kompilierfähig halt an einer Stelle ist.
Ja, und das können die Entwickler ja auf ihrem Rechner dann auch machen.
Ja, und das können die Entwickler auf ihrem Rechner dann auch machen.
Ja, und das können die Entwickler ja auf ihrem Rechner dann auch machen.
Ja, genau, also das ist auch das Ziel.
Also das, was ich auf so einem zentralen Server ablaufen lasse,
das muss auch bei mir lokal halt funktionieren.
Und da gibt es halt gängige Tools, also das muss man dann nicht mit Skripten,
das heißt nicht, dass ich jetzt irgendwelche Tools selber schreiben muss,
sondern dann nämlich bewertete Tools.
Also ich persönlich komme jetzt aus der Java-Ecke
und dann so was ist dann so wie Maven, Gradle,
sind dann so die gängigen Tools, die man dann einsetzt,
um sowas halt automatisch zu machen.
Es gibt natürlich dann auch weitere Möglichkeiten, das zu erweitern,
aber das können wir im nächsten Punkt nochmal tiefer eingehen.
Naja, auf jeden Fall, die Idee ist halt, dass, ich sag immer,
die Wahrheit liegt im Bild-Tool.
Also wir haben manchmal so Quellen, also wir haben ja,
wir arbeiten ja nicht mit so Text-Editoren,
sondern mit ein bisschen ausgereiften EDEs,
also Integrated Developer Environments.
Das heißt, da ist halt auch ein Compiler im Hintergrund,
der guckt, ob das halt alles läuft.
Manchmal haben wir aber die Effekte,
dass die einen halt gerne halt vom Hersteller A nehmen,
die anderen gerne vom Hersteller B
und da gibt es unterschiedliche Auswirkungen,
wie sie auf den Source-Code reagieren, die man schreibt.
Und dann sagt man aber, okay, ist mir egal,
was für eine Idee oder Text-Editor du nimmst,
die Wahrheit liegt halt in diesem Bild-Tool.
Das heißt, wenn das Bild-Tool sagt, hey, das ist kompilierbar,
daraus kann ich halt ein Software-Artefakt bauen,
dann ist das die einzige Stelle der Wahrheit,
ob die Software überhaupt kompilierfähig ist oder nicht.
Also ich weiß nicht, wie oft ich schon in Meetings gesessen habe
und dann hieß es, ja, bei mir in Eclipse funktioniert das sehr schön,
aber Maven meckert und wenn Maven meckert,
dann meckert halt auch das auf dem zentralen Server
und dann kann ich das halt nicht ausliefern.
Das heißt, jeder kann sein persönliches Werkzeug nehmen,
also für mich ist ein Text-Editor halt ein Werkzeug
und man muss sich halt nur auf das Bild-Tool einigen
und das ist dann die Quelle der Wahrheit,
ob die Software baubar ist oder nicht.
So für mich als Nicht-Techie, wie viele Tools gibt es denn in dem Umfeld,
die relativ gleich sind von der Funktionalität?
Also sprechen wir davon, dass ich vielleicht nur ein, zwei Tools habe
oder habe ich auch wirklich eine Auswahl von, weiß ich nicht,
neun oder zehn Tools, die wirklich eigentlich relativ nah beieinander liegen,
was die Funktionalität angeht?
Im Umfeld sind mir also drei, vier.
Also wenn ich auch die X-Routen nehme,
sind mir bis zu zehn Tools bekannt.
Ich glaube, namentlich würde ich fünf oder sechs aufzählen können.
Also dann gibt es halt, dann habe ich ja nicht so Java,
sondern halt noch andere Sprachen, die auf der Java-Plattform aufbauen.
Die bringen dann manchmal auch eigene Bild-Tools mit.
Also dann haben wir schon wieder, das muss mal 20 sein.
Und wenn ich dann sage, okay, ich möchte nicht Java benutzen
oder aus der JDK-Welt rausgehe, sondern C-Shrat nehme,
gibt es wieder eigene Bild-Tools.
Wenn ich halt Web-Frontend machen möchte,
dann arbeite ich meistens mit JavaScript.
Dann halt das nicht Bild-Tool, sondern Task-Run,
aber vom Prinzip her haben sie so eine ähnliche Aufgabe,
nur dass ich bei JavaScript das nicht kompilieren muss,
sondern halt in andere Checks halt laufen lassen möchte.
Ja, und dann gibt es halt gerade im JavaScript-Umfeld gefühlt,
tauchen da jede Woche zwei neue Tools auf in jedem Bereich.
Also da, also ich glaube, da kann man sich wochenlang darüber unterhalten.
Also das ist halt…
Okay.
Dann bleiben wir bei unseren 45 Minuten hier.
Okay, gut.
Sandra, die Frage ist ja bei den Teams immer Selbstorganisation.
Wenn ich mich richtig eben verstanden habe, hast du gesagt,
Continuous Build ist wirklich eine Stelle, wo ich eigentlich die Basis schon lege
für ein vernünftiges Continuous Delivery.
Wie stark können denn die Teams sich hier selbst organisieren?
Das heißt, wie stark oder wie weit kann ich ihnen Autonomie zugestehen
bei der Auswahl ihrer Tools?
Also wenn man jetzt den neuen Klassiker, also Microservice nimmt,
dann haben die Teams, ist es davon abhängig,
ein bisschen wie Technologie-Stack aussehen.
Das heißt, wenn ich Teams habe und sage, okay, die dürfen die Technologie-Stack selber aussuchen,
dann bin ich auch gezwungen, denen die Freiheit zu geben,
dass sie sich auch das Build-Tool auswählen.
Das Build-Tool muss halt so zum Technologie-Stack halt passen.
Das heißt, in meinen Augen macht das wenig Sinn, Maven einzusetzen,
nur weil das irgendwo zentral mal festgelegt ist.
Und die Jungs und Mädels programmieren in Python oder in JavaScript.
Vielleicht wird das sogar technisch, in dem Fall bei Python weiß ich es sogar nicht,
aber bei JavaScript würde es sogar bis zu einem gewissen Grad gehen.
Aber ich würde mich ja trotzdem beschneiden, weil die Welt da draußen,
die JavaScript oder Python benutzen, die nutzen halt ein anderes Build-Tooling
oder ein Task-Run in dem Sinne.
Das heißt, an der Stelle würde das aus meiner Sicht wenig Sinn machen.
Die andere Überlegung ist,
wenn aber die Teams ähnliche Technologie-Stacks nehmen,
also zum Beispiel die Teams nutzen alle Java,
dann macht das schon aus meiner Sicht schon Sinn zu sagen,
okay, dann lass uns ein einheitliches Build-Tool an der Stelle nehmen.
Oder man muss wirklich Argumentationen finden,
warum man dann an der Stelle halt abweichen sollte.
Und das ist jetzt nicht, weil man die Farbe des Logos vom Build-Tool halt schöner findet
oder die blieb der Argumentation.
Das wird gerade auf Konferenzen gehypt.
Deswegen…
Deswegen muss man das jetzt machen.
Ja, okay.
Also im Prinzip schon, dass die Teams es selber entscheiden sollten oder müssten,
aber es hängt auch stark von der Technologie ab.
Ja, genau.
Und dann ist es halt auch ein Maß.
Da muss man halt gucken, welche Vorteile bringt das für den Team,
sollen sie halt beim selben Technologien abweichen.
Und wenn das halt, was ja auch mal vorkommt,
dass die Entwickler hier Spieltrieb halt da irgendwie ausleben wollen,
dann sage ich, okay, dann sagt man vielleicht Zeit für sogenannte Teams,
für sogenannte Pet-Projekte,
den Entwickler einräumen,
dass sie sich da ihre Spieltriebe ausleben können
und das natürlich in Produktionsquotient ausprobieren.
Wenn ich so die Teams anschaue, die ich sehe,
wie gesagt, bin ja kein Entwickler,
bin ja eher der Betriebswirt.
Was ich aber als Riesenvorteil sehe, ist,
du hast ja auch gerade den Spieltrieb angesprochen von den Entwicklern,
das wollen wir nicht auf die Entwickler immer so draufschlagen,
aber was ich eben als Vorteil sehe, ist,
dass wir wirklich eine zentrale Quelle haben, wo es funktioniert.
Und eben nicht jeder sagt ja, bei mir auf meiner Maschine funktioniert es,
sondern dass ich durch dieses Continuous Build einkomme,
dass ich wirklich eine zentrale Stelle habe,
wo es dann schon sehr früh funktioniert
oder sehr früh überprüft wird, ob es funktioniert
und nicht auf den einzelnen getunten Maschinen der Entwickler.
Ja, genau.
Also das ist halt der Vorteil, warum man das einführen möchte
und warum man auch da investieren sollte.
Also ich hatte mal einen Kunden gehabt, der meinte,
der sah die Auslieferung so aus,
dass sie sich halt eine Woche vor geplantem Auslieferungstermin
einen Rechner gesucht haben, bei dem in Eclipse
die Software halt gebaut wurden konnte.
Und ja, und da kam ich dann mit so einem Build-Tool daher,
habe das mal automatisiert
und dann hat man Release-Zeiten von einer Woche reduziert,
halt erst mal auf den Tag her.
Also dass man nicht mehr gezwungen war,
also eine Maschine zu suchen,
wo alles halt kompilier- und baubar war, ja.
Also das ist jetzt nicht nur in der Theorie,
sondern in der Praxis habe ich das selber so erlebt.
Okay, gut.
Wenn wir diesen Punkt jetzt so langsam zum Abschluss bringen,
vielleicht eine Frage noch.
Was sollte man denn beachten,
wenn ich das Thema Build automatisieren möchte?
Gibt es ein paar Punkte, die man da beachten sollte aus deiner Sicht?
Ja, also wenn ich mich auf ein Build-Tool einige,
dann soll ich nicht versuchen, gegen Best Practices mich zu wehren.
Und nur weil ich halt, ja,
denke, dass eine bestimmte Struktur oder Anwendungsfälle
oder Lifecycle mir besser gefallen,
aber das Build-Tool unterstützt das nicht,
weil die eigentlich ein ganz anderes Konzept dahinter stellen.
Dann sollte ich nicht gegen dieses Build-Tool halt ankämpfen
und das so biegen, wie das für mich passt.
Denn die Erfahrung zeigt, das bringt nur Schmerzen.
Ich kann wenig Support von der Community bekommen,
sondern dass ich mich dann auf die Idee
und auf das Konzept des Build-Tools mich dann auch aufstütze.
Okay.
Das sind schon solche einfache Geschichten,
wie zum Beispiel die Ordnerstruktur für meines Projektes aussehen soll.
Also zum Beispiel bei Maven ist das so,
dass das halt eine bestimmte Ordnerstruktur halt vorgibt.
Die Erfahrung zeigt halt, wenn ich mich halt bestimmte Konventionen halt halte,
habe ich dann in meiner täglichen Arbeit halt weniger Schmerzen.
Das heißt, ich kann mich dann wirklich auf Feature-Entwicklungen konzentrieren
und dann nicht wieder mit, mich tagelang mit dem Build-Tool beschäftigen.
Ich finde das interessant, weil wenn ich das übertrage auf das Thema Business,
da haben wir eigentlich das Gleiche,
dass eben ja viele, wenn ich jetzt mal in ganz große Parallele ziehe,
SAP oder überhaupt ERP-Projekte,
dass die auch dann ihre Schwierigkeiten haben,
wenn sich die Personen, die mit den Tools arbeiten sollen,
eben nicht umstellen wollen.
Wenn ich also anfange, die Standard-Tools zu verbiegeln,
um individuelle Abläufe zu ermöglichen.
Und das klingt hier ja für mich genauso.
Genau, ich fand deswegen…
Standardisierung.
Genau, genau.
Aber da ist halt beim Business,
da kann man natürlich auch hinterfragen,
ist es sinnvoll, dass ich meinen Geschäftsprozess halt an die Software,
nur weil da das SAP draufsteht, anpasse?
Dann wird daraus für mich eher auch ein Schuh, wo ich sage,
okay, ist es nicht sinnvoll, dass ich mir vielleicht eine Software bauen lasse,
die genau auf meinen Prozess halt abwählt?
Ich meine, da gibt es genügend Startups, die das halt dann machen.
Die kaufen kein SAP-System, sondern die haben halt eine Idee
und bauen halt die Software, die zu ihren Geschäftsprozessen halt passt.
Aber diese Idee lässt sich jetzt…
Also bevor jemand sagt, man soll sich eigene Build-Tools schreiben.
Nein, also das kann man nicht zurückführen auf den Bildverlauf,
denn wenn ich eine Java-Webanwendung bauen muss,
das läuft immer eigentlich nach dem selben Muster ab.
Also da muss man jetzt nicht unbedingt zwingend sein eigenes Bild holen.
Also ich weiß, Google und Facebook machen das.
Die bauen ihre eigenen Tools.
Aber dann kommt dieser Standard-Beraterspruch halt.
Nicht jeder ist halt Google, oder?
Google oder Facebook an der Stelle.
Wobei wir auch jetzt die Diskussion ausführen könnten,
wenn wir mehr Zeit hätten,
ob auch nicht ein Auftragsabwicklungsprozess im Business überall gleich aussehen könnte.
Es gibt vielleicht einzelne Ausstiege, die ein bisschen unterschiedlich sind,
aber das würde uns wahrscheinlich wieder vom Thema abführen
und dann müssen wir uns auf die dritte Folge einfach verabreden.
Also insofern, ich würde, wenn du jetzt nicht ganz Wichtiges noch hast,
Thema Continuous Build verlassen und die nächste Perle zupfen.
Die nächste Perle Continuous Test.
Die nächste Perle Continuous Testing.
Ja.
Ja, das ist leider immer noch ein leidiges Thema bei uns in der Softwareentwicklung, das Testen.
Man fängt ja irgendwie mit manuellen Tests halt an,
aber das wird bei kleinen Projekten, da ist der Aufwand relativ noch überschaubar.
Je größer das Projekt wird, desto größer sind dann die manuellen Tests.
Und dann merkt man halt auch, wenn man die Sachen immer wieder dasselbe tut,
der Mensch ist einfach nicht dafür geschaffen,
wiederholbare Abläufe in derselben Qualität abzuliefern.
Das kann halt eine Maschine halt eindeutig besser.
Und da ist halt die Idee entstanden, okay, wieso kann ich meine Testabläufe,
wenn das immer wiederkehrend ist, auch nicht automatisieren.
Und ich meine, das kann man halt auch mit Sourcecode abwickeln.
Also ich schreibe meine Tests in derselben Sprache, wie ich auch mein Produktionscode halt abteste.
Und dann fange ich halt auf verschiedenen Ebenen halt an.
Also bei Entwicklertest, das heißt, das sind Tests, was die Entwickler selber schreiben.
Und da kommen auch dann verschiedene Methoden mit rein, wie man das macht.
Also ich persönlich bevorzuge Test-Driven-Development.
Das heißt, bevor ich mit meinem Produktionscode anfange zu schreiben, schreibe ich erstmal den Test dazu
und gucke dann, okay, passt der Produktionscode zum Test?
Und das hat für mich dann als Entwickler so ein Sicherheitsnetz.
Das heißt, wenn ich dann auch mal Änderungen mache, weiß ich immer,
im Hintergrund laufen irgendwelche Tests ab, die gucken, ob das, was ich tue,
ob das keine Auswirkungen hat auf das Gesamtverhalten vom System.
Ja, und da gibt es halt verschiedene Stufen.
Also ich habe ja vorhin den Entwicklertest genannt.
Dann teste ich vielleicht die Interaktion zwischen den Systemen.
Das kann ich auch automatisiert tun.
Der Tester an sich, der fängt auch mit automatisierten Tests.
Ich kann UI-Tests auch automatisieren, obwohl sie recht teuer sind in der Ausführung.
Das heißt, dann muss man auch ein bisschen gucken, ob ich wirklich alles damit abtesten möchte
oder ob ich das nicht vielleicht für den nicht so kostspieligeren, also eher Richtung Entwicklertest,
das dann runterskaliere.
Und dann trotzdem bleiben immer noch manuelle Tests.
Meiner Ansicht nach haben sie Sinn, wenn das solche explorativen Tests sein sollen.
Das heißt, wenn ich einfach mal ausprobieren möchte, wie die Software sich verhält,
wenn der User etwas macht, was man nicht erwartet.
Also wenn er die Software benutzt, nicht so, wie es im Handbuch steht.
Also beziehungsweise kommt eher das dazu.
Ich meine, wer liest heutzutage Handbücher?
Wenn es sie noch gibt.
Ja, genau.
Wenn es sie überhaupt noch gibt, ja.
Und im Endeffekt ist das ja so, man macht die Software auf und klickt erstmal mit drauf rum,
gucken, wie die darauf reagiert, ja.
Und da erwartet man trotzdem, dass die Software halt robust läuft.
Und das sind für mich so Tests, die man am besten halt manuell mal durchlässt,
um zu gucken, wie reagiert die Software, wenn man etwas Unerwartetes tut.
Ja, wenn ich jetzt den Bogen mal spanne vom Continuous Build zum Continuous Testing,
in beiden Fällen habe ich ja den Fall,
dass die Entwickler eben auf ihren lokalen Rechnern das durchführen.
Das heißt, die machen sowohl das Build, das hatten wir ja besprochen, wie auch das Testen.
Und damit kriege ich ja auch noch mehr Qualität in den gesamten Erstellungs- und Auslieferungsprozess.
Genau.
Also ich habe dann mehr Feedback-Information.
Das heißt, ich weiß dann auf der einen Seite, okay, ich habe ein Source Code,
was auf jeden Fall sonntags fehlerfrei ist, weil es kompilierfähig ist.
Und mit den Tests habe ich die ersten Indizien dafür auch, dass die Software auch das tut,
was man von ihr erwartet.
Und gerade die Entwickler-Tests werden auch in diesen Build-Tools halt mit eingebunden.
Und das heißt, wenn ich dann mein Build starte, dann laufen zumindest auch noch Entwickler-Tests mit.
Und wenn diese Entwickler-Tests erfolgreich sind, dann wird daraus auch ein fertiges Software-Artifakt gestellt,
die ich dann später halt zum Beispiel meinen Testern, damit sie zum Beispiel UI-Tests
oder Explorationstests halt machen können, dann zur Verfügung stelle.
Also da unterstützt ihr mich.
Also dann kann ich die Tests, den Testlauf schon überprüfen.
Dann kann ich die Tests, den Testlauf schon in meinem Build mit rein integrieren.
Wenn ich mal überlege, wenn ich dahin komme, dass die Entwickler alle Tests wirklich codieren,
also alle Tests entwickeln und automatisieren, dann habe ich damit ja auch den Vorteil,
dass ich eben diese Verschwendung von ich mache es immer wieder manuell vermeide.
Im Sinne von Lean und von Kanban, dass ich eben einfach wirklich Dinge nur einmal durchführe
und danach werden sie eben automatisiert und ich muss es eben nicht immer manuell tun.
Genau.
Es gibt ja auch Stimmen, die sagen halt, ja, warum soll ich jetzt teure Entwicklerstunden
dafür investieren, dass ich Tests schreibe?
Dafür habe ich ja meine Tester.
Also ich habe auch schon mal Kunden erlebt, die gesagt haben, die Entwickler-Tests dürfen
in Entwickler geschrieben werden, die werden nachgelagert von unseren Testern geschrieben.
Naja, und das Problem, also ich finde halt, dass da immer, also Sala sagt nicht, dass die Tester,
die haben auch immer ihre Daseinsbefugnis, aber die sollten halt andere Sachen testen.
Als was ich als Entwickler, also die trivialen Geschichten kriege ich auch als Entwickler selber hin,
beziehungsweise ich weiß, ich sehe ja, kriege dann direkt beim Wickeln auch das Feedback von wegen,
das, was ich mir ausdenke, funktioniert das überhaupt?
Und wenn ich diese Tests nicht schreiben dürfte, wie würde ich das sonst machen?
Ich würde dann vielleicht trotzdem auf der Kommando-Line irgendwie starten und mal mich selber durchklicken,
um zu gucken, ja, tut es überhaupt das, was es tun soll?
Und dann kann ich die Zeit auch nutzen, um halt diesen Tester zu schreiben.
Also jetzt für Lioness versucht zu erklären.
Ja, ja.
Oder ich verliere natürlich die Geschwindigkeit, wenn ich also dann als Entwickler gar nicht teste,
weil das die Tester nachher machen, dann kriege ich ja die Rückmeldung, das Feedback, wo du immer mehr darauf hinweist,
eben sehr viel später oder zu spät.
Also natürlich kann ich das durchrechnen und sagen, so eine Entwicklerstunde ist teurer als eine Testerstunde.
Das ist aber, wie ich finde, dann auch eine relativ kurzfristige Betrachtungsweise.
Also was ich sehr cool fand in meinem Projekt, das habe ich dann vom QA-Team auch direkt als Feedback bekommen,
die haben mir gesagt, also sie wissen, wenn sie ein Feature von der Sandra bekommen,
dann die Happy Cases, die werden auf jeden Fall laufen, die können sich dann halt auf andere Sachen spezialisieren, gucken,
weil sie wussten halt, dass ich halt einen Entwicklertest schreibe.
Bei anderen Entwicklern, die das vielleicht dann selber in meine Oberfläche durchgeklickert haben,
da haben sie immer wieder Sachen gefunden, also auf dem Papier scheint das trivial in Geschichten dann zu sein.
Und das heißt, sie mussten das wieder zurückmelden.
An den Entwicklern, der Entwickler musste sich dann wieder einarbeiten und so weiter.
Also Feedback-Schleifen waren halt unheimlich lang.
Also ich fand das eine tolle Feedback-Form, das hat mich dann auch bestätigt,
meine Arbeitsweise da, auch wenn das Management ein bisschen am Rummieren war.
Also Papier brauchte ich natürlich länger als andere Entwickler, bevor ich das zum QA-Team übergeben hatte.
Aber ich habe das dann wieder rausgekriegt, weil die Zeit,
wo es Richtung Produktion ging, halt geringer war als bei den anderen Entwicklern.
Also wenn man das für mich vergleicht, dann sind das auch immer philosophische Diskussionen.
Weil das, was du vielleicht teurer warst, habt ihr an anderer Stelle eingespart.
Aber das kann ja niemand wirklich nachrechnen oder errechnen, wo der Vorteil ist an der Stelle.
Sondern das ist einfach eine philosophische Betrachtungsweise, wie ich finde,
zu sagen, liefere ich gute Qualität ab und dann brauchst du vielleicht länger und du bist vielleicht auch teurer.
Aber dadurch hat man andere Vorteile, die man eben so gar nicht bewerten kann.
Ja genau, man muss halt abstrakte Rechnungen machen.
Also man weiß zum Beispiel, dass wenn ich meine Arbeit unterbrechen muss,
dass ich, bis ich wieder im Kontext drin bin, dann gibt es ja solche Größen, wo man sagt,
man braucht durchschnittlich 10 bis 15 Minuten, bis man wieder im Kontext ist.
Und der Entwickler, der ständig einen Anruf von QA-Abteilung kriegt,
der wird ja natürlich dann schon im nächsten Feature schon sitzen.
Das heißt, das muss er abbrechen, dann muss er sich wieder reindenken beim alten Feature, wie wäre das nochmal.
Also man kann dann nur eine abstrakte Rechnung machen.
Vollkommen richtig. Und die Anrufe nimmt er vielleicht irgendwann gar nicht mehr entgegen, weil die immer wieder nerven.
Ja genau.
Dann lasst uns mal auf den nächsten Punkt gehen, der in dem Spicker nicht beschrieben ist,
aber wir sollten ihn aufgrund der Durchgängigkeit schon kurz ansprechen.
Das ist das Thema Continuous Inspection. Was verstehst du da drunter?
Ja und das geht halt darum, irgendwann hat man ja festgestellt, ich krieg die Qualität schon, also unsere innere Qualität,
also das innere Qualität, das sagen wir im Entwickler dazu, ob der Source Code halt lesbar ist.
Meine Lieblingsanalogie für LINE ist halt, wenn ich einen Text lese und der besteht aus Bandwürmern,
der ist unheimlich schwer zu lesen und ich brauch drei, vier Anleufe, bis ich eigentlich den Sinn dieses Textes verstanden habe.
Und wenn ich dann diesen Text nochmal umschreibe in kürzere Sätze, dann ist er meistens dann viel lesbarer für die,
auch für Leute, die nicht in der Thematik drin sind.
Und so ähnlich ist es gelagert auch mit dem Source Code, also ich kann einen Source Code schreiben,
der für die Maschine wunderbar ausführbar ist.
Aber für meinen Entwicklerkollegen, der vielleicht da einen Bug fixen muss,
dann kann ich das sehr relativ schwer, den Source Code so schreiben, dass es schwer zu verstehen ist.
Das heißt, ich soll meinen Source Code so schreiben, dass er auch für jemanden anders,
der jetzt nicht in der Thematik drin ist, leicht lesbar ist, damit er sich leichter einarbeiten kann.
Und dann hat man gesagt, okay, dann lass Code Reviews machen.
Das heißt, dass, indem ich meine Arbeit abgeschlossen habe,
dass ich mir einen Kollegen nehme, der nochmal drüber schaut und guckt, ob es einen Feedback dazu gibt.
Und da stellt sich heraus, dass es mit der Zeit immer so gewisse Best Practices, also Muster gibt,
die immer wieder kehren sind, wo dann man sagt, okay, eigentlich könnte ich auch eine Maschine drüberlaufen lassen,
die mir dann sagt, hey, an der Stelle ist ein potenzieller Bug drin, aufgrund der, wie du das geschrieben hast.
Oder hey, du hast hier eine, wir sagen dann halt so Bedingungskomplexität,
das heißt, wenn wir viele Fallunterscheidungen haben,
Fallunterscheidungen haben im Code und auch gerne auch verschachtelt.
Das ist, dann kann man sich vielleicht vorstellen, okay, wenn ich ganz oben in Source Code eine Bedingung habe,
die muss ich mir aber im Kopf behalten, weil sie 100 Zeilen später Auswirkungen auf eine andere Bedingung hat,
kann man sich vielleicht vorstellen, dass es vielleicht schwierig ist.
Man muss da sehr hoch konzentriert sein.
Und dann gibt es halt Tooling, die mir dann sagen kann, hey, deine Komplexität an der Stelle ist hier relativ hoch.
Meinst du nicht, dass wir das nochmal überarbeiten?
Das heißt aber nicht, dass jetzt diese Code Reviews überflüssig werden, sondern das ist nur eine Unterstützung.
Dass man sich auf so, Anführungsstrichen, Trivialitäten schon Feedback von der Maschine holt.
Und wenn das schon mal gut durchgelaufen ist, dass ich dann mit meinen Kollegen nochmal drüber gehe
und dann vielleicht über das Design sich unterhalten kann, wenn ich vielleicht andere Designpattern an der Stelle
oder ob ich dann vielleicht eine Architekturverletzung drin habe und mich unterhalten kann.
Ja, okay.
Und dann gibt es noch andere Trivialitäten, wie zum Beispiel, also wie blieb es der Kampf unter den Weglern ist,
ob ich für eine Rückung jetzt Tabs benutze oder Leere.
Ja, okay.
Oder Leerzeichen.
Das ist, ehrlich gesagt, für den Laien schwer zu erklären, warum man darüber diskutieren muss.
Ich handhabe das so, dass ich mich einfach, also ich komme meistens von den laufenden Projekten,
ich frage einfach nach, was habt ihr, Tabs oder Spaces.
Und dann kann ich halt auch so eine Maschine drüber laufen lassen und dann so, um zu gucken,
ob die Leute sich solche Trivialitäten überhaupt einhalten.
Dann muss ich das nämlich auch nicht mit einem Code Review umschlagen.
Aber ich kann dich beruhigen.
Diese Problematik kenne ich genauso, wenn es um das Thema geht, wie baue ich Folien auf.
Also selbst bei PowerPoint-Folien gibt es die Frage.
Oder bei Word-Texten arbeite ich mit Tabs, mache ich dafür einen neuen, mache ich einen Zeilenumbruch.
Also diese Banalitäten, wie du sie nennst, gibt es wahrscheinlich auch dann in allen Ecken und Enden.
Ja, super.
Jetzt heißt unser Podcast oder diese Folge ja Tool-Parade.
Wir haben eben vergessen, beim Continuous Testing über ein paar Tools zu sprechen.
Ich würde die nur der Vollständigkeit halber nochmal erwähnen.
Wie gesagt, in den Notes gibt es ja auch deinen Spicker dazu.
Also beim Continuous Testing reden wir über Tools wie xUnit, jUnit.
xUnit, jBehave, Selenium, Jasmin, alles ganz schöne Namen.
Beim Continuous Inspection, hast du da mal so zwei, drei Tools, die man besprechen sollte?
Also wenn es zum Beispiel nur darum geht, abzutesten, ob die Einrückungen richtig sind.
Da wird gerne im Java-Umfeld CheckStyle benutzt.
Wenn ich zum Beispiel im JavaScript-Umfeld unterwegs bin, um zu gucken, ob man sich so am Best-Practice hält,
um potenziellen Bugs aus dem Weg zu gehen, da gibt es diesen JS-Lint.
Dann…
Ich kann diese Tooling auch dazu benutzen, um zu gucken, wie meine Testabdeckung ist.
Das heißt, ob die Tests auch alle möglichen Stellen meines Codes durchlaufen.
Da gibt es im Java-Umfeld zum Beispiel das Yakoko.
Der misst dann halt, wie hoch meine Testabdeckung ist.
Und dann das Mega-Tool im Java-Umfeld, wo man mal denkt, wenn ich das Tool einsetze,
dann werde ich alle meine Code-Analyse-Probleme aus dem Wind schaffen, ist SonarCube.
Aber man darf sich da jetzt auch nicht blenden lassen.
Man muss da ja auch wieder Zeit und Energie einsetzen.
Die Leute müssen ihre Arbeitsweisen anpassen, wenn ich dann solche Tooling einsetze.
Also ich fahre meistens mit einem Minimal-Set.
Was ich auf jeden Fall mache, ist halt, dass ich Yakoko und CheckStyle und für potenziellen Bugs
halt vielleicht noch SpotBugs einsetze.
Und das kann ich auch wieder in meinen Bildlauf mit einbauen.
Das heißt, wenn da irgendwelche Regelverletzungen gibt, dass das Bild auch bricht
und auch keine Software-Artefakte angebaut werden.
Und wenn das nicht ausreicht und der Kunde mehr möchte und auch bereit ist,
seine Arbeitsweise umzusetzen, dann kann ich das auch einsetzen.
Und wenn das nicht ausreicht und der Kunde mehr möchte und bereit ist,
seine Arbeitsweise umzusetzen, dann kann ich das auch einsetzen.
Dann nehme ich solche Plopper wie SonarCube an der Stelle.
Okay.
Für das Management ist das halt fancy.
So ein SonarCube hat eine fancy Web-Oberfläche.
Da kann man ganz tolle Zahlen daraus generieren.
Einiges Verkaufsargument wahrscheinlich.
Ja, genau.
Und bei SpotBug, CheckStyle oder Yakoko, da merkt man halt,
das ist halt eine andere Zielgruppe.
Da bekomme ich halt so Kommando-Lines-Ausgaben.
Vielleicht kann ich noch HTML-Reports ausgenerieren,
aber die sehen halt nicht so fancy aus.
Ja, okay.
Gut, dann gucken wir mal zum nächsten Punkt
auf deiner Perlenkette.
Und der ist auch in dem Sticker wieder beschrieben.
Continuous Database Integration.
Was muss ich mir darunter vorstellen?
Ja, also das ist Persistenz an der Stelle.
Und das ist halt,
also ich habe jetzt keine Zahlen, aber in den Projekten,
wo ich eigentlich bisher zu 90 Prozent,
also das ist eine persönliche Wahrnehmung,
zu 90 Prozent wird halt Persistenz
gerne an eine relationale
Datenbank eingesetzt.
Es gibt dann auch andere Daten,
so NoSQL, das sind so dokumentenbasierte,
oder Key-Value-Datenbanken,
aber was ich halt
meistens sehe ist, da werden halt
gerne relationale Datenbanken.
Naja, die relationalen Datenbanken haben halt,
was heißt Problem, also
das ist halt eine Eigenschaft von relationalen Datenbanken,
dass ich halt da die Tabellenstruktur
halt beschreiben muss. Das heißt,
ich muss sagen, hey, leg mir bitte
folgende Tabellen an, die haben
folgende Spalten, in diesen Spalten
dürfen nur bestimmte Datentypen
eingespeichert werden. Und dann ist die Herausforderung
ja, meine Software und meine Anforderungen,
die ändert sich halt mit der Zeit. Am liebsten,
das tun aber auch nicht alle,
müsste eigentlich auch meine Datenbankstruktur
mit der Zeit sich auch verändern. Und das wird
eine Zeit lang wurde sehr wenig gemacht,
weil man Angst hatte,
da was zu ändern, das könnte ja was kaputt gehen,
oder Daten verloren gehen.
Das heißt, man hat dann angefangen,
in den bestehenden Strukturen
irgendwas reinzuflanschen. Das läuft
vielleicht paar Mal, paar Jahre gut, aber irgendwann
ist dann diese ganze Datenbankstruktur
so unübersichtlich, dass man
das relativ dann schon wegen der Datenbankstruktur
sagt, okay, eigentlich müssen wir das nochmal neu schreiben.
Ist aber eigentlich keine Lösung darin.
Naja, und dann
hat man gedacht, okay, irgendwie möchte ich ja
meine Datenbanken auch
irgendwie automatisiert, also die Änderungen
an der Datenbankstruktur irgendwie auch
automatisiert testen. Und dann fängt man halt
an auch Skripte zu schreiben, die halt
meine Datenbank verändert. Und dass man die
halt mit abtestet, so wie
meinen normalen Source-Code. Und das ist eigentlich auch das Verwunderliche
an der ganzen Geschichte, also
das ist mir noch vor wenigen Jahren
rübergekommen, also dass man so Java-Code,
oder JavaScript-Code in ein
Visionskontrollsystem ablegen muss.
Das war für die Leute schon klar
und hat Mama fleißig gemacht.
Aber die Skripte für die Datenbankstruktur,
was eigentlich auch
Bestandteil der Software sein sollte, die flogen
dann irgendwelchen Tickets, Handbüchern,
E-Mails herum. Und dann
die arme Sau, die am Wochenende dann
diese neuen Rollout machen musste,
der musste dann halt sich die Sachen vorher irgendwie
zusammensuchen und hoffen, dass das halt dann
irgendwann funktioniert übers Wochenende.
Also im Java-Umfeld
sind mir nur zwei geläufig,
Flyway und Liquibase, und
die unterstützen mich darin, einmal,
dass diese Skripte automatisiert mit
ablaufen, das heißt, wenn ich eine neue Release-Version
meiner Software habe, dass sie dafür Sorge tragen,
dass auch die Datenbank, die unterliegende Datenbank
damit abgedatet wird.
Die kann ich dann auch fürs Testen halt dann auch benutzen,
um zu gucken, hey, wie funktionieren sie überhaupt. Und das Schöne
ist auch, sie schreiben auch in der Datenbank
so eine Änderungshistorie. Das heißt, ich kann,
wenn es zu Problemen kommt, genau nachvollziehen,
welche Skripte auf
welcher Datenbankinstanz, wann
liefen, und so habe ich dann
einen Überblick von wegen, okay, das ist
der Zustand dieser Datenbank, weil
folgende Skripte gelaufen sind.
Hat aber auch wieder Auswirkungen auf den Entwickler,
das heißt, den Helden spielen
und mal schnell auf Produktion
die Datenbankstruktur ändern
oder Daten löschen, ist da halt nicht mehr.
Weil dann wird das ganze System wieder ad absurdum geführt.
Und wenn ich mal schaue, über welche
Tools reden wir dann da?
Ja, da kommen wir eigentlich schon mehr Richtung
Operation. Das geht halt darum, dass ich
also
für den Laien gesprochen, wenn ich so einen Laptop bestelle,
das ist meistens, wenn ich Glück habe, vielleicht nur
ein Windows drauf, oder manchmal ist es auch blank.
Und dann setze ich mich am Wochenende hin
und bin mir Windows am installieren oder
ein anderes System
und meine ganze Software drauf am spielen.
Und
sowas muss man sich vorstellen, das gibt es auch im Serverbereich.
Nur im Serverbereich ist es ja nicht so, dass ich
alle paar Jahre mal einen Server neu installiere,
sondern da muss ja kontinuierlich
Updates aufgespielt werden,
neuer Bedarf ist da, das heißt, neue
Server müssen bestellt werden, dann möchte ich gerne, dass jeder
Server gleich aufgesetzt wird und nicht unterschiedlich,
sodass
ich weiß, okay, wenn das auf diesem Server läuft, dann wird
das auf dem nächsten Server auch laufen. Ja, und dann
automatisiere ich da an der Stelle.
Das heißt, ich schreibe mir auch solche
sogenannte Provisionierungsskripte,
das ist auch wieder Code,
das heißt, das gehört auch wieder in
mein Provisionierungskontrollsystem
und das hat auch,
das heißt, wenn ich einen neuen Server habe oder
Änderungen fahren möchte, dann rufe ich halt
diese Skripte auf, die den Server
dann genau so anpassen, wie ich es in meinem
System steht. Hat auch hier wieder
Auswirkungen auf den Entwickler.
Ich darf nicht
irgendwas manuell auf den Kisten machen,
sondern alles muss über Skripte
verteilt werden.
Und
ja,
ein paar Toolings zu nennen,
also die Platzhörscher
an der Stelle sind halt
Ansible, Puppet,
vielleicht Chef, gibt auch
Tooling, die nicht so verbreitet sind,
wie Salt,
so, wenn jemand sich wundert, warum ich
jetzt Docker nicht genannt habe, ja, weil Docker
kein Konfigurationsmanagement-Tooling ist,
das ist halt eine Containertechnologie, das heißt,
ich benutze mal ein Konfigurationsmanagement-Tool
wie Ansible und Puppet,
um halt meinen Docker-Demon
auf meinen Server zu installieren.
Mhm, okay.
Welche Vorteile habe ich
von einem automatisierten
Konfigurationsmanagement? Kannst du das mal
vielleicht ganz kurz nochmal aufzählen?
Der Vorteil ist halt, ich
weiß, ich habe
einen Server, und die sehen
alle gleich aus, weil sie mit den gleichen Skripten halt
installiert worden sind.
Und da habe ich
nicht die Effekte, dass zum Beispiel auf meinem
Testsystem die Software läuft, aber auf Produktion nicht,
weil die
unterschiedliche
vielleicht Softwarestände draufinstalliert haben vom
Betriebssystem oder sowas. Das kommt ja auch schon manchmal vor.
Und damit kann ich halt sicherstellen,
wenn ich die
Provisionsskripte von meinem Produktionsserver nehme
und damit einen Testserver aufsetze,
dass ich das Risiko halt da an der Stelle
minimiere, dass ich dann Richtung Produktionsgang
dann nochmal irgendwelche Überraschungen kriege.
Ja, okay, gut.
Dann der nächste Schritt, automatisierte
Verteilung.
Da
geht es halt darum, dass
ich jetzt hier meinen,
mit meinen Entwicklern halt die Software
gebaut habe,
zusammengeschnitten in so ein Softwareartifakt,
und dann geht es halt darum, dass ich dieses
Softwareartifakt
halt auf den Server draufkriege.
Und das ist nicht nur, dass ich
dieses Artifakt rüber kopieren muss,
sondern ich muss
Konfigurationen
mit ausspielen, und dann ist es halt so, wenn ich
dann mehrere Umgebungen habe, wie Tests, Produktionen
und verschiedene
Staging,
dann ist natürlich die Konfiguration
ist dann, sieht immer anders aus,
weil ich dann andere Datenbankverbindungen brauche,
andere User,
vielleicht andere Timeouts,
also gibt es verschiedene Spielarten.
Und die Idee dahinter ist halt,
dass ich ein Softwareartifakt habe,
für alle Umgebungen,
und dieses Artifakt halt
weiß, wie er sich in Umgebungen
zu verhalten hat, anhand der Konfiguration.
Da gibt es halt verschiedene Möglichkeiten,
das halt zu machen. Ich kann dann sagen, okay,
ich spiele das Softwareartifakt,
und der guckt dann lokal
auf den Server, wo er drauf ist,
hey, wie soll ich mich konfigurieren?
Oder er fragt halt einen Konfigurationsserver ab,
hey, ich bin auf der Kiste
XYZ,
wie sehen die Konfigurationen dafür halt aus?
Oder ganz klassisch,
ich schiebe mit dem
Softwareartifakt
meine Konfigurationsdateien
mit auf der Kiste.
Und was für mich
ganz wichtig ist an der Stelle, ist immer,
ich muss diesen
Bildvorgang, also wie ich mein Softwareartifakt baue,
und meinen Deploymentvorgang
immer trennen. Das heißt, wenn
der Bild fehlgeschlagen ist,
darf das keine Auswirkungen auf den
Deploymentvorgang haben, das heißt, wenn ich dann mal ein neues Deployment
mache, dann geht das immer mit dem letzten
funktionierenden Stand raus.
Und das heißt, wenn ich auch meine,
beim Test dann zum Beispiel meinen
Server halt kaputt getestet habe,
dass er
ein fertiges Softwareartifakt immer wieder neu
draufspielen kann, ohne dass er den
vorgelagerten Bild
Vorgang nochmal antriggern muss.
Antriggern muss, jawohl, okay.
Wenn wir hier über Tools sprechen, du hast ja
eben bei dem Konfigurationsmanagement
schon über ein paar Tools gesprochen,
und soweit ich das weiß, gibt’s ein paar Tools,
die quasi in den beiden Bereichen tätig sind.
Genau. Wie zum Beispiel Ansible.
Genau. Also ich persönlich
nutze dann meistens recht Ansible.
Es können
aber auch Shell-Skripte sein.
Oder was eigenes geschriebenes.
Das muss jetzt nicht, also ich habe auch schon mal
gesehen, dass man ganz einfache Shell-Skripte
schreibt.
Das wäre zum Beispiel
ein gangbarer Weg, wenn man zum Beispiel als
Softwareartifakt, also das Format her zum Beispiel
so ein Docker-Container ist,
dann reicht zum Beispiel auch vollkommen aus zu sagen,
okay, ich schreibe ein Shell-Skript, der diese Container
auf die Maschinen halt verteilt.
Oder wenn ich halt in größeren Umgebungen bin,
also vor allem in der Containerwelt, dann
sind ja solche Sachen wie
Kubernetes oder Docker Swarm
dann halt gehypt, und die helfen einem auch dabei,
die Sachen halt zu verteilen und sogar
automatisiert zu verteilen. Die haben aber
natürlich noch andere Aufgaben, aber das sind dann spezielle
Containereigenschaften,
die sie dann vermitteln.
Gut.
Dann, soweit ich
deinen Spicker verstanden habe, hier wären wir
jetzt durch, was so das ganze Thema
Tooling angeht. Habe ich das richtig
verstanden oder richtig interpretiert?
Jawohl. Weil wir haben jetzt auf deinem
Spicker noch ein paar Themen,
wo ich sagen würde, Mensch, da könnte man vielleicht nochmal
einen separaten Podcast für machen, eine separate
Aufnahme, weil das ja eben
nicht mehr die Tools an sich sind.
Also, wenn du einverstanden bist, würde ich
sagen, beenden wir jetzt die Toolparade.
Ja, gerne.
Okay, gut. Also,
beenden heißt Toolparade, aber
wie gesagt, der Spicker bietet noch Chancen, ein paar
andere Sachen zu machen. Ja, vielleicht
machen wir später nochmal
eine weitere Aufnahme und greifen
dann nochmal drauf zurück.
Gibt es irgendwo einen Punkt, den du nochmal so
beim Rückblick auf diese beiden Folgen nochmal
ergänzen wollen würdest, oder
war das für dich jetzt eine runde Sache?
Ja,
vielleicht ein abschließendes Wort, also
Tools gibt es halt reichlich,
aber im Endeffekt,
ich hoffe, das kam rüber, denn
das Sprichwort
noch seine Berechtigung hat,
Tool für Tool ist der
Tool. Das heißt, eigentlich
nützt es nicht, irgendwelche
Tooling einzuführen, sondern ich muss wirklich halt
Richtung
Organisationsstrukturen gehen und sagen, hey,
das Tool kann mich unterstützen,
aber auch nur, wenn ich mich
gewisse Arbeitsweisen halt dann
aneigne an der Stelle.
Das vielleicht so als Fazit von der ganzen
Geschichte. Also, aus meiner Sicht,
das habe ich dabei auch rausgehört, natürlich
kann ich über Tools reden, und
wenn ich jemandem die Freiheit lasse,
sich seine Tools auszusuchen, dann wird er natürlich
auch die Tools aussuchen, die ihm
genehm sind an der Stelle.
Und was ich eben rausgehört habe,
ist, dass man über das Thema
Tools schon sehr viel auch steuern kann,
und dass eben von der
Auswahl des Tools, oder dass die Auswahl
eines Tools und die effektive Nutzung,
dass das schon auch davon abhängt, welchen
Qualitätsanspruch haben die Entwickler
an der Stelle. Und das
denke ich, das wäre so aus meiner Sicht das, was du
gesagt hast mit dem Tool
und dem Fool an der Stelle.
Ja, genau. Gut, ja,
also dann bedanke ich mich
recht herzlich für die Unterstützung,
für diese beiden Folgen an der Stelle,
für das Verteilen, für das Teilen
deines Wissens an der Stelle,
und ich freue mich auf die nächste
Folge, die wir sicherlich nochmal machen,
zu dem Thema Continuous Controlling, Continuous
Observation, aber wie gesagt,
hier zum Thema Toolparade sind wir durch.
Vielen Dank, liebe Sandra. Vielen Dank.
Sehr gerne.
Vielen Dank.

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

Inhalt laden

Mit Sandra Parsick spreche ich über den Toolseinsatz im Rahmen von modernen Techniken aus Continuous Integration (CI) und Continuous Delivery (CD). Insbesondere unterstützt Continuous Delivery wichtige Architekturziele wie Stabilität und Reaktionsfähigkeit. Sandra hat einen sehr informativen „Spickzettel“ zum Thema Continuous Delivery erarbeitet, den wir zum Anlass nehmen, über die Perlenkette der Tools zu sprechen. Und wir hatten so viel zu besprechen, dass wir gleich noch eine weitere Folge angehängt haben, siehe dazu Teil 2.

In dieser Folge des DevOps-Podcasts wird eine tiefgreifende Diskussion über verschiedene DevOps-Tools und deren Einsatz in der Softwareentwicklung und im Betrieb geführt. Sandra Parsick, eine erfahrene Beraterin, und der Gastgeber Dierk Söllner erörtern die Bedeutung der Tools für die Automatisierung und Optimierung der Entwicklungsprozesse. Themen wie Continuous Delivery, Continuous Testing, Version Control Systems, und die Herausforderungen der Integration von Entwicklung und Betrieb werden ausführlich behandelt. Dabei wird auch auf die kulturellen Aspekte von DevOps und die Notwendigkeit der Anpassung von Arbeitsweisen und Unternehmenskulturen eingegangen.

Inhalt

• Einleitung und Vorstellung von Sandra Pasig
• Definition und kulturelle Aspekte von DevOps
• Bedeutung von Version Control Systems in DevOps
• Diskussion über Continuous Delivery und Testing
• Bedeutung von Continuous Inspection und statische Code-Analyse
• Datenbankintegration und Herausforderungen
• Konfigurationsmanagement in der Praxis
• Automatisierte Verteilung und Controlling von Software
• Rolle von Monitoring und Feedback-Systemen
• Diskussion über Organisationsstrukturen und Arbeitskulturen
• Verschiedene Arten der Versionsverwaltung

Shownotes

Die Basis unseres Gesprächs, der Architektur-Spicker

Webseite von Sandra Parsick

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 Folge DevOps Podcast auf die Ohren und ins Hirn. Das
heutige Thema ist die DevOps Toolparade. Wir hatten ja schon mal in einer Folge das
Periodensystem von den DevOps Tools mal so auf einer allgemeinen Ebene besprochen. Heute gehen
wir ein bisschen tiefer und ich freue mich auch auf den Gast, den ich dort habe. Sandra Pasig ist
erfahrene Beraterin und kennt sich mit den Tools aus in dem DevOps Umfeld. Also heute reden wir
über Technik, reden viel über Tools und ich würde sagen, Sandra, am besten stellst du dich einfach
mal vor. Ja, hallo Dirk. Danke für deine Einladung, dass ich hier dabei sein kann. Ja, wie du sagst,
Sandra Pasig mein Name. Ich bin freiberuflich als Softwareentwickler unterwegs, hauptsächlich im
Java Enterprise Umfeld. Gerne nach agilen Methoden und Software-Craftmanship-Prinzipien. Ich werde
aber auch gerne eingesetzt, deswegen hast du mich auch wahrscheinlich auch eingeladen, weil ich,
um die Entwicklungsprozesse zu automatisieren. Und das sind ja so Schlagwörter wie DevOps oder
Continuous Delivery, Integration. Ja, und dann geht es halt darum, halt Tools einzusetzen, um dann
zu automatisieren. Sehr schön. Ja, also wir sind genau drin und im Vorgespräch haben wir schon
herausgefunden, dass wir beide auf das Thema DevOps, auf den Begriff DevOps, unsere eigene,
aber eben gleiche Sicht haben. Und ich starte ja in meinem Podcast auch immer mit der Frage an meine
Gäste, wie sie DevOps beschreiben würden, wie sie DevOps definieren würden. Also insofern, Sandra,
wie würdest du DevOps definieren? Also für mich ist DevOps eigentlich ein Kulturbegriff,
hat eigentlich weniger mit Technik.
zu tun, sondern es geht eigentlich eher aus meiner Sicht darum, wie kriege ich diese Silos zwischen
Entwicklung und Operation oder Betrieb halt, also die Mauern halt abgerissen und wie kriege ich halt
die zwei Welten, die eigentlich in klassischer Sichtweise halt unterschiedliche Ziele haben,
irgendwie zusammen, sodass am Ende die Software besser oder schneller halt ausgeliefert werden
kann oder auch besser halt auch betrieben werden kann. Von daher so Sachen wie mit DevOps Engineer,
kann ich dann immer wenig anfangen, obwohl ich ja auch mich auf Projekte halt dann bewerbe,
wo DevOps Engineer drin ist, weil man muss dann meistens immer hinterfragen beim Kunden,
was die genau damit meinen. Aber was eigentlich, was für mich DevOps ist, ist eigentlich,
wie kriege ich zwei Welten zusammengeschmeidt, um dann besseres Software zu entwickeln und zu betreiben.
Ja, okay. Also auch du, selbst wo du aus der Technik kommst, aus meiner BWL-Sicht an der Stelle, sagst auch du, es ist eine Kultursicht und ja,
es geht um das Zusammenführen. Das ist natürlich richtig und insofern könnte es ja sein,
dass ich mit Tools ja auch eine Zusammenarbeit unterstütze.
Ja, natürlich. Also ich meine, das fängt ja schon bei den einfachsten Sachen an, wie zum Beispiel,
dass ich meinen Source-Code oder meine Konfigurationen ja versionieren sollte.
Also, dass diese Sachen nicht irgendwo auf Netzwerklaufwerke umschwirren oder lokal auf dem Rechner von einem Entwickler
oder Konfigurationsbeschreibungen, wenn es gut läuft, in einem Wiki oder wenn es schlecht läuft,
halt ein E-Mail-System oder in Word-Dokumenten, sondern dass ich zum Beispiel sowas in einem Visionskontrollsystem halt ablege.
Also das fängt ja schon damit ja an. Also ich meine, durch dieses Kulturelle, durch die Zusammenarbeit,
da wird auch erstmal auch der Bedarf ja geweckt, dass man anfängt halt Tools zu entwickeln.
Also es ist ja nicht so, dass jemand aus Spaß die Dinger entwickelt hat, sondern es sind ja auch irgendwelche Bedürfnisse entstanden.
Wenn wir den Begriff jetzt mal so nehmen, Continuous Delivery, du hast so einen wunderschönen Architekt,
du hast so einen Architekturspicker gebaut und den werde ich auch in die Shownotes verlinken.
Der ist sehr, sehr schön dargestellt und an dem werden wir auch uns entlanghangeln.
Und dieser Architekturspicker, der fängt so schön an mit dem Thema, worum geht es überhaupt?
Also welche Herausforderungen gibt es, wenn wir über das Thema reden, Continuous Delivery und welche Ziele verfolgen wir damit überhaupt?
Ja genau, das ging halt hauptsächlich einmal so, wie wir halt Risiken minimieren.
Das heißt,
da merkt man schon, wo dieser Gap ist zwischen Entwicklung und Betrieb.
Entwickler wollen halt, dass ihre Features, die sie entwickelt haben, so schnell wie möglich halt rausgehen.
Und der Betrieb hat aber eigentlich Angst, hier das mal neue Software rauszuhauen, weil das ist immer,
ja, da ist immer eine, man weiß halt nicht, wie die Software dann halt sich dann verhält in der Produktion.
Und da will man halt unter anderem durch Tool-Unterstützung oder durch, wie man sich zusammenrauft, halt dieses Risiko minimieren.
Also trotzdem schnell.
Ausliefern können, aber auf der anderen Seite das Risiko minimieren, dass die Entwickler, dass der Betrieb, Entschuldigung, an der Stelle die Angst abgenommen wird, dass das alles instabil wird.
Und dann ist es halt auch so, wir haben halt in der Softwareentwicklung öfter mal Aufgaben, die sind monoton, immer wiederkehren.
Und das, was der Mensch nicht kann, ist monotone, wiederholbare Tätigkeit mit derselben Qualität abzuliefern.
Und da ist die Frage, wie kriegen wir das?
Durch Tool-Unterstützung solche Aufgaben halt gelöst, sodass man nicht das Risiko hat, dass durch monotone Tätigkeit irgendwann mal Fehler halt sich reinschleichen.
Und dann will man auch gucken, okay, welche Auswirkungen haben eigentlich Änderungen in meinem Quellcode?
Oder wenn ich andere Technologien einsetze oder Konfigurationen ändere, dann möchte man das auch relativ früh im Entwicklungsprozess erkennen und nicht erst beim Gründen.
Wenn die Strafe beim Kunden halt läuft.
Und das sind so die Hauptpunkte, wo man sagen möchte, okay, das sind die Motivationen, worum ich denke, Tools oder worum ich automatisieren möchte.
Ja, also es geht im Prinzip dann, wenn ich es mal mit meinen Worten kurz zusammenfasse, es geht um Risikominimierung.
Ja, genau, BWLer, genau, Risikominimierung.
Und das zieht auch bei Controllern, die dann weiter Ausgaben bewilligen müssen, weil Tools kosten ja auch Geld.
Am besten muss ich ja noch Begriffe reindringen, wie Kostenminimierung.
Und Business Case, Business Case hilft auch nochmal.
Genau, dann Return of Invest war das auch noch so ein Begriff auf meiner BWL-Verlegung.
Ja, okay, wobei natürlich Risikominimierung finde ich schon, also es wäre für mich auch als Techniker, glaube ich, wäre das für mich ein Punkt.
Du hast ja gesagt, die Entwickler wollen, dass ihre Funktionen schnell in Produktion gehen.
Und ich würde mal hoffen und erwarten, dass die Entwickler auch wollen, dass sie eben,
vernünftig in die Produktion gehen, dass sie eben keinen Platz ausliefern.
Genau, natürlich. Also man will natürlich die Angst minimieren.
Also ich weiß jetzt noch, wo Continuous Delivery noch nicht so ein Begriff war oder so schnell auf Produktion gehen,
dann hast du ja solche Release-Zyklen gehabt von drei, viermal im Jahr.
Und das war immer mit Angstschweiß verbunden, weil so keiner so recht wusste, ob das Ding ja wirklich live gehen möchte.
Und damit sie, und ich meine, jeder Entwickler möchte, oder jeder Arbeitnehmer,
möchte eigentlich ein gelassenes Wochenende haben und nicht am Wochenende angeschweißt in der Firma sitzen und dann so eine Software halt ausliefern.
Und das heißt, da ist ja auch eine Eigenmotivation darin, okay, ich brauche halt ein Sicherheitsnetz,
wo ich dann getrost halt so eine Auslieferung machen kann, ohne dass ich da Sorge habe, dass dann mein ganzes Wochenende dabei drauf geht.
Also natürlich, die Entwickler haben natürlich da auch Interesse dran, nicht nur der Betrieb.
Wenn der Betriebschein nicht weiter weiß, wen rufen sie an, den Entwickler ja.
Richtig. Und im schlimmsten Fall ist das Wochenende,
die Ohren geschlagen und bis am Montag kommst du dann halbwegs unausgeschlafen zur Arbeit
und dann hast du dann die hunderte von Bugs, die dir dann nochmal…
Ja, genau.
Und im schlimmsten Fall, da muss zurückgedreht werden.
Ja, wenn das auch noch geht, dann ist das dann der Test, ob das Backup-System überhaupt funktioniert.
Stimmt, da kann man ja mal ausprobieren. Nein, Spaß beiseite.
Einen wichtigen Punkt finde ich dabei immer noch, wenn ich komme, ja, du hast ja schon gesagt, BWLer,
für mich ist halt auch das Thema Organisation und Prozesse ist wichtig.
Und was ich eben auch interessant finde, ist, dass über die Architektur auch Organisationsfragen quasi angesprochen
oder angetriggert werden, nämlich, wenn ich von autonomen Teams rede, wenn ich sie haben möchte,
müssen sie auch von der Architektur unterstützt werden.
Das heißt, ein weiterer Grund ist eben auch, denke ich, dass ich mit so einer CI, CD-Pipeline
und Microservices das Ding auch viel besser in den Griff kriege.
Ja, aber obwohl ja mittlerweile mit den Microservices ja auch so ein Trend geht,
die ersten haben…
Und der Hype geht wieder runter mit Microservices, die ersten haben die ersten großen Schmerzen
und merken halt, okay, vielleicht haben wir zu kleine Microservices.
Und die Frage ist ja, weil du das Organisatorische oder die Struktur der Organisationen angesprochen hast,
es gibt ja auch Organisationen, die haben pro Team drei, vier Microservices.
Die Frage ist halt, ob das dann mal nicht daraus das Team nochmal aufteilen sollte
oder einen anderen Weg geht und sagt, okay, ich fasse die drei, vier Microservices zum einen der Anwendung halt zusammen.
Ja.
Okay.
Und was ich auch mal auch interessant fand, mal einen Ansatz zu sagen,
okay, welche Architektur wollen wir haben?
Und danach ist die Organisationsstruktur an dieser Softwarearchitektur aufzubauen,
genau wegen diesem Convey Law, ja.
Weil normalerweise sieht man die Auswirkungen, okay, ich habe eine Organisationsstruktur,
die ist halt gesetzt und dann entwickelt sich das in Unterbewusstheit,
was in der Softwarearchitektur, bildet sich das wieder.
Und ein interessanter Ansatz wäre halt, das mal genau andersherum zu machen.
Ja.
Also ich finde, ich finde das auch ist was…
Das Interessante ist, ich kriege es in den Organisationen, die ich begleite oder betreue,
quasi nur so mit, dass ich Teams eben sehe, die sich nach und nach als Team formieren.
Das heißt, da sind die Unternehmen…
Also ich habe noch kein Unternehmen persönlich direkt erlebt,
was quasi die gesamte Organisation verändert hat.
Die meisten, die ich erlebe, machen das schrittweise.
Die machen einzelne Teams, die sich unterschiedlich schnell entwickeln,
die vielleicht auch in einem großen Projekt arbeiten, also auch ruhig mehrere Teams.
Aber dass ich eben eine Organisation komplett neu aufstelle,
also wirklich eine Änderung…
habe ich noch nicht erlebt und insofern, ja, bin ich mal gespannt,
wann ich das erste Mal bei so etwas mit dabei sein werde.
Ich kann mir gut vorstellen, dass es vielleicht in kleiner Unternehmen
eher funktioniert als so in großen Unternehmen.
Und dann ist die Frage halt, muss ich das ganze Unternehmen jetzt auch umbauen
oder würde es reichen, wenn ich jetzt meine IT nach dem ausrichte?
Ich meine, dass sich die IT eben entsprechend anders aufstellt im Rahmen einer Organisation.
Das ist natürlich klar, dass der Kunde sich dann daran ausrichten muss, ist auch klar.
Aber also wie gesagt, ich hatte eben…
Meinst du die IT-Organisation?
Ah, okay, gut, dann sorry, da habe ich dich nicht mehr so gut verstanden.
Ja, ja.
Jetzt haben wir die Überschrift Toolparade.
Jetzt haben wir nur über Kultur geredet.
Also insofern sollten wir jetzt mal auf die Toolparade eingehen.
Und ich habe ja auf deinen Architekturspeaker schon verwiesen.
Und der hat so eine wunderschöne Reihenfolge.
Also insofern würde ich sagen, stell doch mal ganz kurz,
oder auch ein bisschen ausführlicher, die Continuous Delivery Perlenkette da,
die du dort eben aufgeführt hast.
Ja, also wir haben uns da gedacht,
ja, wie kriegen wir das Thema oder auch die Tools am besten aufgereiht?
Und dann stellt es sich heraus,
dass das ganze Thema eigentlich in mehreren Unterthemen aufgeteilt ist.
Wie zum Beispiel, das fängt eigentlich an mit der Grundlage wie Visionskontrollsystem.
Und da geht es dazu, dass man eigentlich eine Code-Versionierung haben möchte.
Das heißt also Code im Sinne von Java-Code, PHP-Code, SQL-Code,
aber auch Konfration oder wenn man halt Richtung Automatisierung der Infrastruktur kommt,
guckt auch Code, mit dem man halt die Infrastruktur beschreibt.
Ja, und da, um das kulturelle vielleicht ein bisschen einzufangen,
das soll ja auch helfen, die Zusammenarbeit zwischen den Teams oder innerhalb des Teams zu verbessern
und auch das Nachvollziehen zu machen.
Was haben die Entwickler über die Wochen, Monate gemacht?
Nicht als Kontrollmechanismus, sondern also wie so ein Geschichtsbuch halt.
Okay, wie hat sich die Software halt in den letzten Monaten entwickelt?
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Das kann man am besten am Code selber sehen.
Dann sieht man auch die Historie, wie sich so ein Feature halt entwickelt.
Am Anfang dachte man, man nimmt den roten Weg.
Und dieser Weg wurde mit der Zeit halt grün.
Und dann kann man das wunderbar in so einer Visionskontrollhistorie halt ablesen.
Und da gibt es halt mehrere Ansätze.
Also Visionskontrollsystem wird ja zentral gehalten oder dezentral.
Das würden wir ja gleich im nächsten Schritt nochmal angehen.
Ja, können wir ja machen.
Machen wir ein bisschen detaillierter.
Das heißt, quasi Bild 1 oder auf dem Bildpunkt 1 ist, man braucht einfach ein Versionskontrollsystem.
Genau.
Also das ist auch das, was ich halt, also ich habe das zum Glück noch nicht erlebt, in
ein Team zu kommen, die kein Versionskontrollsystem benutzen.
Also wenn sie was, es kann sein, dass sie nicht den ganz modernen Tool an der Stimmung,
aber irgendein Versionskontrollsystem ist immer.
Aber ich kenne zwei andere Kollegen her, die in Projekten kommen und dann stellt sich heraus,
dass die Entwickler…
…die Sourcecodes mit USB-Sticks untereinander verteilen.
Und ja, und ich denke, also meiner Sicht ist, wenn ich das nicht im Griff habe,
dann muss ich über Continuous Delivery jetzt gar nicht nachdenken.
Ja, okay.
Das heißt, bei dieser Perlenkette, der Schritte 2 wäre dann der, der darauf dann folgt.
Genau.
Der zweite Schritt wäre dann, also wenn ich das im Griff habe, mit meinen Artefakten,
also wenn ich meinen Sourcecode halt visioniere, dass ich dann den nächsten Schritt gehe und sage,
okay, ich möchte…
…meine Auslieferungsartefakte, wo später halt die Software halt, also die Diplomate-Artefakte,
dass ich die automatisiert erstelle.
Und was viel wichtiger ist, dass sie reproduzierbar erstellt.
Also ich möchte ja nicht Fakte haben, dass ich heute ein anderes Artefakt zusammenbaue als morgen.
Und der einzige Unterschied ist, weil morgen Dienstag ist und heute Montag.
Das möchte ich nicht.
Und ich möchte auch nicht, dass bei meinen Kollegen halt ein anderes Diplomate-Artefakt rauskommt als bei mir.
Nur weil wir unterschiedliche Rechner haben.
Deswegen…
Und dann gibt es halt auch Tooling-Unterstützung.
Die mich da unterstützen, dass sie die Abhängigkeiten für mich zusammensammeln
und da auch helfen, reproduzierbare Diplomate-Artefakte zu erstellen.
Okay. Continuous Build und dann kommt Continuous Testing.
Ja, beim Testing ist das so, dann kommen wir erst in Richtung Qualität.
Und das, was auch den TPO-Vermeisten interessiert, ob die Software auch das tut, was es soll.
Und da möchte ich halt auch einmal…
Risikominimierung machen, aber auch wiederkehrende Aufgaben, Motone-Aufgabe halt wegautomatisieren von Tests.
Das heißt, ich habe dann mehrere Arten von Tests, Entwicklertests, dann Funktionaletests oder fachliche Tests.
Das, was nicht jedes Mal jemand bei Hand machen muss, sondern dass die einmal geschrieben werden und dann wiederholbar sind.
Und am besten auch so, dass das während, bevor ich mein Deployment-Artefakt halt zusammenbaue,
dass dann nochmal vorher die Tests abgelaufen werden, um so sicherzustellen, hey, das Ding, was ihr da gebaut habt, funktioniert.
Auch so, wie sich die Fachmännlichkeit das vorstellt.
Okay, das heißt, wenn ich auf diese Perlenkette gucke, das war ja der Punkt 3, Continuous Testing.
Und dann kommt der Punkt 4, den ihr gar nicht so mit Punkt 4 benannt habt, weil der wahrscheinlich so umfangreich ist,
dass man für einen eigenen Spicker schreiben musste, Continuous Inspection.
Genau, da gehen wir jetzt im Spicker nicht drauf ein, aber das gehört trotzdem noch zu der Kette.
Es geht da darum, halt statische Krutanalyse zu machen.
Ja, hört sich jetzt technisch an, es geht halt darum, man muss sich vorstellen,
wir machen halt Code-Reviews, das heißt, wenn ich meinen Source-Code geschrieben habe,
dann gebe ich es einem Kollegen und er soll so mal drüber schauen, ob der unter anderem lesbar ist.
Aber damit er sich auf, oder ob ich auf die Architektur-Prinzipien, die ich mit dem Team halt vereinbart habe, auch eingehalten habe.
Und damit er sich auf solche Sachen konzentrieren kann und nicht, ob ich jetzt den Source-Code nach bestimmten Formatierungsregeln eingehalten habe,
dass er sich damit nicht aufhalten muss, lassen wir statische Krutanalyse-Tools drüber laufen,
die mich dann schon darauf aufmerksam machen, hey, hier.
Also, hast du, verstehst du ein paar Prinzipien, was du mit deinen Kollegen aufgemacht hast?
Oder da gibt es auch Tooling, die schon potenzielle Bugs, die man, wo wir halt wissen,
dass wenn wir gewisse Sachen so schreiben, die könnten halt so potenzielle Fehler dahinter stecken,
dass dann, dass so ein Tool uns an der Stelle da schon Sachen halt abnehmen kann.
Und der Code-Review-Partner halt sich dann auf richtig wichtigere Aspekte konzentrieren kann,
wie habe ich Architektur-Prinzipien eingehalten, ist der Code lesbar, verständlich,
und solche Sachen.
Denn die Verständlichkeit kann halt keine Maschine halt analysieren, da muss jemand.
Das stimmt, aber die Maschine kann ja auch das abnehmen, was du auch eingangs ja gesagt hast,
nämlich monotone Aufgaben und einfach nur zu gucken, ob irgendwelche banalen Regeln eingehalten sind.
Das kann Maschinen sicherlich sehr gut.
Genau, und dafür setzt man das hauptsächlich ein.
Oder halt Bugs, so wie es Null-Pointer-Exception, dann gibt es halt Pattern,
die man anhand der Code-Analyse halt sehen kann, dass es Potenzial dafür gibt.
Und das kann natürlich auch eine Maschine schneller herausfinden, als mein Kollege an der Stelle.
Ja, lass uns mal bei den Tools weitergehen.
Ich habe schon ein paar andere Fragen jetzt schon so, die in Richtung Menschen gehen und wie ticken so die Entwickler.
Aber ich glaube, wir sollten erstmal die Perlenkette einmal zu Ende durchgehen.
Also wir hatten jetzt eben Continuous Inspection, das ist wie gesagt ein eigener Punkt.
Das ist der vierte und auf der Perlenkette die Nummer vier ist der fünfte Schritt,
Continuous Database Integration.
Genau, und da geht es halt darum, dass wir mit so älteren,
Werkzeugen zu tun haben, wie oder Datenbanken, wie Relational-Datenbanken.
Und da ist es halt so, dass sich die Struktur dieser Datenbanken mit Tabellen ja mit der Zeit sich auch anpassen sollten.
Tun sie aber nicht, weil sich viele halt damit schwer tun, diese gewachsene Systeme halt anzufassen.
Weil man muss dann Migrationsskripte dann schreiben und die auch dann auch verteilen.
Und dann haben sich dann solche Datenbanken sich so ein bisschen entwickelt, wie diese NoSQL-Datenbanken,
also Key-Value, also wo ich dann keine Tabellen mache.
Keine, keine, nicht unbedingt, keine feste Struktur der Daten, die ein bisschen flexibler ist.
Und da hat man sich gedacht, ja eigentlich möchte ich diese Flexibilität auch in meiner Relationalen Datenbank haben.
Und da hat sich dann halt Tooling sich entwickelt, die einen dabei unterstützen, automatisiert diese Migration zu machen,
sodass am Ende die Datenbank zu der Struktur in der Software halt passt.
Boah, ich hoffe, das war jetzt nicht so…
Ja, ich wollte gerade sagen, das klingt auch für einen BWLer so nachvollziehbar.
Also, wobei ich muss ja gestehen, dass ich auch schon ein bisschen was mit,
mit Relationalität habe.
Ja, ich wollte gerade sagen, das klingt auch für einen BWLer so nachvollziehbar.
Ja, dass ich meine Datenbank selber gemacht habe, ist schon ein paar Jährchen her,
aber zumindest sagt mir SQL was, aber okay.
Ja, okay. Ich glaube, die BWLer haben gerne Microsoft Access benutzt, ne?
Ja, da erinnere ich mich immer an die Diskussion, ob Microsoft Access eine Datenbank ist.
Ja, ich weiß.
Ich finde die nur köstlich, weil da waren so bei mir, wie gesagt, ganz zu Beginn meiner Berufszeit
saßen dann Notes-Datenbankentwickler und Access-Datenbankentwickler mit Oracle-Datenbankenentwickler
beim Mittagessen zusammen.
Und ich konnte in Ruhe essen, weil die haben sich über Datenbanken unterhalten und gestritten,
ob denn nun das jeweils Datenbanken sind.
Und das ging aber über mehrere Jahre.
Also, sie sind nie zu einer Lösung gekommen.
Und jetzt verrate ich ein Geheimnis.
Meine Relational-Datenbank-Vorlesung 1 in der Uni begann mit Microsoft Access.
Also, von daher, also wir durften in den ersten Übungen noch nicht an Oracle ran, weil der,
ich weiß nicht, ob der Übungsleiter oder der Professor gesagt hat, für die ersten Übungen,
die wir machen, da reicht Microsoft Access vollkommen aus.
Also, so viel zum Thema.
Aber Access gibt es noch, gibt es noch.
Ja, das glaube ich wohl.
Also, ich glaube auch, oder ich bin mir sicher, dass in den Unternehmen an vielen Stellen
Access noch im Einsatz ist.
Und ich sehe es jetzt gerade in zwei Projekten, wo es darum geht, Microsoft Office zu migrieren
in die Cloud.
Und jetzt fangen sie an, die ganzen Access-Datenbanken, die teilweise wichtige Geschäftsprozesse
unterstützen, dass sie die so langsam einsammeln oder einfach mal in den Überblick bekommen,
also, ich glaube, da lauert noch viel unnütze Arbeit, also unnütze Arbeit im Sinne von,
das gibt kein Business mehr wert, diese Access-Datenbanken also abzulösen, wie auch immer sie abgelöst
werden.
Also, da schlummert noch viel, viel Arbeit.
Ja, auch wenn wir jetzt ein bisschen abschweifen, aber Microsoft Access, das ist einer der Vorreiter
der Daten-IT.
Also, wenn man keine Unterstützung aus der Entwicklung kriegt, warum auch immer, es gibt
tausend Kunden, die aber eine Lösung brauchen, dann ist Microsoft Access gepaart mit Microsoft
auf Excel die Lösung für die Fachlichkeit, ihre Prozesse halt da zu automatisieren.
Ja, das ist vollkommen richtig, ja.
Gut, aber dann schweifen wir wieder zurück auf unsere, oder auf deine Perlenkette.
Der nächste Punkt ist Konfigurationsmanagement.
Ja, genau.
Da geht es schon mehr Richtung Operation, Betrieb.
Und zwar geht es darum, wie kriege ich die Infrastruktur in so einem Server schnell in
die Benutzung und am besten automatisiert.
Also, ich weiß nicht, jeder hat, glaube ich, irgendwann mal Windows.
Bei sich zu Hause selber installiert und der weiß halt, dass das sowas sehr, sehr langwierig
ist und sowas möchte man auch nicht manuell machen.
Man muss sich vorstellen, so auf dem Server ist das halt so ähnlich.
Und also gibt es da schon ein bisschen mehr und mehr Hilfen, aber also am liebsten ist,
wenn man halt auch reproduzierbare Server haben möchte, dass man das halt auch wieder
wegautomatisiert, weil die Abläufe da relativ gleich sind.
Und die Erfahrung hat gezeigt, wenn man das halt nicht wegautomatisiert, dann, man hat
zwar eine Checkliste, versucht sie auch zu pflegen, aber trotzdem sieht die der Server
im Satz ein wenig anders aus in den Annoncen und dann, ja, dann wundert man sich, dass
es auf dem einen Server funktioniert und auf dem anderen nicht.
Und auch da in dieser Stelle wieder Risikominimierung und Schnelligkeit, also eigentlich zwei Aspekte
Risikominimierung und ich will meinen Server halt schnell zur Führung stellen, deswegen
damit beschäftigt sich halt Konfigurationsmensch nicht.
Ja, da sind wir eben schon abgeschwiffen oder abgeschweift und ich muss dann immer, also
was du jetzt gerade so erzählst.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
viel Schwierigkeiten, die er aber selber dann auch
wieder lösen kann. Wie sind denn da so deine
Erfahrungen? Es ist unterschiedlich.
Also ich habe zum Beispiel mit dem Thema
angefangen, weil mich genau das angekotzt
hat. Ich wollte nicht der Held sein, denn
die Helden sterben immer am Ende der Geschichte.
Also wenn man sich so
Sagen andurchliest.
Die Helden sterben immer am Ende.
Außer bei Gene Kim.
Jawohl, der wird
dabei, ich glaube, du redest vom
Project Phoenix, ne? Ja, richtig.
Der wurde auch am Ende, also der wurde
ja am Ende mehr und mehr kaltgestellt.
Da war jetzt noch eine Stelle, wo der
Projektleiter sagte, ich glaube, Billy hieß der,
wo er sagte, ich will einen
anderen Ingenieur neben dem siebten haben,
der aufschreibt alles, was er da macht.
Nur herauszufinden,
herauszufinden, was er da macht. Ich meine, am Ende, und das ist
für mich so ein bisschen kaltstellen. Also der Held wird
da an der Stelle ja auch ein bisschen kaltgestellt.
Er wird ja auch als Problem halt angesehen. Ja, das stimmt.
Und da fing ich halt an,
meine Sachen, die ich mache,
zu automatisieren, sodass ich dann irgendwann
einen anderen Kollegen gesagt habe und sagen konnte,
hey, wenn ihr wissen wollt, wie das funktioniert,
hier ist die Dokumentation und die Dokumentation
ist halt ein Skript. Ihr seid alles
Entwickler. Das müsst ihr schon verstehen.
Okay. Also,
aber ich kenne auch in anderen Unternehmen,
dass sie auf diese Helden auch aufbauen
und die Leute fühlen sich auch erst mal
auch wohl. Ich meine, das ist total menschlich,
dass manche Leute sich gerne im Mittelpunkt
stehen und auch eine Krankheit
bekommen. Und ich meine,
so funktionieren
Sportveranstaltungen, ja? Also,
da haben wir auch einen Sieger, ja?
Einen Helden.
Der Nation. Oder manchmal elf Helden
der Nation.
Und ja, und deswegen,
das ist, und also, ich kenne beide Seiten.
Ich habe Kollegen
erlebt, die wollten dieses Heldentum
nicht und auch aktiv dagegen
gekämpft haben. Aber es gab auch
Kollegen, die das genossen haben,
dass es so ein Heldentum ist, auch wenn es denn nicht
das Wochenende über die, aber sie
konnten dann mit erhobener Brust nach Hause
gehen und sagen, zu Hause 10, ich habe
heute wieder die Welt gerettet. Also,
ich kenne beide Typen.
Also, ich glaube, das ist einfach eine Tüftel.
Und dann ist es eine kulturelle
Geschichte. Da muss das Unternehmen
für sich halt entscheiden, welche
Unternehmenskultur möchte ich hier haben? Was möchte
ich für Menschen haben, die bei mir arbeiten?
Und dann müssen sie halt Maßnahmen machen.
Vollkommen richtig. Und meine, es ist ja so,
diese Helden, die sich
selbst reflektieren, die kommen dann wahrscheinlich zu
dem Punkt, dass sie sagen, sie brauchen das nicht
mehr. Ihnen reicht ein gutes Gefühl, aber
eben nicht die andauernde Bestätigung
oder permanente Bestätigung.
Aber insofern,
das finde ich richtig. Ja gut,
lass uns mal bei der Perlenkette bleiben.
Sonst bleiben wir noch mal ab hier.
Vielleicht können wir mal einen Podcast noch über Heldentumme
machen. Ja, dann würde ich auch ein paar
Helden einladen. Nur denen würde ich vorhin nicht sagen, dass
sie als Helden eingeladen sind, denn dann würden sie
vielleicht nicht daran teilnehmen. Ja, okay.
Nächster Punkt ist die automatisierte
Verteilung deiner Perlenkette.
Auch wieder, natürlich ist die
Automatisierung wieder im Fokus.
Und da geht es halt darum, so ähnlich
gelagert wie die Bereitstellung der Infrastruktur.
Ich muss ja irgendwann meine Software irgendwann mal auf den
Server installieren.
Das heißt, im Java-Umfeld ist es halt
meistens so, oder oft ein
JAR oder ein WAR-File, ein Tomcat
oder ein Location-Server.
Mittlerweile wird ja Container-Technologie gehypt.
Beziehungsweise Hype ist ja schon wieder ein bisschen
abgeflacht, dass ich auch meine Docker-Container irgendwo
wie auf die Server verteilt bekomme.
Ja, und das will ich ja auch nicht händisch machen.
Sondern dann schreibe ich mir auch Skripte,
wo ich dann sage, hey,
auf den Server oder
irgendwo im Cluster, wenn man halt, um
die Passwort zu bedienen, Kubernetes.
Das habe ich doch gesagt. Ich wollte es mir
eigentlich vor dem Licht rüberlegen.
Reingefallen, ne?
Ja, reingefallen.
Also, lass uns mal da was vornehmen.
Das, dass ich halt meine
Software halt in Cluster verteilen möchte.
Und das will ich ja auch nicht händisch machen.
Und ja, dann schreibe ich mir Skripte, die dann
sagen, hey, verteilen wir mit den Containern bitte
auf folgenden Cluster. Beziehungsweise
macht das ja dann mein Cluster
Verwaltungs-Software, dessen Namen
wir nicht kennen wollen.
Auch wenn wir von einer Tool-Parade reden heute hier, ne?
Ja, weil ich so Leute,
die mich kennen,
ich bin bei Werkzeugen, die so gehypt werden
und Goldene Hammer für alle unsere
Probleme dargestellt werden. Ich habe da so eine,
das triggert mich immer so gleich
in so einer Anti-Hype.
Alles klar.
Gut. Letzter?
Das wäre wieder Heldentum, ne?
Auf der Tool-Seite, jawohl. Okay, ja.
Letzter Punkt ist
Continuous Controlling, Continuous Observation.
Ja, das geht dann darum,
dass ich gerne meine Software auch
überwachen möchte. Also, ich möchte ja frühzeitig erkennen,
ob meine
Software, die ich da draußen in Betrieb habe,
Blödsinn macht. Und nicht erst,
wenn das Kind schon im Brunnen gefallen ist.
Also, da gibt es das sehr klassische Monitoring.
Aber es gibt mittlerweile auch
Tools, wo ich dann so eine Vorhersage
machen kann oder schon so Anzeichen
sehen kann, hey, da könnte
irgendwas schieflaufen. Wie zum Beispiel
ein Fall war gewesen, dass zum Beispiel
wir haben ein System, der eigentlich
jeden Tag irgendwie 50.000
Anfragen bearbeitet. Und von heute auf morgen
gab es keine 50.000 Anfragen,
obwohl die Systeme alle
technische Metriken in Ordnung waren.
Und das kann man als Metrik nehmen, um zu gucken,
okay, vielleicht
ist da irgendwas falsch an der Stelle.
Vielleicht müssen wir mal gucken, was
im Umfeld des Systems irgendwas nicht
stimmt. Dass auf einmal keine 50.000
Anfragen kommen an das System, obwohl man
weiß aus der Vergangenheit,
da sollte was sein. Und eine andere Geschichte
ist auch, die Fachlichkeit
möchte, dass wir Features, Features, Features
implementieren. Und die wissen halt
nicht, ob diese Features
überhaupt benutzt werden. Und wenn sie
eine Frage ist, ja, wie finden wir es heraus,
ob der Endkunde die Sachen, die wir uns
ausdenken, überhaupt benutzt. Und dann kann ich
entsprechend, also Sensoren einbauen in der Software,
die halt Fachlichkeit misst.
Wird dieses Feature überhaupt benutzt? Wenn nicht,
dann kann man halt
dieses Feature wieder löschen, denn
ein Source-Code, was nicht existiert,
kann auch keinen Ärger machen. Und dann gibt es
auch noch Sachen, wie zum Beispiel Robustheit
abzutesten, um zu gucken,
okay, ich schmeiß mal ein paar
Sachen, also ein paar Instanzen mal
weg und funktioniert dann meine Software dann immer noch.
Also ist dann zum Beispiel
meine Software robust. Aber wie du merkst,
das ist halt nochmal ein Riesenschalt.
Deswegen haben wir das auch im Spicker
und sind wir dann auch nicht näher drauf eingegangen.
Ja, okay. Ja, wir sind jetzt eben bei der Perlenkette
am Ende. Also sind ja, wie gesagt,
sind ja acht Schritte. Ihr habt sechs auch in dem
Spicker selber noch ein bisschen
detaillierter beschrieben. Und
das ist jetzt ja, wie ich finde, eine sehr
logische Reihenfolge. Die Frage
wäre, die sich mir dann eben aufdrängt,
das, was ihr als Reihenfolge gewählt habt,
kann man das als eine Art Standard sehen?
Oder gibt es andere Standards, die ich sonst so
kenne, wie Plan, Build, Run und solche Themen?
Also gibt es quasi eine
Standardfolge, die sich etabliert hat?
Oder gibt es da verschiedene? Und
sprich, wie passt eure dann auch da rein?
Also das ist jetzt so Erfahrungswerte,
die ich halt aus den Projekten mitgenommen habe.
Das, ich brauche nicht mit,
z.B. mit automatisierten Tests anfangen,
wenn ich meinen Trostgurt nicht mehr automatisiert
gebaut kriege. Wenn ich aber mir Literatur
zu dem Thema anschaue, die gehen immer schon
in diese Richtung. Also die würden das jetzt nicht so
in der Perlenkette nicht aufzeichnen wie wir, aber
das,
die gehen schon in die Richtung, wenn ich mir
so Standardwerke anschaue, wie Continuous
Integration oder Continuous Delivery,
die fangen alle mit so einem Versionskontrollsystem
an an der Stelle. Vielleicht
einen Announcen halt, weil
nachdem, was für ein Versionskontrollsystem
oder was für ein
Pattern man innerhalb Arbeitsweise
mit dem Versionskontrollsystem, also da ändert sich,
da gibt es ja schon Unterschiede,
aber so von der Grundstruktur
würde ich sagen, das ist schon so ein
Rahmen, wo ich sage, okay, das zieht
sich eigentlich durch an der
Stelle.
Also mir wäre zumindest jetzt
nichts bekannt. Also wenn jemand draußen
was anderes kennt, das würde
mich interessieren, mal
ein anderes Facebook an der Stelle.
Ja, der wird sich bestimmt melden, aber wahrscheinlich werden
die, die was anderes kennen, diesen Podcast nicht
hören, weil sie ja schon die Experten sind.
Ja, genau. Aber manchmal
hören ja Experten
auch mal Line zu.
Ja, das stimmt. Und vielleicht machen
wir auch, weil wir das so nett rüberbringen,
vielleicht auch. Ja, genau. Also ich höre auch
mal Sachen bei Sachen, Podcastsachen, wo ich denke,
das kennst du schon und dann
kommt trotzdem immer noch eine Sache. Ach, so
habe ich das doch auch noch nicht gesehen. Also von daher.
Ja, das stimmt. Das war jetzt die
Zusammenfassung der Perlenkette. Wir sind
ja teilweise schon ein bisschen in die
Details eingestiegen
und haben wir eben auch nochmal so
uns überlegt, gibt es da
ein allgemeines Vorgehen
und ja, wie ich rausgehört
habe, ist das schon ein Standard-Vorgehen
und vor allen Dingen, was ich ganz interessant
finde, ist, dass eben auch bei dir oder bei euch
bei diesem Bild hier das Versionskontrollsystem
oder Versionskontrolle zu Anfang
steht. Ich weiß nicht,
ob das der Ausgabe 17
oder 16 war, der
State of DevOps Report, da kommt ja auch
ganz klar raus, dass erfolgreiche
IT-Organisationen eben
ein Versionskontrollsystem haben.
Insofern quasi gibt es ja auch die Bestätigung
für deine Erfahrungen aus der Praxis.
Man muss aber auch sagen, es gibt
Unternehmen, die haben ein Gesundheitskontrollsystem
und trotzdem scheitern. Okay.
Dann fehlt noch was anderes.
Ja, genau.
Wie sagen die Mathematiker?
Es ist eine ausreichende,
aber keine hinreichende
Bindung, aber nicht zwingend oder so.
Ja, genau.
Also es ist,
ja, man braucht das, aber
das ist jetzt kein Erfolgsgarantie.
Ja, okay.
Aber dann lass uns bei dem Thema
Versionskontrollsystem einfach noch mal ein bisschen ins Detail
einstrengen. Also das ist der Einstieg, hast du ja gesagt,
der Beginn ist die Basis.
Was muss ich mir dann, wenn man ein bisschen
ins Detail einsteigt unter einem Versionskontrollsystem?
Versionskontrollsystem vorstellen?
Also man muss sich das so vorstellen,
dass ich, also das ist ein Verwaltungstool,
also ich habe es für Leiden ausgesprochen,
das Verwaltungstool für Textdateien
und ich, bei jeder Änderung,
die ich an diesen Textdateien mache,
habe ich die Möglichkeit,
eine Beschreibung zu hinterlegen.
Und das heißt, ich fasse halt einen Satz von
Änderungen an verschiedenen Dateien halt
in einem Arbeitspaket zusammen und das lege ich dann ab.
Und dann habe ich halt so eine Art
Grafen, wo ich dann durch meinen Grafen
dann navigieren kann und sehen,
zu welchem Zeitpunkt welche Änderung
an diesen Dateien halt gemacht worden ist.
Und diese Textdateien, die sind halt
einmal die Grundlage für die Software,
die am Ende gebaut wird.
Aber diese Textdateien können sogar
Bildskripte sein, also Skripte,
mit denen ich meine Software halt dann baue
oder Konfigurationen von meiner
Software oder Skripte,
um die Software halt später auf die Server
zu verteilen. Datenbankskripte,
die Migration, da habe ich ja auch
im Überblick halt das erwähnt.
Und ja,
wo auch der Trend auch jetzt hingeht, dass ich auch
immer mehr auch meine Dokumentation
halt in solchen Textdateien halt
ablege, auch in so ein Visionskontrollsystem
ablege, in der Nähe meines Sourcecodes und
daraus dann halt schöne Word-Dokumente
oder PDF-Dokumente herausgeneriert.
Das würde dann Documentation
as Code halt sein.
Das klingt gut. Ja, und da gibt’s halt
ja,
also ich meine, jeder
hat sein anderes Format als Vorliebe.
Ich weiß auch halt aus anderen Projekten halt,
das ist immer die Diskussion, ja, in was schreiben
wir unsere Dokumentation? Die POs wollen,
dass wir es in Word-Dokumenten sagen,
wir machen kein Word-Dokument und
wir wollen aber irgendwas Text-laftiges
und das finden die aber nicht so schön und
die wollen gerne, oder PDF wollen die halt
haben, dann
kann man sich vielleicht ein Wiki auf sich ein Wiki eignen,
aber auch wenn es da draußen ist, keiner
hören möchte, aber Confluence ist,
seit es vom Management entdeckt worden
ist, ist es nicht mehr
schön zu benutzen. Zustimmung,
volle Zustimmung.
Also, ich weiß jetzt auch, aber
Confluence bis Vision 3
war einfach ein cooles Tool. Ich konnte da
so ähnlich schnell, musste mich
nicht um Formatierung kümmern, so, konnte einfach
runterschreiben, wie ich das damals an der Uni
mit Latex gewohnt war.
Da gab es ein paar Kurze, die ich mir merken musste,
wo ich dann, wo dann ja Wiki
oder das Confluence hat die Wiki-Seite
eine Überschrift gelegt und jetzt bin ich wie
bei Word, bin ich am Kämpfen,
dann will er diese
Eindrückung nicht so machen, wie ich möchte.
Dann kann ich auch gar nicht in Word benutzen.
Aber da wir ja selbstorganisierte Teams haben,
die ihre Tools selber auswählen dürfen.
Ja, ja, genau.
Genau, das steht in den Büchern.
Aber
wir haben ja selbstorganisierte Teams
und sind ja agil, weil wir
Jira und Confluence… Ja, das ist doch die Grundvoraussetzung.
Ich glaube, wir müssen
nachher noch bei der Veröffentlichung so einen Ironie-Modus
immer einblenden.
Okay.
Also, ich hoffe, das kann jetzt als Ironie…
Ich habe ja, es ist bei mir
genauso, dass ich diese Ironie dann, wenn man
sich gegenübersteht, dann kann man das ja sehen,
sehen oder zeigen. Also, insofern,
ich glaube aber, unsere Zuhörer werden das auch
raushören. Okay, es ist nur für
das Protokoll, das war jetzt Ironie mit den
Agilen. Also, jetzt kommt Ironie Ende,
jetzt kommt wieder Fachlichkeit. Genau, jetzt wird Fachlichkeit.
Ja, und dann
ist die Motivation, also aus BWLer
Sicht kann man jetzt fragen, was ist der
Business Value dahinter von so einem
Versionskontrollsystem? Naja, also
der Business Value ist, ich will halt die
Kosten minimieren, um
meinen Kaufkreuz an den Entwickler zu verzeihen.
Man will ja nicht das einen Entwicklern
Kaufkreuz arbeitet, sondern mehrere
Entwickler. Am liebsten im Tarn, aber
manchmal auch getrennt voreinander.
Ja, das ist dann halt die effiziente Art und Weise,
wie ich den Kaufkreuz unter meiner
Entwicklerhand beteiligt bekomme. Ja,
das bedeutet aber schon natürlich, dass
ich höre jetzt ganz klar raus, dass es
eine wichtige Voraussetzung ist, also
wird für mich jetzt auch nachvollziehbar,
bedeutet aber auch, dass bei den Teams
sich manchmal ein paar Dinge ändern müssen,
in der Art der Zusammenarbeit. Ja, auf jeden Fall.
Also, ich möchte ja zum Beispiel
schnell Feedback kriegen, wie es mein Zustand
meiner Software, die ich vielleicht später zum Kunden
rausschicken will. Das heißt, ich muss
ja auch dann, also als Entwickler muss ich
meine Änderungen, die ich mache, so schnell wie möglich halt auch
in dieses Visionskontrollsystem auch einchecken
oder auch veröffentlichen,
damit halt die nachgehenden
nachlagerte Prozesse,
also dieser Versammenbauen
halt dann auch angetriggert werden können.
Ich meine, das nützt mir nicht, dass ich zwar ein tolles
Visionskontrollsystem habe, aber alle Entwickler
checken erst so zwei Tage vor
Produktionsgang alles ein, ja. Dann
habe ich eine Zwei-Tage-Zeit, alles so
treffbar. Da habe ich den Vorteil an der ganzen Stelle
halt auch nicht. Und deswegen geht es
halt darum, auch so schnell wie möglich
seine Änderungen, lauffähige, natürlich lauffähige
Änderungen halt einzuchecken, dass
die anderen auch die Möglichkeit haben, von diesen Änderungen
halt mitzubekommen und das eventuell
auch darauf zu reagieren.
Und somit, dass
man nicht zwei Tage vor
oder Endtage vor Produktionsgang
in so einen klassischen
jetzt müssen wir alles mal integrieren
Modus. Ja, ja, klar. Also ich habe das
auf dem Spicker, da hast du ja oder habt ihr
geschrieben, Entwickler checken Code häufig ein
und letzten Endes, was
ich daraus für mich gemacht habe,
auch wenn ich in Trainings anspreche,
eigentlich täglich. Also wenn wir
die kleinen Scheibchen haben wollen, warum
soll er nicht täglich einchecken? Ja, also
das ist sogar schon, also Fanatiker
gehen sogar so weit und sagen
stündlich. Okay.
Weil du lauffähig bist,
weg von der Platte
und ab in
das Kontrollsystem. Also weg von der Platte
ist jetzt, also wirklich,
also ich habe mir
vorhin mal
gesagt, die Entwickler
haben nichts auf der Platte.
Ja, okay. Ich habe mir gerade
den Entwicklern mit der Platte vorgestellt,
wenn wir jetzt bei den Bildern schon sind, aber die
haben ja meistens lange Haare.
Gut,
jetzt ist der Ironie-Modus wieder aus,
wir schweifen schon wieder ab, aber
insofern, also häufig einen, häufig
durch die tolle Umschreibung für
täglich, halbstündlich,
halbtäglich, wie auch immer, aber wirklich häufig.
Um es dann auch wirklich
aus dem Kopf quasi raus
zu bekommen, um dann auch sich
zu fokussieren auf das, was als nächstes
ansteht. Genau.
Jetzt habt ihr auch so schön stehen, jedes Team ist für seinen
Quelltext gemeinsam verantwortlich.
Collective Ownership.
Da hätte ich jetzt auch gesagt. Ja, aber auch da hätte ich
gesagt, Menschenskinners, die Helden,
die muss ich einfangen.
Genau. Und das ist auch noch ein anderer Aspekt.
Ich meine, wir haben ja
Enterprise-Architekten und Software-Architekten
so einen klassischen,
äh, Unternehmen, ähm, IT-Unternehmen
mit eigenen Rollen, die basteln
halt eine super Architektur
und das wissen wir alles nicht, wenn, ähm,
Entwickler halt Klassen
oder, oder, oder Stellen mit
Southcode für sich beanspruchen. Keiner darf
was dran ändern und nur ändern mit deren
Absprache, dann kann ich die ganze
Architektur die Tonne drücken, weil
dann wird’s halt angefangen, weil die Leute dann gar
keine Lust haben, mit diesen Helden
oder den Owner von diesen Stellen halt zu kommunizieren.
Dann wird halt drumherum gebaut. Also man merkt,
also man kann wunderbar am Southcode,
analysieren,
auch anhand der Git-Historie,
äh, wie sich so, ähm,
Kommunikationsstrukturen halt zwischen
Entwicklern halt entstehen.
Also, ähm, das ist manchmal sehr interessant.
Das finde ich interessant, ja. Darum sage ich, also
ein Bedienungs-Kontrollsystem ist, ähm,
ist manchmal sehr
aufschlussreich, wie, ähm,
wie man halt die Kommunikation oder die
Zusammenarbeit im Team halt… Das finde ich super.
Also, sollten wir mal irgendwo über den Weg
laufen in einem Projekt, dann musst du mir das mal
zeigen, weil das würde mich auch interessieren,
wie man quasi einfach nur an Buchstaben
und an solchen Einträgen sowas erkennen
kann, ne? Ähm, da kann ich dir gleich
nochmal sagen, es geht nämlich
Tooling, was, wo man du, damit
du, ähm, Git-Historien
analysieren kann. Und
zwar, wenn ich jetzt
das auf die Schnelle hinkriege,
ach,
dann, aber es gibt ein cooles Tooling
mit, ähm, der nämlich
auf Grafen-Datenbanken aufbaut, wo
du halt die Historie halt in die Grafen-Datenbank
reinlesen kannst, einlesen kannst,
und dann dir, ähm,
mit Abfragen anschauen kannst,
nach bestimmten Pattern
angucken kannst. Aber wie das nun mal so ist,
wenn man das schnell braucht…
Du, Sandra, das ist, das ist überhaupt kein Problem.
Ich hab grad mal auf die Uhr geguckt. Wir sind jetzt schon
47 Minuten bei der Aufnahme.
Also, wir werden
es nicht mehr in der Zeit schaffen, weil da sind
ungefähr 45 Minuten. Wir haben noch so
viel vor uns. Wollen wir eine zweite,
einen zweiten Termin machen? Wollen wir eine Folge
zwei machen? Ja, können wir, können wir
machen. Gut.
Können wir auf jeden Fall machen. Und wir
haben jetzt grad das Tooling angefangen, nämlich
ähm, der Q-Assistent.
Da gibt’s, ähm, jetzt kann man, es gibt auch Vorträge
von Dirk Mahler, der sich
dann auch einen ganzen Vortrag darüber zeigt,
wie man Git-Historien halt an der Stelle
halt… Ja, super. Dann können wir das ja auch noch in die
in die Shownotes mit aufnehmen. Also,
dann stoppen wir jetzt erstmal.
Wir machen nochmal einen zweiten
Termin. Wir machen Folge zwei. Das ist
zum ersten Mal passiert, aber ich finde das super.
Und das Ziel ist ja auch wirklich, authentische
Podcasts zu machen und jetzt keine,
weiß ich nicht, keine, ähm,
vorgefertigten und marketingmäßig
aufbereiteten Podcasts.
Ähm, insofern werden wir beim nächsten Mal dann
starten oder weitermachen. Also,
starten mit dem Thema, ähm, welche
Arten der Versionsverwaltung gibt’s denn? Es gibt ja
zentrale und verteilte. Damit können
wir beim nächsten Mal sehr gut starten.
Insofern sind wir noch mittendrin in dem ersten Punkt
der Perlenkette, Versionskontrollsystem.
Ich würde sagen, für heute
sag ich jetzt erstmal vielen Dank für das
nette und aufschlussreiche Gespräch
und auf bald.
Auf jeden Fall, auf bald.

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

Inhalt laden

Der weltweit tätige Agile Coach Ben Linders hat ein Self Assessment Kartenset als Unterstützung für Retrospektiven entwickelt. Ich habe die deutsche Übersetzung erstellt, inklusive der DevOps Erweiterung, so dass wir über einige Aussagen der Karten ein interessantes Gespräch (in Englisch) führen konnten.

In this podcast, Dierk Söllner interviews Ben Linders, an expert in Agile and DevOps practices, living in the Netherlands. They delve into the nuances of DevOps, its broad collaborative approach within organizations, and the intersection with Agile methodologies. Ben introduces his Agile Self-Assessment Game, a tool designed to foster team improvement and discussion. He shares insights into cultural differences in Agile implementation, the importance of commitment and psychological safety within teams, and the effectiveness of various Agile practices across different organizational contexts. The episode is a rich exploration of Agile and DevOps concepts, emphasizing practical tools and strategies for enhancing team performance and collaboration.

Inhalt

• Introduction of guest Ben Linders
• Definition and discussion on DevOps
• The Agile Self-Assessment Game by Ben Linders
• Role of gamification in business and team improvement
• Importance of collaboration and communication in organizations
• Agile methodology, including practices like Scrum and Kanban
• Culturally diverse implementation of Agile practices
• Team dynamics, commitment, and psychological safety
• Practical Agile tools and techniques for teams
• Celebrating successes and creating a safe team environment

Transkript (automatisiert, daher keine Gewähr 🙂 )

devops auf die ohren und ins hirn ein podcast rund um devops von Dirk Sölln
hallo und herzlich willkommen zum devops podcast auf die ohren und ins hirn wir haben zum zweiten
mal jetzt einen englischsprachigen gast so dass ich jetzt auch auf das englische wechseln werde
also für die deutschsprachigen zuhörer hello and welcome to the devops podcast auf die ohren und
ins hirn which means devops right to your ears and into your brain this is the second podcast
for the german series with an english speaking guest the first one was rob england and now
welcome ben linders he will introduce himself so i will pass it over ben could you please
introduce yourself
to the listeners yes thank you derek i’m ben linders living in the netherlands i’m a trainer
coach advisor author and speaker so most of time now i’m working together with organizations and
teams to train them into increasing their agility helping them to find ways to improve their way
of working it’s a mixture of training and coaching i’m also advising organizations
on how they are doing software development finding new ways to to do that finding ways
to improve their performance and i’m also author of a couple of books and a speaker
at conferences i also do a lot of workshops and mini workshops at conferences so most
of the talk is focused on topics like deploying software development management practices
continuous improvement collaboration communication and professional development and the main focus
is there to help individuals using software development design modeling also my main
focus is in performance agreement and internship with digital technologistsWhat Heavyこう
help people to improve their value within the organization and to improve the value that
the organization is delivering as a whole to their customers and stakeholders
all right that sounds good and i think i will place your your website link to the show notes
so every kind everyone can can read and look for your um for your products and for your services
after having heard this podcast so we came together because i found a gamification part
on your website we will talk about this one about the agile and assessment cards but
first of all all of my guests i asked them to define or describe devops
it’s a devops podcast so how would you define devops well i think defining
i would like to do it in a way that is actually not limiting because that is actually one of the
strengths of devops that it’s about connecting people so there’s two things which stand out on me
first of all devops meaning collaboration broad collaboration within the organization
and it initially started as having people from development from operations working together
but i i would to see it as as a general theme of
finding ways to increase the collaboration within your organization not not just limited to people
from developers or operations but for anybody involved in the development chain of products
to improve their collaboration improve their communication the reason being that i think
that key aspects for organizations to to improve their results are mostly focused around this
collaboration and communication parts and this is where devops provides the culture provides the
boundaries to help the neural network we lead the mental promoting the split yourself to
transform ourselves the ways we just came up with devops means and also provides the techniques
to to do this in the organization right that’s it sounds good we came together because you developed
the gamification to help customers to help companies to improve their work
maybe you should describe
what you
auf meinem Website, welches sich als DHL-Self-Assessment-Game nennt.
Ich habe den Namen Game in einem Titel benutzt, aber wie bereits erwähnt, ist es vielmehr
Gamification, das bedeutet, dass es die Anwendung von Mindset-Techniken aus der
Gaming-Welt in die Business-Welt bringt, um Organisationen zu helfen, um Teams sich zu verbessern.
Die Self-Assessment-Parte dieses Games betrifft das Bilden und Verständnis, wie man
sich in der Organisation befindet.
Selbst-Assessment betrifft den Fokus auf die Leute, die ihr eigenes Assessment machen, anstatt
ein externes Assessment zu haben oder einen Auditor in die Organisation oder zu ihrem Team zu kommen
und darauf zu achten, wie sie es machen.
Also ist es tatsächlich die Bildung von Fähigkeiten für Teams, um, wenn man den DHL-Term benutzt,
darauf zu achten, wie sie es machen, aber in einer Art und Weise, dass sie wissen können,
was ihre echte Leistung ist und in einer Art und Weise, dass sie wissen würden, was sie da verbessern.
Die andere Sache ist, dass es sich darum handelt, wie man sich als Team verbessern kann.
Ich bin mehr in Agile verwendet als ein Mindset und ein Konzept, nicht so viel wie ein bestimmtes
Prozess oder eine Art und Weise, wie es funktioniert.
Manche Leute denken vielleicht an Scrum, wenn sie Agile sind.
Das ist sicher nicht der Fall und tatsächlich gibt es viele Ausstellungen, die verschiedene
Methoden für diese Karten bieten.
Ich denke eher an Agile als eine Art, die für mich eigentlich Grundsatz ist, Software
zu entwickeln, das zusammenarbeiten ist, es in einem kurzen Zeitraum macht.
Das heißt, es geht darum, die Art und Weise zu verbessern, wie du dein Software-Development
kontinuierlich machst und darauf konzentriert bist, die Leistung deiner Kunden zu erzeugen.
Okay, richtig.
Also, du hast ein Kartenset entwickelt, bis zu 52 Karten für die Agile-Parte und es gibt
einen DevOps-Extensionen-Pack mit 26 Karten.
Also, wenn du es für DevOps-Karten nutzt, haben wir 76 Karten, nur um selbst zu prüfen,
richtig?
Ja, das ist richtig.
Es gibt tatsächlich auch ein DevOps-Extensionen-Pack für Scrum, welches, wenn ich mich nicht
verletze, 39 Karten hat und es gibt auch ein DevOps-Extensionen-Pack für Kanban, welches
tatsächlich 52 Karten hat.
Der Grund dafür ist, dass es so viele gute Praktiken in Kanban gibt, die sich darauf
konzentrieren, wie du dein Werk machst und wie du es verbessern kannst, dass es mir die
Möglichkeit gab, viel mehr Karten für Kanban zu machen.
Also, wenn du das totale Set von Karten nimmst, dann hättest du ungefähr 200 Karten für
Kanban.
Was, übrigens, viel zu viel ist, um ein Spiel mit ihnen zu spielen.
Richtig.
Du kannst Wege für das oder das spielen.
Genau.
Also, was ich immer sage, wenn Leute mit diesem Spiel spielen wollen, ist, dass das erste
Ding ist, darauf zu konzentrieren, worauf du dich gerade konzentrieren willst und dann
ein Subset der Karten zu machen, die du in dieser bestimmten Situation nutzen willst.
Also, präsentiere deine Karten vorher, bevor du ein solches Spiel mit ihnen spielst.
Ja.
Also.
Und für die Agile-Parte und den DevOps-Extensionen-Pack?
Ja.
Für die Agile-Parte und den DevOps-Extensionen-Pack.
Ja, also für die Agile-Parte und den DevOps-Extensionen-Pack.
Da sind mehrere Sprachen verfügbar und die deutsche Extension, die deutsche Translation
dafür wurde von mir erledigt, also danke dir für die Chance, dein Werk zu übersetzen
und es für Deutschland verfügbar zu machen.
Also, danke dir für das Übersetzen der Karten.
Richtig.
Also, ich denke, es war sehr, es ist sehr beeindruckend, glaube ich, weil es einige
grundsätzliche Fragen gab, die nicht diskutiert werden sollten.
But there are some questions and some points on your cards.
I think we can talk about it.
And because talk about your experience, maybe all over the Europe part or all over your customers.
So I want to open up the mind and the experience from Germany to all the other countries you are supporting.
So we may start with Agile Card 3.
And that’s the statement or the question.
The team is committed and takes responsibility for delivery.
Okay, right.
So that’s just the appointment.
But what if not?
What if there’s no commitment?
What if the team does not take commitment and does not take the responsibility?
Well, actually, if the team is not taking this commitment, then there’s some gray area in commitment.
We can go into that a little bit later.
But the team.
It’s not saying, okay, we want to do the best we can to deliver value to our customers.
And we’re focused on delivering that stuff.
I think it’s one of the basic principles of Agile.
And actually, it’s the basic principles of doing work that is valuable for somebody.
You want people to really be involved in the work and to really know why they are doing it and to understand their customers
and deliver something that will be valued to their customers.
And this is the kind of commitment that you’re looking at.
So it’s not a part commitment like Okay, we’re going to put in 40 hours a week, and we’re going to be working hard, but it’s a commitment,
which is looking on the actual impact that the team tries to make with the product of the service that they are delivering.
And that’s also why you say, okay, not just through the work, but it also means putting it into the hands of your customers, which is a delivery part in there.
It’s not just about how they deliver.
All right.
Good.
Not just making a product, but just making it available.
Right, so what do you think, if the team does not take responsibility for delivery,
what is the main cause for that?
Is it just the management behind the team or is it the team itself who does not take responsibility?
Well, actually you’re diving into the way that you actually can use these cars
and that you actually use the game with the team.
Because if I use these cars with the team assessment,
this is the kind of discussion that I would like to trigger.
Be it in a team, when the team is playing with the cars,
or being when people from the organization and teams are working together on this.
Because if you see that there are different views like,
okay, I’m not sure if we really are committed to deliver value to the customers
or we see some barriers in there,
that’s where you want to dive deeper into these kind of discussions.
There can be various reasons in there.
There can be reasons that teams are scared to actually give any commitment in the organization
because commitments are treated in such a way that if the team doesn’t live up to that commitment,
they’re somehow going to be punished.
They’re somehow going to get into a lot of trouble.
And if this is the culture in the organization,
then there’s a big chance that teams don’t want to take that commitment
because they will be afraid that they cannot live up to it.
Actually, it is.
It is.
This is a discussion that we saw in a similar way in the Scrum Guide,
which initially used the word commitment also as a kind of sprint commitment on theme
and then later moved out this commitment word from this sprint part
because they found out that it would actually backfire on the way the team were working with Scrum.
Instead of being committed, they were actually sacrificing quality
to just deliver the full functionality and to deliver on time,
which was not how it was ever intended in there.
So, the committed part dives into do you have the right atmosphere in the organization
where teams dare to take commitment for the things they do,
dare to take commitment for delivering,
knowing that they will do the best they can in there.
It usually goes back again to the collaboration between the teams
and the management in there.
If you want to have a real good environment where teams can be committed.
Right.
So, there are both sides of…
They don’t let me take responsibility
or I want to take responsibility and I fight for it.
I work on that and to get this responsibility and to deliver to the customer.
That’s okay.
I think it’s quite good to have this deep dive following up this question.
It’s these kind of discussions that actually help.
It’s these kind of discussions that help organizations to find out where the real problem is in there.
And I actually had situations where managers truly wanted to give freedom to teams
and wanted them to take responsibility.
But given to how the culture has been previously,
a lot of teams are still scared to take this responsibility.
And this is actually where I tell teams like,
okay, just try out, take this responsibility,
dare to do whatever you can and see what happens in there.
Yes, right.
I heard from a German HR coach or from a responsible HR coach for, I think, 50 scrum masters.
He said, okay, a good scrum master, a good coach is someone who breaks a rule every day.
One rule every day just to have a look.
Where are the rules?
Where are the borders who can go over?
I think that makes sense.
And actually, I would question whether…
Are really rules or not rules?
They might be perceived as rules by the team.
Yes.
Okay, are we allowed to do this or not?
I worked with a project manager one time who had a simple statement like,
if there’s no rule anywhere which tells us that we’re not allowed to do this,
then let’s just do it and see how it works out.
Yes, right.
That’s it.
Okay, so I would like to switch over to Agile Card 8.
There’s the question.
Test cases are written up front.
It’s based on requirements and user stories.
And the first part of my question is,
do you see any difference between the countries where you are working?
So are there regional differences between the part of this question?
Yeah, I think it’s regional and often even more cultural differences
between the way that organizations are working.
Also the way that organizations are applying Agile.
For instance, when I was in Australia working with teams over there,
I noticed that it’s very common to have business analysts within your team
as people who have a deeper knowledge on the requirements area
and who are part of a team at one hand,
but they’re working very intensively together with product managers
or product owners to clarify what the product actually needs to do.
So this really domain knowledge of the business is a key aspect.
And the business analyst role, which was there already before
that those organizations started to incorporate Agile,
a lot of those organizations managed to keep this business analyst role,
but they actually moved it into the team.
And I think by making those business analysts part of the team and team members
and improving the collaboration between the business analysts, developers and testers,
I think that’s giving a lot of improvement.
I see also cultures where there’s still a big difference
between product owners and the teams
when it comes to defining the requirements
and discussing the requirements and clarifying them
up to the level that it might even harm working in an Agile way.
One organization I worked with started to implement Agile
in the different teams in there.
And after a couple of months, I noticed big differences between the projects
where the product owners and the teams were working together.
And I think that’s a big difference between the projects where the product owners and the teams were working together.
And I think that’s a big difference between the projects where the project owners and the teams were working together.
And I think that’s a big difference between the projects where the project owners and the teams were working together.
really was available to the teams and really worked together with the team very intensively
to clarify what their customers needed
and really was using also things like the product review
to see what the team had delivered and giving feedback on that
versus product managers who actually stated their role and said,
okay, I just gave you a specification
and I’m going to be back in five or six months from now
when the project is finished to see what you have delivered.
I didn’t even want to attend the product reviews.
And those teams who managed to get their product owners on board,
they got much bigger benefits.
And it was actually a win-win.
It was a win-win for the teams and it was a win-win for the product owners.
So it was actually a culture clash within the organization.
And actually, the funny thing was that after a couple of months,
discussions were ongoing between the different product managers in the organization
where they said like, okay, but I’m working in a different way with the teams right now.
And yeah, initially it took me more time.
But right now, take a look at my agenda.
I actually got much more freedom to do stuff.
I got time to dive into topics that I couldn’t dive in previously
because right now the teams can do much more themselves.
So they actually managed to free up their agenda by working in an agile way
and getting better results from teams.
That’s right.
I think it’s, to my point of view,
user stories are just an invitation to discuss something,
not to describe everything,
switching from business cases or other traditional things
to a modern way of describing requirements.
No, it’s just an invitation.
And to start a discussion, and discussion means investing time,
and you will be paid off after that, just as you mentioned.
Yeah, I agree.
You’re looking for the most rich communication techniques that you can use.
Face-to-face contact, face-to-face communication,
even if it’s remotely via video connection,
it’s much better than trying to use documentation.
So that was the second example for having your cards using
for just to start discussion and self-assessment.
Moving on to Agile Card 11, which states,
the team knows how much they can deliver.
It’s a short sentence, but very expressive and with much meaning in it.
And what?
What does that mean in practice, to your point of view?
What you’re actually aiming at with this card is that teams know their capability
and you want the teams to work in a sustainable space.
So when teams know how much they can do and they know their capability,
they also know what they are capable of, what they are not capable of.
They’re in a much better position to make realistic discussions
with the product owners, with their customers,
and to start a conversation.
And to say what they can deliver and what they cannot deliver.
What you want to prevent is putting pressure on teams.
What you want to prevent is overloading them.
And the more teams are capable of knowing what they can do and what they cannot do,
it empowers them in these kinds of discussions when they are put under pressure.
Because then they can say, well, this is how much that we can do.
And what we can actually discuss about is what we will be doing.
But putting more pressure on us won’t give you a better result.
It will actually give you worse results.
So it’s about empowering the team, basically.
Regarding my teams, I have one team in mind,
which overloaded itself for weeks, for several sprints.
They were taking cards and were taking stories for their sprints.
And I think for six, seven or eight sprints, they did not deliver what they committed.
And I got the feeling that they don’t have the point on that.
They are not feeling committed.
Just putting the same pressure.
But if they did not reach their goal, and as I mentioned, six or seven sprints in the past,
they did not reach their goal.
But it doesn’t matter.
It’s okay.
So just take another chance and fail again.
What was a hard work to tell them.
What does it mean?
You know what?
You know what you can deliver, how much you can deliver, and commit yourself to that.
Exactly.
And if you know how much you can do, I’ve seen teams actually where I had to make them
think differently about things like project deadlines.
When they started on the project, when they planned their first sprint, they got worried
like, okay, if we keep on working like this, if this is the amount of stuff that we’ll
be doing every sprint, then we won’t have everything ready at the end of the project.
And then they also started taking on more work and weren’t able to finish it.
So after a couple of sprints, I actually got them together and I told them, like, you should
stop worrying about your project deadlines, about the delivery of your project.
The only thing you should focus upon right now is on the sprints that you are doing.
Trying to do your sprint the best you can.
Learn from what happened in the sprint, use your retrospective to see where you can improve
there.
And if you see where you did well work, what are your strengths that you can use to even
further improve in there.
And if you work in that way, you’re going to be doing the maximum you can.
And if that means that you still can’t make the deadline on the project, well, you’re
not going to make it if you put on more work.
Right.
That’s actually going to backfire.
So that’s not going to be the solution.
So stop worrying about the project scope, stop worrying about the project deadline.
This is something that the project manager and the product officer should do.
And if they know what your capacity is, then they can take the proper decision on prioritizing
what needs to be done.
I think there’s another point to start discussion about different roles and different responsibilities
for that.
It’s quite good.
Exactly.
Exactly.
And this is also where the cars will show whether a certain statement that is made on
the car.
It’s not really a question, it’s more like a statement.
If you have a team.
If you also have teams involved with your product owners and project managers, then
you can actually discuss like, okay, who’s taking responsibility for this?
This is something that we should be doing as a team or multiple teams.
It is something where we expect the product owner to be in the lead.
This is something where we expect the project management to be in the lead.
And the cars will help them to discuss this and to see if this is properly covered or
not.
Right.
And so you can use your cards to rerun the case.
Right.
So you can play the game after three months or six months and have a look if anything
changed.
Exactly.
Exactly.
Actually, I’ve seen teams who use these cards at the start up as a team to discuss, okay,
what’s the main stuff that we should be focusing on right now?
And who’s going to be doing this?
So they use it as a kind of kickoff for their teams right now.
And then after three months, two or three months, again, they take a subset of the cards, do
a kind of self assessment and see how they are doing at that point in time and see what
other things they can do.
And that’s what we’re going to take along right now.
So I would like to move on to the Agile Card 16.
And this means the team tracks progress daily, for example, with burn down charts.
How does a chart help to your point of view?
The main reason of using a chart, which can be a burn up or burn down or any other mechanism,
is visualization.
What you want to do is to make sure that you have the right visualization.
Right.
So what you want to do is to put it in a chart, make it visible for everybody involved
in there.
My experience is that when you start making stuff visible, when you start drawing it
out, whether that’s a whiteboard or whether that’s on a tool or whatever, it becomes a
lot easier for people to discuss it, to see how they are doing.
So visualization is a key technique in there to show how the team is doing.
Yes, I think that’s right.
And regarding my team.
What I had in mind for the Agile Card 11, I asked them to use the burn down charts for
each sprint.
And we got a clear image of what they did not deliver.
So the burn down chart does not burn down.
It doesn’t go to the zero line.
So they saw for five sprints, oh, we did not deliver.
What?
We committed, right?
It’s visualization.
Exactly.
Exactly.
And once it becomes visible, then people can see, okay, is this, is this really a problem
or not?
And how should we act on it?
It prevents a lot of discussion, much more power that you can do with a picture than
you can do with words.
That’s right.
So, um, that’s the Agile Card 18 and I think, uh, it’s, I think would be one of my favorite
cards.
Uh, the trainings I give for, um, scrum and for DevOps.
The Agile Card 18 means, uh, or states face to face conversation is preferred for conveying
information, conveying information.
And I think today it’s often, uh, a challenge.
You have, uh, teams sitting all around the, the world, uh, or, uh, different buildings.
So they’re not in, uh, not sitting together for that.
That’s what, what, what I see it.
Um.
So, um, so I think, uh, the Agile Card 18 is a, is a, is a great platform for, uh, for
most of my clients, for most of my customers.
What’s your, uh, impression for that.
I, I think basically this is becoming the norm.
I think we should start with the assumption that getting all the people at one place,
getting them into one room to do everything that needs to be done end to end is simply
not possible in, I think, nine out of 10 situations, but probably in 99 out of 100 situations.
There’s different reasons for this.
One reason being, that, uh, I think it’s a very good tool.
Das heißt, wenn man die Systeme erledigen möchte, die gerade entwickelt werden müssen,
sind diese Systeme so komplex, dass sie viele Leute betreffen,
und es ist einfach nicht möglich, all diese Leute in einen Raum zu bringen.
Es würde nicht funktionieren, weil es zu viele Leute gäbe.
Das andere ist, dass wir auch nicht denken sollten,
dass wir einfach alle auf die gleiche Stelle kommen und dort sind
und acht Stunden dort arbeiten und zusammenarbeiten.
Menschen können von überall arbeiten,
sei es in ihrer Heimat, sei es in der anderen Teil der Welt.
Und ich denke, remote arbeiten ist der Standard jetzt.
Ich habe meine eigene Situation angeschaut.
Die meiste meiner Arbeit ist gerade remote.
Und ich kann viele Dinge remote machen,
sei es Menschen zu coachen,
zusammen mit Teams zu arbeiten,
meine Trainings- oder Präsentationen zu entwickeln.
Es gibt also viele Dinge, die ich remote machen kann.
Wenn man sich die Kommunikation anschaut,
die eine Sache, die ich versuche,
mit den Teams anzuzeigen, ist,
dass die wichtigste Sache in der Kommunikation Distanz ist.
Und Distanz ist nicht nur physische Distanz,
Distanz ist auch emotional Distanz.
Einer meiner Seitenarbeiten, die ich mache,
ist das Schreiben für InfoQ.
Redakteure für InfoQ sind überall auf der Welt.
Wir sehen uns meistens ein oder zwei Mal im Jahr,
manchmal sogar weniger.
Aber wir haben eine so starke Verbindung mit einander.
Wir kennen die Dinge, die wir am meisten wertschätzen.
Wir kennen die Dinge, die unsere Benutzer,
die Redakteure für InfoQ,
suchen.
Und wir sind so stark verbunden,
dass nicht in dem gleichen Ort zu sein,
eigentlich kein Problem ist.
Denn unsere emotionale Distanz ist sehr klein.
Also kann ich einfach viel machen,
mit E-Mail, mit Slack,
manchmal mit Skype-Anrufen.
Und wir können tolle Sachen machen,
während wir überall auf der Welt distribuiert werden.
Wir müssen nicht in dem gleichen Raum sein,
weil unsere emotionale Distanz sehr klein ist.
Und das zahlt für die physische Distanz.
Und wenn ich physische Distanz meine,
meine Vorrednerin lebt in Neuseeland.
Also das ist ungefähr so weit,
wie wir von dort aus gehen können.
Und wir können zusammen sehr gut zusammenarbeiten.
Okay, also es gibt einen besonderen Sinn
hinter dieser Satz,
hinter dieser Frage.
Okay, also emotional Distanz.
Ich denke, das ist ein guter Punkt,
um darauf zu arbeiten
und darauf zu schauen.
Und das ist aufgrund der Kultur
und der Art und Weise,
wie du und dein Leiter
und wie dein Team
die Arbeit machen
und wie sie zusammenarbeiten.
Richtig.
Ja, ich denke, es ist die Kultur,
die Glauben,
das gemeinsame Mindset,
das Wissen, was wichtig ist,
das Fokus.
Das ist die Art von Sachen,
die deine emotionalen Distanz bestätigen.
Je kleiner diese Distanz ist,
desto mehr bist du auf das,
was wichtig ist,
desto bessere Resultate
bekommst du als Team.
Ja, richtig.
Also gehen wir weiter
zu Agile Card 21,
die sagt,
das Team ist in der Lage,
unabhängig eine konstante Zeit zu halten.
Und wir haben darüber gesprochen,
weil du nicht sicher warst,
ob meine deutsche Übersetzung
den richtigen Sinn hat
oder die richtige Ausführung.
Und wir haben darüber diskutiert.
Was ist deine Idee,
wenn es um die Geschäftspressur geht?
Siehst du,
dass die Geschäftspressur da ist?
Ja, leider sehe ich
noch viel von der Geschäftspressur.
Das ist tatsächlich einer der Aspekte,
die ich in meinem zweiten Buch
über die Qualität der Arbeit
diskutiert habe.
Denn diese Art von Geschäftspressur
und auch die Druck auf den Projektleiter
oder die Druck, die die Projektleiter
auf Teams legen,
tun viel Schaden,
wenn es um die Qualität der Produkte und Service geht.
Also ist diese Art von Druck
immer noch da.
Und für mich ist es
eine Art von Überraschung,
denn wenn du in diesem Bereich sehr tief reingehst,
ist es selten,
dass ich irgendwelche Situationen sehe,
in denen das wirklich funktioniert.
Manchmal, wenn du ein Team kennst,
das genug fähig ist,
technische Dämpfe zu nehmen
und etwas auf kurze Anmerkung zu erlernen
und dann die Zeit zu nehmen,
sich davon zu erlernen
und die Probleme zu lösen, dann kann es funktionieren.
Okay, richtig.
Was ich sehe, ist,
dass es
nicht so viel Druck gibt.
Vielleicht sehe ich es nicht
und es ist da,
aber ich kann es erkennen.
Aber ich denke,
wie du es erwähnt hast,
wenn es nicht so viel Druck gibt,
wenn das Unternehmen weiß,
dass es keine bessere Qualität
oder Software bekommt
in weniger Zeit,
dann ist es okay,
wenn sie darüber sprechen,
wie viel Druck es von der Firma gibt.
Ich denke, es ist okay,
wenn sie darüber sprechen,
wie viel Druck es von der Firma gibt.
Und Druck wird nicht helfen,
um bessere Software zu bekommen
oder um die Software früher zu bekommen.
Das ist eine Diskussion,
die ich gerne sehen möchte
zwischen den Leuten
in der Managementrolle,
den Leuten in den Geschäftsrollen
und den Leuten, die in den Teams arbeiten.
Und ich habe beide Situationen gesehen,
in denen Teams sich beeinflusst haben,
aber ich habe auch Situationen gesehen,
in denen Teams sich mehr oder weniger
beeinflusst haben
und in denen die Leute
von der Produktseite gesagt haben,
es gibt genug Zeit,
nicht zu viel Arbeit zu machen.
Wie wir vorhin diskutiert haben,
Teams beeinflusst sich selbst.
Also gehen wir weiter
zu Asia Card 26.
Wenn jemand sagt,
dass er sich auf ein Produkt
beinhalten möchte,
dann muss er sich selbst
auf ein Produkt beinhalten.
Und er muss sich selbst
auf ein Produkt beinhalten.
Wir haben vorhin gesagt,
dass Teams sich beeinflusst haben,
wenn sie sich auf ein Produkt
beinhalten.
Wenn man sich auf ein Produkt
beinhalten lässt,
dann ist das auch so.
Man muss sich selbst auf ein Produkt
beinhalten.
Du musst sich selbst auf ein Produkt beinhalten,
dich selbst.
Wenn du ohne Software
ausımaßlich
Produkt und Service
haben willst und
nicht deinen Kunden
geven willst,
dann unknown
Und das ist das, was diese Karte versucht zu stressen.
Und tatsächlich, die Art und Weise, wie ich diese Karte gestattet habe,
ist, um Menschen in Diskussionen zu bringen,
wie, okay, aber was ist gemacht?
Was ist wirklich gemacht?
Wann sind wir wirklich gemacht?
Und um Diskussionen zu verhindern,
wie, okay, wir haben gemacht, und wir haben gemacht,
und wir haben gemacht, gemacht, gemacht.
Und dann, gemacht, gemacht, gemacht,
ist, wenn es in den Händen der Benutzer ist.
Nein, du willst nur einen gemacht haben.
Das ist eine End-to-End-Verantwortung.
Und es ist nur gemacht, wenn es tatsächlich da ist,
auf der Kostümseite.
Und jeder Schritt dazwischen,
du kreierst einen Art von Hand-over,
der nur Sachen verlängert,
und der, wiederum,
die Verantwortung und die Verantwortung des Teams abnimmt.
Also, du willst die Schritte so gut wie möglich auswählen.
Ja, das ist richtig.
Aber ich möchte noch etwas beiseite bringen.
Meiner Meinung nach,
wollen die Scrum-Guides,
die Team zu verbessern.
Und eine Art oder eine Teil der Verbesserung
ist,
zu sagen,
wir müssen auf die Definition von DONE arbeiten,
um diese Definition von DONE deutlicher zu bekommen,
um mehr Punkte darauf zu haben.
Also, was die DevOps-Punkte oder die DevOps-Parte betrifft,
denke ich, ist es das Hauptwerk für den Scrum-Master,
zum Beispiel,
um dem Team zu helfen,
auf die Definition von DONE zu arbeiten
und um eine mehr detaillierte Arbeit zu bekommen,
äh, nicht Arbeit,
eine mehr detaillierte Sicht auf ihre,
auf ihre Sicht,
äh, was, was sie sehen,
was DONE bedeutet.
Ich, ich denke, das ist wahr,
aber tatsächlich ist es der Art und Weise,
die du durchgehst.
Zuerst, wenn du mit deiner ersten Definition von DONE beginnst,
ich stimme zu, es wird unkompliziert sein,
du wirst Dinge verpasst,
und wenn du deine Retrospective machst,
wenn du auf das passiert ist,
wirst du herausfinden,
okay, das ist auch etwas, was wir tun müssen,
das ist auch etwas, was wichtig ist,
also, lass uns das zu unserer Definition von DONE hinweisen.
Und ich, im Grunde, denke ich, dass das eigentlich ein gutes Verhalten ist.
Sobald deine Teams mehr wachsam werden,
verändert es sich tatsächlich von einem Art und Weise,
von einer Art und Weise, wie, okay, wir müssen alle Regeln folgen,
und dann wissen wir, dass etwas gemacht wird,
zu einem Art und Weise,
okay, wir wissen, wann ein Produkt gemacht wird,
wenn wir es sehen.
Und es ist auch ein Team, das sich wachsamer wird,
weiß, wie flexibel sie sind,
in der Art und Weise, in der sie ihren Prozess benutzen,
sie wissen, ob sie einen Art und Weise der Software entwickeln müssen,
abhängig davon, was diese Art und Weise betrifft,
abhängig davon, was die potenziellen Risiken darin sind,
abhängig davon, wer darin involviert ist.
Ein wachsames Team weiß, wie man ihren Prozess wachsamen kann,
um das richtige Ergebnis daraus zu bekommen.
Und das bedeutet auch, dass sie mehr oder weniger
die Definition von DONE wachsamen,
abhängig von der Situation, in der sie sind.
Was ich versuche zu sagen,
je wachsamer dein Team wird,
desto kleiner wird deine Definition von DONE.
Initial wird es wachsamen,
aber je wachsamer es wird, desto kleiner wird es.
Denn es wird die Werte verändern,
um eine viel mehr
Mindset- und Goals-orientierte Beschreibung
der Tatsache zu haben,
anstatt den ganzen Prozess zu beschreiben.
Richtig, das stimme ich zu.
Das ist der Art und Weise, den du möchtest.
Du hast weniger Dokumentation.
Das stimme ich zu.
Das stimmt, es wird kleiner für das.
Also wachsame Teams,
das stimme ich zu Agile Card 31.
Das bedeutet, der tägliche Stand-up fokussiert sich
auf das abhängige Arbeit, das vorhanden sein muss
und die Bedingungen und dauert nicht mehr als 15 Minuten.
Was ist deine Erfahrung mit all den Teams,
die du weltweit unterstützt hast?
Gibt es regional oder kulturelle Unterschiede?
Bleiben sie in ihrem Zeitraum?
Mhm.
Ich habe gesehen, dass das eine Herausforderung für viele Teams ist.
Und tatsächlich haben einige Teams sehr gute Habits, das zu tun.
Ich hatte ein Team, mit dem ich an einem Punkt im Zeitraum gearbeitet habe,
das die Worte Point mit einem spezifischen Sinn benutzt hat.
Also wenn jemand in einem Stand-up-Meeting spricht
und die Worte Point benutzt hat, um zu sagen,
okay, ich bin bereit,
es ist Zeit für die nächste Person,
die jetzt zu sprechen ist,
um zu erzählen, wie sie sich dort machen.
Und tatsächlich, wenn jemand auf dem Ziel bleibt,
dann könnte jemand auch schauen,
und ich würde sagen,
Point?
Kann man da aufhören?
Also haben sie einen Art von Habit geschaffen,
um mehr zu den Punkt zu sein,
indem sie das Wort Point mit einem spezifischen Sinn benutzt haben.
Ich habe Teams gesehen, die ihren Stand-up in einer anderen Art und Weise machen.
Oder eigentlich sind die Scrum-Lehrer
viel mehr die Diskussion ermöglichen,
indem sie durch das Board gehen.
Sie geben einfach Zeit zum Reden
für alle Teamleute dort.
Sie machen immer noch sicher,
dass all das, was sich umsetzen muss,
synchronisiert werden muss.
Und dass die Leute versuchen,
Hilfe zu bekommen,
dass sie die Möglichkeit haben,
sich sicher genug zu machen.
Also entwickeln verschiedene Teams
verschiedene Habits darin.
Das ist wiederum, wo ich denke,
die Retrospective ist ein sehr starkes Tool.
Deine ersten Stand-ups werden fehlen.
Es ist ein neuer Weg,
und du musst herausfinden, wie du das tust.
Und deine Retrospective kann dir helfen,
zu sehen, wie die Dinge da sind,
und dann, um bessere Wege zu finden,
mit den Experimenten, mit den Stand-up-Meetings zu machen.
Gibt es irgendwelche kulturellen Unterschiede
oder Unterschiede zwischen den verschiedenen Ländern?
Nun, ich sage oft, dass es kulturelle Unterschiede gibt,
aber ich sehe auch das Gegenteil.
Ich habe mit Teams in Indien gearbeitet,
die ihre Stand-up-Meetings machen.
Und da habe ich zu Beginn Geschichten gehört wie,
okay, ich bin mir nicht sicher,
ob sie wirklich so fokussiert sind.
Und ihre Diskussionen könnten länger sein,
und sie könnten nicht sprechen.
Und ich habe tatsächlich Diskussionen gesehen,
die sehr wichtig waren.
Sie hatten Teams mit acht oder neun Mitgliedern.
Ich habe wirklich alle Arbeit synchronisiert.
Und alle haben gesprochen.
Und sie haben in fünf oder zehn Minuten
mit der Stand-up-Meeting beendet.
Und ich war wirklich beeindruckt,
wie sie es da gemacht haben.
Also, ja, es werden kulturelle Unterschiede geben,
aber oft ist es vielmehr die organisatorische Kultur
als die regionalen Kulturen.
Wenn die organisatorische Kultur
Menschen ermöglicht, sich sicher zu fühlen
und mit Dingen zu experimentieren,
dann können Teams in diesem Bereich Wunder machen.
Und dann ist es egal, ob diese Firma in Indien ist
oder in Deutschland oder in den Niederlanden oder in den USA.
Es geht vielmehr um die lokale Kulturen der Firma.
Okay, richtig, das ist interessant.
Okay, also, ich denke, wir haben ein oder zwei mehr Karten.
Also, bevor wir zum Schluss kommen,
würde ich gerne einige Beispiele von Ihrem Arbeit nehmen.
Agile-Karte 34.
Da ist die Frage.
Die Produkt-Demonstration oder Sprint-Review
wird von vielen Stakeholdern,
Geschäftsführern, Geschäftsführern und anderen Teams besucht.
Was ist Ihre Meinung?
Können Sie uns einige Beispiele von Ihrem Arbeit geben?
Vielleicht von überall auf der Welt?
Ja, ich habe hier eine große Unterschiede gesehen.
Ich habe viele Produkt-Review-Meetings gesehen,
die immer noch eine Art von Beratungs-Meetings sind.
Also, es ist tatsächlich das Team, das Beratungen macht,
und es ist das Team, das den Produkt-Mitglied anbietet.
Und oft ist der Produkt-Mitglied eigentlich der einzige Geschäftsführer in der Raum.
Und ich denke, diese Beratungen sind grundsätzlich nicht wirklich effektiv.
Die Idee der Produkt-Review ist, dass es eine Beratungs-Meetung ist,
in der man Feedback bekommen möchte.
Es ist also keine Beratungs-Meetung.
Man will Feedback auf das Produkt bekommen,
weil man diese Feedback nutzen möchte.
Man will diese Informationen nutzen, um zu entscheiden, worauf man weiter arbeiten möchte.
Und man will überprüfen, ob man das richtige Produkt in der Raum hat,
anstatt darauf zu beraten.
Ich habe Beratungs-Meetings gesehen, die wirklich offen waren.
Ich habe bei einer kleinen Start-up-Firma gearbeitet.
Und im Grunde genommen würde jeder in der Firma in der Raum sein,
wenn sie im Büro waren.
Jeder, also etwa 25 oder 30 Leute,
insbesondere der CEO.
Und tatsächlich habe ich Situationen gesehen,
in denen der CEO zu dem System, das demonstriert wurde, überwacht,
und dann angefangen hat, einige Sachen auszuprobieren und in Sachen zu typen,
und mit der Maus zu arbeiten, um zu sehen, wie das funktioniert.
Okay, wie fühlt sich dieses Produkt an?
Ist das das, was unsere Kunden möchten?
Also hatten sie wirklich alle in der Raum
und es war wirklich möglich, solche Diskussionen in der Raum zu machen.
Ich habe Produkt-Reviews gesehen,
wo ein Team und ein Produktführer zusammenarbeiten.
Und je nachdem, wer im Publikum ist,
es kann sein, dass der Produktführer die Szene setzt
und die Leute in der Raum sicher fühlen,
um in der Raum Feedback zu geben.
Und dann die Leute aus dem Team,
die das Produkt tatsächlich demonstrieren
und zeigen, was sie gerade machen.
Aber sie nehmen auch einen Art von Wunsch für das Arbeit,
das sie in der Raum machen.
Also da ist eine sehr große Unterschiede.
Ich habe Organisationen gesehen, die experimentieren
mit zwei verschiedenen Arten von Produkt-Reviews.
Es war eine Organisation, die nicht zu groß war, aber es war eine Organisation, die nicht zu groß war,
aber es war eine Organisation, die nicht zu groß war,
und es gab zwei verschiedene Orte.
Das Team der Entwicklung war in einem Ort,
die Produktführer waren in einem anderen Ort.
Und sie alternierten ihre Produkt-Reviews,
sie hatten einen Produkt-Review am Entwicklungs-Schein,
wo es nur ein paar Produktführer gab,
die viel mehr auf das technische Teil des Produkts konzentriert waren,
wo das andere Produkt-Reviews
mit einfachen Mehrheitenukeben låst.
Und die anderen Woche waren bei Produktführern.
Und dann waren ein paar Entwickler dort,
die eine strategischere Perspektive mit den beiden Ortebarkeiten
ergeben konnten.
Und indem sie字ieren,
auch in Nina hat sie verschiedene Vorsbuilten,
die sie Grove Bhushabды gelementieren.
Und diese kh hazards!
Das mainly Das eigentlich noch eine rein
Das eigentlich noch eine rein
Äußerliche als setzt es hier auf.
Man hat das Gefühl,
wenn man vitamin-纥 eins passe,
dann hat man einevingtiative Eschshi
Wenn man aufouleist ich habe jetzt im ungefähr der gtver-
persönlich verunssympfung Gefühlt 타
Also sie haben keine saber aus Свφ haben zu tun.
Agile Card 52, the last one for this podcast and the last one from your card set, which means team members enjoy the work that they do, have fun and celebrate successes.
What do you experience? What’s your experience about that?
Well, this actually has some cultural aspect in there. I think what I’ve seen with teams in the Netherlands and also with some of the teams in Germany and there, like celebrating your successes, it’s still some kind of cultural thing like, okay, celebration is something that you don’t do in the office.
If you want to celebrate and you will go out to a bar or you’re going to have a party, but celebrating in the office, like this is work. This is serious stuff, right?
And do you have fun at work?
It’s the same. If you want to have fun, you go out to bars and do it in your private time.
Well, you can still have fun as a team. And I think it’s actually important to have fun. The thing behind having fun is that it also creates a safe culture.
So if it’s safe enough to have fun, if it’s safe enough to have a laugh, if it’s safe enough to sometimes tease somebody a little bit on some stuff, it’s also safe enough to speak up if something is really bothering.
And again, this psychological safety is a key aspect for teams, for people to work together in teams.
So if you want to create this psychological safe environment, making sure that people can also have fun, can have a laugh, is very important because it helps to create this environment, which is so essential for people to work together.
That’s right. Safe safety, yes.
Okay, Ben.
Having a look at the time box, we are just over the 45 minutes, which was our time box, but I think it was a great part.
And I’ve learned very much from your worldwide experience about that.
Is there anything you want to add?
Did I miss some really great card or some really great point?
Well, I think not really a card.
We only went through the HR card.
As you mentioned, there’s a DevOps card.
There’s a set for software.
There’s also a set for business agility, so we take on different aspects of collaboration there.
I think the key thing for this agile self-assessment game is not that much a card, but it’s the playing formats.
And what I actually have seen is that I’ve described, I think it’s something like 10 different playing formats as a guideline with the cards to give people some ideas on how to play with them.
And what I found out is that people actually took this kind of inspiration.
And they developed their own games and developed their own playing situations to use the cards in a way that made sense to them.
And that actually makes me feel very happy.
So that’s again, the difference between game and gamification.
It’s not about the cards.
It’s not about the rules.
It’s about giving people a tool, an agile coaching tool that they can use in the way that works best for them.
And I actually encourage this by saying, okay, if you are a player and you know, if you have a good technique, then you can do it.
Then you can use it.
Okay, wenn du das Produkt kaufst, wenn du die Karten auf meinem Website downloadst, bekommst du freie Lebenszeit-Support.
Also, wenn du diese Karten in deiner Organisation benutzen willst und du eine Frage hast, wie man das macht,
oder du willst nur ein paar deiner Ideen checken, wie man mit ihnen spielen kann,
dann ruf mich an und ich helfe dir mit dem. Ich werde dir einige Ideen geben, wie man das macht.
Oder du kannst deine Ideen mit mir verabschieden, weil ich finde es wichtig, dass die Leute die Dinge in deinem Umfeld benutzen.
Und das ist, warum ich diese zusätzlichen Schritte für die Leute verabschiede, um es ihnen sicher zu machen, Dinge zu probieren.
Okay, danke.
Also, ich werde einen Link zu deinem Website geben, wo jeder die englische oder die deutsche Version kaufen kann,
um dieses große Selbstassessmentspiel zu bieten und agile Arbeit zu bieten.
Also, danke.
Danke dir, dass du ein Gast in meinem Podcast warst und ich hoffe, dass wir uns bald wiedersehen.
Danke, dass du mich besucht hast.

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.

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.

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.