Zu Gast habe ich in dieser Folge Oliver Simon. Er ist Head of IT Technology & Development bei der direct services Gütersloh GmbH. WIr sprechen darüber, wie man in bestehenden Unternehmens-Strukturen die Grundlage für eine DevOps-Entwicklung schafft und wie Altbekanntes dabei auf den Prüfstand gestellt wird. Oliver Simon berichtet dabei von seiner Reise aus den letzten Jahren. Zu Beginn klären wir gemeinsam die Fragen: „Was ist DevOps und was ist es nicht? Was bedeutet DevOps für uns?“ Weiterhin sprechen wir über die Notwendigkeit von DevOps und was aus der Sicht von Oliver alles dazu gehört.
In dieser Podcast-Episode erörtern Gastgeber Dierk Söllner und Gast Oliver Simon die Komplexitäten der Integration von DevOps in eine Organisation. Sie behandeln die anfänglichen Herausforderungen, DevOps in einem Unternehmen greifbar zu machen, die Entwicklung vom traditionellen Entwicklungs- und Betriebsmodell hin zu einem kooperativeren und effizienteren Ansatz sowie die Rolle von Tools bei dieser Transition. Die Diskussion umfasst wichtige Themen wie das Überwinden der ‚Mauer der Verwirrung‘ zwischen Entwicklung und Betrieb, die Bedeutung von kontinuierlicher Integration und Auslieferung sowie die Notwendigkeit organisatorischer Veränderungen, um die Vorteile von DevOps wirklich zu nutzen. Sie betonen die Rolle der Teamdynamik, kontinuierliche Verbesserung und den entscheidenden Aspekt, ein Gefühl von Eigentum und Verantwortung unter den Teammitgliedern für ihre Produkte zu schaffen.
Inhalt
- Einführung in DevOps und seine Definition
- Entwicklung von DevOps in Organisationen
- Abbau der ‚Mauer der Verwirrung‘ zwischen Entwicklung und Betrieb
- Übergang vom traditionellen Entwicklungs- und Betriebsmodell zu einem integrierten Ansatz
- Rolle von Tools bei der Implementierung von DevOps und organisatorischen Veränderungen
- Kontinuierliche Integration (CI) und kontinuierliche Auslieferung (CD)
- Teamdynamik und die Bedeutung eines kooperativen Umfelds
- Herausforderungen des organisatorischen Wandels bei der Adoption von DevOps
- Das Gleichgewicht zwischen Automatisierung und manueller Intervention
- Das Konzept von ‚Alles als Code‘
- Die Integration von Agile, Lean und IT Service Management mit DevOps
- Die Bedeutung von Teamautonomie und Verantwortung
- Kontinuierliche Verbesserung und die Rolle von Metriken in DevOps
- Schlussfolgerungen und abschließende Gedanken
Transkript (automatisiert erstellt, daher keine Gewähr 🙂 )
DevOps. Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Dirk Söllner.
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps. Auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begleite Unternehmen auf dem Weg zu einer hochperformanten
IT-Organisation und nutze dazu unter anderem DevOps. DevOps umfasst für mich kulturelle,
organisatorische, prozessuale und technische Aspekte. Diese diskutiere ich in diesem Podcast
mit Experten aus der Praxis. Ich freue mich heute auf das Thema DevOps, eine organisatorische Reise
ins Ungewisse. Zu Gast habe ich Oliver Simon von der Direct Services Gütersloh GmbH. Er ist dort
Head of IT Technology und Development. Hallo Oliver. Kannst du dich vielleicht zum Beginn
einfach mal kurz vorstellen? Ja, gerne. Hallo Dirk. Mein Name ist Oliver Simon. Du hast mich ja schon,
was meine Bezeichnung meines Jobs angeht, schon vorgestellt. Ich bin 48 Jahre alt,
schon seit einigen Jahren auch in dem DevOps-Umfeld unterwegs. Ich habe ungefähr 40 Mitarbeiter,
wesentlichen mit dem Thema Softwareentwicklung beschäftigen und über diesen Kontext sind wir
auch beim Thema DevOps letztendlich gelandet. Super. Ja, schön, dass du dabei bist und bei
meinen Gästen habe ich ja immer kurz nach der Vorstellung kommt ja immer die Frage DevOps. Wie
würdest du DevOps definieren? Wie würdest du DevOps beschreiben? Und insofern, das ist ja genau auch
unser Einstieg hier. Also insofern würde ich sagen, ja, ich spiele den Ball gleich wieder zurück. Was ist
das für dich? Genau. Lass uns mal rausfinden, was das für uns beide ist. Ich bin mal ganz gespannt,
welches DevOps-Bild sich für uns beide herauskristallisiert. Aber ich fange gerne mal an.
Zumindest hat es sich bei uns als sehr schwer herausgestellt, im Unternehmen DevOps überhaupt
greifbar zu machen. Ich gehe nochmal ein Stück weit in der Zeit zurück und beschreibe mal,
wie wir ursprünglich mal mit dem Thema DevOps gestartet sind. Im Wesentlichen hieß bei uns,
DevOps vor einigen Jahren, Development macht Operations. Dev macht Ops. Das war so der
ursprüngliche Gedanke und das ursprüngliche Gefühl zum Thema DevOps. Es hat sich aber doch
rasant verändert. Für mich ist DevOps etwas, was sich damit beschäftigt, diese berühmte
Wall of Confusion zwischen Dev und Ops anzugehen und sie möglichst niederzureißen. Ich glaube,
diese Wall of Confusion, ich glaube, das hat jeder auch schon mal gehört, ist im Wesentlichen,
der Spannungsfeld zwischen Veränderung auf der Dev-Seite und Stabilität auf der Ops-Seite.
Und das sind Dinge, die gegebenenfalls gegeneinander arbeiten und darüber entsprechend
Abgrenzungen zwischen diesen beiden Bereichen aufbauen. Man kann es vielleicht noch ein bisschen
anders beschreiben. Letztendlich geht es doch darum, von einer Vision hin zu einem Value zu kommen. Und
auf der Visionsseite, auf der Visionseite, auf der Visionseite, auf der Visionseite, auf der Visionseite,
auf der Visionseite, auf der Visionseite, auf der Visionseite, auf der Visionseite, auf der Visionseite, auf der Visionseite,
sind dann oft Themen wie Innovation, Komplexität und eben Veränderung von Relevanz. Auf der Value-Seite
eben die erwähnte Stabilität, aber auch Skalierbarkeit und Verlässlichkeit. Wie kommt man von einem zum
anderen, sind im Wesentlichen Dinge, die meines Erachtens das im Dev-Ops-Konstrukt.
Ich wollte nochmal ganz kurz einhaken, weil du hast eben so zwei Sachen angesprochen, die finde ich
sehr, sehr interessant. Erstens hast du gesagt, Dev macht Ops. Und meine Erfahrung ist, dass häufig
ich sage mal echte Entwickler, was auch immer echte Entwickler sind, aber die Entwickler, die ich treffe,
die sind häufig nicht drauf erpicht, Ops zu machen. Weil Ops heißt ja, wenn ich es ein bisschen weiterfasse,
ja nicht nur irgendwo einen Server aufsetzen, das geht ja vielleicht noch, aber Ops heißt ja auch
Störungsbeseitigung, Ops heißt vielleicht auch Verfügbarkeit, also im Sinne von Erreichbarkeit,
24-7 und so weiter. Also wenn ich die Ops-Tätigkeiten ein bisschen weiterfasse, sind das manchmal Dinge,
die Devs nicht machen wollen. Ja, das ist sicherlich auf der einen Seite wahr und es sind
teilweise auch organisatorische Themen, die dagegen sprechen. Wenn ich ein Dev-Team habe, das
beispielsweise drei oder vier Mitarbeiter umfasst, ist es ganz, ganz schwer, Dinge wie einen 24-7-Support
überhaupt zu organisieren. Selbst wenn die vier Leute das wollten, ist es organisatorisch einfach
nicht ohne weiteres umsetzbar. Das ist so etwas, was gegen Dev-Macht-Ops spricht.
Es gibt aber sicherlich Teams und Dev-Teams, die gerne auch Ops machen und sich dafür auch
verantwortlich fühlen. Das sind durchaus Dinge, die dem Dev-Ops-Gedanken meines Erachtens sehr
entgegenkommen, dieses Verantwortungsgefühl wahrzunehmen und zwar über den gesamten
Lebenszyklus der Applikation letztendlich selbst auch. Allerdings, warum habe ich gesagt, das sind
Dinge, die wir ein Stück weit hinter uns gelassen haben, das liegt im Wesentlichen daran, dass
ich die Erfahrung gemacht habe, dass Menschen in der Softwareentwicklung oft gar nicht so einen
ausgeprägten Ops-Charakter haben und für sie ganz andere Dinge wichtig sind als Operations selbst.
Oftmals entsteht eben keine Software, die ausgesprochen gut betreibbar ist. Das heißt
noch lange nicht, dass ein Entwickler, wenn er eine Plattform betreibt oder einen Service betreibt,
dass dies auch in idealer Weise funktioniert.
Und besonders effizient passiert. Deshalb haben wir uns ein Stück weit von dem Thema
Dev macht Ops zurückgezogen und versuchen eher
alle Aspekte, die zur Entwicklung oder zur Verfügbarkeit
und zur Betreibbarkeit eines Services gehören, auch in der besten Ausprägung
zu liefern.
Ja, okay. Das würde ja auch heißen, wir sind ja eigentlich mitten im Thema letzten Endes.
Wie würde ich so etwas umsetzen? Vielleicht kommen wir da später
auch nochmal mit drauf, weil wir wollten ja auch ein bisschen über die Reise sprechen,
die ihr gemacht habt. Du hast jetzt eben gesagt, Dev macht Ops ist nicht mehr so der Fokus gewesen.
Das gab verschiedene Gründe dafür. Und wir wollten klären, was ist Dev Ops überhaupt?
Und da kann man ja auch mal klären, was ist Dev Ops denn nicht? Und für mich ist eben ganz klar,
und das ist vielleicht auch dann eine gute Frage auch an dich, aus meiner Sicht kommen dann
Tool-Hersteller häufig mit dem Punkt, ja, wenn du mein Auto,
Automatisierungstool kaufst und einsetzt, dann machst du Dev Ops.
Ja, das ist zumindest ein zweischneidiges Schwert. Ich sag’s mal so,
interessanterweise ist unsere Dev Ops Journey, ist die gestartet
mit der Frage nach Continuous Integration
und Continuous Delivery vor ungefähr zweieinhalb Jahren.
Und daraus ist erstmal der Wunsch entstanden,
Software, also Services auf eine andere Art und Weise
zu liefern, als wir es heute tun. Das hat was mit Automatisierung logischerweise zu tun,
auch ein ganz starkes Dev Ops Artefakt, aber im Wesentlichen auch damit möglichst gleichförmig
und möglichst nachvollziehbar wiederholbar Software zu liefern, also Services zu liefern,
sodass unser Operations-Bereich, den wir heute nicht mit in einem der Dev Teams sitzen haben,
auch möglichst gleichförmige Lieferungen bekommt.
Und so auf diese Art und Weise viel eher akzeptieren kann,
dass sich Dinge kontinuierlich ändern.
Ich sag’s mal so, über dieses CI-CD,
über dieses CI-CDs-Learning sind wir
weiter in den Prozess gestiegen, haben uns mit dem Thema
Dev Ops Fundamentals beschäftigt, sind in Schulung gegangen, haben Mitarbeiter
spüren lassen, auch ein Stück weit, was Dev Ops bedeuten kann,
sind dann aber relativ schnell
zum Spaß der die Tools an in die Diskussion gekommen, welche Art von Unterstützung wir uns eigentlich
zum Thema Dev Ops holen können, was Tools angeht.
Im Wesentlichen sind wir an der Stelle bei einer PaaS gelandet,
eine Plattform as a Service, wie man so schön sagt,
und haben uns Software eingekauft, die uns dort in der Delivery stark unterstützt.
Und was dann passiert ist, es ist insofern wirklich spannend,
für mich gewesen, weil wir vom
Tool letztendlich doch zur Organisation
gelaufen sind. Über die Nutzung des Tools oder die Nutzung der Tools
haben einfach Mitarbeiter angefangen zu sagen, hey, wir sind nicht richtig
organisiert, wir müssen uns anders aufstellen, wir sind zu sehr voneinander getrennt.
Lass uns gucken, wie das besser funktionieren kann.
Und so haben sich bestimmte DevOps-Konstrukte
tatsächlich ein Stück weit von allein herausgebildet,
wie beispielsweise das, ich glaube, bekannte
Plattform-Team, das dafür da ist, bestimmte
auch Cloud-Services den Dev-Teams zur Verfügung zu stellen.
Insofern hat das schon ein Stück weit so funktioniert,
dass wir auch vom Tool zur Organisation gekommen sind.
Okay, wobei das ja dann schon zeigt, dass da die
Menschen im Unternehmen mitgedacht haben,
und gesagt haben, hey, wir haben eine gewisse Verantwortung, wir wollen besser werden,
und wir haben ein gutes Tool eingekauft, das sollte man ja dann mal voraussetzen,
und wenn wir das Tool richtig nutzen wollen, müssen wir uns auch organisatorisch verändern.
Da kann es ja auch immer mal sein, dass ein Team dann eben sagt, okay, das Tool ist schlecht,
weil man eben die Organisation nicht angepasst kriegt, oder es wird nur
in einer, ich sag mal, niedrigen Eifergrad genutzt. Das heißt also,
bei euch höre ich raus, hat die Organisation sich verändert,
weil die Menschen das so wollten.
Die Menschen erkannt haben, wir müssen etwas verändern, richtig?
Das kann man durchaus so sagen. Ich glaube, es war erst die Organisation im Vordergrund,
und das Lernen auch auf die theoretische Basis zu setzen,
aber der Wunsch war relativ schnell da, viel stärker
in die Praxis zu gehen. Ich habe ungefähr, bestimmt
drei bis vier Monate investiert in die theoretische Schiene. Wir haben sehr viele
Workshops, auch in einer sehr cross-funktionalen Art und Weise, also über
alle Teams, nicht nur im Team, sondern auch in der Praxis.
Nicht nur im Dev-Bereich, sondern auch im Ops- und im Projektmanagement-Bereich
hinweg organisiert, haben uns dem Thema, in diesem Fall Continuous Integration
und Delivery, stark genähert. Und irgendwann gab es in diesen Workshops
einfach den Wunsch zu sagen, lass uns nicht weiter theoretisieren,
lass uns einfach so konkret werden, dass wir auch selbst was damit
aktiv anfangen können. Ein ganz klassisches nächstes Ding war dann
ein Hackathon, den wir veranstaltet haben.
Der sich auch im Wesentlichen um den Bereich Continuous Integration
und Delivery handelt oder gedreht hat.
Und daraus ging es dann relativ schnell auch weiter
in die Bildung eines eigenständigen Teams, dass
die Plattform, auf der wir dann in der Zukunft
deliveren wollten, auch zur Verfügung gestellt hat. Daraus ist
immer mehr auch der Wunsch entstanden, alle
Beteiligten in dieser Delivery-Kette zu involvieren.
Und dieses Involvement führt immer stärker für mich
zu einem ausgeprägteren DevOps-Gedanken. Da sind wir aber auch noch
ganz am Anfang, muss man immer dazu sagen. Das ist etwas, was sich
glaube ich einfach entwickeln muss und was sich aber
am besten entwickelt, wenn es von den Mitarbeitern kommt
und als Organisationsform künstlich aufgepropft wird.
Ja, naja, klar.
Ich habe vorhin so einen Satz bei dir rausgehört, da wollte ich nochmal nachfragen.
Ich habe verstanden, dass ihr nicht DevOps-Teams
habt, wo also quasi Dev und Ops als
Aufgabe zusammen in einem Team wahrgenommen wird. Ist das richtig?
Das ist im Prinzip zu einem gewissen Prozentsatz auf jeden Fall richtig.
Wir haben durchaus auch Teams,
die Operations auch mitmachen als Development-Teams.
Ich halte diesen Anlass aber nicht unbedingt für
zielführend, aus den vorhin schon erwähnten Gründen.
Mit kleineren Teams kann man bestimmte Funktionalitäten oder bestimmte Services eigentlich
gar nicht liefern, wenn man sich so aufstellt.
Auf der anderen Seite glaube ich, dass Developer
an sich
nicht besonders gute
Skills haben, was den Betrieb grundsätzlich angeht.
Also Software so zu bauen, dass sie auch ideal betreibbar ist.
So holen wir uns dann in der Regel lieber die Expertise
dazu hinein in Teams und versuchen auf der Basis
eine möglichst gut betreibbare Software zu liefern, die aber dann nicht
direkt durch die Dev-Teams oder DevOps-Teams, wenn man so möchte, betrieben werden.
Okay. Genau. Sondern es gibt ein weiteres Team,
das das entsprechend tut und darüber entsprechend auch beispielsweise
Services wie 24 mal 7 zur Verfügung stellen kann.
Ja. Okay. Das ist auch klar. Ich höre auch häufig, dass man einfach auch über die Kostenseite kommt.
Dass man sagt, ich habe teure Entwickler und die müssen nicht 24 mal 7 quasi
bezahlt werden. Also egal, wie du es organisierst, das kann ja auch
zu erhöhten Kosten führen. Und man will ja die teuren Entwickler
vielleicht auch nicht in die preiswerten oder preiswert abrechenbaren
Betriebsfähigkeiten stecken. Oder ist das für euch kein Thema?
Kosten sind immer ein Thema, würde ich mal behaupten.
Das ist ja gar keine Frage. Auf der anderen Seite
muss man sich immer vor Augen halten, was DevOps eigentlich
erreichen möchte. Für mich möchte man
gerne durch DevOps so etwas wie eine zentrale
Verantwortlichkeit erzeugen.
Also sprich Menschen mit einem Produkt, mit einem Service
identifizieren und sie dann auch mit einem Service identifizieren.
Und die auch dazu bewegen, so viel Verantwortungsgefühl und so viel
auch Lust auf dieses Thema zu erzeugen, dass es in idealer Weise
entwickelt und betrieben werden kann über den gesamten Lebenszyklus.
Das ist, glaube ich, auch der Grund, warum man bestimmte andere Teams
bildet, wie beispielsweise ein Plattform-Team, das bestimmte Leistungen
halt dem DevOps-Team zur Verfügung stellt. Grund ist letztendlich,
dass man die Leistungen, die man hat, die man hat, die man hat, die man
gar nicht möchte, dass sich Verantwortung über mehrere
Instanzen, über mehrere Silos hinweg erstreckt.
Das, was man doch erlebt hat, und das ist vielleicht auch die Frage, warum überhaupt DevOps,
das ist doch die Erfahrung aus der Vergangenheit, dass
wenn man in sehr effizienter Art und Weise in Silos arbeitet,
dass dann Verantwortlichkeit für
sein Produkt eher nachlässt, weil man eher nur Teil
einer längeren Kette ist.
Und das Ganze und das Große und Ganze letztendlich gar nicht mehr so richtig sieht.
Also ich würde da mal einhaken, du hast es so nett gesagt, Verantwortlichkeit lässt nach.
Meine Wahrnehmung ist, wenn ich Silos habe, wenn ich lange Prozessketten
habe, die in unterschiedlichen Abteilungen durchgeführt werden, dann habe ich
eigentlich gar keine Verantwortlichkeit mehr für ein Produkt oder für einen Kunden.
Dann bin ich nur noch verantwortlich für die Arbeitsschritte, die ich machen muss,
von dem Eingang in meinen Prozess bis hin zum Ausgang.
Insofern finde ich, das hast du vorher auch sehr schön gesagt,
ein ganz wichtiger Punkt ist, diese Verantwortlichkeit herzustellen.
Also auf der einen Seite die organisatorisch zu regeln, also Verantwortung wirklich
organisatorisch jemandem zuzuweisen, einem Team oder
einer Gruppe von Leuten und die auch dazu befähigen und
zu ermächtigen, diese Verantwortlichkeit umzusetzen und auch zu spüren
und das auch so zu empfinden und nicht die Verantwortung aufzuoktroyieren.
Ja, ich glaube tatsächlich, das ist so.
Und insofern ist es immer ein zweischneidiges Schwert, sich anders zu organisieren,
als sozusagen einem zentralen Team, nennen wir es ruhig weiter Dev Team, diese
Verantwortung für alles, alle Gewerke rund um den Service halt zu geben.
Wenn man das aufbietet, muss man genau wissen, was man tut.
Das hat dann gegebenenfalls kommerzielle Gründe, wie du schon sagst, völlig korrekt,
aber eben auch Service-Erbringungsgründe.
Manche Konstellationen lassen sich in einem einzelnen Team einfach gar nicht gut abbilden,
sodass man nach Alternativen suchen muss, wie das denn eigentlich besser geht.
Aber ich bin schon der Meinung, dass gerade dieses typische
Cross-Funktionale auch sicherlich ein weiteres, sagen wir mal,
Merkmal von DevOps sehr, sehr wichtig ist, sodass man
eben nicht über viele Silos hinweg, wie du halt jetzt weißt,
ich habe einen DBA und ich habe jemanden, der mir ein Stück Infrastruktur zur Verfügung stellt.
Ich habe jemanden, der
Java programmieren kann. Ich habe jemanden, der mir das Frontend baut. Ich habe jemanden und so weiter.
Solche Silos kann man ja beliebig weiter fortführen.
Das hat zwar den Vorteil, dass man in den Silos besonders effizient arbeiten kann,
aber sicherlich der Einzelne
für den Service oder das Produkt, was eigentlich zur Verfügung gestellt
werden soll, gar nicht so richtig mehr ein Gefühl hat
und damit entsprechend auch sich immer weniger
verantwortlich fühlt für das Endergebnis.
Das ist nicht gut. Das möchte sicherlich DevOps auch verändern und verbessern.
Ja, auf jeden Fall. Und du sprichst ja immer von der Effizienz in diesen
Silos. Das ist dann ja auch nur eine suboptimale Effizienz. Also ich habe ja dann
100 suboptimale effiziente Prozessschritte,
aber ob das insgesamt effizient ist, also aus Unternehmenssicht, aus
Kundensicht, das müssen wir glaube ich nicht beantworten. Die Frage, die ist schon klar,
das ist dann eben genau nicht effizient. Und die Frage ist ja auch,
muss ich in der heutigen Zeit effizient sein oder kann ich nicht
eher über Effektivität auch Potenziale heben an der Stelle?
Ja, keine Frage. Ich sage noch was dazu, weil das
ein ganz anderes Thema für mich ist. Da verknüpfen sich nämlich auf einmal
bestimmte andere Disziplinen mit DevOps, wie
beispielsweise Lean an dieser Stelle. Ein Lean-Mechanismus versucht
eben genau das zu vermeiden, dass Reibungsverluste
zwischen Silos entstehen. Beziehungsweise Silos am besten zu vermeiden, sodass
gar keine Reibungsverluste überhaupt erst entstehen können. Das ist ein ganz
klassischer Ansatz, den Flow zur
Erzeugung des Produktes möglichst störungsfrei laufen zu lassen
und eben genau solche Aufwände zu vermeiden.
Das passt dann ganz gut wieder zu DevOps tatsächlich.
Ja, und ich finde in dem Zusammenhang auch den Blick auf Lean
sehr, sehr interessant, denn wenn ich jetzt DevOps
beschreibe in meinen Schulungen, dann sage ich immer, DevOps besteht aus
Agilität, also das Thema Agile reinzubringen, das Thema Lean reinzubringen
und eben IT-Service-Management, also Betriebstätigkeiten. Also DevOps
ist da für mich eben kein Framework, sondern eine
Philosophie und das spricht ja aus dem auch, was du erzählt hast. Also ihr habt
euch natürlich ausgebildet, schlau
gemacht, was es da so gibt, aber ihr habt ja nicht ein Framework genommen und das
quasi bei euch eingeführt, sondern ihr habt euch, wie gesagt, mit dem
Thema beschäftigt und ich würde jetzt nochmal genau
eben auf den Punkt eingehen, den du eben gesagt hast, Lean und
wir haben ja viel über Teams gesprochen, Cross-Funktional-Teams, das ist ja
wiederum agil. Also die Frage wäre, wie viel von diesen
drei Themen, die ich eben genannt hatte, steckt bei dir, steckt bei
euch in dem DevOps-Gedanken, also Agile, Lean und IT-Service-Management?
Kannst du da so ein bisschen was
aufteilen? Den Ansatz zur
agilen Entwicklung von Software hatten wir schon vor einigen Jahren
auch ganz losgelöst von dem Gedanken zu DevOps,
sondern ganz eigenständig in dem Wunsch, dass wir
in einer sich ständig komplexer gebenden Welt
in der Lage sind, diese Komplexität auch
in der Softwareentwicklung möglichst gut zu managen und immer noch
in der Lage sind, die Produkte liefern zu können. Agile ist für mich
im Fokus immer das Thema Satisfy the Customer,
was sicherlich bei DevOps auch nicht groß anders ist.
Letztendlich geht es aber darum, in kleineren Einheiten zu liefern
und immer wieder auf das Feedback des Kunden,
des Product Owners zu achten, das einfließen zu lassen und
daraus entsprechende Schlüsse zu ziehen und die Software
daraus entsprechend zu verändern.
Was auch ganz oft im Fokus steht, ist ein kontinuierlicher
Verbesserungsprozess, der auch letztendlich Teil
hier auch von Lean, aber auch letztendlich von DevOps ist.
Ich sprach vorhin schon von der Verantwortlichkeit
des Dev-Teams und das bezieht sich auch
natürlich darin, möglichst das beste Dev-Team zu werden,
das diesen Service liefert und dann auch
aktiv und eigenständig in einen kontinuierlichen
Verbesserungsprozess zu investieren.
Ich spreche nochmal ein Thema an, was für mich
tatsächlich auch in all diesen Bereichen stark ausgeprägt ist
und stark wichtig ist. Das ist das Thema Autonomie.
Ich glaube gerade
im DevOps-Bereich ist es wichtig, dass man
alle Facetten von Autonomie,
die man in der Software hat, versteht und ausprägt,
sodass überhaupt eine Eigenständigkeit entstehen kann.
In der Regel ist ein Team von derartig vielen Dingen abhängig,
dass eine Eigenständigkeit und vor allen Dingen auch eine eigenständige
Verantwortlichkeit oftmals gar nicht so recht entstehen kann.
Das ist genau ein Thema, was uns auch gerade aktuell stark umtreibt,
was auch ein Stück weit zu der Form von Organisationen geführt hat, die wir heute haben.
Jetzt habe ich ja eben drei Frameworks genannt, drei Bereiche genannt und zwei hast du erläutert.
Der dritte Bereich IT-Service-Management, Betriebstätigkeiten, ist für dich deswegen,
es ist zwar im DevOps-Gedanken mit drin, aber eigentlich quasi nur,
nicht nur, nur ist es schon so abwertend. Also es ist mit drin, aber es ist nicht
in dem Team-Gedanken an sich mit drin, es ist an deinem Team entsprechend aufgebaut,
sondern dass man das in der Arbeit, in der täglichen Arbeit berücksichtigt
und Ops-fähige Produkte liefert. Richtig?
Sehr richtig. Wobei natürlich eins nicht missachtet werden darf,
ein Software-Entwickler ist auch immer für den Third-Level-Support zuständig.
Das heißt, nicht alle Themen sind beispielsweise durch den Service-Desk abbildbar,
sondern man ist immer dafür verantwortlich, schlussendlich welche Software man geschrieben hat.
Und muss natürlich auch im täglichen Betrieb an der einen oder anderen Stelle helfen können und wollen.
Letztendlich ist es ja auch so, es gibt so einen schönen Begriff, der heißt
Create with the End in Mind. Das heißt, ein ganzheitlicher Prozess soll abgebildet werden
und man ist nie, auch wenn ein Produkt schon live gegangen ist, aus dem Operator,
aus dem Operations-Bereich raus.
Das finde ich so interessant, wenn ich, ich habe Schulungen zum Thema DevOps häufig auch in größeren Organisationen
und dann kommen die nach so einem halben Tag, so nach drei, vier Stunden, sagen sie,
was sollen wir uns da erzählen zu DevOps? Das haben wir früher auch gemacht.
Also früher hieß es dann so vor 10, vor 15 Jahren, vor 20 Jahren.
Da war das Ganze ja auch noch sehr gut machbar, weil man häufig ja erst oder nur kleinere Applikationen hatte.
Die ganze Komplexität, die wir technisch heute haben, die war nicht so einfach.
Und dann sagen die natürlich, also ich habe da entwickelt, mein Kollege, mein Entwicklerkollege saß mir gegenüber
und wenn wir ein Ops-Thema hatten, dann sind wir einfach einen Raum weitergegangen
oder auf dem Flur einmal hoch und dann saß der Ops-Mann da.
Also letzten Endes kommt das häufig, kommt der Hinweis, haben wir früher gemacht und das war viel besser.
Wir haben uns viel besser gefühlt.
Ja, es ist auch ganz klar, wenn man letztendlich für die gesamte Kette verantwortlich ist,
möglichst wenig Abhängigkeiten zu anderen hat, ist man auch viel eher in der Lage, kontinuierlich etwas zu liefern.
Abhängigkeiten, wir waren vorhin bei den Silos gedanklich, erzeugen auch immer Reibung
zwischen verschiedenen Schritten in der Zur-Verfügung-Stellung von Software oder Services.
Das ist etwas, was man sicherlich weder mag, noch ist es besonders gut in der Verfügbarkeit des gesamten Services.
Insofern kann ich gut nachvollziehen, wenn jemand sagt, früher war alles besser.
Da haben wir alles aus einer Hand geliefert und das, was wir heute propagieren,
ist doch das, was wir früher schon gemacht haben im Wesentlichen.
Das stimmt vielleicht sogar in gewissen Ansätzen.
Nichts ist letztendlich so neu.
Was aber ein Stück weit für mich neu ist, jetzt kommen wir wieder zu dem Thema Tools,
ist die Unterstützung.
Die Unterstützung in der Delivery als solches, was die Verfügbarkeit von Tools angeht,
die man in dem Zuge einsetzen kann.
Die Form beispielsweise von Automatisierung oder Automatisierbarkeit aller Bestandteile eines Services,
so wie sie heute machbar ist, die gab es vor 20 Jahren in der Form einfach nicht.
Und so ist es heute einfach viel einfacher umsetzbar, in einen kontinuierlichen Verbesserungsprozess überhaupt zu investieren.
Denkt mal an das ganze Thema Dokumentation zum Beispiel.
Wie deploye ich überhaupt eine Applikation?
Das kann man aufschreiben in Word-Dokument und das immer schön aktuell halten.
Das hat man sicherlich vor 20 Jahren so gemacht.
Oder man schafft sich einen Prozess, der hochautomatisiert ist
und der seine Dokumentation sozusagen schon in sich enthält,
weil alle Schritte, die notwendig sind, um ein Stück Software live zu bekommen
oder überhaupt zu deployen, dort schon enthalten sind.
Ich brauche gar keine Dokumentation im Word-Format mehr.
Ich kann, wie man schon sagt, Everything as Code, Documentation as Code, feine Sache,
investiert super in einen kontinuierlichen Verbesserungsprozess.
Und da kommen wir auch wiederum zu dem Qualitätsanspruch und zu dem Verantwortungsbewusstsein,
dass eben jemand, dass ein Entwickler auch vielleicht sagt, ich habe keinen Bock zu dokumentieren,
also nicht extra in Word oder in anderen Text-Tools, Latex oder so, oder Latex oder so,
aber dass er eben einfach sagt, ich will nicht dokumentieren in Word
und ich baue die Software so, ich baue meine Toolkette so auf,
dass ich das gar nicht mehr muss an der Stelle.
Dass es eben auch ohne Dokumentation funktioniert.
Ja, ein wirklich entscheidender Punkt.
Deshalb glaube ich, das ist auch heute anders als vor 20 Jahren.
Ich bin der festen Überzeugung, dass auch solche Dinge wie Wissen teilen zum Beispiel,
auch ein wichtiger Punkt.
Dass man nicht auf seinem Wissen-Stack sitzt, sondern möglichst alle mit beteiligt.
Deshalb machen wir heute auch einen Podcast, weil wir eigentlich davon doch erfüllt sind,
unser Wissen teilen zu wollen.
Das ist total wichtig und das geht viel einfacher, wenn man Dinge gleichförmiger gestalten kann,
um auch gerade stark automatisierte Dinge teilen zu können.
Wenn ich erstmal einen Delivery-Prozess habe für eine bestimmte Art von Applikation,
dann kann die ein anderer auch nehmen, verbessern, wieder zurückführen in die Automatisierung
und so darüber wieder andere teilhaben lassen an dem, was er oder sie gemacht hat.
Richtig.
Und das halte ich für einen ausgesprochen großen Move unserer heutigen Zeit
und das entscheidet uns sicherlich vor dem, was wir vor 20 Jahren getan haben.
Ja, und auch vor 10 Jahren, wie auch immer, wenn man eine Zeitscheibe zurückdreht.
Du hast eben von kontinuierlicher Lieferung gesprochen.
Und da würde ich jetzt gerne nochmal ein bisschen auf so,
einen eher technischen Punkt vielleicht eingehen,
oder einen auch technischen Punkt, Continuous Delivery.
Ein wichtiges Thema. Würdest du das vielleicht nochmal ganz kurz erläutern,
was so dein Bild ist von Continuous Delivery?
Ja, ich habe da insofern ein etwas spezielles Bild,
weil ich persönlich für mich die beiden Begrifflichkeiten Continuous Deployment
und Continuous Delivery gar nicht voneinander unterscheide.
Halte ich persönlich für nicht besonders zielführend.
Vielleicht kurz der Unterschied, zumindest der sich mir erschließt.
Der liegt darin, dass, wie soll man sagen, die beiden Presse unterscheidet,
inwiefern das Deployment auf Produktionsumgebung automatisiert abläuft oder nicht.
Dafür ist aber der Unterschied für mich so gering,
dass es für mich wenig Sinn macht, überhaupt zwei Begrifflichkeiten dafür anzunehmen.
Aber im Wesentlichen geht es darum,
dass man am liebsten von der Erfassung der Anforderungen
bis hin zur Lieferung des gesamten Services auf eine Produktionsumgebung
die gesamte Deliverykette automatisiert hat.
Angefangen bei den Anforderungen habe ich deshalb formuliert,
weil solche Dinge wie Abnahmekriterien beispielsweise,
eher aus fachlicher Sicht gesehen,
in einer stark automatisierten Umgebung natürlich eine große Rolle spielen.
Ja.
Je mehr ich sozusagen wieder an manuellen Schritten machen muss,
desto weniger kontinuierlich kann ich liefern.
Deshalb spielt auch die anfängliche Anforderung schon in der Kette für mich eine Rolle.
Klassisch startet die Kette in der Regel mit einem Einchecken von einem Stück Code,
über das Bilden des Codes, über das Testen des Codes,
über das Zusammenfügen in der Regel Containertechnologien
bis zum Ausrollen der Container,
der oder der,
des oder der Container in einer orchestrierten Umgebung,
wie auch immer die aussehen mag.
Wir setzen beispielsweise Docker und Kubernetes an der Stelle ein.
Das ist ein sehr hilfreicher Stack, der uns da sehr beflügelt.
Aber es gibt sicherlich auch andere Möglichkeiten der Containerisierung.
Wichtig ist letztendlich,
dass man alle Bestandteile des Services in diesem Kontext betrachtet.
Ich sage immer, als Softwareentwickler hat man nur seinen Code natürlich vor Augen,
den man geschrieben hat.
Aber Konfigurationen,
Daten, Infrastruktur beispielsweise,
sind weitere Bestandteile eines Services,
die auch ausgeliefert werden müssen,
gerade in der kontinuierlichen Auslieferung,
sodass beispielsweise Infrastructure as Code,
Configuration as Code
natürlich einen großen Anteil auch dieser Delivery-Kette haben.
Und vielleicht ist dadurch auch der Wunsch besonders groß
einer Unternehmensreorganisation,
wie man arbeitet,
wie arbeitet man denn eigentlich zusammen,
weil man einfach merkt,
dass diese Kette, diese Delivery-Kette nur eine gemeinsame sein kann
und nicht die eines Einzelnen,
sondern die einer Gruppe,
die letztendlich alle Bestandteile,
die für den Service notwendig sind,
in dieser Kette zur Verfügung stellt.
Weil du es auch gerade so gesagt hast,
Anforderungen, die Anforderungen müssen sich verändern,
also die Beschreibung der Anforderungen, die Formulierung,
in einer der ersten Folgen,
Folge 7, glaube ich, war das ungefähr,
hatte ich die T-Systems MMS zu Gast
und die haben beispielsweise einen Webshop,
den sie betreuen für ein großes deutsches Unternehmen,
den Namen haben sie mir immer noch nicht gesagt,
aber das ist keine Pille-Palle-Firma
und die haben eben gesagt,
die haben es geschafft, dass sie quasi,
wenn der Entwickler eincheckt,
das, was du eben auch sagtest,
also die Anforderungen, die haben wir draußen vor,
wenn der Entwickler eincheckt,
dann brauchen sie eigentlich nur noch,
eine Stunde, bis das dann wirklich in der Produktion ist
und Produktion heißt eben Webshop,
also nicht irgendwie, weiß ich nicht,
Controlling-Software, die einmal im Jahr was tut,
sondern wirklich ein Webshop,
der stark frequentiert ist,
eine Stunde an der Stelle
und das ist eben natürlich das,
was sie für sich als Marke haben
und dann kann man daran natürlich auch messen,
daran kann man ja messen,
also erstmal braucht man es überhaupt
und man kann messen, ob man sich verbessert,
weil man das eben vielleicht noch schneller schafft.
Und jetzt kommen wieder alle Bereiche zusammen,
von Lean, Agile und ITSM und DevOps,
ganz interessant,
diese Frage der Frequenz
ist ja auch bei Agilitäten ein zentrales Thema.
Man macht ja nicht umsonst,
ich sag mal zwei Wochen Sprints zum Beispiel,
sondern man macht das auch,
um den Wert, den man da erzeugt hat,
in diesen zwei Wochen,
auch liefern zu können.
Dazu braucht man natürlich auch entsprechend
die notwendigen technischen Voraussetzungen,
um das überhaupt umsetzen zu können.
Wenn ich einen ewig langen Testzyklus habe,
den ich manuell durchführe,
Integrations- oder ähnliches,
die mich einen hohen Aufwand kosten,
überhaupt es aufzusetzen,
dann hilft mir eigentlich die Agilität nur wieder beschränkt,
weil der Wert dann wieder in der Lieferung
wartet auf irgendwas anderes.
Ich muss doch in der Lage sein,
diesen Wert dann auch zu liefern,
wenn ich ihn erzeugt habe.
Und dann kommt noch was ganz Spannendes hinzu.
Ich stelle jetzt mal eine Behauptung auf,
die da heißt,
Agilität ohne Automation
im Speziellen im Segment Testing
ist gar nicht machbar.
Stell dir vor,
du hast einen Wert geliefert
nach einem zwei Wochen Sprint,
machst einen Sprint danach nach einem anderen
und der Endesprint nach meinem ursprünglichen Sprint
zerstört meinen ersten Sprint,
weil ich was gemacht habe,
was Einfluss hatte auf den Wert,
den ich ursprünglich schon mal geliefert habe.
Wie stellt man das denn fest?
Dieses typische Regressive,
diese regressiven Fragen
spielen doch gerade bei einer kleinteiligen Lieferung
eine immer stärkere Rolle.
Und die Möglichkeit,
etwas auch weiterhin testen zu können,
also auch das, was ich schon geliefert habe,
währenddessen Stabilität zu sichern durch weitere Tests,
kann ich doch manuell gar nicht durchführen.
Sondern dann brauche ich entsprechend
diese starke Automation,
die mir hilft,
meinen Wert,
den ich geliefert habe,
zu erhalten.
Richtig.
Und die Automation dann aber eben,
deswegen ja Continuous Delivery,
über die gesamte Kette hin.
Also eben nicht nur Teilschritte automatisieren,
sondern die gesamte Kette im Blick haben an der Stelle.
Das ist total richtig.
Deshalb hatte ich eingangs gesagt,
für mich fängt eigentlich die Delivery-Kette
nicht erst beim Einchecken an,
sondern bei der Frage,
wie kann ich eigentlich Anforderungen,
die ich habe,
so formulieren,
dass ich sie auch in meine Tests überführen kann
und so kontinuierlich sicherstellen kann,
dass das, was an Anforderungen auch da ist,
auch wirklich geliefert wurde.
Das ist genau der Hintergrund.
Denn am Ende des Tages,
wenn ich einen Kunden habe,
dass ich auch noch manuell angucken muss,
wie kontinuierlich kann ich dann liefern
und wie kleinteilig kann ich dann liefern?
Vermutlich gar nicht mehr.
Deshalb muss ich darauf achten.
Behaviour-Driven nennt sich das dann in der Regel.
Ich muss dafür sorgen,
dass auch Akzeptanz-Kriterien
beispielsweise auch in meine Automatisierung einfließen können.
Das ist gar nicht so einfach,
aber …
Ja, ich wollte gerade sagen,
dann sind wir bei der riesen Herausforderung,
dass dann der Anwender,
der dir die Anforderungen formuliert,
dass der nicht einfach sagen kann,
mach mal,
sondern er muss sich wirklich ganz genau überlegen,
was er genau haben will.
Und dann sind wir schon bei dem nächsten Schritt,
dass Dev und Ops nicht nur zusammen müssen,
sondern eigentlich muss ich ja den Kunden
das Thema Anforderungen da auch mit reinnehmen.
Absolut.
Auch die Agilität hat er schon mit im Bauch.
Agilität funktioniert nur dann gut,
wenn ich nach meiner Iteration,
die ich gemacht habe,
bei einem Zwei-Wochen-Rhythmus beispielsweise,
auch in der Lage bin,
jemanden zu fragen und ihn zu involvieren
und ihn zu fragen,
ist das, was ich gemacht habe,
das, was du möchtest?
Wenn ich das nicht erreichen kann,
dann kann man sich durchaus wieder fragen,
wie erfolgreich kann man mit agilen Methoden sein,
wenn man so einen Feedback-Zyklus
gar nicht erst etablieren kann.
Das ist für Dev Ops wichtig,
das ist für Agile aber im Speziellen wichtig.
Und das führt diese beiden Konzepte
entsprechend wieder ganz gut zusammen.
Ganz genau.
Ja.
Du hast jetzt eben so eine schöne Überleitung gemacht
zu einem Thema,
was mir noch wirklich auf den Nägeln brennt,
ist das Thema Verbesserung.
Hast du für dich oder habt ihr für euch,
was weiß ich nicht,
Kennzahlen entwickelt,
Maßnahmen entwickelt,
irgendwas entwickelt,
wo ihr schauen könnt,
ob ihr besser geworden seid,
also wo ihr sagen könnt,
Dev Ops hat uns geholfen
und wir sind besser geworden.
Noch nicht gut genug,
aber besser geworden.
KPIs sind tatsächlich in der Praxis
gar nicht so einfach.
Ich glaube,
dass das reine Lernen oder Lehrmaterial,
was man sich dazu anlesen kann,
ist relativ trivial und straightforward.
Und es gibt, glaube ich,
auch relativ klare Ideen dazu,
welche KPIs denn sinnvoll sind
in einem Dev Ops Umfeld.
Ein ganz simples Beispiel,
die Anzahl von Deployments,
die man durchführt,
könnte ein guter Indikator sein,
um zu messen,
mit welcher Frequenz man etwas liefert,
weil man glaubt,
dass eine höhere Frequenz
etwas Besseres ist
als eine niedrigere Frequenz.
Allerdings sind KPIs insofern,
schwierig,
weil sie erstmal ein komisches Gefühl
im Bauch der Mitarbeiter erzeugen.
Man wird gemessen,
man wird beurteilt an etwas,
das ist sehr bürokratisch
und sehr statisch.
Eine Zahl ist ein relativ kaltes Instrument
und man fühlt sich vielleicht
als Mitarbeiter gar nicht so sehr
von einer Zahl charakterisiert.
Ich glaube,
jeder kann sofort nachvollziehen,
dass das so ist.
Da versuchen wir extrem vorsichtig,
lieber zu sagen,
auch da von unten heraus
Motivation zu schaffen,
sich eine gewisse Guidance aufzuerlegen.
Ich glaube,
das ist vielleicht nochmal
ein ganz guter Begriff.
Wenn man etwas erreichen will,
da muss man natürlich den Weg kennen.
Man braucht aber auch immer
gewisse Leitplanken,
gewisse Guidance,
die einem ermöglicht zu sehen,
befinde ich mich immer noch auf dem Weg
oder mache ich etwas schlechter als vorher.
Und so würde ich KPIs eher wahrnehmen.
Wichtig vielleicht noch zu unterscheiden,
eine KPI ist nicht wie die andere.
Wir unterscheiden da zwischen
Leading-Indikatoren und Lagging-Indikatoren.
Geht im Wesentlichen darum,
wann man etwas misst.
Man kann etwas messen,
das für etwas anderes stehen kann.
Also beispielsweise,
die Frequenz der Deployments
habe ich ja eben schon genannt.
Das sind Indikatoren,
die dazu führen können,
dass etwas passiert.
Das ist ein Indikator in die Zukunft,
wenn man so möchte.
Man kann natürlich auch hinterher messen,
ob etwas eingetreten ist.
Die Lagging-Indikatoren,
die dann entsprechend
beispielsweise SLAs
zum Beispiel überprüfen und sagen,
ich habe ein SLA in einem Vertrag vereinbart
und ich prüfe jetzt,
ob ich das auch wirklich geschafft habe.
Das ist aber eine Betrachtung im Nachhinein.
Wenn ich eine Guidance haben will,
investiere ich eigentlich eher
in Leading-Indikatoren,
die mir ermöglichen zu sehen,
dass ich mich auf ein Ziel zubewege.
Also für mich sind diese beiden Indikatoren
mein Shift.
Ich mag diese englischen Wörter immer nicht,
aber die zeigen für mich auch
eine unterschiedliche Ausrichtung,
warum ich überhaupt etwas messe.
Denn wenn ich jetzt im Rückblick messe,
dann messe ich ja nicht,
um mich zu verbessern.
Also klar, ich könnte das nutzen,
aber der primäre Zweck ist dann häufig da,
ich sage mal, Rechtfertigung
oder Vertrag ist erfüllt.
Das hilft dem Kunden ja aber,
gut, es hilft ihm schon, wenn er weiß,
der Vertrag ist erfüllt worden, keine Frage.
Aber wenn ich eben
kontinuierliche Verbesserung erreichen will,
wenn ich mich verbessern möchte,
und das will ein Kunde ja garantiert auch,
dann muss ich mehr in andere Indikatoren schauen.
Und wie du sagtest,
das ist wahnsinnig schwierig,
einfach anders zu messen,
andere Dinge zu messen und daraus abzuleiten,
was können wir denn für die Zukunft
verbessern an der Stelle.
Also ich glaube, das ist das Thema
dieser beiden Arten der Indikatoren.
Ja, ich glaube, es wird,
also das ist mein Eindruck aus den Schulungen heraus,
ich glaube, der Punkt aus diesen beiden Indikatoren,
der wird noch nicht so gesehen in der Praxis.
Die meisten sind noch dabei,
eher Lagging zu messen,
also rückblickend,
wahrscheinlich auch aus der Historie heraus,
aus Verträgen und so weiter.
Und ich glaube, wenn man es schafft,
auch Leading Indicators zu etablieren,
dann guckt man mehr nach vorne
und dann kommt man auch mehr in so eine
kontinuierliche Entwicklung oder Verbesserung.
Und das ist auch gar nicht so schwer,
was die Tools wiederum angeht.
Wenn man beispielsweise in die statische Code-Analyse guckt,
dann
gibt es so klassische Dinge wie
beispielsweise Testabdeckung.
Also wie viele Zeilen
Code decke ich überhaupt mit meinen,
in diesem Fall Unit-Tests,
überhaupt ab.
Das sind für mich auch letztendlich Leading Indikatoren,
die indizieren sollen,
inwiefern denn meine Software
gewissen Qualitätsansprüchen
genügen könnte.
Und mir helfen
letztendlich das, was für mich wichtig ist,
nämlich meine automatisierten Tests
mit bestimmten
Grundlagen zu unterfüttern.
Sowas ist total einfach,
das versteht auch ein Entwickler sofort,
dass es hilfreich ist,
in solche Kennzahlen zu investieren.
Viel schwerer ist es beispielsweise,
schon von Deployment Frequenz
gesprochen,
oder
Meantime to Repair oder sowas,
um zu schauen.
Das sind eher sozusagen auch
an die Personen gekettete
Indikatoren,
die auch sehr schnell in Leistungsmessungen
übergehen,
wo man ganz klar, wie man sagen,
eine Formulierung finden muss,
die die Ängste dann nimmt
und
dieses Gefühl der Guidance
auf sich erhält und nicht des Messens
von einzelnen Menschen.
Das ist nämlich nie das Ziel,
dass ich einzelne Menschen messen möchte,
sondern
für mich ist immer das Ziel,
die notwendige Führung, die notwendige
Guidance zu geben,
die mir ermöglicht,
mein Ziel kontinuierlich zu
immer weiter kontinuierlich in Richtung
meines Ziels zu laufen, ganz genau.
Ja, und vor allen Dingen
das, was du eben gesagt hast, dass das Ziel
nicht ist, einzelne Menschen zu messen,
das könnte man jetzt quasi als
eine Marketing-Aussage hinstellen
oder eine Aussage, weil das
politisch korrekt ist, das so zu sagen,
aber ich glaube, dass du da
genauso verstanden hast, wie eben
immer mehr verstehen,
selbst wenn ich jetzt eine Person messen würde
und da irgendwas rausfinden würde,
die Frage ist ja, warum ist das
so? Liegt es an der Person?
Ich glaube eben immer seltener,
dass es so ist, sondern liegt es an der Umgebung?
Liegt es daran, dass sich derjenige vielleicht
in einem Team nicht wohlfühlt,
dass er in einem Team vielleicht auch nicht
unterstützt wird?
Also, wenn ich aus einer Kennzahl
bei einer Person etwas herausfinde
und ich habe ein Teamgedanken,
dann ist immer die Frage, warum ist das so?
Und diese Frage muss ich im Team
und mit dem Team klären an der Stelle.
Genau, ich glaube, das ist so der
Grund, warum man in Teams arbeitet,
warum man letztendlich, natürlich auch
eine Menge von Arbeit spielt natürlich auch eine Rolle,
gar keine Frage, aber beispielsweise
Cross-Funktionalität, das klappt ja meistens in
einer Person schon gar nicht,
das ist gar nicht abbildbar,
sondern letztendlich braucht man immer
mehr als einen Menschen,
aber eben auch, um sich
gegenseitig sozusagen unterstützen zu können.
Das ist natürlich ein weiteres
wichtiges Gut,
man ist nicht allein mit etwas,
sondern man hat Support von anderen.
Man muss natürlich immer eins sagen,
wenn man wieder ein Stück weit in die Agilität
schaut,
ich glaube,
es gibt so einen schönen englischen Begriff wieder, ich weiß gar nicht,
ob es einen vernünftigen deutschen
Begriff dazu gibt, der nennt sich Peer Pressure.
Hast du bestimmt auch schon mal
gehört, ne?
Du bist in dem, und auch gespürt
vermutlich,
ich glaube, der Einzelne
hat genügend Druckelemente
in den Konstrukten, die wir heute
um uns herum erzeugen,
im Speziellen auch Agilität,
die
ihn dazu bewegen, eine eigene
Motivation auszubilden,
sich zu verbessern, sich zu verändern,
anderen auch nachzueifern, zum Beispiel.
Diese Art von
sozialer Druck,
ist das eine adäquate
Übersetzung von Peer Pressure?
Weiß ich nicht.
Ich weiß es auch nicht so richtig,
aber es ist auch sicherlich ein Aspekt,
dass untereinander passiert,
dass sicherlich auch
in agilen Methoden genutzt wird,
um halt auch in diesen kontinuierlichen
Verbesserungsprozess zu kommen. Selbstmotiviert.
Ja, richtig.
Und was du eben sagtest, mit dem,
der soziale Druck oder beziehungsweise auch
der soziale Ausgleich an der Stelle,
ich komme immer mit einem Beispiel,
wo wir das wirklich mal hatten, dass bei einem Team,
die auch, die haben auch
Second, die haben ja auch Second und Third Level
gemacht und teilweise auch schon beim First Level
unterstützt. Da war die Frage,
warum diese eine Person, da hat jemand
wirklich mal gemessen und gezählt,
wie viele Tickets bearbeitet wurden.
Und diese eine Person,
die war immer unter
dem Durchschnitt, weit unter dem Durchschnitt.
Und das denkt man erstmal, okay,
der ist nicht so produktiv, der macht
zu wenig. Dann sind wir aber mal eingestiegen
in die einzelnen Tickets und
haben rausgefunden und haben also auch
die Planings und die Reviews
nicht überprüft, aber haben darauf geachtet.
Interessant war, dass
dieser Mensch
Dinge übernommen hat, die die anderen nicht machen
wollten. Also die meisten Entwickler haben sich
auf die einfachen oder schnellen Tickets
gestürzt und das, was dann sozusagen
übrig blieb, waren die schwierigeren,
die ungeliebten Tickets und die hat dann
dieser Kollege genommen an der Stelle. Das heißt also,
der hat eben weniger geschafft,
wenn man allein nur auf die Zahlen guckt, auf die Anzahl
der Tickets, aber er hat abgesehen davon, dass er
eine soziale Funktion übernommen hat,
er hat nämlich dann die Reste bearbeitet
und das hat ihm auch noch Spaß gemacht.
Er hat eben auch dafür gesorgt, dass ich bei den
letzten 20 Prozent oder
was soll noch mehr, dass ich da auch
als Team gut geleistet habe. Und als
das klar war, hat er auch
an Ansehen im Team gewonnen, weil die einfach
gemerkt haben, hey, der ist nicht
langsam oder der schafft nicht so viel,
sondern er kümmert sich um die Dinge, um die wir uns
nicht kümmern wollen
und wenn wir ihn nicht hätten, dann müssten wir uns
darum auch noch kümmern. Also das ist
immer so mein
Beispiel, wenn jemand kommt und
mit ganz einfachen Kennzahlen Menschen
vergleicht. Ja,
absolut und
was dabei auch nochmal nach vorne kommt,
ist für mich das Thema
Transparenz,
was auch ein schwieriges
Thema ist tatsächlich. Transparenz
insofern,
ich glaube, wenn man besser werden möchte,
dann muss man auch in der Lage
sein, offen und ehrlich
miteinander über alles zu sprechen
und das, was passiert, auch, ich sag mal,
transparent darzustellen. In deinem
beschriebenen Case konntest du das nur
machen, das, was du herausgefunden hast,
weil offensichtlich Transparenz
über bestimmte Dinge
hergestellt wurde.
Und mit dieser Transparenz kann man dann gut weiterarbeiten.
Wenn man die nicht herstellt,
Menschen sind gar nicht so gerne
transparent, ist
meine Erfahrung.
Dann kann man ganz oft auch wenig
in kontinuierliche Verbesserungen
investieren, gerade was die persönliche
Verbesserung oder Optimierung angeht,
weil man sich eher zurückzieht
und sagt, wenn ich
jemand anderem etwas sage, wie ich es mache,
der fängt an und korrigiert mich auch noch.
Das ist
ein ganz schwieriges
Unterfangen und sicherlich auch eine
der größeren Herausforderungen,
die man im Führen von Mitarbeitern sicherlich
gerade
in einem sehr menschenzentrierten
Bereich, wie
DevOps, Agile und Lean hat.
Richtig, ja.
So, jetzt gucke ich mal auf die Uhr
und wir haben
einen tollen Podcast aufgenommen,
wie ich finde. Ich bin etwas überrascht,
wie spät es schon ist, wie lange wir schon
aufgenommen haben. Ich finde es
auch interessant, dass
du dich oder wir uns von der Bohrmaschine
bei dir im Hintergrund nicht großartig
haben aus dem Konzept bringen
lassen. Gibt es noch irgendwelche
Themen, die du noch ansprechen möchtest? Sachen,
die wir noch nicht besprochen haben,
die dir noch wichtig sind?
Also, es gibt bestimmt noch
Dutzende von Dingen,
die man ansprechen könnte.
Vielleicht ein wichtiger Punkt für mich ist,
dass
auf diesem Weg hin
zu DevOps oder Agile
oder Autonomie, was auch immer
da jetzt im Vordergrund steht,
braucht man
Zeit für die Mitarbeiter.
Ich glaube,
auszurufen,
in den Wald hineinzurufen, ab morgen sind wir
autonom,
das funktioniert nicht.
Sondern man muss diesen
Weg gemeinsam beschreiten.
Wir sprachen ja anfangs auch von dem
Thema Verantwortung und
Verantwortungsübernahme.
Das ist nichts, was von alleine passiert.
Es gibt auch genügend Menschen,
die diese Art
von Verantwortung vielleicht gar nicht übernehmen
möchten, vielleicht auch gar nicht übernehmen können.
Ich glaube, man muss
den Prozess Zeit lassen.
Man muss viel Zeit und viel Energie
auch viel
Motivation in diesen Prozess
hineinfüllen
mit den Mitarbeitern,
um am Ende des Tages auch in der Lage
zu sein,
jeden Mitarbeiter
die gewünschte Verantwortung
auch tragen lassen zu können.
Und das ist ein Weg,
der beschritten werden muss,
der nicht einfach nur so da ist.
Das hätte ich noch gern gesagt.
Super, super.
Das ist ja eine Kernaussage
oder ein tolles Zitat.
Ich werde dich jetzt häufiger in meinen Schulungen zitieren.
Da sitzen ja auch manchmal Leute drin,
die sich diese Zeit noch nicht nehmen können
oder wollen, also dieses Verständnis,
was du eben gezeigt hast,
die das noch nicht haben.
Insofern kann ich jetzt immer wieder auf Oliver Simon
verweisen und sagen, ihr braucht Zeit.
Das braucht Zeit,
wenn ich die Vorteile heben will an der Stelle.
Und quasi heißt das umgekehrt,
wenn du keine Zeit investieren willst,
dann brauchst du dich eigentlich auch nicht um Agilität
und Lean und DevOps kümmern,
weil dann wird es nicht funktionieren.
So ist es.
Sehr schön. Oliver, dann danke ich dir
für diese knappe Stunde,
die wir hier verbracht haben.
Ich finde, da sind sehr, sehr viele schöne Aussagen mit drin,
sehr, sehr viele Berichte
aus deiner Erfahrung.
Also wie gesagt, herzlichen Dank an meiner Stelle
dafür, dass du dir diese Zeit genommen hast.
Ja, vielen Dank auch von meiner Seite.
Hat sehr viel Spaß gemacht.
Gerne jederzeit wieder.