Hier folgt die zweite Folge zu DevOps bei T-Systems MMS. Unsere Gäste sind weiterhin Michael Glathe und Holger Helas.
Die beiden berichten von ihrer täglichen Arbeit und helfen uns, DevOps Theorie und gelebte Praxis zu verbinden.
In Dieser Folge geht’s um’s Eingemachte: um die Menschen, mit denen man zusammenarbeitet.
Insbesondere um beliebte heiße Eisen wie die Rufbereitschaft und wie sie bei T-Systems MMS umgesetzt ist.
Außerdem sprechen wir viel über das Menschenbild und das Thema Vertrauen, die natürlich zentrale Punkte bei der Gestaltung der Zusammenarbeit sind.
Inhalt
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni
Hallo und herzlich willkommen zu einer weiteren Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingiarni, Dirk Söllner und Falko Werner.
Wir sind jetzt in der Fortsetzungsfolge, immer noch mit unseren Gästen Holger Helers und Michael Glate von der T-Systems MMS aus Dresden.
Die hatten so viele Themen mitgebracht und wir haben so nett geplaudert und so gut uns unterhalten,
dass wir über die Zeit gegangen sind und dann, dass wir es schon so ein bisschen erwartet haben, eine zweite Folge jetzt aufnehmen.
Also hier Folge 57, wo wir ein bisschen mehr versuchen wollen, auf das Thema DevOps in der Praxis einzugehen.
Und dann fange ich mal an mit der…
… der Liste, von der ich ja auch in der letzten Folge schon gesprochen habe.
Ihr habt uns ja eine lange Liste mit Punkten gesprochen, geschickt, über die ihr sprechen könntet.
Und ein bisschen habt ihr schon über den nächsten Punkt gesprochen in der letzten Folge.
Einarbeitung. Wie organisiere ich den Ramp-up? Also wie kriegt man Leute in ein DevOps-Team?
Vielleicht ist es ganz gut, wenn ich aus meiner Rolle Scrum Master beginne und Michael, du dann über deine eigene Einarbeitung erzählst, oder?
Na klar.
Also wir haben…
Vor anderthalb Jahren sind wir gestartet als komplett neues Team, was neben ein anderes Team gestellt wurde.
Und wir haben ein sehr gutes anderes, ein sehr kommunikatives anderes Team gefunden.
Und da war die Einarbeitung so, dass sie am Blog stattfand und die erste Woche wirklich dafür da war, uns aufzuladen, was es bedeutet,
Schweizer Transportunternehmen, was erreicht werden soll, was wir in unserem Bereich machen und sozusagen von der Flughöhe weit oben immer tiefer herabgegangen sind,
um dann wirklich in unserem Bereich anzukommen.
Aber ich als Scrum Master habe…
Ich habe jetzt noch weitere Teammitglieder, die ich reinbringen muss.
Und da stelle ich halt fest, dass das wirklich so wie eine Art Trainingslager ist, die ersten zwei, drei Monate, die unbedingt einen motivierten Mitarbeiter haben.
Und dann diesen Kopf aufmachen, das Wissen da reinstecken, wieder zumachen und hoffen, dass es bleibt.
Das ist echt schwierig.
Die Themen sind so aneinandergereiht, dass man einfach auch vergisst und Dinge mehrfach hören muss.
Und wie man das halt strukturiert, das ist gar nicht so einfach.
Und der Mitarbeiter durchläuft da auch so.
Also ein paar Phasen, wenn ich so die letzten drei von uns angucke, die haben immer Euphorie, weil die Umgebung positiv ist.
Die erlangen erste Inselerkenntnisse, die werden dann auch frustriert, weil es nie weitergeht oder die treten irgendwo drauf und das rutscht weg.
Die spüren dann auch so die Wärme des Teams, dass sie aufgefangen werden, dass jeder bereit ist, die Fragen zu beantworten.
Und irgendwann kommt es dann zu dieser wunderbaren Erleuchtung, wo diese Synapsen geschlossen werden, dieses Aha-Erlebnis kommt und ich bin ja doch nicht doof und das brauche aber.
Und das sind meines Erachtens…
Ein halbes Jahr vergangen.
Und so ist auch der Zeitraum, in dem wir planen.
Wir führen die ran, sorgen für Arbeitsfähigkeit, geben die Rechte, erklären den agilen Prozess.
Und dann geht es in ein Thema, meistens bei uns als Tandem, also zu zweit neben einem Erfahrenen, weil es bringt einfach nichts.
Es braucht diese helfende Hand am Anfang, alles alleine rauszufinden, macht einfach frustrierend.
Da braucht man jemanden, der sagt, guck mal, das ist der Zustand, mach das so, lese das so.
Und dann kommt es auf den Mitarbeiter drauf an, was er mitbringt.
Und wie merkt er sich Dinge, schreibt er sich schöne Cheats, die wachsen ins Unerlässliche.
Und er braucht aber die Motivation, wenn sonst ist dieses Trainingslager nie auszuhalten.
So, Michael, jetzt erzähl mal, hast du das so wahrgenommen im ersten halben Jahr?
Also erst mal vom Anfang angefangen ist ja ganz lustig, dass als das Team von Holger angekommen ist, das war ja das Team von Holger plus ich.
Ich hatte die Einarbeitung da mit euch zusammen.
Ich weiß gar nicht, ob ich noch Mitspracherecht beim Teamnamen hatte.
Aber ich glaube nicht.
Jedenfalls, als ich dann angekommen bin in diesem komplexen Umfeld, war es auch erst mal ein sehr, sehr fast schon überfordernde Menge an Informationen, die neu auf einem eingeprasselt sind.
Und ich bin auch der Meinung, dass dieses Einarbeiten im weitesten Sinne gar nicht so schnell aufhört.
Weil die Themen jetzt gerade, wenn ich jetzt über einem Jahr in dem Projekt mit dabei bin, neue Themen werden immer.
Auf Einkommen.
Dinge, von denen man nur am Rande vielleicht mal den Begriff gehört hat, aber jetzt noch nicht groß was mit zu tun hatte.
Also muss diese Bereitschaft auch über das Einarbeiten hinaus bleiben, sich mit neuen Dingen zu beschäftigen und da offen zu sein und da halt vielleicht auch sich die Fähigkeit anzutrainieren, schneller zu lernen.
Also mit der Zeit.
An sich, ich kann auch darüber sprechen, wir hatten jetzt auch zwei neue Kollegen, also drei eigentlich.
Wir einarbeiten mussten, was wir auch versucht haben, als Team abzufangen.
Und dementsprechend sind uns ganz viele Know-how-Träger weggebrochen.
Gerade in bestimmten komplexen Bereichen, wo wir dann gesagt haben, hier, bevor du weg bist, stell uns mal eine Agenda zusammen.
Was ist in deinem Kopf alles drin?
Und dann haben wir nochmal extra Know-how-Sessions gemacht.
Also quasi eine Stunde oder auch ein bisschen kürzer, wo wir das Ganze als Video aufgenommen haben.
Und das dann.
Für perspektivisch neue Kollegen oder Dritte abgelegt haben, wo man sich das immer wieder, ich möchte mal sagen, antun kann.
Natürlich ist das Initial so viel, das kann keiner nach einmal hören, begreifen oder erleben.
Aber letztendlich ist es dafür wichtig, dass, wenn dann der neue Kollege mal in dem Bereich zu tun hat, kann er sich das ja dann mal ein bisschen detaillierter anschauen.
Ich muss da lachen.
Ich habe heute mit dem Kollegen nochmal vorab geredet und gefragt.
Und er hat halt so einen schönen Satz gesagt.
Ja, das Video, das reicht ja nicht.
Es gibt einfach so Pummelthemen, wo man rausfinden muss.
Und wenn man da zwei Stunden sucht und so und niemanden hat, der ihm hilft, dann ist man einfach aufgeschmissen.
Dann kann er den Tag wegschmeißen.
Aber ich habe Respekt vor jedem, der den Schritt, den du auch gegangen bist, sozusagen getätigt hat.
Und dieses Trainingslager, Knochenmühle, so viel Wissen wie möglich reinschaufeln.
Und vor allen Dingen, meine Sachen, es ist viel wichtiger, das Wissen zu behalten.
Und du weißt noch, als wir angefangen haben, haben wir jeden Tag die Schleife gemacht.
Wir haben das irgendwie fortgeführt.
Es gibt ja alle möglichen Toolings dafür, Miro und wir arbeiten mit Microsoft Teams.
Da bleibt jeder Chatraum persistent mit allem da.
Und das ist da gut unterstützt.
Aber es braucht halt das.
Ganz kurz.
Ich wollte definitiv jetzt nicht damit sagen, dass so ein Video reicht.
Um Gottes Willen.
Also allein dieses Theoretische, das ist dann erstmal vielleicht der Einstieg.
Aber dann hat es mir auch erst geholfen oder hat ein nachhaltiges Wissen aufgebaut.
Wenn so dieses, der Begriff Make Your Hands Dirty, also quasi wirklich mal den Code angefasst,
eine Kleinigkeit gemacht, an einer Kleinigkeit frustriert und die dann irgendwann gelöst.
Und das dann immer Stück für Stück.
Findet das richtige Level der Frustration, was noch ausgehalten werden kann pro Tag.
In Hosen sozusagen, ja.
Ja, wie läuft das denn eigentlich bei euch?
Wenn ich jetzt anfange bei euch nagelneu als irgendwie Entwickler, sagen wir mal,
ab wann darf ich mir denn da die Finger dreckig machen?
Das ist, also wie gesagt, bei dem großen Big Bang, Team neben Team gestellt,
gab es diesen richtig klassischen Einarbeitungsplan.
Da wurde geguckt, welches Wissen benötigt wird.
Da wurden Termine dafür gemacht.
Da war die erste Woche nur Vorstellung, was die SBB ist, was ein Transportunternehmen ist,
wie wichtig in Schweizer die Versorgung ist, das auf Bargeldwert legen.
Was unsere Aufgabe ist, dass die Kasse stimmt.
Das wurde wirklich eingebrannt.
Das war auch notwendig, um diesen Anwendungsfall zu verstehen.
Und dann ging es weiter.
Und dann ging es weiter.
Und dann ging es weiter.
Und dann ging es weiter.
Und dann ging es zum Team.
Dann wurden die Tools erklärt.
Und dann wurden in den einzelnen Bereichen Applikationen von Architekten wie Vorträge gemacht.
Und dann war man eigentlich platt nach den drei Wochen.
Und dann durfte man aber recht schnell ins Team kommen.
Und da, wie wir es jetzt inzwischen machen, machen wir es eigentlich so,
wir haben so einen Plan, dass nach einem halben Jahr ungefähr er wissen muss,
wo er hingreifen muss und auch vielleicht sogar die Rufbereitschaft schon durchgeführt hat.
Und nach einem Jahr muss er produktiv sein.
Und das ist so der Zyklus.
Und das wird…
Und das wird bei uns aktuell so erreicht, dass wir wirklich ganz viel über Tandems arbeiten.
Dass die Kollegen mit einem Erfahrenen zusammen Dinge lösen, aber nie zugucken und lösen lassen,
sondern sich selber eigentlich so ab dritte, vierte, fünfte Woche,
nee, eigentlich schon ab den ersten Tagen auch die Hände schmutzig machen.
Genau.
Weil anders lernen sie es ja nicht.
Genau.
Und es ist im Sinne, man ist ja dann auch nicht allein oder wird nicht allein gelassen, um Gottes Willen.
Also, wenn man jetzt sagt,
man kommt an, hat hier ein kleines Problem, ja, und man traut sich das zu, da mal ranzugehen,
dann ist es ja auch immer, bevor das Ganze produktiv geht, wird ja noch so viele,
geht das ja noch über so viele Stages bis hin zu, es muss ja noch auch jemand über den Commit,
also den Pull Request gucken und den dann genehmigen.
Also, sage ich jetzt mal, ein neuer Kollege am zweiten Tag schreibt ja schon mal was,
sind wir mal optimistisch.
So, und dann muss es aber auch immer einen Kollegen geben, der sagt,
okay, ja, das ist gut so, das ist richtig so, das genehmige ich jetzt mal.
Ja, also, das ist nicht so, dass ein neuer jetzt dann kommen kann, sich überschätzt, da was macht
und dann alleine auf einmal unsere ganzen Schienen im Larm legt.
So, das kann eigentlich in der Regel nicht passieren.
Es kann sich, wie gesagt, auch rausstellen, dass die Verantwortung oder die Aufgabenbreite einfach zu breit ist,
dass der Mensch, der da anfängt, das auch nicht schafft.
Das kann durchaus sein.
Wir reden ja über DevOps und die Erweiterung der Wissensfelder und mehr Verantwortung.
Das kann auch zu viel sein.
Aber was wir zum Beispiel auch gut rausbekommen haben, ist, um jetzt neue Kollegen an,
sagen wir mal, Sachen, Sachte an den Code heranzuführen, sind solche Dinge,
die keiner tut, wenn man in diesen Stories und Featuren Kreislauf drin hängt,
nämlich einfach mal Codesmells aufzuräumen, Optimierungen am Code zu machen.
Da gibt es ja jetzt hier neuerdings bei uns auch so ein Analyse-Tool,
was uns da sagt, ja hier vom Code,
da müsste man mal aufräumen, da sollte man mal was machen.
Und dann ist es auch die Eigenverantwortung des neuen Kollegen,
dass er jetzt nicht einfach nur die Pendancies da rauslöscht,
sondern dass er sich dann halt auch vielleicht in dem Modul,
in dem er unterwegs ist, sich das Ganze mal ein bisschen anguckt.
Ja, was macht denn das überhaupt? Wofür ist das da?
Und dann, dass sich vielleicht mal durch den Kopf gehen lässt im Zuge dessen.
Aber man hat dann schon ein paar Aufräumarbeiten, die man dann ja durchaus mitgeben kann.
Ja.
Michael, ich musste gerade lachen. Wir haben ja wirklich zusammen angefangen.
Weißt du noch, wie wir zusammen unsere Entwicklungsumgebung aufgesetzt haben mit sieben Kollegen?
Ja, ja, ja.
Wir haben das als Mob gemacht.
Also alle zusammen in einer Session, alle eine halbe Stunde hat der Driver-Seed gewechselt.
Einer war im Dokumentations-Seed und dann haben wir bei der SBB die Dokumentation,
wie die Entwicklungsumgebung eingerichtet wird,
was ja in einem Confluence ein ganz normales Dokument drunter ist,
macht dies nach, dies nach dem.
Hat der Doku-Seed sitzen, sind dann halt verfeinert mit Bildern,
wie es wirklich funktioniert und, aber wir haben es halt durchgezogen.
Und das war auch eine gute Art des Lernens, weil du warst immer dabei.
Am Ende hatte jeder die gleiche Entwicklungsumgebung.
Jeder wusste ungefähr, was für Entwicklungspräferenzen, Stile sind.
Und das hat zum Beispiel als Maßnahme sehr gut geholfen am Anfang.
Mob-Programming.
War durchaus sehr intensiv, aber zielführend.
Ja, wenn ich das so höre, Holger, du hast es eben sehr schön gesagt.
Ja.
Und erweiterte Verantwortung oder eine relativ hohe Verantwortung.
Und zwar sozusagen nicht nur in die Tiefe, sondern auch in die Breite.
Also wir reden ja bei DevOps von End-to-End.
Und das habt ihr vorhin in der ersten Folge von dieser Doppelstaffel jetzt hier
ja auch schon mal angesprochen.
Ihr habt ja wirklich eine End-to-End-Verantwortung.
Ja, die ist da.
Also vom, wie gesagt, Refinement bis zur Skizze, wie der Code aussehen soll,
bis zum Commit, bis zum Monitoren, bis zum Loggen, bis zum Backloggen,
bis zum Backfixen, wird die Strecke von dem Entwickler begleitet.
Es gibt maximalen Übergang zu anderen Entwicklern,
wenn halt ein neues Planning ansteht und ein anderer da weiterarbeitet.
Aber die gibt es.
Und das Wissen ist unglaublich breit.
Und das ist auch sowas, wo ich immer mit mir kämpfe.
Kann ein Mensch das alles auffassen?
Ist das zielführend, wenn er auch wirklich den Anspruch an sich hat,
alles zu wissen?
Geht das vielleicht gar nicht?
Und da habe ich noch keine richtige Antwort dafür.
Ja, ich denke, es ist auch personenabhängig.
Denn ich hätte jetzt wiederum gesagt, die Frage ist ja auch, will jemand das?
Also da habt ihr sicherlich auch, oder habt ihr vielleicht auch andere Erfahrungen,
aber die Entwickler, die ich kenne, das ist schon ein paar Jährchen her,
wo ich intensiver mit denen zusammengearbeitet habe,
die hatten letzten Endes, sage ich mal ganz platt, keinen Bock zum Testen.
Und Produktion schon mal gar nicht.
Die haben tolle Dinge gebaut, die haben wunderschöne Applikationen gebaut
und dann hat es auch aufgehört.
Und das ist ja die Frage.
Was da so eure Erfahrungen sind, ob das, was ihr erwartet,
nämlich den Wunsch, mehr Verantwortung zu übernehmen,
mehr Aufgabenfelder zu übernehmen, wie das sozusagen ankommt
bei euch und bei euren Entwicklern sozusagen.
Da können wir ja wieder Bande spielen, Michael.
Wir nehmen mal das Thema Rufbereitschaft, oder?
Weil das ist ja so ein Wissensthema, was ganz weit in der DevOps-Welt ist
und wo viele Entwickler sich weigern, das zu tun.
Und bei uns gehört es dazu.
Wir denken auch, dass das nachhaltig ist.
Dass das ein Erfolgsfaktor ist.
Weil wenn ich wirklich mal nachts rausgerufen werde
und feststelle, dass der Code, den ich da geschrieben habe, nicht funktioniert,
dann spüre ich die Verantwortung im wahrsten Sinne des Wirkes,
dass ich vielleicht mal kurz orientierungslos bin
oder danach auch nicht mehr schlafen kann.
Das will man nicht.
Deswegen sind die Rufbereitschaften auch getaktet,
dass sie nicht zu nah hintereinander sind.
Aber wie führt man einen Entwickler ran, dass er Rufbereitschaft macht?
Wie war es bei dir, Michael?
Da möchte ich vielleicht noch mal ganz kurz daran ansetzen,
an der grundlegenden Frage von Dirk,
ob man darauf Lust hat.
Also ich kann da nicht für jeden Entwickler sprechen wahrscheinlich,
aber ich persönlich, ich habe Bock darauf,
jetzt nicht einfach nur ein Feature oder eine Story zu schreiben
und die dann abzugeben und mich dann nicht mehr dafür zu interessieren,
ja, was passiert denn mit der überhaupt?
Was für ein Traffic läuft darüber? Wie funktioniert das?
Geht das überhaupt in der Praxis so eine Art?
Das würde ich schon, da habe ich schon Bock drauf,
das weiter zu verfolgen.
Und dementsprechend jetzt mal ganz weggeschoben
mit der Verantwortung ist es einfach so dieses,
ich möchte damit auch was damit zu tun haben,
von dem, was ich geschaffen habe letztendlich.
Das ist dein Code, den hast du gemacht.
Und dann mit der Rufbereitschaft, das ist dann,
okay, da spürt man dann die Verantwortung.
Das ist richtig, auf jeden Fall.
Nur kann ich dir auch da ganz ehrlich sagen,
hatte ich auch Bock drauf, nicht um darauf zu warten,
dass beim Kunden irgendwas kaputt geht, um Gottes Willen.
Nein, aber es ist gar nicht so schlimm,
Rufbereitschaft zu haben, denn wenn wirklich was kaputt geht,
wenn wirklich da, ich will jetzt nicht ein Wort benutzen,
was jetzt hier vielleicht, wenn wirklich was kaputt geht,
ist man nicht alleine, auf jeden Fall.
Dann sind auch noch andere involviert.
Wie wurden wir da rangeführt?
Es ging ganz einfach los, erstmal natürlich mit den Monitoring-Systemen,
sich vertraut zu machen und zu gucken,
was haben wir überhaupt für Anwendungen,
was läuft da für Traffic drüber,
was kann ich daraus an Informationen gewinnen?
Dann ist das nächste, Schulungen organisiert
und dann kommen wir dann auch wieder zu den Rufbereitschaften.
Das ist ein ganz wichtiger Punkt,
weil wir haben ja in der SBB eben zu sagen,
hier, du hast jetzt mal simuliert einen ganzen Tag Rufbereitschaft.
Wir machen auf den Integrationsumgebungen irgendwas kaputt
und du sollst das dann einfach mal lösen
und eben diesen ganzen Kreislauf mitmachen
mit eben der Kommunikation untereinander.
Und dann gibt’s wiederum auch ein Partner-Team,
ähnlich bei Holger, das nennen wir Cluster.
Wir haben auch ein Cluster-Partner-Team,
was sehr, sehr erfahren ist schon.
Das ist jetzt auch ein Thema,
das wir auch im zweiten Jahr,
in der ersten Session wiederum,
also wo sie uns diesen Timo War Room,
also einen Kriegsraum gezeigt haben,
in dem wir dann im Zweifel auch einfach Informationen finden,
wo auch ganz viel stand,
ja hier, so und so ist manches zu lesen.
Das ist schon mal ganz oft vorgekommen.
Und damit konnte man vielleicht auch schon 90 Prozent
der zu erwartenden kleinen Fehler,
wo man dann alleine bleibt, mit lösen.
Ja, und wenn dann die anderen zehn Prozent,
dann kann man sicher sein,
dass man nicht alleine wach ist in der Nacht.
Die Idee dahinter ist ja,
dass die SBB so eine Art Zero-Impact-Strategie fährt,
dass man Fehler frühzeitig bekommen will
und dass man da so eine Staffelung hat aus Fehlern,
wo man sofort aktiv werden muss und wo gemailt wird.
Und deswegen gibt’s die Rufbereitschaft jedes Team.
Bei uns sind insgesamt elf Teams.
Fast jedes Team stellt immer einen,
der von 17 bis 7 Uhr in Rufbereitschaft ist.
Der kriegt ein Telefon, auf den kommen Sprachnachrichten.
Und wenn man dann so eine Rufbereitschaft hat,
wenn dann seine Applikation dran ist,
dann muss er da eine Problembehebung,
Erstentstörung machen.
Aber es ist das Netz wieder angesprochen worden.
Es ist immer noch so ein Häuptling da,
der drüber sitzt und mit aufpasst.
Und wir haben die Schulung angesprochen,
wo wirklich fast produktionsnah was runtergerissen wird.
Und danach kommen meistens alle
und wollen noch mal ein bisschen Monitoring auffrischen,
wie sie was lesen können.
Und dann, wenn es in die erste Rufbereitschaft gibt,
ist meistens auch noch ein anderer, erfahrener,
Genau.
Mitarbeiter mit im Call, den man anrufen kann.
Und dann sind wir wieder dabei.
Also das war die Strecke halbes Jahr.
Da soll er seine Rufbereitschaft gemacht haben.
Da soll er das Gefühl gehabt haben,
die Verantwortung mitnehmen.
Und in der Zeitraum soll es auch stattfinden.
Und bisher haben sich dem allen gestellt.
Mir persönlich wäre das schwergefallen.
Also ich so Feierabend, Nacht,
ich stelle mir das heilig vor,
aber ich entwickle niemals Software.
Von daher wirklich Respekt für alle, die das machen.
Und letztendlich, weil du am Anfang auch mal gesagt hattest,
wenn dann den Code, den man geschrieben hat, da kaputt geht,
im Zweifel, bevor etwas produktiv ist,
was ich anfangs oder in der letzten Folge gesagt hatte,
es durchläuft so viele Stages,
bevor wirklich etwas produktiv ist,
da wird so oft auffallen und noch Bugs kommen,
bis da wirklich man selber nur für diese eine Codezeile verantwortlich war,
die dann etwas kaputt gemacht hat.
Da muss schon sehr viel passieren.
Und dann ist man auch lange nicht mehr alleine schuld.
Und dann gibt es immer auch die goldene Regel bei der Rufbereitschaft,
niemals in den Code gehen und um Gottes Willen nicht auf
Produktion in der Nacht noch irgendeinen Bugfix zu machen.
Das kann ja noch Schlimmeres hervorrufen,
sondern dann wird einfach das Ganze zurückgefahren auf eine Version,
die man funktioniert hat letztendlich oder von der man hofft,
dass sie funktioniert.
Und dann gibt es am nächsten Tag einfach ein sogenanntes Postmortem,
wo dann das besprochen wird, was da passiert ist,
wo das dann halt auch mit Kollegen ganz entspannt analysiert wird,
geguckt wird, wie problematisch ist das?
Und dann wird das auch gemeinsam gelöst.
Wobei ich da jetzt auch dazu sagen muss,
es klingt so, ihr sagt, Rufbereitschaft ist gar nicht so schlimm.
Ich glaube, das liegt ganz wesentlich daran, dass ihr sehr,
sehr viel Energie und sehr viel Hirnschmalz da reingesteckt habt,
dass es auch tatsächlich nicht schlimm ist.
Ja, wenn ihr mal anruft, die Hütte brennt, dann ist das was anderes.
Ja, und schau, ihr habt ein hinreichend stabiles Grundsystem.
Ihr habt Mechanismen, ihr habt Rückfall-Ebenen, ihr habt…
Ja.
… Anweisungen und so weiter.
Wenn man all das nicht hat, allein wenn ich, wenn alle besten Willens sind,
aber leider habe ich sehr viele technische Schulden oder sowas,
und jede zweite Nacht kracht, ja, dann fände ich es auch ätzend.
Aber mei, wenn es dann halt einmal im Monat ein bisschen knirscht, meine Güte,
dann kann ich das Telefon mal mitnehmen, wird ja eh nicht bringen.
Genau. Ich muss noch was dazu sagen.
Wir sind ja für ein Projekt, für einen Auftraggeber 100 Prozent verantwortlich.
Wir fahren jetzt nie das Thema, dass man drei Projekte gleichzeitig hat
und Rufbereitschaft für mehrere Kunden nachzahlt.
Das führt auch zu Zufriedenheit.
Auch so ein Ding, genau.
Genau. Also, ich glaube, ihr stellt da so ein bisschen euer Licht unter den Scheffel,
weil ich glaube, nach dem, was ich so gehört habe, habe ich mir gedacht,
meine Güte, die haben sich aber schon echt Mühe gegeben,
dass man das auch tatsächlich jedem zumuten kann, Rufbereitschaft anzunehmen.
Ich sage es halt immer so, wenn diese Welt, in der wir arbeiten und Lösungen suchen,
so komplex ist, dann muss die Organisation dafür mindestens,
genauso sein. Und wenn ihr jetzt hört, was es alles für Rollenschulungen gibt,
dann ist die Ausbaustufe sehr hoch. Und das ist ja jetzt nicht nur unser Verdienst,
sondern das ist eine gewachsene Organisationsform mit vor allen Dingen viel,
wahrscheinlich auch Rückenwind, diese Veränderung, dass jeder, die mitmacht,
auch vom Management oder vom Mitarbeiter. Und das ist ja das Feld, in das wir reingekommen sind.
Was wir einbringen, ist, dass wir schnell lernen, dass wir Fragen stellen,
dass wir neugierig sind und dass wir überall mitmachen. Und indem wir das machen
und auch wahrgenommen werden und auf Augenhöhe das ist, ist es halt diese motivierende Umgebung,
die dafür sorgt, dass aus jedem das Beste rauskommt und dass Michael in einem halben Jahr
sich einarbeitet, seine Rufbereitschaft gemacht hat und das halt eingeht.
Genau. Und ich denke aber, und ich bin eigentlich auch felsenfest davon überzeugt,
dass so etwas auch nur in so einem agilen Umfeld entstehen kann.
Also, dass man dann eben, wenn wir dieses Inspect and Adapt nochmal aufgreifen,
was wir in der letzten Folge hatten,
dann eben mal Missstände, das ist jetzt ein großes Wort, aber wenn man dann eben so Dinge,
die nicht funktioniert haben, anspricht und dann ernsthaft darüber nachdenkt,
ja, wie kann man es dann besser machen, dann ist ja klar, dann entstehen auch solche Umgebungen,
wo man sich dann eben nochmal so einen War Room anlegt, wo man dann nochmal so eine Schulung
vom CPR-Team gestellt bekommt für neue Entwickler, alles drumherum.
Ich kann mir nicht vorstellen, dass da einer saß und gesagt hat, ja, hier, damit das gut funktioniert,
brauchen wir von Tag eins dies, das, jenes.
Sondern es wird viel mal vor die Wand gefahren sein.
Aber man hat in dem Umfeld oder Projekt von der SBB halt eben daraus gelernt
und hat dadurch entsprechende Veränderungen vorgenommen, die es dann eben für neue Kollegen einfacherer macht,
so etwas leichter anzunehmen und als gar nicht so schlimm zu empfinden.
Ja, richtig.
Ich möchte gerne auch nochmal auf etwas anderes eingehen,
weil ich finde, ein ganz wesentlicher Aspekt davon, Fehler zu beheben, ist überhaupt erstmal wahrzunehmen,
dass ein Problem besteht.
Mit anderen Worten, eine ausreichende Infrastruktur zu haben in Richtung Monitoring und Logging und sowas.
Dazu hattet ihr ja auch eine Notiz in eurer Themenliste.
Das ist so ein bisschen dieser Zero Impact.
Also das ist alles vorgegeben und gefunden, aber ich finde ihn stark,
weil bei 250.000 Finanztransaktionen am Tag ist ja die Frage, wo stellt man sein Messinstrument ein,
ab wann man benachrichtigt werden will und wie sensibel ist es auch über die Zeit.
Und wir haben…
Wir haben da wirklich Kollegen, die da fast alles auf null Fehler runterbringen wollen,
wo ich schon immer sage, das ist ja so viel Aufwand, der ist ja gar nicht wirtschaftlich.
Aber den Ansatz haben sie halt.
Die wollen nicht, dass der Kollege, nee, der Kollege, der Kunde am Bahnsteig steht und sein Ticket nie buchen kann
oder sein SAV, sein Service Apprevent, sein Rückgeld, wenn er die Reise nie angetreten hat, halt auch pünktlich bekommt.
Und das steckt in denen drin.
Da gibt’s…
Ich bin da immer erstaunt, egal auf welcher Ebene, wie tief man vergraben ist.
Ist es da sozusagen, glänzt hervor, diesen Kunden in den Fokus zu stellen?
Ja, auf jeden Fall.
Auch wenn man mal den Umgang dann halt auch mit entsprechenden…
Also die Folge aus diesen Fehlern sind ja dann auch, gerade auf Produktion sind ja auch Bugs,
beziehungsweise Blocker-Bugs bei uns genannt.
Und wenn man jetzt in der Bugs-Bock-Rolle ist beispielsweise und so einen Blocker-Bug gerade aus der Produktion aufschlägt,
ja, dann hat man auch, dann hat man alles stehen und fallen zu lassen und sich erstmal um den zu kümmern.
Genau.
Und das hoffentlich in möglichst kurzer Zeit.
Du hast die Bugs-Bock-Rolle angesprochen.
Also wir sind DevOps-Entwickler, alle müssen und dürfen alles können.
Aber wir sind noch nie so weit in der Evolution, dass jeder alle Bugs quer fällt, löst, weil da die Abstimmung einfach groß ist.
Sondern es gibt eine Rolle, die schützt das Team und die löst nur Bugs.
Und es gibt eine Rolle, das ist der DevOps, der macht nur Produktionssachen, entstören und aktualisieren.
Und die zwei Rollen schützen das Team.
Und in den Rollen lernt man aber sehr viel.
Und das ist aber auch ein Knochenjob, weil man da wirklich in den Sprint drei Wochen drin sitzt und täglich nur Bugs nach Prio löst.
Da lernt man unglaublich viel, auch weil wir vorhin gesagt haben, wie bringt man neue Mitarbeiter ins Rollen.
Es ist die Pflicht bei uns, dass die beide Rollen mit einem Erfahrenen machen, weil man da einfach so viel lernt,
weil man so viele neue Problemfälle sieht und die end-to-end durchgespielt kriegt,
bis sie dann wirklich auf Produktion mit einem Bug-Fix wieder gelöst sind.
Da muss man wirklich dafür sorgen.
Ich würde sagen, dass das Wissen auch alles hängen bleibt.
Das ist ja das Schwierige.
Ich will nochmal auf einen anderen Punkt eingehen.
Wir hatten ja vorhin den Punkt Entwickler und Hofbereitschaft.
Da haben wir ja herausgearbeitet, wie ihr das seht.
Und Michael hat ja auch gesagt, dass für ihn das okay ist.
Es wird Entwickler geben, die das nicht so okay finden.
Das ist auch nochmal eine persönliche Entscheidung.
Es gibt noch einen anderen Punkt, den ich in den DevOps-Trainings regelmäßig höre
und wo ich immer nur wieder sage, das geht.
Aber vielleicht habt ihr nochmal so eine wirklich gute Antwort und eine gute Erklärung.
Nämlich die Frage, wie kann es sein, dass ich die Entwickler in meine Produktionsumgebung lasse?
Naja, jetzt mal aus der Praxis gesprochen.
Wie oft war ich jetzt auf der Produktionsumgebung wirklich aktiv?
Das kann ich an einer Hand abzählen, jetzt über das Jahr hinweg gesehen.
Und das ist die Vorbereitung auf meine Hofbereitschaft gewesen.
Also im Sinne mal zu testen, komme ich im Zweifel auf die Produktionsumgebung
und kann da etwas nachstellen, wenn etwas schief läuft.
Ansonsten, als Entwickler arbeitest du ja auf Testsystemen,
also auf Snatchot-Umgebung bei uns, die dann irgendwann zur Integration wird.
Da laufen dann noch Abnahmetests, Finanztests drumherum,
bis dann irgendwann diese Freigabe gegeben wird.
Ja, es darf Produktion.
Und dann aktiviert man das ja auch nur in Anführungsstrichen.
Also das glaube ich dir, Michael.
Jetzt kommt das Aber.
Es soll Sicherheitsauditoren geben, die überprüfen, ob du dahin darfst,
weil du da eigentlich nicht hinkommen dürftest.
Bin ich da vollkommen aus der Welt oder wie seht ihr das?
Also das eine ist natürlich klar, DevOps.
Ihr sagt ganz klar, das macht Sinn.
Und das können wir auch alle nachvollziehen.
Aber es gibt eben Menschen, die gucken auf andere Dinge.
Die gucken auf Governance und Security und so weiter.
Und wie gesagt, da kriege ich regelmäßig die Fragen.
Es kann ja nicht sein, dass wir die Entwickler auf die Produktionsumgebung lassen.
Die können ja Kundendaten angucken und so weiter.
Ja, okay, ich verstehe.
Aber Sicherheitsvorfälle waren ja Log4J und Sonstiges im letzten Jahr alle betroffen.
Und die haben auch eine Sicherheitsabteilung, die Leitfäden rausgibt, wie man handeln soll.
Aber was ist denn jetzt wirklich das Risikobehaftetere, wenn jeder Zugriff hat und sich dem Zugriff bewusst ist
und solche Dinge an die Leute auch gestreut werden, dass sie bitte auch auf Informationssicherheitssachen aufpassen müssen,
ist das doch eigentlich was Besseres, wenn es nur der eine oder andere ist.
Also ich versuche die Frage gerade zu greifen und darauf zu antworten, aber mir fällt es schwer.
Okay.
Weil das ist ja dieses Denken, sollte jeder, könnte jeder, warum nicht?
Ja.
Also was ist die Antwort?
Wie stellt ihr sicher, dass Michael sich nicht, Michael, du verzeihst mir das,
sich nicht die Kreditkartenzahlen holt oder die Handynummern oder, oder, oder.
Also all das, was wir ja verhindern wollen.
Ja.
Über geschulte Mitarbeiter.
Ja, was heißt geschulte Mitarbeiter?
Ich glaube, der Dirk möchte auch darauf hinaus, dass, keine Ahnung, wenn ich mal irgendwie einen Frust auf unseren Kunden habe,
und dann da mutwillig böse Aktionen mache, weil ich die Möglichkeit habe, auf diese Umgebung zu gehen.
Aber dann ist für mich die Frage, okay, wenn man seinem Mitarbeiter oder seinem Entwickler von vornherein schon misstraut,
dann warum sollte man ihm vertrauen, dass er pünktlich bestimmte Feature liefert?
Ich denke auch, das geht in die Richtung positives Menschenbild, von dem wir reden und von dem wir ausgehen.
Die Chance besteht, aber die wird halt nie in den Fokus gerückt.
Ich kann mich noch erinnern, vor zehn Jahren, als ich angefangen habe, zwölf Jahren,
da habe ich bei Auslieferungen, bin ich mal drei Etagen hochgegangen von den Entwicklern zu denen, die es in Produktionen dann betreut haben
und habe mich da, damals hieß es noch, Qualitätsmanager hingesetzt und gesagt, die unten haben das gesagt, die oben haben das gesagt
und dann passierte das ein paar Mal und ich habe dann ganz paar Höhenmeter gemacht.
Das ist ja das alte System und da war vielleicht auch sicher, dass nur der darauf kann oder der Teilnehmerkreis,
aber deswegen war es ja nicht produktiv, das hat ja alles viel länger gedauert.
Wir haben ja Dinge designt, die ersten Jahre später dann irgendwie mit CD verschickt und aufgespielt wurden.
Das ist ja heute, Nehmer, heute wird alle drei Wochen geliefert und da hat halt jeder Zugriff.
Und man muss auch dazu sagen, finde ich, wenn jemand tatsächlich böswillig irgendwo ran will an das System,
dann schafft das eh, also gerade von den Internen, an irgendeinem Punkt, da stimme ich euch zu, Holger und Michael,
muss man halt auch seinen Kollegen irgendwie vertrauen, das hilft ja alles nichts.
Ich muss ja auch, also ganz stumpf gesagt, ich muss auch dem Busfahrer vertrauen,
dass er neben der Bushaltestelle anhält und mich nicht einfach unterfliegt.
Genau.
Das gehört einfach mit dazu, ich kann es auch nicht unterbinden.
Na gut, da kommen wir auf den Punkt Menschenbild.
Also ich stimme euch ja zu, aber habe jetzt vielleicht so ein, zwei Argumente mehr nochmal bekommen.
Es geht einfach auch um das Menschenbild und um die praktischen Anforderungen.
Das heißt also, ich kann diese Sicherheitsstufen, die so jemand dann gerne hätte,
die kann ich heute zeitlich gar nicht mehr umsetzen.
Also dann bin ich irgendwann raus aus der Nummer, weil ich eben nicht schnell genug liefere.
Okay, Haken.
Ich muss jetzt aber auch.
Ich muss vielleicht das nochmal relativieren an der ganzen Geschichte und damit zugeben,
man weiß es, ich weiß es auch nicht ganz genau, vielleicht auch aus dem Grund,
weil ich noch nie ein böswilliges Vorhaben hatte.
Sehr gut.
Letztendlich haben wir auch ein Team, das ist das CPR-Team,
die sich eben um diese ganze Robustheit des Gesamtsystems und der Infrastruktur kümmern.
Und die haben auch irgendwo bei den Deployments und bei den, wenn bevor etwas produktiv geht,
die Aufsicht oder sage ich jetzt,
mal die Hoheit und überwachen das so ein bisschen, dass alles korrekt verläuft.
Und dadurch wird auch ein Stück weit sichergestellt, dass jetzt nicht einfach mal irgendein Entwickler,
weil er nicht richtig zugehört hat,
eine noch nicht freigegebene Version auf Produktion bringt.
Weil das muss erstmal alles, wir haben da immer hier unser Daily,
das kommt dann vom Release Train Engineer, glaube ich, genau,
kommt das runtergeschickt, wo dann eine Freigabe für eine Version passiert.
Und dann erst kann das auf Produktion kommen.
Diese ganzen Argumente zeigen dann auch so ein bisschen darauf,
wie robust ist eigentlich eure Infrastruktur.
Wie riskant wäre es denn, jemanden in die Produktion zu lassen,
jetzt einfach nur im Sinne der Stabilität.
Wenn ihr, ich sage jetzt mal, ausreichend gute Rollback-Mechanismen habt,
dann soll er halt Kleinholz machen, dann rollen wir es halt wieder zurück.
Und das ist also auf der technischen Ebene dann,
auf der technischen Ebene das, und auf der menschlichen Ebene irgendwie,
muss man natürlich auch Leuten vertrauen.
Ich meine, es gibt ja auch Techniken, es gibt gewisse Organisationen,
die gesagt haben, wisst ihr was, wir lassen einfach niemanden auf die Produktionsumgebung.
Sondern das läuft alles nur automatisiert.
Du kannst ein neues, keine Ahnung, Ansible-Skript einspeisen,
und das wird dann halt ausgeführt, und dann gibt es einen Papertrail und so.
Aber gar niemand kommt auf die direkte Produktionsumgebung drauf.
Das wäre auch ein Weg, den man gehen kann, auch wenn er natürlich gewisse Grenzen hat.
Wir haben ja den Punkt gehabt oben, der heißt Können, Dürfen, Wollen.
Das ist ja so das Dreieck, wo ich denke, dass der DevOps-Mitarbeiter
in alle drei Bereiche vollen Zugriff haben muss, damit er intrinsisch motiviert ist.
Und da ist das positive Menschenbild dahinter.
Man kann nicht davon alles so bauen, dass nur Einzelne durchkommen,
und dass alles sicher ist. Das wollen wir auch nie.
Also so wird es auch nicht wahrgenommen, von daher.
Nee, aber diese ganze Diskussion oder das Gespräch gerade
macht mich fast schon ein bisschen neugierig darauf,
ob ich das überhaupt könnte, jetzt, heute, auf Produktion der Version hochzudeployen,
die ich nicht dahin deployen soll.
Ich kann mir nicht vorstellen, dass man dann doch so viel Macht hätte.
Du, es, du, es, du, es.
Du brauchst den Mithilfer, der hat ja den Pull-Request, oder irgendwie.
Checks and Balance gibt es ja. Einen zweiten brauchst du schon, würde ich sagen.
Ja, genau, eben. Es muss ja dann auch nochmal eine Bestätigung kommen, letztendlich.
Und es bleibt ja unter uns, also wenn ich da was probiere, dann…
Ja, ja.
Michael, mach mal. Wir schneiden das raus, aber mach mal.
Das würde ich gerne mal erleben.
Dann stehst du wahrscheinlich morgen dann in der Schweiz in den Zeitungen.
Das habe ich mir so erzählen lassen, dass das Ziel ist, was ihr nicht habt,
nämlich nicht in die Schweizer Zeitungen zu kommen.
Ja, das war eine Anekdote, die haben wir sogar zusammen mitbekommen am Anfang,
weil wir halt in Finance landen und da viel Druck drauf ist,
dass die schwarze Null steht, dass, wenn man einen Fehler macht,
hatte einer gesagt, aber sofort das auch zurückgenommen,
dann stehst du in der Zeitung. Und das war so, wo ich gedacht habe, das ist Kramer.
Oh, das ist ungünstig.
Das baut so eine gewisse Art von Druck auf, den wir nicht haben wollen.
Da ist mir lieber, wir machen einen Fehler, aber einmal und lernen dann draus
und nicht ein zweites Mal. Und das Credo ist auch das, was jetzt aktuell gültig ist.
Das war einfach nur so ein Hallo wach, da, wo ihr dran rumarbeitet.
Das kann auch mal schiefgehen und in der Zeitung landen, so Bild-Zeitung oder so was.
Ja, okay.
Ich glaube, damit wollte uns vor allem signalisieren,
dass da auch die Presse in der Schweiz durchaus sehr feinfühlig ist,
wenn da etwas passiert mit der Schweizer Bundesbahn,
dass da auch sehr fix mal ein Artikel draußen ist.
Die haben auch Haltepunkte bei deutlich weniger Mitarbeitern.
Die haben auch eine andere Pünktlichkeit.
Die zahlen auch das Doppelte von wir für ihre Mobilität
und erwarten dann natürlich auch etwas dafür.
Und das ist ja so wichtig, warum wir im Finance das Geld einnehmen müssen,
weil es ist ja durch Schweizer bezahlt, der öffentliche Transport.
Und wir sorgen dafür, dass die, ich weiß es nicht,
35, 36, 40 Prozent wieder zurückkommen durch Ticketeinnahmen.
Das ist ja…
Ich würde ganz gerne noch mal auf etwas anderes eingehen.
Nämlich, wir haben ja jetzt eine Menge Mutmaßungen angestellt
über die böswilligen Angreifer von innen.
Aber viel harmloser, was passiert denn jetzt,
wenn einer etwas verkehrt macht, trotz aller besten Absichten?
Mit anderen Worten, wie steht es denn eigentlich um Fehlerkultur?
Wie wird das denn bei euch gelebt und gehandhabt und philosophiert?
Letztendlich, wenn Fehler geschehen,
dann sind die meistens nicht alleine passiert.
Weil es gibt, sobald man etwas merchen möchte
oder auf Develop bringen möchte, muss es immer jemanden geben,
der auch diesen Pull-Request freigegeben hat,
also eine Review gemacht hat.
Also sind schon mal auf jeden Fall zwei im Boot.
Aber letztendlich, was ich mitbekommen habe,
wenn mal wirklich große Fehler in der Endkonsequenz passieren,
dieses Fingerpointing,
habe ich bisher noch nicht wahrgenommen in dem Umfeld.
Und ich habe da sogar auch mal einen Spruch gehört,
wenn man sich über unangenehme Themen oder auch Fehler unterhält,
dann war da immer so dieser geflügelte Satz,
hart am Thema, weich an der Person.
Harte an der Sache, weich zur Person.
Richtig, genau.
Und das ist mir im Kopf hängen geblieben,
weil es eigentlich genau das zusammenfasst,
wie meiner Meinung nach eine Fehlerkultur sein sollte.
Dass man, klar,
kommuniziert, was ist schlecht gelaufen,
wie können wir es besser machen,
aber jetzt nicht sagt, Mitarbeiter A, B, C,
was hast du da für einen Mist gebaut?
Genau.
Also ich glaube, dahinter steckt,
keiner will ja der Idiot sein und macht bewusst was falsch.
Davon gehen wir aus, gehört zum positiven Menschenbild.
Und ich kann das auch nur so bestätigen,
ich habe zwei Fälle erlebt, wo schwere Fehler passiert sind
und wo ich im Meeting dann mit drin war
und wo ich sehen kann man es ja nicht mehr,
wir sind ja virtuell unterwegs,
man kann das Video in die Stimme anhören,
wo ich schon gemerkt habe,
da knirscht es auf der gegenüberliegenden Seite,
es wäre schon echt gut gewesen,
wenn der Fehler nie passiert wäre,
aber die Person hat sich so zusammengenommen und gesagt,
es kann passieren, es gibt die Postmortem,
wir lernen draus und du machst den Fehler nicht nochmal.
So in der Art wie einmal ist keinmal,
zweimal ist einmal zu viel und das schätze ich aber.
Bei allem Wohlfühloase,
wie das jetzt auch manchmal so ein bisschen im Podcast rübergekommen ist,
natürlich, wenn da Fehler sind,
wir sind immer noch da,
in einem Umfeld, wo es sehr sensibel sein kann,
wenn große Fehler passieren,
dann kann die Stimmung auch schon mal kippen.
Ich bin aber der Meinung,
dann zeigt sich erstmal die Professionalität auch des Kunden daran,
wie man dann eben mit diesem Fehler oder mit der Person,
die den Fehler gemacht hat, umgeht.
Und da muss ich sagen,
habe ich das bisher auch immer als sehr produktiv wahrgenommen.
Sehr schön.
Ich habe in eurer Liste einen Satz gefunden, eine Aussage gefunden,
wo ich gedacht hätte, die kommt niemals von einem ITler,
die kommt aus der Personalentwicklung,
die kommt von diesen Chaka-Chaka-Menschen,
nämlich Feedback ist das Frühstück der Champion.
Könnt ihr das mal erläutern?
Erstmal finde ich Chaka-Chaka-Menschen einen sehr, sehr schönen Ausdruck.
Ich habe ja die Rolle als Scrum Master
und ich bin ja nicht in der Personalführung
und ich muss mir überlegen, wie ich Menschen dazu bewege,
Veränderungen wahrzunehmen,
und auch anzugehen.
Und mein Hauptmittel dazu ist, ihnen Feedback zu geben.
Also ich muss genau beobachten
und ich muss dann diese Beobachtung dem Kollegen mitteilen,
sagen, was mir dabei im Kopf vorgeht,
wie ich mich dabei fühle und wo ich mir Dinge besser vorstelle.
Und das machen wir sehr oft.
Das machen wir einzeln.
Ich als Scrum Master bin natürlich ein großer Feedbackgeber,
auch in Terminen wie dem Daily, wo man einfach sagt,
ja, das war gut, dass du Danke gesagt hast,
dass du eine Hilfestellung gekriegt hast,
dass die Idee dazu gekommen ist.
Aber wir machen es auch in so einmal im Sprint als Team,
wo man sich virtuell in einem Tool trifft und Kreise bilden kann
und sich da Feedback gibt.
Und ich muss auch dazu sagen,
dass das auch ein zentrales Thema unter allen Scrum Master waren.
Die wurden alle geschult darin,
wie man ordentlich Feedback gibt für ein Team.
Und das findet statt und ist für mich
einer der wichtigsten Mittel herauszufinden,
wo man steht, wo man schon gut ist,
wo man noch besser werden kann.
Und wenn man das von einem Kollegen hört
und das auch noch gut rüberkommt,
dann motiviert das einfach unglaublich.
Genau, also das kann ich unterstreichen.
Also Feedback zu bekommen und zu geben ist meiner Meinung nach
auch extrem wichtig für die auch persönliche Weiterentwicklung
so in dem Projektumfeld, sowohl als Entwickler
als auch so in diesen Soft Skills.
Wie gebe ich mich, wie wirke ich auf andere?
Aber also mein persönlich großes Anliegen
als Arber, als Entwickler oder als IT-Lehrer ist…
Die Lüge kommt nach dem Arber.
Genau, als IT-Lehrer ist es,
man kann, es ist auch zu viel des Guten manchmal.
Also ständig immer ein Feedback zu geben.
Ich sehe es auch im Cluster.
Wahrscheinlich unser Scrum Master wurde genauso geschult wie du.
Und er versucht jetzt auch im Cluster
eine Feedback-Kultur zu etablieren,
was auch durchaus wichtig ist, immer daran erinnert zu werden.
Man hat die Möglichkeit, sowohl Feedback zu bekommen,
als auch selber zu geben.
Aber solche festen Runden zu bestimmten Zeitpunkten
finde ich teilweise kontraproduktiv,
weil dann sagt man, wenn es zu oft ist, auch immer dasselbe
oder weiß nicht, dann findet man auch irgendwann keine Worte mehr dafür.
Und dann sitzt man sich gegenüber und sagt so,
jo, ich mag heute dein Hemd.
Gestern sah es schlechter aus oder keine Ahnung,
so auf die Spitze getrieben.
Man muss das auch üben.
Also ich bin ja ein großer Vogelfreund.
Ich fütter seit zwei, drei Jahren
und beobachte alle unterschiedlichen in meinem Garten
und ich bin da sehr zufrieden.
Ich mag beobachten.
Aber wenn man Feedback geben will, muss man davor auch beobachten.
Bei mir ist immer ein Zettel bereit.
Da schreibe ich das dann auf und ich kann das teilen mit dir.
Wenn man natürlich verordnet in den Termin kommt
und dann einfach willkürlich jemandem Feedback geben,
dann kann das auch nie inhaltsgenug sein
oder das gegenteilige Ergebnis erzielen.
Das stimmt.
Feedback geben muss man können
und auch Feedback nehmen muss man sozusagen können.
Das muss ja auch von der Kultur her so sein,
dass wir das auch annehmen können,
muss und nicht muss,
sondern dass man es annehmen kann
und dass das nicht so aufgesetzt wirkt.
Genau, auf jeden Fall.
Also ich habe heute schon zwei Kollegen Feedback gegeben
und das war einmal jemand,
der heute früh eine Präsentation gehalten hat,
die gut vorbereitet war, auf den Punkt.
Ist auch ein neuer Mitarbeiter, der sich das zugetraut hat.
Das fand ich sehr gut.
Und einmal war es ein Feedback zu einem Thema in einem Daily,
wo das Eingeständnis ist,
und das war, dass er gestern nie so gut erreichbar war
und nie so viel geschafft hat
und er sich getraut hat, das zu sagen
und im Prinzip auch weggenannt hat,
wie er da heute besser wird in dieser Rolle.
Gut, aber das muss man jetzt vielleicht dann auch
ein bisschen differenzieren,
was Holger gerade auch mit angesprochen hat.
Feedback zu Dingen oder zu Events,
die man gerade ausgeführt hat,
also sei es eine Präsentation oder mal etwas zu moderieren,
ne?
Ein Abgleich.
Dieses Feedback zu geben,
finde ich in der Regelmäßigkeit direkt danach
auf jeden Fall sehr, sehr wichtig,
dass man das auch vielleicht jedes Mal,
jedes zweite Mal bekommt,
muss man natürlich auch teilweise einfordern,
bin ich der Meinung.
Andersrum aber diese allgemeinen Feedbacks,
wo man sagt, okay, ich habe jetzt hier eine Feedback-Runde,
diese sollte man nicht zu oft machen,
denn man muss auch demjenigen die Zeit geben,
der das Feedback bekommen hat,
sich dementsprechend weiterzuentwickeln.
Wenn ich jetzt überlege,
ich habe jetzt hier vielleicht im Monat
eine Feedback-Runde mit jedem Kollegen,
wir haben jetzt sieben Kollegen im Team,
das sind sechs Feedback-Runden pro Monat,
dann habe ich in der Woche mehr als eine.
So, dann finde ich das schon sehr häufig.
Ja.
Sehr schön.
Ja, Mensch, also,
wahrscheinlich könnten wir noch eine dritte Folge aufnehmen
mit den Themen, die wir haben.
Spielend.
Mit dem, was ihr so zu berichten habt.
Ich spucke alle, jetzt müssen wir aufhören.
Jetzt müssen wir aufhören, ne?
Ja.
Also, nee, wir müssen nichts, aber wir dürfen.
Also, Spaß beiseite mit der Wortwahl.
Gibt es irgendetwas, was ihr noch zum Abschluss sagen wollen würdet,
was ihr noch nicht gesagt habt?
Denn dann würden wir so ein bisschen in den Abgesang einsteigen.
Ja, ich bedanke mich für die Gelegenheit, hier teilzunehmen
und habe eigentlich jetzt gar nicht so groß im Kopf,
wenn noch Fragen sind, können wir die beantworten,
aber ich finde, das ist eine runde Sache
und es hat mir Spaß gemacht.
Also, da kann ich mit Leichtigkeit einsteigen.
Es hat mir auch super viel Spaß gemacht,
hier auch ein bisschen mal drüber schwafeln zu können,
was wir hier Tag für Tag treiben.
Ja, genau.
Sehr schön, das freut mich.
Und schwafeln, das klingt so ein bisschen wie,
na ja, wir reden mal so ein bisschen.
Ich fand, da war sehr viel Inhalt dabei
und sehr viel, weiß ich, Zusammenhang.
Also, es hat für mich ein sehr, sehr rundes Bild gegeben,
ein sehr, sehr tolles Bild.
Und ich weiß eins, dass diese beiden Folgen
werde ich in meinen Trainings immer empfehlen.
Vielleicht können wir die sozusagen
als Voraussetzung mal einbauen.
Das heißt, jeder, der ein Training bei uns besuchen will,
der muss diese beiden Folgen erstmal hören,
damit er weiß, auf was er sich einlässt,
wenn er Def Ops macht.
Das Schwafeln können wir gerne rausschneiden.
Sehr schön. Dann sage ich vielen Dank, Luca.
Ich würde sagen, dir überlasse ich jetzt mal gerne das Schlusswort.
Ja, da gibt es ja fast nichts mehr hinzuzufügen.
Ich möchte mich auch nur nochmal bei euch bedanken dafür,
dass ihr euch die Zeit genommen habt heute
und dass ihr uns so sehr habt teilhaben lassen
an der Art und Weise, wie ihr arbeitet.
Ich fand das unglaublich spannend.
Insofern vielen Dank dafür.
Ja, wir bedanken uns.
Genau. In diesem Sinne wünsche ich euch einen ganz tollen Tag
und vielen, vielen Dank für diese zwei tollen Podcast-Folgen.
Bis zum nächsten Mal.