Folge 56: DevOps bei T-Systems MMS 1/2

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

Inhalt laden

Heute haben wir Michael Glathe und Holger Helas von T-Systems MMS zu Gast.

Die beiden berichten von ihrer täglichen Arbeit und helfen uns, DevOps Theorie und gelebte Praxis zu verbinden.

In der Tat war dieses Gespräch so angenehm und spannend, daß es uns nicht gelang uns kurz zu fassen, so daß wir es in zwei Folgen aufgespalten haben.

Heute hört Ihr einen etwas allgemeineren Teil, die kommende Folge wird demgegenüber etwas praxisorientierter sein.

In dieser Folge des Podcasts „DevOps – auf die Ohren und ins Hirn“ tauschen sich die Gastgeber Dirk Söllner, Falko Werner und Luca Ingiarni mit ihren Gästen Holger Helas und Michael Glathe von T-Systems MMS aus Dresden über verschiedene Aspekte von DevOps aus. Die Diskussion umfasst praktische Erfahrungen und Herausforderungen im Bereich DevOps, insbesondere im Kontext der Arbeit bei T-Systems MMS. Die Teilnehmer erörtern verschiedene Themen, von der Bedeutung des Übens und des Lernens im Arbeitsalltag bis hin zu spezifischen Projekterfahrungen und den Herausforderungen im Umgang mit DevOps in einem großen, komplexen Projektumfeld.

Inhalt

  • Definition und praktische Bedeutung von DevOps
  • DevOps im Kontext von T-Systems MMS
  • Üben und Lernen im Arbeitsalltag von DevOps-Profis
  • Spezifische Herausforderungen und Lösungsansätze in großen DevOps-Projekten
  • Erfahrungen und Erkenntnisse aus der Arbeit von Holger Helas und Michael Glate
  • Diskussion über die kulturellen, organisatorischen und technischen Aspekte von DevOps

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 neuen Folge des Podcasts
DevOps – auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingiarni, Dirk Söllner und Falko Werner.
Wir sind Trainer für DevOps und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns drei kulturelle, organisatorische und technische Aspekte.
Diese diskutieren wir mit Experten aus der Praxis oder in einer gemeinsamen Folge zwischen uns dreien.
Heute haben wir wieder mal Gäste aus der Praxis, nämlich sogar zwei.
Holger Helas und Michael Glate von der T-Systems MMS aus Dresden.
Ich habe die beiden in einem Training kennengelernt, wo sie mich unterstützt haben
für die T-Systems MMS und habe gefragt, ob sie einfach bei uns hier mal ein bisschen was von dem berichten wollen,
was sie auch in der Praxis, was sie in dem Training berichtet haben.
Wir haben ein ganz tolles DevOps-Projekt, wobei ob es ein Projekt ist, das klären wir gleich noch,
aber wir haben ein ganz tolles Thema, wir haben einen ganz tollen Kunden
und insofern freuen wir uns auf ein oder zwei Folgen,
denn die Themen, die sie uns gegeben haben zur Vorbereitung, die sind so lang und so interessant,
dass wir gesagt haben, da können wir eventuell sogar zwei Folgen draus machen.
Also insofern freuen wir uns auf Holger und Michael und ich würde sagen,
Holger, stell dich mal doch vielleicht mal ganz kurz vor.
Ja, herzlich willkommen. Holger, mein Name, 40 Jahre alt, frisch aus der Quarantäne mit drei Kindern,
von daher weiß ich noch gar nicht so richtig, heute die ersten Arbeitstage hinter mir
und in meiner Rolle als Scrum Master für drei Teams mit so 20 Mann tätig.
Und wir waren beim Dirk.
Ich bin der Schulung und das hat uns, da haben wir schon einen guten Austausch gehabt
und das führen wir heute weiter.
Genau, dann würde ich mich mal kurz vorstellen.
Ich bin der Michael, 28 Jahre jung und bin in dem Projekt, was Dirk kurz angeteasert hat,
als Entwickler tätig und werde aus der Sicht meiner Rolle berichten können,
was da in der Praxis so vor sich geht.
Super.
Endlich ja mal ein DevOps-Engineer hier an Bord, hoffe ich doch mal,
weil sonst haben wir immer nur schlaue Leute, so wie Luca und Falco und mich,
aber hier haben wir jemanden, der von der Front berichten kann.
Sehr schön. Interessant fand ich auch, Holger, du hast dein Alter genannt.
Michael hat sein Alter als jung bezeichnet, aber ich kann dich beruhigen,
mindestens ich bin auch noch ein bisschen älter.
Also insofern kriegen wir das hin. Heute haben wir eine gesunde Mischung.
Sehr schön.
Die erste Frage, die wir in dem Podcast immer haben,
ist das Thema, wie definiert ihr oder wie definierst du DevOps?
Wie würdest du DevOps beschreiben?
Und ich würde sagen, dann lass uns mal bei Michael anfangen.
Michael, was ist für dich DevOps?
Genau, also die Frage ist auf jeden Fall schon mal richtig.
Was ist für mich DevOps?
Ich denke, da gehen die Meinungen oder die Ansichten auch sehr stark auseinander.
Für mich speziell als Entwickler bedeutet dieses DevOps eher,
sage ich mal, das Aufgabenumfeld oder die Zuständigkeit.
Also wofür oder was wird von mir erwartet?
In einem Projektumfeld als Entwickler, in dem Fall eben nicht nur die reine Entwicklung,
sondern halt auch eben bestimmte Aktivitäten im Betrieb, auf der Produktion.
Also quasi nicht mehr nur dieses klassische Entwickler-Dasein,
sondern zusätzliche Aufgaben, die durch das DevOps mit dazukommen.
Aber ich denke, da kann man, wenn man jetzt Holger fragt,
dann auch noch mal eine andere Sicht.
Dann übernehme ich gleich.
Also ich würde die Frage beantworten,
dass ich es nicht weiß.
Das wurde schon in so viele Richtungen hin diskutiert.
Für mich macht es aus, dass ich mit einer größeren Vielzahl an Menschen zu tun habe.
Es gibt einfach Testerinnen, Entwickler, Kollegen,
die sich tief unten in Atmosphären auskennen, die ich noch nie gesehen habe.
Und das macht mir Spaß, das ist das eine.
Und das andere ist, dass die Kollegen das selber in der Hand haben,
von der Idee bis zur Umsetzung.
Und für mich sind die dadurch motivierter und ich arbeite einfach gern mit
motivierten Personen, weil da kommt Spaß rüber,
da kommen gute Ergebnisse raus und deswegen DevOps.
Super. Okay, dann haben wir das ja schon geklärt.
Und ich finde es immer wieder interessant,
wie viele unterschiedliche Beschreibungen wir dafür bekommen.
Und ich glaube, wenn jemand eine DevOps-Schulung jetzt konzipieren würde,
dann könnte er wahrscheinlich den Podcast immer so die ersten fünf Minuten anhören.
Dann hätte er schon 20, 30 Folien voll mit Themen,
die man da behandeln müsste.
Das ist so, so vielfältig.
Also vielen Dank auch für eure beiden Beschreibungen oder Definitionen.
Sehr schön. Gut, wir haben es gesagt, dass wir von euch eine Liste bekommen haben
von Themen, über die ihr sprechen könntet oder auch wolltet.
Denn ihr seid ja nicht nur in dem Podcast hier unterwegs als DevOps-Experten,
sondern auch bei euch bei der T-Systems MMS.
Und da sprecht ihr auch über Themen.
Und insofern haben wir gesagt, Mensch, das sind so viele gute Themen.
Wir haben sie ein bisschen
für uns sortiert, aber ich finde es einfach gut,
was ihr da so geliefert oder bereitgestellt habt.
Und ich würde einfach mal so mit dem ersten Punkt anfangen,
den wir so ein bisschen bei Organisation und Werte einsortiert haben.
Und da habt ihr geschrieben Üben, üben, üben oder geht uns die spielerische Art verloren?
Ohne Spieltrieb keine menschliche Entwicklung, nur noch triste Perfektion.
Und das finde ich so interessant, weil das eben was Übergreifendes ist.
Holger, du hast es eben gesagt, du arbeitest gern mit Menschen zusammen,
wo es Spaß macht.
Das ist ja letzten Endes was, denke ich, nicht nur beim Lernen motiviert,
auch beim Arbeiten motiviert.
Also insofern siehst du gegebenenfalls die Gefahr,
dass die spielerische Art verloren geht durch das ganze Thema DevOps?
Ja, der Fokus liegt bei mir bei dem Ausdruck auf dem Üben.
Ich habe so das Gefühl, wenn man es zum Beispiel mit dem Fußball vergleicht,
die tun 95 Prozent trainieren und fünf Prozent haben sie Spiel.
Und in der Softwareentwicklung ist es andersrum.
Und das Üben, das macht aber Spaß und da entstehen andere Dinge.
Und wir versuchen immer, die Formate zu finden, wo man halt auch ins Üben reinkommt,
wo Ideen gechallenged werden.
Und deswegen war mir das so wichtig.
Also wie kommt man hin, dass man offen ist, dass man lernt, dass man neue Dinge tut?
Und ich musste bloß gerade meinen Rechner entsperren.
Das kommt jetzt in den Podcast mit drauf.
Aber es passt, deswegen bin ich jetzt ein bisschen aus der Idee raus.
Und wir versuchen halt Erfahrungen damit zusammen.
Zum Beispiel haben wir gerade einen Disaster Recovery Test.
Wir haben eine Zahlmittelkette mit verschiedenen Dienstleistern
und da gab es mehrere Problemfälle.
Und wir tun immer wieder neue Probleme feststellen und nie üben,
sondern immer nur direkt knallhart Einsatz machen und entstören.
Und wir versuchen, die jetzt zusammenzukriegen
und halt so produktionsnah wie möglich wirklich mal ein Inzident da platzen zu lassen
und dann zu schauen,
wie die einzelnen Menschen und die Menschen müssen ja noch zusammenarbeiten,
miteinander handeln und wollen dann rauskriegen,
was gut lief und was nicht gut lief.
Und von den Formaten gibt es ein paar.
Wir haben noch ein anderes Format, wo auch viel geübt wird.
Alle, die bei uns eine Rufbereitschaft machen,
müssen so eine Rufbereitschaftsschulung.
Und da kriegt man dann einen Anruf und hat einen Echtfall.
Und auch da wird geübt.
Und ich habe das Gefühl, dass die Menschen daran Spaß haben,
dass die da eine Rückmeldung kriegen, wo sie gut sind, wo Themen noch flach liegen,
wo sie sich weiterentwickeln können.
Und dann kommt halt diese spielerische Art rein.
Und die ist auch ein bisschen das Salz in der Suppe.
Ja, ich würde mal kurz auch was zu sagen.
Ich finde es gut, dass das Holger so anspricht im Sinne von,
dass der Entwickler auch manchmal einfach immer nur am Reagieren ist,
also quasi löscht, wo es brennt und selber dann gar nicht in diese Möglichkeit gerät,
dann neue Dinge auszuprobieren oder halt eben sich auf den Ernstfall vorzubereiten.
Klar hat man jetzt in dem Projekt
hier bei der, wo wir beide mit involviert sind, was Holger angesprochen hat,
einige Formate wie diese Schulung von dem Picket-Dienst, also der Rufbereitschaft.
Allerdings kann ich das nicht so ganz unterstreichen,
denn wir haben ja auch in dem Sprint-Zyklus immer noch als Entwickler am Ende so eine Phase,
die sehr viel Spaß macht, die so zwei bis drei Wochen lang ist,
wo wir eben Neues ausprobieren können, wo wir Innovationen mit vorantreiben können.
Wir nennen das IP-Sprint, wo wir dann Ideen oder Probleme mal aufschreiben,
besprechen im Team und dann vielleicht mal challengen und daran ein bisschen was arbeiten.
Aber vielleicht muss man dazu sagen, ich bin auch in einem anderen Team jetzt als der Holger.
Klar, wenn man jetzt in Zahlung da ganz, ganz viele Brände hat
und die dann am Ende nur noch am Löschen ist, das macht keinen Spaß.
Das sehe ich ein, genau.
Mhm.
Vielleicht sollte man wissen, was über euch ist.
Ich wollte ja über euer Projekt oder über euer Programm erzählen,
weil ich habe ja gesagt, ein interessantes Programm oder Projekt, wie gesagt,
das müssen wir noch mal klären, ob das für euch ein Projekt ist, wie ihr das seht.
Vielleicht könnt ihr da mal ein bisschen was zu berichten,
weil das sicherlich auch sehr interessant ist für die Hörer,
dass wir eben nicht über ein Produkt sprechen, was irgendwo so eine App ist oder so,
sondern das ist ja ziemlich sichtbar, das, was ihr da baut und betreibt.
Wir sind bei der SBB in der Schweiz tätig,
Mobilitätsdienstleiter.
Da sind recht viele Unternehmungen unter dem roten Dach vereint
und wir speziell sind da in Zahlung drin.
Es gibt ganz viele Transaktionen, ob sie nur über das Mobile naht hier in der Schweiz
oder am Schalter gemacht werden.
Es gibt unglaublich viele Zahlmittel und in der Kette hängen auch ganz viele andere Dienstleister mit drin.
Man ist nie allein.
Also DevOps umfasst jetzt ja nicht bloß das, was wir direkt beim Dienstleister tun,
sondern oft sind auch externe Partner mit dabei.
Und, äh,
da sind halt viele Transaktionen am Tag tätig, über 200.000.
Und die müssen halt durchprozessiert werden und immer am Laufen gehalten werden.
Und der DevOps-Anteil ist dann da halt dafür zu sorgen,
dass auf der einen Seite die Produktion immer läuft.
Das ist auch die erste Priorität.
Auf der anderen Seite, dass die Wünsche der Kunden und der Vertreter im Unternehmen der SBB,
die das übersetzen in Form von Epic Features User Stories,
dann auch stabil eine Weiterentwicklung erfährt.
Und auf den zwei Beinen muss man immer hin und her springen.
Man darf aber keins von den beiden irgendwie mal eine längere Zeit eingeknickt lassen,
weil dann wird’s schwierig.
Deswegen ist das so anspruchsvoll, nenn ich’s mal.
Aber okay.
Okay.
Genau.
Das heißt, wenn ein Schaffner in einer Schweizer Bahn ein Ticket kontrolliert,
dann läuft das sozusagen über euer Produkt oder über eure Produkte?
Das muss man ein bisschen differenzieren.
Also letztendlich arbeiten wir an,
wenn man das als Produkt bezeichnen möchte,
an mehreren.
Also es gibt sowohl den Webshop,
also was jeder Kunde in der Schweiz oder wir hier von Deutschland aus einfach auf unserem Handy aufrufen können.
Dann gibt es aber wiederum das Kassensystem, also dieses CASA.
Man muss sich das vorstellen, jetzt in Deutschland,
man geht in ein Infozentrum und dann sitzt da ein Angestellter vor einem Rechner
und möchte dir ein Ticket ausdrucken oder dir eine Erstattung machen, was auch immer.
Und dann arbeitet er mit einer Seite, Produkt nenn ich’s jetzt mal,
das heißt bei uns CASA.
Dafür sind wir quasi auch noch zuständig letztendlich.
Und das sind so zwei Dinge, für die wir uns offensichtlich kümmern,
die man selber sehen kann.
Der Holger mit seinem Team ist da, wie er gerade beschrieben hat, in den Finanzen tätig.
Für mich in meinem Team als Entwickler geht es dann eher darum, was passiert nach der Fahrt.
Also in der Schweiz heißt es Service à prévent,
wenn ich das hoffentlich richtig ausgesprochen habe.
Ein französischer Begriff, war ich nie gut.
Jedenfalls heißt es, was passiert, wenn man die Reise getätigt hat oder sie eben nicht antreten konnte.
Also man hat einen Erstattungswunsch, man möchte etwas teilerstatten lassen.
Und da muss man sagen, sind die Schweizer schon sehr sehr kulant, was da zu erstatten geht.
Das ist schon ganz schön Wahnsinn.
Und da muss man natürlich auch gucken, mit den ganzen Providern und Drittsystemen zusammenzuarbeiten.
Gerade im internationalen Personenverkehr
hat man ja da auch grenzübergreifende Themen, wo man dann eben gucken muss,
ja okay, wie kriegt man das Geld wieder anteilig, was passiert da drumherum.
Und dann setzt natürlich Holgers Team wieder an.
Wenn wir sagen, ja okay, wir erstatten euers, dann…
Ja, wir haben dann wieder Probleme, wenn in einem Land der Mehrwertsteuersatz gehoben oder gesunken wurde.
Das war ja letztes Jahr gang und gäbe während der Pandemie.
Und dann spielen wir wieder zusammen in größeren Unternehmen.
Aber das ist dann nicht mehr mein Problem.
Ich habe jetzt gerade auch noch mal kurz eine Nachfrage, wo wir vorhin diese Überschrift üben, üben, üben hatten.
Ich habe mal gehört, dass DevOps irgendwie um Automation ginge. Sollte ich denn dann überhaupt noch üben müssen?
Automation in welchem Bereich? Also Testautomatisierung würde mir da jetzt als erstes einfallen.
Naja, also meine Antwort darauf wäre, dieses Mobilitätsunternehmen mit seinen 300 verschiedenen Unternehmungen,
die da sind und der Vielzahl an Tickets, dass da alles automatisiert ist.
Das ist eine Ausbaustufe, die können wir uns vorstellen.
Aber ob die irgendwann erreicht wird, das ist schwierig.
Nach wie vor sind Menschen notwendig, um halt Brüche in Unternehmen oder in Tools oder in Fehlermeldeprozessen zu machen.
Und das muss nach wie vor noch geübt werden.
Es ist ja nie dieser ominöse Button, der in vielen Köpfen hängt, auf den man draufdrückt und dann wird da paketiert und ausgeliefert.
Und es ist sofort live. Also es gibt wirklich mehr als genug Sachen, die man übt.
Und mein Gefühl ist halt, wenn man die Möglichkeit gibt, zu üben, dass die Mitarbeiterinnen sicherer werden,
Vertrauen haben und damit auch besser handeln in ihrer täglichen Arbeit. Und deswegen mein Plädoyer fürs Üben.
Genau. Aber mich würde der Punkt mit dem Automatisieren gerade noch mal interessieren, Luca, an was du da gedacht hast.
Ja, ich meine, ich gebe es zu. Die Frage war natürlich auch ein bisschen hinterhältig gestellt.
Aber ich war so erinnert an einen anderen Podcast, den wir hier gemacht haben, wo wir einen Site Reliability Engineer von Google zu Gast hatten.
Und der hat auch etwas gesagt, was ich eben so bemerkenswert fand. Er hat gesagt, die befinden sich immer in diesem Spannungsfeld.
Eigentlich wollen sie alles wegautomatisieren, was sie irgend können.
Macht ja auch Sinn, wenn du irgendwie fußballfeldweise Server betreiben musst.
Aber andererseits ist es ihnen ganz wichtig, dass jeder SRE sich …
sicher fühlt, selbstbewusst fühlt, auch manuell sogar auf Produktionsumgebungen rumzufuschen, weil früher oder später wird er es eh tun müssen.
Ja, das ist aber auch der Klassiker. Also wenn ein Neuer in das Projekt reinkommt und wir ihm am Anfang erzählen, du hast ab morgen Zugriff auf Prod und auch die Rechte
und du dürftest, wenn du wolltest, da was ändern und das würde direkt am Schalter oder im Mobile sein, dann hätte er einfach zu viel Angst.
Oder irgendwelche andere Sinne schlagen fehlen und er macht es einfach.
Aber ich sage halt, über das Üben kommt man ran. Also was ist die andere Methode zu lernen in so einem Projekt?
Und das ist ja riesig, dieses Umfeld. Das ist ja zugucken, aufschreiben, notieren, ausprobieren, aber irgendwann muss man ja auf Produktion kommen.
Genau. Und wenn da dann eben das Üben fehlt, dann ist es auch wichtig, in einem gesicherten Umfeld zu sein mit dem Team, wo man meistens dann auch erfahrene Mitglieder dabei hat,
wo, sage ich auch, Dokumentationen vielleicht schon existieren von Fehlern, die mal aufgetreten sind und die schon mal da waren.
Und das macht ja keinen Sinn, einen neuen Mitarbeiter in ein Haifischbecken zu werfen, dass er seine Erfahrungen erstmal selber sammeln muss,
sondern dass er dann immer Dokumentationen nochmal beiseite hat oder weiß, wo er es findet zumindest, um dann auf Dinge reagieren zu können, die er zum ersten Mal sieht.
Aber das Problem hatte man schon mal. Das hat mal jemand zu mir gesagt, ja, dann google doch einfach, ich wette mit dir, dass irgendjemand auf der Welt das Problem schon mal vor dir hatte.
So.
Und so läuft es mit einer guten Dokumentation eben von Fehlern, gerade wenn man sagt, man ist in der Rufbereitschaft und da passiert etwas, dann muss man immer diese Fallstricke oder dieses Sicherheitsnetz haben, gerade als neuer Entwickler.
Also das war ein tolles Stichwort, Entwickler in der Rufbereitschaft, das werden wir sicherlich nachher nochmal aufgreifen, aber jetzt habe ich noch eine andere Frage, wenn ich mich in die Lage eines Controllers versetze oder in das Business,
also bei der SBB wird es ja sicherlich auch Business geben, wird es Controller geben, die aufs Geld gucken und wenn ich jetzt mir so vorstelle, üben, üben, üben, ja, spielerische Art, wir wollen was durchprobieren, das kostet doch und das bringt für mich keinen Wert, oder?
Naja, der Controller, das ist ja so, der ist eher auf der automatisierten Seite, weil er viele Transaktionen oder viele Prüfungen machen muss zu einem regelmäßigen Zeitraum, der tut jedes Release, was gebaut wird, daraufhin prüfen,
dass am Ende die schwarze Null steht und bei 250.000 Transaktionen täglich über so eine drei Wochen Sprintzeit, wenn da Neues reinkommt, ist da einiges drin, der ist wahrscheinlich für Automation auch sehr willkommen und will gar nicht so links und rechts so viel Überraschung haben, aber wir haben den einen Aspekt angesprochen, der neue Mitarbeiter braucht es für die Sicherheit und für mich braucht es auch der bestehende Mitarbeiter, das ist das Salz in der Suppe, weil so eine Übung, wie wir es jetzt machen mit fünf Dienstleistern, wo man auf so ein Niveau kommt, dass man sich erbaut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut
hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich
Ich hätte jetzt sogar gedacht, dass du auch noch ein bisschen darauf abhebst,
dass der Vorteil bei diesem Üben ja auch derjenige ist,
dass man dann im Fall der Fälle besser ist.
Also dass es sich schlussendlich auch für einen Controller rechnet,
wenn man einfach sozusagen mal über die gesamte Zeit sich das anschaut.
Also nicht nur, naja, jetzt sitzen sie zwei Tage und üben irgendwas und bauen nichts.
Ich kriege keine Funktionalität, aber es lohnt sich eben für das Gesamtthema.
Ja, nicht für die Schule, für das Leben lernt man noch.
Naja, letztendlich ist, glaube ich, die Übung oder das Üben, worüber wir hier sprechen,
eher dieses, wie gehe ich an Probleme ran, an neuen Problemen?
Und wie finde ich schnell eine Lösung dazu, wenn ich das Problem vorher noch nicht gesehen habe?
Weil ich meine, wir sprechen jetzt als Entwickler da sein.
Zum Beispiel, ich habe das über meine Ausbildung, über mein Studium zum gewissen Teil gelernt,
dieses Handwerkszeug, wenn man das mal so runter bricht.
Wir sprechen hier jetzt nicht von Skifahren.
Ich spiele Geige und muss da jetzt durch Wiederholungen üben,
sondern eher, man hat das Handwerkszeug und durch Erfahrung im Projekt
und mit Arbeit mit dem Code und den Systemen und den Monitoring-Systemen
eignet man sich ja ein bestimmtes Verständnis von diesem System an.
Und wenn man dieses als Entwickler hat, klar, dann wird es immer wieder irgendwelche Probleme geben,
die man vorher noch nie hatte.
Aber, okay, da sind wir wieder bei dem Üben.
Dann muss man üben, wie gehe ich an dieses Problem?
Dann muss man eben ran mit dem Handwerkszeug, was ich habe.
Verständnis plus eben die Basics, die man als Entwickler gelernt haben muss.
Und demnach ist es dann einfach auch Erfahrung, die man sammelt.
Und dadurch kann man halt dieses fehlende Üben vielleicht durch die Erfahrung der Kollegen im Team,
die schon länger dabei sind, ein Stück auffangen.
Das dehnt sich jetzt, das geht aus Üben schon raus in Richtung Lernen
und vor allen Dingen auch, wie so ein Neuer reinkommt.
Ich finde das auch gut.
Wir hatten in unserer Demo zum Beispiel mal den Part,
dass dir immer ein Bug gezeigt wurde und erklärt wurde mit Fokus,
wie habe ich überhaupt rausgefunden, wo der Fehler ist.
Und ein Erfahrener wird da aus irgendwelchen Logs was rauslesen,
was du nie siehst oder in Dinge reingucken, Schubladen aufziehen, die du nie gesehen hast.
Und dann, ja, soll das halt aus dem einen Kopf in den anderen.
Und hoffentlich steht er dann vor der Situation mal und muss da die gute Lösung finden.
Aber weil wir ja den Rückschuss nochmal zur Automatisierung finden würden,
wir haben ja gerade beschrieben, das Problem ist immer ein Neues
und das ist halt schwer zu automatisieren.
Deswegen hat der Mensch seine Berechtigung.
Wenn ich immer nur Transaktionen nach Schema X mache,
dann kann ich da den Button hinsetzen und das schwarze Loch automatisiert alles
und dann wird es ausgeliefert.
Aber so weit sind wir noch nicht.
Ich habe auch mit dem Begriff der Automatisierung immer noch ein kleines Problem.
Klar kann man Tests automatisieren, bestimmte Testszenarien per Selenium,
was auch immer, die Oberfläche und Prozesse testen.
Von deinem Produkt oder von einem System.
Aber darüber hinaus, wenn ein neues Feature ansteht,
wenn neue Anforderungen kommen vom Business, vom PO oder was halt im Planning angesprochen wird,
dann ist es da schwierig, gerade in so einem komplexen Umfeld,
ohne jetzt dem Menschen auszukommen.
Auf jeden Fall.
Ja, das ist Balsam auf meine Seele.
Ich bin ja eigentlich ein altgedienter Software-Tester und ich sehe das ganz gleich wie du.
Ich meine, Testautomatisierung ist ganz toll und ich möchte sie auf gar keinen Fall missen.
Aber nichts geht über einen mit ausreichend Bosheit gesegneten Tester.
Der findet Sachen, die findet kein Automat jemals.
Zumal die Testautomatisierung, gerade was ich angesprochen habe mit Selenium,
jetzt nur Prozesse testen kann.
Der Code oder bestimmte Module müssen immer noch anders getestet werden mit Grenzkriterien,
wo auch meiner Meinung nach immer noch zu wenig Zeit reingesteckt wird jetzt als Entwickler.
Und da fasse ich mich auch um meine eigenen.
Also definitiv, dass man erst mal das Feature fertig kriegen möchte und sagt,
hier, ich habe das Ticket abgearbeitet.
Testen, ach so, ja, wird schon funktionieren.
So schlimm ist es nicht, jetzt mal so unter uns.
Aber es ist immer noch mal so eine Sache, die noch mal oben drauf kommt,
die man vielleicht jetzt auch nicht mitgeplant hat an Zeit.
Da muss man sich immer wieder daran erinnern,
oh, hier, wenn ich sage, okay, ich brauche so lange für ein Ticket,
aber plus, ich schreibe ordentliche Tests.
Das muss vielleicht noch in den Köpfen der Entwickler ein bisschen mehr ankommen.
Dass das sehr, sehr wichtig ist.
Aber da sind wir ja beim DevOps-Ansatz.
Also ich glaube, wenn was Neues entwickelt wird, dann gehört es dazu,
dass auf einer sehr produktionsnahen Umgebung der Screenshot angehangen wird,
ein Jira-Ticket, dass der Test erfolgreich durchgeführt wurde.
Und dann wird es abgenommen.
Und das muss halt auch der Entwickler machen, der es entwickelt hat.
Der muss auch den Test dafür neu schreiben.
Der muss auch sorgen, dass es getestet wird
und auf die richtige Produktionsstraße gebracht wird.
Und da sind wir ja dann wieder dabei.
Aber es sind noch Menschen, die da tätig sind.
Naja, tatsächlich geht täglich bei uns der erste Blick aufs Cleopatra-Board,
wo wir dann…
Du musst erklären, was es ist.
Ja, das Cleopatra-Board ist bei uns so ein Monitoring-Tool,
wo wir alle unsere Anwendungen sehen, welche Versionen laufen drauf,
wo wir dann uns auch bestimmte Test-Automatisierungen anzeigen,
die halt in Regressionen täglich zweimal auf den unterschiedlichen Umgebungen laufen.
Und da sehen wir, okay, was ist hingefallen?
Ja, die starten wir als Entwickler gar nicht.
Die laufen einfach irgendwann los.
Und täglich sitzt unser Scrum-Master zum Beispiel, der Hannes,
im Scrum-Master-Daily und da wird geguckt…
Mit mir?
Genau, mit dir.
Da ist viel Rotes.
Was ist denn da los?
Und dann wird dann eine Aussage getätigt werden müssen.
Okay, wir haben das auf dem Schirm, wir fixen das.
Oder Umsystem A reagiert nicht, wir kriegen die Verträge nicht und so weiter.
Das sind die meisten Antworten dann letztendlich,
weil wir immer sehr abhängig sind von dem,
was drumherum ist bei uns.
Aber so sieht Test-Automatisierung bei uns letztendlich dann aus, vom Prozess.
Da muss ich auch immer dran denken.
Ich gebe eine Vorlesung an der FH, Software-Qualitätssicherung.
Und wenn ich da…
Das sind alles so berufsbegleitende Studenten.
Die arbeiten also irgendwie alle als Software-Entwickler.
Wenn ich die frage, wer von euch testet denn eigentlich?
Dann herrscht immer so betretenes Schweigen.
Insofern finde ich es schön, dass ihr das anders macht.
Auch, ich meine, wenn man immer noch sich steigern kann oder sowas.
Aber ich befürchte, ihr seid da wesentlich weiter vorne,
als mir lieb ist, als Nutzer von Software.
Ja, aber das ist ja das Ganzhaltige, wo ich auch sage,
dass das die Menschen motiviert.
Wenn das Thema das erste Mal ausgesprochen wird vom Business
oder man es selbst einbringt,
wird es halt irgendwann in eine brauchbare Programmiergröße runtergebrochen,
wird refined.
Da kann man bei der Idee schon dabei sein,
kann vielleicht auch eine Architektur mit beeinflussen.
Selbst wenn man bloß Entwickler ist,
nicht mal eine Architektenrolle hat,
man kann sich dann zu dem Team mit hinzubringen.
Man kann es umsetzen, man kann es testen,
man kann es in die Welt bringen,
man kann die Bugs lösen.
Das ist halt von der Wiege bis zur Bar.
Genau.
Und ich meine, es ist ja auch im Grundeigensten Interesse des Kunden,
dass das System, gerade wenn es um Geld geht,
um Geldfluss, dass da das auch ordentlich getestet ist.
Ich meine, bestes Beispiel jetzt von meiner Sicht bei der Erstattung,
dass man dem Kunden nicht mehr Geld zurückzahlt,
als das Ticket gekostet hat.
Ich finde das ja kundenfreundlich.
Naja, also für uns ist der Kunde ja letztendlich die SBB.
Der Endkunde letztendlich am Schalter.
Genau.
Aber jetzt lass uns doch mal eins weiterspringen.
Wir haben uns hier aufgeschrieben,
Inspect and Adapt.
Die Chance, das Gehege zu flicken
und nicht immer nur Schafe einzeln im Sprint einzufangen.
Um was geht es denn da?
Das ist so ein klassischer Ausspruch,
den ich schon in vielen Scrum-Teams gehört habe.
Könnten wir doch mal jetzt das schließen oder das machen,
damit wir nicht immer diese Anzahl von Bugs haben?
Und da hat es der Michael schon angesprochen.
Und ich würde noch aus Sicht des Entwicklers das berichten lassen.
Ich sage nur so viel.
Bei uns im PI sind es drei Sprints,
drei Wochen und dann sind zwei Wochen lang
ein Zeitraum, der Inspect and Adapt heißt.
Und was es ist, kann Michael bestimmt erklären.
Genau.
In dieser Zeit,
in dieser Zeit,
ganz kurz, Stopp, Holger,
die Nachfrage.
Die Zeit, Inspect and Adapt,
für mich persönlich ist das ein Termin,
ein Meeting mit
Der IP-Sprint sozusagen.
Der IP-Sprint, genau.
Das ist ja Innovation, genau.
Improvement-Sprint quasi,
also das IP steht für Improvement.
Und das sind zwei Wochen,
an denen ein Entwickler mal Themen ausprobieren kann
und mal challengen kann,
zu der er im normalen Sprint nicht kommt.
Also quasi, wo das Business nicht reinredet,
wo kein PO sagt,
hier ist ein Backlog mit,
mit geschätzten Stories
und hier ist die Priorisierung, mach mal,
sondern das sucht sich der Entwickler selber
und quasi, auf was er Bock hat
und nimmt sich das dann in dieser Zeit vor.
Kann aber auch explizit dafür genutzt werden,
um sich weiterzubilden.
Also sagen, okay,
ich habe ja noch ein bisschen Schwächen in Angular
oder in anderen technischen Systemen
und sagt, okay, ich mache da nochmal eine Schulung
oder kümmere mich nochmal darum.
So, never mind.
Und hier ist ja Inspect and Adapt angesprochen
und das ist für mich ein Termin,
der ist ziemlich nützlich aus meiner Sicht.
Ich glaube, da gehen die Meinungen auch auseinander.
Aber wir sitzen da zusammen,
wo bestimmte Statistiken mit den Entwicklern geteilt werden.
Also quasi, wie lief denn der letzte Sprint?
Was ist so das Feedback vom Business quasi?
Wie haben die das gesehen?
Wie ist unsere Lieferzuverlässigkeit?
Also wie viele Stories konnten wir in der Zeit,
die wir uns vorgenommen haben, bearbeiten?
Dann ist immer noch ein ganz nützlicher Punkt,
wie stabil sind unsere Systeme gelaufen?
Also die Ausfallzeiten prozentual dargestellt.
Letztendlich und als so eine Dinge, wo man dann halt sieht,
okay, was lief alles gut?
Das ist natürlich auch immer schön zu sehen,
aber auch auf der anderen Seite, was lief schlecht?
Und dann wird auch immer Zeit dafür gegeben,
das zu diskutieren.
Also es ist quasi wie eine,
Holger, bitte korrigiere mich da,
wie eine Kronik,
wo man dann sagt, okay, das lief schlecht.
Wir gucken mal, wie wir das verändern können mit Next Steps
und diskutieren darüber.
Genau, also die Begriffe Inspect und Adapt
ist die Retrospektive nicht vom Team,
sondern in einem Safe-Umfeld einer ganzen Art.
Und das sind bei uns 80 Leute
und zu den Terminen kommen auch immer so 30, 40 Leute
und der dauert zwei Stunden.
Und da werden die Themen als Frage vorgeschlagen,
die man betrachten will.
Und dann gibt es einzelne Breakout-Sessionen dazu.
Da werden dann die Dinge besprochen.
Und die sind dann für den nächsten Planungszeitraum
als Verbesserungen hinzuzufügen.
Und dieser Improvement-Sprint wurde ja auch noch angesprochen.
Also immer, wir haben drei Wochensprints,
davon drei am Stück sind ein PI
und danach kommt ein Improvement-Sprint.
Und natürlich ist es so,
dass Leftovers aus den Sprints da zum Teil noch gefixt werden.
Aber die Entwickler organisieren sich das selbst.
Die machen selber das Planning.
Die pflegen selber das Backlog.
Die legen selber die Priorität fest.
Die sind frei darin zu sagen,
was sie verbessern wollen,
oder ob sie in Weiterbildungen investieren.
Und das ist immer der Abschluss von so einem PI sozusagen.
Und das ist auch der Wert.
Und dann sind wir wieder beim Üben,
wie immer am Anfang.
Genau, wollte ich gerade auch sagen.
Da sind wir wieder beim Üben, die Zeit da.
Ich finde diese Metapher so schön.
Die Chance, das Gehege zu flicken
und nicht immer nur die Schafe einzufangen.
Weil ich habe ja manchmal so meine Schubladen von ITlern.
Und ich glaube, dass viele ITler eben nach wie vor
noch gerne immer wieder Schafe einfangen.
Weil sie sich da beweisen können,
wenn man das Beispiel jetzt mal nimmt.
Und ich komme ja immer in meinen Trainings
mit dem Beispiel Axt schärfen,
um die Bäume besser frähen zu können.
Ist ja das Gleiche.
Also insofern, das habe ich jetzt hier gelernt.
Ich habe das irgendwann schon mal gehört,
aber ich finde es einfach ein schönes Bild,
einfach zu sagen so,
wie kann ich denn Agiles vorgehen?
Wie kann ich ins Backend-Adapt erklären?
Nämlich genau zu sagen,
ich kann immer Schafe wieder einfangen,
aber ich kann auch mal dran gehen,
das Gehege zu flicken.
Und dann vielleicht sogar dauerhafter zu flicken.
Also nicht nur flicken,
sondern vielleicht sozusagen dann den Zaun noch höher ziehen
oder die Maschen enger zu ziehen, wie auch immer.
Also das finde ich schon sehr, sehr interessant.
Für mich sind die zwei Punkte, die da wichtig sind.
A, dass diese Zeit gegeben wird
und dass die Teams wirklich selbst organisiert
das machen können.
Und wenn man es ordentlich durchführt,
dass auch der Glaube daran wächst,
dass es einen Sinn hat,
dass es das wirklich verbessert,
weil das ja dann direkt
auf die Motivation einzahlt.
Nichts motiviert weniger,
als wenn ich permanent Bugs hinterherlaufe,
die immer, wo die Quelle immer wieder offen ist,
aber ich nie den Weg dahin schließe,
sondern es immer wieder kommen lasse,
weil ich einfach die Zeit gar nicht habe,
daran zu gehen.
Genau.
Und als Entwickler hat man da auch vor allem das Gefühl,
dass man sich da auch mal selber bei Dingen,
die einen stören oder die schieflaufen,
dass man die ansprechen kann
und dann auch mitbekommt,
ja, da kann man,
da wird drüber nachgedacht.
Also,
ich weiß noch ganz am Anfang in der Zeit,
da wurde auch mal,
oder man wird als Entwickler immer mal wieder gefragt,
von wegen Marionette oder Puppenspieler.
Es gibt einem zumindest das Gefühl,
ein Stück weit Puppenspieler sein zu können,
dass man auch mal Dinge anspricht,
die nicht gut laufen
und man dann auch einen Raum hat,
wo man diese angehen kann
oder wo zumindest das Ganze gechallenged wird.
Und das bringt schon viel.
Ich kann das nochmal
als Scrum Master Perspektive bringen.
Wir leiten ja im Sprint die Meetings
und da kann man ja auch mal messen
oder beobachten,
wer welchen Redeanteil hat
und ich kann sagen,
in den IP-Sprints,
wo das Team selber plant,
kommen deutlich mehr Mitarbeiter zu Wort.
Es ist viel diverser.
Viele, die ich sonst nie höre,
weil die Moderation halt vorgegeben ist
oder weil man sich dann zum Teil
vielleicht auch bequem zurücksetzt
und auf seinen Einsatz wartet.
Das gibt es da nicht.
Da ist das Team unter sich.
Da wird gesprochen.
Sehr schön.
Übrigens für die Zuhörer,
die sich beruflich verändern wollen,
wahrscheinlich,
man findet auch eure Webseite,
da habt ihr bestimmt auch noch freie Stellen,
denn ich denke mal,
dass von dem, was ihr dort berichtet,
ich mich als Entwickler wohlfühlen würde.
Und wir haben immer das Thema
intrinsische Motivation.
Und das, was ich bei euch raushöre,
ist eben wirklich,
dass ihr das nicht nur,
ich sag mal,
im Sinne von,
ja, wir machen mal so ein Bildchen,
als ob wir das tun,
sondern für mich klingt das so,
als ob sich das durch eure ganze Einstellung,
durch eure ganze Organisation durchzieht,
dass ihr eben Wert auf die Entwickler legt,
auf deren Motivation,
auf deren Kreativität
und dass ihr darüber ja auch
die intrinsische Motivation herbeiführt.
Aber das müssen wir machen.
Wir stellen Teams mit Leuten,
die schnell produktiv werden müssen
und wir müssen die Umgebung so gestalten,
dass sie positiv ist
und dass aus jedem das Beste rauskommt,
weil nur dann,
also es gibt ja auch ein harter Fakt dahinter,
nur dann überleben wir das halbe Jahr,
das Jahr, das nächste Jahr
und bleiben Partner
und können auch an solchen guten Projekten teilnehmen.
Ja, zum einen Partner,
aber zum anderen,
ohne dass jeder von sich aus auch mitarbeitet
und dann sagt,
hier, ich bin gerade frei.
Hat denn jemand gerade was für mich,
weil ich gerade blockiert bin mit dem Ticket?
Ohne diese Einstellung würden wir als Team
am Ende des Tages auch nicht auf unsere Ziele kommen,
die im Planning gesetzt werden
und dann hat man das Meeting mit den Business Leuten
und muss sich vielleicht für etwas rechtfertigen,
was man nicht geschafft hat,
was immer nicht schön ist.
Ja.
Aber um das zu verhindern,
ist es ein,
ja,
ist es,
nur miteinander kann man das letztendlich schaffen
und deswegen,
ja,
ist das meiner Meinung nach
eine Anforderung an eine Person,
in so einem Umfeld zu arbeiten.
Man profitiert dann eben halt auch davon,
dass der Arbeitgeber
oder sage ich jetzt mal im Projekt,
man,
ja,
ein schönes Umfeld geliefert bekommt,
aber ich,
letztendlich,
was Holger gesagt hat,
runtergebrochen,
das ist ja auch so,
dass man dann auch produktiv sein muss,
ne.
Also,
wie gesagt,
mein,
mein Eingangssatz war,
dass ich gern mit motivierten Menschen arbeite
und
die Umgebung macht da viel aus
und das miteinander
und
ohne den würde man das auch nicht schaffen.
Wir,
wir sind darauf angewiesen,
dass der,
der mitarbeitet,
sich traut,
Fragen zu stellen,
Feedback gibt,
Rückmeldung gibt
und nur,
wenn er das macht
und interagiert
und dann sind wir auch wieder bei DevOps,
weil das gehört für mich genauso dazu,
dann,
dann kommt am Ende auch das Ergebnis raus,
weil ankommen tut man nur als Team,
äh,
ja.
In der Liste,
die ihr uns,
äh,
an Themen gegeben habt,
ist so ein Begriff,
den habe ich vorher nicht geklärt,
ich habe nicht nachgefragt
und ich bin mal gespannt,
was da jetzt als Erklärung kommt.
Da steht nämlich,
Hamsterrad.
Jeder kann so viel,
wie er kann
oder jeder gibt so viel,
wie er kann.
Ja,
wir hatten das vorher schon abgesprochen,
ne,
der,
der,
der Martin kannte das auch nicht,
sozusagen.
Jetzt werden wir mal gucken.
Martin?
Das war eingebaut.
War eingebaut.
Genau,
ähm,
na ja,
also,
wenn,
wenn du mich jetzt fragen würdest,
was ich tippe,
was du damit meinst,
gut,
na ja,
dann hieße das höchstens,
im Hamsterrad befinde ich mich,
wenn es immer wieder von vorne losgeht
und immer wieder dasselbe passiert.
Ja,
kennst du das nicht,
du bist in Sprints drin,
du bist vielleicht in einem Projekt,
das schon Sprint 52 hat
und alle zwei,
drei Wochen wird das Ding neu angeworfen
und du bist die User Story Factory
und musst
am Ende die Stories liefern,
am besten mit 100% Commitment,
12 von 12 geschafft,
dann,
und dann,
halben Tag frei,
Autos suchen,
weil die Demo so
aufreibend war,
dass du nicht mehr weißt,
wo du früh geparkt hast
und dann geht’s nächste Woche
wieder los.
Hamsterrad.
Genau,
aber da würde ich dir
insofern widersprechen,
ein Hamster sieht immer dasselbe
und,
ähm,
wir,
also ich habe nicht das Gefühl,
dass ich,
ähm,
auf Arbeit komme
und jeden Tag
mit denselben Themen,
klar,
wenn ich mal ein großes,
komplexes Thema habe,
dann beschäftigt man sich
auch eine Weile damit
und dann kommen vielleicht
nochmal ein paar Bugs
in der Richtung daher,
aber das ist schon
vielfältiger
von den Aufgaben her,
zudem haben wir im Team
auch noch selber
untereinander Rollen,
also mal ein Bugs-Bug
zu sein,
dann,
wir nennen das bei uns
DevOps-Bug,
ne,
das soll jetzt nicht diese,
ähm,
diesen Podcast untergraben,
aber so,
so nennen wir diese,
diese Rolle,
der,
der für die Deployments
verantwortlich ist
und sich das Testing anguckt,
das definiert jedes Team
für sich selbst,
aber dadurch,
dass die Rollen immer wechseln,
hat man auch da
nochmal Abwechslung,
dann,
wie willst du das sagen?
Ja,
ja,
also,
der,
die Überschrift hieß ja
Hamsterrad,
jeder gibt so viel,
wie er kann
und in meinen ersten Monaten,
wo ich bei der SBB gekommen bin,
mit einer super Einarbeitung,
motiviert,
bis in die Haarspitzen,
haben wir dann angefangen,
das Team
zusammenzubringen,
die agilen Prozesse
einzuschleifen
äh,
und das war,
war wirklich motivierend,
aber du kommst da dann
irgendwann an den Punkt,
wo du einfach auch
keine Kraft mehr hast,
wo deine Selbstkontrolle
durch ist
und da war dann der Satz,
äh,
P.I. Objectives ausgelegt,
dass sich niemand hinlegt
und aufgrund des Teams ausruht,
aber,
wenn man halt so schnell,
wenn man eine User Story Factory ist
oder wenn man P.I. Objectives
immer alle ein Vierteljahr
bringen muss,
da kann nicht jeder
jeden Sprint
120 Prozent machen,
denn einen Sprint
stricht halt der hervor,
den anderen der
und ich finde,
wenn man auf so ein Niveau kommt,
dass jeder so viel gibt,
wie er kann
und dieser Satz ist wirklich gefallen,
den fand ich halt so passend,
als äh,
wie nennt man’s denn,
als,
als kooperatives Team,
wo,
wo halt nie nur
die Professionalität
im Vordergrund steht
und was jeder macht
und tut,
äh,
sondern dass man auch mal
sagen kann,
hey,
heute ist schlecht,
äh,
nicht ganz so produktiv.
Ich,
ich versteh.
Da geht’s so ein bisschen
einfach dann in Richtung Team
und ähm,
nicht toll ein anderer macht’s,
sondern together
each one achieves more,
ne,
also,
dass man sich wirklich
dann mal,
ähm,
wie du schon sagst,
nicht ausruhen kann,
aber wenn’s,
wenn’s mal nicht so geht,
dann geht’s eben nicht
und dann sollte man’s
auch sagen können
und auch sagen dürfen,
ja,
ja,
ja,
aber ich muss da jetzt mal kurz,
äh,
ich muss da jetzt mal kurz
reingrätschen,
weil das klingt jetzt immer so ganz nett
und ganz prima und so,
aber,
äh,
also,
mein Chef hätte da was dagegen,
wenn,
wenn ich sage,
öh,
also,
hm,
die Woche ist irgendwie mir so,
hm,
ähm,
nee,
Leistung muss hier.
Ja,
das ist so eine Sache,
also,
ich denke mir,
wenn ich dich als Mitarbeiter hätte,
dann würd ich sagen,
die acht Stunden,
die du täglich machst,
40 Stunden in der Woche,
entstehen ja auch Gefühle
und die Gefühle können ja auch Frustration sein,
wegen schlechter Arbeitsmittel
oder weil du nicht vorankommst
und es,
es ist kein gefühlsvoller,
äh,
gefühlsfreier Raum,
du,
klar geht’s um Produktivität
und am Ende wird gemessen,
aber deswegen bist du ja ein Team
und deswegen kann der eine mal mehr bringen
und der andere mal weniger,
das heißt,
nie ausruhen,
sondern,
da muss das Team auch schon zusammen sein
und dafür einstehen
und sagen,
okay,
das,
äh,
dann nehmen wir was dafür.
Muss ich jetzt nochmal nachfragen,
weil angenommen,
du bist jetzt doppelt so schlau wie ich,
was ich jetzt einfach mal voraussetzen würde,
dann,
ähm,
dann wär das doch irgendwie ganz schön mies
für das ganze Team,
wenn ich dann irgendwie immer nur halb so viel leiste,
wie du beispielsweise,
also,
ist das,
entspricht das dann auch dem Teamgeist?
Du fragst ja mich als Scrum Master
und das ist genau meine Tätigkeit
und ich muss da mit einer Geschichte antworten,
ich hatte jetzt das erste Elterngespräch
und der Lehrer sagte,
äh,
über Lerngeschwindigkeiten
bei seinen 28 Schülern,
der eine ist schneller,
der andere ist langsamer
und er hat das super gemanagt,
der hat gesagt,
okay,
das ist jetzt so,
das müssen wir im Klassenrat besprechen
und das ist was,
was ich täglich hab,
es gibt einfach unterschiedliche Geschwindigkeiten,
Dinge aufzunehmen
oder Dinge abzuarbeiten
und die wird’s immer geben in dem Team
und da wird’s auch immer Streit geben,
die beiden Enden werden immer gegeneinander sein,
aber,
wir müssen ja zusammen ankommen am Ende,
äh,
nur die Superhirne hinschalten,
Rücken freizuräumen
und machen zu lassen,
dann bring ich doch über die Jahre
keine,
äh,
stabile Produktion
und neue Features,
weil der,
der Wandel ist das Endstil,
was,
was Stabiles bei uns,
wir hatten letztes Jahr acht Abgänge
und 13,
äh,
Zugänge,
äh,
ja,
wo willst du’s machen?
Und deswegen finde ich dieses,
jeder gibt so viel er kann
und zwar positiv,
ausgelegt,
wichtig.
Und das auch immer sagen kann,
heute ist nicht so.
Da würde ich vielleicht auch mal als Entwickler einhaken,
ähm,
mit diesem,
äh,
im Sinne von,
aus persönlichen Gefühlen heraus zu sagen,
ich nehme mich jetzt mal zurück,
ähm,
was tatsächlich im Team oder uns im Team
noch gar nicht so groß passiert.
Ähm,
klar spielt das immer mal unterbewusst noch eine Rolle,
dass da ein bisschen,
ein bisschen Produktivität hängen bleibt,
aber nicht,
dass jetzt es so in Anführungsstrichen akut ist,
dass ein anderes Teammitglied einspringen muss.
Man hat,
es klingt natürlich immer strikt,
man hat seine drei Wochen pro Sprint,
das drei Mal
und dann ist der Sprint vorbei.
Es ist auch eine gewisse Zeit dahinter.
Und wenn man etwas nicht schafft
oder mit in den nächsten Sprint,
nimmt,
dann gibt es da kein Fingerpointing,
wo gesagt wird,
hey,
hier,
ihr habt so viel da eingeplant,
warum hast du das nicht geschafft?
Dann ist es so,
dann braucht es seine Zeit
und dann geht es halt noch mal ein Stück weiter.
Aber dieses jeder gibt so viel er kann,
würde ich jetzt halt auch fast auf neue Kollegen mitbeziehen.
Also,
wenn man einen neuen Kollegen hat,
der kann eben noch nicht so viel
oder sagen wir mal,
wir haben zwei,
der eine lernt schneller als der andere,
dann ist das eben so,
ne?
Aber wir vom Team sind darauf angewiesen,
dass beide früher oder später produktiv sind,
um uns eben gemeinsam mit nach vorne zu bringen.
Und dann ist dieses Teamkonzept
oder das Klima im Team entscheidend.
Wie wird den beiden geholfen?
Und das ist ganz normal und menschlich,
dass sie unterschiedlich schnell lernen.
Und dann können sie noch das fünfte Mal kommen,
fragen und um Unterstützung bitten.
Und dann ist es so.
Und dann wird die Unterstützung auch gewährt und gegeben.
Also ich habe noch nie im Team erlebt,
dass auf die Frage
kann ich,
kann ich dich mal um eine Meinung bitten,
dass da jemand Nein sagt.
Das ist,
finde ich,
das geht auch nicht in dem Umfeld.
Das ist,
muss ich sagen,
ist auch beachtlich,
weil gerade Architekten oder Lead-Entwickler
so viel zu tun haben.
Genau.
Und sich trotzdem immer noch die Zeit nehmen.
Und wenn es am Abend 17 Uhr dann die zehn Minuten sind,
um das zu erklären,
dann ziehe ich einen Hut davor.
Und das,
Respekt,
ja.
Genau.
Also das finde ich ganz toll,
dass ihr das gesagt habt.
Und ich finde,
dass du auch insbesondere,
Michael,
fast ganz Wichtiges gesagt hast.
Wenn einer irgendwie nicht so richtig mit dem Team mitziehen kann,
dann muss sich an irgendeinem Punkt auch das Team fragen,
warum sie den zurückgelassen haben.
Genau.
Also das fand ich ganz spannend.
Und ich habe die Frage auch deswegen gestellt,
sozusagen stellvertretend für viele Leute in meinen Trainings,
die vielleicht noch nicht so erfahren sind in agiler Arbeit
und die dann eben die ganz ehrliche Sorge haben.
Wenn ich jetzt mal den unvermeidlichen schlechten Tag habe,
trotz all meiner ehrlichen Bemühungen,
machen die mich dann kopfkürzer,
weil ich kann mich ja auch gar nicht mehr verstecken.
Also und darum finde ich,
dass ganz wichtig,
dass man,
genauso wie ihr es jetzt gesagt habt,
da auch erstens die Sorge nehmt,
sagt,
das passt schon.
Und zweitens,
dass man auch ganz klar den Spieß umdreht und sagt,
es ist auch in der Verantwortung des Teams,
dass das Team als Ganzes vorwärtskommt.
Ich würde es nochmal umdrehen.
Also die Verantwortung,
die seelische sozusagen und produktiv und gesund zu sein,
die hat natürlich jeder selber
und auf die muss er auch aufpassen.
Er muss auch gucken,
dass er nicht zu viel arbeitet,
hat und kann auch nicht immer mehr annehmen
und sich vom Management auch noch beklatschen lassen.
Nimm noch mehr dazu,
sozusagen.
Es gibt ja so verschiedene Ebenen davon,
wo das hingehen kann.
Man muss halt aufpassen.
Und das ist vielleicht ein großer Sprung.
Ich glaube,
dieser Strom an Arbeit,
was er das Hamsterrad auch festmacht,
der muss auch wirklich gut geplant werden.
Und der ist bei uns gut geplant.
Das muss abarbeitbar sein.
Das ist dieses berüchtigte Commitment,
das halt im 58. Sprint so fast gar nicht mehr hörbar ist.
Schaffen wir das jetzt so hier alles?
Fragt das Grammar.
Das Team so,
und am Ende macht man so.
Aber das ist halt wichtig.
Also das muss auch dazu passen,
was drin abgearbeitet werden kann in den Teams.
Und da immer in diesem Rahmen sage ich halt,
jeder gibt so viel er kann.
Das Ziel ist immer gesetzt am Ende.
Alle User-Stories schaffen,
die PI-Objects schaffen,
Dinge ausliefern,
die Kundenwert haben.
Das hört ja nicht auf.
Es dreht sich weiter.
Genau.
Klar.
Da kann ich vielleicht auch ein bisschen
aus dem Projekt mal reden.
Wir waren da auch an einem Thema dran,
was wir erst eingeplant haben
und dann halt auch maßlos unterschätzt haben.
Tatsächlich,
weil wir in einer bestimmten Sache
nicht einfach nur weiter so wollten,
sondern halt auch da die Chance gesehen haben,
eine Verbesserung für uns als Team reinzubekommen.
Und diese Geschichte zieht sich jetzt schon
auch eine ganze Weile und einige Sprints
und wird auch immer wieder mitgenommen,
wo wir dann halt auch uns rechtfertigen müssen.
Warum dauert es so lange?
Was sind denn die Gründe?
Aber letztendlich haben wir daraus jetzt
den Mehrwert zu generieren,
dass wir dann auch
die
jetzt auch zusammenstellen können.
Okay, welche Fehler haben wir gemacht?
Und wenn dieses Problem nochmal in der ganzen Factory,
in der Timo Factory vorkommt,
hier, so ist das Vorgehen.
Die Fehler haben wir gemacht.
Macht die nicht.
Fangt lieber gleich den richtigen Weg an.
Und dadurch haben wir dann auch nochmal vielleicht
aus dieser Zeit, die wir länger gebraucht haben,
wo wir erst mal vor eine Wand gelaufen sind,
natürlich jetzt auch zu zeigen,
hier ist die Wand,
geht mal lieber drum herum.
Ja.
Und das bringt dann auch schon mal viel,
weil man dann in einem,
sage ich mal,
konstruktiven Umfeld ist,
wie mit einem,
ich will es nicht Versagen nennen,
aber wie es mit einem Fehler
oder mit einem Fail einfach umzugehen.
Ja, für mich gehört das zu der Umgebung dazu,
die motivierend ist.
Wettbewerb ist gut,
das muss auch da sein,
aber ich würde gerne da arbeiten,
wo nett sein die Regel ist.
Und ich will auch, dass alle nett sein
und trotzdem ihre Professionalität,
Ehrgeiz und Erfolg weiter behalten.
Das ist schon richtig.
Aber irgendwo ist die Grenze.
Genau, irgendwo ist die Grenze.
Das stimmt natürlich.
Wenn es für den Kunden kritisch wird,
gerade in Sachen Hilfsbereitschaft drumherum,
dann muss man natürlich auch liefern.
Und dann ist auch mal schnell diese Wohlfühlmentalität
und Bereich vorbei,
wenn man da eben auch nicht liefert.
Ja.
Aber insofern finde ich es gut,
dass ihr den Begriff Hamsterrad nochmal erklärt habt.
Denn ich habe manchmal so diesen,
den flapsigen Spruch,
auch ein Hamsterrad kann wie eine Karriereleiter aussehen.
Das wäre natürlich nicht das, was ihr wollt.
Also deswegen ist es sehr schön gehört zu haben,
jeder gibt so viel, wie er kann.
Und das finde ich, zeigt auch,
wie ich eben vorhin schon auch gesagt habe,
dass das nicht nur einzelne Aspekte sind,
wo ihr sozusagen euch so eine agile Fassade aufbaut,
sondern wo das sich eben komplett durchzieht.
Und wo man, ich finde,
auch so nach und nach jetzt mitbekommt,
wenn das alles gemacht wird,
dann greift das quasi eins ins andere hinein.
Das heißt also,
das sind alles Aspekte,
die überall in Summe Vorteile bringen,
die natürlich auch Konsequenzen mit sich bringen.
Aber in Summe habt ihr einfach engagierte, motivierte Leute.
Und das zahlt sich eben aus.
Es zahlt sich auch aus durch Dinge,
die man vielleicht nicht messen kann.
Aber es zahlt sich eben auch aus durch,
dass ihr die Mitarbeiter an Bord behaltet
und dann doch gut performt.
Weil, das hast du ja auch gesagt, Holger,
bei allen agilen und menschlichen Sichten,
ihr müsst liefern.
Ihr müsst was abliefern.
Also nur zu sagen,
unserem Team geht es gut
und wir schaffen aber heute nichts,
das wird er nur zweimal sagen können wahrscheinlich.
Ja.
Ich gucke ein bisschen auf die Uhr.
Und wir haben ein Luxusproblem.
Nämlich das Luxusproblem,
dass wir von unseren geplanten Punkten
na ja, noch nicht mal die Hälfte abgearbeitet haben.
Was ich aber absolut super finde,
weil wir nach meiner Meinung,
nach meiner Einschätzung,
ein ganz tolles Gespräch haben.
Also ich frage jetzt mal in unserer kleinen Teamrunde.
Ist es für euch okay,
wenn wir jetzt diese erste Aufnahme stoppen,
die erste Folge sozusagen hiermit beenden
und dann quasi mit der zweiten dann irgendwie weitermachen
und wo wir dann so ein bisschen auf die Punkte
der Forbes in der Praxis eingehen?
Na klar.
Machen wir so.
Jawohl.
Gut.
Dann sage ich erstmal für diese Folge herzlichen Dank
und bis gleich zur nächsten Folge.
Auf Wiedersehen.